Архитектура безопасности автоматизированных систем Российский патент 2020 года по МПК G06F21/53 

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

Настоящее изобретение относится к системам обеспечения безопасности автоматизированных систем.

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

Современный мир наполнен компьютерными технологиями, которые позволяют с легкостью выполнять людям многие повседневные дела и рабочие задания, автоматизировать многие процессы. Современное программное обеспечение (ПО) решает широкий спектр различных задач, начиная от формирования текстовых документов и заканчивая управлением сложными промышленными объектами. В связи с такой повсеместной компьютеризацией резко стоит вопрос обеспечения компьютерной безопасности. Безопасность важна для пользователей домашних ПК, так как вредоносное ПО, такое как вирусы, компьютерные черви и троянские программы, на сегодняшний день очень широко распространено, и подобное ПО на компьютерах пользователей может быть орудием для совершения серьезных киберпреступлений, таких как воровство денежных средств с банковских счетов. Но особенно важны вопросы безопасности для критических объектов инфраструктуры и промышленных систем. Широко обсуждаемый пример компьютерного червя Stuxnet показал, что уже существует программное обеспечение, которое может быть использовано в качестве средства несанкционированного сбора данных и диверсий в автоматизированных системах управления технологическим процессами (АСУТП) промышленных предприятий, электростанций, аэропортов и других критически важных объектов. Обеспечение безопасности - очень важный вопрос, который необходимо решать в реальном времени при работе домашнего ПК и промышленных систем.

На сегодняшний день программное обеспечение имеет свой функционал, связанный с безопасностью, который может существовать как отдельно, так и совместно с функционалом безопасности операционной системы. Другими словами, в современных операционных системах и программном обеспечении безопасность и функциональная логика едины. Такой подход имеет минусы, так как злоумышленник, используя какие-либо ошибки в функциональной логике и уязвимости нулевого дня (англ. 0-day), зачастую может обойти установленный уровень безопасности. В качестве примера можно указать TCP/IP стек - набор сетевых протоколов, в котором протокол, располагающийся на уровне выше, работает «поверх» нижнего, используя механизмы инкапсуляции. Данный набор протоколов функционально предназначен для передачи информации по сети. В тоже время в операционных системах компании Microsoft существовала уязвимость из-за ошибки в стеке TCP/IP при обработке IPv4 пакетов. Удаленный пользователь мог с помощью специально сформированного пакета завершить работу системы. В качестве другого примера можно привести файловую систему NTFS, которая обладает своими механизмами безопасности, например разграничением доступа. Так, NTFS драйвер, который инициирует обращение к блокам информации на диске, также осуществляет и контроль доступа. Если из драйвера убрать эти функции безопасности, то файловая система NTFS станет уязвимой для ряда возможных атак.

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

Прототипом архитектуры безопасности автоматизированных систем, представленной в рамках данного изобретения, послужила архитектура мандатного управления доступом Flask, разработанная National Security Agency (NSA) совместно с Secure Computing Corporation (SCC), основанная на механизме принудительной типизации (от англ. «Type Enforcement», сокращенно ПТ). Архитектура Flask была интегрирована в ядро ОС Linux. Данный проект получил название SELinux (Security Enhanced Linux). Информация о Flask и SELinux доступна мировому сообществу в сети Интернет.

Согласно архитектуре Flask, в ОС выделяется отдельный компонент, называемый сервером безопасности, в рамках которого реализуется политика безопасности. Сервер безопасности предоставляет определенный программный интерфейс другим компонентам ОС для получения ими решений политики безопасности. Другие компоненты ОС называются менеджерами объектов. Например файловая система является менеджером файлов. Архитектура Flask определяет только интерфейс, предоставляемый сервером безопасности менеджерам объектов. В SELinux сервер безопасности поддерживает следующие три механизма управления доступом: принудительной типизации (ТЕ - Type Enforcement), ролевого управления (RBAC - Role-Based Access Control) и многоуровневой безопасности (MLS - Multi-Level Security). Эти модели безопасности жестко прописаны в архитектуре, и любые изменения этого перечня повлекут за собой необходимость внесения изменений в основные компоненты архитектуры: в сервер безопасности и менеджеры объектов.

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

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

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

Настоящее изобретение предназначено для обеспечения безопасности автоматизированных систем.

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

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

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

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

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

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

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

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

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

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

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

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

В другом частном варианте осуществления множество сущностей может содержать по меньшей мере один процесс в качестве сущности.

