Система и способ формирования монитора безопасности

Изобретение относится к области информационной безопасности. Технический результат заключается в повышении безопасности ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми процессами приложений операционной системы (ОС), и в обеспечении контроля доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, в соответствии с политиками безопасности. Согласно изобретению анализируют политики безопасности, в частности, путем определения процессов, для которых используется соответствующая политика безопасности; выбирают и передают политики безопасности соответствующим средствам настройки; выполняют настройку модулей проверки политик; формируют монитор безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения. 2 н. и 18 з.п. ф-лы, 6 ил.

 

Область техники

Изобретение относится к области информационной безопасности.

Уровень техники

Современные операционные системы (ОС) представляют собой сложные информационные системы (ИС) с множеством установленного программного обеспечения (ПО) для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются встроенные в ОС средства защиты, а также особенности архитектуры ОС, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий (англ. inter-process communication, IPC), которые могут быть реализованы, в частности, путем обмена сообщений между процессами.

Во многих популярных ОС (например, Windows 9x, Linux, Android и др.) используют монолитное ядро (англ. monolithic kernel), которое обладает рядом преимуществ, например простотой взаимодействия между драйверами и производительностью. Но из-за большого количества программных модулей ядра и, как следствия, высокой вероятности ошибок в коде обеспечение надежности и безопасности ОС с монолитным ядром затруднительно. Как следствие, при наличии уязвимости в ОС или в ПО некоторые нежелательные или вредоносные сообщения между процессами могут быть разрешены средствами обработки и контроля межпроцессных взаимодействий. Примером такого вредоносного сообщения между процессами может служить сообщение, содержащее запрос на доступ к защищенному участку памяти. Другим типом ядра ОС является микроядро (например, KasperskyOS, Symbian и др.), предоставляющее минимальный набор элементарных функций управления процессами и абстракций для работы с оборудованием. Для микроядерной (англ. microkernel) архитектуры ОС характерен небольшой размер микроядра и доверенной вычислительной базы. Это способствует более высокому уровню надежности и безопасности микроядерной архитектуры ОС, так как небольшой объем кода микроядра проще проверить на корректность. Но при этом такая архитектура ОС обладает, как правило, более низкой производительностью. Также существуют ОС с гибридными ядрами (англ. hybrid kernel, например MacOS X, Windows NT и др.), которые позволяют операционной системе использовать преимущества хорошо структурированной микроядерной архитектуры ОС, сохраняя при этом производительность монолитного ядра.

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

Из уровня техники известен патент US8234686B2, в котором описывают технологию создания политики безопасности криптографического модуля, после этого проверяют упомянутые политики на предмет их возможной подмены. Также известен патент US8650620B2, в котором описаны система и способ контроля запуска приложений на мобильном устройстве путем проверки сертификатов ЭЦП и с использованием мандатного контроля доступа.

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

Раскрытие сущности изобретения

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

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

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

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

Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.

Согласно еще одному частному варианту реализации сообщения включают: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.

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

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

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

На Фиг. 2 представлена система формирования монитора безопасности.

На Фиг. 3 представлен способ формирования монитора безопасности.

Фиг. 4 представляет пример компьютерной системы общего назначения.

Осуществление изобретения

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

Глоссарий

Процесс (англ. process) - последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.

Межпроцессное взаимодействие (англ. inter-process communication, IPC) - набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов.

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

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

Операция - элементарное действие, выполняемое в рамках рассматриваемого процесса (в качестве операции может выступать, например, API-функция).

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

Конечный автомат (англ. Finite State Machine, FSM) - модель дискретного устройства, характеризующаяся состояниями и переходами от одного состояния к другому. Каждое состояние конечного автомата характеризует одну из возможных ситуаций, в которой может находиться конечный автомат.

