Policy engines и авторизация на масштабе

Почему размазанная авторизация деградирует

Авторизация начинается просто. Один сервис, пара ролей, if user.role == "admin" в начале обработчика. Это работает, поэтому следующий сервис копирует приём, а за ним и следующий. В отдельно взятый день в этом нет ошибки — это путь наименьшего сопротивления, и каждая команда локально права. Сбой эмерджентен: через год у тебя одно и то же правило выражено сорока чуть различными способами, на четырёх языках, против трёх слегка разных моделей ролей, и ни одного места, способного ответить на вопрос о политике.

У этой деградации три конкретные цены, которые зрелый инженер ощущает в продакшене. Первая — дрейф: когда «менеджеры могут одобрять расходы своей команды до $5k» меняется на «$10k», тебе нужно найти и поправить это в каждом сервисе, который это проверяет, — и ты один пропустишь, молча, потому что ничего не падает, когда проверка всего лишь устарела, а не отсутствует. Вторая — неаудируемость: на вопрос комплаенса или инцидента вроде «кто может удалить запись клиента» нет авторитетного ответа; ты грепаешь сорок репозиториев и надеешься. Третья — несогласованное применение: правило возврата, пускающее тимлидов в CSR-инструменте, но не в биллинге, — это не фича, это уязвимость, которую никто не решал отгружать. Размазанная авторизация не просто беспорядочна; это структурная причина уже знакомых тебе багов broken access control, помноженная на число твоих сервисов.

Вынос решения наружу: PDP и PEP

Лекарство — отделить принятие решения от применения. Это разделение PDP/PEP, и именно эта ментальная модель проясняет всё остальное:

• Точка применения политики (PEP, Policy Enforcement Point) живёт в твоём сервисе. Это код на границе запроса, который говорит: «Я собираюсь выполнить действие X над ресурсом Y для пользователя Z — мне можно?» Он не содержит правила. Он спрашивает.
• Точка принятия решения (PDP, Policy Decision Point) — это policy engine. Он держит правила как данные, получает вопрос плюс релевантный контекст (роли пользователя, владельца ресурса, атрибуты), вычисляет политику и возвращает allow или deny.

Код твоего приложения сжимается до одной строки: собрать вход, вызвать PDP, исполнить ответ. Логика — каждое условие, роль и исключение — переезжает в версионируемый policy-as-code, который живёт в одном репозитории, проходит ревью, тестируется в CI и деплоится независимо от потребляющих его сервисов. Выигрыш прямой: у вопроса аудитора теперь ровно одно место для поиска, правило возврата меняется ровно в одном файле, а применение одинаково везде, потому что каждый сервис спрашивает один и тот же мозг.

OPA и Rego на практике

Эталонная реализация этого паттерна — OPA (Open Policy Agent), выпускник CNCF, универсальный policy engine. Политики OPA пишут не на языке приложения; их пишут на Rego — декларативном языке запросов, созданном ровно под эту форму задачи: «для данного входа заключает ли хоть одно правило allow?» Тривиальная политика на Rego выглядит так:

package authz

default allow := false

allow if {
    input.action == "refund"
    input.user.role in {"billing_admin", "team_lead"}
}

Здесь важны две вещи. default allow := false — это deny by default, выраженный одной строкой: если ни одно правило не сработало, ответ «нет», ровно тот рефлекс, которого требует контроль доступа. И правило — это данные, которые вычисляет engine, а не поток управления, который ты сопровождаешь: ты меняешь, кому можно делать возврат, редактируя этот файл, а не охотясь по коду сервисов. OPA годится не только для авторизации сервисов — тот же engine и язык применяют admission control в Kubernetes (через Gatekeeper), проверки Terraform-планов и гейты CI, поэтому вложение в Rego окупается по всей платформе, а не только в одном API.

Операционный вопрос — где работает PDP, и вот тут зрелый инженер отрабатывает свою зарплату:

Доминирующий продакшен-ответ — модель сайдкара / локального демона: OPA работает рядом с каждым сервисом (тот же под, тот же хост), политика раздаётся как подписанные бандлы, которые агент периодически подтягивает, а решение — loopback-вызов, измеряемый микросекундами. Ты меняешь сетевой round-trip, который не можешь позволить на каждом запросе, на согласованность в конечном счёте для политики: изменённое правило достигает каждого узла за интервал опроса бандла. Для авторизации это обычно нормально; но чтобы отозвать скомпрометированного админа прямо сейчас, ты обязан понимать, что лаг распространения реален, и проектировать с учётом этого.

Что зрелый инженер делает неверно (и верно)

Соблазнительная ошибка — считать «мы внедрили OPA» финишной чертой. Вынос engine наружу не выносит наружу данные, которые нужны политике: если политика должна знать, что пользователь 42 владеет инвойсом 4815, этот факт владения обязан как-то дойти до PDP — переданным во входе, реплицированным в engine или дотянутым по ходу решения. Каждый вариант — реальный компромисс (раздувание входа против устаревшей реплики против зависимости на момент решения, которой ты пытался избежать). И engine теперь на твоём критическом пути: тебе нужно определённое поведение, когда PDP недоступен. Fail-closed (отказ при ошибке engine) — безопасный дефолт и правильный выбор для чувствительных действий; fail-open изредка оправдан для низкорисковых чтений, где доступность важнее строгости, — но это решение, которое ты принимаешь явно, на каждое действие, с открытыми глазами, а не запасной вариант, который ты обнаруживаешь во время аварии.