سیاست به عنوان کد

1) آنچه به عنوان «سیاست» محسوب می شود

• دسترسی/مجوز: RBAC/ABAC، ReBAC، صادرات داده ها، گام به گام (MFA).
• امنیت زیرساخت: کنترل پذیرش Kubernetes، سیاست تصویر/مخفی، قوانین شبکه.
• انطباق و حریم خصوصی: مدیریت رضایت، برچسب گذاری PII، روزهای گزارش محلی، محدودیت های جغرافیایی.
• پیکربندی و کیفیت: «انکار: آخرین»، محدودیت منابع، برچسب منابع اجباری (ابر).
• داده ها و ML: ممنوعیت آموزش در مجموعه های بدون رضایت، k-ناشناس بودن، بودجه DP، تغییرناپذیر خط داده ها.

2) مدل معماری PaC

PAP (نقطه مدیریت سیاست): فرآیندهای مخزن و مدیریت (MR/PR، بررسی، نسخه).
PDP (نقطه تصمیم گیری سیاست): موتور است که محاسبه تصمیم سیاست (OPA، سرو موتور، مترجم بومی).
PEP (نقطه اجرای سیاست): نقطه کاربرد (دروازه API، مدیریت webhook در K8s، ترانسفورماتور ETL، SDK).
PIP (Policy Information Point): منابع ویژگی ها/حقایق: IdP، دایرکتوری منابع، انبار داده، میزان ریسک.
ورود به سیستم تصمیم/حسابرسی: سیاهههای مربوط به راه حل غیر قابل تغییر (برای تجزیه و تحلیل حادثه و انطباق).

جریان: درخواست → PEP فرم زمینه → PDP بارهای حقایق (PIP) → محاسبه راه حل → PEP اعمال می شود (اجازه/انکار/ویرایش) → ورود/معیارها.

3) ابزارها و دامنه ها

OPA/Rego یک موتور و زبان جهانی برای سیاست های اعلانی است (مدیریت webhook در K8s: Gatekeeper، در CI - Conftest، در API - sidecar/service).
Kyverno - سیاست های اعلانی برای Kubernetes در YAML، patch/validation/generation.
Cedar (AWS/portable) یک زبان سیاست با تمرکز بر چه کسی بیش از چه مجوز است.
Cloud IAM (AWS/GCP/Azure) - سیاست های منابع ابر (ترجیحا بررسی PaC استاتیک و در برنامه های IaC).
سفارشی - DSL/قوانین بیش از JSON/SQL برای جزئیات (به عنوان مثال، انطباق ML).

4) چرخه عمر سیاست

1. تعریف هدف و دامنه: «ممنوعیت بارگیری ظروف با آسیب پذیری های بالا/CRITICAL».
2. فرمول بندی در کد: Rego/Cedar/YAML.
3. تست ها: جداول حقیقت، موارد منفی، مبتنی بر اموال.
4. چک CI: linter، واحد، ادغام در تظاهرات ساختگی/درخواست.
5. انتشار و توزیع: انتشار در بسته نرم افزاری، امضا، تحویل به PDP/لبه.
6. نظارت: نرخ ضربه، تاخیر p95/p99، انکار سهم، داشبورد رانش.
7. استثنائات/چشم پوشی: زمان/حجم محدود، حسابرسی و متعلق به.
8. Refactoring و آرشیو: نسخه, سازگاری, مهاجرت.

5) ذخیره سازی و توزیع

Repo-layout: 'policies/< domain >/< policy> .rego' cedar 'yaml', 'tests/',' bundles/', 'schemas/'.
نسخه بندی: semver و «policy _ version» در پاسخ های PDP.
بسته های نرم افزاری - بسته های سیاست فشرده + طرح + پیکربندی، امضا شده (امنیت زنجیره تامین).
توزیع: کشش (PDP می کشد از registry/S3) و یا فشار (کنترل می فرستد).
ارزیابی جزئی: سیاست های اجرای سریع در محیط را پیش بینی می کند.

6) مدل داده ها و طرح ها

قرارداد تک متن: «موضوع»، «منابع»، «اقدام»، «env»، «قانونی».
JSON-Schema/Protobuf: اعتبار مدل های واقعی ؛ عدم تطابق طرحواره - علت «نامشخص → انکار».
نرمال سازی ویژگی: نام های متحد (به عنوان مثال، «tenant _ id»، «risk _ level»، «pii _ tags»، «image». ولنز ").

7) عملکرد و قابلیت اطمینان

