Governança de segurança

Governança de segurança é o conjunto de estrutura organizacional, papéis, responsabilidades e prestação de contas que permite à empresa decidir, acompanhar e reportar seus controles de segurança, mantendo o risco dentro do apetite definido pelo negócio.

A perspectiva de Segurança do AWS Cloud Adoption Framework (CAF) trata isso como a capacidade Security governance: desenvolver, manter e comunicar papéis, responsabilidades, políticas, processos e procedimentos. Não é um projeto com fim: precisa acompanhar mudanças no negócio e nas ameaças.

Os documentos de governança costumam formar uma hierarquia, do mais estável ao mais detalhado:

Nível	Responde	Exemplo
Política	O quê e por quê (intenção, aprovada pela liderança).	"Dados classificados como confidenciais devem ser criptografados em repouso e em trânsito."
Padrão	Qual o requisito mensurável.	"Buckets S3 com dados confidenciais usam SSE-KMS com chave gerenciada pelo cliente; Block Public Access ativado."
Procedimento	Como executar, passo a passo.	"Como criar e rotacionar a chave KMS de um novo workload."
Diretriz (opcional)	Recomendação, sem obrigatoriedade.	"Prefira serviços gerenciados para bancos de dados."

O CAF sugere alguns artefatos para acelerar: um modelo operacional de segurança (pessoas e processos, incluindo a responsabilidade compartilhada), uma declaração de apetite a risco por categoria de workload, um framework de controles alinhado a referências como NIST, CIS ou ISO/IEC 27001, uma política de segurança em nuvem e princípios documentados para decidir quando não há regra específica.

Governança só funciona se cada atividade tiver dono claro. O CAF cita a matriz RACI (responsável, aprovador, consultado, informado) como base para o modelo de GRC (governança, risco e conformidade). Uma divisão típica:

Papel	Faz	Não deveria fazer
Quem aprova (liderança, dono do risco)	Aprova políticas, aceita riscos residuais, decide exceções.	Operar os controles que aprova.
Quem opera (plataforma, times de produto)	Implementa e mantém controles, responde a achados.	Aprovar as próprias exceções.
Quem audita (auditoria interna ou externa)	Verifica, de forma independente, se os controles funcionam.	Ter permissão de alterar o ambiente auditado.

Documentos sozinhos não garantem nada. O CAF lembra que a ideia DevOps de "tudo como código" melhora visibilidade e controle, e que organizações maduras codificam políticas e processos para medir continuamente a eficácia dos controles. Exemplos na AWS:

• Preventivo: SCPs no AWS Organizations limitam o máximo de permissões nas contas-membro de uma OU, bloqueando ações fora do padrão (veja guardrails).
• Detectivo: regras do AWS Config apontam recursos fora da conformidade.
• Em escala: AWS Control Tower aplica controles preventivos e detectivos num ambiente multi-conta.
• Rastreabilidade: AWS CloudTrail registra a atividade de API para auditoria.

Assim, o padrão "Block Public Access ativado" deixa de ser uma frase num PDF e vira uma regra versionada, revisada por pull request e avaliada automaticamente. O detalhamento vem na lição 12.

A boa prática SEC01-BP03 pede que você derive objetivos de controle a partir dos seus requisitos de conformidade e dos riscos do seu modelo de ameaças, e que valide esses objetivos continuamente. A governança é o que dá dono e processo a esse ciclo:

1. A política registra a intenção (o requisito do negócio ou da regulação).
2. O objetivo de controle diz o resultado que precisa ser garantido.
3. O padrão e o controle implementam esse resultado, de preferência como código.
4. A evidência mostra, a qualquer momento e ao longo do tempo, que o controle funciona.

Esse encadeamento é o tema da lição 9.

• Política sem dono: ninguém revisa, ela envelhece e passa a ser ignorada.
• Exceções sem prazo: toda exceção precisa de aprovador, justificativa e data de revisão.
• Mesma pessoa opera e audita: anula a independência da verificação.
• Mesmo rigor para tudo: o CAF lembra que nem todo workload precisa do mesmo nível de proteção; use o apetite a risco para calibrar.
• Cultura de culpa: o CAF recomenda uma cultura sem culpados, para que problemas sejam reportados cedo.

Governança de segurança define quem decide, quem opera e quem verifica, e documenta isso em políticas, padrões e procedimentos. Separação de funções evita conflito de interesse. Governança madura é codificada (SCPs, regras do Config, Control Tower) e alimenta o ciclo de objetivos de controle da SEC01-BP03.

• SEC01-BP03 Identify and validate control objectives

• AWS CAF Security Perspective — Security governance
• Security Pillar — princípios de design
• Service control policies (SCPs) — AWS Organizations