Не так давно мы проводили очередную оценку соответствия требованиям ГОСТ Р 57580 (далее — просто ГОСТ). Клиент — компания, которая разрабатывает систему электронных платежей. Система серьезная: более 3 млн пользователей, более 200 тыс. транзакций ежедневно. К информационной безопасности там относятся очень ответственно.
В процессе оценки клиент между делом сообщил, что отдел разработки, помимо виртуальных машин, планирует использовать контейнеры. Но с этим, добавил клиент, есть одна проблема: в ГОСТ про тот же Docker — ни слова. Как быть? Как оценивать безопасность контейнеров?
Это правда, в ГОСТ написано только про аппаратную виртуализацию — про то, как нужно защищать виртуальные машины, гипервизор, сервер. Мы обратились за разъяснением в Центробанк. Ответ нас озадачил.
ГОСТ и виртуализация
Для начала напомним, что ГОСТ Р 57580 — новый стандарт, в котором прописаны «требования по обеспечению информационной безопасности финансовых организаций» (ФИ). В числе таких ФИ — операторы и участники платежных систем, кредитные и некредитные организации, операционные и клиринговые центры.
С 1 января 2021 года ФИ раз в два года обязаны проводить . Мы, ITGLOBAL.COM, — аудиторская компания, которая проводит такую оценку.
В ГОСТ есть подраздел, посвященный защите виртуализированных сред, — № 7.8. Термин «виртуализация» там не уточняется, разделения на аппаратную и контейнерную виртуализации нет. Любой айтишник скажет, что с технической точки зрения это некорректно: виртуальная машина (ВМ) и контейнер — разные среды, с разным принципом изолирования. С точки зрения уязвимости хоста, на котором разворачиваются ВМ и Docker-контейнеры, — это тоже большая разница.
Выходит, оценка информационной безопасности ВМ и контейнеров тоже должна отличаться.
Наши вопросы ЦБ
Мы направили их в Департамент информационной безопасности Центробанка (вопросы приводим в сокращенном виде).
- Как при проведении оценки соответствия ГОСТ рассматривать виртуальные контейнеры типа Docker? Корректно ли оценивать технологию в соответствии с подразделом 7.8 ГОСТ?
- Как оценивать средства управления виртуальными контейнерами? Можно ли приравнивать их к серверным компонентам виртуализации и оценивать по тому же подразделу ГОСТ?
- Нужно ли отдельно оценивать защищенность информации внутри контейнеров Docker? Если да — какие меры защиты следует для этого учитывать в процессе оценки?
- Если контейнеризация приравнивается к виртуальной инфраструктуре и оценивается согласно подразделу 7.8 — как реализуются требования ГОСТ по внедрению специальных средств защиты информации?
Ответ ЦБ
Ниже — основные выдержки.
«ГОСТ Р 57580.1-2017 устанавливает требования к реализации путем применения технических мер в отношении следующих мер ЗИ подраздела 7.8 ГОСТ Р 57580.1-2017, которые, по мнению Департамента, можно распространить и на случаи использования технологий контейнерной виртуализации с учетом следующего:
- реализация мер ЗСВ.1 – ЗСВ.11 по организации идентификации, аутентификации, авторизации (разграничение доступа) при осуществлении логического доступа к виртуальным машинам и серверным компонентам виртуализации может отличаться от случаев использования технологии контейнерной виртуализации. С учетом этого для реализации ряда мер (например, ЗВС.6 и ЗВС.7) полагаем возможным рекомендовать финансовым организациям разработать компенсирующие меры, которые будут преследовать те же цели;
- реализация мер ЗСВ.13 – ЗСВ.22 по организации и контролю информационного взаимодействия виртуальных машин предусматривает сегментацию вычислительной сети финансовой организации для разграничения объектов информатизации, реализующих технологию виртуализации, относящихся к разным контурам безопасности. С учетом этого полагаем целесообразным предусмотреть соответствующую сегментацию и при использовании технологии контейнерной виртуализации (как в отношении исполняемых виртуальных контейнеров, так и в отношении используемых на уровне операционной системы систем виртуализации);
- реализация мер ЗСВ.26, ЗСВ.29 – ЗСВ.31 по организации защиты образов виртуальных машин должна быть осуществлена по аналогии также и в целях защиты базовых и текущих образов виртуальных контейнеров;
- реализация мер ЗВС.32 – ЗВС.43 по регистрации событий защиты информации, связанных с доступом к виртуальным машинам и серверным компонентам виртуализации, должна быть осуществлена по аналогии также и в отношении элементов среды виртуализации, реализующих технологию контейнерной виртуализации».
Что это значит
Два главных вывода из ответа Департамента ИБ Центробанка:
- меры для защиты контейнеров не отличаются от мер для защиты виртуальных машин;
- из этого следует, что в контексте информационной безопасности ЦБ ставит знак равенства между двумя типами виртуализации — Docker-контейнерами и ВМ.
В ответе также упомянуты «компенсирующие меры», которые нужно применять для нейтрализации угроз. Вот только неясно, что это за «компенсирующие меры», как измерять их адекватность, полноту и эффективность.
Что не так с позицией ЦБ
Если при оценке (и самооценке) пользоваться рекомендациями Центробанка, нужно решить ряд технических и логических затруднений.
- Каждый исполняемый контейнер требует установки на него программных средств защиты информации (СЗИ): антивируса, контроль целостности, работа с логами, DLP-системы (Data Leak Prevention) и так далее. Всё это без проблем устанавливается на ВМ, но в случае с контейнером установка СЗИ — абсурдный ход. Контейнер несет в себе минимальное количество «обвеса», которое нужно для функционирования сервиса. Установка в него СЗИ противоречит его смыслу.
- По тому же принципу следует защищать и образы контейнеров — как это реализовать, тоже непонятно.
- ГОСТ требует ограничивать доступ к серверным компонентам виртуализации, т. е. к гипервизору. Что считать серверной компонентой в случае с Docker? Не значит ли это, что каждый контейнер нужно запускать на отдельном хосте?
- Если для обычной виртуализации можно разграничить ВМ по контурам безопасности и сетевым сегментам, то в случае с Docker-контейнерами в рамках одного хоста — нет.
На практике, скорее всего, каждый аудитор будет оценивать безопасность контейнеров на свой лад, опираясь на свои знания и опыт. Ну, или вообще не оценивать, если ни того, ни другого нет.
На всякий случай добавим, что с 1 января 2021 года минимальная оценка должна быть не ниже 0,7.
Кстати, ответы и комментарии регуляторов, связанные с требованиями ГОСТ 57580 и Положений ЦБ, мы регулярно выкладываем в нашем .
Что делать
На наш взгляд, у финансовых организаций всего два варианта решения проблемы.
1. Отказаться от внедрения контейнеров
Решение для тех, кто готов позволить себе использовать только аппаратную виртуализацию и в то же время опасается низких оценок по ГОСТ и штрафов ЦБ.
Плюс: легче выполнить требования подраздела 7.8 ГОСТ.
Минус: придется отказаться от новых средств разработки на основе контейнерной виртуализации, в частности от Docker и Kubernetes.
2. Отказаться от выполнения требований подраздела 7.8 ГОСТ
Но при этом — применять лучшие практики в обеспечении ИБ при работе с контейнерами. Это решение для тех, кому важнее новые технологии и возможности, которые они предоставляют. Под «лучшими практиками» мы здесь понимаем принятые в отрасли нормы и стандарты по обеспечению безопасности Doсker-контейнеров:
- безопасность ОС хоста, правильно настроенное логирование, запрет обмена данными между контейнерами и так далее;
- применение функции Docker Trust для проверки целостности образов и использование встроенного сканера уязвимостей;
- нельзя забывать о безопасности удаленного доступа и сетевой модели в целом: атаки типа ARP-spoofing и MAC-flooding никто не отменял.
Плюс: никаких технических ограничений на использование контейнерной виртуализации.
Минус: высока вероятность того, что регулятор накажет за несоблюдение требований ГОСТ.
Заключение
Наш клиент решил не отказываться от контейнеров. При этом ему пришлось значительно пересмотреть объем работ и сроки по переходу на Docker (они растянулись на полгода). Клиент отлично понимает риски. Понимает и то, что при проведении следующей оценки соответствия ГОСТ Р 57580 многое будет зависеть от аудитора.
А как бы вы поступили в этой ситуации?
Источник: habr.com