В другом частном варианте осуществления множество сущностей может содержать по меньшей мере одно приложение в качестве сущности.

В другом частном варианте осуществления множество сущностей может содержать по меньшей мере одно компьютерное устройство в качестве сущности.

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

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

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

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

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

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

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

Фиг. 3 иллюстрирует сервер безопасности.

Фиг. 4 иллюстрирует шлюз.

Фиг. 5 показывает общий вариант реализации архитектуры безопасности.

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

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

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

Для наглядности и в целях лучшего понимания рассмотрим архитектуру безопасности, представленную в рамках данного изобретения, на примере системы безопасности в рамках операционной системы с микроядерной архитектурой, а более конкретно на примере межпроцессного взаимодействия в рамках такой операционной системы. Межпроцессное взаимодействие (англ. Inter-Process Communication, IPC) - набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью.

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

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

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

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

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

Компьютерная программная среда, представленная на Фиг. 1, в рамках которой осуществляет работу заявленная система в рамках данного варианта реализации изобретения, функционирует на вычислительном устройстве, таком как ПК или сервер, состоит из операционной системы 101, ряда приложений 104 и подсистемы безопасности, которая состоит из сервера безопасности 102 и шлюзов 103, соответствующих приложениям 104.

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

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

Любые приложения осуществляют взаимодействия между собой, а также с какой-либо операционной системой с помощью программных интерфейсов. В компьютерных системах все взаимодействия типизированы и основаны на использовании программных интерфейсов. Так, например, существуют API (от англ. API, Application Programming Interface), позволяющие одной программе обращаться к другой программе с целью выполнения конкретной операции или получения доступа к каким-либо данным, а также самой получать запросы от других программ. В целях обеспечения безопасности необходимо осуществлять проверку взаимодействия приложений с помощью указанных программных интерфейсов.