На Фиг. 1а-1в представлены схемы межпроцессного взаимодействия с использованием монитора безопасности 120 на примере операционной системы (ОС) 100 с микроядерной архитектурой. Представленная на Фиг. 1а ОС 100 включает изолированные процессы 131-132 приложений ОС 100, которые взаимодействуют между собой (IPC), а также с ядром ОС 110 посредством программных интерфейсов путем обмена сообщений 140 (также сообщения межпроцессного взаимодействия, IPC-сообщения, на фигуре обозначены стрелкой, начинающейся с точки). При этом упомянутые интерфейсы, реализуемые процессами, статически описаны, а разрешенные взаимодействия между процессами заданы заранее.

Отправка и получение сообщений процессами 131-132 происходят посредством системных вызовов ядра ОС 110.

Системные вызовы могут включать следующие:

call() - используется процессом 131 для отправки запроса 142 к процессу 132 и получения ответа 143 на осуществление межпроцессного взаимодействия;

recv() - используется процессом 132 для получения запроса 142;

reply() - используется процессом 132 для отправки ответа 143 процессу 131.

Монитор безопасности 120 - компонент ОС 100, предназначенный для осуществления контроля доставки упомянутых сообщений 140. Сообщения 140 включают следующие: запрос на запуск 141 процесса 131, запрос 142 от процесса 131 или ответ 143 от другого процесса 132 (например, вызов процессом 131 метода процесса 132), запрос процесса 132 к монитору безопасности 120 (запрос безопасности 144). Также сообщения 140 могут включать уведомление об ошибке от ядра ОС 110 в ответ на сообщения от процессов 131-132. С использованием монитора безопасности 120 осуществляют контроль доставки сообщений 140 с учетом решений 150, принятых на основании политик безопасности из базы политик 121. Контроль доставки сообщения 140 включает разрешение или запрет доставки сообщения 140 и, соответственно, разрешение или запрет выполнения взаимодействия, осуществляющегося с использованием указанного сообщения 140. Решение 150 о способе контроля доставки сообщения 140 указывает на разрешение или запрет на передачу сообщения 140 при выполнении политики безопасности. Решение 150 используется монитором безопасности 120 или его компонентами для осуществления упомянутого контроля доставки сообщений 140 (см. Фиг. 2). На основании политик безопасности могут выносить решение 150 с использованием данных сообщения 140 (например, имя запускаемого процесса или фактические аргументы вызываемого метода процесса).

Также решение 150 о способе контроля доставки сообщения 140 может зависеть от корректности структуры упомянутого сообщения 140. Таким образом, если сообщение 140 имеет недопустимую структуру, передача указанного сообщения 140 может быть запрещена. В этом случае допустимые структуры сообщений могут быть определены с использованием декларативного описания интерфейса процесса-получателя сообщения. Упомянутая структура может содержать размер сообщения, допустимые аргументы и другие допустимые параметры сообщения.

В одном частном варианте реализации монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением. В другом частном варианте реализации монитор безопасности 120 исполняется в привилегированном режиме ядра ОС 110.

В частном варианте реализации ОС 100 дополнительно включает сервис аудита 133, предназначенный для записи в журнал результатов контроля доставки сообщений 140. При этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита 133. В еще одном частном варианте реализации монитор безопасности 120 осуществляет контроль доставки сообщений 140 дополнительно с учетом текущего статуса сервиса аудита 133. При этом упомянутый статус указывает на готовность сервиса аудита 133 принимать сообщения 140. Например, если процесс 131 выполняет запрос 142 к защищенному ресурсу (через процесс 132), где информация о доступе к защищенному ресурсу всегда должна быть записана в журнал, но при этом статус сервиса аудита 133 указывает на то, что сервис аудита 133 в данный момент не сохраняет сообщения, то такой запрос 142 будет запрещен монитором безопасности 120 согласно политике безопасности.

