ИНТЕГРИРОВАННОЕ САНКЦИОНИРОВАНИЕ ДОСТУПА Российский патент 2010 года по МПК G06F21/00 

Область техники, к которой относится изобретение

Описываемая технология относится к компьютерной безопасности и, в частности, к контролю доступа к ресурсам на компьютерной системе.

Предшествующий уровень техники

Так как зависимость от компьютеров и компьютерных сетей увеличивается вместе с изощренностью и частотой атак на компьютеры и компьютерные сети, тема компьютерной безопасности становится как никогда актуальной в промышленности. Настоящие методы компьютерной безопасности не отвечают требованиям по защите программ приложений и операционных систем от вредоносных программных средств - например, вирусов, «червей», и троянцев - специально предназначенных для повреждения или разрушения компьютерной системы или другой нежелательной деятельности.

Существующие модели безопасности контроля доступа обычно основываются на мандате пользователя для санкционирования (авторизации) доступа к ресурсам на компьютере. В этих моделях каждому процессу, который выполняется или исполняется с одинаковым мандатом, даются одинаковые права доступа независимо от того, необходим или нет процессу доступ ко всем ресурсам, которые доступны пользователю. Также процесс, которому необходим доступ к ресурсу, например, для считывания, записи и т.д., задает требуемый доступ в тот момент, когда производится доступ к ресурсу.

Например, пользователь регистрируется на персональном компьютере с учетной записью пользователя и предполагает, что он может получить доступ ко всем документам подготовки текста, хранимым на персональном компьютере и созданным с использованием конкретной программы подготовки текста. Чтобы выполнить такое предположение, обычная система безопасности контроля доступа предоставляет всем программам, выполняющимся в контексте пользователя, разрешение на доступ ко всем вышеупомянутым документам подготовки текста. Это представляет собой предоставление избыточного уровня разрешения, однако, так как несколько программ, выполняющихся в контексте пользователя, кроме программы подготовки текста, фактически требуют доступа к любому документу подготовки текста.

Обычно вредоносные программные средства поражают процессы посредством использования дефектов кода. Если вредоносные программные средства выполняются внутри скомпрометированного процесса, они наследует права доступа контекста пользователя, в котором выполняется процесс, и получают доступ ко всем ресурсам, которые доступны для пользователя, которых может быть значительно больше, чем исходный процесс когда-либо требовал.

Следовательно, интегрированный подход к санкционированию доступа, который усовершенствует и улучшает безопасность ресурсов на компьютере, будет иметь существенную полезность.

Краткое описание чертежей

Фиг.1 - блок-схема, иллюстрирующая выбранные компоненты, обычно включаемые по меньшей мере в некоторые компьютерные системы, на которых исполняется средство.

Фиг.2 - блок-схема, иллюстрирующая выбранные компоненты средства, согласно некоторым вариантам осуществления.

Фиг.3 - примерная политика, подходящая для использования средством, согласно некоторым вариантам осуществления.

Фиг.4 - блок-схема последовательности операций способа, посредством которого средство выполняет аудит отклоненных запросов доступа, согласно некоторым вариантам осуществления.

Фиг.5 - блок-схема последовательности операций способа, посредством которого средство выполняет аудит опасных по своей природе операций, согласно некоторым вариантам осуществления.

Фиг.6 - блок-схема последовательности операций способа, посредством которого средство выполняет обучение для облегчения точной настройки политики, согласно некоторым вариантам осуществления.

Фиг.7 - блок-схема последовательности операций способа, посредством которого средство обеспечивает многоуровневую проверку контроля доступа, согласно некоторым вариантам осуществления.

Фиг.8 - блок-схема последовательности операций способа, посредством которого средство определяет степень риска нарушения безопасности программы приложения, согласно некоторым вариантам осуществления.

Фиг.9 - блок-схема последовательности операций способа, посредством которого средство накладывает более ограничительную политику при обнаружении аномалии, согласно одному варианту осуществления.

Фиг.10 - блок-схема последовательности операций способа, посредством которого средство накладывает политику при обнаружении аномалии, согласно некоторым вариантам осуществления.

Подробное описание

Описывается программное средство («средство») для защиты компьютерной системы от отрицательных последствий, являющихся результатом использования против программ приложения и операционной системы на компьютерной системе. В некоторых вариантах осуществления средство реализуется в виде неотъемлемой части операционной системы и добавляет логически управляемый уровень контроля доступа к операционной системе. Например, средство реализуется так, что оно является неотъемлемой частью механизма контроля доступа операционной системы.

Средство может предусматривать модуль санкционирования, который принимает запросы санкционирования для различных зависящих от безопасности доступов к ресурсам и возвращает решение о разрешении доступа или отказе в доступе к ресурсу, основываясь на централизованной политике. Политика представляет собой набор правил и практик, которые определяют, как ресурс - такой как, например, сеть, файловая система, программа приложения и т.д. - управляется и защищается. В централизованном хранилище политик правила в политике располагаются централизованно, что дает возможность отменять централизованно и устанавливать централизованно правила и/или политику. Это в противоположность распределенной или пообъектной модели контроля доступа, обычно реализуемой с использованием списков контроля доступа, которые связаны с физическими объектами.

Модуль санкционирования может запрашиваться непосредственно различными компонентами операционной системы, которые обслуживают запросы доступа к ресурсам, выдаваемые программами пользовательского режима, например программами приложений, исполняющимися в контексте пользователя. Альтернативно, модуль санкционирования может запрашиваться «уровнем перехвата», располагающимся поверх таких компонентов операционной системы. Уровень перехвата представляет собой код, который перехватывает функции системного вызова, используемые программами пользовательского режима для доступа к ресурсам, и применяет «оболочки» к перехваченным функциям системного вызова. Модуль санкционирования принимает свои решения контроля доступа (т.е. разрешить или отказать), основываясь на идентификации принципала, которой является или идентификация программы приложения - например, процесса приложения - предпринимающего попытку доступа к ресурсу, или комбинация идентификации программы приложения и идентификации пользователя, от имени которого исполняется программа приложения, и политики, которая применяется к принципалу.

