Система и способ контроля доступа к данным

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

 

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

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

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

В последнее время применение цифровых сервисов в промышленном Интернете вещей (англ. 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 (также сообщения межпроцессного взаимодействия, IPC-сообщения, на Фиг. 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. При этом упомянутые интерфейсы, реализуемые процессами, представляют собой структуры данных с объявленными в них методами, реализующими функционал соответствующего процесса.

Упомянутые интерфейсы статически описаны, а разрешенные взаимодействия между процессами заданы заранее.

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

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

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

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

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

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

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

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

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

Согласно заявленному изобретению, монитор безопасности 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 является MindSphere Agent, если сервер-получатель данных 351 является облачным сервером на базе платформы Siemens MindSphere.

Агент источника 315 предназначен для получения упомянутых данных из первой сети 310 от источника данных 311, например, по промышленному протоколу связи OPC UA. Кроме того, монитор безопасности 120 предназначен для предоставления доступа к доверенной памяти 331 по запросу от агента получателя 355 при условии выполнения политик безопасности из базы политик 121. Агент источника 315 может использовать для своей работы доверенную память 331, например, служебную информацию агента источника 315, буфер для хранения данных, полученных от источника данных 311.

Агент получателя 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 могут быть любыми известными из уровня техники сетевыми картами (также — сетевая плата, сетевой адаптер, англ. network interface controller), которые являются устройствами для взаимодействия шлюза 300 с другими устройствами первой сети 310 или второй сети 350 соответственно. Примерами таких сетевых карт являются 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 могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL конечный автомат задан классом политик finite_state_machine. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в ОС 100, которые могут быть реализованы путем обмена сообщений 140 между процессами, соответствующими компонентам шлюза 300. При каждой попытке взаимодействия, то есть при проверке монитором безопасности 120 сообщений 140, монитор безопасности 120 исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения 140). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.

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

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

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

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

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

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

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

Ниже представлено описание конечного автомата secure_gateway:

Конечный автомат secure_gateway может находиться в одном из следующих состояний: safe (безопасное состояние), work (рабочее состояние). Состояния конечного автомата secure_gateway соответствуют состояниям шлюза. Таблица переходов конечного автомата представлена в структуре transitions. При инициализации конечного автомата secure_gateway, он находится в состоянии safe, указывающем для агента получателя 355 на разрешение доступа к доверенной памяти 331 и на запрет доступа ко второй сети 350 и к недоверенной памяти 332. Из состояния safe конечный автомат может перейти только в состояние work, указывающее для агента получателя 355 на запрет доступа к доверенной памяти 331 и на разрешение доступа ко второй сети 350 и к недоверенной памяти 332, а также указывающее на разрешение передачи данных от агента источника 315 агенту получателя 355 и на запрет передачи данных от агента получателя 355 агенту источника 315.

При этом из состояния work конечный автомат secure_gateway может перейти только в то же состояние work и не может вернуться в состояние safe.

Ниже представлены примеры политик безопасности в базе политик 121 для агента получателя 355 (Agent_dst), использующих конечный автомат secure_gateway.

Согласно описанной выше политике безопасности, агенту получателя 355 разрешен доступ (метод Read) к доверенной памяти 331 (Safe_storage) при условии, что конечный автомат secure_gateway находится в состоянии safe.

Согласно данной политике безопасности, агенту получателя 355 (Agent_dst) запрещен доступ (метод Access) ко второй сети 350, например, посредством второй системы ввода-вывода 354 (IO_ext) при условии, что конечный автомат secure_gateway находится в состоянии safe.

Согласно данной политике безопасности, агенту получателя 355 запрещен доступ (методы Read и Write) к недоверенной памяти 332 (Unsafe_storage) при условии, что конечный автомат secure_gateway находится в состоянии safe.

Согласно данной политике безопасности, монитору безопасности 120 разрешено выполнить запрос безопасности 144 (security) на изменение состояния (метод confirm) конечного автомата secure_gateway на work. При этом изменение состояния конечного автомата также выполнит монитор безопасности 120 в случае, если указанное изменение состояния конечного автомата находится в соответствии с таблицей переходов конечного автомата.

Согласно данной политике безопасности, агенту получателя 355 разрешен доступ (методы Read и Write) к недоверенной памяти 332 при условии, что конечный автомат secure_gateway находится в состоянии work.

Согласно данной политике безопасности, агенту получателя 355 запрещен доступ (методы Read и Write) к доверенной памяти 331 при условии, что конечный автомат secure_gateway находится в состоянии work. Стоит отметить, что эта политика безопасности может быть опциональной (то есть отсутствовать в базе политик 121) в случае, если монитор безопасности 120 применяет политики безопасности по модели «по умолчанию запрещено» (англ. default deny). В этом случае, если в базе политик 121 отсутствует политика безопасности, разрешающая доступ агента получателя 355 к доверенной памяти 331, когда конечный автомат находится в состоянии work, то такой доступ по умолчанию будет запрещен.

Согласно данной политике безопасности, агенту получателя 355 разрешено получение данных (метод Receive) от агента источника 315 (Agent_src) и запрещена передача данных (метод Transfer) агенту источника 315 при условии, что конечный автомат secure_gateway находится в состоянии work.

Согласно данной политике безопасности, агенту получателя 355 разрешен доступ (метод Access) ко второй сети 350, например, посредством второй системы ввода-вывода 354 при условии, что конечный автомат secure_gateway находится в состоянии work.

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

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

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

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

В еще одном частном варианте реализации политики безопасности используют темпоральную логику. Для задания политик безопасности на основе темпоральной логики формулируют свойства (требования) безопасности с помощью формулы темпоральной логики и с использованием темпоральных операторов. С использованием монитора безопасности 120 компонентам шлюза 300 ставят в соответствие события их состояния из заранее определенного множества событий. Для шлюза 300 множество событий может включать следующие: {read_safe, data_transfer}, где read_safe — событие доступа агента получателя 355 к доверенной памяти 331, data_transfer — событие передачи данных из первой сети 310 во вторую сеть 350 через агент источника 315 агенту получателя 355. Свойство безопасности формулируют, например, описанным ниже образом.

Свойство 1. Всегда, когда агент получателя 355 получает доступ к доверенной памяти 331 в защищенном состоянии шлюза 300, должно быть гарантировано, что после перехода в рабочее состояние шлюза 300 агент получателя 355 не должен иметь возможности считать данные из доверенной памяти 331. Также должно быть гарантировано, что доступ агента получателя 355 к недоверенной памяти 332 и ко внешней сети 350 возможен только в том случае, если ранее был осуществлен доступ агента получателя 355 к доверенной памяти 331, то есть наступило событие read_safe. Кроме того, при наступлении события read_safe гарантируется разрешение на передачу данных от агента источника 315 агенту получателя 355 и запрет передачи данных от агента получателя 355 агенту источника 315. Указанное свойство можно записать в виде формулы:

G (data_transfer => P read_safe),

где G — темпоральный оператор «всегда в будущем», P — темпоральный оператор «хотя бы один раз в прошлом».

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

Стоит отметить, что возможны и другие формулировки свойства 1, например, оно может быть задано следующим образом: передача данных не осуществляется, пока агент получателя 355 не получил доступ к доверенной памяти 331 (то есть состояние шлюза 300 не переведено из защищенного в рабочее):

! 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 может использовать различные уязвимости указанных компонентов, осуществлять DDoS-атаки, производить неавторизированный доступ и др. Стоит также отметить, что разграничение компонентов шлюза 300, относящихся к первой сети 310 и ко второй сети 350, позволяет также использовать политики безопасности для каждого компонента шлюза 300 для повышения общей безопасности шлюза 300. В частном примере реализации для драйвера второй сетевой карты 353 будут использованы политики безопасности, ограничивающие доступ драйвера второй сетевой карты 353 к устройствам второй сети 350, например, разрешающие только доступ к серверу-получателю данных 351. Даже в случае компрометации указанного драйвера второй сетевой карты 353 монитор безопасности 120 на основании политик безопасности из базы политик 121 не разрешит драйверу второй сетевой карты 353 получить доступ к другим устройствам второй сети 350.

Таким образом, получив доступ ко второй системе ввода-вывода 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 по протоколу передачи данных, позволяющему производить авторизацию данных (например, OPC UA). Поэтому исключена передача данных от неавторизированного источника данных, отличного от источника данных 311. Кроме того, в том случае, когда шлюз 300 находится внутри защищенного периметра промышленной информационной системы, исключается возможность физической атаки (например, подключения неавторизированных устройств, таких как флеш карта, к шлюзу 300) на компоненты шлюза 300.

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

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

Конечный автомат secure_gateway2 может находиться в одном из следующих состояний: safe (безопасное состояние), work (рабочее состояние). Состояния конечного автомата secure_gateway2 соответствуют состояниям шлюза 300. Таблица переходов конечного автомата представлена в структуре transitions. При инициализации конечного автомата secure_gateway2, он находится в состоянии safe, указывающем для второго приложения 460 на разрешение доступа к первой области памяти 411 и на запрет доступа ко второй области памяти 412. Из состояния safe конечный автомат может перейти только в состояние work, указывающее для второго приложения 460 на запрет доступа к первой области памяти 411 и на разрешение доступа ко второй области памяти 412.

При этом из состояния work конечный автомат secure_gateway2 может перейти только в то же состояние work и не может вернуться в состояние safe.

Ниже представлены примеры политик безопасности в базе политик 121 для второго приложения 460 (Second_app), использующие конечный автомат secure_gateway2.

Согласно описанной выше политике безопасности, второму приложению 460 разрешен доступ (метод Read) к первой области памяти 411 (Storage_one) при условии, что конечный автомат secure_gateway2 находится в состоянии safe.

Согласно данной политике безопасности, второму приложению 460 запрещен доступ (методы Read и Write) ко второй области памяти 412 (Storage_two) при условии, что конечный автомат secure_gateway2 находится в состоянии safe.

Согласно данной политике безопасности, монитору безопасности 120 разрешено выполнить запрос безопасности 144 (security) на изменение состояния (метод confirm) конечного автомата secure_gateway2 на work. При этом изменение состояния конечного автомата также выполнит монитор безопасности 120 в случае, если указанное изменение состояния конечного автомата находится в соответствии с таблицей переходов конечного автомата.

Согласно данной политике безопасности, второму приложению 460 разрешен доступ (методы Read и Write) ко второй области памяти 412 при условии, что конечный автомат secure_gateway2 находится в состоянии work.

Согласно данной политике безопасности, второму приложению 460 запрещен доступ (методы Read и Write) к первой области памяти 411 при условии, что конечный автомат secure_gateway2 находится в состоянии work. Стоит отметить, что эта политика безопасности может быть опциональной (то есть отсутствовать в базе политик 121) в случае, если монитор безопасности 120 применяет политики безопасности по модели «по умолчанию запрещено» (англ. default deny). В этом случае, если в базе политик 121 отсутствует политика безопасности, разрешающая доступ второго приложения 460 к первой области памяти 411, когда конечный автомат находится в состоянии work, то такой доступ по умолчанию будет запрещен.

Согласно данной политике безопасности, первому приложению 450 разрешен доступ (методы Read и Write) к первой области памяти 411 в обоих возможных состояниях конечного автомата secure_gateway2 — safe и work.

Согласно данной политике безопасности, первому приложению 450 запрещен доступ (методы Read и Write) ко второй области памяти 412 в обоих возможных состояниях конечного автомата 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. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

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

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

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

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

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

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

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

1. Система контроля доступа к данным, содержащая:

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

б) аппаратный процессор, выполненный с возможностью исполнения:

по меньшей мере первого приложения и второго приложения;

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

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

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

3. Система по п. 1, в которой первая область памяти и вторая область памяти разделены на физическом уровне или на программном уровне.

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

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

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

а) доступ к процессу первой ВФС разрешен первому приложению;

б) доступ к процессу второй ВФС разрешен второму приложению;

в) иные доступы одного компонента к другому, не указанные в политиках безопасности, запрещены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

контроль доступа по меньшей мере к первой области памяти, при этом доступ к первой области памяти разрешен первому приложению посредством процесса первой ВФС;

контроль доступа ко второй области памяти, при этом доступ ко второй области памяти разрешен второму приложению посредством процесса второй ВФС.

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

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

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

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

14. Способ по п. 13, в котором для контроля доступа используют политики безопасности, определяющие следующие разрешения или запреты:

а) доступ к процессу первой ВФС разрешен первому приложению;

б) доступ к процессу второй ВФС разрешен второму приложению;

в) иные доступы одного компонента к другому, не указанные в политиках безопасности, запрещены.

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

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

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

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

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

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

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

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

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

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

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