Рабочий лист для учета учетных данных AI-агентов для программирования

AI-агентам для программирования нельзя выдавать набор унаследованных учетных данных и расплывчатую просьбу быть осторожнее. Прежде чем агент вызовет API, развернет сервис или откроет SSH-соединение, кто-то должен зафиксировать, к чему ведут эти учетные данные, кто отвечает за такой доступ и как команда его отключит.

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

Реестр должен описывать полномочия, а не строки секретов

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

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

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

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

NIST SP 800-57 Part 1 рассматривает управление криптографическими ключами как жизненный цикл: генерация, распространение, хранение, использование, замена и уничтожение требуют контроля. Документ посвящен криптографическим ключам, но его принципы напрямую применимы и здесь. Список, который заканчивается на фразе «мы создали токен», не является реестром. Это подсказка для памяти, которая подводит именно тогда, когда сотрудникам нужны надежные записи.

У каждой учетной записи должен быть ответственный владелец

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

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

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

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

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

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

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

Записывайте разрешенные действия как глаголы и цели

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

Записывайте разрешения в таком виде:

глагол + цель + граница + запрещенное действие

Например:

• GET /v1/projects/acme/builds в стейджинге; запросы к продакшен-тенантам запрещены
• Создавать ревизии развертывания для сервиса catalog-api; откат и удаление запрещены
• SSH под учетной записью deploy в группу хостов сборки; выполнять только утвержденную команду выпуска; интерактивная оболочка запрещена
• Создавать комментарии к задачам в репозитории alpha; слияние, удаление веток и изменение настроек запрещены

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

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

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

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

Для разных сред нужны отдельные строки и разные последствия

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

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

Рабочее поле среды может выглядеть так:

продакшен / тенант 4821 / данные аккаунта клиента / конечная точка api.example.internal

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

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

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

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

SSH-доступ требует больше деталей, чем API-доступ

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

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

Выполните эту команду для файла открытого ключа:

ssh-keygen -lf ~/.ssh/id_agent_deploy.pub

Обычный результат выглядит так:

256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd agent-deploy (ED25519)

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

Для целевых хостов проверяйте ограничения в authorized_keys, а не считайте, что учетная запись для развертывания ограничена только потому, что так задумано. OpenSSH описывает в руководстве sshd такие параметры, как command=, no-port-forwarding, no-agent-forwarding и no-pty. Они могут превратить автоматизационную личность в исполнителя ограниченного набора команд. Но они не исправят учетную запись, которая входит в систему как неограниченный администратор.

Запись может выглядеть так: «вход под deploy, хосты из группы выпуска A, принудительная команда /usr/local/bin/release-catalog, перенаправление портов запрещено, PTY запрещен, перенаправление агента запрещено». Если для аварийной работы нужна интерактивная оболочка, создайте отдельную личность для человека. Не переиспользуйте личность агента только потому, что она уже доступна.

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

Полезный реестр заставляет отвечать на сложные вопросы

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

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

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

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

План ротации должен включать замену и подтверждение результата

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

План ротации должен содержать пять операционных фактов:

1. Событие, которое запускает ротацию: плановое истечение срока, уход сотрудника, подозрение на раскрытие или изменение области доступа.
2. Человек, создающий замену, и человек, утверждающий изменившиеся полномочия.
3. Место, где хранится новый материал, не попадая к агенту.
4. Узкое тестовое действие, подтверждающее работоспособность замены.
5. Точный момент отзыва старого материала и сохранения подтверждения.

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

Запись о тесте может быть такой:

Credential ID: api-catalog-deploy-prod-01
Replacement ID suffix: ...7KQ2
Test: POST /deployments/validate for catalog-api revision 8f3c
Expected: HTTP 200 with validation status accepted
Old credential revoked: provider audit event recorded
Reviewer: production service owner

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

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

Подтверждение действий агента должно зависеть от их последствий

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

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

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

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

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

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

Аудит помогает разобраться после неудачного запуска

Реестр предотвращает проблемы. Аудит отвечает на другой вопрос после неожиданного поведения агента: что он действительно пытался сделать, что получилось и какие полномочия это позволили? Не объединяйте эти задачи. Тщательно поддерживаемая таблица не доказывает, что вызов состоялся, а журнал не доказывает, что разрешение было оправданным.

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

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

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

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