Policy as Code

1) «Саясат» деп не санау керек

• Қол жеткізу/авторизациялау: RBAC/ABAC, ReBAC, деректер экспорты, step-up (MFA).
• Инфрақұрылым қауіпсіздігі: Kubernetes admission-бақылау, бейнелер/құпиялар саясаты, желілік ережелер.
• Комплаенс және құпиялылық: келісімдерді басқару, PII-тегтеу, жергілікті есептік тәуліктер, гео-шектеулер.
• Конфигурациялары мен сапасы: «тыйым салу: latest», ресурстар лимиттері, міндетті ресурстар тегтері (Cloud).
• Деректер және ML: келісімсіз жинақтарда тренингке тыйым салу, k-анонимділік, DP-бюджеттер, Data Lineage-инварианттар.

2) PaC сәулет моделі

PAP (Policy Administration Point): репозиторий және басқару процестері (MR/PR, ревю, нұсқа).
PDP (Policy Decision Point): саясат бойынша шешімді есептейтін қозғалтқыш (OPA, Cedar-engine, жеке интерпретатор).
PEP (Policy Enforcement Point): қолдану нүктесі (API-шлюз, K8s webhook-адмиссия, ETL-трансформер, SDK).
PIP (Policy Information Point): атрибуттар/фактілер көздері: IdP, ресурстар каталогтары, деректер қоймасы, тәуекел жылдамдығы.
Decision Log/Audit: өзгермейтін шешім журналдары (инциденттерді талдау және сәйкестік үшін).

Ағын: сұрау → PEP контекстін қалыптастырады → PDP фактілерді жүктейді (PIP) → шешімді есептейді → PEP қолданады (allow/deny/редакция) → лог/метрика.

3) Құралдар мен домендер

OPA/Rego - декларативтік саясаттарға арналған әмбебап қозғалтқыш және тіл (Gatekeeper K8s webhook-admission, CI - Conftest, API - sidecar/қызмет).
Kyverno - YAML-да Kubernetes үшін декларативті саясат, патч/валидация/генерация.
Cedar (AWS/тасымалданатын) - «біреу не істеп жатыр» авторизациясына назар аударатын саясаткер тілі.
Cloud IAM (AWS/GCP/Azure) - бұлтты ресурстар саясаты (мүмкіндігінше статикалық және IaC жоспарларындағы PaC чек).
Custom - ерекшеліктер үшін JSON/SQL үстінен DSL/ережелер (мысалы, ML-комплаенс).

4) Саясаттың өмірлік циклі

1. Мақсатты және доменді анықтау: «High/CRITICAL осалдықтары бар контейнерлерді тиеуге тыйым салу».
2. Кодтағы формализация: Rego/Cedar/YAML.
3. Тесттер: шындық кестелері, теріс жағдайлар, property-based.
4. CI-тексерулер: линтер, unit, жалған манифестерде/сұрауларда біріктіру.
5. Релиз және тарату: bundle-да жариялау, қолтаңба, PDP/edge-ге жеткізу.
6. Мониторинг: hit-rate, latency p95/p99, deny үлесі, дрифт дашбордтары.
7. Ерекшеліктер/waivers: уақыт/көлем бойынша шектелген, аудитпен және иесімен.
8. Рефакторинг және мұрағат: нұсқалар, үйлесімділік, көші-қон.

5) Сақтау және тарату

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Нұсқалау: PDP жауаптарында semver және 'policy _ version'.
Bundles: (supply chain security) қол қойылған сығылған саясат пакеттері + схемалар + пішіндер.
Distribution: pull (PDP registry/S3 тартады) немесе push (контроллер таратады).
Partial evaluation: периметрде жылдам орындау үшін саясатты алдын ала есептеу.

6) Деректер моделі мен схемасы

Мәтінмәннің бірыңғай келісімшарты: 'subject', 'resource', 'action', 'env', 'legal'.
JSON-Schema/Protobuf: фактілік модельді растаңыз; схемалардың сәйкес келмеуі - «indeterminate → deny» үшін себеп.
Атрибуттарды қалыпқа келтіру: біріздендірілген атаулар (мысалы, 'tenant _ id', 'risk _ level', 'pii _ tags', 'image. vulns`).

7) Өнімділік және сенімділік

