Рассмотрим требования к безопасности информации в средствах контейнеризации, указанные в Выписке из Приказа ФСТЭК России №118 «Требования по безопасности информации к средствам контейнеризации», приведем разъяснения к каждому требованию. Также в статье проанализируем техническую реализацию требований Приказа ФСТЭК России №118 на примере ОС Astra Linux Special Edition и программные механизмы реализации в среде ОС.

Навигация по статье

1. Технология контейнеризации

2. Обзор Приказа ФСТЭК России №118 «Об утверждении требований по безопасности информации к средствам контейнеризации»

3. Реализация требований Приказа ФСТЭК России №118 «Об утверждении требований по безопасности информации к средствам контейнеризации» для защиты контейнеров на примере ОС Astra Linux Special Edition

   3.1. Изоляция контейнеров

   3.2. Выявление уязвимостей в образах контейнеров

   3.3. Проверка корректности конфигурации контейнеров

   3.4. Контроль целостности контейнеров и их образов

   3.5. Регистрация событий безопасности

   3.6. Идентификация и аутентификация пользователей

4. Заключение

1. Технология контейнеризации

Контейнеризация — это метод виртуализации, при котором ядро операционной системы (ОС) поддерживает несколько изолированных экземпляров пространства пользователя вместо одного. Эти экземпляры с точки зрения выполняемых в них процессов, идентичны отдельному экземпляру ОС. Сами контейнеры — это и есть упомянутые изолированные экземпляры. В контейнер можно поместить различные среды, сервисы, части приложений.

В настоящий момент достаточно популярна микросервисная архитектура приложений, которая является основным практическим применением технологии контейнеризации. На рисунке 1 представлена диаграмма популярности запускаемых в контейнерах технологий среди мировых IT‑компаний на 2023 год по итогам опроса DZone Kubernetes in the Enterprise Survey.

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

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

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

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

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

В реализации качественного обеспечения безопасности помогает набор формализованных требований безопасности, рекомендуемый или обязательный к выполнению. Выполнение такого набора требований позволяет однозначно определить уровень защищенности реализованного решения. Набор требований безопасности для средств контейнеризации представлен в Приказе ФСТЭК России № 118 «Об утверждении требований по безопасности информации к средствам контейнеризации». В нем описан ряд обязательных требований к безопасности информации в средствах контейнеризации и несколько дополнительных требований, включая требование к централизованному управлению образами контейнеров и контейнерами.

2. Обзор Приказа ФСТЭК России №118 «Об утверждении требований по безопасности информации к средствам контейнеризации»

Гарантией обеспечения безопасности системы с внедренным средством контейнеризации может стать сертификат ФСТЭК России, подтверждающий соответствие системы требованиям Приказа ФСТЭК России № 118. Для успешного прохождения сертификации и получения такого сертификата необходимо реализовать выполнение требований в системе программными средствами.

Требования приказа ФСТЭК России № 118 распространяются на средства контейнеризации, которые создают образы, формируют среду выполнения контейнеров и обеспечивают выполнение их процессов, запускают контейнеры и управляют ими, централизованно управляют контейнерами, организуют взаимодействие между ними, а также распространяют образы контейнеров. Для разграничения требований безопасности к средствам контейнеризации выделяется шесть классов защиты. Первый класс — самый высокий, шестой — самый низкий.

Обобщенный перечень технологий, к которым предъявляются требования приказа ФСТЭК России № 118, представлен в пункте 5 Выписки из упомянутого приказа «Требования по безопасности информации к средствам контейнеризации». Так, обязательные требования по безопасности информации предъявляются к:

• уровню доверия средства контейнеризации,

• хостовой операционной системе, в среде которой функционирует средство контейнеризации,

• составу функций безопасности средства контейнеризации,

• изоляции контейнеров средством контейнеризации,

• выявлению уязвимостей в образах контейнеров,

• проверке корректности конфигурации контейнеров,

• контролю целостности контейнеров и их образов в средстве контейнеризации,

• регистрации событий безопасности в средстве контейнеризации.

