Временный доступ к продакшену: разрешения, которые заканчиваются вместе с задачей

Доступ AI-агента программирования к продакшену должен прекращаться потому, что так решил механизм авторизации, а не потому, что кто-то собирался вернуться к этому позже. Цель, крайний срок и проверка после закрытия превращают рискованное исключение в ограниченное разрешение, которое может проверить другой инженер.

Я видел, как контроль доступа ломается самым будничным образом: инцидент решен, задача закрыта, а учетные данные по-прежнему работают. В тот день ничего драматичного не происходит. Через несколько месяцев те же учетные данные появляются в постороннем скрипте, старый процесс агента возобновляет работу или человек использует их просто потому, что так удобнее. Первоначальное исключение по невнимательности превращается в постоянный доступ к продакшену.

Временный доступ к продакшену должен содержать три факта, которые может проверить точка применения политики: зачем агенту разрешено действовать, к чему он может обращаться и когда должен остановиться. Последняя часть так же важна, как первые две. Если вы не можете показать, что после закрытия задачи запрос будет отклонен, задача еще не завершена.

Крайний срок должен отклонять запросы, а не украшать задачу

Указанное время окончания имеет силу только тогда, когда компонент, выполняющий или разрешающий действие, проверяет его при каждом запросе. Трекер проекта, запись в календаре или напоминание в чате не помешают старому процессу вызвать API в 02:00.

Это различие застает команды врасплох, потому что их процесс изменений выглядит дисциплинированным. Они требуют задачу, проверяющего и статуса закрытия. Затем они выдают агенту учетные данные, которые остаются действительными, пока кто-то вручную их не заменит. Рабочий процесс фиксирует намерение, а учетные данные сохраняют полномочия.

Размещайте срок действия там, где запрос пересекает границу продакшена. В зависимости от архитектуры это может быть провайдер идентификации, выдающий короткоживущий токен, шлюз доступа, проверяющий базу разрешений, валидатор SSH-сертификатов или брокер, который хранит учетные данные и выполняет действие. Защищенный сервис должен получать запрос, который он сможет отклонить после крайнего срока.

В описании архитектуры нулевого доверия NIST SP 800-207 делает полезное замечание: решения о доступе следует принимать до установления сессии с корпоративным ресурсом, а доступ выдавать отдельно для каждой сессии. Это не значит, что каждому приложению нужно копировать полноценный продукт нулевого доверия. Но выдача разрешения один раз с предположением, что оно навсегда останется уместным, противоречит этой модели.

Для агентов проверяйте доступ как минимум в начале каждого действия. Для долгих операций нужно принять отдельное решение: либо позволить уже начатой операции завершиться в пределах ограниченной аренды, либо отменить ее после окончания аренды. Определите поведение до аварии, потому что незапланированное прерывание восстановления базы данных может быть не менее опасным, чем неограниченный доступ.

Крайний срок должен быть отметкой времени в единой согласованной системе, обычно UTC. Не пишите «до конца дня» в надежде, что все системы понимают под этим один и тот же день. Храните 2025-04-18T16:30:00Z, показывайте согласующему человеку местное время, а путь запроса сравнивайте с сохраненной отметкой.

Цель должна ограничивать разрешение

Цель полезна только тогда, когда ограничивает действия агента. «Помочь с продакшеном» и «исследовать предупреждение» описывают настроение, а не границу полномочий.

Сформулируйте цель так, чтобы инженер, который не согласовывал доступ, мог решить, относится ли к ней конкретный запрос. Практичная формулировка называет рабочий элемент, из-за которого возникла задача, объект, разрешенную операцию и условие завершения. Например:

Исследовать рост числа ошибок оформления заказа в инциденте INC-482. Читать журналы и статус развертывания сервиса оформления заказа. Перезапускать только обработчик оформления заказа, если руководитель инцидента одобрит перезапуск. Завершить доступ после решения INC-482 или в 16:30 UTC, в зависимости от того, что наступит раньше.

Такая формулировка создает проверяемые решения. Чтение базы данных биллинга ей не соответствует. Отправка несвязанного изменения приложения тоже. Для перезапуска обработчика требуется явно названное условие согласования. Агент по-прежнему может быть полезен, не получая чистый чек.

Область действия должна включать больше, чем слово «продакшен». Привязывайте разрешение к конкретным объектам:

• названным API-хостам, репозиториям или SSH-хостам;
• конкретным методам или командам, например GET /health или запросу статуса развертывания;
• названным окружениям и идентификаторам учетных записей;
• максимальному числу действий или частоте запросов, если задача предполагает повторяющиеся вызовы;
• человеку-владельцу, который может остановить работу.

Избегайте популярной рекомендации дать агенту широкие права на чтение, потому что «чтение безопасно». Доступ на чтение часто раскрывает записи клиентов, конфигурацию, структуру системы, историю развертываний или учетные данные, случайно попавшие в старые журналы. Он также позволяет агенту собрать гораздо больше контекста, чем нужно для цели. Дайте ему конкретные точки наблюдения и диапазон запросов к журналам, необходимые для задачи.

Есть еще одна граница, которую команды часто размывают: цель задачи не равна подсказке. Подсказка говорит агенту, что вы попросили его попробовать. Цель авторизации сообщает точке применения политики, что разрешено даже в случае изменения подсказки, неверного вывода модели или вредоносных инструкций в ответе инструмента. Считайте подсказки недоверенными входными данными для решения о доступе.

Учетные данные и полномочия истекают по-разному

Учетные данные доказывают, что вызывающая сторона владеет определенным секретом. Авторизация решает, может ли эта сторона выполнить данный запрос сейчас. Для завершения доступа вместе с работой нужны обе части.

Токен предъявителя с утверждением exp может хорошо ограничивать время, если принимающий API проверяет подпись, аудиторию и срок действия при каждом запросе. Универсальным решением он не становится. Некоторые сервисы кэшируют аутентификацию, принимают непрозрачные токены, проверяемые в другом месте, или авторизуют токен по серверному состоянию, которое остается активным. Токен, истекающий через 15 минут, также не соответствует границе задачи, если задача завершилась через четыре минуты.

Та же проблема возникает с SSH. OpenSSH поддерживает подписанные пользовательские сертификаты с интервалом действия. В руководстве ssh-keygen параметр -V описан как параметр интервала действия. Короткоживущий сертификат намного лучше, чем долгоживущий закрытый ключ в рабочей области агента, но его срок отвечает только на вопрос о времени. Нужно также ограничить субъектов, целевые хосты и поведение команд.

Эта команда показывает сертификат, действующий 20 минут:

ssh-keygen -s ./user_ca -I agent-run-7f3a \\
  -n deploy-readonly -V +20m ./agent-run-7f3a.pub

Обычно вывод содержит имя файла подписанного открытого ключа, например:

Signed user key ./agent-run-7f3a-cert.pub: id "agent-run-7f3a" serial 0 for deploy-readonly valid from 2025-04-18T16:00:00 to 2025-04-18T16:21:00

Не принимайте этот сертификат за полное разрешение на задачу. Если удаленная учетная запись может выполнять произвольные команды, сертификат по-прежнему разрешает произвольные команды до 16:21. Используйте ограниченную учетную запись, принудительную команду или список разрешенных команд на хосте, если этого требует работа.

Отзыв и истечение срока тоже различаются. Истечение предсказуемо и работает даже при недоступности центральной службы отзыва. Отзыв досрочно прекращает полномочия, когда инцидент решен, агент ведет себя неожиданно или согласующий отзывает согласие. Хорошая архитектура поддерживает оба механизма: короткий максимальный срок и немедленный отзыв.

Закрытие задачи должно создавать машиночитаемое событие

Закрытие задачи должно создавать событие, которое может обработать компонент управления доступом. Изменение человеком статуса задачи без подключенного пути отзыва создает ложное ощущение завершенности.

Используйте два условия завершения. Первое, жесткое время окончания, задается при создании разрешения. Второе, более ранний сигнал закрытия от рабочей системы или ответственного человека. Фактическим окончанием становится более раннее из этих условий. Повторное открытие задачи не должно молча восстанавливать старое разрешение. Для этого нужны новое согласование и новый срок.

Это защищает от знакомой ошибки. Агент получает доступ для работы с инцидентом. Он сообщает, что исправил проблему, и оператор закрывает инцидент. Второй процесс агента все еще держит аутентифицированное соединение и продолжает собирать диагностику. Позже команда снова открывает инцидент, но никто не замечает, что старый процесс не остановился. Решение о доступе оказалось связано с описанием в задаче, а не с жизненным циклом настоящего процесса.

