Как защитить учётные записи Linux, которые запускают сервисы?

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

Как применить принцип наименьших привилегий к секретам?

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

Что делать, если пароль или токен попал в Git или чат?

Сначала определите, какой именно секрет раскрыт, кто им пользуется и какие системы он защищает. Затем создайте новое значение через принятый механизм и сохраните его в управляемом хранилище. Переведите потребителей на новый секрет и подтвердите успешное подключение каждого из них. Только после этого отключите старый токен, ключ, пароль или учётную запись и проверьте, что прежнее значение больше не работает. Удаление строки из репозитория, чата или конфигурации не устраняет риск: значение могло сохраниться в истории Git, локальных клонах, артефактах CI/CD, образах, кэшах, журналах и резервных копиях. Эти места нужно зафиксировать в инвентаризации как возможные копии и ограничить к ним доступ. В журналы и тикеты не следует переносить само значение секрета.

Можно ли передавать секрет через переменную окружения?

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

Управление секретами сервера: хранение, ротация и отзыв доступов

Пароли, API-ключи, закрытые ключи и реквизиты сервисов нужно учитывать как объекты с владельцем, сроком и процедурой отзыва, а не как строки в конфигурации. Для нескольких сервисов и CI/CD обычно выбирают управляемое хранилище секретов; для малого изолированного сервера допустим отдельный файл с жёсткими правами либо штатное хранилище учётных данных ОС, если заранее определены резервное копирование, аудит и ротация. Доступ выдаётся конкретному пользователю или рабочей нагрузке по принципу наименьших привилегий, а смена и отзыв должны быть воспроизводимыми операциями.

Что считать секретом, а что — нет

Секрет — это значение, обладание которым позволяет аутентифицироваться, получить доступ, подписать операцию, расшифровать данные или выдать себя за сервис. К нему относятся пароли, API-токены, ключи доступа, закрытые SSH-ключи, пароли баз данных, токены webhook, ключи шифрования и реквизиты служебной учётной записи.

Объект	Считать секретом	Почему
Пароль обычной пользовательской учётной записи	Да, но это секрет человека	Его жизненный цикл связан с личностью и политикой аутентификации, а не с настройкой приложения.
Пароль или токен служебной учётной записи	Да, это секрет приложения или автоматизации	Его потребляет служба, задача или интеграция; у него должен быть технический владелец и процедура ротации.
Закрытый SSH-ключ	Да	Он позволяет аутентифицироваться от имени владельца ключевой пары. Выпуск и настройка SSH-доступа рассматриваются в статье «Безопасная настройка SSH: ключи, root и ограничение доступа».
Открытый ключ, идентификатор клиента, имя пользователя	Обычно нет	Эти данные могут быть чувствительными, но сами по себе обычно не дают право доступа. Их всё равно не следует без необходимости включать в публичные журналы.
Хеш пароля в базе аутентификации	Хранить как чувствительные данные, но не выдавать приложению как секрет подключения	Хеш используют для проверки пароля. Его раскрытие позволяет подбирать пароль офлайн, а некоторые типы хешей в определённых протоколах могут применяться для аутентификации без знания исходного пароля. Защита базы хешей — отдельная задача.
Ключ шифрования	Да	Это отдельный класс секрета с требованиями к управлению ключами шифрования. Аппаратное хранение ключей возможно через аппаратный модуль безопасности, если это соответствует архитектуре.

Не смешивайте управление секретами с парольной политикой пользователя. Требования к сложности, MFA, блокировке и сроку действия учётных записей Windows Server описаны в «Парольная политика, блокировка учётных записей и MFA в Windows Server», а персональные учётные записи, sudo и PAM в Linux — в «Учётные записи, sudo и парольная политика в Linux».

1. Найдите секреты и создайте инвентаризацию

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

Инвентаризация секретов

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