В еще одном частном варианте реализации ОС 100 содержит контекст 122 монитора безопасности 120, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст 122 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности. В частном варианте реализации политики безопасности используют модель конечного автомата, модель мандатного контроля целостности или другие модели для реализации политик безопасности. Подробнее об упомянутых моделях будет раскрыто далее. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.

На Фиг. 1б представлен пример доставки разрешенного запроса 142 от процесса 131 к процессу 132. Процесс 131 может вызвать метод интерфейса процесса 132, для этого процесс 131 отправляет запрос 142, содержащий входные аргументы вызываемого метода. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «разрешено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 передает запрос 142 далее процессу 132.

В рассматриваемом примере процесс 132 далее отправляет ответ 143 процессу 131, где ответ 143 содержит выходные аргументы вызываемого метода. Способ отправки ответа 143 аналогичен способу отправки запроса 142, но в обратном порядке, от процесса 132 к процессу 131. То есть, процесс 132 отправляет ответ 143 посредством ядра ОС 110, которое в свою очередь передает ответ 143 на проверку монитору безопасности 120. Монитор безопасности 120 выносит новое решение «разрешено» на основании политик безопасности и передает указанное новое решение обратно ядру ОС 110. После этого ядро 110 на основании нового решения передает ответ 143 далее процессу 131.

На Фиг. 1в представлен пример запрещенного запроса 142 от процесса 131 к процессу 132. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «запрещено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 направляет уведомление об ошибке процессу 131. При этом запрос 142 не будет передан процессу 132.

На Фиг. 2 представлена система формирования монитора безопасности 200. Система формирования монитора безопасности 200 используется для повышения безопасности ОС 100 при обмене сообщениями 140, а также для обеспечения контроля доставки упомянутых сообщений 140 получателям. При этом монитор безопасности 120 может быть использован разработчиками ПО в различных операционных системах 100, а также в любых других компьютерных системах, в которых осуществляется обмен сообщениями, в частности в базах данных и в прикладном ПО. Пример такого использования был приведен ранее на Фиг. 1а-1в. Для каждой ОС 100 формируют монитор безопасности 120 с учетом особенностей архитектуры ОС 240, а также с учетом требований безопасности для данной ОС 100, которые выражаются в политиках безопасности. Стоит отметить, что для различных программных и программно-аппаратных систем разработчика на базе ОС 100 (далее - система разработчика) основные объекты архитектуры ОС 240 могут быть общими, например процессы, службы, приложения, драйверы, отвечающие за работу ядра ОС 110 и других компонентов ОС 260. В то же время, другие объекты архитектуры ОС 240, отвечающие за функциональность системы разработчика, будут различными для каждой из упомянутых систем. Следовательно, будут различаться и политики безопасности, с использованием которых осуществляется контроль доставки сообщений 140. Системы разработчика могут включать программное обеспечение, а также программно-аппаратные комплексы.

Система 200 содержит базу политик безопасности 121, предназначенную для хранения политик безопасности, необходимых для контроля доставки сообщений 140. Система 200 также содержит по меньшей мере одно средство настройки 220, которое предназначено для настройки соответствующего ему модуля проверки политик 221 на основании полученных от средства формирования 210 политик безопасности. Модуль проверки политик 221 предназначен для вынесения решения 150 о способе контроля доставки сообщения 140 (далее - решение) по запросу монитора безопасности 120 при выполнении политики безопасности. Система 200 также содержит описание архитектуры ОС 240, включающее такие объекты архитектуры ОС, как процессы и приложения ОС 100. В частном варианте реализации упомянутые объекты архитектуры ОС дополнительно включают объекты системы разработчика на базе ОС 100. В еще одном частном варианте реализации объекты архитектуры ОС дополнительно включают:

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

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

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