Привязывайте авторизацию к неизменяемому идентификатору запуска, а не только к идентификатору задачи. У задачи может быть несколько запусков в течение нескольких дней. Для каждого запуска нужны свои начало, конец и владелец. При завершении запуска отзывайте разрешение. При закрытии задачи отзывайте все еще активные запуски, связанные с ней.

Для события закрытия нужен идемпотентный получатель. Системы повторяют доставку вебхуков, а операторы нажимают кнопки дважды. Запрос на отзыв должен принимать повторную доставку и сохранять первое фактическое время окончания, а не считать дубликат ошибкой, которую кто-то проигнорирует.

Фиксируйте источник закрытия. Изменение статуса в системе управления задачами, ручная остановка руководителем инцидента, завершение процесса и жесткое истечение срока по-разному выглядят во время расследования. Для доступа результат один, но в аудите должна сохраняться причина завершения.

Не выдавайте автоматическое продление только потому, что агент отправляет больше вызовов инструментов ближе к крайнему сроку. Такая схема вознаграждает занятый процесс дополнительными полномочиями. Пусть человек принимает новое решение, а если работа изменилась, обновляет и ее цель.

Запись разрешения предотвращает расплывчатые согласования

Структурированная запись разрешения превращает согласование в объект, который может применить система и проверить инженер. Она также показывает пропущенные решения до того, как агент коснется продакшена.

Следующий пример намеренно прост. Это формат записи, а не язык политик. Его поля не дают запуску агента унаследовать расплывчатое разрешение, пригодное для повторного использования.

grant_id: grant_01JQ7P8V6R
agent_run_id: run_7f3a2c
purpose: "INC-482: inspect checkout worker failures"
owner: "on-call engineer"
created_at: "2025-04-18T16:00:00Z"
ends_at: "2025-04-18T16:30:00Z"
ends_on_task_close: "INC-482"
targets:
  - "https://ops.example.internal/checkout/status"
  - "ssh://checkout-worker-03.internal"
allowed_actions:
  - "GET /checkout/status"
  - "journalctl -u checkout-worker --since 20m"
closure_required: true
verification_action: "GET /checkout/status"

В записи не сказано «доступ к продакшену: да». Такое поле скрывало бы важные решения. В ней указано, кто отвечает за решение, какому запуску выдан доступ и какой запрос подтвердит, что разрешение исчезло.

Область действия должна быть достаточно понятной, чтобы согласующий мог ее отклонить. Огромный список путей с подстановочными знаками заставляет людей автоматически одобрять доступ: под давлением его невозможно понять. Если агенту нужны двадцать несвязанных объектов, разделите работу на отдельные разрешения или признайте, что цель слишком широка.

Не помещайте секрет в эту запись. Достаточно идентификатора разрешения и описания цели. Исполнитель может получить защищенные учетные данные после проверки разрешения. Такая архитектура позволяет хранить полезные аудиторские данные, не сохраняя материал, из которого можно восстановить доступ к продакшену.

Запись должна переживать перезапуск и быть доступной только для добавления с точки зрения человека, запускающего агента. Если агент может изменить ends_at, поменять цели или стереть сигнал закрытия, вы передали решение о безопасности процессу, который собирались ограничить.

Отдельно определите поведение операций, уже находящихся в работе. Запрос журнала может завершиться после окончания срока с небольшим риском. Развертыванию, миграции или перезапуску могут понадобиться правило отмены, граница транзакции или процедура передачи человеку. Хуже всего оставить это неопределенным и выяснять поведение во время восстановления.

Докажите истечение срока отрицательным запросом

Доказать прекращение доступа можно запросом, который теперь должен завершиться ошибкой через тот же путь, которым пользовался агент. Закрытая задача, истекший пропуск в административной консоли и отозванная строка в базе данных служат дополнительными свидетельствами. Доказательством они не являются.

Запланируйте проверку сразу после того, что наступит раньше: закрытия задачи или истечения срока. Используйте безвредную точку, которая все еще требует разрешения, например запрос статуса сервиса. Не проверяйте общедоступную проверку состояния: она будет успешной независимо от того, прекращен доступ или нет.

Простая последовательность выглядит так:

# Этот вызов был успешным, пока разрешение действовало.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

# После закрытия задачи повторяем ту же защищенную операцию.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