В некоторых вариантах осуществления средство обеспечивает возможность аудита. Например, политика может указывать, что определенное действие независимо от того, дана ли санкция (например, предоставлена авторизация) или не дана (например, заблокирована), представляет собой предмет аудита, так что добавляется элемент данных в журнал аудита. Элемент данных может включать в себя указание неуспешного правила, ресурса или объекта и принципала. Для определенных операций, таких как опасные по своей природе операции, элемент данных может включать в себя указание правила независимо от того, разрешено ли это правило или отклонено, ресурса или объекта и принципала. Средство может дополнительно инициировать события, основываясь на аудите. Например, средство может быть сконфигурировано для предоставления принципалу (например, программе приложения и/или пользователю) или другой заинтересованной стороне уведомления или указания неуспешного правила или опасной по своей природе операции.

В некоторых вариантах осуществления средство предоставляет функциональную возможность режима обучения, когда средство тестирует или сообщает о правиле вместо применения правила. Например, правило в политике может задавать, что отклоняется запрос санкционирования выполнения действия. Если режим обучения активируется для правила, например, автором политики, средство, вместо отказа в запрашиваемой санкции на выполнение действия, разрешает или предоставляет санкцию на выполнение действия и устанавливает событие, указывая, что запрос санкционирования выполнения действия был бы отклонен. Средство может генерировать отчет, который указывает, например, правило, которое было бы заблокировано, состояние программы приложения перед запросом действия и т.п. Возможность режима обучения облегчает точную настройку политики. Например, автор политики может анализировать отчет и принимать решение о необходимости того, чтобы политика или правило в политике было более или менее ограничительным.

В некоторых вариантах осуществления средство исполняется как часть многоуровневой проверки контроля доступа. В данном случае, средство выполняет свою проверку политики как часть последовательности проверок контроля доступа. Например, когда выполняется запрос к ресурсу, первоначально может вызываться обычный механизм контроля доступа для определения того, существует ли санкция для запрашиваемого ресурса. После обычного механизма контроля доступа, первоначально определяющего, что существует санкция для запрашиваемого ресурса, может вызываться средство для проверки своих политик с целью определения того, существует ли санкция для запрашиваемого ресурса. Потом могут дополнительно вызываться одна или несколько дальнейших проверок контроля доступа для окончательного определения того, существует ли санкция для запрашиваемого ресурса.

Различные варианты осуществления средства и его преимущества легче всего понять, обращаясь к Фиг.1-10 чертежей. Элементы чертежей необязательно выполнены в масштабе, при этом акцент вместо этого делается на ясную иллюстрацию принципов изобретения. На чертежах одинаковые позиции используются для идентичных и соответствующих частей различных чертежей.

На Фиг.1 представлена блок-схема, иллюстрирующая выбранные компоненты, обычно включаемые по меньшей мере в некоторые компьютерные системы, на которых исполняется средство. Эти компьютерные системы 100 могут включать в себя один или несколько центральных процессоров («ЦП») 102 для исполнения компьютерных программ; память 104 компьютера для хранения программ и данных, включая структуры данных, когда они используются; долговременное запоминающее устройство 106, такое как накопитель на жестких дисках, для долговременного хранения программ и данных; дисковод 108 для машиночитаемых носителей, такой как дисковод для компакт-дисков, для считывания программ и данных, хранящихся на машиночитаемом носителе; и сетевое соединение 110 для подключения компьютерной системы к другим компьютерным системам, например, через Интернет для обмена программами и/или данными, включая структуры данных.

Средство может быть описано в общем контексте машиночитаемых инструкций, таких как программные модули, исполняемые компьютерными системами 100 или другими устройствами. В общих чертах, программные модули включают в себя процедуры программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют определенные абстрактные типы данных. Память 104 и долговременное запоминающее устройство 106 представляют собой машиночитаемые носители, которые могут содержать инструкции, которые реализуют средство. Понятно, что память 104 и долговременное запоминающее устройство 106 могут иметь различное другое содержимое в дополнение к инструкциям, которые реализуют средство.

Понятно, что компьютерные системы 100 могут включать в себя одно или несколько устройств визуального отображения для визуального отображения выходного результата программы, таких как видеомониторы или жидкокристаллические панели, и одно или несколько устройств ввода для приема пользовательского ввода, таких как клавиатуры, микрофоны или координатно-указательные устройства, такие как мышь. Хотя компьютерные системы 100, сконфигурированные так, как описано выше, обычно используются для поддержки работы средства, понятно, что средство может быть реализовано с использованием устройств других типов и конфигураций и с другими компонентами.

На Фиг.2 представлена блок-схема, иллюстрирующая выбранные компоненты средства, согласно некоторым вариантам осуществления. Как изображено на Фиг.2, средство включает в себя модуль 202 санкционирования, который реализуется как неотъемлемый компонент операционной системы 204, подходящей для исполнения на компьютерной системе 100. Модуль 202 санкционирования, в основном, функционирует как уровень дополнительной защиты для процессов повышенного риска, таких как ориентированные на сети приложения, ориентированные на сети услуги и компоненты операционной системы, приложения, имеющие дело с недоверенным содержимым, и недоверенный код, например обычно код, доставляемый через Интернет. Модуль 202 санкционирования предусматривает логику для выполнения управляемого политикой контроля доступа к ресурсам, доступным на компьютерной системе 100.

Средство также включает в себя политики 206, на основании которых модуль 202 санкционирования принимает свои решения контроля доступа. Политики 206 представляют собой правила, которые определяют, удовлетворить или отклонить запрос санкционирования доступа к ресурсу. В некоторых вариантах осуществления политики 206 скомпилированы в исполняемые, например двоичные, правила, которые приводятся в исполнение операционной системой 204 и, в частности, модулем 202 санкционирования. В некоторых вариантах осуществления политики 206 реализуются как часть централизованного хранилища политик, которое дает возможность централизованно аннулировать и централизованно устанавливать политики 206, включая правила в политиках 206, например, пользователями и/или администраторами.

