Секреты на сервере: чек-лист для systemd-сервисов

Пароль базы данных может не попасть в Git и всё равно оказаться в логах, дампе процесса или резервной копии. Ниже — практический чек-лист для сервисов на Linux с systemd 252, в частности Debian 12: сравним способы передачи секретов, настроим выдачу через systemd credentials и проверим, что не осталось лишних копий.

Сначала найдите все копии секрета

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

• Поиск по репозиториям и истории коммитов. Если секрет когда-либо попал в Git, считайте его скомпрометированным: удаление строки из последнего коммита не удаляет её из истории.
• Проверка unit-файлов, drop-in-конфигураций и файлов окружения. Посмотрите, не записан ли секрет прямо в параметре ExecStart или в переменной Environment.
• Проверка журналов приложения и CI/CD. Не выводит ли программа конфигурацию целиком при старте или ошибке подключения?
• Проверка резервных копий и снимков диска. Уточните, кто имеет к ним доступ и как долго они хранятся.

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

Выберите способ передачи секретов

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

Переменная окружения — не гарантированная утечка: доступ зависит от прав пользователя, настроек системы и способа запуска. Но это не повод считать её хранилищем секретов. Проверьте, не попадает ли окружение в диагностику, дампы и логи.

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

Настройте выдачу через systemd credentials

В примере используется Debian 12 с systemd 252. Секрет хранится в отдельном файле, а unit передаёт его сервису как credential с именем db-password. Приложение должно уметь читать файл, путь к которому systemd передаёт через $CREDENTIALS_DIRECTORY. Синтаксис проверьте по документации именно установленной версии systemd.

1. Создайте файл секрета. Используйте отдельный файл вне каталога приложения и репозитория. Ограничьте права доступа: читать его должны только root и необходимые администраторы. Проверьте владельца и права через stat; не оставляйте файл доступным всем пользователям.
2. Добавьте credential в unit. Создайте drop-in для сервиса через systemctl edit имя-сервиса и добавьте строку в секцию [Service]: LoadCredential=db-password:/etc/myapp/db-password. Не вставляйте значение пароля в unit.
3. Научите приложение читать credential. Настройте его на чтение файла db-password в каталоге, указанном переменной CREDENTIALS_DIRECTORY. Не выводите содержимое файла в лог; конкретную настройку ищите в документации приложения.
4. Перечитайте конфигурацию и перезапустите сервис. Выполните systemctl daemon-reload, затем systemctl restart имя-сервиса. Проверка: systemctl status имя-сервиса показывает активный сервис, а приложение подключается к базе без ошибки авторизации.
5. Проверьте отказной сценарий. На тестовом стенде временно укажите неверный секрет или недоступный файл. Убедитесь, что сервис не пишет пароль в журнал и ошибка остаётся диагностируемой. После проверки верните рабочее значение.

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

Чек-лист перед запуском в прод

• У каждого секрета есть владелец: человек или команда, отвечающие за ротацию и отзыв.
• Для разных сервисов и окружений используются разные учётные данные. Тестовый пароль не даёт доступ к production.
• Файл секрета не лежит в репозитории, каталоге сайта или образе контейнера и не включён в бэкап без необходимости.
• Права доступа проверены на сервере, а доступ к резервным копиям ограничен отдельно.
• Пароли и токены не появляются в журналах, сообщениях об ошибках, параметрах командной строки и отчётах CI/CD.
• Ротацию можно провести без ручного поиска значения по всем серверам. После замены старый ключ отзывается.
• Процесс запуска сервиса проверен после перезагрузки сервера, а не только после ручного старта.

Что ломается и как выбрать подход

Если приложению нужны переменные окружения

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

Если сервис не запускается

Проверьте синтаксис unit, существование исходного файла и права доступа к нему. Затем изучите журнал конкретного сервиса через journalctl, не публикуя строки, которые могут содержать секрет. Для systemd важны версия системы и фактическая конфигурация: не переносите директиву из примера для новой версии на старый сервер без проверки.

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

Термин: credential

Credential — учётные данные или секрет, которые процесс использует для доступа к ресурсу: например, пароль базы, токен API или сертификат. В systemd credentials — механизм передачи таких данных конкретному сервису; он не превращает исходный файл в защищённое хранилище и сам по себе не решает вопрос шифрования на диске.

Что делать дальше

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