APRENDER. PRATICAR. EVOLUIR.1. Saber quem está abrangido pelo mecanismo
Começa por uma lista de contas, OUs, Regiões e canais de implementação. Uma conta movida para uma OU registada pode ainda não estar inscrita no Control Tower. Os controlos preventive da OU abrangem contas não inscritas, mas os detective e proactive não têm essa mesma cobertura. Um controlo proactive usa CloudFormation hooks; o resultado de um template não demonstra bloqueio de uma chamada direta que não atravessa esse mecanismo. Numa aquisição fictícia, a equipa de governação deve registar a inscrição pendente e os controlos compensatórios antes de declarar a conta integrada. Para cada requisito, escreve o mecanismo e a sua população real. Esta matriz torna visíveis lacunas que a posição da conta na hierarquia não revela.
2. Tratar drift como uma comparação delimitada
CloudFormation drift detection compara configurações suportadas com a definição gerida. NOT_CHECKED deve permanecer uma lacuna de avaliação, e uma stack IN_SYNC pode conter recursos sem suporte. As stacks aninhadas precisam de operação própria. Define explicitamente no template ou parâmetros uma propriedade suportada que pretendes acompanhar; confiar apenas no default do serviço pode deixá-la fora da comparação. No relatório ao comité, indica a população comparada, os recursos excluídos e o instante da observação. O exercício local separa estes estados em vez de converter qualquer resultado não vermelho em sucesso. O modelo não consulta CloudFormation e não conhece a configuração real. Serve para discutir que evidência falta antes de aceitar um conjunto de recursos.
3. Comparar também a referência central
Uma stack de um StackSet pode ser atualizada diretamente por CloudFormation com outro template. Os recursos podem continuar iguais à sua definição local e não apresentar drift, embora a baseline central seja diferente. Acrescenta uma comparação das versões e parâmetros aprovados para demonstrar uniformidade. Em FinOps surge um problema semelhante de população: um relatório de tags favorável não abrange necessariamente recursos que nunca tiveram uma tag de utilizador. Reconcilia a população do relatório com inventário adequado. Para reporting de chaves obrigatórias, a documentação aponta uma limitação da consola Resource Groups por conta e indica o relatório organizacional. Seleciona o modo de evidência que responde ao requisito; um painel disponível não é automaticamente o painel suficiente.
4. Escolher políticas e ensaiar o impacto
Uma RCP limita permissões de recursos abrangidos, mas não restringe chamadas de service-linked roles. Antes de expandir uma política, inclui integrações legítimas e pedidos que devem ser negados num piloto delimitado. Um teste interno isolado não demonstra compatibilidade de parceiros externos. Para um atributo de serviço suportado, uma declarative policy pode impor a configuração no plano de controlo em vez de manter uma lista de ações de API. A política efetiva e o âmbito continuam a precisar de revisão. O plano de retirada também importa: a documentação descreve o retorno do atributo ao estado anterior quando a política declarativa é removida. Identifica esse estado e o controlo substituto antes de tratar a retirada como uma tarefa administrativa simples.
5. Remediar o estado que existe agora
A remediação automática de Config pode arrancar com base num snapshot antigo. Um operador pode ter corrigido o recurso entre a avaliação e a execução. A recomendação operacional é consultar o estado atual, tornar a ação segura quando a correção já existe e registar a decisão de não repetir uma alteração desnecessária. Esta recomendação é uma inferência de desenho, não uma garantia de que qualquer runbook já a implementa. Numa corrida durante o fecho diário, retries adicionais podem multiplicar reinícios sem acrescentar valor. Para diagnosticar falhas, consulta o estado de execução com etapas, tempos e erros. Distingue configuração pretendida, avaliação histórica e resultado observado; cada um destes registos responde a uma pergunta diferente do gestor ou auditor.
6. Apresentar uma decisão com limites claros
Constrói o pacote de aceitação com requisito, referência aprovada, contas e recursos abrangidos, momento da observação, resultado e lacunas. Atribui responsável e próxima ação a cada lacuna relevante. Um subconjunto pode ser aceite quando a decisão define o âmbito e mantém acompanhamento dos restantes elementos; isso não autoriza declarar toda a plataforma conforme. Na passagem a RUN, confirma quem observa os controlos, quem pode alterar políticas e quem responde a falhas fora de horas. Na retirada de recursos, inclui dependências de políticas, evidência a conservar e condições do estado final. O resumo desta aula é separar intenção, aplicação, observação e decisão. Esta disciplina permite comunicar progresso real sem transformar ausência de alerta numa conclusão mais ampla do que os dados suportam.
# Original evidence inventory exercise, not CloudFormation drift detection.
# No credentials, network calls, or AWS changes.
def classify(row):
if row["status"] == "NOT_CHECKED":
return "needs-evidence"
if row["status"] == "DRIFTED":
return "deviation"
if row["status"] != "IN_SYNC":
return "unknown"
if row["template"] != row["approved_template"]:
return "baseline-mismatch"
return "matches-recorded-scope"
base = dict(status="IN_SYNC", template="v4", approved_template="v4")
assert classify(base) == "matches-recorded-scope"
assert classify({**base, "status": "NOT_CHECKED"}) == "needs-evidence"
assert classify({**base, "status": "DRIFTED"}) == "deviation"
assert classify({**base, "status": "FAILED"}) == "unknown"
assert classify({**base, "template": "local-v5"}) == "baseline-mismatch"
print("five evidence-scope cases passed; scope is not whole-platform compliance")
Uma stack sem drift usa uma referência local divergente; a aceitação exige comparar a baseline central e resolver os recursos não avaliados.
Armadilhas comuns
OU como inscrição; ausência de drift como uniformidade; relatório de tags como inventário completo; snapshot antigo como estado atual.
Tópicos relacionados: Telemetria e âmbito de investigação · Passagem a operação e critérios de aceitação
Uma conclusão precisa de declarar contra que referência e sobre que população foi obtida.
Referência: Control Tower terminology · SCS-C03