Находка и проблема формулировки
Повторяющийся результат обследований парков: большинство развёрнутых агентов ничего не делают. Arrakis в своём анализе парков агентов сообщает, что большинство агентов в обследованных парках находятся в спящем состоянии, при этом сохраняя учётные данные и живые подключения к нижестоящим системам. Число значит меньше, чем форма проблемы: активная поверхность парка и его авторизованная поверхность разошлись.
Это расхождение структурное, а не случайное. Спящее состояние — это состояние использования, которое фиксирует всё, что записывает вызовы: API-шлюз, хранилище трассировок, панель использования у провайдера. Авторизация — отдельное состояние, которым владеет провайдер идентичности, менеджер секретов, таблица грантов базы данных, записи OAuth SaaS-вендора. Ничто не заставляет эти два состояния совпадать. Агент может перестать появляться в телеметрии, тогда как его токен остаётся действительным месяцами, и ни одна система не расположена так, чтобы заметить это несоответствие.
Проверка безопасности наследует это разделение. Привычный вопрос — активен ли этот агент? — получает ответ от стека наблюдаемости, который является ненадёжным свидетелем. Несущий вопрос — до чего агент всё ещё может дотянуться, — и на него отвечает граф авторизации. Агент без трафика и с токеном на запись к производственной CRM не выведен из эксплуатации. Это безнадзорный принципал: набор постоянных разрешений без оператора, который за ним следит, без процесса, который можно пропатчить, и без владельца, который заметил бы, если бы его использовали.
Почему агенты уходят в спящее состояние, не теряя доступа
Три механизма объясняют большую часть дрейфа, и все три — обычная инженерия, а не халатность.
Первый — одноразовое провижинирование. Начальная настройка агента часто представляет собой скрипт, написанный один раз во время прототипа: он выпускает токен, записывает его в файл окружения или хранилище секретов и завершается. У скрипта нет понятия владельца записи и нет понятия срока действия, потому что на момент написания агент считался временным. Долгоживущие токены — путь наименьшего сопротивления, когда альтернатива — встроить поток продления в систему, которая может и не работать непрерывно.
Второй — пауза вместо удаления. Удаление агента требует знания того, что от него зависит, а это знание редко записывается. Определение инструмента, на которое ссылается другой агент, цель вебхука, запланированная задача, тестовая фикстура — любое из этого может молча сломаться при удалении принципала. Пауза обратима и дешева; удаление необратимо и требует инвентаризации, которой ни у кого нет. Рациональные операторы ставят на паузу, и пауза становится постоянной, так и не будучи решённой.
Третий — инерция контрагента. Подключение сохраняется, потому что система на другом конце не получает сигнала о том, что агент перестал работать. SaaS-интеграция хранит refresh-токен, пока его не отзовут. Внутренний сервис хранит грант сервисной учётной записи, пока кто-нибудь не отредактирует ACL. Молчание самого агента не является сообщением, которое получает любая из этих систем. Поэтому спящее состояние невидимо с точки зрения каждой стороны, кроме той, что перестала вызывать.
График отзыва
Исправление состоит в том, чтобы рассматривать истечение срока действия учётных данных как запланированное событие жизненного цикла с тем же статусом, что и выпуск, и сделать график принудительным, а не рекомендательным.
Максимальный срок жизни и владелец записи при выпуске. Каждые учётные данные, выпущенные для агента, несут два обязательных атрибута: жёсткий максимальный срок жизни и именованного владельца (команда, ротация, псевдоним дежурного — не личная учётная запись). Продление — это явное действие, выполняемое этим владельцем, а не автоматическое обновление, которое молча продлевает учётные данные навсегда. Короткие максимальные сроки жизни с дешёвым продлением инвертируют умолчание: учётные данные истекают, если кто-то утвердительно не поддерживает их жизнь, что превращает небрежность в истечение срока, а не в постоянный доступ.
Обнаружение спящего состояния по телеметрии последнего успешного вызова. Живость процесса — неверный сигнал. Контейнер, который работает, но выдаёт ошибки, или планировщик, который срабатывает в отозванное разрешение, выглядит живым и функционально мёртв. Важный сигнал — это отметка времени последнего успешного аутентифицированного вызова, агрегированная по учётным данным, а не по процессу. Именно эту отметку читает задача отзыва.
Поэтапный отзыв с логированием на каждом этапе. Отзыв — не одно действие, и отношение к нему как к одному действию — это то, как вывод из эксплуатации ломает зависимые системы. График выполняется поэтапно, каждый этап зависит от предыдущего, и каждый записывается:
- Отозвать области записи. Принципал сохраняет доступ на чтение, поэтому любой потребитель, который только читает, продолжает работать, а любой потребитель, который пишет, падает громко и заметно в окне, когда кто-то может отреагировать.
- Отозвать области чтения. После определённого тихого периода без инцидентов принципал полностью теряет доступ к данным. Зависимые системы, пережившие первый этап, теперь всплывают.
- Удалить принципала. Идентичность, его членства в группах, его записи секретов и его гранты контрагентов удаляются, и удаление записывается в тот же журнал аудита, что и предыдущие этапы.
Набросок объекта политики, который оценивал бы контрольный слой:
principal: agent.reporting.summariser
owner: team-data-platform
issued: 2025-02-11
max_lifetime: 90d
renewal: explicit
last_successful_call: 2025-03-04
stages:
- revoke_write: on_dormant(30d)
- revoke_read: on_dormant(60d)
- delete: on_dormant(90d)
log: audit.credentials
Честный компромисс — операционный шум. Поэтапный отзыв по замыслу порождает сбои, и некоторые из этих сбоев будут неудобными: квартальный отчёт, редко используемая интеграция, демонстрационное окружение. Альтернатива — не меньше сбоев, а более поздние и более тихие: безнадзорный принципал, используемый кем-то другим, обнаруженный постфактум. График обменивает предсказуемые, атрибутируемые поломки сейчас на непредсказуемый, неатрибутируемый доступ позже. Командам, которые его внедряют, следует ожидать, что первый цикл уйдёт на продление сроков жизни агентов, которые окажутся важными, — а это и есть та инвентаризация, которой у них раньше не было.
Что это меняет для парка
Инвентаризация перестаёт быть списком процессов и становится графом авторизации. Полезный вопрос о любом агенте — не работает ли он, а от имени каких принципалов он может действовать, до каких ресурсов эти принципалы дотягиваются и кто владеет каждым ребром. При таком перечислении спящие, но подключённые агенты — самая дешёвая для устранения поверхность атаки в парке: без миграции, без координации с живым потребителем, без окна изменений — и одновременно наименее вероятная быть замеченной, потому что ничто в нормальной работе их не касается.
Политика отзыва также должна находиться в том же контрольном слое, что и выпуск, а не в квартальном аудите. Аудит делает выборку; контрольный слой принуждает. Если система, которая выпускает учётные данные, — та же система, которая их аннулирует, спящее состояние становится состоянием, которое платформа разрешает по таймеру, а не находкой, которую поднимает ревьюер и откладывает команда. Роль аудита смещается к проверке того, что график выполнялся и что исключения обоснованы, — а это гораздо меньшая и более решаемая задача, чем реконструкция того, до чего может дотянуться парк агентов.
Недостающий этап жизненного цикла
Модели жизненного цикла агентов обычно идут от проектирования через развёртывание к выводу из эксплуатации, причём вывод из эксплуатации рассматривается как шаг очистки в конце. Находка Arrakis предполагает, что в модели отсутствует этап: отзыв, который начинается в момент, когда последний успешный вызов агента отдаляется, и заканчивается, когда его принципал удалён. У этого этапа своя телеметрия, свой владелец, свой график и свой журнал аудита. Агент, который сохраняет свои ключи после того, как перестал работать, не выведен из эксплуатации — его оставили работающим в единственном смысле, который важен для атакующего. Гигиена парка — это практика замечать по таймеру раньше, чем кто-либо другой.