1
Определите область поиска
Составьте список серверов, приложений, репозиториев, заданий планировщика, CI/CD-проектов, внешних API, баз данных и административных интерфейсов. Отдельно включите устаревшие сервисы и резервные копии: именно там часто остаются прежние значения.
2
Найдите ссылки на секреты без вывода значений
Проверьте имена файлов, шаблоны конфигураций, переменные окружения и параметры запуска. При поиске не выводите содержимое потенциально секретных файлов в терминал, историю shell или тикет. Результат шага — список мест использования и предполагаемых потребителей, а не копия значения.
3
Заведите запись на каждый независимый секрет
Не объединяйте разные назначения под одним пунктом вроде «пароли приложения». Отдельными объектами будут пароль приложения к БД, токен внешнего API, закрытый ключ развертывания и пароль аварийной учётной записи.
4
Проверьте, есть ли владелец
Владельцем назначают роль или конкретного ответственного, который понимает назначение секрета и уполномочен запросить его замену или отзыв. Владелец приложения не обязательно является администратором хранилища: разделение этих обязанностей снижает риск единоличного неконтролируемого доступа.
5
Зафиксируйте непонятные находки как риск
Если назначение, владелец или потребитель неизвестны, не удаляйте файл сразу: сначала определите зависимости. Пометьте объект для разбора и ограничьте дальнейшее распространение значения; неизвестный секрет нельзя считать безопасным только потому, что сервис пока работает.

Минимальные поля реестра секретов

Поле	Что фиксировать
Идентификатор и тип	Непубличное имя, тип: пароль, токен, закрытый ключ, ключ шифрования, реквизиты служебной учётной записи.
Владелец	Роль или сотрудник, отвечающий за назначение, замену и подтверждение актуальности.
Назначение и целевая система	Какой сервис или ресурс защищает: например, доступ приложения к конкретной БД или API.
Потребители	Конкретные люди, службы, серверы, задания CI/CD и их идентичности.
Место использования и способ доставки	Путь в хранилище, файл, агент, API, защищённая переменная CI/CD; не само значение.
Критичность	Последствия раскрытия: доступ к данным, административные права, возможность подписи, охват систем.
Срок и дата следующего пересмотра	Срок действия, плановая дата ротации либо причина отсутствия срока.
Зависимости ротации	Какие потребители должны перейти на новое значение, возможно ли перекрытие старого и нового.
Экстренный отзыв	Кто и где отключает учётную запись, токен или ключ; что проверять после отзыва.
Копии и резервные данные	Репозитории, образы, резервные копии, конфигурации и журналы, где значение могло сохраниться.

2. Выберите хранилище по масштабу и риску

Репозиторий, образ, общий файл конфигурации, чат и таблица не подходят для контролируемой выдачи: после копирования трудно установить, кто прочитал значение, где оно осталось и все ли потребители перешли на новое. Удаление секрета из Git не отменяет его наличия в истории, клонах, сборках и кэшах.

Сценарий	Соразмерный вариант	Обязательные ограничения
Один небольшой изолированный сервер, один-два сервиса	Штатное хранилище учётных данных ОС либо отдельный файл секрета, доступный только служебной учётной записи	Учесть копирование в резервные копии, ограничить права и владельца, исключить чтение посторонними процессами, определить ручную ротацию и проверку доступа.
Команда с CI/CD и несколькими средами	Управляемое хранилище секретов или штатный защищённый механизм CI/CD с разграничением доступа по проекту и среде	Разделить production и test, назначить идентичности заданиям, исключить секреты из журналов и артефактов, настроить отзыв доступа при изменении роли.
Несколько сервисов, серверов и администраторов	Специализированное хранилище секретов с политиками доступа, аудитом и интеграцией с управляемыми идентичностями	Выдавать доступ к конкретным путям и операциям, проверить резервный административный доступ, процедуру восстановления и работоспособность при недоступности внешней аутентификации.

Шифрование файла не заменяет управление секретами

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

Для отдельного файла секрета создайте выделенный каталог. По умолчанию владельцем файла оставьте root или доверенный механизм доставки, а служебной учётной записи приложения предоставьте только чтение через выделенную группу, в которой нет других потребителей. Права 0750 на каталог и 0640 на файл — типичная базовая мера на Linux для такой схемы. Если приложение должно само изменять файл, это право нужно обосновать и учесть отдельно. Обычные права не защищают от процессов с более высокими привилегиями и не заменяют контроль SELinux или AppArmor, если они применяются. Настройка таких политик описана в статьях «SELinux на сервере: Enforcing, контексты и устранение отказов» и «AppArmor на сервере: профили, enforce и диагностика отказов».

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

install -d -o root -g appsvc -m 0750 /etc/app-secrets && if [ -e /etc/app-secrets/database.env ] || [ -L /etc/app-secrets/database.env ]; then printf '%s\n' 'Файл уже существует и не был изменён' >&2; false; else install -o root -g appsvc -m 0640 /dev/null /etc/app-secrets/database.env; fi && stat -c '%A %U:%G %n' /etc/app-secrets /etc/app-secrets/database.env

