На ревью инфраструктуры инженеру напоминают: хранилища с клиентскими документами нельзя открывать всем. Он исправляет настройку, проверка проходит. Через месяц другой сотрудник вручную включает публичный доступ в облачной консоли. Правило существует, проверка существует, а документы снова доступны не тем людям.
Policy as Code позволяет записать требование так, чтобы программа могла его проверить. Но польза зависит от места применения. Проверка файла перед выпуском, запрет реального изменения и поиск уже возникших нарушений — три разные возможности. Не стоит выдавать одну за все остальные.
Сначала договориться, что означает правило
«Не допускать небезопасные хранилища» — хорошее намерение, но плохое условие для автоматической проверки. Нужны признаки: какие ресурсы относятся к клиентским документам, какой доступ запрещён, какие исключения допустимы. Участники должны одинаково понимать и разрешённый результат, и нарушение.
Допустим, политика запрещает публичный доступ у ресурсов с меткой «клиентские данные». Теперь возникает вопрос: кто ставит метку и что произойдёт без неё? Если любой автор изменения может убрать признак, чтобы проверка перестала применяться, защита держится на добровольном участии. Идеально написанное правило будет проверять не тот набор ресурсов.
У политики нужен владелец требования. Инженер может реализовать условие, но не должен самостоятельно решать, разрешено ли хранить конкретные документы в выбранном месте. Такие решения фиксируют отдельно, а код проверяет те условия, которые действительно можно выразить и наблюдать.
Кто остановит действие после ответа «запрещено»
Движок политик получает сведения и вычисляет решение. Другая часть системы должна исполнить его: заблокировать запрос, остановить выпуск или только записать предупреждение. Например, Open Policy Agent специально разделяет вычисление решения и его применение. Установленный движок без подключённой проверки ничего не защищает.
Проверка в процессе сборки даёт раннюю обратную связь. Контроль на входе в рабочую платформу способен остановить и часть изменений вне этого процесса. Периодическая сверка ищет расхождения, которые уже возникли. У каждого способа свои задержки и охват; нужна карта путей изменения, включая административную консоль и аварийный доступ.
Новый запрет также не обязательно исправляет существующие ресурсы. В Kubernetes проверки admission применяются к соответствующим запросам и не превращают прежние объекты в правильные автоматически. Для накопленных нарушений понадобятся обнаружение, разбор и отдельное изменение. Массово отключать их без понимания владельцев и зависимостей опасно.
Правила тоже нуждаются в испытаниях
Тест «плохую настройку запретили» необходим, но недостаточен. Проверить нужно и рабочий разрешённый вариант: автоматическая защита, блокирующая все релизы, формально не пропустит ни одной ошибки. Команда довольно быстро найдёт, как её отключить.
Для хранилища полезны несколько случаев: закрытый доступ, публичный доступ, отсутствующая классификация, неподтверждённое исключение и попытка изменить защищающий признак. Проверяют также новую форму входных данных после обновления платформы. Примеры организации таких тестов есть в руководстве OPA.
Самая неприятная ошибка — когда вход изменился, правило больше не находит нужное поле, но результат выглядит успешным. Отсутствующие сведения, явное разрешение и техническая невозможность проверки должны различаться. В документации OPA по эксплуатации отдельно разобран неопределённый ответ: работающий HTTP-сервер ещё не означает, что нужная политика загружена и приняла решение.
Предупреждать или запрещать — разные этапы внедрения
Перед включением общего запрета разумно увидеть, кого он затронет. Режим наблюдения позволяет сравнить решения с ожидаемым поведением без остановки работы. Но предупреждение нужно так и называть: пока изменение проходит, обязательного ограничения ещё нет.
После разбора результатов можно ограниченно включить блокировку и проверить выпуск, аварийное исправление и отказ источника политик. Поведение при технической ошибке согласуют заранее. Для критичного изменения отсутствие подтверждённого разрешения не должно молча превращаться в разрешение. Обход на случай аварии требует узкой области, ответственного и последующего разбора.
Нужно также видеть, какая версия реально используется. При распределённой доставке часть проверяющих компонентов может ещё работать со старым правилом. Механизм bundles OPA предусматривает загрузку и активацию наборов политик. Публикация набора и его применение всеми участниками — не один момент. Подпись подтверждает происхождение, но не правильность самого требования.
Исключение должно заканчиваться
Бизнесу может понадобиться временно разрешить особый случай. Для него указывают ресурс, основание, одобрившего человека и срок. Право согласовать исключение отделяют от возможности поставить себе удобную метку. По окончании срока нужно либо устранить отклонение, либо заново принять решение, а не молча оставить пропуск навсегда.
Возврат старой версии политики тоже не всегда безопасен. Он способен восстановить доступ, который новая версия намеренно закрыла. Поэтому при ошибочном ограничении надо проверить разницу разрешений, а не автоматически отменять все последние изменения. Иногда исправление одного условия лучше полного возврата.
В журнале пригодятся идентификатор ресурса, версия правила, исход проверки и применённое исключение. Копировать туда весь клиентский документ ради объяснения запрета обычно не требуется. Сам журнал должен быть доступен тем, кто разбирает проблему, и защищён от произвольного изменения проверяемой командой.
Что считать результатом
Для первого правила достаточно показать, что повторяющееся нарушение перехватывается на нужных путях, нормальный выпуск проходит, а отказ объясняет способ исправления. Затем проверить уже существующие ресурсы. Иначе красивые результаты новых релизов будут скрывать старое открытое хранилище.
Политика экономит согласования только пока она понятна и поддерживается. Если каждую неделю требуется ручное исключение для обычной работы, надо пересмотреть требование или его реализацию. Количество правил здесь почти ничего не говорит о качестве контроля. Гораздо важнее, что компания умеет назвать защищённый риск, область проверки и оставшиеся обходные пути.