Policy as code

Política escrita em documento depende de alguém lembrar. Política escrita como código é aplicada em toda mudança, de forma igual para todos, e deixa rastro do que foi decidido.

Open Policy AgentConftestKyvernoSentinel

O que é

é expressar as regras da organização ("nenhum bucket é público", "container não roda como root", "todo recurso tem dono") em uma linguagem que uma ferramenta consegue avaliar automaticamente contra uma entrada: um plano de Terraform, um manifesto Kubernetes, uma requisição de API.

O ganho é consistência e velocidade. A regra deixa de depender de revisor atento e passa a ser um gate que responde em segundos, com uma mensagem clara de por que bloqueou.

Exemplo em Rego (OPA)

O usa a linguagem Rego. A política abaixo avalia o plano do Terraform e nega a criação de um bucket sem bloqueio de acesso público. Com o Conftest, o mesmo arquivo roda no CI sobre o plano exportado em JSON.

policy/s3.regorego

package terraform.s3

import rego.v1

deny contains msg if {
	r := input.resource_changes[_]
	r.type == "aws_s3_bucket_public_access_block"
	r.change.after.block_public_acls == false
	msg := sprintf("%s permite ACL pública", [r.address])
}

deny contains msg if {
	r := input.resource_changes[_]
	r.type == "aws_s3_bucket"
	not r.change.after.tags.owner
	msg := sprintf("%s sem tag 'owner'", [r.address])
}

Onde aplicar

No PR ou no CI: avaliar o plano de antes do merge (rápido e barato de corrigir).
Na admissão do cluster: um controlador (Kyverno ou OPA Gatekeeper) recusa objetos que violam a política no momento em que chegam à API.
Em runtime e na nuvem: regras gerenciadas e verificação contínua pegam o que escapou ou mudou depois.
As três camadas se complementam: o gate de CI dá feedback cedo; a admissão é a rede de proteção que ninguém contorna.

Testar a política como código

Uma política sem teste é uma suposição. O OPA permite testes unitários em Rego com casos que devem passar e casos que devem ser negados. Sem eles, uma regra pode silenciosamente deixar de pegar nada, ou, no outro extremo, bloquear mudanças legítimas e levar o time a desligá-la.

Exceções e adoção gradual

Exceções existem, e o importante é que sejam explícitas, com dono e prazo, e não buracos informais. Para adotar sem travar todo mundo, comece em modo de aviso (a política só reporta), meça o que seria bloqueado, corrija o legado e só então passe a bloquear, a mesma lógica de observação, shadow e enforcement usada em .

Policy as codeOPA / RegoA política de segurança escrita como arquivo versionado que a pipeline consulta (negar imagem com vulnerabilidade crítica, exigir assinatura). Muda o critério = muda o arquivo, com review.ver no glossário →RegoOPALinguagem declarativa do Open Policy Agent para escrever políticas avaliadas sobre uma entrada (plano de Terraform, manifesto Kubernetes, requisição de API).ver no glossário →IaCinfrastructure as codeDescrever infraestrutura em arquivos versionados (Terraform, Ansible). Dá revisão, histórico e testes à configuração, mas replica erros em escala se não for escaneada.ver no glossário →WAFweb application firewallFiltro na borda que bloqueia padrões de ataque conhecidos em HTTP. Complementa o código — não substitui corrigir a vulnerabilidade, apenas compra tempo.ver no glossário →

conexões no mapa

Infraestrutura segura como códigoé validado porPolicy as code
Policy as codevira gateHardening de CI/CD
Segurança como produto internoentrega como caminho pavimentadoPolicy as code

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

em outros domínios

Conformidade na prática: controles, evidências e auditoriasgrcevidência automática nasce de política executável
DevSecOpsappsecgates e políticas, escritos como código executável

Estude antes

Infraestrutura segura como código

Desbloqueia

Segurança como produto interno

teste o que entendeu

Carregando perguntas…