Дополнительные требования по безопасности информации предъявляются к:

• управлению доступом в средстве контейнеризации,

• идентификации и аутентификации пользователей в средстве контейнеризации,

• централизованному управлению образами контейнеров и контейнерами в средстве контейнеризации.

Между классами защиты средств контейнеризации и уровнями доверия установлено прямое соответствие. Уровень доверия в информационной безопасности — это понятие, определенное в приказе ФСТЭК России № 131 как основа дифференциации средств защиты информации.

Хостовая операционная система, в среде которой функционирует средство контейнеризации, также должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным Приказом ФСТЭК России от 19 августа 2016 г. № 119 <…>, и Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным Приказом ФСТЭК России от 2 июня 2020 г. № 76.

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

Эти требования подробно описаны в Выписке из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации» в пунктах 9 — 9.2, 10 — 10.2, 11, 12 — 12.3, 13 — 13.3, 14 — 14.3, 15 — 15.3, 16 — 16.2. Каждый раздел описывает необходимые условия для выполнения соответствующих требований.

На сегодняшний день есть ряд отечественных ОС, сертифицированных по Приказу ФСТЭК России № 118. К ним относятся: Ред ОС, Альт СП релиз 10, Astra Linux Special Edition.

Далее рассмотрим возможность технической реализации выполнения требований Приказа ФСЭК России № 118 «Об утверждении требований по безопасности информации к средствам контейнеризации» на примере ОС Astra Linux Special Edition.

3. Реализация требований Приказа ФСТЭК России №118 «Об утверждении требований по безопасности информации к средствам контейнеризации» для защиты контейнеров на примере ОС Astra Linux Special Edition

В ОС Astra Linux реализованы меры защиты информации контейнеров различными средствами ОС. На примере внедренных в Astra Linux средств рассмотрим реализацию требований защиты информации по Приказу ФСТЭК России № 118.

Требования раздела 7 Выписки из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации» к сертификации хостовой операционной системы, в среде которой функционирует средство контейнеризации выполняется, так как ОС Astra Linux Special Edition сертифицирована на соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) по первому уровню доверия, на соответствие «Требованиям безопасности информации к операционным системам» (ФСТЭК России, 2016) и документу «Профиль защиты операционных систем типа А первого касса защиты. ИТ.ОС.А1.ПЗ». Таким образом, ОС Astra Linux Special Edition является ОС, сертифицированной для первого класса защиты, что включает соответствие более низким классам защиты — четвертому, пятому и шестому.

Далее декларируются требования к реализации функций безопасности в средстве контейнеризации.

3.1 Изоляция контейнеров

В 9 разделе описана первая функция — изоляция контейнеров. Требование реализовано средствами LXC.

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

Изоляция доступа контейнеров к ресурсам аппаратной платформы достигается путем применения механизма групп управления control groups (cgroups), используемого для ограничения в ресурсах группы процессов, выполняющихся в контейнере, а также для ограничения других групп, например групп процессов, принадлежащих какой‑либо службе или пользовательскому сеансу.

Механизм cgroups (control group) — это механизм ядра ОС, который ограничивает и изолирует вычислительные ресурсы (процессорные, сетевые, ресурсы памяти, ресурсы ввода‑вывода) для групп процессов. В нем реализован механизм изоляции: разделение пространств имен для групп таким образом, что одной группе недоступны процессы, сетевые соединения и файлы другой — является технической мерой изоляции контейнеров.

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

Таким образом, требования раздела 9 в ОС Astra Linux Special Edition можно считать реализованными для любого класса защиты с шестого по четвертый.

3.2 Выявление уязвимостей в образах контейнеров

Далее в разделе 10 выдвигаются требования к выявлению уязвимостей в образах контейнеров. В ОС Astra Linux Special Edition выявление известных уязвимостей образа контейнера осуществляется средствами OpenSCAP и oscap‑docker из состава ОС на основе сведений, содержащихся в банке данных угроз безопасности информации, ведение которого осуществляется ФСТЭК России. Информация о выявленных уязвимостях отображается в журнале в формате HTML, сгенерированном OpenSCAP по результатам сканирования. При обнаружении уязвимостей дальнейшее использование образа контейнера запрещается. Проверка образов контейнеров на наличие известных уязвимостей выполняется не реже одного раза в неделю.

