Управление паролями LDAP-пользователей через StarVault: настраиваем движок секретов LDAP

Разработка безопасного программного обеспечения — одна из самых распространенных тем, связанных с ИБ, в 2026 году. Вокруг нее мы все чаще слышим слова «управление секретами», «безопасная доставка секретов» и т.д. Мы уже писали практическую статью тут, но, как показывает практика, системы управления секретами не крутятся только вокруг key-value значений или динамических секретов для database. Я Руслан Гайфутдинов, ведущий пресейл-инженер системы управления секретами StarVault в Orion soft. В этой статье предлагаю рассмотреть еще один (не забытый, а, скорее, не известный) механизм секретов LDAP. 

Для начала предлагаю разделить понятия. В StarVault есть два совершенно разных способа работы с LDAP, и их легко перепутать:

• Метод аутентификации LDAP — позволяет пользователям входить в StarVault, используя свои LDAP-учетные данные. StarVault проверяет пароль через LDAP и выдает токен;

• Движок секретов LDAP — StarVault сам управляет паролями LDAP-пользователей: автоматически ротирует их по расписанию и выдает приложениям актуальные credentials.

Эта статья про второй сценарий. Движок секретов LDAP превращает StarVault в централизованную систему управления паролями учетных записей в каталоге — будь то FreeIPA, Active Directory или любой другой LDAP-сервер.

Зачем это нужно

Типичная проблема в инфраструктуре: есть сервисные учетные записи в LDAP (например, системы мониторинга, gitlab, vpn, почты и т.д), пароли от которых прописаны в конфигах, переменных окружения или вообще «живут» только в голове администратора. Это создает риски:

• Пароль не меняется годами — если утечет, злоумышленник получает долгосрочный доступ;

• Несколько команд знают один и тот же пароль — при увольнении сотрудника его нужно менять везде;

• Нет аудита — непонятно, кто и когда использовал учетную запись.

Движок секретов LDAP решает эти проблемы: система управления секретами берет на себя ротацию паролей по расписанию, а приложения запрашивают актуальный пароль через API перед каждым использованием.

Архитектура решения

StarVault подключается к LDAP под служебной учеткой (binddn) и меняет пароль целевого пользователя. При следующем обращении приложения StarVault возвращает уже новый пароль.

Настройка

Шаг 1. Включение движка

starvault secrets enable -path=ldap ldap

Флагpath=ldap задает путь, по которому будет смонтирован движок. Можно использовать любой путь, например, -path=ipa-prod или -path=ad-secrets — это удобно, если нужно подключить несколько LDAP-серверов (или, например, у вас есть еще AD).

После выполнения команды StarVault регистрирует новый движок и открывает пространство путей ldap/* для операций с секретами.

Шаг 2. Настройка подключения к LDAP

starvault write ldap/config \
  url="ldap://ipa.demo.pre:389" \
  binddn="uid=admin,cn=users,cn=accounts,dc=demo,dc=pre" \
  bindpass='<ваш_пароль>' \
  userdn="cn=users,cn=accounts,dc=demo,dc=pre" \
  userattr="uid"

Разберем каждый параметр:

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

Шаг 3. Создание статической роли

starvault write ldap/static-role/ldap-user \
  dn="uid=ldap-user,cn=users,cn=accounts,dc=demo,dc=pre" \
  username="ldap-user" \
  rotation_period="1h"

Статическая роль (static-role) — это привязка между StarVault и конкретным пользователем в LDAP. В отличие от динамических учеток для механизма секретов database (которые создаются и удаляются на лету), статическая роль управляет уже существующим пользователем.

Параметры:

Имя роли в пути (ldap-user после static-role/) — произвольное. Можно называть по назначению: ldap/static-role/backup-agent, ldap/static-role/monitoring-user. То есть не обязательно привязываться к учетной записи пользователя.

Что происходит сразу после создания роли: StarVault немедленно генерирует новый пароль для пользователя и устанавливает его в LDAP. Старый пароль перестает работать. Таймер ротации запускается с этого момента.

Шаг 4. Чтение актуальных credentials

starvault read ldap/static-cred/ldap-user

# Пример вывода:
Key                    Value
---                    ----
dn                     uid=ldap-user,cn=users,cn=accounts,dc=demo,dc=pre
last_password          n/a
last_vault_rotation    2026-06-17T22:59:11.159116327+03:00
password               SNg6pqqK8QpIWjuOtDWEMfux87eJtXrOQ5g4eTymJ0Y1HAEvceAPwVMnh4mvCfKd
rotation_period        1h
ttl                    56m7s
username               ldap-user

Поля вывода:

• password — текущий актуальный пароль пользователя в LDAP;

• last_password — предыдущий пароль (на случай если смена еще не применилась повсюду). При первой ротации показывает n/a;

• last_vault_rotation — время последней смены пароля;

• ttl — сколько времени осталось до следующей ротации.

Приложения должны запрашивать пароль через этот endpoint перед каждым подключением к LDAP, а не кэшировать его надолго.

Шаг 5. Вход в StarVault под управляемым пользователем

Если для ldap-user также настроен метод аутентификации LDAP (отдельная настройка), можно войти в StarVault под этим пользователем:

starvault login -method=ldap username=ldap-user

# Пример вывода:
Password (will be hidden): 
Success! You are now authenticated. The token information displayed below is
already stored in the token helper. You do NOT need to run "starvault login"
again. Future StarVault requests will automatically use this token.
Key                    Value
---                    -----
token                  s.H8liKRd2IwUnmEBJQMPtldYS
token_accessor         g6aqaB4ejmGUMSDy5CBmzr
token_duration         768h
token_renewable        true
token_policies         ["default"]
identity_policies      []
policies               ["default"]
token_meta_username    ldap-user

Здесь важно понимать разделение ответственности:

• Движок секретов LDAP управляет паролем пользователя в LDAP-каталоге;

• Метод аутентификации LDAP использует этот пароль для входа в StarVault.

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

Ротация паролей: как это работает изнутри

t=0h     Роль создана → StarVault генерирует пароль 1 → устанавливает в LDAP
t=0h     Приложение читает /ldap/static-cred/ldap-user → получает пароль 1
t=56m    Приложение снова читает → получает пароль 1, ttl=4m
t=1h     StarVault автоматически генерирует пароль 2 → устанавливает в LDAP
         Пароль 1 сохраняется в поле last_password
t=1h+    Приложение читает → получает пароль 2

Пароли генерируются криптографически стойким генератором. Длина по умолчанию — 64 символа (как видно в примере вывода).

Права доступа (Policies)

Для того чтобы приложение могло читать credentials, ему нужна политика StarVault:

# Только на чтение текущего пароля для роли ldap-user
path "ldap/static-cred/ldap-user" {
  capabilities = ["read"]
}
# Только чтение credentials для любой static-роли
path "ldap/static-cred/*" {
  capabilities = ["read"]
}

Итог

Движок секретов LDAP в StarVault переводит управление сервисными учетками из ручного режима в автоматический. Вместо статических паролей в конфигах — динамически ротируемые credentials с централизованным аудитом и контролем доступа через политики StarVault.