В рамках заявленной архитектуры безопасности при взаимодействии приложений с помощью программных интерфейсов используются специальные компоненты - шлюзы 103. Шлюз 103 предназначен для того, чтобы какое-либо приложение 104 взаимодействовало с операционной системой 101, а также с другим приложением 104, через него. Каждое приложение 104 может иметь свой шлюз 103. Указанный шлюз 103 позволяет выделить контекст безопасности, который связан с попыткой осуществления действия (операции), используя команды (вызовы API), передаваемые через какой-либо интерфейс. Таким контекстом безопасности, например, может быть время совершения попытки осуществления действия, идентификатор пользователя, инициировавшего попытку осуществления действия, вызываемый метод в рамках запрашиваемого действия, идентификатор сущности, инициировавшей попытку осуществления действия, идентификатор сущности, в отношении которой запрашивается действие, состояние переменных окружения, состояние сущности (если сущностью является приложением, то его состоянием может быть значение какого-либо параметра, характеризующего текущей статус приложения, например, «запущено»), параметры моделей безопасности (например, тип Type Enforcement, метка мандатного доступа, роль пользователя (в модели RBAC), информация о типе и ограничениях сессии, информация о доступных ресурсах и другие.

Также шлюз 103 содержит наименования правил, которые могут регламентировать работу приложения 104, а сами правила содержатся на сервере безопасности 103. Данные правила могут описывать, например, те интерфейсы, которые разрешены и запрещены для использования приложением 104, время, когда использование определенных интерфейсов разрешено, и так далее. Шлюз 103 может передавать наименование правила и выделенный контекст безопасности на сервер безопасности 102. Сервер безопасности 102 может быть представлен в виде отдельного модуля реализованного в рамках операционной системой 101. Задачей сервера безопасности 102 является проверка выполнения правил на параметрах из переданного контекста безопасности с целью разрешения или запрета операции, а именно выполнения команд, переданных через интерфейс. Если операция будет разрешена сервером безопасности 102, то команды будут обработаны операционной системой 101.

Теперь рассмотрим архитектуру системы безопасности более подробно на примере микроядерной операционной системы, а более конкретно на примере межпроцессного взаимодействия. Архитектура системы безопасности, приведенная на Фиг. 2, включает в себя такие компоненты как микроядро 200, сущности А, Б и В 201, 202 и 203, соответствующие данным сущностям шлюзы А, Б, и В 211, 212 и 213, а также сервер безопасности 210.

Микроядро 200 обеспечивает изоляцию сущностей друг от друга и предоставляет механизмы взаимодействия между данными сущностями. Микроядро 200, таким образом, дает гарантии перехвата всех взаимодействий для целей контроля. Сущность - активный компонент системы, представленный с точки зрения подсистемы безопасности контекстом безопасности. Активность сущностей проявляется, в том числе, в их способности инициировать действия, подлежащие контролю. Объектом принятия решений в подсистеме безопасности, таким образом, являются действия, выполняемые сущностью в отношении другой сущности или системы безопасности. Базовым элементом при принятии решений является контекст безопасности - структура данных, сопоставленная сущности и идентифицируемая уникальным непрозрачным для сущности идентификатором безопасности (SID - Security Identificator). Вторым базовым элементом является сам вызов и его свойства. В рамках межпроцессного взаимодействия сущностями являются процессы, а контекстом безопасности - набор параметров и атрибутов каждого конкретного процесса. Сущностями также могут являться более сложные объекты, такие как сетевые устройства, персональные компьютеры, мобильные телефоны или различные устройства в рамках промышленной инфраструктуры. Соответственно и микроядро 200 может быть реализовано самостоятельным программно-аппаратным комплексом, посредством которого осуществляется взаимодействие в рамках информационной системы.

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

Все взаимодействия между сущностями 201, 202 и 203 строго типизированы и описаны на специальном языке IDL (от англ. Interface Description Language или Interface Definition Language) - язык спецификаций для описания интерфейсов. Все эти взаимодействия в момент передачи микроядром 200 проверяются посредством сервера безопасности 210. Простейшим примером описания интерфейсов сущности для файловой системы на языке IDL может являться следующий код:

В рамках приведенного примера кода описаны два интерфейса: основной интерфейс взаимодействия с файловой системой IFileSystem и интерфейс безопасности IFileSystemSecurity. В рамках каждого из интерфейсов описаны три основные метода взаимодействия: открытие (open), чтение (read) и запись (write). Для наглядности приведем пример описания интерфейсов сущности для ленточного конвейера с дрелью на языке IDL:

Сервер безопасности 210 может быть также сущностью, то есть процессом в рамках примера межпроцессного взаимодействия, для которой имеется описание на IDL ее интерфейса. Очевидно, что сервер безопасности 210, как и микроядро 200 может быть реализован самостоятельным программно-аппаратным комплексом, посредством которого осуществляются проверка сообщений в рамках автоматизированной системы. Для описания конфигурации безопасности сервера безопасности 210 используется специальный язык CFG (язык конфигурации безопасности). Конфигурация безопасности сервера безопасности 210 состоит из правил, реализующих различные политики безопасности. На основании конфигурации сервера безопасности 210 формируются специальные шлюзы 211, 212 и 213. В рамках рассматриваемого примера межпроцессного взаимодействия формирование шлюзов 211, 212 и 213 может осуществляться автоматически путем компиляции конфигурации написанной на языке CFG. Для лучшего понимания, что из себя представляет конфигурация сервера безопасности 210 рассмотрим следующий пример, в рамках которого стоит задача внедрить политику безопасности для фильтрации URL-запросов от веб-браузера с использованием белого списка доменных адресов, в котором разрешенными адресами будут являться только адреса с масками «*.kaspersky.com» и «*.securelist.com». Для решения данной задачи необходим прокси-сервер, через который будет осуществляться доступ в сеть Интернет. Веб-браузер и прокси-сервер будут представлять собой отдельные сущности, взаимодействие между которыми будет проверяться сервером безопасности 210 на предмет соответствия политики фильтрации URL-запросов. Описание интерфейсов прокси-сервера на языке IDL выглядит следующим образом:

В рамках данного описания интерфейсов прокси-сервера приведен только один метод http_get, который выдает веб-страницу (data) по трем параметрам: доменному имени хоста (host), значению порта (port) и идентификатору ресурса (uri). Тогда реализация политики безопасности в рамках сервера безопасности 210, применяемая для фильтрации URL-запросов от веб-браузера с использованием белого списка доменных адресов, будет описана на языке CFG следующим образом:

Остановимся подробнее на том, что описано в каждой из строк данной реализации политики безопасности. В строке 01 декларируется использование базовой простейшей политики безопасности, которая разрешает любое взаимодействие при применении данной политики. В строке 02 декларируется использование политики безопасности, содержащей правила для осуществления строковых сравнений на предмет их совпадения. В строке 03 декларируется использование политики безопасности, содержащей правила для выявления числовых соответствий (равенства чисел). В строках 04-07 приведена конфигурация безопасности для сущности прокси-сервера, в которой доменное имя хоста и значение порта должны быть проверены политиками match и eq на их соответствие определенным в рамках политики безопасности значениям ("*.kaspersky.com" или "*.securelist.com" для доменного имени хоста и 443 для порта), чтобы веб-страница был отображена в веб-браузере.

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

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

- системную конфигурацию;

- конфигурацию отображения действий на политики безопасности (далее - конфигурация отображения).

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

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

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

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

- старт сущностей (отображается на политику инициализации контекста безопасности дочерней сущности и контроля полномочий);

- передача сообщения между сущностями (отображается на политики контроля взаимодействия);

- обращение сущности по интерфейсу безопасности (отображается на политики контроля взаимодействия).

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

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

Старт сущности выполняется следующим образом:

- сущность А 201 запрашивает создание сущности Б 202 путем вызова интерфейса ядра операционной системы;

- микроядро создает шлюз для дочерней сущности Б 202;

- шлюз Б 212 дочерней сущности Б 202 передает серверу безопасности SID родительской и дочерней сущностей, политики инициализации и политики разрешения;

- сервер безопасности 210 разрешает ссылку на контекст безопасности родительской сущности А 201, инициализирует контекст безопасности дочерней сущности Б 202 и выносит вердикт безопасности;

- При положительном вердикте микроядро разрешает создание сущности Б 202;

- При отрицательном вердикте микроядро удаляет шлюз Б 212 сущности Б 202 и возвращает сообщение об ошибке доступа.

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

Передача сообщения выполняется при участии двух сущностей - сущности Б 202, инициировавшей отправку сообщения, и сущности В 203. Контроль передачи сообщения выполняется, исходя из контекста безопасности и шлюза В 213, контекста безопасности и шлюза Б 212, а также содержимого сообщения. Фактически для валидации сообщения достаточно использовать только один из шлюзов, и, как правило, используется только шлюз шлюза-получателя, то есть шлюза В 213.

Контроль передачи сообщения происходит следующим образом:

- сущность Б 202 запрашивает отправку сообщения сущности В 203 путем вызова функции ядра операционной системы;

- микроядро сопоставляет сущности В 203 ее шлюз В 213;

- шлюз В 213 отображает запрос на политики безопасности;

- шлюз В 213 обращается к серверу безопасности 210, передавая ссылки на политики, SID контекстов безопасности сущности Б 202 и сущности В 203, избранные параметры сообщения (которые могут понадобиться политикам) для вычисления вердикта безопасности;

- сервер безопасности 210 вычисляет вердикт;

- при положительном вердикте передача сообщения разрешена;

- в противном случае передача сообщения запрещена, возвращается сообщение об ошибке.

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

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

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

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

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

- сущность В 203 выполняет запрос по интерфейсу безопасности сопоставленного с ней шлюза В 213, передавая необходимые параметры;

- шлюз В 213 отображает запрос на политики безопасности;

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

- сервер безопасности 210 вычисляет вердикт безопасности;

- шлюз В 213 возвращает вердикт безопасности сущности В 203.

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

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

На Фиг. 3 изображен сервер безопасности 210. Основная задача сервера безопасности 210 - это вычисление политик безопасности или, другими словами, вынесение вердикта безопасности в отношении сообщений в рамках системы. Сервер безопасности 210 знает все о политиках безопасности, используемых в рамках архитектуры безопасности: типы политик безопасности и их конкретные реализации в виде правил, оперирующих параметрами из контекстов безопасности. Политики безопасности могут относиться к различным моделям безопасности, например к моделям использующим механизмы принудительной типизации (ТЕ - Type Enforcement), моделям ролевого управления (RBAC - Role-Based Access Control) и многоуровневой безопасности (MLS - Multi-Level Security). Также политики безопасности могут быть построены на основе моделей мандатного управления доступом, в которых определяется уровень доступа для каждого процесса (сущности), а всем ресурсам (файлы, директории, сокеты и т.п.) в рамках данных моделей ставится в соответствие определенный тип (уровень секретности), и формируется список правил, ограничивающих возможности доступа сущностей к определенным типам. Другим примером модели безопасности является модель Bell-LaPadula, в терминах которой все субъекты (процессы) и объекты (файлы) имеют свой уровень допуска. Субъект с определенным уровнем допуска имеет право читать и создавать (писать/обновлять) объекты с тем же уровнем допуска. Кроме того, он имеет право читать менее секретные объекты и создавать объекты с более высоким уровнем. Субъект никогда не сможет создавать объекты с уровнем допуска ниже, чем он сам имеет, а также прочесть объект более высокого уровня допуска. Приведенные примеры моделей безопасности являются лишь частными вариантами и не ограничивают объем данного изобретения.

Для каждой реализации политики безопасности в рамках сервера безопасности 210 выделен интерфейс, посредством которого шлюз может запросить вычисление вердикта безопасности для сообщения в отношении конкретной политики безопасности. Сервер безопасности 210 оперирует вне функциональной логики сущностей и способен только вычислять соответствующие политики безопасности, исходя из поступивших на определенный интерфейс данных от шлюза, и возвращать вердикт безопасности запросившему шлюзу. Например, если рассматривать вариант реализации политики безопасности, использующей комбинацию трех политик, каждая из которых соответственно описана в терминах одного из упомянутых выше механизмов управления доступом ТЕ, RBAC и MLS, то с точки зрения шлюза, сервер безопасности 210 будет представлен тремя интерфейсами, по одному на каждую из перечисленных выше политик. И для каждого сообщения шлюз будет запрашивать у сервера безопасности 210 вычисление вердикта по всем трем интерфейсам. А вердикт в свою очередь будет конъюнкцией результатов вычисления каждой из политик (te && rbac && mls).

На Фиг. 4 схематично изображен шлюз 211. Основные задачи шлюза: определять конкретный метод взаимодействия в рамках сообщений системы и соответствующую ему политику безопасности; выделять контекст безопасности, относящийся к сущностям, взаимодействующим в рамках сообщения; и запрашивать вердикт безопасности у сервера безопасности 210, отправляя контекст безопасности на соответствующий интерфейс сервера безопасности 210. Каждому контролируемому событию соответствующей сущности 201, шлюз 211 сопоставляет множество политик безопасности, вычисление которых необходимо запросить у сервера безопасности для вычисления вердикта.

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

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

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

На Фиг. 5 представлен общий вариант реализации архитектуры безопасности в рамках данного изобретения. Архитектура безопасности в рамках данного варианта состоит из трех уровней:

- уровня компонентов системы, на котором реализованы сущности 501, 502 и 503;

- уровня исполнения политик безопасности, реализованного средством взаимодействия компонентов системы 504; и

- уровня вычисления вердиктов, на котором реализована подсистема безопасности 500, включающая в себя множество шлюзов 510 и сервер безопасности 505.

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

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

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

- по контексту безопасности в соответствии с собственной конфигурацией определяет набор политик, применимых для данного типа взаимодействия;

- запрашивает вычисление данного набора политик у сервера безопасности 505;

- по результатам вычислений набора политик определяет итоговый вердикт;

- передает вердикт на исполнение средству взаимодействия компонентов системы 505.

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

Средство взаимодействия компонентов системы 504, реализованное на уровне исполнения политик безопасности, предназначено для контроля исполнения сущностей, организации взаимодействия между сущностями и непосредственно взаимодействия с соответствующими шлюзами из набора шлюзов для получения и исполнения вердиктов. Вердикты могут быть представлены как простыми булевыми значениями, где 0 - запрещено, а 1 - разрешено, так и более сложными комбинациями любых символов (букв, цифр и специальных симоволов), в том числе известными словами, например, «restart/pause/activate entities».

Фиг. 6 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 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, представленного на Фиг. 6. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

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

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

1. Архитектура безопасности, реализующая контроль полномочий, содержащая:

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

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

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

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

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

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

4. Архитектура по п. 1, где каждый шлюз из множества шлюзов запрашивает вердикт у сервера безопасности более чем через один интерфейс.

5. Архитектура по п. 4, где вердикт будет конъюнкцией вердиктов, полученных от сервера безопасности по каждому из интерфейсов.

6. Архитектура по п. 1, где каждое запрашиваемое действие может быть стартом сущности.

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

8. Архитектура по п. 1, где каждое запрашиваемое действие может быть обращением сущности по интерфейсу безопасности.

9. Архитектура по п. 1, где множество сущностей может содержать по меньшей мере один процесс в качестве сущности.

10. Архитектура по п. 1, где множество сущностей может содержать по меньшей мере одно приложение в качестве сущности.

11. Архитектура по п. 1, где множество сущностей может содержать по меньшей мере одно компьютерное устройство в качестве сущности.

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

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

14. Архитектура по п. 1, где каждый шлюз независимо формируется подсистемой безопасности из конфигурации сервера безопасности.