Благодаря наличию приведенных механизмов ОС Astra Linux Special Edition выполняет требования из раздела 10 Выписки из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации» для любого класса защиты с шестого по четвертый.

3.3 Проверка корректности конфигурации контейнеров

Раздел 11 определяет требования к средствам контейнеризации к проверке корректности конфигурации контейнеров. Обеспечение корректности конфигурации контейнеров, в том числе ограничение прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, вычислительных ресурсов хостовой операционной системы, устройств хранения данных и съемных машинных носителей информации, а также монтирование корневой файловой системы хостовой операционной системы в режиме «только для чтения» и ограничение доступа прикладного программного обеспечения, выполняемого внутри контейнера, к системным вызовам ядра хостовой операционной системы, осуществляется средствами Docker в ОС Astra Linux Special Edition. Это закрывает требование Приказа ФСТЭК России № 118 в ОС Astra Linux для четвертого, пятого и шестого классов защиты.

3.4 Контроль целостности контейнеров и их образов

В разделе 12 описаны требования по контролю целостности контейнеров и их образов. Контроль целостности объектов контроля реализуется в ОС Astra Linux сертифицированными средствами регламентного контроля целостности AFICK из состава ОС. Системный планировщик заданий cron позволяет выполнять проверку целостности объектов контроля в процессе загрузки операционной систем или по установленному расписанию.

Для локального реагирования на события в автозапуске для сессии пользователя находится демон, который обрабатывает входящие от syslog‑ng события и выполняет заданное действие, например, уведомление. Передача данных выполняется с использованием D‑Bus. Реализация действий осуществляется модулем KNotifications. Демон получает информацию только о событиях, для которых настроено реагирование. Демон, запущенный от имени определенного пользователя, реагирует только на те события, которые предназначены данному пользователю. Для этого демон отслеживает сигнал, передаваемый syslog‑ng по D‑Bus всем заинтересованным приложениям. В сигнале также передается список имен пользователей и имен групп, для которых требуется реакция на событие.

Служба Центра уведомлений fly‑notifications выдает оповещения администратору безопасности средства контейнеризации о событиях безопасности. Фильтрация и регистрация событий выполняется модулем syslog‑ng‑mod‑astra посредством анализа низкоуровневых и генерации соответствующих высокоуровневых событий. Основным источником событий является служба auditd. Для просмотра и анализа событий используется утилита fly‑admin‑events.

Контроль целостности содержимого журнала безопасности /parsec/log/astra/events настраивается администратором безопасности, входящим в группу astra‑admin, с помощью совместного применения мандатного контроля целостности и атрибута доступа chattr +a. Таким образом, любые действия, совершаемые с журналом безопасности, будут зафиксированы, а нелегитимные действия не будут позволены. Удаление журнала событий контролируется событием «Журнал событий удален». Переименование или перемещение журнала событий контролируется событием «Журнал событий переименован или перемещен». Ротация журнала событий контролируется событием «Журнал событий ротирован». Прочие действия с журналом событий контролируются событием «Журнал событий изменен недоверенным процессом».

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

По требованиям из раздела 12 ОС Astra Linux Special Edition также можно считать подходящей для шестого, пятого и четвертого классов защиты.

3.5 Регистрация событий безопасности

13-й раздел Выписки из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации» описывает последнее обязательное требование к средствам контейнеризации — требование регистрации событий безопасности, связанных с контейнерами. Регистрация событий безопасности, связанных с контейнерами, осуществляется штатными средствами ОС Astra Linux Special Edition. Подлежащие регистрации события — это:

• неуспешные попытки аутентификации пользователей средства контейнеризации,

• создание, модификация и удаление образов контейнеров,

• получение доступа к образам контейнеров,

