Policy as Code

1) Cosa considerare «politica»

• Accesso/autorizzazione: RBAC/ABAC, ReBAC, esportazione dati, step-up (MFA).
• Sicurezza dell'infrastruttura: controllo admissi di Kubernets, politica immagine/segreto, regole di rete.
• Completamento e privacy: gestione dei consensi, tag PII, notti locali, geo-limitazioni.
• Configurazioni e qualità: latest, limiti di risorse, tag di risorse obbligatori (Cloud).
• Dati e ML: divieto di formazione su set senza consenso, k-anonimato, budget DOP, Data Lineage invarianti.

2) Modello architettonico

IP (Policy Administration Point) - Repository e processi di gestione (MR/PR, review, versione).
PDP (Policy Decection Point) - Motore che calcola la soluzione di criteri (OPA, Cedar-engine, interprete personalizzato).
PEP (Policy Enforcement Point) - Punto di applicazione (API gateway, webhook-admission in K8s, trasformatore ETL, SDK).
PIP (Policy Information Point) - Origini di attributi/fatti: IdP, cataloghi di risorse, deposito dati, rischio-scansione.
I registri di soluzioni invariati (per l'analisi degli incidenti e della conformità) sono Decision Log/Auditel.

Flusso: la query PEP crea il contesto del PDP carica i fatti (PIP) calcola la soluzione PEP applica (allow/deny/redazione) il /metriche.

3) Strumenti e domini

OPA/Rego è un motore universale e un linguaggio per le regole dichiarative (webhook-admission in K8s: Gatekeeper, CI - Conftest, API - sidecar/servizio).
Kyverno è una politica dichiarativa per Kubernets in YAML, patch/convalida/generazione.
Cedar (AWS/Trasmissibile) è un linguaggio di regole con l'accento di autorizzare «chi fa qualcosa».
Cloud IAM (AWS/GCP/Azure) è una politica per le risorse cloud (preferibilmente un assegno da utilizzare con statica e pianificazione).
Custom - DSL/regole sopra JSON/SQL per specifiche (ad esempio, ML).

4) Ciclo di vita delle regole

1. Definizione di destinazione e dominio: Non consentire il caricamento di contenitori con vulnerabilità High/CRITICAL.
2. Formalizzazione in codice: Rego/Cedar/YAML.
3. Test: tabelle di verità, valigette negative, property-based.
4. Controlli CI: linter, unit, integrazione su falsi manifesti/richieste.
5. Rilascio e distribuzione: pubblicazione in bundle, firma, consegna su PDP/edge.
6. Monitoraggio: hit-rate, latency p95/p99, quota deny, dashboard drift.
7. Le eccezioni/waivers sono limitate in termini di tempo/volume, con audio e proprietario.
8. Rifacimento e archivio: versioni, compatibilità, migrazioni.

5) Conservazione e distribuzione

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Versioning: semver e 'policy _ version'nelle risposte PDP.
Pacchetti di criteri compressi + diagrammi + configurs firmati (supply chain security).
Distribuzione: pull (PDP tira da registry/S3) o push (controller invia).
Partial evaluation: anticipa le regole per eseguire rapidamente il perimetro.

6) Modello di dati e schemi

Contratto unico di contesto: «subject», «resource», «action», «env», «legale».
JSON-Schema/Protobuf: convalida i modelli fatti; La mancata corrispondenza degli schemi è il motivo per cui «indeterminate → deny».
Regolazione degli attributi: nomi unificati (ad esempio, tenant _ id, risk _ level, pii _ tags, immagine. vulns`).

7) Prestazioni e affidabilità

Cache delle soluzioni: chiave '(subject _ hash, resource _ key, action, policy _ vision)'; TTL breve, disabilità per evento (cambio ruoli/tag).
Fatti locali: non trascinare PIP pesanti su una via calda - sincronizzare snashot.
Fail-open vs fail-closed - Protezione dei domini critici - fail-closed per i critici UX - degrado (redazione al posto di deny).
Budget di latenza: obiettivo <3-10 ms per la soluzione PDP, <30-50 ms con PIP.

8) Gestione delle eccezioni (waivers)

Tempo limitato (ad esempio 7 giorni), con proprietario e causa obbligatori.
Per risorsa/progetto/neimspace; il divieto globale «per sempre».
Controllo e promemoria: report di waiver'in scadenza, autolesionismo/escalation.

9) Metriche e osservabilità

Il Policy Coverage è una quota di percorsi/endpoint protetti.
Decision Latency / QPS / Error rate.
Deny Rate e False Positive/Negative (tramite la modalità dry-run/shadow).
Draft: la differenza tra il piano (IaC) e il fatto (live), tra SDK e le soluzioni server.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Anti-pattern

Regole ricucite in codice senza versione o test.
La mancanza di schemi/convalida del contesto è una soluzione imprevedibile.
Un file monolitico "mega. rego».
Non c'è nessun processo di esclusione per «giri manuali» e caos.
Solo applicazione runtime senza «maiusc-left» in CI (guasti tardivi).
Effetti di side nascosti in un criterio (il criterio deve essere una funzione pura).

11) Esempi

11. 1 Rego (OPA) - Divieto di immagini vulnerabili in 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: esportazione dei dati solo da MFA e IP «bianco»

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: lettura solo per il proprietario o i membri del team

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): «latest» e . risorse

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 in CI per il piano Terraform

bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform

12) Incorporazione nelle capacità esistenti

RBAC/ABAC: PaC - strato di dichiarazione; PDP/PEP dall'articolo sul motore di ruolo vengono riutilizzati.
Gestione dei consensi: ads/personalization come condizioni di accesso ai dati/endpoint.
Anonimato/PII: i policy vietano la formazione/esportazione senza profili di anonimato e budget DOP.
Routing geo: criteri di instradamento del traffico/dati per regione di storage.

13) Processi e persone

Proprietari di domini di regole: sicurezza, piattaforma, dati, prodotto/marketing.
Revivers: security + proprietari di dominio.
Catalogo di regole: descrizione dell'obiettivo, rischio, SLO, contatto, esempi, riferimenti agli incidenti.
Formazione: gommoni e snippet per gli sviluppatori (come scrivere test, come correggere Rego).

14) Assegno-foglio architetto

1. È stato definito un set minimo di domini e owners?
2. Un repository di criteri con test, linter e CI?
3. PDP/PEP sono posizionati nel perimetro, nell'API, in K8s e nei pipline di dati?
4. Ci sono schemi di contesto e convalida?
5. Firma e consegna dei bandi, strategia di cache e invalidità?
6. Metriche (latency, deny, draft), decimazione e controllo?
7. Processo di esclusione con TTL e report?
8. Modalità Dry-run/shadow prima di Enforce?
9. Partial evaluation/precompilato per i percorsi hot?
10. Runbook per la degradazione (fail-closed/allow-with-redaction)?

Conclusione

Policy as Code rende le regole riproduttive, verificabili e gestibili secondo gli stessi principi dell'applicazione: codice-review, test, CI/CD, metriche e ripristini. Connettendo il PaC con l'autosufficienza (RBAC/ABAC), la compilazione e la sicurezza della piattaforma, si ottiene un tracciato unico, prevedibile e scalabile per la gestione del comportamento del sistema, dall'admision control agli esportatori di dati e alle ML-pipline.