Kod Olarak Politika
1) "Politika" sayılan şey
Bir politika, bağlam göz önüne alındığında "yapabilir/yapamaz" (veya "tam olarak nasıl yapabilir") sorusuna cevap veren deterministik bir kuraldır:- Erişim/yetkilendirme: RBAC/ABAC, ReBAC, veri dışa aktarma, adım atma (MFA).
- Altyapı güvenliği: kabul kontrolü Kubernetes, görüntü/gizli politika, ağ kuralları.
- Uyumluluk ve gizlilik: onay yönetimi, PII etiketleme, yerel raporlama günleri, coğrafi kısıtlamalar.
- Yapılandırmalar ve kalite: "reddet: en son", kaynak sınırları, zorunlu kaynak etiketleri (Bulut).
- Veri ve ML: rızasız setlerde eğitim yasağı, k-anonimlik, DP bütçeleri, Veri Soyu-değişmezleri.
2) PaC Mimari Model
PAP (Policy Administration Point): depo ve yönetim süreçleri (MR/PR, review, version).
PDP (Policy Decision Point): Politika kararını hesaplayan motor (OPA, Cedar-engine, native interpreter).
PEP (Policy Enforcement Point): uygulama noktası (API ağ geçidi, K8s'de webhook yönetimi, ETL transformatörü, SDK).
PIP (Policy Information Point): özniteliklerin/olguların kaynakları: IdP, kaynak dizinleri, veri ambarı, risk oranı.
Karar Günlüğü/Denetim: Değiştirilemez çözüm günlükleri (olay analizi ve uyumluluk için).
Akış: istek - PEP formları bağlam - PDP yükler gerçekler (PIP) - çözüm hesaplar - PEP uygular (izin ver/reddet/düzenle) - günlük/metrikler.
3) Araçlar ve alanlar
OPA/Rego, bildirimsel politikalar için evrensel bir motor ve dildir (K8s'da webhook yönetimi: Gatekeeper, CI - Conftest, API - sidecar/service).
Kyverno - YAML'de Kubernetes için bildirimsel politikalar, yama/doğrulama/oluşturma.
Cedar (AWS/portable), kimin ne yetki verdiğine odaklanan bir politika dilidir.
Bulut IAM (AWS/GCP/Azure) - bulut kaynak politikaları (tercihen PaC statik ve IaC planlarında kontrol edin).
Özel - Ayrıntılar için JSON/SQL üzerinden DSL/kurallar (örneğin, ML uyumluluğu).
4) Politika yaşam döngüsü
1. Hedef ve etki alanının tanımı: "Yüksek/CRITICAL güvenlik açıklarına sahip konteynerlerin yüklenmesinin yasaklanması".
2. Kodda resmileştirme: Rego/Cedar/YAML.
3. Testler: doğruluk tabloları, negatif vakalar, özellik tabanlı.
4. CI kontrolleri: linter, birim, hayali manifestolar/istekler üzerinde entegrasyon.
5. Yayın ve dağıtım: paket halinde yayın, imza, PDP/edge'e teslimat.
6. İzleme: isabet oranı, gecikme süresi p95/p99, reddetme payı, kayma panoları.
7. İstisnalar/feragatlar: zaman/hacim sınırlı, denetlenmiş ve sahip olunan.
8. Yeniden düzenleme ve arşivleme: sürümler, uyumluluk, geçişler.
5) Depolama ve dağıtım
Repo-layout: 'policies/< domain >/< policy> .rego' cidar 'yaml', 'tests/',' bundles/', 'schemas/'.
Sürüm oluşturma: PDP yanıtlarında semver ve 'policy _ version'.
Paketler - sıkıştırılmış politika paketleri + şemalar + yapılandırmalar, imzalı (tedarik zinciri güvenliği).
Dağıtım: çekme (PDP registry/S3 çeker) veya itme (denetleyici gönderir).
Kısmi değerlendirme: Çevrede hızlı uygulama için politikaları öngörür.
6) Veri modeli ve şemalar
Tek bağlam sözleşmesi: 'konu', 'kaynak', 'eylem', 'env', 'yasal'.
JSON-Schema/Protobuf: gerçek modelleri doğrulamak; Şema uyumsuzluğu - "belirsiz - inkar" nedeni.
Öznitelik normalleştirme: birleştirilmiş adlar (örneğin, 'tenant _ id', 'risk _ level', 'pii _ tags','image. vulns ').
7) Performans ve güvenilirlik
Çözüm önbelleği: anahtar '(subject_hash, resource_key, eylem, policy_version)'; Kısa TTL, olaya göre engellilik (rol/etiket değişikliği).
Yerel Gerçekler: Sıcak pistte ağır PIP'leri çekmeyin - anlık görüntüleri senkronize edin.
Fail-open vs fail-closed: kritik alan güvenliği - fail-closed; UX-kritik için - degradasyon (reddetmek yerine baskı).
Gecikme bütçesi: PDP belleğinde çözüm başına '<3-10 ms', PIP ile '<30-50 ms' hedefleyin.
8) İstisna yönetimi (feragat)
Sınırlı süre (örn. 7 gün), zorunlu sahibi ve nedeni ile.
Coupled: kaynak/proje/ad alanı ile; Küresel "sonsuza dek" yasaklamak.
Denetim ve hatırlatıcılar: süresi dolan feragatlerle ilgili raporlar, otomatik kapatma/eskalasyon.
9) Metrikler ve gözlemlenebilirlik
Poliçe Kapsamı: PaC tarafından korunan yolların/uç noktaların oranı.
Karar Gecikme/QPS/Hata oranı.
Reddetme Oranı ve Yanlış Pozitif/Negatif (kuru çalışma/gölge modu ile).
Sürüklenme: plan (IaC) ve gerçek (canlı), SDK ve sunucu çözümleri arasındaki tutarsızlık.
Аудит: 'decision _ id, policy_ids, version, attributes_digest, effect, reason'.
10) Anti-desenler
Politikalar, sürümler ve testler olmadan koda "bağlanır".
Şema/bağlam doğrulama eksikliği - öngörülemeyen kararlar.
Bir monolitik dosya "mega. Rego"
İstisna süreci yoktur - manuel turlar ve kaos.
CI'da shift-left olmadan yalnızca çalışma zamanı uygulaması (geç hatalar).
Politikada gizli yan etkiler (politika saf bir işlev olmalıdır).
11) Örnekler
11. 1 Rego (OPA) - K8s'daki savunmasız görüntüleri reddet
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: yalnızca MFA ve beyaz IP'den veri dışa aktarma
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 Sedir: Sadece sahibine veya ekip üyelerine okuyun
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): Yasak ': en son've zorunlu. kaynaklar
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. Terraform Planı için CI'da 5 Conftest
bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform
12) Mevcut yeteneklere gömme
RBAC/ABAC: PaC - bildirim katmanı; Rol motoru makalesinden PDP/PEP yeniden kullanılır.
İzin yönetimi: Veri/uç nokta erişim koşulları olarak "reklamlar/kişiselleştirme" politikası.
Anonimleştirme/PII: Politikalar, anonimleştirme ve DP bütçe profilleri olmadan eğitimi/ihracatı yasaklar.
Geo-routing: Trafiği/verileri depolama bölgesine göre yönlendirme politikası.
13) Süreçler ve insanlar
Politika etki alanı sahipleri: güvenlik, platform, veri, ürün/pazarlama.
Gözden geçirenler: güvenlik + etki alanı sahipleri.
Politika kataloğu: hedef açıklaması, risk, SLO, iletişim, örnekler, olay bağlantıları.
Eğitim: Geliştiriciler için kılavuzlar ve snippet'ler (testlerin nasıl yazılacağı, Rego'nun nasıl hata ayıklanacağı).
14) Mimar kontrol listesi
1. Minimum alan ve sahip kümesi tanımlanmış mı?
2. Testler, linter ve CI ile politika deposu?
3. PDP'ler/PEP'ler çevreye, API'ye, K8s'ye ve veri boru hatlarına yerleştirilir mi?
4. Bağlam diyagramları ve doğrulama var mı?
5. İmza ve teslimat paketleri, önbellek ve engellilik stratejisi?
6. Metrikler (gecikme, reddetme, sürüklenme), karar kaydı ve denetim?
7. TTL ve raporlama ile istisna süreci?
8. Zorlama öncesinde kuru çalıştırma/gölge modu?
9. Sıcak noktalar için kısmi değerlendirme/ön derleme?
10. Degradasyon için çalışma kitabı (fail-closed/allow-with-redaction)?
Sonuç
Kod Olarak Politika, kuralları tekrarlanabilir, doğrulanabilir ve uygulama ile aynı ilkelere göre yönetilebilir kılar: inceleme kodu, testler, CI/CD, metrikler ve geri dönüşler. PaC'yi yetkilendirme (RBAC/ABAC), uyumluluk ve platform güvenliği ile bağlayarak, sistem davranışı için tek, öngörülebilir ve ölçeklenebilir bir kontrol döngüsü elde edersiniz - kabul kontrolünden veri dışa aktarımlarına ve ML boru hatlarına.