Сетевой шлюз и способ передачи данных из первой сети во вторую сеть Российский патент 2022 года по МПК H04W68/00 

В последнее время применение цифровых сервисов в промышленном Интернете вещей (англ. Industrial Internet of Things, IIoT) становится все более актуальным. Такие цифровые сервисы установлены на удаленном сервере и предназначены для обработки и анализа данных, получаемых от устройств (оборудования) информационной системы (далее - ИС) на базе Интернета вещей (англ. Internet of Things, IoT). Данные от устройств ИС, таких как датчики и сенсоры (англ. sensors), исполнительные механизмы (англ. actuators), передают на удаленный сервер посредством сетевого шлюза (англ. gateway).

Именно на сетевой шлюз (далее - шлюз) возлагается задача обеспечения надежного и безопасного подключения устройств ИС к удаленному серверу. Устройства ИС взаимодействуют с сервером через шлюз, поэтому можно говорить, что устройства ИС размещены во внутренней сети по отношению к серверу, который в свою очередь размещен во внешней сети, и взаимодействие производится между ними через шлюз. В первую очередь проблема заключается в защите внутренней сети ИС от компьютерных атак из внешней сети. Наиболее уязвимыми являются компоненты удаленного сервера, т.к. он подключен к внешней сети, например, сети Интернет. Так, удаленный сервер подвержен целому спектру компьютерных атак, таких как: атака MITC (англ. Man in the cloud - атака, построенная на краже уникальных токенов, которые генерируются при первом использовании сервиса и для удобства хранятся на пользовательской машине); атака с использованием ошибок и уязвимостей в коде и архитектуре удаленного сервера, а также установленных сервисов; атака путем переполнения буфера; атака, реализуемая с помощью SQL-инъекции в базы данных; атака, связанная с повышением уровня привилегий; атака с использованием уязвимых каналов связи; DDoS-атака; атака, связанная с нарушением целостности данных; атака, связанная с подменой сертификатов; фишинговая атака; атака, направленная на подбор паролей или сброс пароля для получения неавторизированного доступа; атака с использованием социальной инженерии; атака, связанная с установкой вредоносного программного обеспечения (далее - ПО); атака с использованием уязвимостей; атака, связанная с установкой небезопасных приложений и др. Осуществив компьютерную атаку на удаленный сервер, злоумышленник может продолжить компьютерную атаку на шлюз и получить доступ ко внутренней сети ИС, что в свою очередь может повлечь неавторизированный доступ к данным устройств ИС и даже вывод из строя устройств ИС и самой ИС. Стоит отметить, что атака на удаленный сервер может быть осуществлена как извне, так и изнутри, например, путем физического доступа к серверу.

Другим вектором компьютерной атаки во внутреннюю сеть ИС является атака на канал связи между шлюзом и удаленным сервером, то есть на внешнюю сеть. Злоумышленник может осуществить такую атаку, например, путем поиска устройств по открытым портам, поиска уязвимостей устройств, взлома канала связи, атакой типа «человек посредине» (англ. man-in-the-middle), путем получения неавторизированного доступа к приложениям устройства.

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

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

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

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

Первый технический результат заключается в реализации однонаправленной передачи данных из первой сети во вторую сеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На Фиг. 3а представлен шлюз для передачи данных из первой сети во вторую сеть.

На Фиг. 3б представлен шлюз по Фиг. 3а и обозначены возможные векторы компьютерных атак злоумышленника из второй сети на компоненты шлюза и на первую сеть.

На Фиг. 4 представлен способ передачи данных из первой сети во вторую.

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

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

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

Глоссарий

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

Агент получателя 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 под контролем монитора безопасности 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:

policy object secure_gateway = finite_state_machine {

states : [Safe, Work],

initial : Safe,

transitions : {

Safe : [Work],

Work : [Work],

}

}

Конечный автомат 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.

request src=Agent_dst,

dst=Safe_storage,

method=Read {

secure_gateway.allow [Safe];

}

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