Вывод:

Ожидаемый результат для нового объекта: каталог имеет права `drwxr-x---`, файл — `-rw-r-----`, владельцем указан `root`, а группой — `appsvc`. Перед запуском сервиса отдельно убедитесь, что его учётная запись входит только в необходимую выделенную группу и может читать файл, но не изменять его.

Резервные копии и аварийный доступ

Файл секрета может попасть в резервную копию вместе с конфигурацией. Укажите в реестре, где хранится такая копия, кто имеет к ней доступ и как она защищена. Аварийный административный доступ должен быть отдельной контролируемой процедурой; при необходимости используют аварийную учётную запись. Не храните её реквизиты в том же единственном недоступном хранилище без проверенного сценария восстановления.

3. Назначьте идентичности и минимальные права

Хранилище секретов должно сначала установить, кто запрашивает доступ, и только затем решить, разрешена ли операция. Идентичностью может быть персональная учётная запись администратора, служебная учётная запись процесса, идентичность задания CI/CD или отдельная роль аварийного доступа. Один общий пароль для команды или всех серверов лишает систему возможности отозвать доступ одному потребителю и затрудняет расследование.

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

Точные названия разрешений, ролей, методов аутентификации, журналов и процедур восстановления зависят от выбранного хранилища, его редакции, версии и модели развёртывания. Перед включением интеграции проверьте в официальном руководстве продукта, поддерживаются ли нужные типы идентичностей, раздельные права операций, аудит, резервный доступ и восстановление после утраты ключей разблокировки или недоступности внешнего провайдера идентичности. В отличие от BIOS, BMC и firmware серверного оборудования, для таких интеграций обычно неприменима привязка к модели сервера; существенны версии и архитектура программных компонентов.

4. Переведите приложения и автоматизацию на контролируемую выдачу

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

Перевод потребителя на управляемый секрет

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

1
Создайте отдельную идентичность потребителя
Для приложения создайте отдельную служебную учётную запись или другую поддерживаемую рабочую идентичность. Для CI/CD используйте идентичность проекта или задания, а не персональный токен разработчика. Результат: в журнале можно отличить запрос одного потребителя от другого.
2
Назначьте только необходимую операцию
Разрешите этой идентичности чтение конкретного секрета или пути. Не выдавайте перечисление всего хранилища, изменение политик или административные права, если задача их не требует. Проверьте отказ при попытке обратиться к соседнему секрету: такой отказ подтверждает, что граница доступа работает.
3
Выберите способ доставки в процесс
Используйте API или агент, если приложение это поддерживает. Для простого сервиса допустим файл с ограниченными правами, созданный механизмом доставки перед запуском. Определите, как файл обновляется без лишних копий и когда удаляется: временный файл не должен сохраняться после остановки сервиса или завершения задачи, если он больше не нужен. Переменная окружения возможна только после оценки рисков и должна передаваться без включения в исходный код, шаблоны и журналы.
4
Уберите значение из исходных материалов
Замените строку секрета в конфигурации ссылкой на путь, имя переменной без значения либо механизмом чтения файла/API. Проверьте шаблоны развертывания, Dockerfile, файлы переменных, скрипты и настройки CI/CD: значение не должно попасть в собранный образ, кэш или артефакт.
5
Проверьте запуск и журналирование
Запустите сервис с новой идентичностью и убедитесь, что он подключается к целевой системе. Затем проверьте журналы приложения, менеджера служб и CI/CD: там должны быть факт успешного запуска или ошибка доступа, но не пароль, токен или полный заголовок авторизации.
6
Удалите прежнюю неуправляемую копию
После подтверждённого перехода удалите старое значение из рабочего файла и ограничьте доступ к историческим копиям. Если прежнее значение было в репозитории, журнале или чате, считайте его раскрытым и выполните отзыв или замену, а не только удаление текста.

Bootstrap-проблема: чем приложение входит в хранилище

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

Переменные окружения удобны, но не являются изолированным хранилищем

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

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

5. Проведите тестовую ротацию и отзыв

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

Тестовая ротация секрета

Сначала отработайте сценарий на одном некритичном потребителе или в контролируемой среде. Результат должен быть документирован в реестре.