کش راه حل: کلید (subject_hash، resource_key، عمل، policy_version) ؛ TTL کوتاه، ناتوانی توسط رویداد (تغییر نقش/برچسب).
حقایق محلی: PIP های سنگین را در مسیر داغ قرار ندهید - همگام سازی عکس های فوری.
Fail-open در مقابل fail-closed: امنیت دامنه بحرانی - fail-closed ؛ برای UX انتقادی - تخریب (نسخه به جای انکار).
بودجه تاخیر: هدف '<3-10 ms' در هر راه حل در حافظه PDP، '<30-50 ms' با PIP.

8) مدیریت استثنا (چشم پوشی)

زمان محدود (به عنوان مثال 7 روز)، با مالک اجباری و دلیل.

همراه: توسط منابع/پروژه/فضای نام ؛ ممنوعیت جهانی «برای همیشه»

ممیزی و یادآوری: گزارش در مورد چشم پوشی منقضی, خودکار نزدیک/تشدید.

9) معیارها و قابلیت مشاهده

پوشش سیاست: نسبت مسیرها/نقاط پایانی محافظت شده توسط PaC.
تاخیر تصمیم/QPS/میزان خطا.
نرخ انکار و مثبت/منفی کاذب (از طریق حالت خشک/سایه).
رانش: اختلاف بین برنامه (IaC) و واقعیت (زنده)، بین SDK و راه حل های سرور.
Аудит: 'decision _ id, policy_ids, version, attributes_digest, effect, reason'.

10) ضد الگوهای

سیاست ها «سخت افزار» را به کد بدون نسخه و تست.
عدم وجود شماتیک/اعتبار سنجی زمینه → تصمیمات غیر قابل پیش بینی.

یک فایل یکپارچه "مگا. رگو"

هیچ فرآیند استثنا وجود دارد → دور کتابچه راهنمای کاربر و هرج و مرج.
فقط کاربرد زمان اجرا بدون چپ-شیفت در CI) خرابی دیرهنگام (.
عوارض جانبی پنهان در سیاست (سیاست باید یک تابع خالص باشد).

11) مثال ها

11. 1 Rego (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 Rego: داده های صادرات از 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): ممنوعیت «: آخرین» و واجب است. منابع

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 از مقاله موتور نقش دوباره استفاده می شود.
مدیریت رضایت: سیاست «تبلیغات/شخصی سازی» به عنوان شرایط دسترسی داده/نقطه پایانی.
ناشناس/PII: سیاست منع آموزش/صادرات بدون ناشناس و پروفایل بودجه DP.
Geo-routing: سیاست برای مسیریابی ترافیک/داده ها توسط منطقه ذخیره سازی.

13) فرآیندها و مردم

صاحبان دامنه سیاست: امنیت، پلت فرم، داده ها، محصول/بازاریابی.
بررسی کنندگان: امنیت + صاحبان دامنه.
کاتالوگ سیاست: توضیحات هدف، ریسک، SLO، تماس، نمونه ها، لینک های حادثه.
آموزش: راهنماها و قطعه هایی برای توسعه دهندگان (نحوه نوشتن تست ها، نحوه اشکال زدایی Rego).

14) چک لیست معمار

1. حداقل مجموعه ای از دامنه ها و صاحبان تعریف شده است ؟

2. مخزن سیاست با آزمون, linter و CI?
3. آیا PDPs/PEPs در محیط قرار می گیرد, در API, در K8s, و در خطوط لوله داده?

4. آیا نمودارهای زمینه و اعتبار سنجی وجود دارد ؟

5. بسته های امضا و تحویل، حافظه پنهان و استراتژی ناتوانی ؟

6. معیارها (تاخیر، انکار، رانش)، تصمیم گیری و حسابرسی ؟

7. فرآیند استثنا با TTL و گزارش ؟

8. اجرای خشک/حالت سایه قبل از اجرا ؟

9. ارزیابی جزئی/precompilation برای نقاط داغ ؟

10. Runbook برای تخریب (fail-closed/allow-with-redaction) ؟

نتیجه گیری

Policy as Code قوانین را قابل تکرار، قابل اثبات و مدیریت بر اساس همان اصول برنامه می کند: کد بازبینی، تست ها، CI/CD، معیارها و رول بک ها. با اتصال PaC با مجوز (RBAC/ABAC)، انطباق و امنیت پلت فرم، شما یک حلقه کنترل واحد، قابل پیش بینی و مقیاس پذیر برای رفتار سیستم - از کنترل پذیرش به صادرات داده ها و خطوط لوله ML دریافت می کنید.