Шешімдердің кэші: '(subject_hash, resource_key, action, policy_version)'; қысқа TTL, оқиғалар бойынша мүгедектік (рөлдерді/тегтерді ауыстыру).
Жергілікті фактілер: ыстық жолда ауыр PIP тартпаңыз - снапшоттарды синхрондаңыз.
Fail-open vs fail-closed: сындарлы домендердің қауіпсіздігі - fail-closed; UX-критикалық үшін - деградация (deny орнына редакция).
Жасырындылық бюджеті: PDP жадындағы шешімге '<3-10 мс' мақсаты, '<30-50 мс' PIP.

8) Ерекшеліктерді басқару (waivers)

Уақыт бойынша шектелген (мысалы, 7 күн), міндетті иесімен және себебімен.
Сатып алынғандар: ресурс/жоба/неймспейс бойынша; жаһандық «мәңгілік» тыйым салу.
Аудит және ескертулер: аяқталатын waiver's бойынша есептер, автоматты жабу/эскалация.

9) Метрика және бақылау

Policy Coverage: PaC қорғалған жолдардың/эндпойндардың үлесі.
Decision Latency / QPS / Error rate.
Deny Rate және False Positive/Negative («dry-run/shadow» режимі арқылы).
Drift: жоспар (IaC) мен факт (live) арасындағы, SDK мен серверлік шешімдер арасындағы айырмашылық.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Қарсы үлгілер

Нұсқалары мен тесттері жоқ кодқа «тігілген» саясатшылар.
Контекст схемаларының/валидациясының жоқтығы → болжанбайтын шешімдер.
Бір "mega. rego».
Ерекшеліктер процесі жоқ → «қолмен аралау» және хаос.
Тек СІ-де «shift-left» жоқ runtime-қолдану (кеш істен шығу).
Саясаттағы жасырын сайд-эффектілер (саясат таза функция болуы тиіс).

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: тек иесіне немесе команда мүшелеріне оқу

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. Terraform-жоспарына арналған CI 5 Conftest

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 бюджеті жоқ тренинг/экспортқа тыйым салады.
Гео-бағыттау: трафикті/деректерді сақтау өңірлері бойынша бағыттау саясаты.

13) Процестер және адамдар

Саясат домендерінің иелері: қауіпсіздік, платформа, деректер, өнім/маркетинг.
Ревьюерлер: секьюритилер + домен иелері.
Саясат каталогы: мақсатты сипаттау, тәуекел, SLO, байланыс, мысалдар, инциденттерге сілтемелер.
Оқыту: әзірлеушілерге арналған гайдтар мен сниппеттер (тестілерді қалай жазу керек, Rego-ны қалай ретке келтіру керек).

14) Сәулетшінің чек-парағы

1. Домендер мен owners ең аз жиыны анықталған ба?
2. Тесті, линтері және CI бар саясаткерлердің репозиторийі?
3. PDP/PEP периметрде, API-де, K8s және деректер пайплайндарында орналастырылған ба?
4. Контекст схемалары мен валидация бар ма?
5. Бандлға қол қою және жеткізу, кэш және мүгедектік стратегиясы?
6. Метрика (latency, deny, drift), decision-лог және аудит?
7. TTL және есептілікпен алып тастау процесі?
8. Dry-run/shadow-Enforce алдындағы режімі?
9. Partial evaluation/« ыстық »жолдар үшін алдын ала компиляция?
10. Runbook деградацияға (fail-closed/allow-with-redaction)?

Қорытынды

Policy as Code ережелерді қолданбамен бірдей принциптер бойынша қайталанатын, тексерілетін және басқарылатын етеді: код-жаңару, тестілер, CI/CD, метрика және кері қайтару. PaC-ді авторизациямен (RBAC/ABAC), комплаенспен және платформаның қауіпсіздігімен біріктіре отырып, сіз admission-бақылаудан бастап деректер экспорты мен ML-пайплейндерге дейінгі жүйенің бірыңғай, болжамды және масштабталатын басқару контурын аласыз.