Модуль 202 санкционирования может запрашиваться различными компонентами 208 ядра операционной системы, которые обслуживают запросы доступа к ресурсу, выдаваемые принципалом, например принципалом 212а. Модуль 202 санкционирования также может запрашиваться уровнем 210 перехвата, который перехватывает функции системного вызова, выдаваемые принципалом, например принципалом 212b, для доступа к ресурсам. Уровень 210 перехвата применяет оболочки к перехваченным функциям системного вызова, чтобы дать возможность модулю 202 санкционирования выполнять проверку контроля доступа в зависимости от применимой политики 206. Например, применение оболочки может включать в себя определение идентификационных данных принципала и/или различных окружающих факторов, связанных с вычислительной системой 100, и предоставление этой информации в качестве части запроса санкционирования для выполнения системного вызова модуля 202 санкционирования, чтобы дать ему возможность выполнять проверку контроля доступа. Кроме того, модуль 202 санкционирования может непосредственно запрашиваться принципалом, например принципалом 212с.

В некоторых вариантах осуществления проверка контроля доступа, выполняемая модулем 202 санкционирования, представляет собой функцию принципала, выполняющего запрос доступа к ресурсу, и политики, которая применяется к этому принципалу. По существу, модуль 202 санкционирования принимает свои решения контроля доступа (т.е. разрешить или отказать), основываясь на идентификации принципала - или идентификации вызывающей программы приложения или комбинации идентификации вызывающей программы приложения и идентификации пользователя, от имени которого исполняется программа приложения - и правил в политике, которые применимы к принципалу. В некоторых вариантах осуществления модуль 202 санкционирования может дополнительно рассматривать параметры, такие как, например, тип запрашиваемого доступа, окружающие факторы, например находится ли компьютер, на котором исполняется программа приложения, в корпоративной сети или подключен к общедоступной сети, уровень исправлений на компьютере и т.д., в дополнение к идентификации принципала и правилам в политике, которые применимы к принципалу при принятии своего решения контроля доступа.

В некоторых вариантах осуществления средство может включать в себя необязательный модуль 214 обнаружения аномалии, как изображено прерывистыми или пунктирными линиями на Фиг.2. Модуль 214 обнаружения аномалии, в основном, функционирует для мониторинга поведения компьютерной системы 100 и программ, исполняющихся на компьютерной системе 100, чтобы обнаружить аномальное состояние. В некоторых вариантах осуществления модуль 214 обнаружения аномалии предоставляет средству первое уведомление при обнаружении аномалии и потом второе уведомление при обнаружении прекращения ранее обнаруженной аномалии. Это дает возможность средству активировать приведение в исполнение политик 206 при обнаружении аномалии до тех пор, пока аномалия не закончится, после чего политики 206 больше не приводятся в исполнение. Альтернативно, средство может первоначально накладывать менее ограничительный набор политик до тех пор, пока не обнаруживается аномалия, в этом случае приводится в исполнение более ограничительный набор политик, пока не закончится аномалия, и снова приводится в действие менее ограничительный набор политик. Модуль 214 обнаружения аномалий может обнаруживать аномалию или в единственном процессе, исполняющемся на компьютерной системе 100, или в группе процессов, исполняющихся на компьютерной системе 100, или во всей компьютерной системе 100.

Вышеупомянутые аспекты средства являются только иллюстративными и не предназначены для предположения никакого ограничения в отношении реализации иллюстрированных компонентов и/или объема использования или функциональных возможностей средства. Например, в некоторых вариантах осуществления нет необходимости реализовывать модуль 202 санкционирования в качестве отдельной части или неотъемлемой части операционной системы 204, но он может быть реализован отдельно или вне операционной системы 204, например, в качестве программы, не являющейся программой операционной системы. Кроме того, в некоторых вариантах осуществления нет необходимости реализовывать политики 206 в качестве централизованного хранилища политик или его части. Таким образом, нет необходимости, чтобы политики 206 были в одном месте, но могут реализовываться с использованием, например, распределенной модели. Кроме того, даже если политики 206 описываются как часть модуля 202 санкционирования или содержатся в нем, политики 206 должны быть только доступны для модуля 202 санкционирования.

В нижеследующем описании варианты осуществления средства описываются вместе с многочисленными иллюстративными примерами. Понятно, что варианты осуществления средства могут использоваться в случаях, которые в различных отношениях существенно отклоняются от этих примеров.

На Фиг.3 изображена примерная политика, подходящая для использования средством, согласно некоторым вариантам осуществления. Примерная политика включает в себя правила для защиты приложения Web-сервера. В качестве примера, процесс приложения, как указано элементом 302, запрашивающий ресурс, проверяется для определения того, является ли он процессом Web-сервера WebServerX, как указано элементом 304. Если модуль 202 санкционирования определяет, что запрашивающим процессом приложения является процесс Web-сервера WebServerX, модуль 202 санкционирования или разрешает, или отказывает в санкции для запрашиваемого ресурса, основываясь на правилах, включенных в политику.

Как изображено, примерная политика содержит привилегии или права доступа, предоставляемые процессу WebServerX, и по умолчанию должна отказать в санкции для запрашиваемого ресурса, как указано правилом 306, если только не задана привилегия или право доступа. В другой формулировке, если запрашиваемый ресурс не предоставлен явно в политике, выдается отказ в санкции для запрашиваемого ресурса. В некоторых вариантах осуществления политика может содержать правила, которые задают ограничения доступа, например правила, которые задают, что в санкции на выполнение конкретных действий должно быть отказано, или которые отказывают в санкции на доступ к ресурсам, или правила, которые вызывают аудит, например регистрацию события.

