Policy as Code

1) Что считать «политикой»

• Доступ/авторизация: RBAC/ABAC, ReBAC, экспорт данных, step-up (MFA).
• Безопасность инфраструктуры: admission-контроль Kubernetes, политика образов/секретов, сетевые правила.
• Комплаенс и приватность: управление согласиями, 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-шлюз, webhook-адмиссион в K8s, ETL-трансформер, SDK).
PIP (Policy Information Point): источники атрибутов/фактов: IdP, каталоги ресурсов, склад данных, риск-скор.
Decision Log / Audit: неизменяемые журналы решений (для разбора инцидентов и соответствия).

Поток: запрос → PEP формирует контекст → PDP загружает факты (PIP) → вычисляет решение → PEP применяет (allow/deny/редакция) → лог/метрики.

3) Инструменты и домены

OPA/Rego — универсальный движок и язык для декларативных политик (webhook-адмиссион в K8s: Gatekeeper, в CI — Conftest, в API — sidecar/служба).
Kyverno — декларативные политики для Kubernetes в YAML, патч/валидация/генерация.
Cedar (AWS/переносимый) — язык политик с акцентом на авторизацию «кто-над-чем-что делает».
Cloud IAM (AWS/GCP/Azure) — политики облачных ресурсов (желательно чек-ить PaC статикой и в планах IaC).
Custom — DSL/правила поверх JSON/SQL для специфичек (например, 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/`.
Версионирование: semver и `policy_version` в ответах PDP.
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).
Бюджет латентности: цель `< 3–10 мс` на решение в памяти PDP, `< 30–50 мс` с PIP.

8) Управление исключениями (waivers)

Ограниченные по времени (например, 7 дней), с обязательным владельцем и причиной.
Скоупированные: по ресурсу/проэкту/неймспейсу; запрет глобальных «навсегда».
Аудит и напоминания: отчеты по истекающим waiver’ам, автозакрытие/эскалация.

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».
Нет процесса исключений → «ручные обходы» и хаос.
Только runtime-применение без «shift-left» в 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: чтение только владельцу или членам команды

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) Процессы и люди

Владельцы доменов политик: безопасность, платформа, данные, продукт/маркетинг.
Ревьюеры: секьюрити + владельцы домена.
Каталог политик: описание цели, риск, 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-пайплайнов.