«Когда регулятор смотрит на облако, он видит сервер, а не услугу. Это фундаментальная ошибка, которая заставляет тратить миллионы там, где можно было просто подписаться. Безопасность как подписка – это не о том, чтобы снять с себя ответственность, а о том, чтобы перестать изобретать велосипед, который уже давно катится у провайдера».
Облачная парадигма изменила всё, кроме нашего подхода к соблюдению регуляторных требований. По-прежнему в голове у многих специалистов по информационной безопасности и регуляторике стоит образ: если у нас есть сервер, то на нём нужно развернуть СЗИ, вести журналы, проводить аттестацию. Облако же ломает эту логику, подменяя владение сервером правом на его использование. Российские провайдеры уже предлагают готовые решения, но мы смотрим на них сквозь призму устаревших инструкций ФСТЭК. Модель «безопасность как подписка» (Security-as-a-Service, SecaaS) – это не маркетинг, а способ примирить гибкость облака с жёсткостью 152-ФЗ.
Почему «облачная» регуляторика отличается от «серверной»
Ключевое различие лежит в плоскости ответственности. В классической модели ЦОД или собственной серверной вы контролируете всю цепочку: от физического доступа к стойке до версии ядра ОС на виртуальной машине. Вы несёте полную ответственность перед ФСТЭК за выполнение всех требований. В публичном облаке провайдер берёт на себя часть этой ответственности согласно модели разделённой ответственности.
Для российского ИБ-специалиста критически именно провайдер сертифицировал по требованиям ФСТЭК. Обычно это инфраструктурный уровень: физическая защита дата-центров, сетевое оборудование, гипервизоры, платформы хранения. Ваш виртуальный сервер (ВМ), работающий поверх этой сертифицированной инфраструктуры, с точки зрения регулятора – это всё ещё ваша зона ответственности. Именно здесь возникает главная ловушка: желание на каждую такую ВМ установить «коробочное» средство защиты информации, как на физический сервер.
Но облачная логика предлагает иной путь: использовать защиту, встроенную в саму облачную платформу, и оплачивать её по подписке. Вместо того чтобы лицензировать десятки экземпляров межсетевого экрана, вы настраиваете Security Groups или облачный фаервол как сервис. Вместо агента DLP на каждой машине – API-интеграция с облачным сервисом анализа трафика. Ответственность за корректную работу, масштабирование и обновление этого функционала лежит на провайдере. Ваша задача – корректно его сконфигурировать в соответствии с вашей моделью угроз и требованиями регулятора.
Модель SecaaS в контексте российских облаков и 152-ФЗ
Концепция «безопасность как подписка» реализуется отечественными провайдерами в нескольких ключевых плоскостях, каждая из которых должна быть оценена с точки зрения соответствия требованиям регуляторов.
Защита периметра и сегментация
Облачные провайдеры предлагают в качестве сервиса гибкие механизмы микросегментации. Это не просто аналоги классических МСЭ, а системы, глубоко интегрированные с программно-определяемой сетью (SDN) провайдера. Важно выяснить, имеет ли данный функционал сертификат ФСТЭК как средство защиты информации. Если нет, то его использование для защиты информации, составляющей государственную тайну, или в АСУ ТП критической информационной инфраструктуры (КИИ) невозможно. Однако для коммерческих систем защиты персональных данных (для УЗ 1-3) он может применяться, но его эффективность должна быть обоснована в рамках модели угроз и системы менеджмента информационной безопасности (СМИБ).
Шифрование данных
Провайдеры часто предлагают управляемые сервисы шифрования как для данных в хранилищах (object storage, managed databases), так и для блочных томов, прикрепляемых к ВМ. Ключевой вопрос – управление ключами шифрования (KMS). Решение, при котором ключи полностью находятся под контролем провайдера, для строгих требований не подходит. Российский регулятор ожидает, что у заказчика будет собственный, изолированный контроль над ключами. Современные облака предлагают опцию Customer Managed Keys, где вы используете облачный KMS, но корневые ключи генерируете и ротируете сами, а провайдер не имеет к ним доступа. Это пример того, как подписка даёт технологию, но контроль над критическим параметром остаётся у вас.
Мониторинг и реагирование на инциденты (SIEM/SOAR как сервис)
Это одна из самых перспективных областей. Вместо развёртывания громоздкой инфраструктуры SIEM (например, на базе Elastic Stack или ArcSight) и содержания команды аналитиков, можно подключить облачный сервис мониторинга. Он агрегирует логи с ваших ВМ, сетевых интерфейсов, сервисов идентификации и предоставляет готовые дашборды, корреляции и алерты. С точки зрения 152-ФЗ и Приказа № 21 ФСТЭК, такой сервис должен обеспечивать необходимую глубину хранения журналов (не менее 6 месяцев для УЗ 1) и иметь механизмы защиты самой журнальной информации от модификации. Важно проверить, может ли провайдер предоставить сертификат на данный сервис или заключение ФСТЭК о соответствии.
Типовые ошибки при переходе на SecaaS и как их избежать
Стремление к облачной экономии и простоте часто приводит к просчётам в области соблюдения регуляторных норм.
- Ошибка делегирования ответственности. Покупка подписки на «защищённый облачный хостинг» не снимает с вашей организации обязанности по проведению оценки уязвимостей, анализу защищённости и аттестации объекта информатизации. Вы лишь меняете объект оценки: теперь вы проверяете не свои серверы, а вашу конфигурацию облачных сервисов. Документы провайдера (сертификаты, заключения по СВТ) становятся приложениями к вашей собственной документации по ИБ.
- Игнорирование конфигурационного дрейфа. Гибкость облака позволяет разработчикам или администраторам в пару кликов открыть порт, создать новое хранилище или изменить политику доступа. Без автоматизированного контроля соответствия (Cloud Security Posture Management – CSPM) ваша изначально безопасная конфигурация через месяц может превратиться в «швейцарский сыр». Подписка на CSPM-сервис или использование встроенных сканеров конфигурации – обязательный элемент.
- Неверная трактовка сертификатов провайдера. Наличие у облачной платформы сертификата ФСТЭК не означает автоматической сертификации всех развернутых на ней вами ВМ. Сертифицирована базовая платформа. Ваша задача – доказать в рамках аттестационных испытаний, что вы используете её разрешённым образом и добавляете необходимые (если требуются) сертифицированные СЗИ на уровне гостевых ОС или приложений.
Практические шаги для внедрения SecaaS с учётом ФСТЭК
- Картирование требований. Выпишите конкретные требования 152-ФЗ, приказов ФСТЭК № 17, 21, 31, относящиеся к вашей системе. Для каждого требования определите, может ли оно быть закрыто встроенным сервисом провайдера (например, аудит, резервное копирование), требует ли дополнения сертифицированным СЗИ или остаётся полностью на вашей стороне (например, организационные меры).
- Технический диалог с провайдером. Запросите не маркетинговые буклеты, а детальные архитектурные схемы, описания сервисов безопасности и, что критически важно, пакет документов для регулятора: действующие сертификаты ФСТЭК на СВТ, заключения о соответствии инфраструктуры, образцы журналов событий безопасности.
- Пилотный проект и документирование. Разверните тестовый контур, максимально использующий SecaaS. Опишите его в техническом проекте (ТП) и разделе «Система защиты информации» (СЗИ) как единый комплекс: «Защита обеспечивается использованием сертифицированной облачной платформы «Провайдер Х» (сертификат №…), её встроенных сервисов безопасности (фаервол, WAF, шифрование) и дополнительно установленного на ВМ сертифицированного СЗИ «Y» для защиты от НСД». Пропишите зоны ответственности.
- Интеграция в процессы. Настройте автоматические уведомления от облачных сервисов мониторинга в ваш тикет-систему. Включите проверки конфигурации безопасности облака в регламент регулярного контроля. Обновите инструкции для администраторов, запрещающие ручное изменение правил безопасности в обход процедур Change Management.
Модель «безопасность как подписка» в российских реалиях – это не отказ от контроля, а его трансформация. Вместо управления железяками и патчами фокус смещается на управление политиками, конфигурациями и процессами в рамках возможностей, предоставляемых провайдером. Это требует от ИБ-специалиста глубокого понимания как облачных технологий, так и буквы регуляторных требований. Правильно выстроенная, такая модель позволяет не просто соответствовать 152-ФЗ, но и получить реальное конкурентное преимущество за счёт скорости развёртывания и экономии на капитальных затратах, переводя их в предсказуемые операционные расходы.