GH GambleHub

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.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Telegram
@Gamble_GC
Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.