Применимо к редакции: МСВСфера 9 (ФСТЭК)

15.5. Функции безопасности

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

Использование непривилегированного (rootless) режима работы Docker позволяет обеспечить механизмы изоляции штатными средствами операционной системы. Каждый экземпляр Docker запускается в контексте конкретного пользователя операционной системы. Остальные пользователи не имеют доступа к данному контексту по определению. Таким образом, использование штатных средств операционной системы и работа Docker в непривилегированном (rootless) режиме в полной и достаточной степени реализуют требуемый уровень механизмов изоляции.

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

В качестве дополнительного средства обеспечения изоляции пространства имён процессов хост-системы и пространства имён контейнеров для межпроцессорного взаимодействия контейнеров также используется настройка cgroup-parent со значением, установленным по умолчанию, которая прописывается в файле настроек daemon.json демона Docker для каждого пользователя. Файл настроек daemon.json защищён от изменения и удаления рядовым пользователем штатными средствами ОС МСВСфера. Настройка защиты осуществляется программным комплексом.

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

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

Таблица 69 - Параметры запуска контейнера, недопустимые к использованию

Параметр	Причина
--net=host	Из-за угрозы нарушения изоляции сетевых пространств контейнеров.
--pid=host	Из-за угрозы нарушения изоляции пространств идентификаторов процессов контейнеров между процессами хост-системы и процессами контейнера.
--ipc=host	Из-за угрозы нарушения изоляции пространств имён процессов хост-системы и пространства имён контейнеров для межпроцессорного взаимодействия контейнеров.
--device	Из-за угрозы нарушения ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съёмных машинных носителей информации (блочных устройств), входящих в состав информационной системы, а также изоляции пространств имён файловой системы хоста и пространств имён файловых систем контейнеров.
--userns=host	Из-за угрозы нарушения изоляции пространств имён пользователей и групп пользователей хост-системы и пространств имён пользователей и групп контейнеров.

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

Таблица 70 - Параметры запуска контейнера, обязательные к использованию

Параметр	Причина
--memory	Для обеспечения ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование оперативной памяти хостовой операционной системы.
--read-only	Для обеспечения ограничения монтирования корневой файловой системы хостовой операционной системы в режиме «только для чтения».

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

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

Перечень утилит для сканирования:

• trivy

• dockle

• docker-bench-security

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

По умолчанию, настроено ежедневное сканирование системы в 14:00. Администратор системы может изменить периодичность сканирования.

Для это выполните следующие действия.

1. Настроите файл таймера /usr/lib/systemd/system/docker_scan_time.timer.

2. Для перезапуска подсистемы сканирования и формирования отчетов выполните команду:

   $ sudo systemctl daemon-reload
   

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

Администратор системы после анализа полученных данных принимает решения по вопросам безопасности.

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

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

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

Пользователь системы не является администратором системы и не имеет прав суперпользователя. Штатные настройки операционной системы не дают рядовому пользователю прав на операции монтирования. Системный администратор должен явно предоставить дополнительные права конкретному пользователю на право монтировать определённую файловую систему. Только суперпользователь сможет выполнять данные действия.

Использование непривилегированного (rootless) режима работы Docker не позволит внутри контейнера получить права на использование периферийных устройств, устройств хранения данных и съёмных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы.

В непривилегированном (rootless) режиме, по умолчанию, только memory и pids контроллеры делегируются пользователям, не являющимся суперпользователем. Чтобы разрешить делегирование полномочий другим контроллерам, необходимо изменить конфигурацию systemd, для чего необходимо явным образом выполнить соответствующие настройки systemd и обладать правами суперпользователя.

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

Монтирование корневой файловой системы хостовой операционной системы в режиме «только для чтения» обеспечивается контролем программного комплекса наличия в параметрах запуска контейнера обязательного к использованию параметра --read-only.

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

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

Для реализации контроля целостности образов используется инструмент «Docker Content Trust» (DCT). Он позволяет разработчикам подписывать свои образы электронной цифровой подписью (ЭЦП), а пользователям проверять эту ЭЦП. Прохождение проверки гарантирует целостность и аутентичность образа. Docker проверяет подписи при каждой операции docker pull и docker run, что минимизирует риск использования изменённых или поддельных образов.

При скачивании пользователем образа по имени и тэгу Docker сначала проверяет ЭЦП манифеста.

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

Инструмент «Docker Content Trust» включается путем добавления в переменные системного окружения значения DOCKER_CONTENT_TRUST=1. Это позволит Docker проверять подписи при каждой операции docker pull и docker push, что минимизирует риск использования изменённых или поддельных образов. Внесение любых изменений в файлы образа, вызовет изменение значений рассчитываемых Docker хэшей и, соответственно, запрет Docker на исполнение последующих действий. В консоль пользователя будет выведено стандартное сообщение Docker об ошибке.

Пользователи, при создании собственных образов, обязаны их подписывать с помощью ЭЦП. Описание технологии создания самоподписанной ЭЦП или создания ЭЦП в сертифицированном центре, и интегрирование ЭЦП в ОС для работы со средствами Docker, не рассматривается. Методика работы с ЭЦП описана в официальной документации Docker.

После настройки пакета, файл эталонной базы /etc/docker_security/integrity/integrity.md5, который должен содержать контрольные суммы контролируемых файлов, отсутствует. Сервис подсистемы контроля целостности docker_integrity.service при своём первом запуске на основании предопределённого перечня файлов контроля из файла /etc/docker_security/integrity/integrity.list формирует файл эталонной базы.

Администратор обязан убедиться, что по электронной почте пришло уведомление с темой письма «Файл контрольных сумм не существует! Инициализация системы контроля целостности…»

Администратор системы может выполнить дополнительную настройку перечня контролируемых файлов integrity.list и пересоздать эталонную базу integrity.md5. Для этого необходимо выполнить следующие действия.

• Внести изменения в файл /etc/docker_security/integrity/integrity.list.

• Удалить файл эталонной базы integrity.md5 с помощью следующей команды:

  $ sudo rm /etc/docker_security/integrity/integrity.md5
  

• Перезапустить сервис подсистемы контроля целостности docker_integrity.service с помощью следующей команды:

  $ sudo systemctl restart docker_integrity.service
  

Администратор системы должен пересоздать эталонную базу integrity.md5 при добавлении нового пользователя в систему. Для этого необходимо выполнить следующие действия.

• Удалить файл эталонной базы integrity.md5 с помощью следующей команды:

  $ sudo rm /etc/docker_security/integrity/integrity.md5
  

• Перезапустить сервис подсистемы контроля целостности docker_integrity.service с помощью следующей команды:

  $ sudo systemctl restart docker_integrity.service
  

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

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

Целостность сведений о событиях безопасности, зафиксированных в системных журналах ОС, обеспечиваются штатными средствами ОС МСВСфера.