Два вендора, один недостающий артефакт
Descope Agentic Identity Hub 3.0 и ServiceNow AI Passport — оба являются разумным ответом на реальную проблему: нечеловеческие вызывающие стороны размножаются быстрее, чем стек идентичности был рассчитан поглощать. Оба продукта занимают схожую архитектурную позицию. Агент получает учётные данные, эти учётные данные предъявляются шлюзу или API, и принимающий сервис решает, признавать ли вызов. Пресса вокруг обоих анонсов подаёт это как прорыв в области идентичности (материал о Descope, материал о ServiceNow.
Оба предполагают нечто, чего ни один из них не поставляет. Любой паспорт, хаб и формат учётных данных исходит из того, что на стороне предприятия существует разрешаемый принципал: стабильный идентификатор агента, именованный владелец (человек или система), определённая область действия и жизненный цикл. В большинстве организаций такого реестра не существует ни в какой авторитетной форме. Принципалы агентов живут в состоянии Terraform, в пространстве имён сервисных аккаунтов Kubernetes, в консоли вендора и в электронной таблице, которую ведёт тот, к кому в последний раз эскалировали проблему.
Теневые агенты — это видимый симптом. Причина — неполный каталог принципалов. Когда нет канонического места для регистрации агента, команды регистрируют его там, где идёт работа, и полученная инвентаризация представляет собой набор частичных представлений, которые ни один процесс управления не может согласовать. Учётные данные, выпущенные для неоднозначного принципала, этого не исправляют; они добавляют криптографическую подпись к нерешённому вопросу.
Что паспорт не может засвидетельствовать
Учётные данные доказывают, кто вызывает. Они не доказывают, на что вызывающий был уполномочен в этот момент, и не доказывают, что это уполномочие всё ещё действительно. Это вопросы каталога, и на них отвечают данные, которых формат учётных данных не несёт.
Рассмотрим цепочку делегирования. Человек-оператор уполномочивает агента-оркестратора, который порождает субагента, который вызывает инструмент. Каждый переход может выпускать производный токен. Цепочка надёжна только при наличии терминального состояния: когда уполномочие человека отозвано, каждый производный токен ниже по цепочке должен стать непригодным. Без этого свойства отзыв носит рекомендательный характер. Субагент продолжает работать, потому что его токен был подписан, когда цепочка была действительна, и ничто в токене не несёт указателя обратно на запись в каталоге, которая могла бы его аннулировать.
Это проблема долгоживущего сервисного аккаунта с новой терминологией. Сервисный аккаунт со статичным секретом и без срока действия опасен, потому что ничто не вынуждает к пересмотру. Паспорт агента без привязки к жизненному циклу имеет ту же форму: он удостоверяет идентичность в момент выпуска и ничего не говорит о том, существует ли стоящий за ним принципал по-прежнему, тот ли у него владелец и те ли области действия.
Конкретный механизм, решающий эту задачу, — сделать учётные данные короткоживущими и привязать каждый токен к ревизии реестра. Токен несёт идентификатор принципала и отметку версии реестра. Шлюз не доверяет одной лишь подписи; он разрешает принципала по реестру во время запроса и отклоняет вызов, если ревизия реестра ушла дальше отметки токена таким образом, что это меняет область действия или владельца. Тогда отзыв становится записью в реестре, а распространение зависит от того, как быстро шлюзы обновляют своё представление о реестре, а не от того, сколько токенов было выпущено.
Честный компромисс — это задержка и связанность. Каждый запрос теперь включает обращение к каталогу или к кэшированному представлению с коротким временем жизни. Это обращение — зависимость: если реестр недоступен, а кэш истёк, стратегия fail-closed по умолчанию отклоняет легитимный трафик. Команды, выбирающие fail-open ради доступности, заново создают исходную проблему, потому что устаревший кэш и отозванный принципал с точки зрения шлюза выглядят одинаково. Проектное решение состоит не в том, добавлять ли эту зависимость, а в том, где её разместить и как ограничить радиус поражения при её отказе.
Последовательность «сначала реестр»
Практический порядок таков: реестр, затем области действия, затем формат учётных данных. Выбор продукта-паспорта до того, как существует каталог принципалов, означает, что продукт будет настроен под ту инвентаризацию, которая доступна, — а это и есть частичная инвентаризация, породившая проблему.
Начните с перечисления принципалов агентов. Для каждого зафиксируйте:
- стабильный идентификатор, который не является текущим именем среды выполнения, потому что среды выполнения переименовывают
- владельца, выраженного как объект каталога, а не как название команды в тикете
- области действия, которые агент может использовать, в виде явных пар «ресурс и действие»
- дату истечения или пересмотра, чтобы никакой принципал не был по умолчанию действителен бессрочно
- цепочку делегирования, в которой он участвует, включая то, какие принципалы могут его порождать
Это неблагодарная работа, и именно она определяет, удержится ли что-либо дальше по цепочке. Перечисление, дающее список имён агентов без владельцев и областей действия, — это не реестр; это инвентаризация, и она не обеспечит отзыв.
Изменения областей действия должны быть событиями с контролем изменений и зафиксированным утверждающим. Механизм значит меньше, чем свойство: когда набор областей действия агента меняется, есть запись о том, кто утвердил изменение и когда, и изменение порождает новую ревизию реестра. Именно эту ревизию читают шлюзы и песочницы. Песочница, разворачивающая среду агента, должна читать области действия из реестра, а не из манифеста, закоммиченного вместе с кодом агента, потому что манифест дрейфует, а реестр — источник истины.
Тот же реестр должен лежать в основе эмитента учётных данных. Когда эмитент выпускает токен, он читает принципала и набор областей действия из реестра и проставляет ревизию. Когда владелец меняется, меняется реестр, и следующий выпуск это отражает. Когда принципал выводится из эксплуатации, реестр помечает его как выведенный, и шлюзы отклоняют токены с этим идентификатором независимо от действительности подписи.
Куда должен идти бюджет на управление
Инстинкт сначала купить формат учётных данных понятен. Паспорта и хабы демонстрируемы, они ложатся в статью закупок и дают видимый артефакт. Реестр даёт электронную таблицу и набор споров о владении, что труднее предъявить и труднее финансировать.
Но учётные данные находятся ниже по цепочке от каталога. Паспорт, выпущенный для неразрешаемого принципала, — это подписанное утверждение, которое нельзя проверить ни против чего авторитетного, а хаб, маршрутизирующий на таких утверждениях, — это хорошо инструментированный путь для тех же теневых агентов, которых он должен был выявить. Реестр — это артефакт, придающий учётным данным смысл, и именно он должен существовать первым. Финансируйте перечисление, модель владения и путь отзыва, затем выбирайте формат, который из них читает.
FAQ
Почему учётных данных недостаточно самих по себе? Учётные данные удостоверяют идентичность в момент выпуска. Они не несут текущую область действия, владельца или состояние жизненного цикла, поэтому не могут ответить, всё ли ещё уполномочен вызывающий в момент вызова.
Что делает цепочку делегирования отзываемой? Терминальное состояние в каталоге. Когда уполномочие исходного человека отозвано, производные токены должны стать непригодными, а для этого шлюзы должны разрешать токены по ревизии реестра, а не доверять одной лишь подписи.
Каков минимально жизнеспособный реестр агентов? Стабильный идентификатор принципала, владелец с опорой на каталог, явные области действия в виде пар «ресурс и действие», дата пересмотра или истечения и отношения делегирования, в которых принципал участвует.
Какова основная цена идентичности «сначала реестр»? Каждый запрос зависит от обращения к каталогу или от короткоживущего кэша. Fail-closed защищает корректность ценой доступности во время отказов реестра; fail-open защищает доступность ценой гарантий отзыва.