Сообщество RSS DEV
Подписаться
Одна организация или много? Разбор полетов, который никто не хочет писать
Финансовое учреждение объединило свои бизнес-подразделения под единой организацией AWS для управления расходами, но ошибка при применении политики контроля служб (SCP) к корневому узлу привела к 47-минутному сбою в работе производства. Давление, связанное с необходимостью консолидированного контроля затрат, единого применения политик и упрощения автоматизации, привело к этому архитектурному решению. Попытка команды безопасности ограничить регионы AWS для соблюдения нормативных требований, применив SCP к корневому узлу, непреднамеренно заблокировала критически важные вызовы DynamoDB для платежного конвейера. Это произошло потому, что платежный аккаунт использовал конечную точку DynamoDB Global Tables в заблокированном регионе, и ошибка осталась незамеченной первоначальным мониторингом.
Хронология инцидента показывает постепенный сбой, от ошибок SDK до срабатывания защитных механизмов и, наконец, оповещения, которое первоначально направило усилия по устранению неполадок по ложному пути. Первопричиной было определено отсутствие ограничений радиуса поражения по дизайну, обусловленное архитектурой единой организации, а не только человеческой ошибкой. В этой конструкции отсутствовала изоляция между регулируемыми рабочими нагрузками, такими как платежи, и операционными рабочими нагрузками. Единая организация с иерархическими SCP означает, что любая SCP на корневом уровне одновременно затрагивает все аккаунты без возможности нативного поэтапного отката.
В тексте противопоставляется этот проблемный шаблон единой организации и исправленный подход с несколькими организациями, который обеспечивает более надежные границы изоляции. Несколько организаций предлагают независимые жизненные циклы политик, отдельные учетные данные управляющего аккаунта и более четкую регуляторную изоляцию, которую аудиторы принимают более охотно. Хотя несколько организаций увеличивают операционную сложность и дублирование автоматизации посадочной зоны, эти проблемы решаемы. Немедленное техническое исправление включало внедрение SCP-ограничения для предотвращения прикрепления политик к корневому узлу или критическим организационным единицам.
В среднесрочной перспективе была создана вторая организация AWS для рабочих нагрузок, соответствующих PCI-DSS, что повысило безопасность и независимость политик. Наблюдаемость была улучшена путем захвата событий AWS Organizations в Slack и PagerDuty, что значительно сократило среднее время обнаружения. Основная проблема с SCP заключается в их немедленном распространении и отсутствии этапов тестирования или автоматического отката, в отличие от типичного кода инфраструктуры. Для решения этой проблемы был внедрен реестр неизменяемого состояния для SCP, позволяющий автоматизировать откаты в течение нескольких секунд.
