Главная мысль
Не концентрируйте защиту только на сетевой границе. Включите в проект сведения о владельце каждого ресурса, обращающихся к нему идентификаторах, обнаружении событий и восстановлении.
Распределите обязанности по модели сервиса
Для IaaS, PaaS и SaaS границы ответственности различаются. Для каждой рабочей нагрузки зафиксируйте уровни, которыми управляет провайдер, и клиентские области: аккаунты, данные, настройки и прикладные компоненты. Например, обновление ОС виртуальной машины может быть обязанностью клиента, тогда как часть нижних уровней управляемой платформы обслуживает провайдер. Не полагайтесь только на название сервиса: составьте матрицу ответственности с учётом фактической конфигурации и документации. Примеры ниже служат отправной точкой; точное распределение зависит от документации и конфигурации сервиса.
| Пример сервиса | Область провайдера | Проверка клиента |
|---|---|---|
| Виртуальная машина IaaS | Физическая инфраструктура и виртуализация | Гостевая ОС, приложения и разрешения |
| Управляемая платформа приложений | Уровни платформы и среды выполнения, определённые сервисом | Код приложения, данные, идентификаторы и доступные настройки |
| SaaS | Сервис приложения, которым управляет поставщик | Пользователи, совместный доступ, настройки тенанта и обработка данных |
Стройте сеть и доступ вокруг идентификации
Составьте карту сетевых сегментов, точек входа, API и связей между сервисами. Вместо доверия широким сетевым границам проверяйте идентичность пользователей и рабочих нагрузок и разрешайте каждому сервису только необходимые соединения. Ограничьте административные интерфейсы, проверьте, откуда и при каких условиях к ним возможен доступ. Сетевые фильтры важны, но они не заменяют разрешения аккаунтов и приложений.
Защитите приложение и данные на этапе проектирования
Определите, где данные создаются, хранятся и передаются в потоке приложения. Спланируйте аутентификацию, авторизацию, безопасное хранение секретов, шифрование и журналы аудита с учётом конфиденциальности. В мультитенантных сервисах проверьте изоляцию между клиентами и тенантами на уровне приложения, хранилища и доступа. Для serverless и контейнеров также назначьте владельцев среды выполнения, пакетов, сервисных аккаунтов и API. Сам перенос приложения в облако не обеспечивает эти меры автоматически.
Включите обнаружение, восстановление и управление изменениями
Заранее определите, по каким журналам расследуются события и кому поступают оповещения. Отслеживайте изменения конфигурации, храните правила и шаблоны под контролем версий, проверяйте влияние автоматического исправления нарушений на бизнес-процессы. Оценивайте резервное копирование и восстановление отдельно от доступности самого облачного провайдера. При архитектурном анализе рассматривайте вместе сценарии угроз, владельцев, эксплуатационные процессы и порядок восстановления.
Проверяйте шаблоны и границы ответственности поставщиков
Безопасные стартовые шаблоны и проверки CI/CD помогают командам повторно применять утверждённую конфигурацию. Документируйте исключения с причиной, владельцем и сроком действия; перед выпуском проверяйте привилегированный доступ, открытые сервисы и отсутствие секретов в коде. Для внешних SaaS, управляемых баз данных и интеграционных провайдеров уточните договорные и операционные обязанности: уведомление об инцидентах, экспорт журналов и зависимости восстановления.