Миграция в облако: почему в России это не просто «перенос серверов»

Миграция в облако — это не перенос серверов «как есть», а пересборка архитектуры под новые условия безопасности.

В России к этому добавляется целый пласт регуляторики: ИСПДн, КИИ, требования ФСТЭК и ФСБ, локализация данных и жёсткие ограничения на использование иностранных СЗИ и их компонентов.

С чего начинать?

Не с выбора провайдера и не с подбора средств защиты. Первый шаг — аудит того, что именно переносится:

• какие системы и данные они обрабатывают;

• под какую регуляторику попадают (ИСПДн, ГИС, КИИ и т.д.);

• какова их критичность для бизнеса;

• как их категорировать по значимости;

• какая предварительная оценка RTO/RPO по каждой категории

1. Локализация данных. Нужно проверять фактическое расположение дата-центров провайдера и фиксировать это в договоре.

2. Запрет иностранных СЗИ. К 2030 году доля отечественного ПО должна достигать 95% для госорганизаций и компаний с госучастием >50%, и 80% для коммерческих организаций ключевых отраслей экономики.

3. Приказ ФСТЭК № 117. С 1 марта 2026 года он расширил требования к ГИС и всем ИС госорганов, ввёл новые правила сертификации СЗИ, ужесточил требования к документированию происхождению всех компонентов, включая open source.

4. Обязательное взаимодействие с ГосСОПКА через сертифицированные шлюзы, личный кабинет, API, e-mail, телефон с 1 сентября 2026 года.

5. Актуализация модели угроз. ФСТЭК добавил в банк данных новые угрозы, связанные с контейнеризацией и облачными средами: атаки через API, риски управления доступом, утечки секретов.

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

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

Инструменты защиты в российском облаке: от Zero Trust до плана выхода

Российские облачные платформы значительно расширили встроенный ИБ стек, но полагаться только на «галочку в маркетплейсе» нельзя.

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

7 требований к архитектуре защиты:

1. Принцип Zero Trust. Ни одно действие не должно проходить без проверки, независимо от расположения внутри периметра. Многоуровневая аутентификация, детализированная авторизация, сегментация сети.

2. Многослойная модель предотвращения угроз. Двухслойная: слой провайдера (физика, гипервизор, сеть) + слой заказчика (приложения, данные, доступ, конфигурации).

3. Интеграция с существующими СЗИ заказчика и проверка их совместимости с облачными сервисами.

4. Шифрование end to end с контролем ключей. Ключи должны оставаться у владельца данных, а не у провайдера. Использование HSM модулей и внешних KMS.

5. Ротация секретов и контроль привилегий. При аудитах клиентов обнаруживается в среднем более 50% статических ключей, которые ротируются реже раза в год, в отдельных случаях — до 90% не ротируются вообще. В среднем 13% виртуальных машин доступны по внешнему IP адресу.

6. Единая система мониторинга. Сбор событий из всех источников — облачных и локальных — в единую SIEM. Без общего обзора угрозы, возникающие в разных частях инфраструктуры, сложнее обнаружить.

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

Почему это важно именно сейчас?

С 1 марта 2026 года приказ ФСТЭК № 117 перевёл защиту ГИС и ИС госорганов из модели «аттестовал и забыл» в режим непрерывного управления ИБ. Это значит, что архитектура должна быть готова к постоянным изменениям, новым угрозам и регулярным проверкам.

Интеграция СЗИ в облаке: 5 этапов проекта и распределение ролей

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

На каждом этапе чётко распределены роли заказчика, провайдера, интегратора и ИБ команд. Это снижает риски срывов, проблем с аттестацией и «серых зон» ответственности.

1. Аудит и планирование

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

• Провайдер/интегратор: проводит аудит, проектирует архитектуру, рассчитывает стоимость, подбирает сервисы.

Именно здесь закладывается соответствие приказу ФСТЭК № 117, требованиям к ГИС/КИИ и модели совместной ответственности.

2. Подготовка инфраструктуры и тестовая миграция

• Заказчик: предоставляет доступы к исходной инфраструктуре, согласовывает конфигурации безопасности, выделяет тестовые среды.

• Провайдер: развёртывает облачную инфраструктуру, настраивает сетевую связность, предоставляет маркетплейс образы СЗИ.

• Интегратор: настраивает NGFW политики, интегрирует SIEM, проводит миграцию данных.

На этом этапе проверяется совместимость российских СЗИ с облачной платформой и корректность работы в новой среде.

3. Миграция и настройка защиты

• Заказчик: отвечает за бизнес продолжительность, координирует переключение систем, утверждает окна миграции.

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

• Команда ИБ заказчика: настраивает прикладные политики безопасности, модели угроз, проводит комплаенс проверки.

• SOC команда: подключает мониторинг облачных событий, настраивает правила детекции.

Здесь реализуется принцип Zero Trust, шифрование end to end, ротация секретов и единый мониторинг.

4. Тестирование и аттестация

• Заказчик: организует тестирование, привлекает аттестующую организацию (с лицензией ФСТЭК).

• Провайдер: предоставляет тестовые среды, техническое сопровождение, подтверждает соответствие инфраструктуры требованиям.

• Аттестующая организация: проводит пентест и аттестационные испытания, выдаёт аттестат соответствия.

С 2026 года аттестация ГИС и ИС госорганов проводится уже по новым требованиям приказа № 117.

5. Промышленная эксплуатация и непрерывный мониторинг

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

• Провайдер: поддерживает доступность и безопасность платформы, обновляет инфраструктурные СЗИ, обеспечивает работу SOC.

• SOC сервис: круглосуточный мониторинг инцидентов, поведенческая аналитика, автоматизированное реагирование.

Это уже не разовый проект, а непрерывный процесс управления ИБ в облаке.