Вам не нужны долгоживущие ключи

Келби Людвиг (Kelby Ludwig, инженер по безопасности в Argemma) утверждает, что долгоживущие криптографические ключи - это риски, которые со временем только накапливаются. Правильный шаг обычно заключается в том, чтобы заменить их временными учётными данными (ephemeral credentials), а не пытаться бесконечно оттачивать процесс их ротации. Если же ротация неизбежна, стоит поручить эту задачу отдельной выделенной команде, а не распределять рутину между всеми инженерами продукта.

Почему долгоживущие ключи увеличивают риски со временем

Риск возрастает со временем под действием трёх независимых факторов:

Люди увольняются. Сотрудники приходят и уходят, а круг людей, потенциально знающих ключ, только расширяется. Забыть ключ по заказу невозможно.
Подбор становится дешевле. Если попытки не прекращаются, совокупная вероятность успешного угадывания с каждым днём растёт.
Криптографический износ. У симметричных примитивов есть ограничения на количество сообщений. Примерно после 2^32 сообщений на одном ключе AES-GCM атаки с подделкой сообщений становятся вполне реальными. Чем дольше живёт ключ, тем больше операций он успевает выполнить.

Почему ротация даётся с трудом

Большинство инженеров сталкивалось хотя бы с одной из этих проблем:

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

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

Временные учётные данные обходят большинство этих проблем

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

Доступ по SSH через EC2 Instance Connect. Вместо статичных пар ключей, скопированных в конфиг и забытых, каждая сессия требует новой проверки аутентификации и авторизации, которая выпускает короткоживущие учётные данные.
Публикация пакетов через Trusted Publishers. Статичный токен PyPI имеет свойство расползаться: сначала в личный 1Password CTO, затем в полузабытые пайплайны релизов. Trusted Publishers позволяет конкретному workflow в GitHub Actions получать временные учётные данные на каждый релиз через OIDC. Утекать здесь просто некому. (См. пример реализации от Astral в open-source-security-astral.)
Аутентификация пользователей через SSO. Долгоживущий пароль, заданный пользователем для каждого приложения, заменяется подписанным короткоживущим assertion'ом от IdP. Злоумышленники могут подобрать слабый пароль, но подобрать подписанный XML-документ им не под силу. Людвиг признаёт, что это по-прежнему опирается на долгоживущий ключ подписи самого IdP - именно об этом следующий раздел.

Когда избавиться от долгоживущего ключа нельзя

От некоторых ключей избавиться невозможно: это ключ подписи IdP, корневые ключи KMS, мастер-ключи шифрования неактивных данных (encryption-at-rest). Но сокращение их количества полезно, даже если свести его к нулю не получается:

Фокус усилий. Анализировать безопасность одного instance'а EC2, чья единственная задача - обращаться к KMS, гораздо проще, чем проверять ноутбук каждого инженера. Меньше долгоживущих ключей - меньше компонентов инфраструктуры, требующих предельно строгого контроля.
Сфокусированная строгость. Лимиты на использование криптографических ключей, расчёт времени их жизни, runbook'и ротации - всё это должно быть чьей-то основной работой. Если для продуктовой команды это второстепенная задача, про неё забывают или делают её с ошибками. Пусть одна команда решит эту задачу один раз для всех.

Чеклист Людвига для оставшихся долгоживущих ключей:

Область действия (Scope). Ограничивайте возможности каждого ключа. Ключ шифрования, привязанный к одному шарду пользовательских данных, принесёт злоумышленнику гораздо меньше пользы, чем глобальный.
Математически обоснованные границы срока службы. Выбирайте максимальное время жизни с тем же уровнем уверенности, с каким утверждают, что "суперкомпьютеру на подбор понадобятся миллиарды лет", а не по наитию.
Ротация как минимум раз в квартал. Относитесь к этому как к тренировке. Регулярная ротация держит инструментарий и документацию в актуальном состоянии.
Концентрируйте рутину. Не размазывайте её по всем. Небольшая команда, которая отвечает за процесс и заинтересована в его строгом соблюдении, справится лучше, чем если бы каждая продуктовая команда пыталась делать это самостоятельно.

Связи

ephemeral-credentials - базовая концепция, в пользу которой приводит доводы эта статья
supply-chain-security - долгоживущие токены реестров пакетов выступают здесь одним из главных источников проблем
jwt-for-sessions - смежный аргумент о несоответствии сроков жизни (долгоживущие сессии в формате токенов, изначально рассчитанном на короткий срок)
crqc / post-quantum-cryptography - другой взгляд на ту же тему: сегодняшние долгоживущие ключи могут не выдержать модели угроз завтрашнего дня