Кроме того, система 200 содержит средство формирования 210, предназначенное для анализа политик безопасности, где анализ заключается, в частности, в определении процессов, для которых используется упомянутая политика безопасности. В частном варианте реализации при упомянутом анализе учитывают объекты архитектуры ОС 240, включающие упомянутые процессы и приложения. Средство формирования 210 также предназначено для выбора политик безопасности из базы политик 121 для соответствующих средств настройки 220 и для передачи по меньшей мере одной выбранной политики безопасности соответствующему средству настройки 220. Средство формирования 210 также предназначено для формирования монитора безопасности 120 с использованием настроенных модулей проверки политик 221, полученных от каждого средства настройки 220 на основании результатов анализа. В частном варианте реализации средство формирования 210 формирует монитор безопасности 120 путем создания кода монитора безопасности 120. При этом упомянутый код может быть исходным кодом, промежуточным кодом или исполняемым кодом. Кроме того, формирование кода монитора безопасности 120 также может включать оптимизацию кода, анализ кода на наличие ошибок. Таким образом, средство формирования 210 может быть компилятором, формирующим упомянутый код.

Архитектура ОС 240, база политик 121, а также средства настройки 220 могут быть настроены заранее с использованием средства разработки 250. Для этого средство разработки 250 может предоставлять набор API (англ. application programming interface - программный интерфейс приложения) или готовые модули для разработки ПО. В частном варианте реализации по меньшей мере часть объектов архитектуры ОС 240, часть политик безопасности из базы политик 121, а также часть средств настройки 220 могут быть общими (шаблонными) для различных ОС 100. В этом случае разработчик с использованием средств разработки 250 может настроить средства настройки 220, объекты архитектуры ОС 240 и политики безопасности из базы политик безопасности 121 путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, объектов архитектуры ОС 240, а также средств настройки 220, необходимых для отражения особенностей ОС 100 или системы разработчика на базе ОС 100 и требований безопасности к ОС 100 или соответственно к системе разработчика на базе ОС 100, для которой упомянутый разработчик формирует монитор безопасности 120. Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС 100 или соответственно в системе разработчика на базе ОС 100. Например, могут быть удалены некоторые политики безопасности и приложения.

Сформированный монитор безопасности 120 вместе с другими компонентами ОС 260 далее включают в операционную систему 100. При этом упомянутое включение монитора безопасности 120 и компонентов ОС 260 может быть осуществлено известными из уровня техники способами, например на этапе компиляции ОС 100 с использованием компилятора ОС 100 или путем установки монитора безопасности 120 в ОС 100. Как упоминалось ранее, монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением ОС 100. Монитор безопасности 120 исполняется в привилегированном режиме ядра ОС 110. Для ОС 100 также может быть создан установочный образ ОС 270, необходимый для установки ОС 100 на компьютерные устройства конечных пользователей. Установочный образ ОС 270 может быть, например, архивом, исполняемым файлом или установочным пакетом. Установочный пакет представляет собой файл архива, в который входят файлы ОС 100, управляющие файлы и опционально файлы для настройки процесса установки ОС 110. Кроме того, в установочный пакет могут входить файлы системы разработчика на базе ОС 100. Упомянутые файлы могут быть представлены в исходном коде, в промежуточном коде или в исполняемом коде.

На Фиг. 3 представлен способ формирования монитора безопасности 200. На шаге 310 с использованием средства формирования 210 анализируют политики безопасности из базы политик 121. Упомянутый анализ заключается, в частности, в сопоставлении политик безопасности 121 и объектов архитектуры ОС 240. Например, будут определены процессы, для которых используется упомянутая политика безопасности. Кроме того, могут быть выбраны лишь те политики безопасности 121, которые соответствуют существующим процессам в рамках архитектуры ОС 240 или системы разработчика на базе ОС 100. Далее на шаге 320 с использованием средства формирования 210 выполняют выбор политик безопасности из базы политик 121 для соответствующих средств настройки 220 и, на шаге 330, осуществляют передачу по меньшей мере одной выбранной политики безопасности соответствующему средству настройки 220. После этого на шаге 340 с использованием средств настройки 220 выполняют настройку модулей проверки политик 221. Упомянутая настройка заключается, в частности, в добавлении выбранных политик безопасности в модули проверки политик 221. В итоге на шаге 350 с использованием средства формирования 210 формируют монитор безопасности 120 с использованием настроенных модулей проверки политик 221 на основании результатов анализа.

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