Первым правилом в примерной политике является директива, разрешающая процессу WebServerX записывать файлы «$html», как указано элементом 308, в «$WebDirectories», как указано элементом 310. «$html» представляет собой представление коллекции типов файлов, например *.html, *.gif и т.д. «$WebDirectories» представляет собой представление коллекции каталогов, сконфигурированных как каталоги Всемирной паутины (Web), и могут быть заданы администратором, таким как Web-администратор, который отличен от создателя политики, такого как администратор системы безопасности. Например, модуль 202 санкционирования возвращает решение о разрешении (т.е. предоставлении санкции), основываясь на этом правиле, в ответ на процесс WebServerX, запрашивающий запись файла типа, определяемого параметром «$html», в один из каталогов, определенный параметром «$WebDirectories». Таким образом, правило в политике может применяться к динамическим, независимо определенным группам объектов, таким как «$WebDirectories», и динамически конфигурируемым окружающим параметрам, таким как «$html».

Вторым правилом в примерной политике является директива, разрешающая процессу WebServerX записывать в «$FTP Upload Directory» (каталог удаленной загрузки по протоколу передачи файлов (FTP)), как указано элементом 312, если он исполняется от имени «user A» (пользователя А), как указано элементом 314. Например, модуль 202 санкционирования возвращает решение о разрешении (т.е. предоставлении санкции), основываясь на этом правиле, в ответ на процесс WebServerX, исполняющийся от имени пользователя А, запрашивающего запись в «$FTP Upload Directory».

Третьим правилом в примерной политике является директива, разрешающая входной трафик протокола передачи гипертекста (http), как указано элементом 316. Например, модуль 202 санкционирования возвращает решение о разрешении (т.е. предоставлении санкции), основываясь на этом правиле, в ответ на процесс WebServerX, запрашивающий прием входных данных http, например прием пакетов данных http, передаваемых по сетевому подключению.

Четвертым правилом в примерной политике является директива, разрешающая «FTP traffic» (трафик по FTP), как указано элементом 318, если переменная «$FTP» разрешена, как указано элементом 320. В данном случае, «$FTP» является переменной и может быть установлена администратором, который отличен от администратора системы безопасности, который создал политику. Например, модуль 202 санкционирования выполняет проверку на этапе выполнения для определения того, разрешена ли переменная «$FTP», и, если да, возвращает решение о разрешении (т.е. предоставлении санкции), основываясь на этом правиле, в ответ на процесс WebServerX, запрашивающий отправку или прием данных, определенных параметром «FTP traffic». Альтернативно, если не разрешена «$FTP», модуль 202 санкционирования возвращает решение об отказе (т.е. отказе в санкции) в ответ на вышеупомянутый запрос доступа, как указано элементом 306.

Понятно, что политика может включать в себя правила, которые определяют привилегии для объектов внутри и вне операционной системы, таких как процессы приложений, как изображено примерной привилегией выше. Правила в политике могут задаваться с использованием схемы с широкими возможностями, аналогично коду записи с использованием компилируемого или интерпретируемого языка программирования. Например, схема может поддерживать включение в правила условий и временных условий, например, «разрешить Х только если Y» («allow X only if Y»), зависимостей от динамически конфигурируемых окружающих параметров и переменных, зависимостей от окружающих факторов и т.д. Кроме того, использование параметров облегчает создание правил, которые применяются как к настоящим, так и будущим объектам. Например, документы конкретного типа могут представляться параметром, и, используя этот параметр, может создаваться правило, которое задает ограничение, которое применяется ко всем документам этого конкретного типа, или существующим в настоящее время, или создаваемым позже. В некоторых вариантах осуществления политика может задавать, что определенные решения должны передаваться для решения конечному пользователю, например, при помощи всплывающего диалогового окна.

На Фиг.4 изображена блок-схема последовательности операций способа 400, посредством которого средство выполняет аудит отклоненных запросов доступа, согласно некоторым вариантам осуществления. В качестве примера, пользователь (например, UserABC), возможно, зарегистрировался на компьютере и запустил приложение подготовки текста (например, WPApp) и запросил открытие файла (например, FileX), хранимого в каталоге (например, YZDir) на компьютере. В результате, WPApp выдает запрос доступа к ресурсу FileX, хранимому в каталоге YZDir. Начиная с начального этапа модуль 202 санкционирования принимает запрос санкционирования, например запрос санкционирования доступа к FileX, хранимому в YZDir, на этапе 402.

На этапе 404 модуль 202 санкционирования идентифицирует принципала, который запрашивает санкцию на доступ к FileX, хранимому в YZDir. В вышеупомянутом примере принципалом может быть или WPApp, или комбинация WPApp и UserABC. На этапе 406 модуль 202 санкционирования идентифицирует политику, применимую к идентифицированному принципалу, например, из централизованного хранилища политик, такого как политики 206, и выполняет проверку контроля доступа, основываясь на идентификации принципала и применимой политики. На этапе 408 модуль 202 санкционирования определяет, является ли результатом проверки контроля доступа, выполняемой на этапе 406, отказ в доступе. Продолжая вышеупомянутый пример, модуль 202 санкционирования анализирует идентифицированную применимую политику для определения того, санкционирует ли правило или привилегия в политике принципала на доступ к FileX, хранимому в YZDir, на этапе 408.

Если модуль 202 санкционирования определяет, что применимая политика санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 420 модуль 202 санкционирования возвращает решение о разрешении, которое представляет собой указание на то, что принципал авторизован на выполнение запрашиваемого действия, и переходит к завершающему этапу. Альтернативно, если модуль 202 санкционирования определяет, что применимая политика не санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 410 модуль 202 санкционирования возвращает решение об отказе, которое представляет собой указание на то, что принципал не имеет санкции на выполнение запрашиваемого действия. На этапе 412 модуль 202 санкционирования может возвратить строку об ошибке принципалу, информируя принципала об отсутствии санкции на выполнение запрашиваемого действия.

