Policy as Code

1) რა არის „პოლიტიკა“?

• წვდომა/საავტორო უფლებები: RBAC/ABAC, ReBAC, მონაცემთა ექსპორტი, step-up (MFA).
• ინფრასტრუქტურის უსაფრთხოება: Kubernetes admission კონტროლი, სურათების/საიდუმლოების პოლიტიკა, ქსელის წესები.
• შესაბამისობა და კონფიდენციალურობა: თანხმობის მენეჯმენტი, PII tegiration, ადგილობრივი საანგარიშო დღე, გეო შეზღუდვები.
• კონფიგურაცია და ხარისხი: „აკრძალვა: ლატესტი“, რესურსების ლიმიტები, რესურსების სავალდებულო ჭდეები (Cloud).
• მონაცემები და ML: ეკიპაჟებზე ტრენინგის აკრძალვა თანხმობის გარეშე, k-ანონიმურობა, DP ბიუჯეტები, მონაცემთა ხაზის ინვარიანტები.

2) არქიტექტურული მოდელი PaC

PAP (პოლიტიკის ადაპტაციის წერტილი): საცავი და კონტროლის პროცესები (MR/PR, revive, ვერსია).
PDP (Policy Decision Point): ძრავა, რომელიც ითვლის პოლიტიკას (OPA, Cedar-Engine, საკუთარი თარჯიმანი).
PEP (Policy Enforcement Point): გამოყენების წერტილი (API კარიბჭე, webhook admision K8s, ETL ტრანსფორმატორი, SDK).
PIP (Policy Information Point): ატრიბუტების/ფაქტების წყაროები: IDP, რესურსების კატალოგები, მონაცემთა საწყობი, რისკი.
Decision Log/Audit: უცვლელი გადაწყვეტილებების ჟურნალები (ინციდენტებისა და შესაბამისობის გასაანალიზებლად).

ნაკადი: მოთხოვნა PEP ქმნის კონტექსტს - PDP ატვირთავს ფაქტებს (PIP) და ითვლის გამოსავალს - PEP იყენებს (allow/deny/გამოცემა) - log/მეტრიკა.

3) ინსტრუმენტები და დომენები

OPA/Rego არის უნივერსალური ძრავა და ენა დეკლარაციული პოლიტიკოსისთვის (webhook admision K8s: Gatekeeper, CI - Conftest, API- ში - sidecar/მომსახურება).
Kyverno არის დეკლარაციული პოლიტიკოსები Kubernetes- ისთვის YAML- ში, patch/validation/თაობა.
Cedar (AWS/გადაცემული) არის პოლიტიკოსი ენა, რომელიც აქცენტს აკეთებს „რაღაცის გაკეთებაზე“.
Cloud IAM (AWS/GCP/Azure) - ღრუბლოვანი პოლიტიკის პოლიტიკა (სასურველია PaC სტატიკის ჩეკი და IaC გეგმები).
Custom - DSL/წესები JSON/SQL სპეციფიკებისთვის (მაგალითად, ML შესაბამისობა).

4) პოლიტიკის ცხოვრების ციკლი

1. მიზნის და დომენის განსაზღვრა: „მაღალი/CRITICAL დაუცველი კონტეინერების დატვირთვის აკრძალვა“.
2. კოდის ფორმალიზაცია: Rego/Cedar/YAML.
3. ტესტები: სიმართლის ცხრილები, უარყოფითი შემთხვევები, წინსვლა.
4. CI ტესტები: ლინტერი, ერთეული, ინტეგრაცია ფიქტიურ მანიფესტებზე/მოთხოვნებზე.
5. გამოშვება და განაწილება: გამოქვეყნება bundle- ში, ხელმოწერა, მიწოდება PDP/edge- ზე.
6. მონიტორინგი: hit-rate, latency p95/p99, დენის წილი, დრიფტის დაშბორდები.
7. გამონაკლისები/waivers: შეზღუდულია დროში/მოცულობით, აუდიტით და მფლობელით.
8. რეფაქტორინგი და არქივი: ვერსიები, თავსებადობა, მიგრაცია.

5) შენახვა და განაწილება

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
ვერსია: semver და 'policy _ version' PDP პასუხებში.
Bundles: შეკუმშული პოლიტიკის პაკეტები + ჩამორთმეული სქემები, ხელმოწერილი (supply chain უსაფრთხოება).
Distribution: pull (PDP იჭერს registry/S3) ან push (მაკონტროლებელი უგზავნის).
პარტიული ღონისძიება: პოლიტიკოსის მიკერძოება პერიმეტრზე სწრაფი შესრულებისთვის.

6) მონაცემთა და სქემების მოდელი

ერთი კონტექსტის ხელშეკრულება: 'subject', 'resource', 'action', 'env', 'legal'.
JSON-Schema/Protobuf: დაელოდეთ ფაქტობრივ მოდელებს; სქემების შეუსაბამობა არის მიზეზი „indeterminate - deny“.
ატრიბუტების ნორმალიზაცია: ერთიანი სახელები (მაგალითად, 'tenant _ id', 'risk _ level', 'pii _ tags', 'image. vulns`).

7) პროდუქტიულობა და საიმედოობა

