APRENDER. PRATICAR. EVOLUIR.Percorrer a hierarquia antes de alterar acessos
Começa por registar conta, principal, ação, recurso, contexto e hora. Neste exercício consideramos apenas a barreira SCP de uma conta membro; assumimos que as restantes políticas permitem a ação. Em cada nível da cadeia root, OUs e conta, procura pelo menos um Allow aplicável. As permissões permitidas por políticas no mesmo nível combinam-se; depois são limitadas pelos restantes níveis. Um Deny aplicável em qualquer ponto da cadeia impede a ação. Este método evita interpretar uma única política isoladamente. No caderno do laboratório, escreve uma linha por nível e identifica a primeira condição que falta. Não elimines a política inteira para experimentar. Produz uma proposta de alteração restrita, um teste positivo e um teste negativo que confirme a manutenção da restrição pretendida.
Exercício guiado: entrada numa OU de produção
Uma conta fictícia de reconciliação sai de Sandbox e entra em Fundos. No destino, o root permite tudo, a OU Fundos permite apenas s3:GetObject e a conta permite tudo. Uma role já autorizada por IAM tenta s3:PutObject. Falta o Allow na OU Fundos, pelo que o pedido fica bloqueado nesse limite. Acrescentar um Allow só à conta não resolve. Se a mesma OU tiver também FullAWSAccess, o Allow restrito deixa de limitar o conjunto por si só. Discute estas duas variantes separadamente. Antes da mudança, recolhe operações usadas pelos jobs de fecho, aprova a matriz de acessos e ensaia numa conta representativa. Durante a janela, confirma o principal real e compara o resultado com a previsão. Um teste com credenciais administrativas diferentes não demonstra que a role de produção funciona.
Delegação e origem das identidades
Distingue administração de acessos, configuração da fonte de identidades e acesso à conta de gestão. O administrador delegado do IAM Identity Center não pode alterar um permission set provisionado na conta de gestão. Na situação fictícia, o permission set NightSupport foi reutilizado aí e em contas membro; a equipa deve separar o acesso de gestão e encaminhar a alteração pelo administrador autorizado. Se o IdP externo for a origem dos grupos, alterações locais podem ser sobrescritas pela sincronização. Identifica quem aprova pertenças a grupos e quem pode emitir tokens SCIM. No handover, apresenta esta cadeia ao turno APS com contactos e critérios de escalada. Evita resolver um incidente criando uma segunda origem informal de identidades que ninguém mantém.
Comportamento do controlo e prova de aceitação
Regista o mecanismo, o âmbito e o resultado esperado de cada controlo. Um controlo detective assinala desvios; isso não demonstra que impediu a criação. Um controlo proativo usa hooks do CloudFormation e aplica-se aos recursos provisionados por esse caminho. Uma alteração direta pela API precisa da sua própria análise de cobertura. O guia consultado indica também que, a partir da landing zone 4.0, os controlos obrigatórios já não são aplicados por predefinição. Confirma versão e estado efetivo em vez de concluir que o nome obrigatório prova ativação. Para o comité de mudança, prepara quatro colunas: requisito, mecanismo, teste observado e responsável pelo desvio. Esta matriz permite decidir uma exceção temporária com prazo sem apresentar a landing zone como prova automática de conformidade.
SCP worksheet (fictional; not deployable policy)
ROOT Allow:*
OU/FUNDS Allow:s3:GetObject
ACCOUNT Allow:*
REQUEST s3:PutObject
OTHER AUTHORIZATION: assumed sufficient
EXPECTED SCP RESULT: blocked at OU/FUNDSA mudança de OU é aceite apenas após testar a role do batch, a restrição que deve continuar ativa e o percurso de escalada do turno noturno.
Armadilhas comuns
Ler apenas uma SCP; confundir políticas no mesmo nível com níveis sucessivos; assumir que delegação permite alterar acesso de gestão; tratar um alerta como bloqueio.
Tópicos relacionados: Rollouts e evidência operacional
O alcance e a combinação dos controlos precisam de ser demonstrados no percurso real da operação.
Referência: SCP evaluation · SAP-C02