Вторая команда должна дать результат примерно такого вида:

request_id=req_92a1
status=403
reason=grant_ended
ended_at=2025-04-18T16:12:09Z

Ваша реализация может вернуть 401, 403 или отказ в соединении. Выберите одно значение, определите его смысл и задокументируйте. В аудиторской записи должно быть указано, что слой доступа отклонил запрос из-за завершения разрешения, а не потому, что не сработал DNS или целевой сервис оказался недоступен.

Проверяйте пути, о которых часто забывают. Если агент может использовать и HTTPS, и SSH, проверьте оба. Если сервис выдает cookie после обмена через API, убедитесь, что cookie не живет дольше разрешения. Если рабочий процесс ставит действия в локальную очередь, проверьте авторизацию в момент отправки действия исполнителем, а не только при принятии задания.

До того как полагаться на архитектуру в продакшене, запускайте плановую проверку истечения в непроизводственной среде. Создайте разрешение с очень коротким сроком, выполните один разрешенный запрос, дождитесь истечения и повторите тот же запрос. Затем досрочно отзовите второе активное разрешение и повторите проверку. Эти тесты выявляют разные дефекты: неправильную работу с часами и сломанный досрочный отзыв.

Синхронизация времени требует отдельного внимания. Компонент, который проверяет крайний срок, должен использовать доверенные системные часы и записывать время проверки. Если ноутбук может перевести часы назад и тем самым продлить доступ, срок нельзя считать обеспеченным. Центральный брокер снижает риск, потому что решение принимает один постоянно работающий компонент, но его источник времени все равно нужно контролировать.

Процессы агентов требуют собственной границы

Задача может продолжаться через повторы, терминалы и новые ходы модели, но процесс агента остается практичной единицей контроля доступа. Выдача полномочий на отдельный запуск дает понятное место для запроса согласования, наблюдения за поведением и немедленного отзыва.

Не смешивайте разговор с процессом. Пользователь может сказать агенту «продолжай исследование» после перезапуска модели или после того, как инструмент запустил дочерний процесс. Если доступ следует за разговором без нового события авторизации, оператор перестает понимать, какой исполняемый файл владеет разрешением.

Записывайте идентичность процесса, инициировавшего запуск. На macOS полномочия подписи кода дают согласующему больше полезной информации, чем имя процесса, сообщенное пользователем. Имя agent почти ничего не говорит. Зафиксированные идентичность подписи, путь к исполняемому файлу, родительский процесс и время запуска делают последующую проверку возможной.

Sallyport по умолчанию запрашивает согласование сессии для нового процесса агента, а в карточке согласования на первом месте показывает полномочия подписи кода процесса. Это разумная граница процесса, но согласование сессии все равно должно находиться внутри разрешения на задачу с заданным сроком.

Отзывайте доступ или завершайте его при обычном выходе процесса, но никогда не полагайтесь только на выход. Процессы аварийно завершаются, компьютеры переходят в режим сна, а связи между родительскими и дочерними процессами становятся сложными. Жесткий срок и событие закрытия задачи остаются резервными механизмами. Если процесс пережил закрытие задачи, путь запроса должен отклонять его еще до того, как операционная система очистит процесс.

Отделяйте доступ человека к терминалу от доступа агента. Соблазнительно позволить агенту унаследовать аутентифицированную оболочку оператора: настройка становится проще. Но атрибуция теряет смысл, а агент может получить все права, которые оператор накопил за день. Выдайте агенту отдельную идентичность и заставьте его обращаться через собственный путь.

Запросы согласования не отменяют необходимость области действия

Человек, который нажимает «разрешить», может заметить явно неправильный запрос, но согласования слабеют, когда приходят слишком часто или содержат слишком мало информации. Запрос с текстом «разрешить вызов API» заставляет человека угадывать последствия.

Покажите согласующему цель, объект, метод или команду, срок разрешения и идентичность агента. Если система не может объяснить запрос в этих терминах, она собрала недостаточно данных для ответственного согласования.

Согласование каждого вызова уместно для необратимых операций: удаления данных, замены учетных данных, запуска платежей или развертывания непроверенного изменения. Оно не должно стать обычным контролем для каждого чтения журнала. Люди подтверждают повторяющиеся запросы автоматически, особенно во время инцидента.