На этапе 414 модуль 202 санкционирования выполняет проверку с целью определения того, разрешен ли аудит. Флаг или запись, ассоциированные с применимой политикой или правилом, может указывать, выполнять ли аудит. Если аудит не разрешен, модуль 202 санкционирования переходит к завершающему этапу. Альтернативно, если аудит разрешен, модуль 202 санкционирования выполняет ввод элементов данных в журнал аудита на этапе 416. Элемент данных может идентифицировать отклоненный запрос, неуспешное правило, принципала и/или запрашиваемый ресурс.

На этапе 418 модуль 202 санкционирования может инициировать одно или несколько событий, основываясь на аудите отклоненного запроса. Например, модуль 202 санкционирования может предоставить администратору системы безопасности указание, например, при помощи электронной почты, голосовой почты, обмена текстовыми сообщениями и т.д., о сделанной принципалом попытке выполнения неавторизованного действия, завершить процесс приложения после сделанной принципалом попытки выполнения неавторизованного действия, наложить более строгий набор политик после сделанной принципалом попытки выполнения неавторизованного действия и т.п. После инициирования событий модуль 202 санкционирования переходит к завершающему этапу.

Для специалиста в данной области техники понятно, что для этого и других процессов и способов, описанных в данном описании, функции, выполняемые в процессах и способах, могут реализовываться в различном порядке. Кроме того, приведенные этапы являются только примерными, и некоторые из этапов могут быть необязательными, объединены в меньшее количество этапов или расширены в дополнительные этапы без отступления от сущности изобретения.

На Фиг.5 изображена блок-схема последовательности операций способа 500, посредством которого средство выполняет аудит опасных по своей природе операций, согласно некоторым вариантам осуществления. В качестве примера, пользователь (например, UserABC), возможно, зарегистрировался на компьютере и запустил программу Web-браузера (например, WebBrowser) и запросил доступ к Web-странице (например, PageX) на недоверенном Web-сайте (например, WebSiteY). В результате WebBrowser выдает запрос на извлечение PageX с WebSiteY. Этапы 502-508, по существу, аналогичны этапам 402-408 способа 400.

Если на этапе 508 модуль 202 санкционирования определяет, что применимая политика не санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 510 модуль 202 санкционирования возвращает решение об отказе, которое представляет собой указание на то, что принципал не имеет санкции на выполнение запрашиваемого действия. В вышеописанном примере WebBrowser может не иметь санкции доступа к недоверенному сайту WebSiteY. На этапе 512 модуль 202 санкционирования может возвратить строку об ошибке принципалу, информируя принципала об отсутствии санкции на выполнение запрашиваемого действия. После возврата строки об ошибке модуль санкционирования переходит к завершающему этапу.

Альтернативно, если модуль 202 санкционирования определяет, что применимая политика санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 514 модуль 202 санкционирования возвращает решение о разрешении, которое представляет собой указание на то, что принципал имеет санкцию на выполнение запрашиваемого действия. На этапе 516 модуль 202 санкционирования выполняет проверку с целью определения того, является ли санкционированное действие опасной по своей природе операцией. Например, средство может вести список опасных по своей природе операций, и модуль 202 санкционирования может проверять этот список с целью определения того, перечислено ли санкционированное действие как опасная по своей природе операция.

Если, как обнаружено, санкционированное действие является опасной по своей природе операцией, тогда на этапе 518 модуль 202 санкционирования выполняет операцию аудита. Например, модуль 202 санкционирования может выполнить ввод элемента данных в журнал аудита опасных по своей природе операций для указания запроса и санкционирования выполнения опасной по своей природе операции. Элемент данных также может включать в себя указание принципала, который запросил санкционирование выполнения опасной по своей природе операции. Модуль 202 санкционирования может дополнительно выполнять другие действия, которые могут инициироваться санкционированием выполнения опасной по своей природе операции. После выполнения операции аудита на этапе 518 или определения того, что санкционированное действие не является опасной по своей природе операцией, на этапе 516 модуль 202 санкционирования переходит на завершающий этап.

В некоторых вариантах осуществления модуль 202 санкционирования может выполнить ввод элемента данных в журнал аудита опасных по своей природе операций для указания запроса санкционирования на выполнение опасной по своей природе операции. Продолжая вышеописанный пример, предположим, что обращение к недоверенному сайту WebSiteY указывается как опасная по своей природе операция и, дополнительно, применимая политика не предоставляет санкции на доступ WebBrowser к WebSiteY, модуль 202 санкционирования возвращает решение об отказе (этап 510) и записывает запрос санкционирования на выполнение опасной по своей природе операции и последующий отказ в санкционировании, например авторизации на доступ к ресурсу, например, в журнал аудита опасных по своей природе операций. Модуль 202 санкционирования может также записывать указание принципала, который запросил санкционирование выполнения опасной по своей природе деятельности.

На Фиг.6 изображена блок-схема последовательности операций способа 600, посредством которого средство выполняет обучение для облегчения точной настройки политики, согласно некоторым вариантам осуществления. В качестве примера, пользователь (например, UserABC), возможно, зарегистрировался на компьютере и запустил программу Web-браузера (например, WebBrowser) и запросил доступ к Web-странице (например, PageX) на Web-сайте (например, WebSiteY). В результате, WebBrowser выдает запрос на извлечение PageX с WebSiteY. Этапы 602-608, по существу, аналогичны этапам 402-408 способа 400.

Если на этапе 608 модуль 202 санкционирования определяет, что применимая политика санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 610 модуль 202 санкционирования возвращает решение о разрешении, которое представляет собой указание на то, что принципал имеет санкцию на выполнение запрашиваемого действия, и переходит на завершающий этап. Альтернативно, если модуль 202 санкционирования определяет, что применимая политика не санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 612 модуль 202 санкционирования выполняет проверку с целью определения того, разрешено ли обучение для правила в политике, которое отказывает в санкции на выполнение запрашиваемого действия. Продолжая вышеупомянутый пример, политика, применимая к WebBrowser, может содержать правило, которое в явной форме отказывает в доступе WebBrowser к Интернету и, таким образом, к WebSiteY, но также может предоставлять указание для применения обучения вместо применения правила.

