Шлюз HITL гарантирует, что ни одно высокорисковое действие агента не выполняется без человеческого суждения. Этот рецепт описывает полный жизненный цикл согласования — от момента, когда управляемое действие создаёт запрос, через определение уровня риска, человеческие решения и предохранительный клапан экстренного обхода — чтобы вы могли проследить каждую движущуюся часть до встречи с ней в продакшене.
Если вы ещё не читали модель авторизации, начните с Управление. Руководство Управление и согласование описывает тот же механизм с точки зрения оператора; эта страница — пошаговый справочник.
Жизненный цикл запроса
Запрос на согласование открывается в режиме запрета по умолчанию и с ограничением по времени. Он начинается со статуса pending,
несёт время истечения и ничего не авторизует, пока достаточное количество людей не примет решение. Запрос не может
снизить собственную планку — соответствующая политика согласования является авторитетной для порога и
таймаутов.
Запрос привязан к хешу плана точной полезной нагрузки вызова инструмента. Это защита от TOCTOU: если базовое действие изменится между запросом и решением, хеш не совпадёт и согласование не может привязаться. Устаревшее согласование никогда не авторизует другое действие.
Определение уровня риска
Четыре уровня определяют, сколько человеческого контроля требуется для управляемого действия:
| Уровень | Что означает |
|---|---|
low / medium | Назначается только явной политикой согласования — ничто не попадает сюда по умолчанию |
high | Значение по умолчанию для всего, что попадает в очередь согласования. Требуется одно человеческое согласование |
critical | Обязательный минимум двух человек (NIST SP 800-53 AC-3(2) двойная авторизация) |
Уровень пересчитывается из живого набора политик при каждом решении, никогда не читается из сохранённого снимка. Изменение политики вступает в силу немедленно. Устаревшая запись никогда не может удерживать планку ниже текущей классификации — это запрет по умолчанию по конструкции.
Встроенный набор critical покрывает действительно необратимое: развёртывание и вывод из эксплуатации,
удаление и стирание данных, изменения безопасности и аварийного выключателя, хранение
и ротация ключей, и вывод NHI из эксплуатации.
Политика согласования с явным risk_tier может повысить или понизить уровень по умолчанию для действия.
Но она никогда не может понизить действие critical ниже минимума двойного контроля.
Шаг за шагом
1. Управляемое действие создаёт запрос
Управляемое действие — развёртывание apply, запуск агента, переопределение бюджета или любое действие,
соответствующее политике согласования — попадает в движок согласования. Движок открывает новый запрос в состоянии pending.
2. Запрос привязывается к хешу плана
Запрос записывает хеш точной полезной нагрузки вызова инструмента. Эта привязка к хешу плана — защита от TOCTOU: решение авторизует только то действие, для которого был создан запрос.
3. Уровень риска определяется из текущей политики
Движок вычисляет живой набор политик (RBAC, нативный ABAC и любой внешний PDP) для определения уровня риска. Уровень никогда не кешируется из предыдущего вычисления.
4. Человек-рецензент принимает решение
Человек с достаточной ролью выдаёт approve или deny. Сервер обеспечивает три
инварианта в этой точке, привязанных к стабильной идентичности пользователя:
- Разделение обязанностей. Запросивший не может решать свой собственный запрос. Это привязано к стабильной идентичности пользователя, а не к строке учётных данных, которую один человек мог бы варьировать.
- Защита от дублирования решающих. Уникальный индекс поддерживает гонку дублирования решающих — один человек считается один раз для порога.
- Привязка истечения. Истекший запрос никогда не может получить обязывающее решение, даже до того, как очистка материализует истечение. Эффективный статус пересчитывается при каждом решении.
5. Критические действия: двойной контроль с AAL3
Для уровня critical: порог ограничен снизу двумя различными человеческими согласующими. Нижний
предел применяется и при создании (сохранённый порог никогда не может начинаться ниже двух), и
повторно при решении (запрос, созданный до того, как действие стало критическим, всё равно не может
пройти с одним человеком).
Каждый решающий человек должен иметь свежую аппаратно-подтверждённую сессию — WebAuthn или PIV повышение (AAL3). Системный токен не несёт человеческой гарантии и отклоняется.
6. Решение записывается в журнал
Каждое решение добавляет неизменяемую строку в след решений запроса и событие журнала, записывающее решение, результирующий статус и уровень риска, при котором оно было принято. Журнал является только для добавления, хеш-цепочкой и подписан Ed25519 — перезапись истории криптографически обнаруживаема.
Истечение
Истечение определяется при чтении, а не записывается один раз. Истекший запрос никогда не может получить обязывающее решение, даже если фоновая очистка ещё не материализовала истечение. Эффективный статус всегда пересчитывается, поэтому медленная очистка — это косметическая задержка, а не брешь в безопасности.
Конфигурация политик
Политики согласования позволяют переопределить уровень риска по умолчанию для класса действий. Политика с
явным risk_tier может переместить действие с high на low или повысить medium до
critical. Единственное ограничение: вы никогда не можете понизить critical ниже минимума двойного контроля. Требование двух человек для необратимых действий является структурным, а не
настраиваемым.
Экстренный обход
Когда кворум недоступен — инцидент в 03:00, когда второй согласующий спит — экстренный обход предоставляет аудируемый предохранительный клапан. Он громкий по конструкции.
Активация требует всего перечисленного:
- Активатор является admin, всегда реальным человеком — системный токен отклоняется.
- Свежее повышение AAL3 (WebAuthn или PIV).
- Письменное обоснование, записанное в той же транзакции.
- Активно записываемая сессия как предусловие.
Ограничение по времени: грант по умолчанию действует один час, жёсткий максимум 24. Экстренная ситуация, которая требует больше, — это режим работы, а не экстренная ситуация, и должна проходить через обычный двойной контроль.
Каждое использование записывается. Каждое действие, выполненное в режиме экстренного обхода, добавляет неизменяемую строку и событие журнала, указывая грант, действие и субъект. Действие, выполненное в режиме экстренного обхода, навсегда отличимо от правильно согласованного.
Принудительная пост-ревизия. Новый грант не может быть активирован, пока любой предыдущий грант не проверен. Проверку должен провести другой человек, не активатор. Нельзя накапливать экстренные ситуации, чтобы избежать контроля.
Экстренный обход ослабляет отсутствующий кворум; он никогда не отменяет явный отказ. Запрос, который кто-то намеренно отклонил, остаётся отклонённым.
Что записывается
Каждое решение — согласование, отказ, истечение или использование экстренного обхода — добавляется в два места:
- След решений запроса: неизменяемая последовательность строк решений на самом запросе, каждая несущая решающего, вердикт и временную метку.
- Аудиторский журнал: хеш-цепочное, подписанное Ed25519 событие, записывающее решение, результирующий статус запроса и уровень риска, при котором оно было принято.
Обе записи происходят в той же транзакции, что и изменение состояния. Вы не можете принять управленческое решение, которое журнал молча забудет.
Связанные материалы
- Управление и согласование — руководство оператора, описывающее тот же механизм.
- Управление — модель авторизации, позиция самоаудита и механика аварийного выключателя.
- Рецепт: учения аварийного выключателя — упражнение шлюза запрета на уровне всего окружения.
- Аварийный выключатель — страница продукта для экстренной остановки.