GH GambleHub

Politica ca cod

1) Ceea ce contează ca „politică”

O politică este o regulă deterministă care răspunde la întrebarea „poate/nu” (sau „cum exact poate”) având în vedere contextul:
  • Acces/autorizare: RBAC/ABAC, ReBAC, export date, step-up (MFA).
  • Securitatea infrastructurii: controlul admiterii Kubernetes, imagine/politică secretă, reguli de rețea.
  • Conformitate și confidențialitate: managementul consimțământului, etichetarea PII, zilele locale de raportare, geo-restricțiile.
  • Configurații și calitate: „neagă: cele mai recente”, limite de resurse, etichete de resurse obligatorii (Cloud).
  • Date și ML: interzicerea instruirii pe seturi fără consimțământ, k-anonimat, DP-bugete, Data Lineage-invariante.

2) Model arhitectural PaC

AP (Policy Administration Point): procese de depozitare și gestionare (MR/PR, revizuire, versiune).
PDP (Policy Decision Point): motor care calculează decizia de politică (OPA, Cedar-motor, interpret nativ).
PEP (Policy Enforcement Point): application point (API gateway, webhook administration in K8s, ETL transformer, SDK).
PIP (Policy Information Point): surse de atribute/fapte: IdP, directoare de resurse, depozit de date, rata de risc.
Jurnalul decizional/Audit: jurnale de soluții neschimbabile (pentru analiza incidentelor și conformitate).

Stream: cerere → PEP formeaza context → PDP incarca fapte (PIP) → calculeaza solutia → PEP se aplica (allow/negy/edit) → log/metrics.

3) Instrumente și domenii

OPA/Rego este un motor universal și un limbaj pentru politici declarative (administrație webhook în K8s: Gatekeeper, în CI - Conftest, în API - sidecar/service).
Kyverno - politici declarative pentru Kubernetes în YAML, patch/validare/generare.
Cedar (AWS/portabil) este un limbaj de politică cu accent pe cine-peste-ce autorizație.
Cloud IAM (AWS/GCP/Azure) - politici de resurse cloud (de preferință, verificați PaC static și în planurile IaC).
Personalizat - DSL/reguli peste JSON/SQL pentru specificul (de exemplu, conformitatea ML).

4) Ciclul de viață al politicii

1. Definirea obiectivului și a domeniului: „Interzicerea încărcării containerelor cu vulnerabilități High/CRITICAL”.
2. Formalizarea în cod: Rego/Cedar/YAML.
3. Teste: tabele de adevăr, cazuri negative, bazate pe proprietate.
4. CI verifică: linter, unitate, integrare pe manifeste/cereri fictive.
5. Lansare și distribuție: publicare în pachet, semnătură, livrare la PDP/edge.
6. Monitorizare: hit-rate, latență p95/p99, neagă cota, tablouri de bord în derivă.
7. Excepții/derogări: timp/volum limitat, auditat și deținut.
8. Refactoring și arhivă: versiuni, compatibilitate, migrații.

5) Depozitare și distribuție

Repo-layout: 'policies/< domain >/< policy> .rego' cedar 'yaml',' tests/', 'bundles/',' schemas/'.
Versioning: semver și „policy _ version” în răspunsurile PDP.
Pachete - pachete de politici comprimate + scheme + configurații, semnate (securitatea lanțului de aprovizionare).
Distributie: pull (PDP trage din registry/S3) sau push (controller trimite).
Evaluare parțială: Anticipează politici de execuție rapidă în perimetru.

6) Modelul și schemele de date

Contract de context unic: „subiect”, „resursă”, „acțiune”, „env”, „juridic”.
JSON-Schema/Protobuf: validați modelele reale; schema nepotrivire - cauza „nedeterminată → negată”.
Normalizarea atributelor: nume unificate (de exemplu, 'tenant _ id',' risk _ level ',' pii _ tags', 'image. vulns').

7) Performanță și fiabilitate

