Эфемерные учётные данные

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

Почему это важно

Долгоживущие учётные данные накапливают проблемы линейно во времени: круг лиц, которые их видели, места, куда их скопировали, попытки подбора, объём использования в рамках криптографических ограничений. Эфемерные учётные данные постоянно сбрасывают этот таймер. Утечка часового токена к моменту, когда её вообще заметят, обычно уже ни на что не влияет. (Полный каталог сценариев сбоев описан в long-lived-keys.)

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

Как это устроено

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

OIDC federation. Нагрузка предъявляет серверу ресурсов подписанное подтверждение подлинности (assertion от GitHub Actions, AWS IAM или IdP), а сервер в обмен выпускает короткоживущий токен доступа. Якорем доверия служит ключ подписи OIDC-эмитента - один надёжно контролируемый долгоживущий ключ на эмитента вместо отдельного ключа на каждого пользователя или нагрузку.
Just-in-time provisioning. Бастион или control plane проверяет, разрешён ли заявителю доступ прямо сейчас (через SSO, MFA или систему тикетов), и выпускает учётные данные на одну сессию. По такой схеме работают AWS EC2 Instance Connect и центры сертификации SSH (SSH CA).
Signed assertions. SSO заменяет отдельные пароли для каждого приложения подписанными подтверждениями от IdP при каждом входе. У пользователя нет долгоживущего секрета в самом приложении - приложение просто доверяет подписи IdP.

Примеры на практике

EC2 Instance Connect - заменяет постоянные SSH-ключи учётными данными на одну сессию, которые выпускаются после свежей проверки прав.
PyPI / crates.io / NPM Trusted Publishers - конкретный workflow в GitHub Actions обменивает свой OIDC-токен на короткоживущие права для публикации. Никаких сохранённых токенов реестра. Пайплайн релизов Astral построен именно на этом; см. open-source-security-astral.
SSO assertions (SAML, OIDC) - подписанные подтверждения при каждом входе вместо постоянных паролей для каждого приложения.
AWS STS / GCP service-account impersonation - рабочие нагрузки запрашивают роль (assume role) и получают учётные данные на время сессии вместо хранения статического ключа.
SSH certificate authorities - короткоживущие SSH-сертификаты, которые CA выпускает после аутентификации, вместо постоянных записей в authorized_keys.

Ограничения

Якорь доверия остаётся долгоживущим. Ключ подписи IdP, ключ SSH CA, ключ OIDC-эмитента - компрометация любого из них катастрофична. Выигрыш достигается за счёт концентрации: один или несколько тщательно охраняемых ключей вместо N долгоживущих ключей, разбросанных по командам. Практики управления такими остаточными ключами описаны в long-lived-keys (жёсткое ограничение прав, математические лимиты срока жизни, ежеквартальная ротация, назначенные владельцы).

См. также

long-lived-keys - аргументы в пользу такого перехода
supply-chain-security - типичный контекст, где сохранение токенов реестров оказывается неверным решением
jwt-for-sessions / paseto - короткоживущие bearer-токены: близкий, но другой сценарий использования