Polityka jako kodeks

1) Co liczy się jako „polityka”

• Dostęp/autoryzacja: RBAC/ABAC, ReBAC, eksport danych, step-up (MFA).
• Bezpieczeństwo infrastruktury: kontrola dostępu Kubernetes, wizerunek/tajne zasady, zasady sieci.
• Zgodność i prywatność: zarządzanie zgodami, znakowanie PII, lokalne dni raportowania, ograniczenia geograficzne.
• Konfiguracje i jakość: „zaprzeczaj: najnowsze”, ograniczenia zasobów, obowiązkowe znaczniki zasobów (Cloud).
• Dane i ML: zakaz szkolenia zestawów bez zgody, k-anonimowość, DP-budgets, Data Lineage-invariants.

2) Model architektoniczny PaC

PAP (Policy Administration Point): repozytorium i procesy zarządzania (MR/PR, przegląd, wersja).
PDP (Policy Decision Point): silnik obliczający decyzję polityczną (OPA, Cedar-engine, native interpreter).
PEP (Policy Enforcement Point): punkt aplikacji (brama API, administracja haków internetowych w K8s, transformator ETL, SDK).
PIP (Policy Information Point): źródła atrybutów/faktów: IdP, katalogi zasobów, magazyn danych, wskaźnik ryzyka.
Dziennik decyzji/audyt: niezmienne dzienniki rozwiązań (do analizy incydentów i zgodności).

Stream: request → PEP formularze kontekst → PDP obciążenia fakty (PIP) → oblicza rozwiązanie → PEP ma zastosowanie (permit/negation/edit) → log/metrics.

3) Narzędzia i domeny

OPA/Rego jest uniwersalnym silnikiem i językiem dla polityki deklaratywnej (administracja haka w K8s: Gatekeeper, w CI - Conftest, w API - sidecar/service).
Kyverno - deklaratywna polityka dla Kubernetes w YAML, patch/validation/generation.
Cedar (AWS/portable) to język polityki skupiający się na autoryzacji kto-over-what.
Cloud IAM (AWS/GCP/Azure) - polityka zasobów w chmurze (najlepiej sprawdzić statyczne PaC i w planach IaC).
Niestandardowe - DSL/reguły nad JSON/SQL dla specyfiki (na przykład zgodność ML).

4) Cykl życia polityki

1. Definicja celu i domeny: „Zakaz ładowania kontenerów z dużymi/krytycznymi lukami”.
2. Formalizacja w kodzie: Rego/Cedar/YAML.
3. Testy: tabele prawdy, przypadki negatywne, nieruchomości.
4. CI checks: linter, unit, integracja na fikcyjnych manifestach/żądaniach.
5. Wydanie i dystrybucja: publikacja w pakiecie, podpis, dostawa do PDP/krawędź.
6. Monitorowanie: szybkość trafienia, opóźnienie p95/p99, odmowa udziału, deski rozdzielcze dryfu.
7. Wyjątki/zwolnienia: ograniczony czas/objętość, kontrolowane i własność.
8. Refaktorowanie i archiwum: wersje, kompatybilność, migracje.

5) Przechowywanie i dystrybucja

Układ repo: 'policies/< domain >/< policy> .rego' cedar 'yaml',' tests/', 'bundles/',' schemas/'.
Wersioning: semver i 'policy _ version' w odpowiedziach PDP.
Pakiety - skompresowane pakiety zasad + schematy + konfiguracje, podpisane (bezpieczeństwo łańcucha dostaw).
Dystrybucja: pull (PDP wyciąga z registry/S3) lub push (kontroler wysyła).
Ocena częściowa: Przewiduje politykę szybkiej realizacji na obwodzie.

6) Model i schematy danych

Pojedyncza umowa kontekstowa: „przedmiot”, „zasoby”, „działanie”, „na”, „prawne”.
JSON-Schema/Protobuf: zatwierdzanie rzeczywistych modeli; niedopasowanie schematu - przyczyna „nieokreślona → zaprzeczenie”.
Normalizacja atrybutów: nazwy ujednolicone (na przykład 'lokator _ id',' risk _ level ',' pii _ tags', 'image. vulns ").

7) Wydajność i niezawodność

