APRENDER. PRATICAR. EVOLUIR.1. Separar deteção e entrega
Um finding pode existir sem que a equipa de suporte o receba. Desenha o fluxo: origem, correspondência da regra, invocação do target, criação do ticket e atribuição a um responsável. Cada passagem tem uma evidência diferente. Numa mudança fora de horas, um screenshot do finding não demonstra notificação nem aceitação pelo turno. Usa identificadores e tempos para seguir uma ocorrência de teste até ao destino. O âmbito desta aula é a entrega a targets de regras EventBridge. Outros mecanismos, como subscribers de Custom Event Bus, Pipes e Scheduler, têm contratos próprios. Não transfiras defaults ou restrições entre eles apenas porque partilham o nome EventBridge. Regista a modalidade concreta no runbook para evitar diagnósticos baseados no produto errado.
2. Interpretar retries e fila de recuperação
Uma política de retry limita o tempo e as tentativas de entrega. Quando o evento é descartado após esgotar essa política, recuperar o target não recria automaticamente o evento. A DLQ permite reter falhas para tratamento posterior. Alguns erros, incluindo permissões em falta, podem chegar à DLQ sem retries. Lê ERROR_CODE, TARGET_ARN, RULE_ARN e, quando aplicável, EXHAUSTED_RETRY_CONDITION. Se a idade esgotou primeiro, aumentar apenas tentativas deixa a mesma janela temporal. Para a DLQ de um target de regra, usa uma fila SQS standard na mesma Região. Ao configurar pela API, garante a resource policy necessária. Distingue a falha original no target de uma segunda falha ao tentar enviar para a própria DLQ.
3. Recuperar com critérios observáveis
Define quem acompanha o backlog, quem corrige a autorização e quem confirma o ticket. Observa também InvocationsFailedToBeSentToDLQ: ter configurado uma fila não prova que eventos falhados chegaram lá. Depois de corrigir a causa, ensaia uma ocorrência nova e prepara o tratamento dos eventos retidos. A sugestão de reconciliar identificadores e evitar tickets duplicados é uma decisão operacional deste cenário, não uma garantia automática do serviço. O exercício local classifica observações fictícias em corrigir entrega à DLQ, corrigir autorização do target, preparar replay ou confirmar o processamento posterior. Não envia eventos nem reproduz a máquina de estados AWS. Discute com RUN o que acontece se o replay falhar e que evidência permite encerrar o incidente.
4. Dar significado à ausência de métricas
Um contador personalizado que só publica erros é diferente de um heartbeat que deve chegar continuamente. No primeiro, silêncio pode ser normal; no segundo, pode indicar falha de emissão. Define esse significado antes de escolher TreatMissingData. notBreaching trata pontos em falta como bons; breaching trata-os como violações; ignore mantém o estado quando a avaliação depende desses pontos; missing permite INSUFFICIENT_DATA quando todos estão em falta. A janela recuperada pode conter pontos reais adicionais. Se forem suficientes para EvaluationPeriods, o preenchimento não é usado. Testa a interrupção da emissão e a recuperação, não apenas a ultrapassagem de um threshold. Estes exemplos são alarmes normais de métricas personalizadas e não descrevem alarmes de logs ou exceções de namespaces específicos.
5. Distinguir inventário, seleção e análise Macie
A descoberta automática Macie escolhe objetos representativos; não é uma prova de leitura integral de todos os dados. Para uma decisão de migração, identifica primeiro o conjunto que precisa de análise e depois observa seleção, permissões e resultados. Um objeto ignorado por falta de acesso não é um objeto analisado sem dados sensíveis. O erro pode envolver a política do objeto ou a chave de cifragem. Num job, a profundidade de amostragem refere-se à seleção de objetos, não a ler uma percentagem dos bytes de cada ficheiro. As condições de exclusão prevalecem sobre inclusão. Mantém essas escolhas no pacote de aceitação para que um resultado de zero findings não seja apresentado fora do âmbito que o produziu.
6. Fechar a cobertura e entregar a RUN
Num job periódico, excluir objetos existentes deixa o histórico fora da análise inicial; as execuções seguintes consideram objetos novos ou alterados. Aumentar frequência não resolve por si só essa decisão de âmbito. O perfil atual de sensibilidade também não é um arquivo imutável: objetos posteriormente alterados ou eliminados saem das estatísticas descritas. Para uma auditoria histórica, guarda a evidência necessária à pergunta concreta, com data e versão do âmbito. No resumo para o gestor, separa o que foi configurado, o que conseguiu executar, o que encontrou e o que falta analisar. A passagem a RUN deve incluir responsáveis, sintomas de cobertura degradada e critérios para repetir testes. Uma conclusão delimitada é utilizável mesmo quando ainda existem lacunas declaradas.
# Original fictional delivery triage, not an EventBridge implementation.
# No credentials, network calls, or AWS changes.
def triage(row):
if row.get("dlq_send_failed"):
return "repair-dlq-delivery"
if row.get("error") == "NO_PERMISSIONS":
return "repair-target-authorization"
if row.get("retained"):
return "plan-controlled-replay"
return "check-downstream-evidence"
assert triage({"dlq_send_failed": True}) == "repair-dlq-delivery"
assert triage({"error": "NO_PERMISSIONS", "retained": True}) == "repair-target-authorization"
assert triage({"retained": True}) == "plan-controlled-replay"
assert triage({"finding_exists": True}) == "check-downstream-evidence"
assert triage({}) == "check-downstream-evidence"
print("five delivery-evidence cases passed; no event was sent")
Uma regra cria zero tickets porque o target nega acesso; a equipa usa os atributos da DLQ para localizar a falha e confirmar recuperação até ao suporte.
Armadilhas comuns
Findings como notificação; retries como correção de permissões; silêncio como saúde universal; amostra como análise integral.
Tópicos relacionados: Telemetria e investigação · Governação e evidência
Aceita resultados no âmbito demonstrado e identifica a etapa concreta onde a evidência deixa de existir.
Referência: Retrying delivery to rule targets · SCS-C03