Soluție cache: cheie „(subject_hash, resource_key, acțiune, policy_version)”; scurt TL, handicap în funcție de eveniment (schimbare de rol/etichetă).
Fapte locale: Nu trageți PIP-uri grele pe pista fierbinte - sincronizați instantanee.
Fail-open vs eșec-închis: securitatea domeniului critic - nu reușesc-închis; pentru UX-critică - degradare (ediție în loc de negare).
Bugetul de latență: țintă „<3-10 ms' per soluție în memoria PDP,” <30-50 ms' cu PIP.

8) Gestionarea excepțiilor (derogări)

Timp limitat (de ex. 7 zile), cu proprietar obligatoriu și motiv.
Cuplat: prin resurse/proiect/namespace; interzicerea globală „pentru totdeauna”.
Audit și memento-uri: rapoarte privind derogările expirate, auto-închidere/escaladare.

9) Măsurători și observabilitate

Acoperirea politicilor: proporția căilor/punctelor finale protejate de PaC.
Latența deciziei/QPS/Rata de eroare.
Neagă rata și fals pozitiv/negativ (prin modul de rulare/umbră).
Drift: discrepanță între plan (IaC) și fapt (live), între SDK și soluțiile de server.
Аудит: 'decision _ id, policy_ids, version, attributes_digest, effect, reason'.

10) Anti-modele

Politici "hardwired' în cod fără versiuni și teste.
Lipsa schemelor/validarea contextului → decizii imprevizibile.

Un fişier monolitic "mega. rego"

Nu există nici un proces de excepție → runde manuale și haos.
Numai aplicarea runtime fără shift-stânga în CI (eșecuri târzii).
Efecte secundare ascunse în politică (politica ar trebui să fie o funcție pură).

11) Exemple

11. 1 Rego (OPA) - nega imagini vulnerabile în 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: datele de export numai din MAE și IP alb

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 Cedru: Citiți numai proprietarului sau membrilor echipei

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): Interzicerea „: cea mai recentă” și obligatorie. resurse

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 în CI pentru Terraform Plan

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

12) Încorporarea în abilitățile existente

RBAC/ABAC: PaC - strat de declarație; PDP/PEP din articolul motorului de rol sunt reutilizate.
Managementul consimțământului: politica „anunțuri/personalizare” ca date/condiții de acces la punctul final.
Anonimizare/PII: Politicile interzic instruirea/exportul fără anonimizare și profiluri de buget DP.
Geo-rutare: politica de rutare a traficului/datelor pe regiuni de stocare.

13) Procese și oameni

Proprietarii domeniului de politică: securitate, platformă, date, produs/marketing.
Recenzori: securitate + proprietari de domenii.
Catalog de politici: descrierea țintei, risc, SLO, contact, exemple, link-uri incidente.
Instruire: ghiduri și fragmente pentru dezvoltatori (cum să scrie teste, cum să depaneze Rego).

14) Lista de verificare a arhitectului

1. Set minim de domenii și proprietari definiți?
2. Depozit de politici cu teste, linter și CI?
3. Sunt PDP/PEP plasate pe perimetru, în API, în K8s și în conductele de date?
4. Există diagrame de context și validare?
5. Pachete de semnătură și de livrare, cache și strategia de handicap?
6. Valori (latență, negare, derivă), decizie-log și audit?
7. Proces de excepție cu TTL și raportare?
8. Modul uscat/umbră înainte de aplicare?
9. Evaluare parțială/precompilare pentru puncte fierbinți?
10. Runbook pentru degradare (eșec-închis/permite-cu-redactare)?

Concluzie

Politica ca cod face regulile reproductibile, verificabile și gestionate pe aceleași principii ca și aplicația: cod de revizuire, teste, CI/CD, valori și rollback-uri. Prin conectarea PaC cu autorizația (RBAC/ABAC), conformitatea și securitatea platformei, obțineți o singură buclă de control, previzibilă și scalabilă pentru comportamentul sistemului - de la controlul admisiei la exporturile de date și conductele ML.

Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Telegram
@Gamble_GC
Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.