Policy-as-Code: контроль встроен, а не прикручен

Когда код начинают писать агенты, узким местом становится не генерация, а проверка. Ревью не масштабируется под поток изменений, а контроль постфактум физически не успевает: к моменту, когда артефакт доходит до приёмки, агент уже построил на нём следующие десять. В зрелом производстве около 70% несоответствий требованиям всплывает в самом конце — на сборке и приёмке, и каждое означает пересборку, ретест и повторный цикл согласований. Добавить ещё один финальный гейт эту задачу не решает: он лишь сдвигает очередь.

В докладе разберём, как контроль переносится в начало конвейера через Policy-as-Code. Архитектурно это четыре точки ответственности — PEP (перехват действия), PDP (вынесение вердикта), PIP (дотягивание недостающих атрибутов), PAP (разработка и версионирование политик) — на движке OPA с языком Rego. Покажу, почему для широкого комплаенса выбран именно OPA, а не Cedar или OpenFGA, и как одна и та же политика применяется в коммите, на pull request, в CI/CD, внутри агента и на приёмке — меняется только точка применения. Стек: OPA/Rego, Conftest для конвейера, Gatekeeper для Kubernetes, интеграция с агентами через обязательный шаг получения политик.

Отдельно — то, что обычно ломается при внедрении: как подключать регулирующие подразделения с разным уровнем зрелости (от ведения политик прямо в движке до поставки проверок через собственного агента), как устроен паспорт политики и её жизненный цикл, и что происходит с ответственностью, когда ручных проверок не остаётся. Ноль ручных проверок — это ноль молчаливых проверок, а не ноль ответственности: каждое отступление становится зарегистрированной развилкой с владельцем и сроком. Доклад основан на опыте построения такого контура в крупной регулируемой организации.