Policy as Code
1) O que considerar «política»
A política é uma regra definida que responde à pergunta «pode/não» (ou «como é possível») no contexto especificado:- Acesso/autorização: RBAC/ABAC, ReBAC, exportação de dados, step-up (MFA).
- Segurança da infra-estrutura: Controle admissional da Kubernetes, política de imagem/segredos, regras de rede.
- Complacência e privacidade: gerenciamento de concordâncias, formatação PII, 24 horas locais de relatórios, limitações geo.
- Configurações e qualidade: «restrição: latest», limites de recursos, marcas de formatação obrigatórias de recursos (Cloud).
- Dados e ML: proibição de treinamento em conjuntos sem consentimento, anonimato k, orçamentos DP, dados lineage-invariantes.
2) Modelo arquitetônico PaC
IP (Policy Management Point): repositório e processos de controle (MR/PR, revezamento, versão).
PDP (Policy Decision Point): motor que calcula a solução de política (OPA, Cedar-engine, seu próprio intérprete).
PEP (Policy Enforcement Point): ponto de aplicação (entrada API, adição webhook em K8s, transformador ETL, SDK).
PIP (Policy Informa Point): fontes de atributos/factos: IdP, diretórios de recursos, armazém de dados, screen de risco.
Decision Jobs/Auditoria: registros de soluções imutáveis (para análise de incidentes e conformidade).
Fluxo: Pedido → PEP forma contexto → PDP carrega factos (PIP) → calcula a solução → o PEP aplica (allow/deny/redação) → logs/métricas.
3) Ferramentas e domínios
OPA/Rego é um motor universal e linguagem para políticas declaratórias (webhook-admissão em K8s: Gatekeeper, CI - Conftest, API - sidecar/serviço).
Kyverno - políticas declaratórias para Kubernetes em YAML, patch/validação/geração.
Cedar (AWS/Portável) é uma linguagem de política com ênfase na permissão de «alguém está fazendo alguma coisa».
Cloud IAM (AWS/GCP/Azure) é uma política de recursos em nuvem (preferencialmente, cheque PaC estática e planos de IaC).
Custom - DSL/regras acima do JSON/SQL para especificados (por exemplo, ML).
4) Ciclo de vida da política
1. Definição de destino e domínio: «Proibição de carregamento de contêineres com vulnerabilidades High/CRITICAL».
2. Formalização em código: Rego/Cedar/YAML.
3. Testes: tabelas de verdade, malas negativas, property-based.
4. Verificações CI: linter, unit, integração em manifestos/pedidos falsos.
5. Lançamento e distribuição: publicação em bundle, assinatura, entrega em PDP/edge.
6. Monitoramento: hit-rate, latency p95/p99, parte deny, dashboard drift.
7. Exceções/waivers: tempo/volume limitado, com áudio e dono.
8. Refactoring e arquivo: versões, compatibilidade, migração.
5) Armazenamento e distribuição
Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Versioning: semver e 'policy _ version' nas respostas PDP.
Bundles: pacotes comprimidos de políticas + diagramas + configs assinados (suply chain security).
Distribuição: pull (PDP a partir de registry/S3) ou push (o controlador envia).
Partial evaluation: Antecipação de políticas para execução rápida no perímetro.
6) Modelo de dados e esquema
Um único contrato de contexto: «subject», «resource», «action», «eng», «legal».
JSON-Schema/Protobuf: valide os modelos de fato; a discrepância de diagramas é uma razão para «indeterminate → deny».
Normalização de atributos: nomes unificados (por exemplo, «tenant _ id», «risk _ level», «pii _ tags',» imagem. vulns`).
7) Desempenho e confiabilidade
A chave é «(subject _ hash, resource _ key, action, policy _ version)»; TTL curto, deficiência por evento (mudança de papéis/marcas).
Factos locais: Não puxem PIP pesado no caminho quente - sincronize os snapshots.
Fail-open vs fail-closed: segurança de domínios críticos - fail-closed; para os críticos UX - degradação (redação em vez de deny).
Orçamento de latência: objetivo '<3-10 ms' para solução em memória PDP, '<30-50 ms' com PIP.
8) Gerenciamento de exceções (waivers)
Tempo limitado (por exemplo, 7 dias), com proprietário e causa obrigatórios.
Por recurso/promoção/neymspace; a proibição do global «para sempre».
Auditorias e lembretes: relatórios de waiver caducando, automático/escalado.
9) Métricas e observabilidade
Policy Coverage: proporção de caminhos/endpoint protegidos por PaC.
Decision Latency / QPS / Error rate.
Deny Rate e Falso Positivo/Negativo (através do modo «dry-run/shadow»).
Draft: divergência entre o plano (IaC) e o fato (live), entre o SDK e as soluções de servidor.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.
10) Anti-pattern
Políticos costurados em código sem versões ou testes.
A ausência de esquemas/validação de contexto → soluções imprevisíveis.
Um arquivo monolítico "mega. rego».
Não há um processo de exceções para «rondas manuais» e caos.
Somente aplicação runtime sem «shift-left» em CI (falhas tardias).
Efeitos de side ocultos na política (a política deve ser uma função pura).
11) Exemplos
11. 1 Rego (OPA): proibição de imagens vulneráveis em K8s
rego package k8s. admission. vulns
deny[msg] {
input. kind. kind == "Pod"
some c img:= input. request. object. spec. containers[c].image vulns:= data. registry. scan [img] # actual-snapshot from PIP count ({v v:= vulns[_]; v.severity == "CRITICAL"}) > 0 msg:= sprintf("image %s has CRITICAL vulns", [img])
}
11. 2 Rego: exportação de dados com MFA e IP branco
rego package api. export
default allow = false
allow {
input. action == "export"
input. subject. mfa_verified == true net. cidr_contains("203. 0. 113. 0/24", input. env. ip)
}
11. 3 Cedar: leitura somente ao proprietário ou aos membros da equipe
cedar permit(
principal in Group::"team_members",
action in [Action::"read"],
resource in Photo::"")
when { resource. owner == principal resource. team_id in principal. team_ids };
11. 4 Kyverno (YAML): proibição ': latest' e . recursos
yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: disallow-latest-and-require-limits spec:
validationFailureAction: Enforce rules:
- name: disallow-latest match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image tag 'latest' is not allowed."
pattern:
spec:
containers:
- name: ""
image: "!:latest"
- name: require-limits match: { resources: { kinds: ["Pod"] } }
validate:
message: "resources. limits.{cpu,memory} required."
pattern:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"
11. 5 Conftest em CI para Plano de Terraform
bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform
12) Incorporar às capacidades existentes
RBAC/ABAC: PaC - camada de declaração; PDP/PEP do artigo sobre o motor de papel são reutilizados.
Gerenciamento de concordâncias: política «ads/personalization» como condições de acesso a dados/endpoint.
Anonymização/PII: Políticos proíbem treinamento/exportação sem perfis de anonimato e orçamento DP.
Gerenciamento geo: política de rotação de tráfego/dados por região de armazenamento.
13) Processos e pessoas
Proprietários de domínios de políticas: segurança, plataforma, dados, produto/marketing.
Revivers: securities + donos de domínio.
Catálogo de políticas: descrição do alvo, risco, SLO, contato, exemplos, referências de incidentes.
Treinamento: guias e snippets para desenvolvedores (como escrever testes, como ajustar Rego).
14) Folha de cheque do arquiteto
1. O conjunto mínimo de domínios e owners foi definido?
2. Repositório de políticas com testes, linter e CI?
3. PDP/PEP estão posicionados no perímetro, na API, no K8s e em Pipline de Dados?
4. Algum padrão de contexto e validação?
5. Assinatura e entrega de bandos, estratégia de cachê e deficiência?
6. Métricas (latency, deny, draft), decição-logos e auditoria?
7. Processo de exceções com TTL e relatórios?
8. Modo Dry-run/shadow antes de Enforce?
9. Partial evaluation/pré-compilação para caminhos quentes?
10. Runbook para degradação (fail-closed/allow-with-redation)?
Conclusão
O Policy AS torna as regras reproduzíveis, verificáveis e controláveis com os mesmos princípios do aplicativo: código-revezamento, testes, CI/CD, métricas e rebotes. Com a conexão de PaC com a permissão (RBAC/ABAC), a complicação e a segurança da plataforma, você obtém um circuito único, previsível e escalável de controle de comportamento do sistema, desde o controle admision até a exportação de dados e pipas ML.