Главная мысль
Сначала определите, кто отвечает за каждый ресурс. Затем ограничьте доступ, защитите данные, регистрируйте изменения и проверяйте восстановление.
Управляйте аккаунтами и идентификацией
Составьте список аккаунтов AWS для production, тестирования и архивов журналов и назначьте технического владельца каждому из них. Предоставляйте доступ людям через централизованную идентификацию; для рабочих нагрузок по возможности используйте роли IAM и временные учётные данные вместо постоянных ключей. Ограничивайте разрешения необходимым для роли минимумом, защищайте привилегированный доступ многофакторной аутентификацией и регулярно проверяйте неиспользуемые учётные записи, роли и ключи. Не используйте root-аккаунт для повседневных задач.
Проверьте данные и доступность ресурсов
Зафиксируйте чувствительность данных и обоснование их публичной доступности, если она необходима. Для S3 проверьте Block Public Access, политики bucket и Object Ownership. Режим Bucket owner enforced отключает ACL; проверяйте ACL только при их использовании, не включайте их ради этой проверки. Документируйте исключения и получайте подтверждение владельца данных. Убедитесь, что чувствительные данные шифруются при хранении и передаче, и определите, кто использует и администрирует ключи. Храните секреты приложений в утверждённой системе управления секретами, а не в коде. Выбирайте параметры шифрования и политики ключей с учётом сервиса: одна настройка не устраняет все риски ресурсов AWS.
Регистрируйте изменения и контролируйте базовую конфигурацию
Настройте регистрацию действий через AWS API с помощью CloudTrail и направляйте журналы в централизованное хранилище с ограниченным доступом; выберите необходимые типы событий. Используйте AWS Config или подходящее средство контроля, чтобы фиксировать конфигурацию ресурсов и обнаруживать отклонения от утверждённой базовой линии. Назначьте команду, отвечающую за оповещения, и порядок эскалации. Сама регистрация не останавливает инцидент: отдельно проверяйте полноту, хранение, поиск и практическое использование журналов. Различайте управленческие события и выбранные события данных, например чтение и запись объектов S3. Для трасс CloudTrail (trails) и хранилищ событий данных регистрация событий данных по умолчанию выключена; проверьте селекторы для нужных ресурсов и операций.
| Вопрос | Проверяемые данные | Что ещё проверить |
|---|---|---|
| Административное изменение | Запись управленческого события | Охват аккаунтов и регионов, срок хранения |
| Чтение и запись объекта | Запись выбранного события данных | Охват селекторов событий |
| Отклонение конфигурации | История конфигурации или отклонение от базовой линии | Владелец и исправление |
| Восстановление | Результат восстановления | Зависимости и измеренные результаты восстановления в сравнении с целевыми показателями |
Защитите рабочие нагрузки и восстановление
Для IaaS-ресурсов, например EC2, определите обязанности клиента по гостевой ОС, приложениям, сетевым правилам и исправлениям. Выберите средство сканирования, которое обнаруживает активы и поддерживает актуальность данных об уязвимостях; направляйте результаты ответственному владельцу и в плановое окно обновления, поскольку сканирование само по себе не устраняет уязвимость. Создавайте новые среды из проверяемых шаблонов инфраструктуры как кода, анализируйте изменения и ищите неожиданные открытые порты, публичные хранилища, избыточные разрешения и устаревшие пакеты. Храните резервные копии так, чтобы инцидент не затронул их одновременно с исходными данными, и проводите проверку восстановления. В управляемых сервисах граница ответственности зависит от конкретного сервиса; сверяйтесь с его документацией.
Планируйте устойчивость и безопасные изменения
Размещение копий в разных зонах доступности может снизить влияние отказа, только если приложение, зависимости и репликация данных настроены соответствующим образом. Для критичных сервисов проверьте зависимости, проверки работоспособности и переключение трафика; защищайте резервные копии отдельно. Распределение по зонам и репликация не заменяют изолированные копии для восстановления и проверку восстановления. Выпускайте изменения шаблонов инфраструктуры после проверки и с планом отката. Выберите цель восстановления для конкретного сервиса и класса данных и проверьте её на учениях.