Uma AWS Organization tem uma única OU chamada Production que contém todas as contas. SCPs de deny-list no nível raiz são usados para restringir o acesso a determinados serviços. Uma conta recém-convidada de uma unidade de negócios adquirida não consegue atualizar as regras existentes do AWS Config para cumprir a política da empresa. Qual abordagem permite que os administradores da nova conta façam as alterações necessárias agora, preservando e aplicando as políticas existentes com o mínimo de manutenção contínua?

A criação de uma OU de Onboarding temporária permite isolar a nova conta para aplicar permissões específicas. Anexar um SCP a esta OU que permita as ações do AWS Config resolve o problema imediato. Mover os SCPs de deny-list da raiz para a OU Production garante que as políticas existentes continuem a ser aplicadas às contas de produção, enquanto a nova conta tem a flexibilidade necessária. Após as alterações, mover a conta para a OU Production a coloca sob as políticas padrão da empresa com o mínimo de manutenção contínua. As outras opções são menos ideais: Remover SCPs da raiz enfraquece a segurança para toda a organização. O Service Catalog é uma solução de longo prazo, não para um problema imediato de permissão. Criar uma OU de Onboarding e permitir o AWS Config, mas manter os SCPs de deny-list na raiz, significa que o deny-list da raiz ainda pode bloquear as ações, pois SCPs de deny-list são avaliados primeiro e podem sobrepor permissões de allow-list em níveis mais baixos. Converter para SCPs de allow-list na raiz é uma mudança significativa que exige uma análise completa de todos os serviços necessários, o que é complexo e propenso a erros, e não é uma solução rápida para este problema específico.