Controles preventivos, detectivos e proativos

No AWS Control Tower, um controle é uma regra de alto nível, escrita em linguagem simples, aplicada a uma OU inteira: toda conta dentro dela fica sujeita ao controle. A documentação classifica cada controle em dois eixos independentes:

• Comportamento — como o controle age: preventivo, detectivo ou proativo.
• Orientação — quão recomendado ele é: obrigatório (mandatory), fortemente recomendado (strongly recommended) ou eletivo (elective).

"Guardrail" e "controle" são sinônimos na documentação; o termo antigo ainda aparece em consoles e blogs.

Os controles detectivos integrados ao Security Hub também são implementados como regras do AWS Config, dentro do padrão gerenciado pelo serviço "AWS Control Tower" no Security Hub CSPM.

Preventivo — uma SCP que impede desligar o trail. Mesmo um administrador com AdministratorAccess na conta-membro recebe AccessDenied:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtegerCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

Detectivo — a regra gerenciada do Config root-account-mfa-enabled marca a conta como NON_COMPLIANT se o root não tiver MFA. Ela não impede nada: avisa.

Proativo — o controle [CT.S3.PR.1] exige que um AWS::S3::Bucket declarado em um template CloudFormation tenha as quatro opções de Block Public Access em true. Um template sem isso recebe FAIL e o bucket não é criado; um template sem buckets recebe SKIP.

• Preventivo para o que nunca pode acontecer e tem regra clara: sair da organização, desligar logs, usar Regiões não aprovadas. É o mais forte, mas um erro na política bloqueia trabalho legítimo — teste antes.
• Detectivo para o que depende de contexto ou que você ainda está medindo: configurações que têm exceções válidas, recursos que já existem, mudanças feitas por qualquer caminho (console, CLI, SDK, Terraform).
• Proativo para dar feedback cedo a quem entrega via CloudFormation: o erro aparece na implantação, com a correção sugerida, em vez de virar finding depois.

• Obrigatórios protegem os recursos que o próprio Control Tower implanta. A documentação atual informa que, a partir da landing zone versão 4.0, eles deixaram de ser aplicados por padrão — confira a versão da sua.
• Fortemente recomendados aplicam boas práticas comuns de ambientes multi-conta, por OU.
• Eletivos rastreiam ou bloqueiam ações que muitas empresas restringem, também por OU.

A orientação não depende do comportamento: existe controle eletivo preventivo, fortemente recomendado detectivo, e assim por diante. Na prática, combine camadas para o mesmo objetivo de controle: por exemplo, "nenhum bucket público" pode ter um proativo (bloqueia no template), um preventivo (SCP que impede alterar o Block Public Access da conta) e um detectivo (pega o que escapou por outro caminho).

Preventivo nega, detectivo encontra, proativo barra antes de provisionar via CloudFormation. Cada um tem pontos cegos, então um objetivo de controle importante merece mais de uma camada. A orientação (obrigatório, fortemente recomendado, eletivo) diz o quanto o controle é recomendado, não como ele age. Veja o comparativo dos tipos de controle.

Esta lição aprofunda a SEC01-BP06 Automate deployment of standard security controls, que pede guardrails capazes de detectar e alertar sobre configurações erradas em templates antes da implantação, além de detecção de drift. Para o lado de IAM das SCPs e RCPs, veja Guardrails no IAM do Zero.

• About controls in AWS Control Tower
• Control behavior and guidance
• Proactive controls
• Regra gerenciada root-account-mfa-enabled (AWS Config)