Comparativo dos tipos de controle
Preventivo, detectivo e proativo: mecanismo, momento e exemplo.
Material complementar · Módulo 5 — Especialista
Lado a lado
Classificação de comportamento usada pelo AWS Control Tower. Os mesmos conceitos valem fora dele, com SCPs, regras do Config e hooks gerenciados por você.
| Preventivo | Detectivo | Proativo | |
|---|---|---|---|
| Mecanismo | Políticas do Organizations: SCPs, RCPs, políticas declarativas. | Regras do AWS Config (inclusive os controles do Security Hub CSPM). | Hooks do CloudFormation (handlers preCreate e preUpdate). |
| Quando atua | Na hora da chamada de API: a ação é negada. | Depois que o recurso existe ou muda: avaliação e alerta. | Antes de provisionar, durante a operação de stack. |
| O que cobre | Qualquer caminho (console, CLI, SDK, IaC) nas contas-membro. | Recursos existentes e novos, criados por qualquer caminho. | Só recursos criados ou atualizados via CloudFormation. |
| Limitações | Não afeta a conta de gerenciamento nem papéis vinculados a serviço; erro na política bloqueia trabalho legítimo. | Não impede nada; a janela até a correção é risco aceito. | Não vê console, API direta ou outras ferramentas de IaC; segredos não são resolvidos antes do hook. |
| Status no Control Tower | enforced / not enabled | clear / in violation / not enabled | PASS / FAIL / SKIP |
| Exemplo concreto | SCP que nega cloudtrail:StopLogging e cloudtrail:DeleteTrail. | Regra root-account-mfa-enabled ou detecção de leitura pública em buckets S3. | [CT.S3.PR.1]: bucket precisa de Block Public Access configurado. |
| Como testar | Numa conta de teste da OU, tente a ação negada e confira o AccessDenied e o evento no CloudTrail. | Crie um recurso fora do padrão em conta de teste e confira NON_COMPLIANT no Config. | Implante os templates de exemplo PASS e FAIL da documentação do controle. |
Testando um proativo
Template FAIL para [CT.S3.PR.1], para usar só em conta de teste — o hook deve impedir a criação:
123456789
Resources: BucketDeTeste: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls: false BlockPublicPolicy: false IgnorePublicAcls: false RestrictPublicBuckets: false A documentação avisa que cada template de exemplo foi feito para testar um controle específico; outros controles habilitados podem dar FAIL no mesmo template. Teste os proativos individualmente.
E os controles corretivos?
O Control Tower não tem um comportamento "corretivo", mas a remediação completa o ciclo detectar → corrigir:
- Remediação do AWS Config: associar uma regra a um documento de automação do AWS Systems Manager, manual ou automática.
- Eventos: um finding ou mudança de conformidade dispara uma regra do EventBridge que chama uma automação.
- Drift: reimplantar a baseline (StackSets, CfCT, AFT) ou reparar a landing zone quando o Control Tower acusar drift.
Comece com remediação manual ou com aprovação e só torne automática quando a ação for segura e previsível: uma correção automática errada é um incidente gerado por você.
Combinando camadas
| Objetivo | Proativo | Preventivo | Detectivo | Corretivo |
|---|---|---|---|---|
| Nenhum bucket público | Exigir Block Public Access no template | SCP que impede alterar o Block Public Access da conta | Regra de leitura/escrita pública em S3 | Reaplicar Block Public Access |
| Logs sempre ligados | — | SCP protegendo o trail | Regra de CloudTrail habilitado | Reativar o trail via automação |
| Root com MFA | — | Remover credenciais root (lição 20) | root-account-mfa-enabled | Processo manual com responsável |