«Безопасность после миграции в облако, это не продолжение локальной политики с поправкой на абстракцию, а полностью новая игра. Если вы не перестраиваете логику контроля с нуля, ориентируясь на идентичность и политики как на границы, то вы просто перемещаете старые проблемы в более динамичную и уязвимую среду. Большинство команд забывает, что облако, это не просто другой дата-центр.»
Почему старые подходы безопасности не работают в облаке
Традиционная безопасность строилась на концепции периметра: сетевые экраны защищали границы центра обработки данных. Внутри этого доверенного периметра всё считалось относительно безопасным. Облачная среда эту модель полностью инвертирует. Здесь нет фиксированного периметра. Рабочие нагрузки, контейнеры, бессерверные функции и пользователи могут появляться и исчезать в любой точке мира за секунды.
Главный провал при миграции — попытка механически перенести правила сетевых экралов (ACL) в облачные группы безопасности. Команды продолжают думать о IP-адресах и портах, тогда как в облаке ключевой единицей становится идентичность — сервисный аккаунт, роль IAM, контейнер или функция. Атака теперь редко начинается снаружи; она разворачивается внутри, через скомпрометированные учетные данные или излишне разрешительные политики доступа.
Уязвимость №1: Слепое доверие к облачному провайдеру и забытый shared responsibility model
Классическое заблуждение: «За безопасность инфраструктуры отвечает облачный провайдер». На практике модель разделённой ответственности (shared responsibility model) делит зоны контроля. Провайдер отвечает за безопасность облака как услуги (физические ЦОДы, гипервизор). Вы несёте ответственность за безопасность в облаке — свои данные, управление доступом, конфигурацию сетевых правил, шифрование.
Самый частый промах — отключенное логирование и аудит ключевых сервисов. Например, без включенных и корректно настроенных Cloud Audit Logs или их аналогов у других вендоров вы летите вслепую. Вы не увидите, кто, когда и откуда получил доступ к вашим данным, какие изменения политик были произведены.
.
Уязвимость №2: Дикие политики IAM и роль «владельца проекта»
В пылу миграции для скорости часто создают сервисные аккаунты или роли с разрешениями по принципу «на всякий случай» — например, дают роль editor или даже owner для всего проекта. Это эквивалент выдачи мастер-ключа от всего офиса стажёру на неделю.
Мало кто сразу настраивает принцип наименьших привилегий (Principle of Least Privilege). Редко используются кастомные роли, собранные строго под конкретную задачу. Ещё реже — регулярный аудит выданных прав с помощью инструментов вроде Policy Analyzer или сторонних решений.
- Сервисный аккаунт для CI/CD с правами на деплой в одну папку хранилища не должен иметь доступ на чтение всех секретов или право создавать новые экземпляры виртуальных машин.
- Роль разработчика не должна включать разрешение на изменение правил межсетевого экранирования или управление сервисными аккаунтами.
Без жёсткого контроля за IAM скомпрометированный ключ одного сервиса может привести к цепной реакции и захвату всей среды.
.
Уязвимость №3: Неуправляемые публичные ресурсы и забытые bucket’ы
Облачное хранилище — постоянный источник утечек. В процессе миграции создаются временные бакеты для переноса данных, тестовые веб-сайты на статических хостингах. Часто на них оставляют публичный доступ на чтение (public-read), а после завершения работ забывают.
Через несколько месяцев эти ресурсы, содержащие резервные копии, логи, конфигурационные файлы, остаются открытыми для всего интернета. Автоматические сканеры находят их раньше, чем ваша команда безопасности. Риск усугубляется, если в именах бакетов используется предсказуемая логика (например, companyname-backups-2024), что облегчает их поиск.
Уязвимость №4: Сетевая изоляция «как было» и пренебрежение сегментацией
Многие воссоздают в облаке плоскую сетевую структуру, похожую на локальную VLAN, где все виртуальные машины в одной сети могут общаться друг с другом. Это противоречит принципу Zero Trust. Если злоумышленник проникает на одну машину (например, через уязвимость в веб-приложении), он получает возможность сканировать и атаковать соседние сервисы — базы данных, системы управления.
Правильный подход — сегментация на уровне сетей VPC/подсетей и строгие правила групп безопасности. Сервис фронтенда не должен иметь прямого сетевого пути к базе данных. Взаимодействие должно происходить через внутренние балансировщики нагрузки или приватные эндпоинты.
Уязвимость №5: Шифрование данных «на лету» и «в покое» — не как требование, а как опция
В спешке миграции шифрование часто откладывают «на потом». Данные переносятся и хранятся в незашифрованном виде по умолчанию. При этом полагаются на шифрование, предоставляемое провайдером по умолчанию (encryption at rest), что не всегда соответствует требованиям регуляторов, если контроль над ключами шифрования остаётся у провайдера.
Для соответствия требованиям ФСТЭК и 152-ФЗ часто необходимо использование клиентского (customer-managed) шифрования, где ключи генерируются и хранятся на вашей стороне, в аппаратных модулях безопасности (HSM) или управляемом сервисе ключей. Настройка такого шифрования постфактум — сложная и рискованная операция.
Что делать: чек-лист безопасности после миграции
Не пытайтесь закрыть всё сразу. Начните с самого критичного.
- Включите и настройте аудит. Активируйте логи всех критичных сервисов (управление доступом, сетевые операции, доступ к данным). Настройте маршрутизацию логов в отдельный, защищённый проект или стороннюю SIEM-систему для анализа.
- Ревизия IAM. Проведите инвентаризацию всех пользователей, сервисных аккаунтов и ролей. Отзовите неиспользуемые ключи. Для каждой роли убедитесь в соответствии принципу наименьших привилей. Внедрите обязательный ревью политик при создании.
- Сканирование на публичные ресурсы. Запустите автоматизированное сканирование (с помощью инструментов провайдера или сторонних) на наличие открытых бакетов хранилища, баз данных с публичным IP, неправильно сконфигурированных групп безопасности.
- Внедрение сетевой сегментации. Спроектируйте и внедрите схему изолированных сетей для разных типов нагрузок (фронтенд, бэкенд, БД, управление). Запретите коммуникацию по умолчанию, разрешайте только необходимое правилами.
- План по шифрованию. Определите, какие данные требуют клиентского шифрования. Начните пилот с самого критичного класса данных (персональные данные, финансовые отчёты). Внедрите управление ключами.
- Автоматизация проверок (Security as Code). Описывайте инфраструктуру через IaC (Terraform, Pulumi). Внедряйте в CI/CD этапы статического анализа кода инфраструктуры на наличие небезопасных конфигураций (с помощью Checkov, Terrascan и т.п.) перед применением.
Итог: Безопасность, это новая архитектура, а не дополнение
Успешная миграция в облако измеряется не только работоспособностью перенесённых сервисов, но и устойчивостью новой среды к угрозам, которые в локальной инфраструктуре были невозможны или маловероятны. Забыть о безопасности — значит создать систему, которая изначально спроектирована с уязвимостями. Безопасность в облаке, это не пункт в списке дел после миграции. Это фундаментальный принцип, который должен быть заложен в архитектуру, процессы и культуру работы с первого дня проектирования перехода.