Шлюз HITL гарантує, що жодна високоризикова дія агента не виконується без людського судження. Ця кулінарна книга описує повний життєвий цикл затвердження — від моменту, коли керована дія створює запит, через визначення рівня ризику, людські рішення та запобіжний клапан аварійного доступу — щоб ви могли простежити кожну рухому частину перед тим, як зустрінете її у продакшні.
Якщо ви ще не прочитали модель авторизації, почніть з Управління. Посібник Керування та затвердження описує ту ж механіку з точки зору оператора; ця сторінка — покрокова довідка.
Життєвий цикл запиту
Запит затвердження відкривається закритим за замовчуванням та обмеженим у часі. Він починається як pending, несе
термін дії та нічого не авторизує, поки достатня кількість людей не прийме рішення. Запит не може
знизити власну планку — відповідна політика затвердження є авторитетною для порогу та
тайм-аутів.
Запит прив’язаний до хешу плану точного корисного навантаження виклику інструмента. Це захист від TOCTOU: якщо базова дія зміниться між запитом та рішенням, хеш не збігатиметься і затвердження не зможе прив’язатися. Застаріле затвердження ніколи не авторизує іншу дію.
Визначення рівня ризику
Чотири рівні визначають, скільки людського контролю вимагає керована дія:
| Рівень | Що означає |
|---|---|
low / medium | Призначається лише явною політикою затвердження — нічого не потрапляє сюди за замовчуванням |
high | За замовчуванням для всього, що потрапляє до черги затвердження. Потрібне одне людське затвердження |
critical | Обов’язковий мінімум двох осіб (NIST SP 800-53 AC-3(2) подвійна авторизація) |
Рівень перераховується з живого набору політик при кожному рішенні, ніколи не читається зі збереженого знімку. Зміна політики набирає чинності негайно. Застарілий рядок ніколи не може тримати планку нижче поточної класифікації — це закрито за замовчуванням за конструкцією.
Вбудований набір critical охоплює справді незворотне: розгортання та виведення з експлуатації,
видалення та стирання даних, зміни безпекового застосування та аварійного вимикача, зберігання
та ротація ключів, та виведення NHI з експлуатації.
Політика затвердження з явним risk_tier може підвищити або знизити замовчування для дії.
Але вона ніколи не може знизити дію critical нижче мінімуму подвійного контролю.
Крок за кроком
1. Керована дія створює запит
Керована дія — deploy apply, agent fire, перевизначення бюджету або будь-яка дія, що відповідає
політиці затвердження — досягає рушія затвердження. Рушій відкриває новий запит у стані 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, що записує рішення, результуючий статус запиту та рівень ризику, за яким воно було прийняте.
Обидва записи відбуваються в тій же транзакції, що й зміна стану. Ви не можете прийняти кероване рішення, яке журнал мовчки забуде.
Пов’язане
- Керування та затвердження — посібник оператора, що описує ту ж механіку.
- Управління — модель авторизації, позиція самоаудиту та механіка аварійного вимикача.
- Кулінарна книга: навчання з аварійним вимикачем — вправа із загальним шлюзом заборони.
- Аварійний вимикач — сторінка продукту для аварійної зупинки.