Гибридная инфраструктура без серых зон
Кто отвечает за безопасность, когда периметр исчез
Гибридная инфраструктура редко появляется по единому плану. Сначала компания держит ключевые системы на собственной площадке. Затем выносит часть нагрузок в публичное облако, размещает оборудование в стороннем ЦОДе, подключает SaaS-сервисы и внешних подрядчиков. И вместо одного понятного контура возникает несколько связанных сред с разными правилами доступа, СЗИ и ответственными командами.
Вот тут-то и начинаются проблемы, потому что чаще всего никто не может точно сказать, кто отвечает за компонент, кто видит события во всех сегментах и кто действует при инциденте.
Дмитрий Шкуропат, руководитель команды киберзащиты облачного провайдера Nubes, рассказал о подходе к безопасности при гибридной схеме, где отказоустойчивость — не пустой звук.
Защищенное облако не делает защищенной всю систему
Распространенное заблуждение считать, что перенос информационной системы в аттестованное облако автоматически выполняет требования регуляторов и снимает с заказчика ответственность за безопасность.
Провайдер отвечает за физическую инфраструктуру, платформу виртуализации, доступность облака и средства защиты, входящие в состав сервиса. Например, NGcloud аттестовано по требованиям 152-ФЗ для УЗ-1, сертифицировано по PCI DSS 4.0 и прошло оценку соответствия ГОСТ Р 57580. В облаке также предусмотрены защита от DDoS L3/L4, сканирование публичных IP-адресов и сбор инфраструктурных логов.
Но аттестат площадки не становится аттестатом информационной системы клиента. Заказчику по-прежнему нужно определить состав ИСПДн, угрозы, роли и порядок доступа, обеспечить безопасность приложений и при необходимости аттестовать свою систему на базе облака.
То же относится к практической защите. Провайдер не знает, зачем клиент открыл порт в интернет, кому выдал административные права и насколько быстро обновляет ПО. Виртуальная машина может работать на отказоустойчивой платформе, но оставаться уязвимой из-за открытого RDP или непропатченного сервиса.
Поэтому, вынося какие-то данные в облако, корректнее говорить не о передаче ответственности, а о ее разделении.
Схема сети — не главный документ гибридной среды
Схема показывает, как соединены офис, ЦОД, облако и внешние сервисы, но не определяет ответственных за возникающие между ними проблемы. Для этого нужна матрица распределения ответственности. Это рабочий документ, привязанный к конкретным операциям. В нем стоит зафиксировать, кто:
- создает и блокирует учетные записи;
- настраивает MFA и парольные политики;
- обновляет ОС, приложения, СЗИ и платформу;
- управляет сетевой связностью и правилами NGFW;
- собирает и хранит логи;
- устраняет уязвимости и расследует инциденты;
- отвечает за резервное копирование и проверку восстановления;
- контролирует привилегированный доступ подрядчиков.
Такая матрица особенно нужна в момент сбоя. И чем больше поставщиков, тем это важнее. Модель «облако у одного, 1С обслуживает второй, сеть — третий, безопасность — четвертый» технически жизнеспособна. Но без единого процесса управления инцидентами она быстро превращается в коллективный поиск виноватого.
Эта практика, кстати, не такая популярная в России, но мы с некоторыми нашими клиентами активно ее применяем, чтобы сократить до минимума те самые «серые» зоны.
Взлом одного сегмента может открыть путь в остальные
Когда инфраструктура находилась внутри офиса, ее граница была относительно понятна: локальная сеть, точка выхода в интернет, межсетевой экран. В гибридной модели эта граница растягивается. В облаке появляются публичные адреса, между площадками — VPN-туннели, подрядчики получают удаленный доступ, а системы обмениваются данными через API.
Каждая такая связь становится возможным маршрутом атаки.
Допустим, у компании есть локальный Active Directory, облачная 1С и отдельный сервис подрядчика. Между ними настроены сетевые доступы и доверительные отношения. Злоумышленник компрометирует учетную запись во внешнем сервисе. Если права выданы шире необходимого, а события из разных контуров никто не сопоставляет, атака может продолжиться через легитимное соединение: от подрядчика к облачной системе, а затем к локальной инфраструктуре.
Похожим образом работают атаки через цепочку поставок. Сотрудник получает письмо с привычного адреса партнера, открывает документ, после чего вредоносное ПО закрепляется на рабочей станции. Атакующий входит через доверенное звено, которое проверяли менее строго.
Так что просто поставить одинаковые межсетевые экраны на каждой площадке недостаточно. Защищать нужно не только границы, но и связи, идентификационные данные, действия администраторов и общий процесс наблюдения за событиями.
Чем заменить единый периметр
Первый принцип: минимизировать доверие между сегментами. Наличие VPN не должно означать, что сети доверяют друг другу целиком. Для каждого взаимодействия нужно определить источник, получателя, протокол и назначение.
Здесь пригодится NGFW. Он фильтрует трафик по адресам, портам и приложениям, выявляет атаки и блокирует нежелательные сценарии. Важно, чтобы правила локальной и облачной среды проектировались как единая политика. Мы в Nubes предоставляем виртуальный NGFW в облаке некоторым клиентам и берем на администрирование устройство на площадке заказчика. Это снижает риск, что разные сегменты будут защищаться по разной логике.
Второй принцип: единое управление идентификацией. Отдельные учетные записи для каждого сервиса увеличивают число забытых доступов и усложняют удаление уволенных сотрудников. Если федерация учетных записей невозможна, необходимы MFA, единые парольные требования, регулярный пересмотр прав и запрет общих административных аккаунтов.
Третий принцип: контроль привилегированных действий. Доступ администраторов провайдера или подрядчика должен быть ограничен по времени и задаче. Для критичных систем подойдет PAM: запись сессий, временные права и блокировка запрещенных команд.
Четвертый принцип: централизованный мониторинг. Если логи из офиса, облака, NGFW, серверов и приложений хранятся отдельно, команда видит симптомы, но не атаку целиком. Облачный SIEM Nubes собирает события из локальных, сетевых и облачных систем в одном месте и позволяет восстановить единый таймлайн инцидента.
Пятый принцип: регулярная проверка конфигурации. После миграции появляются временные исключения, новые правила и открытые порты. А, как мы знаем, временное крайне часто становится постоянным. Аудит ИБ помогает проверить сегментацию, настройки Firewall и NGFW, стойкость паролей, внешние адреса и уязвимости. Его стоит проводить перед запуском и после крупных изменений.
Один провайдер не исключает ответственность заказчика, но сокращает количество стыков
Иногда удобнее разместить собственное оборудование в ЦОДе, связать его с публичным облаком и подключить защиту у одного сервис-провайдера.
В Nubes такую схему можно построить на базе colocation в дата-центре и ресурсов NGcloud. Физические серверы связываются с облачным сегментом, а поверх инфраструктуры подключаются NGFW, защита от DDoS, SIEM и другие ИБ-сервисы.
Да, это не значит, что клиент нажимает кнопку «сделать безопасно», но так сокращается число организационных разрывов. Инженеры видят физическую площадку, облачную платформу и сервисы защиты, а зоны ответственности можно закрепить в одном проекте и одном процессе эскалации.
Гибридная архитектура начинается с вопросов, а не с оборудования
Ну и так как мы говорим про безопасность при гибридной схеме, то перед переносом системы на любую другую площадку рекомендую спросить:
- Какие новые связи и точки входа появятся?
- Какие учетные записи и привилегии понадобятся?
- Кто увидит события во всех задействованных контурах?
- Кто отвечает за обновления, уязвимости, копии и расследование?
- Что произойдет, если один из поставщиков или сегментов будет скомпрометирован?
Если ответы существуют только в головах нескольких инженеров, инфраструктура уже зависит от серых зон. А надежная гибридная модель отличается не количеством облаков и не сложностью схемы. Она отличается тем, что каждый доступ обоснован, каждое событие фиксируется и доступно для анализа, а у каждой операции есть ответственный.