Для вызова с флагом согласования каждого использования Sallyport запрашивает подтверждение при каждом обращении, но эта настройка должна дополнять срок, а не заменять его. Человек может одобрить правильный запрос в 16:29, но после окончания разрешения путь доступа все равно должен отклонять последующие запросы.

Сохраните быстрый аварийный стоп, для которого не нужно искать первоначального согласующего. Дежурному инженеру нужен способ завершить запуск, если агент зациклился, неверно прочитал вывод или начал обращаться не к тому объекту. Записывайте, кто использовал остановку и почему. Аварийный контроль без ответственности может превратиться в еще один непроверенный путь доступа.

Аудит должен отвечать на неудобные вопросы

После события в продакшене люди спрашивают, когда начался доступ, кто его разрешил, какой процесс им пользовался, какие запросы были успешными и действительно ли доступ прекратился. Журналы, где записаны только успехи, не отвечают на последний вопрос.

Записывайте и отклоненные вызовы, особенно после истечения срока или отзыва. Отказ доказывает, что точка применения политики получила запрос и применила границу. Он может показать, что застрявший агент продолжает попытки после закрытия задачи. Это требует внимания, даже если контроль сработал.

Связывайте решение о разрешении с отдельными действиями через идентификаторы. Проверяющий должен иметь возможность перейти от grant_01JQ7P8V6R к согласующему владельцу, связанной задаче, идентичности запуска, разрешенной области, источнику закрытия и каждому запросу. Если эти записи находятся в разных системах без общего идентификатора, восстановление событий превращается в догадки.

Важна защита от незаметного изменения. Записи доступа часто становятся важными после того, как у кого-то появляется причина их редактировать. Sallyport формирует журналы сессий и действий из зашифрованного аудита с цепочкой хешей, а sp audit verify может автономно проверять эту цепочку поверх шифротекста. Это свойство не решает, был ли запрос уместным, но усложняет сокрытие незаметного изменения последовательности.

Не собирайте каждую подсказку и каждую мысль модели вместо журналов действий. Такие записи создают проблемы с конфиденциальностью и сроками хранения, но все равно могут не показать настоящий сетевой запрос. Начните с решения об авторизации и результата действия. Контекст подсказки добавляйте только тогда, когда это оправдано вашими эксплуатационными правилами и правилами конфиденциальности.

Дайте проверяющим фиксированную запись закрытия. В ней должны быть идентификатор разрешения, фактическое время окончания, источник завершения, число успешных действий, число отклоненных действий после окончания и результат проверочного запроса. Такая запись превращает расплывчатое утверждение «доступ удален» в факт, который может оспорить проверяющий изменение.

Постройте контроль как небольшую проверяемую последовательность

Для временного доступа не нужен универсальный движок политик. Нужен узкий механизм, через который проходит каждое действие агента, и путь отказа, который можно протестировать.

Начните с перечня действий, которые агенты сейчас выполняют в продакшене. Разделите операции чтения, обратимые изменения и действия, способные вызвать необратимые или масштабные последствия. Для каждого действия определите фактического владельца учетных данных и точку применения политики. Это упражнение часто обнаруживает учетные данные в переменных окружения, профилях оболочки, журналах CI или скопированных конфигурационных файлах.

Затем соберите минимальный жизненный цикл:

1. Создайте отдельную идентичность запуска и структурированное разрешение с целью и жестким сроком.
2. Направляйте каждый защищенный HTTP- или SSH-вызов через исполнителя, который проверяет разрешение перед использованием.
3. Принимайте ранний сигнал закрытия или отзыва и записывайте фактическое время его применения.
4. После завершения отправляйте безвредный защищенный запрос и сохраняйте результат отказа.
5. Регулярно проверяйте истекшие и отозванные разрешения на наличие попыток, продолжавшихся после окончания доступа.

Не начинайте со сложных правил, классифицирующих каждую возможную команду. Команды тратят недели на обсуждение синтаксиса, пока агенты все еще держат долгоживущие учетные данные. Начните с названных целей, коротких сроков, идентичности на отдельный запуск и доказательства отказа. Добавляйте более точные ограничения там, где история действий показывает, что действительно запрашиваются широкие области.

Критерий качества прост и строг: после закрытия задачи старый процесс агента должен получить отказ на границе продакшена, а вы должны уметь показать причину отказа. Пока такую проверку нельзя выполнить, доступ временный только на бумаге.