В частном варианте реализации монитор безопасности 120 формируют путем создания кода монитора безопасности 120, где код может быть исходным кодом, промежуточным кодом или исполняемым кодом. В этом варианте реализации модули проверки политик 221 также являются участками кода, включаемыми в код монитора безопасности 120.

Описание политик безопасности

В частном варианте реализации политики безопасности используют по меньшей мере одну из следующих моделей:

базовые операции;

конечный автомат;

временной автомат;

ролевое управление доступом;

мандатный контроль целостности;

регулярные выражения;

дискретные события (англ. Discrete Event Systems, DES);

мандатные ссылки;

темпоральная логика (временнáя логика; англ. temporal logic).

Политики безопасности 121 могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL мандатный контроль целостности задан классом политик Mandatory_integrity_control. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в системе, которые могут быть реализованы путем обмена сообщений 140 между процессами. При каждой попытке взаимодействия, то есть при проверке монитором безопасности 120 сообщений 140, монитор безопасности 120 исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения 140). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.

В частном варианте реализации анализ политик безопасности и объектов архитектуры ОС 240 включает по меньшей мере один из следующих видов анализа: лексический анализ, синтаксический анализ, семантический анализ. В результате указанного анализа политик безопасности определяют объекты архитектуры ОС 240, в частности, процессы, участвующие в обмене сообщений 140, для которых применяется упомянутая политика безопасности. То есть будет определено соответствие между определенными объектами архитектуры ОС 240 и политикой безопасности, применяемой для указанных объектов. Например, если политика безопасности разрешает запрос 142 от процесса 131 к процессу 132, то в результате анализа этой политики безопасности будут определены указанные процессы 131-132 и информация о разрешенном запросе 142. Стоит отметить, что в результате указанного анализа политик безопасности могут дополнительно определить и другие объекты архитектуры ОС 240, которые проверяют в указанной политике безопасности, например, методы интерфейсов процесса, когда сообщение 140 адресовано указанному методу и будет передано по указанному интерфейсу процесса. В этом случае, политики безопасности будет проверять условие, что при обмене сообщениями 140 между определенными процессами используются заданные интерфейсы процессов и заданные методы интерфейсов.

На примере языка PSL, с использованием которого могут быть заданы политики безопасности 121, указание на процесс 131, являющийся источником запроса 142, может содержаться в переменной scr. Указание на процесс 132, являющийся получателем запроса 142 может содержаться в переменной dst. Соответственно, именно упомянутый анализ политики безопасности 121, написанной на языке PSL, позволит определить указанные объекты архитектуры ОС, для которых будет применяться указанная политика безопасности.

В другом частном варианте реализации анализ политик безопасности 121 также включает проверку типов объектов архитектуры ОС 240, а также анализ на ошибки в политиках безопасности 121.

Результаты упомянутого анализа учитываются при формировании монитора безопасности 120. Например, в мониторе безопасности 120 могут быть записаны условия применения политик безопасности - перечень объектов архитектуры ОС 240, в частности, процессов, и соответствующие указанному перечню политики безопасности, а также модули проверки политик 221. Поэтому, при получении от ядра ОС 110 сообщения 140, сформированный монитор безопасности 120 определяет объекты архитектуры ОС 240, участвующие в обмене сообщением 140, после чего определяет политики безопасности, применимые к указанным объектам архитектуры ОС 240. После чего монитор безопасности 120 передает сообщения 140 модулям проверки политик 221, соответствующим указанным политикам безопасности, для вынесения решения о способе контроля доставки сообщения 140.

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

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

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

