Система и способ контроля доступа к данным
DATA ACCESS CONTROL SYSTEM AND METHOD

Область техники
Изобретение относится к области информационной безопасности.
Уровень техники
В последнее время применение цифровых сервисов в промышленном Интернете вещей (англ. Industrial Internet of Things, IIoT) становится все более актуальным. Такие цифровые сервисы установлены на удаленном сервере и предназначены для обработки и анализа данных, получаемых от устройств (оборудования) информационной системы (далее — ИС) на базе Интернета вещей (англ. Internet of Things, IoT). Данные от устройств ИС, таких как датчики и сенсоры (англ. sensors), исполнительные механизмы (англ. actuators), передают на удаленный сервер посредством сетевого шлюза (англ. gateway).
Именно на сетевой шлюз (далее — шлюз) возлагается задача обеспечения надежного и безопасного подключения устройств ИС к удаленному серверу. Устройства ИС взаимодействуют с сервером через шлюз, поэтому можно говорить, что устройства ИС размещены во внутренней сети по отношению к серверу, который в свою очередь размещен во внешней сети, и взаимодействие производится между ними через шлюз. В первую очередь проблема заключается в защите внутренней сети ИС от компьютерных атак из внешней сети. Наиболее уязвимыми являются компоненты удаленного сервера, т.к. он подключен к внешней сети, например, сети Интернет. Так, удаленный сервер подвержен целому спектру компьютерных атак, таких как: атака MITC (англ. Man in the cloud — атака, построенная на краже уникальных токенов, которые генерируются при первом использовании сервиса и для удобства хранятся на пользовательской машине); атака с использованием ошибок и уязвимостей в коде и архитектуре удаленного сервера, а также установленных сервисов; атака путем переполнения буфера; атака, реализуемая с помощью SQL-инъекции в базы данных; атака, связанная с повышением уровня привилегий; атака с использованием уязвимых каналов связи; DDoS-атака; атака, связанная с нарушением целостности данных; атака, связанная с подменой сертификатов; фишинговая атака; атака, направленная на подбор паролей или сброс пароля для получения неавторизированного доступа; атака с использованием социальной инженерии; атака, связанная с установкой вредоносного программного обеспечения (далее — ПО); атака с использованием уязвимостей; атака, связанная с установкой небезопасных приложений и др. Осуществив компьютерную атаку на удаленный сервер, злоумышленник может продолжить компьютерную атаку на шлюз и получить доступ ко внутренней сети ИС, что в свою очередь может повлечь неавторизированный (несанкционированный) доступ к данным устройств ИС и даже вывод из строя устройств ИС и самой ИС. Стоит отметить, что атака на удаленный сервер может быть осуществлена как извне, так и изнутри, например, путем физического доступа к серверу.
Другим вектором компьютерной атаки во внутреннюю сеть ИС является атака на канал связи между шлюзом и удаленным сервером, то есть на внешнюю сеть. Злоумышленник может осуществить такую атаку, например, путем поиска устройств по открытым портам, поиска уязвимостей устройств, взлома канала связи, атакой типа «человек посредине» (англ. man-in-the-middle), путем получения неавторизированного доступа к приложениям устройства.
Третьим вектором компьютерной атаки является атака на шлюз, которая может быть осуществлена путем физического доступа к шлюзу или посредством внешней сети при условии успешной атаки на удаленный сервер или на внешнюю сеть.
Ввиду упомянутых векторов атак, возникает проблема несанкционированного доступа к данным. Указанная проблема была описана ранее на примере сетевого шлюза, однако она присуща также и для других ИС. В таких ИС исполняются два и более приложения, имеющие доступ к разным областям памяти, и при этом указанным приложениям запрещен доступ к областям памяти других приложений. В случае компрометации одного из приложений скомпрометированное приложение сможет получить несанкционированный доступ к данным других приложений.
Поэтому возникает техническая проблема, которая заключается в низком уровне защиты данных от несанкционированного доступа.
Существуют различные системы защиты доступа к данным. Например, использование традиционной виртуальной файловой системы (англ. virtual file system — VFS), которая представляет собой уровень абстракции поверх конкретной реализации файловой системы, обеспечивает единообразный доступ приложений к различным типам файловых систем и различной памяти. Однако такая реализация обладает недостатком, который заключается в том, что в случае компрометации злоумышленником одного из приложений он затем может скомпрометировать виртуальную файловую систему и получить несанкционированный доступ к данным других приложений.
Поэтому возникает необходимость в технологии, способной решить заявленную техническую проблему.
Раскрытие сущности изобретения
Технический результат заключается в повышении уровня защиты данных от несанкционированного доступа путем разграничения доступа к областям памяти, которые используются приложениями.
Согласно варианту реализации используется система контроля доступа к данным, содержащая: по меньшей мере первую область памяти, предназначенную для хранения данных первого приложения, и вторую область памяти, предназначенную для хранения данных второго приложения; аппаратный процессор, выполненный с возможностью исполнения: по меньшей мере первого приложения и второго приложения; по меньшей мере процесса первой виртуальной файловой системы (далее — ВФС) и процесса второй ВФС, при этом процесс первой ВФС предназначен для организации доступа к первой области памяти, а процесс второй ВФС предназначен для организации доступа ко второй области памяти; монитора безопасности, предназначенного для контроля доступа по меньшей мере к первой области памяти и ко второй области памяти при запросе доступа к данным по меньшей мере одного приложения, при этом доступ к первой области памяти разрешен первому приложению посредством процесса первой ВФС, а доступ ко второй области памяти разрешен второму приложению посредством процесса второй ВФС.
Согласно одному из частных вариантов реализации используется система, содержащая по меньшей мере одну дополнительную область памяти, предназначенную для хранения данных соответствующего дополнительного приложения, при этом аппаратный процессор выполнен с возможностью исполнения дополнительного приложения и процесса дополнительной ВФС, который в свою очередь предназначен для организации доступа к упомянутой дополнительной области памяти, а монитор безопасности предназначен для контроля доступа к дополнительной области памяти при запросе соответствующего доступа, при этом доступ к дополнительной области памяти разрешен дополнительному приложению посредством процесса дополнительной ВФС.
Согласно другому частному варианту реализации первая область памяти и вторая область памяти разделены на физическом уровне или на программном уровне.
Согласно еще одному частному варианту реализации дополнительно аппаратный процессор выполнен с возможностью реализации драйвера хранилища данных, посредством которого организован доступ к первой и ко второй областям памяти, и предназначенного для выполнения операций ввода/вывода к первой области памяти по запросу от процесса первой ВФС или ко второй области памяти по запросу от процесса второй ВФС.
Согласно одному из частных вариантов реализации контроль доступа заключается в разрешении или запрете доступа одного компонента к другому компоненту из числа следующих: первого приложения, второго приложения, процесса первой ВФС, процесса второй ВФС, при этом разрешение или запрет определяется в соответствии с предварительно заданными политиками безопасности.
Согласно другому частному варианту реализации для контроля доступа используют политики безопасности, определяющие следующие разрешения или запреты: доступ к процессу первой ВФС разрешен первому приложению; доступ к процессу второй ВФС разрешен второму приложению; иные доступы одного компонента к другому, не указанные в политиках безопасности, запрещены.
Согласно еще одному частному варианту реализации первая область памяти дополнительно предназначена для хранения части данных второго приложения, при этом дополнительно задана политика безопасности, согласно которой доступ к процессу первой ВФС разрешен второму приложению.
Согласно одному из частных вариантов реализации политики безопасности реализуют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат с предварительно заданной таблицей переходов состояний конечного автомата; временной автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.
Согласно варианту реализации используется способ контроля доступа к данным, реализуемый при помощи компьютерной системы, включающей по меньшей мере одну область памяти и аппаратный процессор, при помощи которых: исполняют по меньшей мере первое приложение и второе приложение, при этом в процессе исполнения первое приложение имеет доступ к данным первого приложения, хранящимся в первой области памяти, а второе приложение имеет доступ к данным второго приложения, хранящимся во второй области памяти; исполняют по меньшей мере процесс первой виртуальной файловой системы (далее — ВФС) и процесс второй ВФС, при этом процесс первой ВФС предназначен для организации доступа к первой области памяти, а процесс второй ВФС предназначен для организации доступа ко второй области памяти; при запросе доступа к данным по меньшей мере одним из приложений с помощью монитора безопасности осуществляют: контроль доступа по меньшей мере к первой области памяти, при этом доступ к первой области памяти разрешен первому приложению посредством процесса первой ВФС; контроль доступа ко второй области памяти, при этом доступ ко второй области памяти разрешен второму приложению посредством процесса второй ВФС.
Согласно одному из частных вариантов реализации при наличии по меньшей мере одной дополнительной области памяти, предназначенной для хранения данных соответствующего дополнительного приложения, на аппаратном процессоре исполняют дополнительное приложение и процесс дополнительной ВФС, который в свою очередь предназначен для организации доступа к дополнительной области памяти, а с помощью монитора безопасности осуществляют контроль доступа к дополнительной области памяти при запросе соответствующего доступа, при этом доступ к дополнительной области памяти разрешен дополнительному приложению посредством процесса дополнительной ВФС.
Согласно другому частному варианту реализации первая область памяти и вторая область памяти разделены на физическом уровне или на программном уровне.
Согласно еще одному частному варианту реализации на аппаратном процессоре дополнительно исполняют драйвер хранилища данных, посредством которого организован доступ к первой и ко второй области памяти, при этом с помощью драйвера хранилища данных выполняют операции ввода/вывода к первой области памяти по запросу от процесса первой ВФС или ко второй области памяти по запросу от процесса второй ВФС.
Согласно одному из частных вариантов реализации контроль доступа заключается в разрешении или запрете доступа одного компонента к другому компоненту из числа следующих: первого приложения, второго приложения, процесса первой ВФС, процесса второй ВФС, при этом разрешение или запрет определяется в соответствии с предварительно заданными политиками безопасности.
Согласно другому частному варианту реализации для контроля доступа используют политики безопасности, определяющие следующие разрешения или запреты: доступ к процессу первой ВФС разрешен первому приложению; доступ к процессу второй ВФС разрешен второму приложению; иные доступы одного компонента к другому, не указанные в политиках безопасности, запрещены.
Согласно еще одному частному варианту реализации в первой области памяти дополнительно осуществляют хранение части данных второго приложения, при этом дополнительно задана политика безопасности, согласно которой доступ к первой ВФС разрешен второму приложению.
Согласно одному из частных вариантов реализации политики безопасности реализуют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат с предварительно заданной таблицей переходов состояний конечного автомата; временной автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:
Фиг. 1а-1в
На  представлены схемы межпроцессного взаимодействия с использованием монитора безопасности на примере операционной системы с микроядерной архитектурой.
Фиг. 2
На  представлена система формирования монитора безопасности.
Фиг. 3а
На  представлен шлюз для передачи данных из первой сети во вторую сеть.
Фиг. 3б
Фиг. 3а
На  представлен шлюз по  и обозначены возможные векторы компьютерных атак злоумышленника из второй сети на компоненты шлюза и на первую сеть.
Фиг. 4
На  представлен вариант системы контроля доступа к данным.
Фиг. 5
На  представлен вариант способа контроля доступа к данным.
Фиг. 6
представляет пример компьютерной системы общего назначения.
Осуществление изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, обеспеченными для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
Глоссарий
Процесс (англ. process) — последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.
Межпроцессное взаимодействие (англ. inter-process communication, IPC) — набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов.
Операция — элементарное действие, выполняемое в рамках рассматриваемого процесса (в качестве операции может выступать, например, API-функция). Современные операционные системы при обмене данными между двумя процессами методами межпроцессного взаимодействия используют как синхронные, так и асинхронные операции.
Конечный автомат (англ. Finite State Machine, FSM) — модель дискретного устройства, характеризующаяся состояниями и переходами от одного состояния к другому. Каждое состояние конечного автомата характеризует одну из возможных ситуаций, в которой может находиться конечный автомат.
Интернет вещей (англ. Internet of Things, IoT) — вычислительная сеть физических предметов («вещей»), оснащённых встроенными технологиями для взаимодействия друг с другом или с внешней средой. Интернет вещей включает такие технологии, как носимые устройства, электронные системы транспортных средств, умные автомобили, умные города, промышленные системы и пр.
Промышленный Интернет вещей (англ. Industrial Internet of Things, IIoT) состоит из подключенного к Интернету оборудования и платформ расширенной аналитики, которые выполняют обработку данных, получаемых от подключенных устройств. Устройства IIoT могут быть самыми разными — от небольших датчиков погоды до сложных промышленных роботов (https://www.hpe.com/ru/ru/what-is/industrial-iot.html).
Компьютерная атака (также кибератака, от англ. cyber attack) — целенаправленное воздействие на информационные системы и информационно-телекоммуникационные сети программно-техническими средствами, осуществляемое в целях нарушения безопасности информации в этих системах и сетях (см. Указ Президента РФ № 803 от 03.02.2012 «Основные направления государственной политики в области обеспечения безопасности автоматизированных систем управления производственными и технологическими процессами критически важных объектов инфраструктуры Российской Федерации»).
Сетевой шлюз локальной вычислительной сети (также — шлюз, англ. gateway) — устройство, соединяющее локальную вычислительную сеть с другой сетью.
Современные операционные системы (далее — ОС) представляют собой сложные ИС с множеством установленного ПО для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются встроенные в ОС средства защиты, а также особенности архитектуры ОС, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий, которые могут быть реализованы, в частности, путем обмена сообщений между процессами. Во многих популярных ОС (например, Windows 9x, Linux, Android и др.) используют монолитное ядро (англ. monolithic kernel), которое обладает рядом преимуществ, например, простотой взаимодействия между драйверами и производительностью. Но из-за большого количества программных модулей ядра и, как следствие, высокой вероятности ошибок в коде обеспечение надежности и безопасности ОС с монолитным ядром затруднительно. Как следствие, при наличии уязвимости в ОС доставка некоторых нежелательных или вредоносных сообщений между процессами может быть разрешена средствами обработки и контроля межпроцессных взаимодействий. Примером такого вредоносного сообщения между процессами является сообщение, содержащее запрос на доступ к защищенному участку памяти. Другим типом ядра ОС является микроядро (например, KasperskyOS, Symbian и др.), предоставляющее минимальный набор элементарных функций управления процессами и абстракций для работы с оборудованием. Для микроядерной (англ. microkernel) архитектуры ОС характерен небольшой размер микроядра и доверенной вычислительной базы. Это способствует более высокому уровню надежности и безопасности микроядерной архитектуры ОС, так как небольшой объем кода микроядра проще проверить на отсутствие уязвимостей и других ошибок. Но при этом такая архитектура ОС обладает, как правило, более низкой производительностью. Также существуют ОС с гибридными ядрами (англ. hybrid kernel, например MacOS X, Windows NT и др.), которые позволяют операционной системе использовать преимущества хорошо структурированной микроядерной архитектуры ОС, сохраняя при этом производительность монолитного ядра.
Фиг. 1а-1в
120
100
На  представлены схемы межпроцессного взаимодействия с использованием монитора безопасности  на примере ОС  с микроядерной архитектурой.
Фиг. 1а
100
131
132
100
110
140
Фиг. 1а-1в
140
141
131
142
131
143
132
131
132
132
120
144
140
100
131
132
120
100
140
120
140
110
140
131-132
Представленная на  ОС  включает изолированные процессы - приложений ОС , которые взаимодействуют между собой за счет межпроцессного взаимодействия, а также с ядром ОС  посредством программных интерфейсов путем обмена сообщениями(также сообщения межпроцессного взаимодействия, IPC-сообщения, на  обозначены полужирной стрелкой, начинающейся с точки). Сообщения  включают следующие: запрос на запуск  процесса , запрос  от процесса  или ответ  от другого процесса  (например, вызов процессом  метода процесса ), запрос процесса  к монитору безопасности  (запрос безопасности ). Стоит отметить, что под сообщениями  в настоящем изобретении понимаются сообщения межпроцессного взаимодействия, в общем случае обеспечивающие возможность взаимодействия между различными процессами ОС , в том числе процессами -. Монитор безопасности  — компонент ОС , предназначенный для осуществления контроля доставки упомянутых сообщений . Подробности реализации монитора безопасности будут раскрыты далее по тексту. Также сообщения  могут включать уведомление об ошибке от ядра ОС  в ответ на сообщения  от процессов . При этом упомянутые интерфейсы, реализуемые процессами, представляют собой структуры данных с объявленными в них методами, реализующими функционал соответствующего процесса.
Упомянутые интерфейсы статически описаны, а разрешенные взаимодействия между процессами заданы заранее.
140
131
132
110
Отправка и получение сообщений  процессами - происходят посредством системных вызовов ядра ОС .
Системные вызовы могут включать следующие:
131
142
132
143
• call() — используется процессом  для отправки запроса  к процессу  и получения ответа  на осуществление межпроцессного взаимодействия;
132
142
• recv() — используется процессом  для получения запроса ;
132
143
131
• reply() — используется процессом  для отправки ответа  процессу .
В частном варианте реализации системный вызов reply() производится в том же потоке процесса, в котором происходил вызов recv().
120
100
20
Фиг. 6
120
140
150
121
140
140
140
150
140
140
150
120
140
Фиг. 2
121
150
140
Монитор безопасности  реализован с возможностью исполнения на процессоре компьютера, на котором установлена ОС  (пример компьютера  общего назначения представлен на ). С использованием монитора безопасности  осуществляют контроль доставки сообщения  с учетом решений , принятых на основании политик безопасности из базы политик . Контроль доставки сообщения  включает разрешение или запрет доставки сообщения  и, соответственно, разрешение или запрет выполнения взаимодействия, осуществляющегося с использованием указанного сообщения . Решение  о способе контроля доставки сообщения  указывает на разрешение или передачу сообщения  при выполнении политики безопасности. Решение  используется монитором безопасности  или его компонентами для осуществления упомянутого контроля доставки сообщения  (см. ). На основании политик безопасности из базы политик  могут выносить решение  с использованием данных сообщения  (например, имени запускаемого процесса или фактических аргументов вызываемого метода процесса).
150
140
140
140
140
140
140
140
Также решение  о способе контроля доставки сообщения  может зависеть от корректности структуры упомянутого сообщения . Таким образом, если сообщение  имеет недопустимую структуру, передача указанного сообщения  может быть запрещена. В этом случае допустимые структуры сообщений могут быть определены с использованием декларативного описания интерфейса процесса-получателя сообщения . Упомянутая структура может содержать размер сообщения , допустимые аргументы и другие допустимые параметры сообщения .
120
110
120
110
В одном частном варианте реализации монитор безопасности  может быть частью ядра ОС  или отдельным приложением. В другом частном варианте реализации монитор безопасности  исполняется в привилегированном режиме ядра ОС .
100
133
140
140
133
120
140
133
133
140
131
142
132
133
133
140
142
120
В частном варианте реализации ОС  дополнительно включает сервис аудита , предназначенный для записи в журнал результатов контроля доставки сообщения . При этом контроль доставки сообщения  дополнительно включает выполнение аудита с использованием сервиса аудита . В еще одном частном варианте реализации монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом текущего статуса сервиса аудита . При этом упомянутый статус указывает на готовность сервиса аудита  принимать и сохранять сообщения . Например, если процесс  выполняет запрос  к защищенному ресурсу (через процесс ), где информация о доступе к защищенному ресурсу всегда должна быть записана в журнал, но при этом статус сервиса аудита  указывает на то, что сервис аудита  в данный момент не сохраняет сообщения , то такой запрос  будет запрещен монитором безопасности  согласно политике безопасности.
100
122
120
140
122
122
120
122
150
121
Фиг. 3а
122
122
122
В еще одном частном варианте реализации ОС  содержит контекст монитора безопасности , при этом монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом упомянутого контекста , где контекст монитора безопасности  содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности  дополнительно предназначен для изменения контекста  с учетом решений  на основании политик безопасности из базы политик . В частном варианте реализации политики безопасности используют модель конечного автомата, модель мандатного контроля целостности или другие модели для реализации политик безопасности. Подробнее об упомянутых моделях будет раскрыто далее в описании к . В зависимости от используемых политиками безопасности упомянутых моделей контекст  может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст  будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст  будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.
Фиг. 1б
142
131
132
120
131
132
131
142
131
142
110
142
120
120
150
121
150
110
110
150
142
132
На  представлен пример контроля доставки разрешенного запроса  от процесса  к процессу с использованием монитора безопасности . Процесс  может вызвать метод интерфейса процесса , для этого процесс  отправляет запрос , содержащий входные аргументы вызываемого метода. Процесс  отправляет запрос  посредством ядра ОС , которое в свою очередь передает запрос  на проверку монитору безопасности . Монитор безопасности  выносит решение  «разрешено» на основании политик безопасности из базы политик  и передает указанное решение  ядру ОС . После этого ядро  на основании решения  передает запрос  далее процессу .
132
143
140
131
143
143
142
132
131
132
143
110
143
120
120
150
121
150
110
110
150
143
131
В рассматриваемом примере процесс  далее отправляет ответ  (обратный порядок следования сообщений  не указан) процессу , где ответ  содержит выходные аргументы вызываемого метода. Способ отправки ответа  аналогичен способу отправки запроса , но в обратном порядке, от процесса  к процессу . То есть процесс  отправляет ответ  посредством ядра ОС , которое в свою очередь передает ответ  на проверку монитору безопасности . Монитор безопасности  выносит новое решение  «разрешено» на основании политик безопасности из базы политик  и передает указанное новое решение  обратно ядру ОС . После этого ядро  на основании нового решения  передает ответ  далее процессу .
Фиг. 1в
142
131
132
120
142
142
131
142
110
142
120
120
150
121
150
110
110
150
131.
142
132
На  представлен пример контроля запрещенного запроса  от процесса  к процессу , в котором монитор безопасности  осуществляет контроль доставки запроса  путем запрета доставки запроса . Процесс  отправляет запрос  посредством ядра ОС , которое в свою очередь передает запрос  на проверку монитору безопасности . Монитор безопасности  выносит решение  «запрещено» на основании политик безопасности из базы политик  и передает указанное решение  ядру ОС . После этого ядро  на основании решения  направляет уведомление об ошибке процессу  При этом запрос  не будет передан процессу .
Фиг. 2
200
200
100
140
140
120
100
140
Фиг. 1а-1в
100
120
240
100
100
240
110
260
240
140
На  представлена система формирования монитора безопасности . Система формирования монитора безопасности  используется для повышения безопасности ОС  при обмене сообщениями , а также для обеспечения контроля доставки упомянутых сообщений получателем. При этом монитор безопасности  может быть использован разработчиками ПО в различных операционных системах , а также в любых других компьютерных системах, в которых осуществляется обмен сообщениями , в частности в базах данных и в прикладном ПО. Пример такого использования был приведен ранее на . Для каждой ОС  формируют монитор безопасности  с учетом особенностей архитектуры ОС , а также с учетом требований безопасности для данной ОС , которые выражаются в политиках безопасности. Стоит отметить, что для различных программных и программно-аппаратных систем разработчика на базе ОС  (далее — система разработчика) основные объекты архитектуры ОС  могут быть общими, например, процессы, службы, приложения, драйверы, отвечающие за работу ядра ОС  и других компонентов ОС . В то же время другие объекты архитектуры ОС , отвечающие за функциональность системы разработчика, будут различными для каждой из упомянутых систем. Следовательно, будут различаться и политики безопасности, с использованием которых осуществляется контроль доставки сообщения . Системы разработчика могут включать программное обеспечение, а также программно-аппаратные комплексы.
200
121
140
200
220
221
210
221
150
140
120
121
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
240
121
220
100
250
220
240
121
240
220
100
100
100
100
120
100
100
Архитектура ОС , база политик , а также средства настройки  могут быть настроены заранее с использованием средства разработки . Для этого средство разработки  может предоставлять набор API (англ. application programming interface — программный интерфейс приложения) или готовые модули для разработки ПО. При этом под интерфейсом далее понимается интерфейс процессов, описанный ранее, а для программного интерфейса приложения будет использовано сокращение API. В частном варианте реализации по меньшей мере часть архитектуры ОС , часть политик безопасности из базы политик , а также часть средств настройки  могут быть общими (шаблонными) для различных ОС . В этом случае разработчик с использованием средств разработки  может настроить средства настройки , архитектуру ОС  и политики безопасности из базы политик  путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, объектов архитектуры ОС , а также средств настройки , необходимых для отражения особенностей ОС  или системы разработчика на базе ОС , и требований безопасности к ОС  или, соответственно, к системе разработчика на базе ОС , для которой упомянутый разработчик формирует монитор безопасности . Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС или, соответственно, в системе разработчика на базе ОС . Например, могут быть удалены некоторые политики безопасности и приложения.
120
260
100
120
260
100
100
120
100
120
110
100
120
110
100
270
100
270
100
100
100
Сформированный монитор безопасности  вместе с другими компонентами ОС  далее включают в операционную систему . При этом упомянутое включение монитора безопасности  и компонентов ОС  может быть осуществлено известными из уровня техники способами, например, на этапе компиляции ОС  с использованием компилятора ОС  или путем установки монитора безопасности  в ОС . Как упоминалось ранее, монитор безопасности  может быть частью ядра ОС  или отдельным приложением ОС . Монитор безопасности  исполняется в привилегированном режиме ядра ОС . Для ОС  также может быть создан установочный образ ОС , необходимый для установки ОС  на компьютерные устройства конечных пользователей. Установочный образ ОС  может быть, например, архивом, исполняемым файлом или установочным пакетом. Установочный пакет представляет собой файл архива, в который входят файлы ОС , управляющие файлы и опционально файлы для настройки процесса установки ОС . Кроме того, в установочный пакет могут входить файлы системы разработчика на базе ОС . Упомянутые файлы могут быть представлены в исходном коде, в промежуточном коде или в исполняемом коде.
121
140
120
140
120
150
140
Политики безопасности из базы политик  могут быть заданы с использованием языка спецификации, например, PSL (англ. policy specification language). На примере PSL мандатный контроль целостности задан классом политик Mandatory_integrity_control. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в системе, которые могут быть реализованы путем обмена сообщений  между процессами. При каждой попытке взаимодействия, то есть при проверке монитором безопасности  сообщений , монитор безопасности  исполняет правила для определения решения  о допустимости указанного взаимодействия (доставки сообщения ). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.
Фиг. 3а
300
310
350
300
20
Фиг. 6
300
20
35
300
100
Фиг. 1а-1в
120
300
310
340
311
340
310
300
351
350
300
На  представлен сетевой шлюз  для передачи данных из первой сети  во вторую сеть . В предпочтительных вариантах реализации шлюз  реализован в виде отдельного компьютерного устройства, например, компьютера общего назначения , представленного на  или в виде аппаратного маршрутизатора. В еще одном примере реализации шлюз  реализован в виде виртуальной машины, исполняющейся на процессоре компьютера общего назначения . В качестве операционной системы  шлюза  может быть использована ОС , пример которой представлен на , и включающая монитор безопасности , реализованный с возможностью исполнения на процессоре шлюза . Первая сеть  может быть внутренней сетью ИС  на базе Интернета вещей. Источник данных  включает устройства ИС , объединенные в первую сеть  и подключенное к шлюзу , для передачи данных серверу-получателю данных , например, удаленному серверу, посредством второй сети , к которой также подключен шлюз .
300
100
300
120
120
300
100
300
300
300
313
314
315
316
317
320
356
355
354
353
317
356
320
331
332
331
332
300
300
331
332
300
Ввиду того, что шлюз  является компьютерным устройством на базе ОС , для осуществления контроля взаимодействий в шлюзе  используется монитор безопасности . При этом монитор безопасности  контролирует взаимодействия между программными компонентами шлюза , представленными в виде сервисов, приложений и процессов ОС , установленной на шлюзе , и реализованных с возможностью исполнения на процессоре шлюза . При этом компоненты шлюза  включают: драйвер первой сетевой карты , первую систему ввода-вывода , агент источника , сервис обработки данных , процесс первой виртуальной файловой системы (ВФС)  (также — первая ВФС), драйвер хранилища данных , процесс второй ВФС  (также — вторая ВФС), агент получателя , вторую систему ввода-вывода , драйвер второй сетевой карты . Упомянутые процессы первой ВФС  и второй ВФС  могут быть реализованы в виде процессов или отдельных приложений, осуществляющих реализацию соответствующей виртуальной файловой системы. В частном варианте реализации драйвер хранилища данных  может содержаться в доверенной памяти , а также в недоверенной памяти . В этом случае доверенная память  и недоверенная память  также будут являться компонентами шлюза , то есть содержать сервис, приложения и процесс, реализованные с возможностью исполнения на процессоре шлюза . В то же время доверенная память , а также недоверенная память  располагаются на машиночитаемом носителе шлюза  с возможностью хранения данных.
300
121
120
300
Для каждого компонента шлюза  заданы политики безопасности в базе политик , в соответствии с которыми монитор безопасности  осуществляет контроль каждого взаимодействия между упомянутыми компонентами шлюза .
300
355
331
350
332.
355
331
350
332
315
355
355
315.
300
120
300
331
300
Фиг. 3а
300
300
355
331,
300
355
331
Шлюз  может обладать по меньшей мере двумя состояниями –– защищенное и рабочее. Защищенное состояние указывает для агента получателя  на разрешение доступа к доверенной памяти  и запрет доступа ко второй сети  и к недоверенной памяти  Рабочее состояние указывает для агента получателя  на запрет доступа к доверенной памяти , разрешение доступа ко второй сети  и к недоверенной памяти , а также на разрешение передачи данных от агента источника  агенту получателя  и на запрет передачи данных от агента получателя  агенту источника  Информация о текущем состоянии шлюза  хранится, например, в мониторе безопасности . В другом варианте реализации информация о текущем состоянии шлюза  содержится в доверенной памяти  или в отдельном временном или постоянном хранилище шлюза  (на  не указано). Поэтому политики безопасности также зависят от состояния шлюза  — например, задана политика безопасности, согласно которой в защищенном состоянии шлюза  агенту получателя  разрешен доступ к доверенной памяти  и существует другая политика безопасности, согласно которой в рабочем состоянии шлюза  агенту получателя  запрещен доступ к доверенной памяти . Подробнее о политиках безопасности будет описано далее.
300
100
300
110
140
131
132
110
120
140
100
120
Фиг 1а-1в
Так как шлюз  использует защищенную ОС , то упомянутые компоненты шлюза  взаимодействуют между собой (IPC), а также с ядром ОС  посредством программных интерфейсов путем обмена сообщениями (также сообщения межпроцессного взаимодействия, IPC-сообщения). При этом упомянутые интерфейсы, реализуемые процессами, статически описаны, а разрешенные взаимодействия между процессами заданы заранее. Отправка и получение сообщений процессами - происходят посредством системных вызовов ядра ОС . Монитор безопасности  осуществляет контроль упомянутых взаимодействий путем контроля доставки упомянутых сообщений . Подробнее о защищенной ОС  и контроле межпроцессных взаимодействий с использованием монитора безопасности  было описано ранее на .
120
300
355
331
350
332
121
300
355
331
350
332
Согласно заявленному изобретению, монитор безопасности  служит для установления состояния шлюза  в защищенное, которое указывает для агента получателя  на разрешение доступа к доверенной памяти  и запрет доступа ко второй сети  и к недоверенной памяти . Для реализации указанных разрешений и запретов задана по меньшей мере одна политика безопасности в базе политик , согласно которой в защищенном состоянии шлюза  разрешен доступ агента получателя  к доверенной памяти  и запрещен доступ ко второй сети  и к недоверенной памяти .
300
120
300
Стоит отметить, что политики безопасности могут быть заданы заранее администратором шлюза . Кроме того, политики безопасности могут быть заданы монитором безопасности  в процессе работы шлюза .
331
300
311
350
300
300
355
332
300
311
351
355
351
351
Доверенная память  содержит данные, критические для безопасной работы шлюза  и источника данных , например, параметры авторизации для передачи данных во вторую сеть (включая логины, пароли, сертификаты, электронно-цифровые подписи, необходимые для авторизации процесса передачи данных), программное обеспечение шлюза , файлы конфигурации (настройки) различных компонентов шлюза , в частности агента получателя  и др. Недоверенная память  содержит данные, не являющиеся критическими для безопасной работы шлюза  и источника данных , например, служебную информацию сервера-получателя данных , служебную информацию агента получателя , буфер для хранения передаваемых данных. Служебная информация может включать данные для авторизации сервера-получателя данных , а также приложений и сервисов, установленных на упомянутом сервере-получателе данных . К таким данным авторизации относится, например, API-токен доступа.
355
351
315,
351
350
355
351
При этом агент получателя  предназначен для установления связи с сервером-получателем данных , а также для передачи данных, полученных от агента источника  серверу-получателю данных  посредством второй сети . Одним из примеров агента получателя  является MindSphere Agent, если сервер-получатель данных  является облачным сервером на базе платформы Siemens MindSphere.
315
310
311
120
331
355
121
315
331
315
311
Агент источника  предназначен для получения упомянутых данных из первой сети  от источника данных , например, по промышленному протоколу связи OPC UA. Кроме того, монитор безопасности  предназначен для предоставления доступа к доверенной памяти  по запросу от агента получателя  при условии выполнения политик безопасности из базы политик . Агент источника  может использовать для своей работы доверенную память , например, служебную информацию агента источника , буфер для хранения данных, полученных от источника данных .
355
355
331
355
355
120
355
300
355
331
350
332
355
331
317
120
300
355
300
355
331
350
332
315
355
355
315
121
300
355
331
350
332
315
355
355
315
355
Агент получателя  предназначен для настройки в защищенном состоянии шлюза на основании параметров агента получателя  из доверенной памяти . При этом упомянутая настройка может быть осуществлена самим агентом получателя . В другом примере реализации настройка агента получателя  осуществляется монитором безопасности . Упомянутая настройка агента получателя  осуществляется в момент, когда шлюз  находится в защищенном состоянии, в котором агенту получателя  разрешен доступ к доверенной памяти  и запрещен доступ ко второй сети  и к недоверенной памяти . При этом доступ агента получателя  к доверенной памяти  может был осуществлен посредством процесса первой ВФС . Монитор безопасности  также служит для изменения состояния шлюза  на рабочее после настройки агента получателя . При этом рабочее состояние шлюза  указывает для агента получателя  на запрет доступа к доверенной памяти , разрешение доступа ко второй сети  и к недоверенной памяти , а также на разрешение передачи данных от агента источника  агенту получателя  и на запрет передачи данных от агента получателя  агенту источника . Для реализации указанных разрешений и запретов задана политика безопасности в базе политик , согласно которой в рабочем состоянии шлюза  агенту получателя  запрещен доступ к доверенной памяти , при этом разрешен доступ ко второй сети  и к недоверенной памяти , а агенту источника  разрешена передача данных агенту получателя , при этом агенту получателя  запрещена передача данных агенту источника . При этом до настройки агенту получателя  не предоставлены упомянутые разрешения и запреты.
355
351
350
355
300
355
351
355
331
350
310
311
355
315
355
350
355
В частном варианте реализации упомянутая настройка агента получателя  заключается в подготовке запроса авторизации, содержащего параметры авторизации (например, логины, пароли, сертификаты, электронно-цифровые подписи, необходимые для авторизации процесса передачи данных) к серверу-получателю данных  во второй сети . Соответственно результат настройки агента получателя  будет включать упомянутый запрос авторизации. При этом после изменения состояния шлюза  на рабочее агент получателя  служит для отправки подготовленного запроса серверу-получателю данных  для авторизации и установления соединения для последующей передачи данных. В еще одном частном варианте реализации параметры агента получателя , содержащиеся в доверенной памяти , дополнительно включают перечень данных для передачи во вторую сеть  из первой сети . Например, только данные от заданных устройств источника данных , данные заданного типа и др. В этом примере настройка агента получателя  дополнительно заключается в настройке фильтра данных для фильтрации (также — обработки) получаемых от агента источника  данных в соответствии с упомянутыми параметрами. Настройка фильтра данных может заключаться в создании правил фильтрации получаемых данных в соответствии с упомянутыми параметрами агента получателя  для последующей передачи во вторую сеть  только отфильтрованных данных. При этом фильтр данных может являться частью агента получателя .
315
355
120
121
355
355
332
332
351
Передача данных из первой сети во вторую сеть осуществляется через агента источника  и агента получателя  под контролем монитора безопасности  при выполнении политик безопасности из базы политик  и с учетом настройки агента получателя . При этом агент получателя  использует недоверенную память  для осуществления упомянутой передачи данных. Недоверенная память  включает служебную информацию получателя, то есть сервера-получателя данных .
331
332
331
332
330
330
330
331
332
300
331
332
330
330
331
332
320
320
300
300
120
121
В частном варианте реализации доверенная память  и недоверенная память  являются отдельными хранилищами данных (машиночитаемыми носителями). В другом частном варианте реализации доверенная память  и недоверенная память  являются двумя разделами одного хранилища данных , расположенными в различных диапазонах адресов хранилища данных . Хранилище данных  является, например, жестким диском, флеш-памятью или другим машиночитаемым носителем данных. При этом доступ к доверенной памяти  и к недоверенной памяти  будет осуществляться как доступ к отдельным устройствам. Поэтому оба упомянутых варианта реализации могут быть использованы в шлюзе . Для простоты изложения далее будет рассматриваться второй вариант реализации, в котором доверенная память  и недоверенная память  являются двумя разделами одного хранилища данных . Доступ к хранилищу данных  и, соответственно, к доверенной памяти  и к недоверенной памяти  осуществляется посредством драйвера хранилища данных . Драйвер хранилища данных  служит для организации доступа в хранилище данных  — то есть для выполнения операций ввода-вывода в хранилище данных  под контролем монитора безопасности  и с учетом политик безопасности из базы политик .
331
300
317
332
356
317
300
331
356
300
332
317
331
332.
356
332
331
При этом для организации доступа к доверенной памяти  в шлюзе  используется процесс первой виртуальной файловой системы , а для организации доступа к недоверенной памяти  используется процесс второй виртуальной файловой системы . Организация доступа заключается в обеспечении доступа приложений к соответствующей области памяти и её файловой системе, то есть в осуществлении операций ввода/вывода при доступе (на чтение/запись) к файлам в соответствующей области памяти. Заданы политики безопасности, разрешающие перечисленные взаимодействия и запрещающие иные взаимодействия. То есть для процесса первой ВФС  задана политика безопасности, разрешающая обращение только к первому диапазону адресов памяти хранилища данных , соответствующему доверенной памяти . Аналогично для процесса второй ВФС  задана политика безопасности, разрешающая обращение только ко второму диапазону адресов памяти хранилища данных , соответствующему недоверенной памяти . Таким образом, согласно политикам безопасности, процессу первой ВФС  будет разрешен доступ к доверенной памяти  и запрещен доступ к недоверенной памяти  При этом процессу второй ВФС  будет разрешен доступ к недоверенной памяти  и запрещен доступ к доверенной памяти .
300
312
310
313
312
311
315
313
314
300
314
313
315
313
314
311
310
312
Шлюз  также содержит первую сетевую карту , обеспечивающую подключение к первой сети . Драйвер первой сетевой карты  служит для передачи и приема данных от устройств первой сетевой карты , в частности от источника данных . В частном варианте реализации доступ агента источника  к драйверу первой сетевой карты  осуществляется посредством первой системы ввода-вывода . При этом заданы политики безопасности, разрешающие перечисленные взаимодействия и запрещающие иные взаимодействия. В частности, в защищенном и в рабочем состоянии шлюза первой системе ввода-вывода  разрешен доступ к драйверу первой сетевой карты  и к агенту источника , а драйверу первой сетевой карты  разрешен доступ к первой системе ввода-вывода , а также разрешено получать данные от источника данных  в первой сети  посредством первой сетевой карты . При этом неуказанные взаимодействия запрещены.
350
300
352
353
351
355
352
354
Для обеспечения подключения ко второй сети  шлюз  содержит вторую сетевую карту . Драйвер второй сетевой карты  служит для передачи и приема данных от устройств второй сети, в частности сервера-получателя данных . В частном варианте реализации доступ агента получателя  к драйверу второй сетевой карты  осуществляется посредством второй системы ввода-вывода . При этом заданы политики безопасности, разрешающие перечисленные взаимодействия и запрещающие иные взаимодействия, в частности следующие:
300
354
353
• в защищенном состоянии шлюза : отсутствуют разрешенные взаимодействия для второй системы ввода-вывода  и для драйвера второй сетевой карты ;
300
354
355
353
352
354
350
352
• в рабочем состоянии шлюза : второй системе ввода-вывода  разрешен доступ к агенту получателя  и к драйверу второй сетевой карты , драйверу второй сетевой карты  разрешен доступ ко второй системе ввода-вывода , а также разрешен обмен данными с устройствами второй сети  (с использованием второй сетевой карты );
• неуказанные взаимодействия запрещены.
312
352
300
310
350
Первая сетевая карта  и вторая сетевая карта  могут быть любыми известными из уровня техники сетевыми картами (также — сетевая плата, сетевой адаптер, англ. network interface controller), которые являются устройствами для взаимодействия шлюза  с другими устройствами первой сети  или второй сети  соответственно. Примерами таких сетевых карт являются Ethernet-адаптер, Wi-Fi-адаптер, Bluetooth-адаптер и др.
315
355
316
316
315
355
316
121
355
300
355
316
300
300
300
300
355
300
331
В еще одном частном варианте реализации агент источника  связан с агентом получателя  посредством сервиса обработки данных . При этом сервис обработки данных  служит для запроса и получения данных от агента источника  и последующей односторонней передачи данных агенту получателя . Стоит отметить, что для сервиса обработки данных  в базе политик  задана политика безопасности, разрешающая доступ к агенту получателя  в рабочем состоянии шлюза , в то время как для агента получателя  задана политика безопасности, запрещающая доступ к сервису обработки данных  в рабочем состоянии шлюза . Таким образом, будет реализована однонаправленная передача данных в рабочем состоянии шлюза . При этом в процессе инициализации шлюза , когда шлюз  находится в защищенном состоянии, агент получателя  считается доверенным компонентом шлюза  и ему разрешен доступ к доверенной памяти .
355
331
350
310
316
355
315
316
355
300
331
315
121
Согласно одному частному варианту реализации, упоминаемому ранее, параметры агента получателя , содержащиеся в доверенной памяти , включают перечень данных для передачи во вторую сеть  из первой сети . Согласно еще одному частному варианту реализации сервис обработки данных  дополнительно предназначен для получения упомянутых параметров агента получателя  и последующей настройки фильтра данных для фильтрации (обработки) получаемых от агента источника  данных в соответствии с упомянутыми параметрами. При этом сервис обработки данных  может получить упомянутые параметры от агента получателя  в защищенном состоянии шлюза  либо из доверенной памяти  посредством агента источника . В обоих случаях в базе политик  будут заданы политики безопасности, разрешающие упомянутые взаимодействия и запрещающие иные взаимодействия.
355
350
316
Настройка фильтра данных может заключаться в создании правил фильтрации получаемых данных в соответствии с упомянутыми параметрами агента получателя  для последующей передачи во вторую сеть  только отфильтрованных данных. При этом фильтр данных может являться частью сервиса обработки данных .
316
355
300
315
355
316
300
355
315
350
351
310
Сервис обработки данных  будет передавать агенту получателя  уже отфильтрованные данные в рабочем состоянии шлюза . Таким образом, реализуется однонаправленная передача данных от агента источника  агенту получателя  посредством сервиса обработки данных  в рабочем состоянии шлюза . Кроме того, в случае возможной компрометации злоумышленником агента получателя , злоумышленник получит доступ только к отфильтрованным данным, но не к исходным данным, полученным агентом источника . При этом к отфильтрованным данным злоумышленник мог и так получить доступ, скомпрометировав вторую сеть  или сервера-получателя данных . Поэтому представленный вариант реализации дополнительно повышает защиту данных первой сети .
Описание политик безопасности
В частном варианте реализации политики безопасности используют по меньшей мере одну из следующих моделей:
базовые операции;
конечный автомат;
временной автомат;
ролевое управление доступом;
мандатный контроль целостности;
регулярные выражения;
дискретные события (англ. Discrete Event Systems, DES);
мандатные ссылки;
темпоральная логика (временнáя логика; англ. temporal logic).
121
100
140
300
120
140
120
140
Политики безопасности из базы политик  могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL конечный автомат задан классом политик finite_state_machine. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в ОС , которые могут быть реализованы путем обмена сообщений  между процессами, соответствующими компонентам шлюза . При каждой попытке взаимодействия, то есть при проверке монитором безопасности  сообщений , монитор безопасности  исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения ). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.
240
240
140
240
142
131
132
131
132
142
240
140
140
В частном варианте реализации анализ политик безопасности и объектов архитектуры ОС  включает по меньшей мере один из следующих видов анализа: лексический анализ, синтаксический анализ, семантический анализ. В результате указанного анализа политик безопасности определяют объекты архитектуры ОС , в частности процессы, участвующие в обмене сообщений , для которых применяется упомянутая политика безопасности. То есть будет определено соответствие между определенными объектами архитектуры ОС  и политикой безопасности, применяемой для указанных объектов. Например, если политика безопасности разрешает запрос  от процесса  к процессу , то в результате анализа этой политики безопасности будут определены указанные процессы - и информация о разрешенном запросе . Стоит отметить, что в результате указанного анализа политик безопасности могут дополнительно определить и другие объекты архитектуры ОС , которые проверяют в указанной политике безопасности, например, методы интерфейсов процесса, когда сообщение  адресовано указанному методу и будет передано по указанному интерфейсу процесса. В этом случае политика безопасности будет проверять условие, что при обмене сообщениями  между определенными процессами используются заданные интерфейсы процессов и заданные методы интерфейсов.
121
131
142
132
142,
121
На примере языка PSL, с использованием которого могут быть заданы политики безопасности в базе политик , указание на процесс , являющийся источником запроса , может содержаться в переменной scr. Указание на процесс , являющийся получателем запроса  может содержаться в переменной dst. Соответственно, именно упомянутый анализ политики безопасности из базы политик , написанной на языке 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
Политики безопасности могут использовать базовые операции, разрешающие или запрещающие передачу сообщения  при условии совпадения параметров сообщения  (например, имя запускаемого процесса или фактические аргументы вызываемого метода) с данными, указанными в политике безопасности. Например, политика безопасности может определить, что процесс  может получать любые сообщения, но при этом процессу  запрещено отправлять сообщения.
300
300
300
В частном варианте реализации политики безопасности используют конечный автомат, где состоянием конечного автомата является состояние шлюза , при этом политика безопасности определяет разрешение или запрет доступа одного компонента шлюза  к другому компоненту шлюза  в зависимости от состояния конечного автомата и в соответствии с таблицей переходов состояний конечного автомата.
Ниже представлено описание конечного автомата secure_gateway:
355
331
350
332
355
331
350
332
315
355
355
315
Конечный автомат secure_gateway может находиться в одном из следующих состояний: safe (безопасное состояние), work (рабочее состояние). Состояния конечного автомата secure_gateway соответствуют состояниям шлюза. Таблица переходов конечного автомата представлена в структуре transitions. При инициализации конечного автомата secure_gateway, он находится в состоянии safe, указывающем для агента получателя  на разрешение доступа к доверенной памяти  и на запрет доступа ко второй сети  и к недоверенной памяти . Из состояния safe конечный автомат может перейти только в состояние work, указывающее для агента получателя  на запрет доступа к доверенной памяти  и на разрешение доступа ко второй сети  и к недоверенной памяти , а также указывающее на разрешение передачи данных от агента источника  агенту получателя  и на запрет передачи данных от агента получателя  агенту источника .
При этом из состояния work конечный автомат secure_gateway может перейти только в то же состояние work и не может вернуться в состояние safe.
121
355
Ниже представлены примеры политик безопасности в базе политик  для агента получателя  (Agent_dst), использующих конечный автомат secure_gateway.
355
331
Согласно описанной выше политике безопасности, агенту получателя  разрешен доступ (метод Read) к доверенной памяти  (Safe_storage) при условии, что конечный автомат secure_gateway находится в состоянии safe.
355
350
354
Согласно данной политике безопасности, агенту получателя  (Agent_dst) запрещен доступ (метод Access) ко второй сети , например, посредством второй системы ввода-вывода  (IO_ext) при условии, что конечный автомат secure_gateway находится в состоянии safe.
355
332
Согласно данной политике безопасности, агенту получателя  запрещен доступ (методы Read и Write) к недоверенной памяти  (Unsafe_storage) при условии, что конечный автомат secure_gateway находится в состоянии safe.
120
144
120
Согласно данной политике безопасности, монитору безопасности  разрешено выполнить запрос безопасности  (security) на изменение состояния (метод confirm) конечного автомата secure_gateway на work. При этом изменение состояния конечного автомата также выполнит монитор безопасности  в случае, если указанное изменение состояния конечного автомата находится в соответствии с таблицей переходов конечного автомата.
355
332
Согласно данной политике безопасности, агенту получателя  разрешен доступ (методы Read и Write) к недоверенной памяти  при условии, что конечный автомат secure_gateway находится в состоянии work.
355
331
121
120
121
355
331
Согласно данной политике безопасности, агенту получателя  запрещен доступ (методы Read и Write) к доверенной памяти  при условии, что конечный автомат secure_gateway находится в состоянии work. Стоит отметить, что эта политика безопасности может быть опциональной (то есть отсутствовать в базе политик ) в случае, если монитор безопасности  применяет политики безопасности по модели «по умолчанию запрещено» (англ. default deny). В этом случае, если в базе политик  отсутствует политика безопасности, разрешающая доступ агента получателя  к доверенной памяти , когда конечный автомат находится в состоянии work, то такой доступ по умолчанию будет запрещен.
355
315
315
Согласно данной политике безопасности, агенту получателя  разрешено получение данных (метод Receive) от агента источника  (Agent_src) и запрещена передача данных (метод Transfer) агенту источника  при условии, что конечный автомат secure_gateway находится в состоянии work.
355
350
354
Согласно данной политике безопасности, агенту получателя  разрешен доступ (метод Access) ко второй сети , например, посредством второй системы ввода-вывода  при условии, что конечный автомат secure_gateway находится в состоянии work.
В еще одном частном варианте реализации политики безопасности используют модель временных автоматов (англ. Timed automata), например временной автомат типа ERA (англ. Event-recording automata), который является одним из видов конечных автоматов. В данной модели дополнительно для каждого сообщения задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения. Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение было получено спустя время, определенное таймером.
140
120
240
140
131
132
Модель мандатного контроля целостности (англ. Mandatory integrity control) используется для разрешения или запрета доставки сообщения . Согласно модели мандатного контроля целостности, с использованием монитора безопасности  объектам архитектуры ОС , участвующим в передаче сообщения , например процессам -, ставят в соответствие два числа, называемые уровнем целостности (англ. Integrity level) и уровнем доступа. При этом для разрешения доставки сообщения от одного объекта к другому используются политики безопасности на основе мандатного контроля целостности, то есть использующие значения уровней целостности и уровней доступа объектов. Например, может быть использована политика безопасности, согласно которой одному объекту разрешено обращаться к другому объекту, если значение уровня доступа первого объекта не ниже значения уровня целостности другого. На языке спецификаций PSL для модели мандатного контроля целостности задают уровни целостности и уровни доступа. Таким образом, для задания уровней целостности определяют объект политик integrity, являющийся экземпляром класса Mandatory_integrity_control:
В конфигурации объекта политик integrity будут заданы три уровня целостности: LOW (низкий), MEDIUM (средний) и HIGH (высокий) — в порядке возрастания. То есть LOW < MEDIUM < HIGH.
В основе политик на основе мандатных ссылок (англ. object capability model) лежит принцип минимальных привилегий. Этот принцип организации доступа к ресурсам подразумевает предоставление субъекту (процессу или пользователю) только тех привилегий, которые являются абсолютно необходимыми для успешного выполнения задачи. Например, пользователю, который хочет ознакомиться с содержимым файла, должны быть выданы только права на чтение этого файла и только на период использования этого файла.
120
300
300
355
331
310
350
315
355
В еще одном частном варианте реализации политики безопасности используют темпоральную логику. Для задания политик безопасности на основе темпоральной логики формулируют свойства (требования) безопасности с помощью формулы темпоральной логики и с использованием темпоральных операторов. С использованием монитора безопасности  компонентам шлюза  ставят в соответствие события их состояния из заранее определенного множества событий. Для шлюза  множество событий может включать следующие: {read_safe, data_transfer}, где read_safe — событие доступа агента получателя  к доверенной памяти , data_transfer — событие передачи данных из первой сети  во вторую сеть  через агент источника  агенту получателя . Свойство безопасности формулируют, например, описанным ниже образом.
Свойство 1.
355
331
300
300
355
331
355
332
350
355
331
315
355
355
315
Всегда, когда агент получателя  получает доступ к доверенной памяти  в защищенном состоянии шлюза , должно быть гарантировано, что после перехода в рабочее состояние шлюза  агент получателя  не должен иметь возможности считать данные из доверенной памяти . Также должно быть гарантировано, что доступ агента получателя  к недоверенной памяти  и ко внешней сети  возможен только в том случае, если ранее был осуществлен доступ агента получателя  к доверенной памяти , то есть наступило событие read_safe. Кроме того, при наступлении события read_safe гарантируется разрешение на передачу данных от агента источника  агенту получателя  и запрет передачи данных от агента получателя  агенту источника . Указанное свойство можно записать в виде формулы:
G (data_transfer => P read_safe),
где G — темпоральный оператор «всегда в будущем», P — темпоральный оператор «хотя бы один раз в прошлом».
Создание объекта класса политик, реализующего управление доступом на основе темпоральной логики, может быть реализовано на языке PSL в виде следующей конструкции:
355
331
300
Стоит отметить, что возможны и другие формулировки свойства 1, например, оно может быть задано следующим образом: передача данных не осуществляется, пока агент получателя  не получил доступ к доверенной памяти  (то есть состояние шлюза  не переведено из защищенного в рабочее):
! data_transfer U read_safe,
где U — темпоральный оператор «до тех пор, пока не наступит заданное событие».
310
350
Политика на основе модели темпоральной логики при передаче данных из первой сети  во вторую сеть  связывает с данным межпроцессным взаимодействием событие data_transfer и проверяет истинность формулы, указанной в конфигурации объекта политик. Если формула истинна, политика разрешает взаимодействие, если ложна — запрещает.
221
Политики на основе модели с дискретными событиями задают с использованием соответствующего политикам модуля проверки . Упомянутые политики безопасности также могут быть описаны на языке спецификаций PSL. Упомянутые политики безопасности могут быть применены для систем разработчика, состоящих из большого количества компонентов. Для упомянутой системы модель с дискретными событиями представляет собой результирующий конечный автомат, который задан путем комбинации множества конечных автоматов, каждый из которых описывает отдельный компонент системы. Для каждого конечного автомата указывают множество их состояний и переходов между ними при возникновении определенных событий. Состояние результирующего конечного автомата определяют путем комбинации состояний конечных автоматов компонентов системы. При этом указанная комбинация осуществляется, например, путем синхронного или асинхронного произведения конечных автоматов. Для результирующего конечного автомата также задают список разрешенных переходов, список разрешенных состояний и список запрещенных состояний результирующего конечного автомата. Соответственно, с использованием политик безопасности проверяют переход упомянутых конечных автоматов компонентов системы и результирующего конечного автомата в начальное состояние, заданное в конфигурации (конфигурация включает, например, набор состояний и переходов) соответствующего конечного автомата, переход между состояниями при возникновении определенного события, нахождение соответствующего конечного автомата в одном из заданных состояний.
Фиг. 3б
300
Фиг. 3а
390
350
300
310
390
300
На  представлен шлюз  по , и обозначены возможные векторы компьютерных атак злоумышленника  из второй сети  на компоненты шлюза  и на первую сеть . Так, серой заливкой обозначены средства и модули, которые могут быть атакованы и скомпрометированы злоумышленником . Серыми стрелками обозначены векторы атак злоумышленника, при этом крестом обозначены векторы атак, которые будут невозможны при использовании шлюза  согласно заявленному изобретению.
390
351
350
390
353
354
350
390
300
310
350
300
300
353
353
350
351
353
120
121
353
350
Злоумышленник  может атаковать сервер-получатель данных  или сразу вторую сеть . После этого злоумышленник  может атаковать драйвер сетевой карты  и вторую систему ввода-вывода , которые обрабатывают все сетевые запросы из второй сети . При этом злоумышленник  может использовать различные уязвимости указанных компонентов, осуществлять DDoS-атаки, производить неавторизированный доступ и др. Стоит также отметить, что разграничение компонентов шлюза , относящихся к первой сети  и ко второй сети , позволяет также использовать политики безопасности для каждого компонента шлюза  для повышения общей безопасности шлюза . В частном примере реализации для драйвера второй сетевой карты  будут использованы политики безопасности, ограничивающие доступ драйвера второй сетевой карты  к устройствам второй сети , например, разрешающие только доступ к серверу-получателю данных . Даже в случае компрометации указанного драйвера второй сетевой карты  монитор безопасности  на основании политик безопасности из базы политик  не разрешит драйверу второй сетевой карты  получить доступ к другим устройствам второй сети .
354
390
355
390
316
315
317
331
390
300
355
315
331
300
355
350
300
390
355
300
Таким образом, получив доступ ко второй системе ввода-вывода , злоумышленник  продолжит компьютерную атаку на агента получателя . Однако злоумышленник  не сможет развить атаку на сервис обработки данных  и на агента источника , а также на процесс первой ВФС  и доверенную память . Злоумышленник  не сможет развить атаку ввиду того, что шлюз  находится в рабочем состоянии, в котором агенту получателя  запрещен доступ к агенту источника  и к доверенной памяти . Стоит также отметить, когда шлюз  только начинает работу и находится в защищенном состоянии, агент получателя  считается доверенным, и ему запрещен доступ во вторую сеть . Поэтому в защищенном состоянии шлюза  злоумышленник  не сможет скомпрометировать агента получателя  и развить компьютерную атаку на другие компоненты шлюза .
300
390
355
356
332
390
320
331
320
300
320
300
317
356
332
При этом в рабочем состоянии шлюза  злоумышленник , скомпрометировав агента получателя , сможет развить атаку на процесс второй ВФС  и на недоверенную память . Однако злоумышленник  не сможет скомпрометировать драйвер хранилища данных  и, соответственно, не сможет получить доступ к доверенной памяти . Защита драйвера хранилища данных  обеспечивается тем, что указанный драйвер считается доверенным компонентом шлюза  ввиду ограниченного функционала драйвера хранилища данных , который может быть проверен для исключения наличия ошибок и уязвимостей. Тем не менее, в частном варианте реализации шлюз  может содержать два драйвера хранилища данных, один из которых обеспечивает доступ процесса первой ВФС  к доверенной памяти, а второй драйвер обеспечивает доступ процесса второй ВФС  к недоверенной памяти .
390
300
310
300
311
315
311
300
300
300
Что касается возможных атак злоумышленника  непосредственно на шлюз  и на первую сеть , то такие атаки могут быть исключены представленной архитектурой шлюза . Источник данных  связан с агентом источника  по протоколу передачи данных, позволяющему производить авторизацию данных (например, OPC UA). Поэтому исключена передача данных от неавторизированного источника данных, отличного от источника данных . Кроме того, в том случае, когда шлюз  находится внутри защищенного периметра промышленной информационной системы, исключается возможность физической атаки (например, подключения неавторизированных устройств, таких как флеш карта, к шлюзу ) на компоненты шлюза .
315
355
330
331
332
300
450
460
Фиг. 4
411
412
Фиг. 4
450
460
450
460
315
355
411
412
331
332
300
400
Способ организации доступа агента источника  и агента получателя  к хранилищу данных  и, соответственно, к доверенной памяти , и к недоверенной памяти  может быть использован для решения проблемы защиты данных от несанкционированного доступа не только шлюза , но и других информационных систем. То есть для контроля доступа двух и более приложений  и  (см. ) к памяти, разделенной на две и более областей памяти (в частности, первая область памяти  и вторая область памяти  на ) и предназначенной для хранения данных упомянутых приложений , . При этом в частном варианте реализации в качестве упомянутых приложений ,  используются агент источника  и агент получателя , а в качестве областей памяти (первая область памяти  и вторая область памяти ) используются доверенная память  и недоверенная память . Поэтому частные варианты, описанные ранее применительно к шлюзу , также будут применимы и к системе .
Фиг. 4
400
20
Фиг. 6
21
411
412
35
400
100
Фиг. 1а-1в
120
400
411
412
330
330
330
330
27
411
450
412
460
Таким образом, на  представлен вариант системы контроля доступа к данным , являющейся компьютерным устройством (пример компьютера общего назначения  представлен на ), которое содержит аппаратный процессор  и по меньшей мере две разделенные области памяти , . В качестве операционной системы , установленной на компьютерной системе  может быть использована ОС , пример которой представлен на , включающая монитор безопасности , реализованный с возможностью исполнения на аппаратном процессоре системы . Первая область памяти  и вторая область памяти  могут быть разделены как на физическом уровне, например, в виде двух различных хранилищ данных , так и на программном уровне, например, в виде двух логических разделов одного хранилища данных , расположенных в различных диапазонах адресов хранилища данных . Второй вариант будет рассматриваться как предпочтительный. При этом хранилище данных  является машиночитаемым носителем данных, например, жестким диском  или флеш-памятью. Первая область памяти  предназначена для хранения данных первого приложения , а вторая область памяти  предназначена для хранения данных второго приложения .
400
450
460
317
356
120
Аппаратный процессор системы  выполнен с возможностью исполнения на нем первого приложения  и второго приложения , процессов первой виртуальной файловой системы  и процесса второй ВФС , а также монитора безопасности .
317
411
356
412
120
411
412
411
450
317
412
460
356
Процесс первой ВФС предназначен для организации доступа к первой области памяти , а процесс второй ВФС предназначен для организации доступа ко второй области памяти . При этом монитор безопасности  предназначен для контроля доступа к первой области памяти  и контроля доступа ко второй области памяти  при запросе доступа к данным по меньшей мере одним из приложений, где упомянутый доступ к первой области памяти  разрешен первому приложению  посредством процесса первой ВФС , а доступ ко второй области памяти  разрешен второму приложению  посредством процесса второй ВФС . Организация доступа заключается в обеспечении доступа приложений к соответствующей области памяти и её файловой системе, то есть в осуществлении операций ввода/вывода при доступе (на чтение/запись) к файлам в соответствующей области памяти.
400
320
411
412
411
317
412
356
В частном варианте реализации аппаратный процессор системы  дополнительно выполнен с возможностью реализации драйвера хранилища данных , посредством которого организован доступ к первой области памяти  и ко второй области памяти , то есть предназначенного для выполнения операций ввода/вывода к первой области памяти  по запросу от процесса первой ВФС  или ко второй области памяти  по запросу от процесса второй ВФС .
120
400
100
400
120
400
450
460
317
356
121
400
120
400
120
Фиг. 3а
320
400
411
412
320
411
412
400
400
411
412
400
Монитор безопасности  контролирует взаимодействия между программными компонентами системы , представленными в виде сервисов, приложений или процессов ОС , и реализованных с возможностью исполнения на аппаратном процессоре системы . То есть контроль доступа, осуществляемый монитором безопасности , заключается в разрешении или запрете доступа одного компонента системы  к другому компоненту из числа следующих: первого приложения , второго приложения , процесса первой ВФС , процесса второй ВФС , при этом разрешение или запрет определяется в соответствии с предварительно заданными политиками безопасности, содержащимися в базе политик . Стоит отметить, что политики безопасности могут быть заданы заранее администратором системы . Кроме того, политики безопасности могут быть заданы монитором безопасности  в процессе работы системы  (более подробно задание политик монитора безопасности  рассмотрено при описании ). Драйвер хранилища данных  также является компонентом системы . В другом частном варианте реализации в первой области памяти , а также во второй области памяти  может содержаться по экземпляру драйвера хранилища данных . В этом случае первая область памяти  и вторая область памяти  также будут являться компонентами системы , то есть содержать сервис, приложение или процесс, реализованные с возможностью исполнения на процессоре компьютерной системы . В то же время первая область памяти , а также вторая область памяти  располагаются на машиночитаемом носителе компьютерной системы  с возможностью хранения данных.
400
100
400
110
140
131
132
110
120
140
100
120
Фиг 1а-1в
Так как система использует защищенную ОС , то упомянутые компоненты системы взаимодействуют между собой посредством IPC, а также с ядром ОС  посредством программных интерфейсов путем обмена сообщениями (также сообщения межпроцессного взаимодействия, IPC-сообщения). При этом упомянутые интерфейсы, реализуемые процессами, статически описаны, а разрешенные взаимодействия между процессами заданы заранее. Отправка и получение сообщений процессами - происходят посредством системных вызовов ядра ОС . Монитор безопасности  осуществляет контроль упомянутых взаимодействий путем контроля доставки упомянутых сообщений . Подробнее о защищенной ОС  и контроле межпроцессных взаимодействий с использованием монитора безопасности  было описано ранее на .
Фиг. 3а,
121
Фиг. 4
Ранее, в описании к  были раскрыты политики безопасности из базы политик , которые также применимы к системе по .
В одном частном варианте реализации при контроле доступа используют политики безопасности на основе базовых операций, которые определяют следующие разрешения или запреты:
317
450
411
а) доступ к процессу первой ВФС разрешен первому приложению  (и, следовательно, разрешен доступ к первой области памяти );
356
460
412
б) доступ к процессу второй ВФС разрешен второму приложению  (и, следовательно, разрешен доступ ко второй области памяти );
460
317
450
356
в) иные доступы одного компонента к другому, не указанные в политиках безопасности, запрещены (например, второму приложению  запрещен доступ к процессу первой ВФС , а первому приложению  запрещен доступ к процессу второй ВФС ).
460
317
411
120
356
411
120
Таким образом, например, если второе приложение  запросит доступ к первой ВФС  и первой области памяти , монитор безопасности  запретит такое взаимодействие. В другом случае, если, например, вторая ВФС  была скомпрометирована и попытается получить доступ к первой области памяти , монитор безопасности  также запретит это взаимодействие, тем самым повысив уровень защиты данных от несанкционированного доступа.
411
460
317
460
460
317
411
460
В еще одном частном варианте реализации первая область памяти  дополнительно предназначена для хранения части данных второго приложения , при этом дополнительно задана политика безопасности, согласно которой доступ к процессу первой ВФС разрешен второму приложению . При этом могут быть дополнительно заданы политики безопасности (на основе конечного автомата или темпоральной логики), разрешающие доступ второго приложения  к процессу первой ВФС и соответственно к первой области памяти  при наступлении условий, определенных указанной политикой безопасности. Например, упомянутый доступ может быть разрешен однократно при запуске второго приложения , после чего доступ будет запрещен.
411
412
400
120
320
Стоит отметить, что настоящее изобретение не ограничивается использованием двух разделенных областей памяти  и . Система контроля доступа к данным  также применима при наличии трех и более разделенных областей памяти (на фигуре не указаны), предназначенных для хранения данных дополнительных приложений, соответствующих каждой дополнительной области памяти. Для каждой дополнительной области памяти будет создан соответствующий процесс дополнительной ВФС, предназначенный для организации доступа к упомянутой дополнительной области памяти. При этом монитор безопасности  также предназначен для контроля доступа к упомянутой дополнительной области памяти при запросе соответствующего доступа от дополнительного приложения посредством процесса ВФС. Соответственно доступ к дополнительной области памяти разрешен дополнительному приложению посредством процесса дополнительной ВФС. Кроме того, драйвер хранилища данных  также выполнен с возможностью организации доступа к упомянутой дополнительной области памяти, то есть предназначен для выполнения операций ввода/вывода к дополнительной области памяти по запросу от процесса дополнительной ВФС.
400
Фиг. 4
300
Фиг. 3а-3б
450
315
460
355
411
331
412
332
300
В других частных вариантах реализации система  по  может быть применена к шлюзу , описанному на  или к другой подобной ИС, в которой меняются правила доступа приложений к данным в зависимости от состояния ИС. В этом варианте реализации в качестве первого приложения  выступает агент источника , в качестве второго приложения  — агент получателя , в качестве первой области памяти  — доверенная память , а в качестве второй области памяти  — недоверенная память . Политики безопасности могут использовать конечный автомат с предварительно заданной таблицей переходов состояний конечного автомата. Ниже представлено описание конечного автомата secure_gateway2, который реализует контроль доступа к данным шлюза .
300
460
411
412
460
411
412
Конечный автомат secure_gateway2 может находиться в одном из следующих состояний: safe (безопасное состояние), work (рабочее состояние). Состояния конечного автомата secure_gateway2 соответствуют состояниям шлюза . Таблица переходов конечного автомата представлена в структуре transitions. При инициализации конечного автомата secure_gateway2, он находится в состоянии safe, указывающем для второго приложения  на разрешение доступа к первой области памяти  и на запрет доступа ко второй области памяти . Из состояния safe конечный автомат может перейти только в состояние work, указывающее для второго приложения  на запрет доступа к первой области памяти  и на разрешение доступа ко второй области памяти .
При этом из состояния work конечный автомат secure_gateway2 может перейти только в то же состояние work и не может вернуться в состояние safe.
121
460
Ниже представлены примеры политик безопасности в базе политик  для второго приложения (Second_app), использующие конечный автомат secure_gateway2.
460
411
Согласно описанной выше политике безопасности, второму приложению  разрешен доступ (метод Read) к первой области памяти  (Storage_one) при условии, что конечный автомат secure_gateway2 находится в состоянии safe.
460
412
Согласно данной политике безопасности, второму приложению запрещен доступ (методы Read и Write) ко второй области памяти  (Storage_two) при условии, что конечный автомат secure_gateway2 находится в состоянии safe.
120
144
120
Согласно данной политике безопасности, монитору безопасности  разрешено выполнить запрос безопасности  (security) на изменение состояния (метод confirm) конечного автомата secure_gateway2 на work. При этом изменение состояния конечного автомата также выполнит монитор безопасности  в случае, если указанное изменение состояния конечного автомата находится в соответствии с таблицей переходов конечного автомата.
460
412
Согласно данной политике безопасности, второму приложению  разрешен доступ (методы Read и Write) ко второй области памяти при условии, что конечный автомат secure_gateway2 находится в состоянии work.
460
411
121
120
121
460
411
Согласно данной политике безопасности, второму приложению запрещен доступ (методы Read и Write) к первой области памяти при условии, что конечный автомат secure_gateway2 находится в состоянии work. Стоит отметить, что эта политика безопасности может быть опциональной (то есть отсутствовать в базе политик ) в случае, если монитор безопасности  применяет политики безопасности по модели «по умолчанию запрещено» (англ. default deny). В этом случае, если в базе политик  отсутствует политика безопасности, разрешающая доступ второго приложения  к первой области памяти , когда конечный автомат находится в состоянии work, то такой доступ по умолчанию будет запрещен.
450
411
Согласно данной политике безопасности, первому приложению  разрешен доступ (методы Read и Write) к первой области памяти в обоих возможных состояниях конечного автомата secure_gateway2 — safe и work.
450
412
Согласно данной политике безопасности, первому приложению  запрещен доступ (методы Read и Write) ко второй области памяти в обоих возможных состояниях конечного автомата secure_gateway2 — safe и work.
400
460
411
460
120
411
412
Таким образом, заявленная система контроля доступа к данным  позволяет решить упомянутую техническую проблему, заключающуюся в низком уровне защиты данных от несанкционированного доступа (например, от доступа второго приложения  к первой области памяти , когда второму приложению  запрещен такой доступ). При этом за счет использования монитора безопасности  для контроля доступа к первой области памяти  и контроля доступа ко второй области памяти  достигается заявленный технический результат, а именно повышается уровень защиты данных от несанкционированного доступа.
Фиг. 5
510
400
450
460
317
356
120
520
411
412
450
460
411
317
356
530
540
120
411
412
411
450
317
412
460
356
Фиг. 1а-4
Фиг. 5
На  представлен вариант способа контроля доступа к данным. На шаге  исполняют на аппаратном процессоре компоненты системы  — первое приложение , второе приложение , процесс первой ВФС , процесс второй ВФС  и монитор безопасности . Далее на шаге  выполняется запрос доступа к первой области памяти  или ко второй области памяти  (например, от первого приложения  или от второго приложения ). При этом запрос доступа к первой области памяти  выполняется от процесса первой ВФС , а запрос доступа ко второй области памяти выполняется от процесса второй ВФС . Далее на шаге  или соответственно на шаге  с помощью монитора безопасности  осуществляют контроль доступа к первой области памяти  или соответственно ко второй области памяти  при запросе доступа к данным по меньшей мере одним из приложений. При этом доступ к первой области памяти  разрешен первому приложению  посредством процесса первой ВФС , а доступ ко второй области памяти  разрешен второму приложению  посредством второй ВФС . Частные варианты реализации, описанные ранее к  также применимы и к способу по .
Фиг. 6
20
21
22
23
21
23
24
25
26
20
24
представляет пример компьютерной системы общего назначения, персональный компьютер или сервер , содержащий центральный процессор , системную память  и системную шину , которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором . Системная шина  реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) , память с произвольным доступом (ОЗУ) . Основная система ввода/вывода (BIOS) , содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера , например, в момент загрузки операционной системы с использованием ПЗУ .
20
27
28
29
30
31
27
28
30
23
32
33
34
20
Персональный компьютер  в свою очередь содержит жесткий диск  для чтения и записи данных, привод магнитных дисков  для чтения и записи на сменные магнитные диски  и оптический привод  для чтения и записи на сменные оптические диски , такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск , привод магнитных дисков , оптический привод  соединены с системной шиной  через интерфейс жесткого диска , интерфейс магнитных дисков  и интерфейс оптического привода  соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера .
27
29
31
56
23
55
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск , сменный магнитный диск  и сменный оптический диск , но следует понимать, что возможно применение иных типов компьютерных носителей информации , которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине  через контроллер .
20
36
35
37
38
39
20
40
42
20
46
47
23
48
47
Компьютер  имеет файловую систему , где хранится записанная операционная система , а также дополнительные программные приложения , другие программные модули  и данные программ . Пользователь имеет возможность вводить команды и информацию в персональный компьютер  посредством устройств ввода (клавиатуры , манипулятора «мышь» ). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе  через последовательный порт , который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор  или иной тип устройства отображения также подсоединен к системной шине  через интерфейс, такой как видеоадаптер . В дополнение к монитору , персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
20
49
49
20
Фиг. 6
Персональный компьютер  способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами . Удаленный компьютер (или компьютеры)  являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера , представленного на . В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
50
20
50
51
20
54
54
23
46
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN)  и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях (также — информационных системах), внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер  подключен к локальной сети  через сетевой адаптер или сетевой интерфейс . При использовании сетей персональный компьютер  может использовать модем  или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем , который является внутренним или внешним устройством, подключен к системной шине  посредством последовательного порта . Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В соответствии с описанием, компоненты, этапы исполнения, структура данных, описанные выше, могут быть выполнены, используя различные типы операционных систем, компьютерных платформ, программ.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.