СИСТЕМА И СПОСОБЫ АУДИТА ВИРТУАЛЬНОЙ МАШИНЫ
SYSTEM AND METHODS FOR AUDITING A VIRTUAL MACHINE

Связанные с изобретением патентные заявки
[0001] По настоящей заявке испрашивается приоритет по дате подачи предварительной заявки на патент США №62/274,902, поданной 5 января 2016, под названием "Системы и способы аудита виртуальной машины", содержание которой в полном объеме включено в данный документ посредством ссылки.
Уровень техники
[0002] Настоящее изобретение относится к системам и способам проведения программных аудитов и, в частности, к программным аудитам, выполняемым в конфигурациях аппаратной виртуализации.
[0003] В современной программно-управляемой экономике объем и сложность поддерживаемых компанией ресурсов аппаратных средств и программного обеспечения постоянно увеличиваются. При переходе сотрудников от использования настольных компьютеров к использованию мобильных устройств, таких как ноутбуки, планшетные компьютеры и мобильные телефоны, и по мере того, как работа становится все менее локализованной, отслеживание аппаратных и программных ресурсов компании становится серьезной проблемой. Например, вместо использования единой версии программного приложения на всех компьютерах компании, в данный момент компании обычно используют несколько версий каждого приложения, учитывая различные аппаратные платформы и операционные системы, которые сотрудники используют в современном мобильном офисе. Ситуация еще более осложняется при применении обновлений программного обеспечения, когда такие обновления не могут быть единообразно переданы на все компьютеры и мобильные устройства.
[0004] Такая возрастающая неоднородность может осложнить лицензирование программного обеспечения и соглашений по обслуживанию. Более того, недавнее быстрое разрастание прикладного программного обеспечения, используемого на мобильных устройствах, создает все большую угрозу компьютерной безопасности. Вредоносное программное обеспечение и программы-шпионы могут легко скрыться среди изобилия легитимных приложений и версий, тем самым подвергая сотрудников и компанию риску несанкционированного доступа к конфиденциальным данным и, среди прочего, потери производительности.
[0005] Недавним эволюционным изменением классической модели компьютерной обработки является аппаратная виртуализация. В таких приложениях, как фермы интернет-серверов и инфраструктура виртуальных рабочих столов (ИВРС), на одной физической платформе одновременно могут исполняться сотни виртуальных машин. Такие виртуальные машины могут быть созданы и/или удалены динамически, что еще больше увеличивает неоднородность программного обеспечения, выполняющегося в одно время на соответствующей физической платформе.
[0006] Программное обеспечение для аудирования может использоваться для отслеживания программного обеспечения, установленного и/или исполняемого в компьютерной системе, в том числе для таких целей, как лицензирование, управление цифровыми правами, управление приложениями и обеспечение компьютерной безопасности. При этом растет интерес к разработке систем аудита и способов, особенно подходящих для современных виртуализированных сред.
Раскрытие сущности изобретения
[0007] Согласно одному из аспектов, компьютерная система содержит по меньшей мере один аппаратный процессор, выполненный с возможностью исполнять набор виртуальных машин (ВМ) и в дальнейшем исполнять подсистему аудита ВМ вне набора гостевых ВМ. Подсистема аудита виртуальной машины конфигурирована так, чтобы в ответ на получение запроса аудита от удаленного сервера аудита вводить агент аудита в целевую ВМ из набора гостевых ВМ, при этом агент аудита сконфигурирован выполнять аудит целевой виртуальной машины, причем аудит включает в себя элемент, выбранный из группы, состоящей из формирования списка легитимных компьютерных программ, установленных для выполнения на целевой ВМ, и определения объема аппаратных ресурсов, используемого в данный момент целевой виртуальной машиной. Подсистема аудита виртуальной машины дополнительно сконфигурирована так, чтобы в ответ на введение агента аудита побуждать целевую виртуальную машину исполнить агент аудита и в ответ на исполнение агента аудита целевой ВМ удалить агент аудита из целевой ВМ.
[0008] Согласно другому аспекту, способ включает в себя использование по меньшей мере одного аппаратного процессора компьютерной системы для исполнения подсистемы аудита виртуальной машины вне набора гостевых виртуальных машин, исполняемых в компьютерной системе. Исполнение подсистемы аудита ВМ включает в себя, в ответ для получения запроса на аудит от удаленного сервера, введение агента аудита в целевую ВМ из набора гостевых ВМ, причем агент аудита сконфигурирован выполнять аудит целевой ВМ, при этом включает в себя элемент, выбранный из группы, состоящей из создания списка легитимных компьютерных программ, установленных для исполнения на целевой ВМ, и определения объема аппаратных ресурсов, используемых в данный момент целевой ВМ. Исполнение подсистемы аудита ВМ дополнительно включает в себя вызывает, в ответ на введение агента аудита, побуждение целевой ВМ исполнять агент аудита и, в ответ на исполнение целевой ВМ агента аудита, удаление агента аудита из целевой ВМ.
[0009] Согласно другому аспекту, серверная компьютерная система содержит по меньшей мере один аппаратный процессор, сконфигурированный выполнять операции аудита на множестве клиентских систем. Операция аудита включать в себя отправку запроса на аудит в клиентскую систему из множества клиентских систем, и в ответ - получение отчета аудита от клиентской системы, при этом отчет аудита определяется подсистемой аудита виртуальной машины, исполняемой в клиентской системе вне набора гостевых ВМ, исполняемых в клиентской системе. Определение отчета аудита включает в себя, в ответ для получения запроса на аудит от серверной компьютерной системы, введение агента аудита в целевую ВМ из набора гостевых ВМ, при этом агент аудита сконфигурирован выполнять аудит целевой ВМ, причем аудит включает в себя элемент, выбранный из группы, состоящей из составления списка легитимных компьютерных программ, установленных для исполнения на целевой ВМ, и определения объема аппаратных ресурсов, используемых в данный момент целевой ВМ. Определение отчета аудита также включает в себя, в ответ на введение агента аудита, побуждение целевой ВМ исполнять агент аудита, и, в ответ на исполнение целевой ВМ агента аудита, удаление агента аудита из целевой ВМ.
[0010] Согласно другому аспекту, долговременный машиночитаемый носитель хранит инструкции, которые при их исполнении по меньшей мере одним процессором компьютерной системы побуждают компьютерную систему исполнить подсистемы аудита виртуальной машины, причем подсистема аудита ВМ исполняется вне набора гостевых ВМ, представленных на компьютерной системе, при этом подсистема аудита ВМ сконфигурирована так, чтобы в ответ на получение запроса аудита от удаленного сервера аудита ввести агент аудита в целевую ВМ из набора гостевых ВМ, причем агент аудита сконфигурирован для выполнения аудита целевой ВМ, при этом включает в себя элемент, выбранный из группы, состоящей из создания списка легитимных компьютерных программ, установленных для исполнения на целевой ВМ, и определения объема аппаратных ресурсов, используемых в данный момент целевой ВМ. Подсистема аудита ВМ дополнительно сконфигурирована так, чтобы в ответ на введение агента аудита побуждать целевую ВМ исполнять агент аудита и, в ответ на исполнение целевой ВМ агента аудита, удалять агент аудита из целевой ВМ.
Краткое описание чертежей
[0011] Вышеуказанные аспекты и преимущества настоящего изобретения более ясны из последующего подробного описания со ссылками на чертежи, где:
[0012] На фиг. 1 показана примерная конфигурация, в которой множество клиентских систем подвергаются аудиту по запросу сервера аудита, в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0013] На фиг. 2-А показана примерная конфигурация аппаратных средств проверяемой клиентской системы в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0014] На фиг. 2-В показана примерная аппаратная конфигурация сервера аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0015] На фиг. 3-А показана примерная виртуальная машина, предоставленная гипервизором, исполняемая на проверяемой клиентской системе, и подсистема аудита ВМ, исполняемая вне проверяемой VM в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0016] На фиг. 3-В показана альтернативная конфигурация, в которой гостевая виртуальная машина проверяется отдельной ВМ аудита, исполняемой на клиентской системе в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0017] На фиг. 4 показана примерная последовательность этапов, выполняемых приложением установщика аудита для проведения аудита клиентской системы в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0018] На фиг. 5 показан примерный обмен данными между проверяемой клиентской системой и сервером аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0019] На фиг. 6 показана примерная последовательность этапов, выполняемых подсистемой аудита ВМ в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0020] На фиг. 7 показаны примерные компоненты агента аудита, исполняемого на различных уровнях процессорных привилегий в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0021] На фиг. 8 показана примерная последовательность этапов, выполняемых подсистемой аудита ВМ для введения агента аудита в проверяемую ВМ в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0022] На фиг. 9 показана примерная последовательность этапов, выполняемых загрузчиком драйвера агента аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения.
[0023] На фиг. 10 показана примерная последовательность этапов, выполняемых драйвером аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения.
Осуществление изобретения
[0024] В последующем описании подразумевается, что все обозначенные соединения между структурами могут быть непосредственными оперативными соединениями или опосредованными оперативными соединениями посредством промежуточных структур. Набор элементов включает один или большее количество элементов. Любое обозначение элемента понимается как ссылка на по меньшей мере один элемент. Множество элементов включает в себя по меньшей мере два элемента. Если не требуется иное, любые описанные этапы способа не обязательно должны быть выполнены в конкретном показанном порядке. Первый элемент (например, данные), полученный из второго элемента заключает в себе первый элемент, равный второму элементу, а также первый элемент, генерируемый путем обработки второго элемента и, возможно, других данных. Принятие определения или решения в соответствии с параметром включает в себя в себе принятие определения или решения в соответствии с параметром и дополнительно в соответствии с другими данными. Если не указано иное, показателем некоторого количества/данных может быть само количество/данные или показатель, отличающийся от непосредственно количества/данных. Компьютерная программа-это последовательность инструкций процессора, выполняющая задание. Компьютерные программы, описанные в некоторых вариантах осуществления настоящего изобретения, могут быть автономными программными объектами или суб-объектами (например, подпрограммами, библиотеками) других компьютерных программ. Если не указано иное, легитимная компьютерная программа это компьютерная программа, установленная или иным образом сконфигурированная для исполнения легитимным пользователем соответствующей компьютерной системы. Напротив, неподлинное вредоносное программное обеспечение (вредоносные программы) и компьютерные программы, установленные неавторизованным злоумышленником в соответствующей компьютерной системе, в данном документе считаются нелигитимными компьютерными программами. Говорят, что компьютерная программа исполняется внутри или в виртуальной машине (или что соответствующая виртуальная машина исполняет соответствующую компьютерную программу), когда соответствующая компьютерная программа исполняется по меньшей мере на одном виртуальном процессоре соответствующей виртуальной машины. Процесс является отдельным случаем компьютерной программы, такой как приложение или часть операционной системы, и характеризуется наличием по меньшей мере исполняемого потока и назначенного ему пространства виртуальной памяти, при этом содержимое соответствующего пространства виртуальной памяти включает в себя исполняемый код. Если не указано иное, страница представляет наименьшую единицу виртуальной памяти, которая может быть индивидуально сопоставлена физической памяти хост-системы. Если не указано иное, регистр представляет собой компонент хранения, интегрированный с или формирующий часть процессора, отличную от оперативной памяти с произвольным доступом (RAM). Туннель является виртуальным соединением «точка-точка» между двумя объектами, соединяемыми с сетью связи. Машиночитаемая среда включает в себя долговременный носитель, такой как магнитный, оптический и полупроводниковый носитель информации (например, жесткие диски, оптические диски, флэш-память, DRAM), а также связные линии, такие как проводные кабели и волоконно-оптические линии. Согласно некоторым вариантам осуществления, настоящее изобретение предусматривает, в частности, компьютерные системы, содержащие аппаратные средства (например, один или большее количество микропроцессоров), запрограммированные для выполнения описанных здесь способов, а также инструкции, закодированные в машиночитаемых носителях, для выполнения описанных в данном документе способов.
[0025] В нижеприведенном описании раскрыты варианты осуществления настоящего изобретения на примере и не обязательно носит ограничительный характер.
[0026] На фиг. 1 показана примерная конфигурация в соответствии с некоторыми вариантами осуществления настоящего изобретение, в которой множество клиентских систем 12a-d проходят аудит дистанционно по запросу сервера 14 аудита. Примеры клиентских систем 12a-d включают в себя системы персональных компьютеров, мобильные вычислительные платформы (ноутбуки, планшеты, мобильные телефоны), развлекательные устройства (телевизоры, игровые приставки), носимые устройства (смарт-часы, фитнесс-браслеты), бытовые приборы, и любое другое электронное устройство, содержащее процессор и память и выполненное с возможностью выполнения роли платформы аппаратной виртуализации. Клиентские системы 12a-d взаимосвязаны посредством коммуникационной сети 10, такой как корпоративная сеть или Интернет. Части сети 10 могут включать в себя локальную сеть (LAN).
[0027] Сервер 14 аудита соединен с возможностью коммуникации с клиентскими системами 12a-d и взаимодействует с каждой клиентской системой 12a-d для проведения аудита соответствующей клиентской системы. Примеры аудиторских операций включают в себя, в частности, идентификацию имеющегося программного обеспечения и проверку соответствующих программных средств в отношении лицензий, использования и прав. Степень детализации такого аудита может варьироваться от относительно высокого уровня (например, определения того, какие приложения/версии установлены в клиентской системе) до углубленного аудита, включающего в себя, например, определение того, используют ли программы, исполняемой в клиентской системе, определенную версию критического компонента (например, драйвера, патча, модуля защиты от вредоносных программ), когда каждый компонент был установлен или запущен, как много аппаратных ресурсов использует отдельное приложение и так далее. Другие примерные аудиторские операции включают в себя, в частности, определение того, какие компоненты программного обеспечения (приложения, процессы, драйверы и так далее) непосредственно исполняются на момент проверки, определение текущего состояния процессора соответствующей клиентской системы, определение текущего уровня использования ресурсов (например, центрального процессора, памяти, диска, сети и так далее), и определение набора значений параметров конфигурации и настроек операционной системы, различных приложений, пользовательских настроек и так далее, соответствующей клиентской системы.
[0028] Сервер 14 в общем представляет собой набор взаимосвязанных вычислительных систем, которые могут быть, а могут и не быть близко расположенными друг к другу. В некоторых вариантах осуществления сервер 14 аудита настроен для доступа к клиентской базе данных 15. В примере клиентской базы данных 15 каждая запись связана с проверяемой клиентской системой 12a-d и может включать в себя содержимое набора отчетов аудита (см. ниже), полученных от соответствующей клиентской системы. Каждая запись может дополнительно сопровождаться отметкой времени с указанием времени получения каждого отчета аудита, полученного от соответствующей клиентской системы. Каждая запись базы данных 15 может содержать данные аудита, определенные для соответствующей клиентской системы, включающие в себя, например, индикаторы аппаратной конфигурации соответствующей клиентской системы, индикатор типа и версии операционной системы (ОС), индикатор набора легитимных легитимно установленных приложений или других программных компонентов (например, драйверов, патчей), индикатор набора программных компонентов (приложений, процессов, драйверов и так далее), загруженных в данный момент и/или исполняемых на момент проведения аудита, набор параметров с указанием различных ОС, приложения и/или пользовательских настроек для соответствующей клиентской системы, а также набор индикаторов использования ресурсов (например, центрального процессора, памяти, диска и так далее) на момент проведения аудита. Данные аудита могут также включать в себя временные индикаторы с указанием того, когда был установлен каждый из перечисленных программных компонентов и/или последний момент доступа к перечисленному компоненту или его изменения.
[0029] На фиг. 2-А показана примерная аппаратная конфигурация клиентской системы 12, такой как системы 12a-d на фиг. 1. Для простоты показанная клиентская система является компьютерной системой; аппаратная конфигурация других клиентских систем, таких как мобильные телефоны, часы и так далее, может несколько отличаться от показанной конфигурации. Клиентская система 12 содержит набор физических устройств, в том числе аппаратный процессор 16 и блок 18 памяти. Процессор 16 содержит физическое устройство (например, микропроцессор, многоядерную интегральную схему, сформированную на полупроводниковой подложке, и так далее), сконфигурированное для выполнения вычислительных и/или логических операций с набором сигналов и/или данных. В некоторых вариантах осуществления такие операции передаются процессору 16 в виде последовательности процессорных инструкций (например, машинного кода или другого типа кодировки). Блок 18 памяти может содержать энергозависимые машиночитаемые носители (например, DRAM (динамическая память с произвольным доступом), SRAM (статическая память с произвольным доступом), хранящие инструкции и/или данные, получаемые или генерируемые процессором 16.
[0030] Устройства ввода 20 могут включать в себя, среди прочего, компьютерные клавиатуры, мыши и микрофоны, включая соответствующие аппаратные интерфейсы и/или адаптеры, позволяющие пользователю вводить данные и/или инструкции в клиентскую систему 12. Устройства 22 вывода могут включать в себя устройства отображения, такие как, среди прочего, мониторы и динамики, а также аппаратные интерфейсы/адаптеры, такие как графические карты, позволяющие клиентской системе 12 передавать данные пользователю. В некоторых вариантах осуществления, устройства 20 ввода и устройства 22 вывода могут иметь общую аппаратную часть, как в случае устройств с сенсорным экраном. Запоминающие устройства 24 включают в себя машиночитаемые средства, обеспечивающие возможность энергонезависимого хранения, чтения и записи инструкций программного обеспечения и/или данных. Примерные запоминающие устройства 24 включают в себя магнитные и оптические диски и устройства флэш-памяти, а также съемные носители, такие как CD и/или DVD диски и приводы. Набор 26 сетевых адаптеров дает возможность клиентской системе 12 подключаться к компьютерной сети и/или другим устройствам/компьютерным системам. Управляющий концентратор 28 представляет собой множество системных, периферийных шин и/или шин набора микросхем и/или всех других схем, обеспечивающих связь между процессором 16 и устройствами 18, 20, 22, 24 и 26. Например, управляющий концентратор 28 может включать в себя, среди прочего, контроллер памяти, контроллер ввода/вывода, и контроллер прерываний. В другом примере управляющий концентратор 28 может содержать северный мост, соединяющий процессор 16 с памятью 18 и/или южный мост, соединяющий процессор 16 с устройствами 20, 22, 24, и 26.
[0031] На фиг. 2-В показана примерная аппаратная конфигурация сервера 14 аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения. Сервер 14 содержит по меньшей мере один аппаратный процессор 116 (например, микропроцессор, многоядерную интегральную схему), физическую память 118, и набор серверных сетевых адаптеров 126. Адаптеры 126 могут включать в себя сетевые карты и другие коммуникационные интерфейсы, позволяющие серверу 14 аудита подключаться к коммуникационной сети 10. В некоторых вариантах осуществления сервер 14 дополнительно содержит устройства ввода, вывода и хранения, которые могут быть функционально аналогичны устройствам 20, 22, и 24 ввода, вывода и хранения, соответственно.
[0032] В некоторых вариантах осуществления клиентская система 12 сконфигурирована для предоставления набора виртуальных машин, например, как показано на фиг. 3-А-В. Виртуальная машина (ВМ) эмулирует реальную физическую машину/компьютерную систему, используя любой из множества методов, известных в области аппаратной виртуализации. В некоторых вариантах осуществления на клиентской системе 12 исполняется гипервизор 30, также известный в данной области техники как монитор виртуальной машины (ВММ), сконфигурированный для создания или обеспечения множества виртуализированных устройств, таких как виртуальный процессор и блок управления виртуальной памятью, и предоставления программному обеспечению доступа к таким виртуализированным устройствам вместо реальных физических устройств клиентской системы 12. Такие операции в данной области техники обычно известны как предоставление виртуальной машины. Гипервизор 30 может дополнительно обеспечивать возможность для нескольких виртуальных машин совместного использования аппаратных ресурсов хост-системы 12, так чтобы каждая виртуальная машина работала независимо и не получала информации о других виртуальных машинах, одновременно исполняемых на клиентской системе 12. Примеры популярных гипервизоров включают в себя, среди прочих, BMware vSphereTM от компании BMware Inc. и Xen hypervisor с открытым исходным кодом.
[0033] В примерных конфигурациях, показанных на фиг. 3-А-В, гостевая виртуальная машина 32 исполняет гостевую операционную систему (ОС) 34, а также набор приложений 36а-b. Гостевая ОС 34 может содержать любую широкодоступную операционную систему, такую как, среди прочих, Microsoft Windows, MacOS, Linux, iOS или AndroidTM, обеспечивающую согласование между приложениями, исполняемыми в ВМ 32 и виртуализированными аппаратными устройствами виртуальной машины 32. Приложения 36а-b обычно представляют любое пользовательское приложение, как, например, текстовые процессоры, электронные таблицы, графические приложения, браузеры, социальные сети и приложения электронной связи.
[0034] В варианте осуществления, показанном на фиг. 3-А, подсистема 40а аудита ВМ исполняется вне гостевой ВМ 32, на привилегированном уровне процессора гипервизора 30 (например, корневой уровень или кольцо-1). Подсистема 40а аудита ВМ сконфигурирована для выполнения аудита гостевой виртуальной машины 32. В некоторых вариантах осуществления такой включает в себя введение агента 42 аудита в проверяемую виртуальную машину, как подробно описано ниже, и удаление агента 42 из проверяемой ВМ после завершения аудита.
[0035] В альтернативном варианте осуществления, проиллюстрированном на фиг. 3-В, гипервизор 30 сконфигурирован так, чтобы подвергнуть аудиту ВМ 33 отдельно от всех проверяемых гостевых виртуальных машин, причем аудит ВМ 33 может выполняться одновременно с гостевыми виртуальными машинами 32. Некоторые варианты осуществления аудита ВМ 33 содержат облегченную минимальную операционную систему (например, настроенная для пользователя версия ОС Linux), и сконфигурированы на исполнение подсистемы 40b аудита ВМ, сконфигурированного для выполнения аудита гостевой виртуальной машины 32. Виртуальное окружение гостевой виртуальной машины 32 и аудит виртуальной машины 33 могут быть изолированы друг от друга с использованием любого известного в области виртуализации способа, чтобы гарантировать, что исполнение вредоносного программного обеспечения внутри гостевой ВМ 32 не может заразить или иным образом вмешаться в программы, исполняемые при аудите ВМ 33. В варианте осуществления с фиг. 3-В, подсистема 44 самодиагностики исполняется вне гостевой ВМ 32 и аудита ВМ 33, на привилегированном процессорном уровне гипервизора 30. В примерном варианте осуществления из фиг. 3-А, некоторая часть работы подсистемы 44 самодиагностики может быть выполнена по меньшей мере частично, подсистемой 40а аудита ВМ.
[0036] Хотя на фиг. 3-А-В представлена только одна гостевая ВМ 32, исполняемая на клиентской системе 12, некоторые варианты осуществления могут быть настроены для выполнения аудитов в клиентской системе, где работают несколько виртуальных машин. Типичными применениями таких платформ виртуализации являются серверные фермы, где единая компьютерная система может содержать сотни отдельных виртуальных машин веб-сервера, работающих одновременно. Другое типичное приложение относится к категории инфраструктуры виртуальных рабочих столов (ИВРС), где пользовательские приложения исполняются на первой компьютерной системе, пока пользователь взаимодействует с соответствующими приложениями через вторую компьютерную систему (терминал). В типичных конфигурациях ИВРС виртуальная машина, на которой исполняется запрошенное приложение, создается по требованию на первой компьютерной системе, которая может в конечном итоге исполнять сотни таких виртуальных машин для нескольких удаленных пользователей. В таких вариантах осуществления отдельная подсистема 40а-b аудита ВМ может выполнять аудиты нескольких ВМ или всех ВМ, исполняемых в соответствующей клиентской системе. Например, подсистема 40а-b аудита может поместить агент аудита внутрь каждой из соответствующих гостевых ВМ. В одном таком примере, механизм 40а-b аудита ВМ может выбрать тип агента аудита и настроить процедуру введения агента в соответствии с аппаратными и/или программными характеристиками каждой ВМ, например, в соответствии с типом ОС, исполняемой в соответствующей ВМ. В некоторых вариантах осуществления подсистема 40а-b аудита ВМ может получить инструкции от сервера 14 для выборочного выполнения аудита определенной целевой ВМ или выбранного подмножества виртуальных машин, исполняемых в соответствующей клиентской системе.
[0037] В некоторых вариантах осуществления подсистема 44 самодиагностики (фиг. 3-Б) сконфигурирована для обнаружения различных событий, происходящих во время исполнения программного обеспечения в проверяемой гостевой ВМ, и обмен такой информацией с другими проверяющими программами (например, агентом 42 и/или подсистемой 40а-b). Примерные события, обнаруживаемые подсистемой 44 самодиагностики, включают в себя, например, исключение процессора и/или прерывание, попытка выполнения определенной функции гостевой ОС 34, смена привилегии процессора (например, системный вызов), попытка доступа (чтение, запись и/или исполнение из) к определенному месту в памяти и так далее. Подсистема 44 самодиагностики может быть дополнительно сконфигурирована для определения адресов различных программных компонентов в памяти, исполняемых в гостевой ВМ 32, как описано ниже.
[0038] Известно несколько способов обнаружения таких событий. В одном из таких примеров, подсистема 44 самодиагностики может взаимодействовать с гипервизором 30, чтобы установить разрешения на доступ к памяти с использованием механизма преобразования адресов второго уровня (например, расширенные таблицы страниц - ЕРТ на Intel платформах, быстрое индексирование виртуализации - RVI на платформах AMD). При попытке доступа к определенной странице памяти нарушается набор прав доступа для соответствующей страницы памяти, соответствующая попытка может вызвать такое событие процессора, как исключение или событие выхода из виртуальной машины (BMExit на платформах Intel). В результате события процессора, процессор 16 может переключиться на исполнение подпрограммы обработчика событий в подсистеме 44 самодиагностики, который позволяет подсистеме 44 обнаружить наличие соответствующего события. Такие механизмы могут обнаруживать, например, вызов определенной функции, путем маркировки страницы памяти, содержащей часть соответствующей функции, как неисполняемую.
[0039] Для простоты и без потери общности, последующее описание сфокусировано на примерном варианте осуществления, сконфигурированном как показано на фиг. 3-А. Опытный специалист поймет, что описанные системы и способы могут быть адаптированы к другим конфигурациям, и, в частности, к примеру конфигурации с фиг. 3-В. В последующем описании подсистема (подсистемы) аудита ВМ обозначена в целом позицией 40 и при этом представляет собой либо подсистему 40а аудита, либо подсистему аудита 40b, в зависимости от выбранной конфигурации.
[0040] На фиг. 4 показан пример последовательности этапов, выполняемых для проведения аудита клиентской системы в соответствии с некоторыми вариантами осуществления настоящего изобретения. В типичном сценарии аудита корпоративной сети, сетевой администратор может установить приложение аудита на каждой клиентской системе 12a-d. Приложение аудита может содержать различные компоненты, такие как подсистема 40 аудита ВМ, подсистема 44 самодиагностики и так далее. Показанная последовательность этапов может быть выполнена, например, с помощью утилиты установки соответствующего приложения аудита. При установке на клиентскую систему, не работающую в данный момент в конфигурации аппаратной виртуализации, программное обеспечение аудита может сначала обработать процессор 16 на самом привилегированном уровне (например, BMXRoot на платформах Intel, поддерживающих режим виртуализации, или же широко известном корневом или кольца-1 режиме), и установить гипервизор 30. Гипервизор 30 может затем предоставить гостевую ВМ 32 и переместить все программное обеспечение, ранее исполнявшееся на соответствующей клиентской системе, для исполнения на гостевой ВМ 32. Гипервизор 30 может далее установить подсистему 40 аудита ВМ и/или подсистему 44 самодиагностики. При установке на платформу аппаратной виртуализации, где уже исполняются несколько виртуальных машин, этапы 200-202 могут быть опущены.
[0041] В некоторых вариантах осуществления этап 206 может установить удаленный доступ с сервера 14 аудита к подсистеме 40 аудита. Такой доступ может позволить серверу аудита отправлять инструкции непосредственно проверяемой клиентской системе 12, автоматически или с помощью оператора. Такие инструкции могут, например, дать указание подсистеме 40 аудита ВМ на выполнение определенного вида аудита, чтобы проверить наличие гостевой ВМ, и/или характеристики определенного компонента программного обеспечения, на определение текущего состояния процессора 16 (например, содержимое набора регистров процессора), на чтение набора параметров настройки для гостевой ОС 34 или другого программного обеспечения и так далее. В одном примере варианта осуществления, на этапе 206 может быть настроен туннель (т.е. линия связи точка-точка) между сервером 14 и гипервизором 30 и/или между сервером 14 и ВМ 33 аудита. Могут быть созданы примерные туннели в соответствии с протоколами и способами установления виртуальной частной сети (VPN) и/или безопасной оболочки (SSH). Как только такой туннель создан, он может использоваться сервером 14 для передачи запросов аудита и/или других инструкций для подсистемы 40 аудита ВМ.
[0042] На следующем этапе 208 установщик аудита может настроить самодиагностику и/или перехват события с уровня гипервизора 30. Этап 208 может включать в себя, например, установку разрешений доступа к некоторым страницам памяти, используемым проверяемой гостевой ВМ, чтобы попытка получить доступ к соответствующей странице вызвала событие процессора (например, событие выхода из ВМ), позволяя подсистеме 40 аудита ВМ или подсистеме 44 самодиагностики обнаружить наступление события (например, системного вызова) внутри проверяемой гостевой ВМ 32. В некоторых вариантах осуществления этап 208 может дополнительно установить сигнальный и/или коммуникационный механизм связи между компонентами, исполняемыми в проверяемых виртуальных машинах (например, агентами 42 аудита) и компонентами, исполняемыми вне соответствующей ВМ (например, подсистемой 40, аудита, подсистемой 44 самодиагностики). Такая связь или сигнализация может использовать любой способ, известный в области аппаратной виртуализации. В одном примере два программных компонента могут передавать данные между собой через раздел физической памяти, совместно используемый двумя программными компонентами. Для передачи данных из первого компонента, исполняемого внутри ВМ, второму компоненту за пределами соответствующей ВМ первый программный компонент может записать данные в общий раздел памяти и затем выдать привилегированную процессорную инструкцию (например, BMCALL на Intel платформах), вызывая, таким образом, событие выхода ВМ. События выхода ВМ, такие как BMExit на Intel платформах, переключают процессор 16 с исполнения первого программного компонента на исполнение подпрограммы обработчика, которая может быть частью второго программного компонента. Таким образом можно уведомить второй компонент, исполняемый вне соответствующей ВМ, что первый компонент пытается передать данные. И наоборот, чтобы отправить данные из второго компонента в первый компонент, второй компонент может записать данные в общий раздел памяти, а затем ввести прерывание в соответствующую ВМ. Прерывание будет обработано обработчиком прерываний, исполняемым в соответствующей ВМ (например, первым программным компонентом). Таким образом, первый компонент может обнаружить, что второй компонент пытается передать данные. В некоторых вариантах осуществления, этап 208 включает в себя регистрацию подходящих программных компонентов в качестве обработчиков различных события процессора, чтобы включить механизм связи, описанный выше.
[0043] На фиг. 5 показан пример обмена данными между сервером аудита 14 и проверяемой клиентской системой в соответствии с некоторыми вариантами осуществления настоящего изобретения. Сервер 14 может отправить запрос 50 на проведение аудита клиентской системе 12, при этом запрос 50 дает инструкции подсистеме 40 аудита ВМ для выполнения аудита клиентской системы 12. В некоторых вариантах осуществления запрос 50 на проведение аудита включает в себя индикатор типа аудита, например, типа операции аудита, которая должна быть выполнена в клиентской системе 12: перечислить все легитимные приложения, определить текущие настройки операционной системы и так далее. Другой пример запроса 50 на проведение аудита включает в себя индикатор целевой виртуальной машины, исполняемой в данный момент в клиентской системе 12; такой запрос аудита может предписать подсистеме 40 аудита выборочно выполнять аудит целевой ВМ. Еще один пример запроса 50 аудита может включать в себя индикатор конкретного компонента программного обеспечения (например, Microsoft Word, особого драйвера и так далее). Такой запрос может дать указание подсистеме 40 определить, среди прочего, является ли соответствующий программный компонент легитимно установленным в соответствующей клиентской системе, какая версия соответствующего программного компонента установлена, является ли соответствующий программный компонент в данный момент загруженным в память/исполняемым, когда соответствующий компонент программного обеспечения использовался в последний раз, и так далее. Другой пример запроса 50 аудита может дать указание подсистеме 40 определить текущий уровень/количество/процент аппаратных ресурсов (например, процессора, хранилища, памяти), используемых целевой ВМ или определенным компонентом программного обеспечения, исполняемым в целевой ВМ.
[0044] Запрос 50 аудита может включать в себя идентификатор целевой гостевой ВМ, исполняемой на проверяемой клиентской системе. Такой запрос может дать указание подсистеме 40 аудита провести выборочный аудит соответствующей гостевой ВМ. Другие запросы 50 могут дать указание подсистеме 40 аудита выполнить аудит всех гостевых ВМ, исполняемых в данный момент в проверяемой клиентской системе.
[0045] Запросы 50 аудита могут быть отправлены в соответствии с перечнем или в ответ на действие сетевого администратора. Запросы 50 аудита могут быть разосланы единообразно во все клиентские системы 12a-d, или могут быть специально адаптированы к каждой проверяемой клиентской системе. В некоторых вариантах осуществления, запрос аудита может быть инициирован событием, происходящим в соответствующей клиентской системе, или в ответ на событие, происходящее в другом месте коммуникационной сети 10. В ответ на проведение запрошенного аудита, подсистема (подсистемы) 40а-b аудита ВМ может отправить отчет 52 об аудите серверу 14. Отчет 52 содержит результат соответствующего проведения аудита, например, список установленных компонентов программного обеспечения, набор текущих параметров конфигурации соответствующей клиентской системы и так далее.
[0046] На фиг. 6 показан пример последовательности этапов, выполняемых подсистемой 40 аудита ВМ в соответствии с некоторыми вариантами осуществления настоящего изобретения. Подсистема 40 может отслеживать запросы 50 аудита от сервера 14. При получении запроса 50 подсистема 40 может выбрать целевую ВМ для проведения аудита в соответствии с запросом 50 аудита и поместить агент аудита в целевую гостевую ВМ (например, гостевую ВМ 32 на фигурах 3-А-В).
[0047] Агент может быть создан в соответствии с типом проверяемой гостевой ВМ, например, в соответствии с типом гостевой ОС 34, исполняемой в данный момент в проверяемой ВМ. Тип ОС может содержать именной индикатор, такой как Windows, и индикатор версии, такой как, среди прочих, 7, Домашняя или Профессиональная. В некоторых вариантах осуществления подсистема 40 аудита определяет тип ОС в соответствии с содержимым специфичного для модели регистра (MSR) соответствующей гостевой ВМ или содержимым раздела памяти, указанного в соответствующем MSR. В некоторых вариантах осуществления подсистема 40 может определить имя ОС в соответствии с данными, записываемыми в такие MSR программным обеспечением проверяемой ВМ. Например, подсистема 40 может перехватывать инструкции, записываемые в MSR SYSENTER или SYSCALL и определять тип ОС, исполняемой или инициализируемой в данный момент, по параметру такой записи инструкции. Другие примеры регистров, которые могут предоставить информацию об имени ОС, включают в себя, среди других, регистры управления, таблицу дескрипторов прерываний (IDT), и глобальную таблицу дескрипторов (GDT),. Для определения типа ОС в соответствии с записями в MSR подсистема 40 самодиагностики может дополнительно использовать сопоставление содержания с заранее определенной библиотекой обработчиков быстрых системных вызовов, специфичных для каждой ОС (например, системные вызовы, обрабатываемые в соответствии с содержимым MSR SYSCALL или SYSENTER). Такие библиотеки быстрых системных вызовов могут быть предусмотрены подсистемой 40 аудит и/или подсистемой 44 самодиагностики, и могут поддерживаться актуальными путем обновления программного обеспечения, периодического или по требованию.
[0048] В некоторых вариантах осуществления индикатор версии (такой как имя выпуска, номер сборки и так далее) может быть получен путем анализа определенных структур данных ядра, специфичных для соответствующего типа ОС. Примерами структур данных, позволяющими идентифицировать версию ОС, являются некоторые выводимые символы ядра Linux или ядра Windows, такие как, среди прочих, NtBuildNumber.
[0049] После введения агента 42 аудита в целевую гостевую ВМ последовательность этапов 228-230-232 может циклически повторяться до завершения аудита. Во время продолжения аудита, подсистема 40 аудита ВМ может обмениваться данными (например, адресами памяти различных программных компонентов, различными результатами аудита) с агентом 42 аудита. Такой обмен сообщениями между компонентами, исполняемыми внутри и вне виртуальной машины может выполняться с помощью любого способа, известного в области виртуализации (например, через раздел памяти, общий для подсистемы 40 аудита и агента 42 аудита, как описано выше). По завершении аудита на этапе 234 агент аудита удаляется из проверяемой ВМ, например, путем очистки раздела памяти, содержащего загрузчик драйвера (подробнее ниже). На следующем этапе 236 подсистема 40 аудита формирует и отправляет аудиторский отчет 52 для сервера 14 аудита.
[0050] На фиг. 7 показаны примеры компонентов агента 42 аудита с точки зрения уровней привилегий процессора (например, кольца привилегий). В некоторых вариантах осуществления агент 42 аудита содержит загрузчик 46 драйвера и драйвер 48 аудита. Загрузчик 46 драйвера может быть введен подсистемой 40 аудита ВМ в исполняемое приложение 36, такое как приложения 36а-b на фиг. 3-А-В. Загрузчик 46 может, следовательно, исполняться на уровне привилегий приложения 36, обычно в кольце 3 (пользовательский режим или пользовательский уровень из привилегий процессора). В некоторых вариантах осуществления загрузчик 46 драйвера загружает и запускает драйвер 48 аудита на гостевой ВМ 32, при этом драйвер 48 обычно исполняется на уровне привилегий процессора гостевой ОС 34 (например, кольца 0, режима ядра или уровня ядра). Затем драйвер аудита 48 может провести операции аудита в гостевой ВМ 32. По завершении аудита загрузчик 46 или подсистема 40 аудита ВМ может удалить драйвер 48 из гостевой ВМ 32, например, путем очистки раздела памяти, содержащего драйвер 48. Альтернативный вариант осуществления не использует загрузчик 46 драйвера, а вместо этого вводит код (например, агента 42 аудита) непосредственно в ядро гостевой ОС 34. В таких вариантах осуществления агент 42 может исполняться полностью в кольце 0 (режим ядра).
[0051] Введение программного компонента в виртуальную машину может быть обеспечено различными способами, известными в данной области. На фиг. 8 показан пример последовательности этапов, выполняемых подсистемой 40 аудита ВМ для введения агент 42 внутрь гостевой ВМ 32 (этап 226 на фиг. 6) в соответствии с предпочтительным вариантом осуществления настоящего изобретения. На этапе 250, подсистема 40 аудита ВМ определяет раздел памяти, подходящий для введения загрузчика 46 драйвера. В некоторых вариантах осуществления загрузчик 46 драйвера создают как можно меньшего размера, например, намного меньше, чем страница памяти, так что он может быть безопасно скрыт среди существующих структур данных без необходимости использования средств распределения памяти ОС (их использование может сделать загрузчик 46 и/или драйвер 48 поддающимся обнаружению другими программными средствами, включая вредоносные программы, исполняемые в гостевой ВМ 32).
[0052] В одном примере подсистема 40 аудита ВМ может искать раздел памяти, подходящий для получения загрузчика 46 драйвера в пространстве загрузки, обычно резервируемом гостевой ОС 34 между разделами драйверов. Такое пространство загрузки существует, поскольку некоторые операционные системы, такие как Windows распределяют память таким образом, чтобы каждый отдельный раздел объекта был выровнен по границе страницы. Если раздел не занимает всю страницу памяти, оставшееся пространство памяти в пределах соответствующей страницы дополняется фиктивными данными (например, нулями). В таких вариантах осуществления, поиск подходящего пространства памяти для размещения загрузчика 46 драйверов может содержать просмотр страницы памяти, выделяемой драйверу гостевой ОС 34 для нахождения таких фиктивных данных.
[0053] В другом примере подсистема 40 может перехватить попытку ОС выделить память для небольшого объекта (например, драйвера), где соответствующий объект меньше страницы памяти. Вместо выделения требуемого объема памяти подсистема 40 может побуждать гостевую ОС 34 выделить полную страницу памяти (например, 4кБ) соответствующему объекту и использовать оставшееся пространство в пределах соответствующей страницы памяти для размещения загрузчика 46 драйвера. Чтобы перехватить такую попытку выделения памяти, некоторые варианты осуществления подсистемы 40 аудита и/или подсистемы 44 самодиагностики могут обнаружить попытку исполнения функции управления памятью родной ОС, такой как KeAllocatePoolWithTag в Windows. Чтобы определить адреса памяти, где такие функции хранятся в памяти соответствующей гостевой виртуальной машины 32, подсистема 40 аудита может обращаться к определенным структурам данных, таким как экспортированные таблицы функций двоичных образов ядра (например, Portable Executable в Windows, Executable and Linkable в Linux). Тип объекта, выделяемого в данный момент, может быть определен по тегу выделения в перехваченном вызове. Например, в Windows тег 'Driv' указывает на объект драйвера.
[0054] В следующем другом примере этап 250 включает в себя отображение неиспользуемой страницы памяти на пространство памяти исполняемого процесса, например, приложения 36 на фиг. 7. После определения подходящего раздела памяти для размещения загрузчика 46 драйвера подсистема 40 аудита ВМ на этапе 252 может ввести загрузчик 46 в соответствующий раздел памяти.
[0055] Кроме того, некоторые варианты осуществления подсистемы 40 аудита могут ожидать, пока текущий исполняемый процесс (такой как приложение 36) попытается изменить привилегии процессора, например путем системного вызова, например, SYSCALL на платформах AMD или SYSENTER на платформах Intel. Перехват системного вызова извне соответствующей ВМ может быть достигнут несколькими путями. В одном примере подсистема 40 может восстановить значение процессорного регистра виртуального процессора, исполняемого в данный момент поток, делающий попытку системного вызова. Примеры таких процессорных регистров включают в себя регистры IA32_LSTAR и IA32_SYSENTER_EIP на платформах Intel. Подобная манипуляция регистром впоследствии вызовет ошибку при попытке системного вызова; соответствующая ошибка может быть обнаружена подсистемой 40 аудита ВМ или подсистемой 44 самодиагностики. В другом примере подсистема 40 может поместить перенаправляющий обработчик прерываний на кодовую страницу, содержащую обработчик системного вызова гостевой ОС 34.
[0056] В некоторых вариантах осуществления, когда перехватывают системный вызов, этап 256 выполняет набор проверок правомочности, чтобы определить, позволяет ли контекст соответствующего системного вызова безопасный ввод загрузчика 46 драйвера. В одном примере, где перехват системных вызовов достигается через подключение обработчика системных вызовов, проверки правомочности могут содержать определение того, является текущий стек пользовательским стеком или нет. Попытка ввести код, когда стек является пользовательским стеком, может подвергнуть риску систему, потому что все, что относится к пользовательскому режиму, для ядра является ненадежным. Кроме того, другие потоки могут перехватывать данные из пользовательского стека и даже могут атаковать загрузчик 46 драйвера. В некоторых вариантах осуществления определение того, является ли стек пользовательским стеком, включает в себя определение уровня привилегий дескриптора сегмента стека. Другая проверка правомочности может определять, разрешены ли в данный момент прерывания. Загрузчику 46 драйвера, возможно, необходимо исполнить некоторые инструкции процессора, которые требуют, чтобы прерывания были разрешены. Еще одна проверка правомочности может определить текущий уровень запроса прерываний (IRQL). Некоторые варианты осуществления могут потребовать, например, чтобы текущий IRQL был равен 0, чтобы иметь возможность выполнять операции загрузчика 46 драйвера.
[0057] Если системный вызов соответствует требованиям правомочности, на шаге 260, подсистема 40 аудита может приостановить исполнение потока, выдавшего соответствующий системный вызов, и переключить процессор 16 на исполнение загрузчика 46 драйвера. Когда закончится исполнение загрузчика 46, подсистема 40 аудита может переключить процессор 16 назад на исполнения исходного потока (например, приложения 36).
[0058] На фиг. 9 показана примерная последовательность этапов, выполняемых загрузчиком 46 драйвера в соответствии с некоторые вариантами осуществления настоящего изобретения. Для выделения памяти для драйвера 48 аудита и/или создания потока для драйвера 48 некоторые варианты осуществления могут вызывать специальные функции гостевой ОС 34, например ExAllocatePoolWithTag и PsCreateSystemThread в Windows (подобные функции существуют в других ОС, например, Linux). В варианте осуществления, где от загрузчика 46 драйвера требуется занимать небольшой объем памяти, адреса таких функций ОС могут быть предоставлены загрузчику 46 подсистемой 40 аудита ВМ, например, через механизм обмена сообщениями, как описано выше. В таких вариантах осуществления, загрузчик 46 фактически не может записать драйвер 48 в выделенную память. Вместо этого загрузчик 46 может передать подсистеме 40 аудита ВМ адрес выделенного раздела памяти, в то время как фактическая запись выполняется подсистемой 40 аудита.
[0059] После запуска драйвера 48 аудита (этап 274) загрузчик 46 может закончить выполнять свои функции. В некоторых вариантах осуществления загрузчик 46 драйвера может удалить драйвер 48 аудита из гостевой ВМ 32, когда драйвер 48 аудита завершает исполнение, например, по завершении текущей операции аудита. В альтернативном варианте осуществления подсистема 40 аудита ВМ может выполнить очистку (например, удалить драйвер 48 из памяти.
[0060] На фиг. 10 показан пример этапов, выполняемых драйвером 48 аудита в соответствии с некоторыми вариантами осуществления настоящего изобретения. Поскольку драйвер 48 исполняется в гостевой ВМ 32, имеющей собственное пространство памяти и поток исполнения, драйвер 48 может использовать все ресурсы, доступные в гостевой ОС 34 для выполнения аудита гостевой ВМ 32, например, для составления перечня установленных приложений, определения различных значений параметров ОС, определения меток времени, связанных с различными компонентами программного обеспечения, определения использования ресурсов и так далее. Такие задачи могут выполняться с использованием различных способов, известных в данной области. Например, драйвер 48 аудита может перечислить определенные ключи реестра гостевой ОС 34, при этом соответствующие ключи вскрывают подлинность установленных приложений/комплекта программ и так далее. Другой способ аудита вызывает интерфейс программирования приложений (API), предоставляемый гостевой ОС 34 (такой как Инструментарий Управления Windows - WMI в Windows), для получения различных данных об установленных программах. В следующем другом примере, драйвер 48 может искать определенные файлы и папки (например, Program Files в Windows) для получения списка установленных программ и обновлений. Такие примерные способы могут быть использованы независимо или совместно. Данные, собранные в ходе аудита, могут быть переданы подсистеме 40 аудита ВМ, например, путем записи таких данных в заранее определенный раздел памяти, общий для драйвера 48 и подсистемы 40 аудита ВМ.
[0061] В некоторых вариантах осуществления, в ответ на проведение аудита и до выхода из него, драйвер 48 аудита может загрузить и/или запустить модуль безопасности, такой как драйвер защиты от вредоносных программ. Модуль безопасности может определить, например, включает в себя ли проверяемая гостевая ВМ вредоносные программы и/или может удалить или иным образом вывести из строя существующие вредоносные программы. Из-за скрытности и динамичного развертывания такого модуля безопасности, для вредоносных программ, исполняемых в соответствующей гостевой ВМ относительно трудно обнаружить его наличие и работу и ему помешать.
[0062] Описанные в данном документе примерные системы и способы позволяют проводить аудит программного обеспечения удаленно, на относительно большом количестве клиентских систем (например, корпоративной сети). Проверка программного обеспечения в данном документе относится к оценке легитимного программного обеспечения, т.е. программного обеспечения, установленного и/или настроенного для исполнения на соответствующей клиентской системе легитимным пользователем (например, системным администратором) соответствующей клиентской системы. Примерный аудит может определить, например, какие приложения программного обеспечения установлены в данный момент на компьютерах компании. Такая информация может быть использована, например, чтобы упростить лицензирование программного обеспечения, развертывать обновления и не допускать установку сотрудниками или использования ими определенного программного обеспечения на работе (например, приложений для обмена сообщениями, игр), разрешать сотрудникам использовать конкретный бренд или тип программного обеспечения (например, Google Chrome) и так далее.
[0063] Результаты аудита могут быть удобно сосредоточены на компьютере сервера, соединенного с проверяемыми клиентскими системами. Аудиты могут проводиться автоматически, в соответствии с расписанием и/или по требованию, по запросу администратора. В некоторых вариантах осуществления настоящего изобретения, аудиты могут быть дополнительно связаны с деятельностью по компьютерной безопасности, такой как целевое антивирусное сканирование/очистка выбранных клиентских систем.
[0064] Некоторые варианты осуществления используют технологию аппаратной виртуализации для увеличения безопасности и надежности программного аудита. Чтобы не подвергать программное обеспечение аудита вредоносному вмешательству человека и/или заражению проверяемого клиента вредоносными программами, некоторые варианты осуществления перемещают клиентское программное обеспечение, включая операционную систему, в виртуальную машину (ВМ), и выполняют части аудита вне оберегаемой виртуальной машины. Части программного обеспечения аудита могут, таким образом, исполняться на уровне гипервизора или в отдельной выделенной ВМ аудита, исполняемой на соответствующем клиенте.
[0065] Некоторые варианты осуществления настоящего изобретения, использующие все преимущества виртуализации, также хорошо подходят для аудита клиентских систем, где исполняются несколько ВМ параллельно, таких как фермы серверов и системы инфраструктуры виртуальных рабочих столов (ИВРС). Одна подсистема аудита, сконфигурированная в соответствии с некоторыми вариантами осуществления, может проводить аудит множества виртуальных машин или всех ВМ, исполняемых на соответствующем клиенте. Некоторые обычные системы, сконфигурированные для выполнения операций аудита в виртуализированных средах, выполняют аудит путем анализа снимков памяти проверяемой ВМ. Такие обычные системы могут потребовать, чтобы проверяемая ВМ была остановлена для того, чтобы сделать соответствующий снимок памяти. Напротив, в некоторых вариантах осуществления настоящего изобретения не требуется останавливать проверяемую ВМ, так как агент аудита может быть введен в исполняемую в текущий момент ВМ. Некоторые варианты осуществления, не ограничиваясь информацией, которая может быть извлечена из снимка памяти, могут иметь доступ к значительно более обширным аудиторским данным из исполняемой ВМ.
[0066] Наличие постоянно установленного в проверяемом клиенте программного обеспечения аудита, может подвергнуть такое программное обеспечение воздействию вредоносных программ, которые могут остановить его выполнение или иным образом вывести его из строя. В отличие от таких известных решений, некоторые варианты реализации настоящего изобретения динамически помещают агент аудита в проверяемую машину на время аудита, таким образом уменьшая риски для безопасности компьютера. Еще одно преимущество отсутствия постоянного агента аудита в проверяемой ВМ состоит в том, что такие конфигурации могут значительно облегчить администрирование, развертывание и обновление как виртуальных машин, так и программного обеспечения аудита. Когда решение о проверке является независимым и не привязано постоянно к проверяемой виртуальной машине, программное обеспечение аудита может обновляться независимо от программного обеспечения ВМ. Например, обновления для подсистемы 40 аудита ВМ можно установить, не затрагивая работу гостевых виртуальных машин, исполняемых на соответствующем клиенте. Во многих современных приложениях аппаратной виртуализации, таких как ИВРС, виртуальные машины обычно создаются и удаляются динамически в клиентской системе, часто на основе образа ВМ, хранящегося локально на клиенте или получаемого от компьютера сервера ИВРС. Если у проверяемой ВМ нет постоянного агента аудита, образ ВМ может быть обновлен или иным образом изменен в любое время, не затрагивая программное обеспечение аудита.
[0067] Выполнение операций аудита вне проверяемой ВМ, однако, создает неприятную техническую проблему, широко известную в данной области как "преодоление семантического разрыва". В то время как программное обеспечение, исполняемое в проверяемой ВМ имеет доступ к обширной информации, относящейся к аудиту, программное обеспечение, исполняемое вне соответствующей ВМ, как правило, имеет доступ только к содержимому физической памяти и к текущему состоянию виртуального процессора проверяемой ВМ. Поэтому, распутывание семантик программного обеспечения внутри ВМ и вне соответствующей ВМ может оказаться невозможным, или в лучшем случае может потребоваться значительное количество вычислений. Поэтому, чтобы помочь преодолеть семантический разрыв, в некоторых вариантах осуществления агент аудита помещается в проверяемую ВМ. Агент аудита может собирать информацию внутри проверяемой ВМ и передавать такую информацию компонентам, исполняемыми вне проверяемой ВМ.
[0068] Квалифицированному специалисту ясно, что вышеуказанные варианты осуществления могут быть изменены во многих направлениях, не выходя за рамки объема настоящего изобретения. Соответственно, объем настоящего изобретения должен определяться нижеследующей формулой изобретения и ее юридическими эквивалентами.