Модель временных автоматов (англ. Timed automata), и в частности временной автомат типа ERA (англ. Event-recording automata), является частным случаем конечных автоматов. В данной модели дополнительно для каждого сообщения задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения. Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение было получено спустя время, определенное таймером.

Модель мандатного контроля целостности (англ. Mandatory integrity control) используется для разрешения или запрета доставки сообщения 140. Согласно модели мандатного контроля доступа, с использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие два числа, называемые уровнем целостности (англ. Integrity level) и уровнем доступа. При этом для разрешения доставки сообщения от одного объекта к другому используются политики безопасности на основе мандатного контроля целостности, то есть использующие значения уровней целостности и уровней доступа объектов. Например, может быть использована политика безопасности, согласно которой одному объекту разрешено обращаться к другому объекту, если значение уровня доступа первого объекта не ниже значения уровня целостности другого. На языке спецификаций PSL для модели мандатного контроля целостности задают уровни целостности и уровни доступа. Таким образом, для задания уровней целостности определяют объект политик integrity, являющийся экземпляром класса Mandatory_integrity_control:

В конфигурации объекта политик integrity будут заданы три уровня целостности: LOW (низкий), MEDIUM (средний) и HIGH (высокий) - в порядке возрастания. То есть LOW < MEDIUM < HIGH.

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

Для задания политик безопасности на основе темпоральной логики формулируют свойства (требования) безопасности с помощью формулы темпоральной логики и с использованием темпоральных операторов. С использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие события их состояния из заранее определенного множества событий.

В качестве примера рассматривается применение политик безопасности на основе темпоральной логики для процесса установки ПО из образа ПО. В процессе установки могут участвовать несколько компонентов (являющихся процессами 131-132), например средство проверки и средство установки. Процесс установки ПО может включать проверку целостности образа ПО средством проверки и последующую установку ПО из образа ПО средством установки в случае, если целостность образа ПО не нарушена. Целостность образа ПО определяет непротиворечивость, полнота и сохранность данных образа ПО. Проверка целостности образа ПО может быть осуществлена путем проверки электронно-цифровой подписи. Для упомянутого образа ПО множество событий может включать следующие: {seal, verify, apply}, где seal - событие «запечатывания» образа ПО, verify - событие проверки целостности образа ПО, apply - событие установки ПО из образа ПО. Свойства безопасности формулируют, например, следующим образом:

Свойство 1. Всегда, когда выполняется проверка целостности образа ПО, должно быть гарантировано, что после процесса проверки целостности образа ПО упомянутый образ ПО не будет изменен. Данное свойство можно записать в виде формулы:

G (verify => P seal),

где G - темпоральный оператор «всегда в будущем», P - темпоральный оператор «хотя бы один раз в прошлом». Свойство 1 означает, что всегда, когда осуществляется проверка целостности образа ПО в прошлом, должна быть гарантирована невозможность дальнейшей записи данных в образ ПО.

Свойство 2. Установка ПО из образа ПО возможна только в том случае, если подтверждена целостность образа ПО. Данное свойство можно записать в виде формулы:

G (apply => P verify).

Создание объекта класса политик, реализующего управление доступом на основе темпоральной логики, может быть реализовано на языке PSL в виде следующей конструкции:

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

!apply U verify,

где U - темпоральный оператор «до тех пор, пока не наступит заданное событие».

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

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

В еще одном частном варианте реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки 220. Например, политики безопасности могут быть объедены в классы политик. Класс политик безопасности - это набор семантически связанных политик, реализующих определенную модель политик безопасности. Первый класс политик может состоять из политик безопасности, использующих конечный автомат, а второй класс политик может состоять из политик безопасности, использующих мандатный контроль целостности. В этом примере для политик безопасности из первого класса будет выбрано средство настройки 1, в то время как для политик безопасности из второго класса будет выбрано средство настройки 2. Описанный вариант реализации позволит разрабатывать средства настройки 220, предназначенные для настройки модулей проверки 221 для политик безопасности из одного класса. Кроме того, при добавлении новой политики безопасности в базу политик 121 будет использовано существующее средство настройки 220 без необходимости его доработки или добавления нового средства настройки 220.