გადაწყვეტილებების ქეში: გასაღები '(subect _ hash, resource _ key, action, policy _ version) "; მოკლე TTL, მოვლენების ინვალიდობა (როლების შეცვლა/ჭდეები).
ადგილობრივი ფაქტები: ნუ გადაიტანთ მძიმე PIP- ს ცხელ გზაზე - სინქრონიზაციას უწევს snepshots.
Fail-Open vs fail-closed: კრიტიკული დომენების უსაფრთხოება - fail-closed; UX- კრიტიკულისთვის - დეგრადაცია (გამოცემა დენის ნაცვლად).
ლატენტობის ბიუჯეტი: მიზანი '<3-10 ms' PDP- ის მეხსიერებაში გადასაჭრელად, '<30-50 ms' s PIP.

8) გამონაკლისების მენეჯმენტი

შეზღუდულია დროულად (მაგალითად, 7 დღე), სავალდებულო მფლობელით და მიზეზით.
შეკუმშული: რესურსის/პროექტის/ნეიმსპასის მიხედვით; გლობალური აკრძალვა „სამუდამოდ“.
აუდიტი და შეხსენებები: ვადაგადაცილებული waiver 'am- ის მოხსენებები, ავტო დახურვა/ესკალაცია.

9) მეტრიკა და დაკვირვება

Policy Coverage: PaC- ით დაცული ბილიკების/ენდოპოინების წილი.
Decision Latency / QPS / Error rate.
Deny Rate და False Positive/Negative („dry-run/shadow“ რეჟიმში).
დრიფი: შეუსაბამობა გეგმასა (IaC) და ფაქტს შორის (ცოცხალი), SDK- სა და სერვერის გადაწყვეტილებებს შორის.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) ანტი შაბლონები

პოლიტიკოსები, რომლებიც კოდში „შედიან“ ვერსიებისა და ტესტების გარეშე.
კონტექსტის სქემების/ვალიდაციის არარსებობა არაპროგნოზირებადი გადაწყვეტილებებია.
ერთი მონოლითური ფაილი "მეგა. rego».
არ არსებობს გამონაკლისის პროცესი - „ხელის შემოვლითი გზა“ და ქაოსი.
მხოლოდ runtime გამოყენება CI- ში „shift-left“ გარეშე (მოგვიანებით მარცხი).
ფარული გვერდითი ეფექტები პოლიტიკაში (პოლიტიკა უნდა იყოს სუფთა ფუნქცია).

11) მაგალითები

11. 1 რეგო (OPA): 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 რეგო: მონაცემთა ექსპორტი მხოლოდ MFA- სთან და „თეთრ“ 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 კედარი: კითხვა მხოლოდ მფლობელს ან გუნდის წევრებს

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' და. რესურსები

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 CI Terraform გეგმისთვის

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

12) არსებული შესაძლებლობების შექმნა

RBAC/ABAC: PaC - დეკლარაციის ფენა; PDP/PEP გამოყენებულია როლური ძრავის შესახებ სტატიიდან.
თანხმობის მენეჯმენტი: „ads/personalization“ პოლიტიკა, როგორც მონაცემების/ენდოინების დაშვების პირობები.
ანონიმიზაცია/PII: პოლიტიკოსები კრძალავს ტრენინგს/ექსპორტს ანონიმიზაციის პროფილების და DP ბიუჯეტის გარეშე.
Geo მარშრუტიზაცია: ტრაფიკის/მონაცემების მარშრუტის პოლიტიკა შენახვის რეგიონებში.

13) პროცესები და ადამიანები

დომენის მფლობელები არიან პოლიტიკოსი: უსაფრთხოება, პლატფორმა, მონაცემები, პროდუქტი/მარკეტინგი.
Revewers: security + დომენის მფლობელები.
პოლიტიკის კატალოგი: მიზნის აღწერა, რისკი, SLO, კონტაქტი, მაგალითები, ინციდენტების ბმულები.
ტრენინგი: ჰეიდები და სნიპეტები დეველოპერებისთვის (როგორ დავწეროთ ტესტები, როგორ დავწეროთ რეგო).

14) არქიტექტორის ჩეკის სია

1. დადგენილია დომენების მინიმალური ნაკრები და owners?
2. საცავის პოლიტიკოსი ტესტებით, ლინტერი და CI?
3. PDP/PEP განთავსებულია პერიმეტრზე, API- ში, K8s- ში და მონაცემთა პლანზე?
4. არსებობს კონტექსტის სქემები და შესაბამისობა?
5. ბანდების ხელმოწერა და მიწოდება, ქეშისა და ინვალიდობის სტრატეგია?
6. მეტრიკა (ლატენტობა, დენი, დრიფტი), ციფრული ლოგო და აუდიტი?
7. გამონაკლისის პროცესი TTL- ით და ანგარიშგებით?
8. Dry-run/shadow რეჟიმი Enforce- ის წინ?
9. პარტიული ღონისძიება/წინასწარ შედგენა ცხელი გზებისთვის?
10. Runbook fail-closed/allow-with-redaction?

დასკვნა

Policy as Code ქმნის წესებს რეპროდუქციული, გადამოწმებული და კონტროლირებადი იმავე პრინციპებით, როგორც პროგრამა: კოდი, ტესტები, CI/CD, მეტრიკა და გამოტოვება. PaC- ს ავტორიზაციასთან (RBAC/ABAC), პლატფორმის შესაბამისობასა და უსაფრთხოებასთან დაკავშირება, თქვენ იღებთ სისტემის ქცევის კონტროლის ერთიან, პროგნოზირებად და მასშტაბურ მიკროსქემას - admission კონტროლიდან მონაცემთა ექსპორტამდე და ML payplines.