Паттерн в публикациях
Окна истечения срока действия задаются с запасом, чтобы избежать сбоев в середине запуска. Задача, которая иногда занимает сорок минут, получает учётные данные, действительные в течение двадцати четырёх часов. Ничто не отзывает разрешение, когда запуск завершается нормально, потому что нормальное завершение не рассматривается как событие безопасности. Результат — накопление спящих полномочий, которые никто не отслеживает как поверхность риска. Они не появляются в проверках доступа, потому что никогда не предоставлялись как право доступа; они появляются в логах как успешная аутентификация от рабочей нагрузки, которая технически всё ещё жива.
Проблема не в том, что агент злонамерен. Проблема в том, что у жизненного цикла нет терминального состояния. Учётные данные, выданные для задачи и никогда не отозванные после её завершения, — это не временные учётные данные. Это постоянное разрешение с вводящим в заблуждение названием.
Почему одного срока действия недостаточно
Достаточно долгий запуск всегда потребует пути продления. Любой агент, выполняющий многошаговую работу — получение данных, вызов инструментов, ожидание одобрения человеком, повторные попытки при сбоях зависимости — рано или поздно превысит короткий срок действия. Путь продления — это место, где разрешения тихо становятся постоянными. Если продление автоматическое и привязано к идентичности, агент обновляет свой доступ бесконечно, и срок действия превращается в формальность, порождающую шум в логах, а не в средство контроля.
Срок действия, основанный на времени, также не коррелирует с завершением задачи. Опасное окно — это период после успеха, а не до него. Учётные данные, истекающие через час, безопасны, если запуск завершается за пять минут и разрешение отзывается по завершении. Они небезопасны, если запуск завершается за пять минут, а разрешение живёт ещё пятьдесят пять. Сокращение срока действия уменьшает окно, но не закрывает его, и вводит новый режим отказа: запуски, которые срываются в середине задачи из-за истечения срока действия учётных данных, что подталкивает операторов снова увеличивать окно. Средство контроля колеблется между слишком разрешительным и слишком хрупким, потому что измеряет не то, что нужно.
Конкретный механизм делает разрыв видимым. Рассмотрим разрешение, выданное как подписанный токен с утверждением субъекта agent:researcher-07 и областью действия read:customer_records. Токен имеет exp в двадцать четыре часа. Запуск, которому он был нужен, завершился за восемь минут. В течение оставшихся двадцати трёх часов пятидесяти двух минут любой процесс, способный предъявить этот токен — сам агент, скомпрометированный инструмент, воспроизведение из лога — имеет тот же доступ, что и исходный запуск. Субъект токена — агент, а не запуск, поэтому у центра выдачи учётных данных нет утверждения, по которому можно определить, что работа завершена. Отзыв потребовал бы перечисления токенов по идентичности агента и угадывания, какие из них устарели. Это операционное предположение, а не контракт.
Терминальное состояние для каждого разрешения
Решение — это контракт жизненного цикла, а не более короткий срок действия. Каждые учётные данные выдаются против идентификатора запуска и несут обязательный терминальный переход: completed, failed или abandoned. Идентификатор запуска — это субъект разрешения, а не идентичность агента. Идентичность агента может присутствовать как атрибут, но не как то, к чему привязано разрешение.
Оркестратор испускает терминальное событие. Он уже знает, когда запуск завершается, потому что это компонент, который запускает и останавливает запуски. Когда запуск достигает терминального состояния, оркестратор публикует событие — run.completed, run.failed, run.abandoned — в центр выдачи учётных данных. Центр выдачи учётных данных потребляет событие и отзывает каждое разрешение, выданное против этого идентификатора запуска. Отзыв — не ответственность агента. Агенту, который падает, зацикливается или убит, нельзя доверить уборку за собой, и дизайн, зависящий от сотрудничества агента, не является средством контроля.
Продление — это новое разрешение с новым идентификатором и явным обоснованием. Если запуску нужно больше времени, оркестратор запрашивает новые учётные данные против того же идентификатора запуска, и центр выдачи учётных данных записывает запрос с причиной: continuation: awaiting human approval. Тогда журнал аудита показывает продолжение, а не расширение. Оператор, просматривающий историю, видит последовательность разрешений, каждое с началом и концом, а не одно разрешение, которое тихо обновлялось. Различие важно, потому что расширение скрывает момент, когда временное разрешение стало постоянным; продолжение делает этот момент явным и подлежащим проверке.
Компромисс реален. Контракт с терминальным состоянием требует, чтобы оркестратор был авторитетным источником жизненного цикла запуска, и чтобы центр выдачи учётных данных был доступен при завершении запуска. Если оркестратор умирает, не испустив терминальное событие, разрешение остаётся до тех пор, пока процесс согласования его не поймает. Это согласование — это очистка, которая сравнивает активные разрешения с активными запусками и отзывает разницу. Она медленнее, чем отзыв по событию, и вводит окно, в течение которого разрешение переживает свой запуск. Контракт не устраняет окно; он ограничивает его и делает наблюдаемым. Система, которая не может терпеть даже ограниченное окно, нуждается в другой архитектуре — короткоживущие токены, выдаваемые на каждый шаг, с оркестратором в качестве единственного держателя — но эта архитектура имеет свою цену в задержке и сложности. Контракт с терминальным состоянием — это прагматичная середина: он принимает ограниченное окно сог
Операционные проверки
Перечислите постоянные разрешения, удерживаемые идентичностями агентов, и сравните их с активными запусками. Разница — это экспозиция. Это соединение двух наборов данных, которые уже есть у большинства команд: список выданных разрешений центра выдачи учётных данных и список выполняющихся задач оркестратора. Запрос не экзотический, но его редко выполняют, потому что учётные данные агентов часто рассматриваются как инфраструктура, а не как права доступа.
Оповещайте о разрешениях, которые переживают свой запуск более чем на заданный запас. Запас — это политическое решение, а не техническая константа. Запас в несколько минут учитывает задержку согласования; запас в часы указывает на то, что терминальное событие не испускается или не потребляется. Оповещение должно срабатывать на разрешении, а не на агенте, потому что агент — не единица риска. Единица риска — разрешение.
Рассматривайте осиротевшие разрешения как пункт проверки доступа с той же периодичностью, что и права доступа людей. Если доступ сотрудника-человека проверяется ежеквартально, постоянные разрешения агента должны проверяться по тому же графику с теми же требованиями к доказательствам. Проверка должна задавать конкретный вопрос: с какими запусками связаны эти разрешения, и активны ли эти запуски? Разрешение, которое нельзя связать с активным запуском, — это находка, а не ложное срабатывание.
Более глубокая мысль в том, что учётные данные агентов не являются особым случаем. Это права доступа с жизненным циклом, и жизненному циклу нужно терминальное состояние. Срок действия — это свойство учётных данных; завершение — это свойство разрешения. Смешение этих двух понятий превращает завершённый запуск в постоянное разрешение. Решение — не более короткие часы. Решение — контракт, который гласит: когда работа заканчивается, доступ заканчивается.
Что инструментировать в первую очередь
Начните с идентификатора запуска. Если разрешения нельзя привязать к запуску, контракт жизненного цикла невозможен. Затем испускайте терминальное событие из оркестратора, даже если центр выдачи учётных данных ещё не потребляет его, чтобы поток событий существовал и мог быть воспроизведён. Затем постройте очистку согласования, потому что это страховка для каждого режима отказа, который не покрывает путь событий. Порядок важен: сначала идентичность, затем события, затем согласование. Пропуск первого шага порождает оповещения, по которым нельзя действовать; пропуск третьего порождает систему, которая корректна только тогда, когда корректно всё остальное.