В еще одном частном варианте реализации с использованием средства формирования 210 дополнительно включают в монитор безопасности 120 контекст 122 монитора безопасности 120, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст 122 монитора безопасности 120 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.

В частном варианте реализации в случае, если сообщению 140 соответствуют по меньшей мере две политики безопасности, дополнительно вычисляют общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого общего решения. Когда процесс 131 или процесс 132 инициирует взаимодействие путем отправки сообщения 140, монитор безопасности 120 вызывает все политики безопасности из базы политик 121, связанные с этим конкретным взаимодействием. Если все политики безопасности вынесли решение «разрешено», то с использованием монитора безопасности 120 выносят общее решение «разрешено». Если хотя бы одна политика вынесла решение «запрещено», с использованием монитора безопасности 120 выносят общее решение «запрещено».

В еще одном частном варианте реализации настройка модуля проверки политик 221 включает создание кода, обеспечивающего вынесение решения 150 по запросу монитора безопасности 120 для политики безопасности при выполнении упомянутой политики безопасности.

В частном варианте реализации монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом решений 150 на основании политик безопасности, связанных с упомянутыми сообщениями 140.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях (также — информационных системах), внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

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

1. Система формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), при этом указанная система содержит:

а) базу политик, предназначенную для хранения политик безопасности для контроля доставки сообщений;

б) по меньшей мере одно средство настройки, предназначенное для настройки модуля проверки политик на основании полученных от средства формирования политик безопасности, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности;

в) упомянутое средство формирования, предназначенное для:

анализа политик безопасности из базы политик, где анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности;

выбора политик безопасности из базы политик для соответствующих средств настройки;

передачи по меньшей мере одной политики безопасности соответствующему средству настройки;

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

2. Система по п. 1, в которой контроль доставки сообщения включает разрешение или запрет доставки сообщения.

3. Система по п. 1, в которой при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.

4. Система по п. 1, в которой сообщения включают: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.

5. Система по п. 3 или 4, в которой объекты архитектуры ОС дополнительно включают:

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

перечень программных интерфейсов для каждого процесса;

при этом межпроцессное взаимодействие осуществляется с использованием упомянутых интерфейсов процессов.

6. Система по п. 1, в которой формируют монитор безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.

7. Система по п. 1, в которой упомянутый анализ включает по меньшей мере один из: лексический анализ, синтаксический анализ, семантический анализ.

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

9. Система по п. 1, в которой политики безопасности используют по меньшей мере одну из следующих моделей:

а) базовые операции;

б) конечный автомат;

в) временной автомат;

г) ролевое управление доступом;

д) мандатный контроль целостности;

е) регулярные выражения;

ж) дискретные события;

з) мандатные ссылки;

и) темпоральная логика.

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

11. Система по п. 9, в которой с использованием средства формирования дополнительно включают в монитор безопасности контекст монитора безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого контекста, где контекст монитора безопасности содержит значения параметров политик безопасности.

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

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

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

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

16. Система по п. 1, в которой система дополнительно включает сервис аудита, предназначенный для записи в журнал результатов контроля доставки сообщений, при этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита.

17. Система по п. 16, в которой монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом статуса и текущего состояния аудита.

18. Способ формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), в котором:

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

б) с помощью средства формирования выбирают политики безопасности из базы политик для соответствующих средств настройки;

в) с помощью средства формирования передают по меньшей мере одну выбранную политику безопасности соответствующему средству настройки;

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

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

19. Способ по п. 18, в котором контроль доставки сообщения включает разрешение или запрет доставки сообщения.

20. Способ по п. 18, в котором при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.