Управление паролями 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. Включение движка

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

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

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

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

url

ldap://ipa.demo.pre:389

Адрес LDAP-сервера. Для шифрования используйте ldaps:// на порту 636

binddn

uid=admin,cn=users,...

DN служебной учетки, от имени которой StarVault будет менять пароли. Должна иметь права на изменение userPassword

bindpass

<ваш_пароль>

Пароль служебной учетки. Хранится в зашифрованном виде внутри StarVault

userdn

cn=users,cn=accounts,...

Базовый DN для поиска пользователей

userattr

uid

Атрибут, по которому идентифицируется пользователь (в AD обычно sAMAccountName)

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

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

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

Параметры:

полный DN пользователя

Точный идентификатор записи в каталоге

username

ldap-user

Имя пользователя (по атрибуту userattr из конфига)

rotation_period

Как часто StarVault будет менять пароль. Поддерживаются единицы: s, m, h

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

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

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

Поля вывода:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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