1
Определите способ совместимого перехода
Установите, может ли целевая система временно принимать два ключа, токена или пароля. Если да, задайте ограниченное окно перекрытия. Если нет, согласуйте порядок остановки, смены значения, обновления потребителя и проверки подключения.
2
Создайте новое значение и сохраните его в управляемом месте
Создайте новый секрет по принятому механизму, назначьте ему владельца и срок. Не вставляйте значение в командную строку, тикет или чат. В реестре отметьте, какое значение является новым активным, не записывая его содержимое.
3
Переведите потребителей
Обновите ссылку или механизм получения у каждого потребителя, перезапустите только те службы, которым это требуется, и подтвердите успешную аутентификацию с новым значением. Если потребитель не переходит, не удаляйте старое значение до разбора зависимости и решения о допустимом простое.
4
Проверьте использование нового значения
Проверьте журналы целевой системы, хранилища и приложения за согласованный период. Если события содержат версию или идентификатор реквизита, убедитесь, что известные потребители используют новое значение. Если журналы показывают только имя учётной записи, отсутствие ошибок не доказывает прекращение использования старого пароля или токена: отдельно подтвердите работу нового значения на каждом известном потребителе и учитывайте временно выключенные задания.
5
Отзовите старое значение
Отключите прежний токен, пароль, ключ или учётную запись на стороне целевой системы, а не только удалите его из хранилища. Затем повторите проверку сервиса и следите за отказами: они могут выявить неучтённого или редко запускаемого потребителя. Если отзыв нельзя безопасно отменить, заранее предусмотрите окно обслуживания и порядок выпуска нового значения.
6
Обновите реестр и процедуру
Зафиксируйте дату, ответственного, затронутых потребителей, длительность перехода и найденные копии. Если потребовалось ручное исключение, внесите его как ограничение процесса, а не оставляйте только в памяти исполнителя.

Если секрет мог утечь в репозиторий, журнал или на сервер

Удаление из Git не делает секрет безопасным

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

Определите секрет по реестру: владельца, целевую систему, права, всех известных потребителей и копии.
Ограничьте дальнейшее использование: при необходимости отключите затронутую идентичность, сетевой путь или интеграцию в рамках сдерживания инцидента. Полное реагирование на взлом описано в статье «Сервер взломали: изоляция, артефакты и первые действия».
Отзовите или замените значение на стороне целевой системы: отключите токен, удалите ключ из списка разрешённых, смените пароль служебной учётной записи либо создайте новый ключ по применимой процедуре.
Переведите легитимных потребителей на новое значение и подтвердите их работу. Не возвращайте старый секрет как временный обход, если есть подозрение на утечку.
Проверьте журналы обращений к секрету и целевой системе за период до и после предполагаемой утечки: ищите неизвестные источники, время, операции и неудачные попытки.
Найдите и ограничьте неуправляемые копии в репозиториях, артефактах, файлах, резервных данных и переписке. Удаление копии уменьшает дальнейшее распространение, но не отменяет уже выполненную замену.
Оцените зависимые системы: секрет с административными правами может требовать проверки созданных учётных записей, изменённых политик, новых ключей или обращений к данным.

6. Ведите аудит выдачи и регулярно пересматривайте права

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

Назначьте владельца журналов и период их пересмотра; без ответственного аудит превращается в архив, который никто не читает.
Не записывайте значения секретов в события. Проверьте, что маскируются параметры запросов, заголовки авторизации, переменные отладки и дампы ошибок.
Ограничьте доступ к журналам: идентификаторы секретов, имена сервисов, источники запросов и аргументы могут быть чувствительными.
Установите срок хранения по требованиям расследования и доступному объёму, учитывая резервные копии журналов и право на их удаление.
Регулярно сопоставляйте политики хранилища с реестром: удаляйте доступы уволенных сотрудников, закрытых сервисов, завершённых CI/CD-проектов и временных задач.
Проверяйте экстренный доступ отдельно: запись о наличии аварийной учётной записи не доказывает, что она работает и при этом не используется в обычной эксплуатации.

События хранилища дополняют, а не заменяют журналы ОС и приложений. Для Linux порядок настройки auditd, хранения и поиска событий приведён в «Аудит безопасности Linux: auditd, входы и контроль действий», для Windows — в «Аудит Windows Server: Security Log, Advanced Audit Policy и PowerShell». Если журналы собираются централизованно, доступ к этой системе и её учётным данным также рассматривайте как отдельную область секретов.

Термины в статье

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