Защищенная загрузка терминальных станций с использованием технологий DOCKER

И.В. ЧУМАКОВ, Н.В. МОЗОЛИНА, А.Ю. ЧАДОВ

МФТИ (НИУ), Москва, 117303, Россия

ЗАО «ОКБ САПР», Москва, 115114, Россия

Введение

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

Вопросы защиты систем терминального доступа также поднимались не раз, и не раз находились на них ответы [2-6]. Хрестоматийной истиной стало утверждение, что для обеспечения безопасности необходима защита всех компонентов системы, в том числе и клиентов, с которых происходит подключение, вне зависимости от того, что именно выступает в роли клиента: устаревшие ПК, специализированные аппаратные терминалы или машины с высокой производительностью [7]. И всё-таки задачу обеспечения безопасности информационной системы, построенной на технологии терминального доступа, нельзя назвать решённой раз и навсегда. Год от года повышаются требования к производительности рабочих мест пользователей и терминальных серверов, появляются новые возможности и новые угрозы безопасности, а потому требуется постоянное совершенствование средств защиты.

В основе обеспечения безопасности клиентских рабочих мест лежит доверенная загрузка операционной системы (ОС), какой бы из трёх способов ни использовался: с локального диска, с мобильного носителя или по сети [8, 9]. В данной работе рассмотрим защищённую сетевую загрузку терминальных станций с использованием технологии Docker и её реализацию в ПАК «Центр-Т» [10].

Два этапа загрузки

У сетевой загрузки терминальных станций в чистом виде – по протоколу PXE – есть существенный недостаток: при отправке клиентом PXE-запроса на загрузку ОС не происходит проверки сервера, обсуживающего данный запрос, что делает возможными различные атаки, например, «человек посередине». И хотя уже есть предложения по нейтрализации указанной угрозы, готовых средств защиты на рынке информационной безопасности пока нет [11].

По этой причине в ПАК «Центр-Т» защищённая загрузка терминальных станций происходит в 2 этапа. На первом с отчуждаемого носителя загружается образ ОС, называемый образом начальной загрузки (ОНЗ). Основная и единственная его цель – обеспечение безопасного второго этапа, а именно сетевой загрузки программного обеспечения, посредством которого будет происходить подключение к терминальному серверу.

О преимуществах загрузки со специального защищённого носителя, исключающего запись в него посторонних данных, сказано немало – как в отношении ПАК «Центр-Т» [8, 12], так и про другие продукты [13-14]. Остановимся подробнее лишь на реализации второго этапа загрузки.

Сетевая загрузка ПО в «Центр-Т»

ПО на терминалы загружается с СХСЗ, Сервера хранения и сетевой загрузки, - компонента «Центр-Т», состоящего из аппаратной (специальный носитель) и программной (записанный на носитель образ) частей. Другим компонентом ПАКа является Клиент – специальный носитель (клиентское устройство) с записанным на него ОНЗ. Управление и настройка «Центр-Т» осуществляется посредством утилиты Удалённого управления СХСЗ [10].

Собственно носитель ПО Клиента и есть то отчуждаемые устройство, с которого происходит загрузка терминальной станции на первом этапе. Все разделы, кроме одного служебного, предназначенного для хранения настроек (конфигурация сети, используемое разрешение монитора, настройки даты и времени, информация о СХСЗ, используемом Клиентом), находятся в режиме RO. Раздел настроек – в режиме RW.

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

Образом, получаемым по сети, является Docker-образ, который на СХСЗ хранится в Registry.

Registry – это система хранения и распространения данных, содержащая именованные образы Docker, доступные в различных версиях с тэгами [15].

Registry не хранит образы Docker целиком, как единый элемент. Поскольку образ представляет из себя набор слоев, причем один или несколько слоев могут быть использованы разными образами, то и в качестве элемента в Registry используются, как раз таки, эти слои. Для управления такой системой используются манифесты образов (Image Manifest), в котором содержится список слоев этого образа и значения их хэш-сумм, а также имя образа и его тэг [16].

Таким образом Docker Registry хранит только набор уникальных слоев и манифесты образов, вместо целых образов. И пользователи при получении образа из Registry могут проверить целостность полученных слоев, сверяя хэш-суммы скаченных слоев с хэш-суммами хранящимися в манифесте, тем самым проверяется и целостность всего образа.

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

Однако проверка целостности образа зависит от целостности его манифеста. Поэтому необходимо также контролировать целостность манифеста. В ПАК «Центр-Т» версии 1.2.2 (актуальная версия на момент выхода этой работы) проверка манифеста не реализована. Рассмотрим, как может быть выполнен этот контроль.

Контроль целостности манифеста образа Docker

Контроль целостности манифеста образа в Docker может быть осуществлён посредством Notary. Docker Notary – инструмент, позволяющий публиковать доверенные наборы данных и управлять ими [17]. Разработчики могут подписывать эти наборы цифровой подписью, а пользователи проверять целостность данных и аутентифицировать их. В качестве наборов этих данных выступают манифесты образов. В основе этого инструмента лежит спецификация The Update Framework [18], которая определяет иерархию ключей с различными приведениями и сроками действия [19]. Каждый ключ предназначен для подписи содержимого файла формата json с таким же именем, как и имя ключа. Кратко опишем роль каждого ключа, а также содержимое файла, который он подписывает:

