Orion soft обновила Nova SE для защищенных систем: эксперты назвали риски внедрения контейнерных платформ

46 минут назад

© Сгенерировано ИИ

Orion soft выпустила Nova Special Edition 1.2.0 с интеграцией сканера уязвимостей с БДУ ФСТЭК и дополнительными средствами управления межсервисным трафиком. Разработчик заявляет возможность применения платформы на значимых объектах КИИ первой категории и в АСУ ТП класса К1. Эксперты «Группы Астра» и «Лаборатории Касперского» рассказали RUБЕЖ, какие проверки необходимы при внедрении контейнерной инфраструктуры и почему ошибки в настройках защиты могут нарушить работу производства.

Обновление сертифицированной редакции Kubernetes-платформы Nova Container Platform представлено 12 октября. Как сообщает Orion soft, встроенный сканер теперь использует сведения Банка данных угроз безопасности информации ФСТЭК России.

В Nova SE добавлен Service Mesh на базе Istio, который позволяет управлять трафиком между микросервисами и применять политики безопасности на уровне приложений. Также появились поддержка сетевого плагина Cilium CNI и обновленного отказоустойчивого хранилища Longhorn. Вендор улучшил интеграцию с системой управления секретами StarVault и расширил поддержку версий российских операционных систем.

Применение на объектах КИИ и в промышленности

По информации Orion soft, Nova SE 1.2.0 соответствует четвертому уровню доверия по требованиям приказа ФСТЭК № 76 и четвертому классу защиты по требованиям приказа № 118. Разработчик заявляет возможность использования платформы на значимых объектах КИИ первой категории, в ГИС первого класса защищенности, АСУ ТП класса К1 и системах обработки персональных данных первого уровня защищенности.

Лидер продукта Nova Container Platform Владимир Болвачев связывает выпуск обновления с расширением набора сертифицированных функций для заказчиков с защищенными контурами.

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

Антивирусные проверки не должны мешать работе кластера

Основные проблемы на стыке операционной системы, Kubernetes и средств информационной безопасности возникают на уровне ядра, сети и дисковой подсистемы, отмечает Андрей Диденко, системный архитектор платформы «Боцман», входящей в «Группу Астра».

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

«Платформа должна разворачиваться и обновляться без доступа в интернет», отмечает Андрей Диденко.

Для защищенной инфраструктуры Диденко также считает критичной работу в полностью изолированном контуре. Платформа должна разворачиваться и обновляться без доступа в интернет, а события аудита передавать в корпоративную SIEM. Это позволяет службе ИБ анализировать происходящее в контейнерной среде вместе с событиями из других систем предприятия.

Безопасность образа начинается с проверки происхождения

Проверку контейнерного образа следует начинать с установления его источника, считает Алексей Рыбалко, старший инженер отдела поддержки продаж «Лаборатории Касперского». Для промышленного контура он предлагает использовать собственный реестр, через который на узлы поступают базовые образы, программные компоненты поставщиков АСУ ТП и сборки подрядчиков.

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

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

Подобные механизмы востребованы и за пределами промышленности. Ранее RUБЕЖ рассказывал о внедрении Kaspersky Container Security в НПФ «БУДУЩЕЕ». В проект вошли аудит поставляемого ПО, обязательная проверка образов перед запуском и постоянный контроль контейнеров в процессе работы.

После запуска приложения появляются новые риски

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

«Сканер видит образ как архив в момент проверки. Всё, что происходит после запуска, для него невидимо», поясняет Рыбалко.

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

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

Блокирующие политики нужно проверять на редких штатных операциях

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

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

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