Сетевая безопасность

Обеспечение сетевой автономности и безопасности

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

  1. Бесперебойная работа:
    Система функционирует непрерывно даже при отсутствии доступа к внешним ресурсам;

  2. Локальное управление лицензиями:
    Реализованы механизмы локального хранения данных и управления лицензиями, позволяя системе функционировать при отсутствии Интернета;

  3. Защита от сетевых атак:
    Различные меры безопасности, включая ограничение доступа и шифрование данных;

  4. Локальное кэширование:
    Обеспечивается доступ к данным при отсутствии связи;

  5. Мониторинг и аудит:
    Предоставляются средства для контроля безопасности и работы в режиме автономности.

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

Краткое описание http запроса через прокси

Для доступа к ресурсу, находящемуся за прокси сервером с паролем, необходимо в uri обратиться к недоступному ресурсу (например http://unreachable.com) и указать параметры подключения к прокси серверу (proxyAuthHost,proxyAuthPort,proxyAuthUsername,proxyAuthPassword).

Пример:
<to uri="http://unreachable.com?proxyAuthHost=squid.mydomain.local&proxyAuthPort=3128&proxyAuthUsername=testuser&proxyAuthPassword=JkeprJuT"/>

Гальваническая развязка

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

dmz public

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

Для реализации этого механизма безопасного обмена данными мы использовали брокер сообщений Apache Kafka совместно с Apache Camel, запущенном на Apache Karaf.
Это решение может быть адаптировано для использования различных брокеров сообщений, включая JMS (AMQP), такие, как Active MQ или Rabbit MQ, а также потоковые, например, Kafka и Nats.

Для пользователя это всё выглядит как синхронное взаимодействие, хотя под капотом живёт полный асинхрон.

Используемый сценарий:

  1. На Apache Camel создан REST-сервис, ответственный за обработку входящих HTTP-запросов.

  2. HTTP-запросы отправляются в топик Kafka ('in') для временного хранения сообщений в DMZ. При этом важно - HTTP соединение остаётся в режиме ожидания ответа!

  3. Система-потребитель топика 'in' осуществляет чтение сообщений и выполняет необходимые манипуляции внутри системы.

  4. После завершения обработки, ответы отправляются в выходной топик Kafka ('out'). Важно отметить, что входные и выходные сообщения имеют одинаковое свойство, по которому их можно сопоставить.

  5. После получения сообщения формируется ответ для пользователя на основании входящего HTTP сообщения и ответа из топика out.

  6. При обнаружении соответствия происходит формирование JSON-ответа для HTTP, который отправляется пользователю.

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