request src=Agent_dst,

dst=IO_ext,

method=Access {

secure_gateway.deny [Safe];

}

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

request src=Agent_dst,

dst=Unsafe_storage,

method=Read {

secure_gateway.deny [Safe];

}

method=Write {

secure_gateway.deny [Safe];

}

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

security src=Secure_monitor, method=Confirm {

secure_gateway.enter [Work];

}

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

request src=Agent_dst,

dst=Unsafe_storage,

method=Read {

secure_gateway.allow [Work];

}

method=Write {

secure_gateway.allow [Work];

}

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

request src=Agent_dst,

dst=Safe_storage,

method=Read {

secure_gateway.deny [Work];

}

method=Write {

secure_gateway.deny [Work];

}

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

request src=Agent_dst,

dst=Agent_src,

method=Receive {

secure_gateway.allow [Work];

}

method=Transfer {

secure_gateway.deny [Work];

}

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

request src=Agent_dst,

dst=IO_ext,

method=Access {

secure_gateway.allow [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:

policy object integrity =

Mandatory_integrity_control {

Config {

levels : [“LOW”, “MEDIUM”, “HIGH”]

}

}

В конфигурации объекта политик 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 в виде следующей конструкции:

policy object tl_checker = TL {

config “G (data_transfer => P read_safe)”

}

Стоит отметить, что возможны и другие формулировки свойства 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.

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

На Фиг. 4 представлен способ передачи данных из первой сети во вторую.

На шаге 410 с помощью монитора безопасности 120 устанавливают состояние шлюза 300 в защищенное и на шаге 420 предоставляют доступ к доверенной памяти 331 по запросу от агента получателя 355. В частном варианте реализации проверяют условие выполнения политик безопасности из базы политик 121. Далее, на шаге 430 с помощью агента получателя 355 выполняют настройка агента получателя 355 на основании параметров агента получателя 355 из доверенной памяти 331, в частности параметров авторизации для передачи данных во вторую сеть 350. После настройки агента получателя 355 на шаге 440 с помощью монитора безопасности 120 изменяют состояние шлюза 300 на рабочее.

В итоге на шаге 450 осуществляют передачу данных из первой сети 310 от источника данных 311 во вторую сеть 350 серверу-получателю данных 351 через агента источника 315 агенту получателя 355. При этом упомянутая передача данных осуществляется под контролем монитора безопасности 120 при выполнении политик безопасности из базы политик 121 и с учетом результатов настройки агента получателя 355. При этом агент получателя 355 использует недоверенную память 332 для осуществления упомянутой передачи данных, а недоверенная память 332 включает служебную информацию агента получателя 355. Стоит отметить, что частные варианты реализации, описанные ранее к шлюзу 300 на Фиг 3а также применимы к способу передачи данных из первой сети во вторую, представленному на Фиг. 4.

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

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

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

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

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

1. Реализуемый сетевым шлюзом (далее - шлюз) способ передачи данных из первой сети во вторую сеть, в котором:

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

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

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

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

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

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

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

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

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

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

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

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

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

11. Способ по п. 8, в котором политики безопасности используют темпоральную логику.

12. Сетевой шлюз для передачи данных из первой сети во вторую сеть, содержащий:

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

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

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

• монитора безопасности, предназначенного для:

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

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

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

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

• упомянутого агента источника, предназначенного для:

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

- передачи полученных данных агенту получателя.

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

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

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

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

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

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

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

20. Сетевой шлюз по п. 17, в котором используют политики безопасности на основе темпоральной логики.

21. Сетевой шлюз по п. 17, дополнительно содержащий следующие компоненты:

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

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

в) драйвер хранилища данных, предназначенный для выполнения операций ввода-вывода при доступе к доверенной памяти посредством первой ВФС, а также при доступе к недоверенной памяти посредством второй ВФС;

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

22. Сетевой шлюз по п. 17, дополнительно содержащий:

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

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

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

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

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

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

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