Смена паролей на сервере по расписанию: как не устроить себе аврал

MAATRIX

Раз в квартал (или когда кто-то вспоминает про регламент) в компании объявляют: «сегодня меняем все пароли». Дальше — паника: кто-то судорожно ищет, где вообще используется пароль от базы, кто-то меняет ключ API и роняет интеграцию с платёжным шлюзом, а к вечеру половина сервисов не отвечает, потому что новый пароль обновили не везде. Плановая смена секретов не обязана быть авралом — она становится им только тогда, когда у неё нет расписания, инвентаризации и процедуры проверки. Разберём, как построить смену паролей и других секретов так, чтобы это была рутинная задача по чек-листу, а не спецоперация раз в год.

Почему смена «по команде сверху» превращается в аврал

Типичный сценарий: приходит требование (внутренний аудит, требование клиента, просто чьё-то беспокойство) — сменить все пароли. Проблема не в самой смене, а в том, что она происходит без подготовки:

• нет списка секретов. Никто точно не знает, сколько паролей, токенов и ключей вообще есть в инфраструктуре — часть заведена вручную, часть сгенерирована при установке сервиса и забыта;
• нет карты зависимостей. Пароль от базы данных используется в бэкенде, в скрипте бэкапа, в дашборде мониторинга и в ETL-джобе — и если вы вспомните только про первые два места, третье и четвёртое отвалятся тихо, без явной ошибки, а заметите вы это через день по пропавшим данным в отчёте;
• новый пароль рассылается вручную. В чат, на почту, голосом — и часть получателей его теряет, часть применяет с опечаткой, а сам факт рассылки пароля открытым текстом создаёт отдельную дыру;
• никто не проверяет результат. Пароль поменяли, отчитались — а то, что сервис, который забыли обновить, всю ночь падает с ошибкой авторизации, выясняется утром по звонку от клиента.

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

График по категориям секретов: не всё нужно менять одинаково часто

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

Такой график — не догма, а стартовая точка: конкретные интервалы стоит подстроить под то, как секрет реально используется и что говорит про него поставщик сервиса. Главное — зафиксировать график письменно (таблица в вики или трекере задач с датой следующей ротации по каждой категории) и не полагаться на память. Без письменного графика ротация происходит либо никогда, либо по панике — оба варианта хуже плановой смены раз в оговорённый срок.

Инвентаризация: где используется секрет, прежде чем его менять

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

Практический подход к инвентаризации:

1. Заведите карточку на каждый значимый секрет — не обязательно в сложной системе, подойдёт и таблица: название секрета, где хранится (менеджер секретов, конкретный путь), кто владелец, где используется (список сервисов/скриптов/интеграций), дата последней смены, дата следующей.
2. Ищите использование прямым поиском по инфраструктуре, не полагаясь только на память:

# ищем упоминания пароля/строки подключения в конфигах и переменных окружения
grep -rl "DB_PASSWORD" /etc /opt /srv --include="*.env" --include="*.yml" --include="*.conf" 2>/dev/null

# ищем, какие systemd-юниты используют конкретный env-файл
grep -l "EnvironmentFile=.*app.env" /etc/systemd/system/*.service

# смотрим, где секрет закреплён в docker compose / kubernetes manifest
grep -rn "DATABASE_PASSWORD" /opt/*/docker-compose.yml

1. Проверьте cron и systemd timers — скрипты бэкапа, мониторинга и синхронизации часто используют пароль отдельно от основного приложения и остаются вне поля зрения при смене:

crontab -l -u backup
systemctl list-timers --all

1. Проверьте внешние интеграции — вебхуки, партнёрские API, dashboard-сервисы (Grafana datasource, BI-инструмент), которые подключаются к базе или API напрямую, а не через приложение.
2. Зафиксируйте найденное в карточке секрета — этот список мест и есть чек-лист, по которому вы будете обновлять пароль при следующей ротации. Один раз потратить час на инвентаризацию дешевле, чем каждый раз заново вспоминать, что забыли.

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

Менеджер секретов вместо рассылки паролей в мессенджере

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

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

• секрет хранится в одном месте — менеджере секретов (класс инструментов вроде HashiCorp Vault для инфраструктурных секретов или Vaultwarden/аналогов для паролей команды), а не в десятке разрозненных файлов и переписок;
• новое значение генерируется и сразу попадает в хранилище, минуя человека как промежуточное звено передачи:

# пример генерации случайного пароля и записи в секрет-хранилище
NEW_PASS=$(openssl rand -base64 24)
vault kv put secret/db/production password="$NEW_PASS"

• сервисы читают секрет из хранилища при старте или через API, а не хранят его захардкоженным в конфиге — тогда обновление секрета в одном месте автоматически подхватывается всеми потребителями при перезапуске;
• у людей нет причин знать пароль в лицо — они получают доступ через менеджер секретов со своими правами, а не через передачу самого значения. Это заодно снимает вопрос «а у скольких людей есть этот пароль на бумажке или в заметках телефона»;
• ведётся журнал обращений — кто и когда читал секрет, что полезно и для расследования инцидента, и просто для понимания, какие сервисы вообще этот секрет используют (сверка с вашей инвентаризацией).

Если у вас пока нет менеджера секретов и всё держится на .env-файлах — не обязательно сразу разворачивать тяжёлую систему. Для команды из нескольких человек может хватить менеджера паролей с общими хранилищами и API-доступом; для секретов приложений — что-то в духе Vault. Подробный разбор, как поставить и настроить такую систему, — в статье про HashiCorp Vault и управление секретами. Главное — переход от «пароль знают люди» к «пароль знает система, а у людей есть права на неё».

Процедура плановой ротации: пошагово

Когда график определён и инвентаризация сделана, сама смена одного секрета укладывается в предсказуемую последовательность шагов:

1. Проверьте карточку секрета — актуален ли список мест использования, не добавился ли новый сервис с момента последней ротации.
2. Сгенерируйте новое значение и запишите его в менеджер секретов под новой версией (не затирая старую сразу — многие менеджеры секретов хранят версии, это удобно для отката).
3. Обновите секрет во всех местах из инвентаризации, начиная с тех, что легче протестировать изолированно:

# смена пароля пользователя PostgreSQL
sudo -u postgres psql -c "ALTER USER app_user WITH PASSWORD 'НОВЫЙ_ПАРОЛЬ';"

# обновление .env и перезапуск сервиса, который читает его при старте
sed -i 's/^DB_PASSWORD=.*/DB_PASSWORD=НОВЫЙ_ПАРОЛЬ/' /opt/app/.env
systemctl restart app.service

1. Не отзывайте старое значение сразу — там, где это возможно (API-ключи с поддержкой нескольких активных токенов, пользователи БД с параллельным доступом), оставьте старый секрет действующим на короткий переходный период. Это даёт запас времени, если какое-то место использования всё же не попало в инвентаризацию, — сервис не упадёт мгновенно, а продолжит работать на старом значении, пока вы не найдёте и не обновите пропущенное место.
2. Пройдите весь список мест использования и отметьте каждое как обновлённое — буквально вычёркивайте пункты в карточке секрета, чтобы не полагаться на память в процессе.
3. Только после проверки (следующий раздел) отзовите старое значение — удалите старого пользователя БД, деактивируйте старый API-ключ, уберите старый SSH-ключ из authorized_keys.

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

Тестирование после смены — до того, как объявить готово

Смена пароля без проверки — это не завершённая ротация, а просто повышенный риск в моменте: вы не знаете, всё ли работает, пока не проверили. Минимальный набор проверок перед тем, как закрыть задачу:

• Функциональная проверка сервиса, который использует секрет напрямую — не просто «процесс запустился», а реальный запрос, использующий обновлённое подключение:

# проверка подключения к БД с новым паролем от имени приложения
PGPASSWORD='НОВЫЙ_ПАРОЛЬ' psql -h localhost -U app_user -d app_db -c "SELECT 1;"

• Проверка логов на ошибки авторизации сразу после перезапуска — именно здесь чаще всего всплывает забытое место использования:

journalctl -u app.service --since "10 minutes ago" | grep -iE "auth|password|denied|401|403"

• Проверка смежных интеграций из инвентаризации — если в карточке секрета был отмечен, скажем, дашборд Grafana с прямым подключением к базе, зайдите и убедитесь, что данные на нём обновляются, а не «зависли» на последнем успешном опросе до смены пароля.
• Мониторинг метрик ошибок какое-то время после смены, а не только в момент проверки — часть интеграций (например, cron-задачи раз в сутки) сработает не сразу, и если вы отозвали старый секрет слишком быстро, ошибка проявится только на следующем запуске.
• План отката под рукой — пока старое значение ещё активно (см. предыдущий раздел), откат — это просто вернуть сервису старую конфигурацию, а не экстренно генерировать секрет заново под давлением.

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

Частые вопросы