Главная мысль
Единая панель не доказывает, что один и тот же контроль работает на всех платформах. Сформулируйте общее требование, проверьте его реализацию у каждого провайдера и назначьте владельцев пробелов.
Создайте общий инвентарь и цели контроля
Ведите единый инвентарь аккаунтов AWS, подписок Azure и проектов Google Cloud вместе с их связями и владельцами. Определите общие поля: рабочая нагрузка, класс данных, доступный из интернета интерфейс, критичные зависимости и владелец восстановления. Затем задайте базовые результаты для всех провайдеров: например, защиту привилегированного доступа, хранение журналов и проверку резервных копий. Внутренняя политика может быть единой, но конкретные параметры сервисов в каждом облаке придётся применять по-разному.
| Общая цель | Проверка для конкретного провайдера | Подтверждение эффективности |
|---|---|---|
| Привилегированный доступ | Настройки ролей, доверия и MFA | Проверка разрешённого и запрещённого действия |
| Защищённое хранилище | Настройки публичного доступа, политик и ключей | Тест доступа и конфигурация |
| Пригодные для работы журналы | Выбор событий, экспорт и срок хранения | Доступное для поиска событие с исходным контекстом |
| Восстановление | Зависимости сервиса, копии и путь восстановления | Результат учений |
Согласуйте идентификацию и учётные данные рабочих нагрузок
Предоставляйте доступ к облачным ролям через центральную идентификацию и ведите таблицу соответствия ролей, групп и политик доверия отдельных провайдеров. Отдельно проверяйте пользовательские аккаунты, сервисные идентификаторы, задачи CI/CD и межаккаунтное принятие ролей. Предпочитайте временные учётные данные; если нужен статический ключ, укажите владельца, место хранения, назначение и дату отзыва. Не предполагайте, что одинаковый рабочий идентификатор имеет одинаковые права у каждого провайдера.
Объедините видимость и контроль данных
Направляйте журналы провайдеров в общий анализ, но сохраняйте исходный источник и специфичные поля, чтобы не потерять смысл события при расследовании. Проверяйте правила конфигурации в каждом аккаунте, подписке и проекте; для исключений назначайте владельца и срок. Для потоков данных проверяйте шифрование, управление ключами, резервное копирование и ограничения регионов для каждого сервиса. Не предполагайте, что средство одного провайдера работает в другом облаке или автоматически охватывает все ресурсы.
Проверьте реагирование и восстановление между провайдерами
В плане реагирования храните действия для каждой платформы: точечно ограничить скомпрометированный доступ к аккаунту, сократить разрешения роли, экспортировать журналы, ограничить сеть и связаться с поддержкой провайдера. Сигнал в одном облаке может не показать атаку, затронувшую другие среды; отрабатывайте взаимодействие общего руководителя инцидента и специалистов платформ. Разделяйте тесты восстановления по аккаунтам и сервисам, проверяйте перенос данных и зависимости приложения. Обновляйте тесты при изменении политик и автоматизации. Сохраняйте доказательства и доступ для восстановления.
Защитите API и обмен данными
Для связей приложений между облаками проверьте, от имени какого идентификатора каждый сервис отправляет запросы и какие данные он может читать или изменять. Выбирайте аутентификацию API, проверку разрешений, ротацию секретов, ограничение частоты запросов и аудит с учётом риска приложения. Подтвердите, в каких регионах хранятся и копируются чувствительные данные; перенос ресурса между облаками сам по себе не подтверждает соблюдение юридических и договорных требований.