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

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

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

Я видел, как команды объявляли ротацию завершенной, потому что новое значение появилось в менеджере секретов. Затем выяснялось, что старый ключ развертывания остался в файле authorized keys учетной записи или забытая локальная переменная окружения продолжала хранить просроченный API-токен. Ротация завершена только тогда, когда новая учетная запись доказала работоспособность нужного пути действий, а старая идентичность больше не может пройти аутентификацию.

Ротация меняет идентичность, а не заменяет строку

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

В заметках и инструментах разделяйте четыре понятия:

• Внешняя идентичность: API-токен, секрет клиента, пара SSH-ключей или учетные данные сервисной учетной записи, которые принимает провайдер.
• Запись учетных данных: зашифрованная запись, где хранится идентичность и сведения о ее использовании.
• Цель авторизации: учетная запись API, репозиторий, машинная учетная запись, хост или сетевой endpoint, который ее принимает.
• Сеанс агента: конкретный процесс, запросивший действие.

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

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

NIST Special Publication 800-57, Part 1 рассматривает криптопериоды как нечто большее, чем напоминания в календаре. В документе криптопериод связывается с раскрытием, использованием и риском компрометации. Такой подход подходит и для API- и SSH-учетных данных. Токен с широким доступом на запись, частым использованием или неясным владельцем должен иметь более короткий плановый срок жизни, чем идентичность с узкой областью доступа для одной задачи только на чтение. Не превращайте это в ритуал, при котором строки меняются каждую пятницу, а избыточные права сохраняются.

Четкая формулировка ротации должна выглядеть так: «Сеанс агента сборки использовал запись учетных данных deploy-api-prod для этого запроса. Запись изменилась с идентификатора токена провайдера, заканчивающегося на 4K2, на идентификатор, заканчивающийся на P9M. Старый токен отозвали после того, как новая запись выполнила ожидаемое действие». Сам токен в эту запись не попадает.

Соберите секрет в одном месте до наступления срока действия

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

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

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

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

{
  "credential": "deploy-api-prod",
  "method": "POST",
  "url": "https://api.example.internal/releases",
  "headers": {"Content-Type": "application/json"},
  "body": {"revision": "a81c2f"}
}

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

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

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

Назначьте каждой учетной записи одного владельца и одну цель

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

Называйте записи так, чтобы оператор мог определить границу авторизации, не видя секрет. billing-write-prod говорит больше, чем token-final-2. github-deploy-repo-a говорит больше, чем automation-key. Добавляйте окружение, если оно влияет на цель, и не встраивайте имя человека, когда учетные данные принадлежат сервисной функции. Люди уходят, а назначение сервиса должно оставаться понятным.

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

1. Вы не понимаете, какая цель вызвала ротацию.
2. Расширение области доступа для одного сценария увеличивает доступ для всех остальных.
3. Отзыв идентичности во время инцидента прерывает несвязанные процессы.

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

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

В руководстве OpenSSH для authorized_keys описаны такие параметры, как command=, restrict и from=. Они полезны только после проверки точного пути команды, который требуется автоматизации. Я видел, как добросовестная запись с restrict ломала перенаправление портов, от которого незаметно зависела задача развертывания. Лучше обнаружить такую ошибку во время плановой ротации, а не в полночь. Не добавляйте вслепую все доступные ограничения. Добавляйте те, которые соответствуют названному действию.

Используйте окно перекрытия с заранее назначенным концом

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

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

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

Назначьте время отзыва старых учетных данных до проверки. Если вы не можете назвать это время, у вас нет окна перекрытия. Вы создали еще одни постоянные учетные данные.

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

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

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

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

Проверяйте путь, которым действительно пользуется агент

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

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

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

curl -sS -D /tmp/headers.txt \\
  -H "Authorization: Bearer $NEW_TOKEN" \\
  https://api.example.internal/v1/whoami

В ожидаемом результате в /tmp/headers.txt часто будет статус 200, а тело укажет сервисную учетную запись. Это говорит о том, что провайдер принимает токен. Но это не доказывает, что шлюз действий добавляет тот же заголовок, выбирает правильную запись или не показывает агенту $NEW_TOKEN. Выполняйте такую проверку только под контролем оператора и удаляйте переменную из оболочки после завершения. Никогда не вставляйте настоящий токен в задачу или сохраненную запись терминала.

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

ssh -o BatchMode=yes -o IdentitiesOnly=yes \\
  [email protected] 'id \u0026\u0026 test -w /srv/releases \u0026\u0026 echo write-ok'

BatchMode=yes заставляет команду завершиться ошибкой аутентификации, а не ждать интерактивный пароль. IdentitiesOnly=yes не дает SSH-клиенту пробовать все несвязанные ключи, загруженные в агент. Успешный вход через ssh deploy@host не доказывает, что работает действие развертывания. Удаленная учетная запись может принимать оболочку, но отклонять команду, каталог или ограничение forced command, которое использует задача.

Руководство OpenSSH для ssh объясняет, что IdentitiesOnly ограничивает список идентичностей, предлагаемых клиентом. Этот параметр выявляет распространенный ложноположительный результат на машинах разработчиков: локальный агент успешно использует личный ключ из агента аутентификации, а новый ключ автоматизации в производственной среде не работает. В архитектуре со шлюзом выполняйте аналогичную проверку через SSH-путь шлюза, где выбранный сохраненный ключ однозначен.

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

Ротация SSH завершается ошибкой на сервере, если старые открытые ключи остаются

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

Инвентаризация SSH сложнее, потому что открытые ключи могут находиться в нескольких местах: ~/.ssh/authorized_keys, сервисе управления идентичностями, метаданных облачного экземпляра, шаблоне системы управления конфигурацией или интерфейсе deploy-key провайдера. Сначала найдите источник истины. Если система управления конфигурацией перезаписывает authorized_keys, ручное удаление в экстренном порядке вернет ключ при следующем запуске.

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

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

ssh-keygen -lf deploy-release-ed25519.pub
# 256 SHA256:exampleFingerprint deploy-release-2025 (ED25519)

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

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

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

Разделяйте авторизацию и ротацию

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

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

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

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

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

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

Свидетельства аудита должны отвечать на два разных вопроса

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

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

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

Здесь полезно разделять журналы сеансов и действий. Журнал сеансов показывает, какой процесс агента получил полномочия и отзывал ли кто-то этот запуск. Журнал действий показывает, какие отдельные HTTP- или SSH-действия выполнялись в его рамках. Если API-токен ротировали в 14:00, можно изучить вызовы, использовавшие запись до и после переключения, не считая каждое одобрение сеанса доказательством каждого запроса.

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

Для ротации высокого риска соберите такие свидетельства в одной компактной записи:

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

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

При подозрении на утечку сначала сдерживайте инцидент, потом выполняйте замену

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

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

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

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

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

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

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

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

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