Если модуль 202 санкционирования определяет, что обучение не разрешено для правила, которое отказывает в санкции на выполнение запрашиваемого действия, тогда на этапе 618 модуль 202 санкционирования возвращает решение об отказе, которое представляет собой указание на то, что принципал не имеет санкции на выполнение запрашиваемого действия. В вышеупомянутом примере правило, которое в явной форме отказывает WebBrowser в доступе к Интернету и, таким образом, WebSiteY, может не иметь указания на применения обучения. В этом случае правило применяется и WebBrowser отказывается в санкции на доступ к WebSiteY. На этапе 620 модуль 202 санкционирования может возвращать строку об ошибке принципалу, информируя принципала об отсутствии санкции на выполнение запрашиваемого действия. После возвращения строки об ошибке модуль санкционирования переходит на завершающий этап.

Альтернативно, если на этапе 612 модуль 202 санкционирования определяет, что обучение разрешено для правила, которое отказывает в санкции на выполнение запрашиваемого действия, тогда на этапе 614 модуль 202 санкционирования выполняет ввод элемента данных в журнал отчета об обучении для указания неуспешного правила. Элемент данных также может включать в себя указание принципала, который запрашивал санкцию на выполнение действия, которое привело к неуспешному правилу. На этапе 616 модуль 202 санкционирования возвращает решение о разрешении, которое представляет собой указание на то, что принципал имеет санкцию на выполнение запрашиваемого действия, и переходит на завершающий этап. Таким образом, вместо применения применимого правила модуль 202 санкционирования предоставляет санкцию на выполнение запрашиваемого действия и записывает указание этого события. Администратор системы безопасности или другой заинтересованный пользователь может затем проанализировать содержимое журнала отчета об обучении с целью определения того, является ли правило или политика слишком ограничительным или недостаточно ограничительным, и точно настроить правило или политику перед фактическим приведением в исполнение или реализацией правила или политики.

В некоторых вариантах осуществления модуль 202 санкционирования может выполнить ввод элемента данных в журнал отчета об обучении для указания правила, которое обеспечило санкцию на выполнение запрашиваемого действия. Продолжая вышеупомянутый пример, предполагая, что правило в явной форме авторизует доступ WebBrowser к Интернету и, таким образом, к WebSiteY, и также предусматривает указание к применению обучения, модуль 202 санкционирования возвращает решение о разрешении (этап 610) и записывает указание правила, которое предоставило санкцию на выполнение запрашиваемого действия. Эта информация также может использоваться для точной настройки правила или политики. Например, если определяется из элементов данных в журнале отчета, что санкция на доступ к ресурсу предоставлялась слишком легко, правило или политика могут корректироваться или изменяться, чтобы уменьшить случаи, когда предоставляется авторизация доступа к ресурсу.

На Фиг.7 изображена блок-схема последовательности операций способа 700, посредством которого средство обеспечивает многоуровневую проверку контроля доступа, согласно некоторым вариантам осуществления. Ссылаясь снова на один из предшествующих примеров, пользователь (например, UserABC), возможно, зарегистрировался на компьютере и запустил приложение подготовки текста (например, WPApp) и запросил открытие файла (например, FileX), хранимого в каталоге (например, YZDir) на компьютере. В результате, WPApp выдает запрос доступа к ресурсу FileX, хранимому в каталоге YZDir. Начиная с начального этапа модуль 202 санкционирования принимает запрос санкционирования, например запрос санкционирования доступа к FileX, хранимому в YZDir, на этапе 702.

На этапе 704 операционная система, выполняющаяся на компьютере пользователя, выполняет обычную проверку контроля доступа. Продолжая вышеупомянутый пример, операционная система может выполнять проверку с целью определения того, имеет ли пользователь права на открытие (например, доступ к чтению) FileX в YZDir. На этапе 706 операционная система, используя свой обычный механизм проверки доступа, определяет, отказать ли в доступе пользователя к FileX.

Если обычный механизм проверки доступа операционной системы определяет, что пользователю должно быть отказано в доступе к FileX, тогда на этапе 708 операционная система возвращает решение об отказе и переходит на завершающий этап. Решение об отказе представляет собой указание на то, что пользователь не имеет санкции на выполнение запрашиваемого действия, например открытие FileX. Альтернативно, если обычный механизм проверки доступа операционной системы определяет, что пользователю не должно быть отказано в доступе к FileX, тогда на этапе 710 модуль 202 санкционирования идентифицирует принципала, который запрашивает санкционирование доступа к FileX, хранимому в YZDir.

На этапе 712 модуль 202 санкционирования идентифицирует политику, применимую к идентифицированному принципалу, например, из централизованного хранилища политик, такого как политики 206, и выполняет проверку контроля доступа, основываясь на идентификации принципала и применимой политики. Продолжая вышеупомянутый пример, модуль 202 санкционирования анализирует идентифицированную применимую политику с целью определения того, санкционирует ли правило или привилегия в политике принципала на доступ к FileX, хранимому в YZDir, на этапе 714.

Если модуль 202 санкционирования определяет, что применимая политика санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 720 модуль 202 санкционирования возвращает решение о разрешении, которое представляет собой указание на то, что принципал имеет санкцию на выполнение запрашиваемого действия, и переходит на завершающий этап. Альтернативно, если модуль 202 санкционирования определяет, что применимая политика не санкционирует принципала на выполнение запрашиваемого действия, тогда на этапе 716 модуль 202 санкционирования возвращает решение об отказе, которое представляет собой указание на то, что принципал не имеет санкции на выполнение запрашиваемого действия. На этапе 718 модуль 202 санкционирования может возвращать строку об ошибке принципалу и переходит к завершающему этапу. Строка об ошибке может информировать принципала об отсутствии санкции на выполнение запрашиваемого действия.

