APRENDER. PRATICAR. EVOLUIR.1. Escrever o âmbito como requisito
Uma política central não protege automaticamente todos os recursos que a equipa tem em mente. Em Firewall Manager, a seleção de contas combina-se com tipos e tags de recursos. ALL e ANY representam escolhas diferentes; a correspondência de tags usa chave e valor e um valor omitido é uma string vazia. Transforma o pedido de negócio numa lista de exemplos dentro e fora do âmbito. Inclui uma conta nova, uma tag ausente e um recurso que muda de OU ou de valor de tag. No relatório, apresenta a população esperada e a observada. Esta comparação ajuda a encontrar exclusões acidentais antes de a equipa usar uma percentagem de conformidade como prova de cobertura completa.
2. Definir quem mantém o estado
Se Terraform cria uma regra e Firewall Manager a remove, duas ferramentas estão a defender intenções diferentes. Aumentar retries não resolve ownership. Alinha a configuração ou define âmbitos mutuamente exclusivos, usando exceções limitadas e aprovadas quando necessárias. Sair do âmbito também não significa que todas as proteções desaparecem: por defeito, um ALB pode manter a web ACL se a remoção automática não estiver selecionada. O plano de migração deve dizer que associação ficará, quem a gere e como se confirma o estado após os ciclos das duas ferramentas. Durante uma janela curta, é preferível uma reversão definida ou correção limitada a uma desativação global sem inventário. Regista a dívida operacional se o handover for faseado.
3. Ler o caminho das SCPs
Para uma ação passar o limite de SCP, precisa de Allow em cada nível do caminho entre root, OUs e conta, sem Deny aplicável. Dentro do mesmo nível, vários Allows podem combinar-se; um Allow amplo pode anular a intenção de uma allowlist mais curta nesse nível. Em níveis diferentes, um Allow inferior não preenche uma omissão superior nem ultrapassa um Deny herdado. Desenha o caminho efetivo da conta antes de alterar IAM. Uma conta membro administradora delegada continua sujeita às SCPs aplicáveis; a delegação não a transforma em management account. O ensaio deve incluir dependências operacionais, como recolha de evidência e recuperação, para evitar que uma política de segurança interrompa a própria capacidade de resposta.
4. Manter a avaliação e a evidência
Um conformance pack é gerido pelo serviço. Editar diretamente a stack subjacente pode criar drift e regras difíceis de remover; usa o mecanismo do pack e investiga falhas pelo estado e eventos. Eliminar o pack remove regras, remediações e resultados, pelo que a evidência necessária deve ser preservada antes. A eliminação é assíncrona. Se suspenderes recording de ResourceCompliance para reduzir CIs durante essa operação, regista a lacuna de histórico e acompanha a reposição após conclusão. No reporting, o score é uma proporção de combinações regra-recurso: 18 em 20 e 90 em 100 são ambos 90%, mas representam populações diferentes. Reporta denominador, âmbito e falhas concretas, sem apresentar o número como certificação legal.
5. Controlar novos envios sem inventar rollback
Na resposta a incidentes, Systems Manager Automation pode aplicar um runbook a vários alvos. MaxConcurrency limita a simultaneidade e MaxErrors controla quando deixam de ser lançados novos alvos após erros. Com zero, a primeira falha recebida trava novos envios; não impede iniciar o primeiro alvo. As execuções já em curso podem continuar e falhar. O modelo local desta aula separa conclusão da frota de paragem de envio para tornar essa diferença visível. Não simula o scheduler AWS nem calcula percentagens de erros. Em produção, consulta os estados reais antes de repetir, cancelar ou declarar recuperação. Uma observação que demora mais do que o esperado não é evidência de que a operação terminou.
6. Fixar a execução e preparar o fecho
Uma versão numérica de DocumentVersion permite executar a revisão ensaiada. DEFAULT e LATEST podem apontar para uma revisão diferente quando a janela começar. Regista também parâmetros, alvos, role e controlos por localização: TargetsMaxConcurrency e TargetsMaxErrors têm precedência sobre os valores gerais quando fornecidos. O fecho precisa de evidência por alvo, efeitos produzidos, falhas, recuperação e operações ainda vivas. Comunica à gestão a diferença entre parar novos envios e concluir contenção. Se houver alvos pendentes, mantém responsável e próximo ponto de situação. Termina a retrospetiva com uma alteração concreta no runbook ou nos critérios de aceitação e uma data de ensaio. O objetivo é que a próxima equipa consiga operar o controlo sem depender de memória informal.
# Original fictional closure model, not an AWS scheduler or cancellation tool.
# No credentials, network calls, or AWS changes.
TERMINAL = {'Success', 'Failed', 'Cancelled', 'TimedOut'}
def closed(states):
return bool(states) and all(s in TERMINAL for s in states)
assert closed(['Success','Failed']) is True
assert closed(['Success','Running']) is False
assert closed(['Pending']) is False
assert closed([]) is False
assert closed(['Cancelled','TimedOut']) is True
print('five closure-state cases passed; no automation was cancelled')
A janela termina no dashboard, mas três alvos ainda executam ações de contenção.
Armadilhas comuns
Allow inferior como override; tags vazias como wildcard; eliminar pack como arquivar; parar envios como rollback.
Tópicos relacionados: Evidência e aceitação operacional · Segurança e continuidade
Uma política só é aceite quando o âmbito, os efeitos e os limites operacionais estão demonstrados.
Referência: Firewall Manager policy scope · SCS-C03