Pamięć podręczna rozwiązania: klucz „(subject_hash, resource_key, działanie, policy_version)”; krótki TTL, niepełnosprawność według zdarzeń (zmiana roli/znacznika).
Fakty lokalne: Nie ciągnąć ciężkich PIP na gorącym torze - synchronizować migawki.
Fail-open vs fail-closed: critical domain security - fail-closed; dla UX-critical - degradacja (wydanie zamiast odmowy).
Budżet opóźnienia: cel „<3-10 ms” na rozwiązanie w pamięci PDP, „<30-50 ms” z PIP.

8) Zarządzanie wyjątkiem (zwolnienia)

Ograniczony czas (np. 7 dni), z obowiązkowym właścicielem i rozumem.
W połączeniu: według zasobów/projektu/przestrzeni nazw; zakazanie globalnego „na wieki”.
Audyt i przypomnienia: raporty dotyczące wygaśnięcia zwolnień, automatyczne zamknięcie/eskalacja.

9) Metryka i obserwowalność

Zakres polityki: odsetek ścieżek/punktów końcowych chronionych przez PaC.
Opóźnienie decyzji/QPS/poziom błędu.
Odrzucanie szybkości i fałszywe pozytywne/ujemne (przez tryb suchego biegu/cieni).
Drift: rozbieżność między planem (IaC) a faktem (live), pomiędzy SDK a rozwiązaniami serwera.
Абдий: „decision _ id, policy_ids, wersja, attributes_digest, efekt, powód”.

10) Anty-wzory

Zasady „hardwired” do kodu bez wersji i testów.
Brak schematów/weryfikacji kontekstu → nieprzewidywalne decyzje.

Jeden monolityczny plik "mega. rego"

Nie ma procesu wyjątkowego → rund ręcznych i chaosu.
Tylko aplikacja runtime bez shift-left w CI (późne awarie).
Ukryte skutki uboczne w polityce (polityka powinna być czystą funkcją).

11) Przykłady

11. 1 Rego (OPA) - zaprzeczanie wrażliwym obrazom w 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: dane eksportowe wyłącznie z MSZ i białego IP

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 Cedr: Czytaj tylko właścicielom lub członkom zespołu

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): zakaz „: najnowszy” i obowiązkowy. zasoby

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 Konftest w CI dla planu Terraform

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

12) Wbudowanie w istniejące zdolności

RBAC/ABAC: PaC - warstwa deklaracyjna; PDP/PEP z artykułu silnika ról są ponownie używane.
Zarządzanie zgodami: polityka „reklam/personalizacji” jako warunki dostępu do danych/punktów końcowych.
Anonimizacja/PII: Polityka zabrania szkolenia/eksportu bez anonimizacji i profili budżetowych DP.
Geo-routing: zasady routingu ruchu/danych według regionu przechowywania.

13) Procesy i ludzie

Właściciele domeny polityki: bezpieczeństwo, platforma, dane, produkt/marketing.
Recenzenci: bezpieczeństwo + właściciele domeny.
Katalog zasad: opis celu, ryzyko, SLO, kontakt, przykłady, linki incydentów.
Szkolenia: przewodniki i snippety dla programistów (jak pisać testy, jak debugować Rego).

14) Lista kontrolna architekta

1. Minimalny zestaw domen i właścicieli zdefiniowanych?
2. Repozytorium zasad z testami, linter i CI?
3. Czy PDP/PEP są umieszczone na obwodzie, w API, w K8s i w rurociągach danych?
4. Czy istnieją schematy kontekstowe i walidacja?
5. Pakiety podpisów i dostaw, pamięci podręcznej i strategii niepełnosprawności?
6. Metryka (opóźnienie, zaprzeczenie, dryfowanie), dziennik decyzji i audyt?
7. Proces wyjątkowy z TTL i raportowania?
8. Tryb dry-run/shadow przed Enforce?
9. Częściowa ocena/prekompilacja gorących miejsc?
10. Runbook do degradacji (uszkodzony/dopuszczony z redakcją)?

Wniosek

Polityka jako kod sprawia, że zasady są powtarzalne, weryfikowalne i zarządzane na tych samych zasadach co aplikacja: kod przeglądu, testy, CI/CD, metryki i rolki. Łącząc PaC z autoryzacji (RBAC/ABAC), zgodności i bezpieczeństwa platformy, otrzymujesz pojedynczą, przewidywalną i skalowalną pętlę sterowania dla zachowania systemu - od kontroli wstępu do eksportu danych i rurociągów ML.