Организация имеет 10 аккаунтов AWS в AWS Organizations. В каждом аккаунте запущен AWS Config, и каждый аккаунт принадлежит либо к OU Prod, либо к OU NonProd. В каждом аккаунте есть правило EventBridge, которое уведомляет топик SNS, когда создается входящее правило группы безопасности EC2 с источником 0.0.0.0/0; команда безопасности подписана на этот топик SNS. Для всех аккаунтов OU NonProd команда безопасности должна удалить возможность создавать входящие правила группы безопасности, разрешающие 0.0.0.0/0. Какой подход позволяет достичь этого с НАИМЕНЬШИМИ операционными издержками?

Правильный ответ — создание политики управления сервисами (SCP), которая запрещает ec2:AuthorizeSecurityGroupIngress, когда aws:SourceIp равен 0.0.0.0/0, и применение этой SCP к OU NonProd. SCP — это мощный инструмент AWS Organizations для централизованного управления разрешениями в нескольких аккаунтах. Применение SCP к OU NonProd гарантирует, что ни один аккаунт в этой OU не сможет создать такое правило, что является превентивной мерой и имеет наименьшие операционные издержки, поскольку не требует постоянного мониторинга или автоматического исправления. Изменение правила EventBridge для вызова функции Lambda, которая удаляет некорректные правила, является реактивным подходом и требует больше операционных издержек на разработку и поддержку Lambda-функции. Присоединение управляемого правила AWS Config vpc-sg-open-only-to-authorized-ports не решает проблему напрямую, так как это правило проверяет открытые порты, а не конкретный источник 0.0.0.0/0, и также является реактивным. Создание SCP, которая разрешает ec2:AuthorizeSecurityGroupIngress только тогда, когда aws:SourceIp не равен 0.0.0.0/0, является неправильной логикой для запрета конкретного условия.