• запуск и остановка контейнеров с указанием причины остановки, изменение ролевой модели,

• модификация запускаемых контейнеров.

События безопасности средства контейнеризации, которые относятся к попыткам получения несанкционированного доступа, попадают в журнал /parsec/log/astra/events. Управление регистрацией событий осуществляется с использованием утилиты fly‑admin‑events. Сбор, запись и хранение информации о событиях безопасности осуществляются с помощью службы auditd и модуля фильтрации и обработки syslog‑ng‑mod‑astra путем ведения журналов событий безопасности согласно заданным правилам.

Регистрация событий изменений, связанных с контейнерами и образами контейнеров — их создание, модификации, удаление, получения доступа, запуск и остановка с указанием причины остановки, осуществляется средствами Docker. Для этого демон dockerd запускается с параметром dockerd: DOCKER_OPTS="-D".

Регистрация событий модификации запускаемых контейнеров фактически осуществляется через регистрацию событий доступа к средству контейнеризации. Неуспешные попытки аутентификации при этом фиксируются в журнале /parsec/log/astra/event. Оповещение администратора безопасности средства контейнеризации о событиях безопасности происходит через работу Центра уведомлений — fly‑notifications. Настройка событий, которые подлежат регистрации, а также реагирование на них системы осуществляется с помощью утилиты fly‑admin‑events.

Таким образом, требования раздела 13 Выписки из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации» закрыты в ОС Astra Linux для любого класса защиты с шестого по четвертый.

3.6 Идентификация и аутентификация пользователей

Также ОС Astra Linux Special Edition реализовано одно дополнительное требование — требование из раздела 15, касающееся идентификации и аутентификации пользователей в средстве контейнеризации. Администратор безопасности средства контейнеризации осуществляет первичную идентификацию пользователей средства контейнеризации. При входе в систему осуществляется идентификация и проверка подлинности субъектов доступа процедурой аутентификации. Установка пароля пользователя осуществляется администратором с помощью Политик безопасности — через графическую утилиту fly‑ad. Запрет запуска средством контейнеризации в хостовой ОС процессов, обладающих привилегиями администратора информационной системы и администратора безопасности информационной системы, осуществляется с помощью утилиты unshare, позволяющей реализовать:

• запрет запуска процессов от имени суперпользователя root,

• запрет просмотра процессов хостовой машины,

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

• невлияние монтирования и размонтирования ФС на состав древа каталогов хостовой машины.

4. Заключение

В статье проведен анализ программных средств реализации требований Приказа ФСТЭК России № 118 «Об утверждении требований по безопасности информации к средствам контейнеризации» на примере ОС Astra Linux Special Edition. Описаны меры достижения каждого обязательного требования из Выписки из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации», представленные в ОС Astra Linux, приведены программные механизмы их реализации. Также приведен механизм реализации дополнительного требования раздела 15 Выписки из Приказа ФСТЭК России № 118, касающегося идентификации и аутентификации пользователей.

Стоит отметить, что требования Приказа ФСТЭК России № 118 конкретизированы и единообразны, что упрощает понимание и выполнение документа. Каждое требование детально проработано и описано. Уже есть ряд сертифицированных отечественных решений, удовлетворяющих требованиям Приказа ФСТЭК России № 118. Выполнение описанных требований достаточно для обеспечения безопасности информации в средах контейнеризации. Отдельно стоит обратить внимание на безопасность в средах оркестрации. Достаточно трудно формализовать требования к оркестраторам, так как они являются «конструктором», и ограничение в используемых элементах может привести к потере функционала.

Автор: Александр Токарев, инженер по инфраструктурной безопасности направления безопасной разработки УЦСБ

Команда УЦСБ с чувством глубокой скорби сообщает, что на момент публикации этой статьи Александра Токарева уже нет в живых. Саша трагически погиб, и мы не можем выразить словами, какая это утрата для всех нас. Мы решили опубликовать материал, который он успел подготовить. В знак признания его работы и как дань уважения замечательному коллеге и другу, память о котором навсегда останется в наших сердцах.