Понятно, что многоуровневая проверка доступа может выполняться в порядке, обратном тому, который изображен в способе 700. Например, модуль 202 санкционирования сначала выполняет свою проверку контроля доступа. Если модуль 202 санкционирования определяет, что санкция должна быть предоставлена для доступа к конкретному ресурсу, тогда операционная система выполняет свою проверку безопасности, используя свой обычный механизм контроля доступа.

На Фиг.8 изображена блок-схема последовательности операций способа 800, посредством которого средство определяет степень риска нарушения безопасности программы приложения, согласно некоторым вариантам осуществления. В частности, средство выполняет оценку степени риска нарушения безопасности и/или намерения программы приложения, основываясь на анализе политики, назначенной для программы приложения. В качестве примера, пользователь, возможно, зарегистрировался на компьютере и запросил загрузку и/или исполнение программы приложения на компьютере.

Начиная с начального этапа операционная система, выполняющаяся на компьютере пользователя, принимает запрос на загрузку/исполнение программы приложения на этапе 802. На этапе 804 операционная система вызывает средство с целью определения того, имеет ли программа приложения соответствующую политику. Например, политика, применимая к программе приложения, может сохраняться как часть политик 206. Если средство определяет, что не существует политика, применимая к программе приложения, средство информирует операционную систему о том, что применимая политика не существует. На этапе 806 операционная система отклоняет запрос на загрузку/исполнение программы приложения и возвращает состояние ошибки. После отклонения запроса операционная система переходит к завершающему этапу для данного запроса.

Альтернативно, если на этапе 804 средство определяет, что политика, применимая к программе приложения, действительно существует, тогда на этапе 808 средство анализирует применимую политику для определения степени потенциального риска нарушения безопасности, связанного или возникающего в результате загрузки/исполнения программы приложения. Средство может основывать степень риска на степени или мере санкции, предоставляемой правилами в политике. Например, если правила санкционируют программу приложения на множество ресурсов или ряд опасных по своей природе ресурсов, средство может установить степень риска выше, чем если правила только санкционируют программу приложения на несколько относительно безопасных ресурсов. Средство информирует операционную систему о том, что применимая политика действительно существует и переходит к завершающему этапу.

На Фиг.9 изображена блок-схема последовательности операций способа 900, посредством которого средство накладывает более ограничительную политику при обнаружении аномалии, согласно некоторым вариантам осуществления. В качестве примера, средство, выполняющееся на компьютере, может иметь две политики, PolicyA и PolicyB, которые являются применимыми к программе приложения. Кроме того, PolicyA может быть менее ограничительной, чем PolicyB в том, что PolicyA предоставляет санкцию на большое количество ресурсов.

Начиная с начального этапа средство накладывает менее ограничительную PolicyA на этапе 902. На этапе 904 средство может обнаружить аномальное состояние в экземпляре программы приложения, исполняющейся на компьютере. Продолжая вышеупомянутый пример, экземпляр программы приложения может исполняться на компьютере, и средство может осуществлять мониторинг процесса исполняющейся программы приложения. При мониторинге процесса программы приложения средство может обнаруживать аномальное условие или состояние в процессе. Например, средство может предварительно сгенерировать ориентированный граф, который представляет системные вызовы, нормально выдаваемые программой приложения, посредством отслеживания предыдущих экземпляров программы приложения, которые выполнялись на компьютере, и определить присутствие аномального состояния из сравнения системных вызовов, сделанных текущим процессом программы приложения, и направленного графа.

На этапе 906 средство накладывает более ограничительную PolicyB в ответ на обнаружение аномального состояния и переходит к завершающему этапу. В одном варианте осуществления средство накладывает более ограничительную PolicyB на процесс программы приложения, в котором было обнаружено аномальное состояние. Альтернативно, средство может накладывать более ограничительную PolicyB на программу приложения, например на все экземпляры или процессы программы приложения. Кроме того, в зависимости от обнаруженной аномалии, программы приложения и/или конкретной политики, средство может накладывать набор более ограничительных политик на весь компьютер, например, более ограничительные политики применяются ко всем процессам, исполняющимся на компьютере.

На Фиг.10 изображена блок-схема последовательности операций способа 1000, посредством которого средство накладывает политику при обнаружении аномалии, согласно некоторым вариантам осуществления. В качестве примера, средство, выполняющееся на компьютере, может иметь политику PolicyA, которая является применимой к программе Web-приложения. Начиная с начального этапа средство не накладывает политику на программу Web-приложения на этапе 1002. Таким образом, PolicyA бездействует и не применяется к экземплярам программы Web-приложения, исполняющимся на компьютере. На этапе 1004 средство может обнаружить аномальное состояние в экземпляре программы Web-приложения, исполняющейся на компьютере.

Продолжая вышеупомянутый пример, экземпляр программы Web-приложения может исполняться на компьютере, и средство может осуществлять мониторинг процесса исполняющейся программы Web-приложения. При мониторинге процесса программы приложения средство может обнаруживать аномальное условие или состояние в процессе. Например, средство может осуществлять мониторинг трафика сети, генерируемого или вызываемого процессом Web-приложения, и определить из трафика сети, что аномальное состояние присутствует в процессе Web-приложения. На этапе 1006 средство накладывает бездействующую политику PolicyA на программу Web-приложения, например на процесс программы Web-приложения, в котором была обнаружена аномалия, и переходит на завершающий этап. Альтернативно, средство может накладывать PolicyA на все экземпляры или процессы программы Web-приложения. Таким образом, бездействующая политика становится активной и применяется к программе Web-приложения.

Из вышеописанного понятно, что конкретные варианты осуществления изобретения были описаны в данном описании с целью иллюстрации, но различные модификации могут быть выполнены без отступления от сущности и объема изобретения. Следовательно, изобретение не ограничивается ничем, кроме как прилагаемой формулой изобретения.

