APRENDER. PRATICAR. EVOLUIR.1. Identificar quem configura o serviço
Security Hub CSPM permite gestão central através do administrador delegado, com integração em Organizations. A política define se o serviço, standards e controlos estão habilitados, e pode parametrizar determinados controlos. Criar a política não a aplica: é necessária uma associação ao target. Distingue a definição guardada da configuração que realmente chegou às contas. Uma conta centrally managed recebe essas definições pela administração central no âmbito relevante. Uma conta self-managed mantém gestão própria. Esta aula trata esses mecanismos CSPM; não usa as APIs de agregação de Security Hub V2 como se fossem equivalentes. Antes de uma mudança, regista a conta administrativa, home Region, targets e os responsáveis pela validação. Essa lista evita pedir à equipa local uma alteração que deve ser feita na política central.
2. Resolver herança e exceções
A configuração aplicada diretamente tem precedência sobre herança, incluindo quando a aplicação direta é self-managed. Mover uma conta para uma OU de produção não basta para provar que recebeu a política dessa OU. Verifica a associação efetiva e documenta exceções com owner e revisão. Um target só pode usar uma política de configuração de cada vez, e essa política descreve um conjunto completo. Não combines mentalmente controlos de duas políticas como se fossem camadas seletivas. O exercício local resolve uma hierarquia fictícia: primeiro procura uma configuração aplicada no nó, depois sobe até encontrar a mais próxima. É apenas um modelo de precedência; não prova que a associação real foi bem-sucedida nem que o serviço está operacional em todas as Regiões.
3. Planear alterações de âmbito regional
Uma política aplica-se à home Region e às linked Regions, com as exceções documentadas para controlos de recursos globais e disponibilidade regional. Não oferece um seletor arbitrário para uma parte dessas Regiões. Uma Região opt-in precisa de estar ativada para a conta. Retirar uma linked Region termina a aplicação central nesse âmbito mas conserva as definições existentes. Alterar ou remover a home Region tem impacto maior: políticas e associações são eliminadas, enquanto as contas mantêm configurações. O plano de mudança deve prever exportação da intenção, reconstrução da gestão e testes. Não descrevas uma alteração regional como simples deslocação do dashboard. Combina segurança e RUN para identificar quem passa a gerir cada âmbito e qual evidência confirma a transição.
4. Confirmar aplicação e capacidade de avaliação
PENDING é um estado em curso e FAILED não significa que tudo foi revertido. Algumas definições podem ter sido aplicadas mesmo quando a associação falha. Consulta resultados e mensagens para localizar a conta, Região ou definição problemática. Verifica pré-requisitos, incluindo AWS Config configurado para os recursos relevantes. Mesmo SUCCESS não garante indefinidamente a capacidade de gerar findings: um standard pode passar a ativação incompleta. Define a aceitação em duas camadas, associação pretendida e avaliação operacional. Para controlos novos, escolhe conscientemente entre uma lista de ativação e uma lista de exclusões; a segunda permite ativar os restantes, incluindo lançamentos novos nos standards habilitados. Essa escolha tem impacto na gestão de alterações e deve ter responsável por acompanhar o que passa a ser avaliado.
5. Distinguir workflow de efeito técnico
O estado de workflow pertence ao finding individual. Marcar RESOLVED não reconfigura o recurso nem impede novos findings para o mesmo problema. Quando a conformidade passa de PASSED para FAILED, um finding resolvido pode regressar automaticamente a NEW. A equipa deve interpretar essa transição como nova necessidade de investigação, não como prova automática de duplicação defeituosa. Supressões também exigem justificação e âmbito. Ao avaliar um controlo, o serviço ignora findings arquivados ou suprimidos; por isso, mudar o tratamento dos findings pode alterar o indicador sem alterar o recurso. Guarda a evidência da decisão de tratamento separada da evidência de remediação. Num handover, indica quem acompanha regressões e como a equipa valida o efeito de uma correção declarada.
6. Explicar o score ao sponsor
O score depende dos controlos que entram no cálculo. No data é excluído; não é transformado em Passed. Na regra detalhada de cálculo do summary score, cada controlo único conta uma vez entre standards. Um relatório que soma ocorrências repetidas muda o denominador. Para comparar períodos, apresenta também cobertura, supressões e alterações nos standards ou Regiões. Se a percentagem subiu depois de perder dados, não a traduzas em redução equivalente de exposição. Mostra quais recursos foram efetivamente corrigidos e quais verificações deixaram de ter evidência. O resumo desta aula liga quatro etapas: intenção na política, associação ao âmbito, execução da avaliação e interpretação do resultado. Cada etapa tem um responsável e uma prova diferente, necessários para uma passagem a produção credível.
# Original fictional precedence model, not Security Hub configuration.
# No credentials, network calls, or AWS changes.
parents = {"account": "prod", "prod": "root", "root": None}
def effective(node, applied):
while node is not None:
if node in applied:
return applied[node]
node = parents[node]
return "unconfigured"
assert effective("account", {"root": "baseline"}) == "baseline"
assert effective("account", {"root": "baseline", "prod": "strict"}) == "strict"
assert effective("account", {"prod": "strict", "account": "self-managed"}) == "self-managed"
assert effective("account", {"prod": "self-managed"}) == "self-managed"
assert effective("account", {}) == "unconfigured"
print("five precedence cases passed; association success was not evaluated")
Uma conta mantém self-managed apesar de entrar na OU de produção; a equipa identifica a exceção antes de declarar harmonização.
Armadilhas comuns
OU como prova de herança; SUCCESS como saúde permanente; RESOLVED como correção; No data como Passed.
Tópicos relacionados: Telemetria e investigação · Governação e evidência
Uma política definida e um score elevado precisam de evidência de aplicação e avaliação no âmbito pretendido.
Referência: Security Hub CSPM central configuration · SCS-C03