Сообщить об ошибкеКороткий ответ
Ротация секретов ограничивает «окно жизни» значения, которое могло быть скомпрометировано незаметно (через утечку лога, старый бэкап, уволенного сотрудника с доступом), и уменьшает ущерб даже без явных признаков взлома.
Как это работает подробнее
любой секрет мог попасть к третьим лицам способами, которые сложно обнаружить сразу — через случайно сохранённый лог, доступ бывшего сотрудника, устаревший бэкап конфигурации. Регулярная ротация означает, что даже незамеченная утечка старого значения со временем станет бесполезной для атакующего.
Пример кода
security-example-451.sh
# Пример проверки возраста статического доступа в AWS IAM
aws iam list-access-keys --user-name svc-billing
{
"AccessKeyMetadata": [
{"AccessKeyId": "AKIAEXAMPLE1", "Status": "Active", "CreateDate": "2023-01-10"}
]
}Что использовать на практике
- Практика. ротацию настраивают автоматически там, где возможно (динамические секреты Vault, временные IAM-креды с TTL, автоматическая смена паролей БД), а не вручную по напоминанию в календаре; критичные секреты (ключи шифрования, root-пароли) ротируют чаще и обязательно после увольнения сотрудника с доступом к ним.
- Проверка. Ожидаемое поведение: ключ создан более года назад и не ротировался — политика безопасности (например, AWS Config rule access-keys-rotated) должна пометить такой ключ как несоответствующий требованиям и инициировать создание нового ключа с последующей деактивацией старого.
Подводные камни
- Ошибка. использовать один и тот же пароль администратора годами «потому что всё работает»; ротировать секрет в хранилище, но забывать обновить его во всех местах использования (приложение продолжает работать со старым кэшированным значением до перезапуска); не иметь процесса ротации вообще, что особенно опасно для долгоживущих статических ключей доступа к облаку.