Изобретение относится к компьютерной безопасности и, в частности, к контролю доступа к ресурсам на компьютерной системе. Техническим результатом является усовершенствование и улучшение безопасности ресурсов на компьютере. Для достижения указанного технического результата реализован реализуемый в компьютерной системе способ точной настройки политики, содержащий этапы, на которых: принимают от исполняющейся программы запрос на доступ к ресурсу; обеспечивают централизованное хранилище политик, содержащее политики, каждая из которых применима к отличной от других программе, причем политика, применимая к исполняющейся программе, содержит, по меньшей мере, одно правило, имеющее указание на то, активировать ли режим обучения для этого правила; выполняют проверку контроля доступа для определения того, следует ли предоставить программе доступ к ресурсу, при этом если правило является неуспешным и режим обучения активирован, предоставляют программе доступ к ресурсу и регистрируют предоставление доступа и неуспешный результат правила в журнале; если правило является неуспешным и режим обучения не активирован, отказывают программе в доступе к ресурсу; если правило разрешает доступ к ресурсу и режим обучения активирован, предоставляют программе доступ к ресурсу и регистрируют предоставление доступа и указание правила, ответственного за разрешение доступа к ресурсу, в журнале. 3 н. и 1 з.п. ф-лы, 10 ил.

1. Реализуемый в компьютерной системе способ точной настройки политики, содержащий этапы, на которых
принимают от исполняющейся программы приложения запрос на доступ к ресурсу компьютерной системы;
обеспечивают централизованное хранилище политик, содержащее множество политик, каждая из которых применима к отличной от других программе приложения, при этом по меньшей мере одна политика применима к упомянутой исполняющейся программе приложения, причем эта по меньшей мере одна политика содержит по меньшей мере одно правило, имеющее указание на то, активировать ли режим обучения для этого правила;
выполняют проверку контроля доступа для определения того, следует ли предоставить упомянутой исполняющейся программе приложения запрошенный доступ к упомянутому ресурсу на основе упомянутой по меньшей мере одной политики, применимой к этой исполняющейся программе приложения, при этом
если упомянутое по меньшей мере одно правило является неуспешным и вызывает отказ в санкционировании доступа к упомянутому ресурсу, и режим обучения активирован:
предоставляют упомянутой исполняющейся программе приложения санкцию на доступ к данному ресурсу и
регистрируют предоставление санкции и неуспешный результат упомянутого по меньшей мере одного правила в журнале;
если упомянутое по меньшей мере одно правило является неуспешным и вызывает отказ в санкционировании доступа к упомянутому ресурсу, и режим обучения не активирован:
отказывают упомянутой исполняющейся программе приложения в санкционировании доступа к ресурсу;
если упомянутое по меньшей мере одно правило разрешает санкционирование доступа к упомянутому ресурсу, и режим обучения активирован:
предоставляют упомянутой исполняющейся программе приложения санкцию на доступ к данному ресурсу и
регистрируют предоставление санкции и указание упомянутого по меньшей мере одного правила, ответственного за разрешение санкционирования к данному ресурсу, в журнале.

2. Машиночитаемый носитель данных, содержимое которого предписывает компьютерной системе выполнять способ точной настройки политики, содержащий этапы, на которых
принимают от исполняющейся программы приложения запрос на доступ к ресурсу компьютерной системы;
обеспечивают централизованное хранилище политик, содержащее множество политик, каждая из которых применима к отличной от других программе приложения, при этом по меньшей мере одна политика применима к упомянутой исполняющейся программе приложения, причем эта по меньшей мере одна политика содержит по меньшей мере одно правило, имеющее указание на то, активировать ли режим обучения для этого правила;
выполняют проверку контроля доступа для определения того, следует ли предоставить упомянутой исполняющейся программе приложения запрошенный доступ к упомянутому ресурсу на основе упомянутой по меньшей мере одной политики, применимой к этой исполняющейся программе приложения, при этом
если упомянутое по меньшей мере одно правило является неуспешным и вызывает отказ в санкционировании доступа к упомянутому ресурсу, и режим обучения активирован:
предоставляют упомянутой исполняющейся программе приложения санкцию на доступ к данному ресурсу и
регистрируют предоставление санкции и неуспешный результат упомянутого по меньшей мере одного правила в журнале;
если упомянутое по меньшей мере одно правило является неуспешным и вызывает отказ в санкционировании доступа к упомянутому ресурсу, и режим обучения не активирован:
отказывают упомянутой исполняющейся программе приложения в санкционировании доступа к ресурсу;
если упомянутое по меньшей мере одно правило разрешает санкционирование доступа к упомянутому ресурсу и режим обучения активирован:
предоставляют упомянутой исполняющейся программе приложения санкцию на доступ к данному ресурсу и
регистрируют предоставление санкции и указание упомянутого по меньшей мере одного правила, ответственного за разрешение санкционирования к данному ресурсу, в журнале.

3. Система для выполнения проверки по контролю доступа, содержащая
централизованное хранилище политик, содержащее политики, задающие права доступа для программ приложений, причем по меньшей мере некоторые программы приложений имеют разные политики;
компонент загрузки, выполненный с возможностью принимать запрос на загрузку программы приложения в память и определять в ответ на прием запроса, имеется ли в централизованном хранилище политик политика для данной программы приложения, с тем чтобы, когда определено, что такой политики нет, запрос на загрузку этой программы приложения был отклонен, а когда определено, что такая политика есть, эта программа приложения была загружена в память;
компонент запроса санкционирования, выполненный с возможностью принимать запрос санкционирования, касающийся доступа к ресурсу;
компонент идентификации принципала, выполненный с возможностью идентифицировать принципала, запрашивающего доступ к этому ресурсу, при этом принципал представляет собой комбинацию упомянутой программы приложения и пользователя; и
компонент проверки по контролю доступа, выполненный с возможностью осуществления проверки по контролю доступа в зависимости от упомянутых принципала, политики в централизованном хранилище политик для упомянутой программы приложения и ресурса.

4. Система по п.3, в которой проверка по контролю доступа дополнительно выполняется относительно запрашиваемого действия в отношении ресурса.