• ключ root предназначен для подписи других ключей в системе. В файле root.json хранятся отрытые ключи всех других ключей, требуемых спецификацией TUF;
• ключ snapshot предназначен для подписи метаданных других json файлов – это root.json и tagrets.json. Эти метаданные хранятся в snapshot.json и включают в себя имя файла, его размер и хэш-сумма;
• ключ timestamp предназначен для подписи метаданных файла snapshot.json, а именно его размер, хэш-сумма и номер версии. Все эти метаданные хранятся в timestamp.json, который регулярно переподписывается через равные промежутки времени;
• ключ targets предназначен для подписи метаданных манифестов, хранящихся в файле targets.json;

Notary содержит две главные компоненты [20]: сервер Notary и сервер для подписи Notary. Клиенты Notary взаимодействуют только с сервером Notary для получения метаданных из него или для передачи метаданных ему. Сервер хранит файлы метаданных TUF для одного или нескольких манифестов в связанной базе данных.

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

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

По умолчанию, клиенты Notary отвечают за управление ключами для root, snapshot и targets ролей. Все эти ключи создаются при инициализации новой доверенной коллекции.

Сервер Notary всегда отвечает за управление ключом timestamp.

Таким образом, root, targets и snapshot метаданные создаются и подписываются клиентом, который передает серверу Notary. При этом сервер отвечает за:

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

Сервер подписи отвечает за:

• хранение приватного ключа timestamp;
• выполнение операций подписи с этими ключами по запросу сервера Notary.

Notary может быть расположен как на отдельном сервере, так и совместно с Registry. Исходя из архитектуры «Центр-Т» целесообразней будет его расположить на СХСЗ, чтобы не создавать новые компоненты.

При такой конфигурации «Центр-Т», клиентское устройство будет проверять целостность манифеста при помощи Notary перед тем как скачивать Docker-образ. Если проверка проведена успешно, то дальнейшая работа будет происходить точно так же, как и раньше.

Заключение

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

ПАК «Центр-Т» позволяет решить эту задачу, при этом выстраивая цепь доверия от аппаратных устройств с ОНЗ до загружаемых по сети образов, в том числе, используя механизмы контроля целостности Docker.

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

Список литературы

1. Виртуализация рабочих мест и терминальный доступ [Электронный ресурс]. URL: https://www.croc.ru/solution/ikt-infrastructure/it_infrastructure/terminal/ (дата обращения 24.04.2019)
2. Счастный Д. Ю. Защита решений для федеральных органов власти. // Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15-18 мая 2012 года, Суздаль (Россия). 2012. С. 229–230.
3. Счастный Д. Ю. Построение систем защиты от несанкционированного доступа к терминальным системам // Information Security/Информационная безопасность. 2008. № 2 (март). С. 48–49.
4. Защита ИСПДн с применением технологии терминального доступа
5. Экономичное внедрение защищенной терминальной системы
6. Аттестованная система терминального доступа к ИСПДн
7. Конявская С. В. Защита информации в системах терминального доступа // Information Security/Информационная безопасность. М., 2014. № 3. С. 53–54.
8. Счастный Д. Ю. Терминальные клиенты: начала защиты // Комплексная защита информации. Материалы XIV международной конференции. — 2009. — С. 210–211.
9. Доверенная загрузка ОС терминального клиента
10. ПАК «Центр-Т»
11. Гатчин Ю.А., Теплоухова О.А. Реализация контроля целостности образа операционной системы, загружаемого по сети на тонкий клиент // Научно-технический вестник информационных технологий, механики и оптики. 2015. Т. 15. № 6. С. 1115–1121.
12. Конявская С. В. «Специальное» vs «универсальное» как базовая дихотомия всеобщей теории всего// Комплексная защита информации: материалы XXIII научно-практической конференции, Суздаль, 22-24 мая 2018 г. – Москва, Медиа Групп «Авангард», 2018 год, С. 33–39.
13. Лемке Е.А., Лубкин И.А. Создание защищенной терминальной системы // Решетневские чтения. 2013. №17. 306–308.
14. Интеграционная платформа «Цикрон» [Электронный ресурс]. URL: http://sinclit.ru/platforma-tsirkon.html (дата обращения 25.04.2019).
15. About Registry [Электронный ресурс]. URL: https://docs.docker.com/registry/introduction/ (дата обращения: 25.04.2019).
16. Docker Registry HTTP API V2 [Электронный ресурс]. URL: https://docs.docker.com/registry/spec/api/ (дата обращения: 25.04.2019).
17. Getting started with Docker Notary [Электронный ресурс]. URL: https://docs.docker.com/notary/getting_started (дата обращения: 25.04.2019).
18. A Framework for Securing Software Update Systems [Электронныйресурс]. URL: https://github.com/theupdateframework/tuf (дата обращения: 25.04.2019).
19. The Update Framework Specification [Электронныйресурс]. URL: https://github.com/theupdateframework/specification/blob/master/tuf-spec.md (дата обращения: 25.04.2019).
20. Understand the Notary service architecture [Электронныйресурс]. URL: https://github.com/theupdateframework/notary/blob/master/docs/service_architecture.md (дата обращения: 25.04.2019).
21. Конявская С. В. Защита терминальных клиентов в идеологии «клиент всегда прав»(Information Security/Информационная безопасность. М., 2016. № 5 (ноябрь). С. 35.

Авторы: Чумаков И. В.; Мозолина Н. В.; Чадов А. Ю.

Дата публикации: 10.01.2019

Библиографическая ссылка: Чумаков И. В., Мозолина Н. В., Чадов А. Ю. Защищенная загрузка терминальных станций с использованием технологий DOCKER // Комплексная защита информации: материалы ХХIV научно-практической конференции. Витебск. 21–23 мая 2019 г.: УО ВГТУ. Витебск, 2019. С. 267–271.

---