Разграничение прав доступа LDAP: как группа становится ролью
Сервис принимает логин и пароль, ищет пользователя в LDAP, проверяет его членство в разрешенной группе, сопоставляет группу с ролью и применяет набор прав. Цепочка выглядит так: user → LDAP group → application role → permissions. Наличие учетной записи в каталоге само по себе не означает доступ к сервису. Безопасная модель должна использовать default deny для пользователей без подходящей группы.
Точные названия параметров зависят от продукта и его версии, но логика настройки одинакова. В этой статье разберем, как спроектировать группы, проверить атрибуты каталога, настроить фильтры поиска, связать группы с ролями и проверить итоговые права.
Аутентификация и авторизация решают разные задачи
Аутентификация подтверждает личность пользователя: сервис проверяет, что логин существует в каталоге и пароль верен. Авторизация определяет, какие действия пользователю разрешены. Эти этапы разделены. Успешный вход в LDAP не гарантирует корректные права доступа: приложение дополнительно читает членство в группах и сопоставляет его с ролями.
Каталог возвращает набор атрибутов пользователя, включая DN и списки групп. Приложение интерпретирует эти данные по своим правилам. Если группа не назначена или не сопоставлена с ролью, доступ должен быть отклонен.
Базовая схема LDAP-группы и роли
Минимальная рабочая модель: группа cn=app-admins назначается роли администратора, cn=app-operators роли оператора, cn=app-readonly роли только для чтения. Каждая роль включает определенный набор прав, например:
- Администратор: полный доступ к настройкам, управление пользователями, изменение конфигурации.
- Оператор: выполнение рабочих операций, просмотр состояния, запуск задач.
- Только чтение: просмотр данных без изменений.
Группы доступа отделяйте от функциональных или организационных групп. Группа отдела «Маркетинг» не должна автоматически давать права на сервис. Для каждого сервиса создавайте отдельные группы с явным указанием уровня доступа.
Спроектируйте модель групп до подключения сервиса
Начните с матрицы ролей и прав, затем создавайте LDAP-группы под эту матрицу. Одна группа должна иметь понятное назначение, а имя отражать сервис и уровень доступа. Пример иерархии: ou=Groups,dc=example,dc=com со схемой app-admins, app-operators, app-readonly.
Не смешивайте группы доступа с отделами, командами и группами рассылки. Это затрудняет аудит и повышает риск случайной выдачи прав.
Прямое и вложенное членство в группах
Прямое членство означает, что пользователь явно добавлен в группу как атрибут member или uniqueMember. Вложенное членство: пользователь входит в группу A, которая сама является членом группы B. Не каждый сервис разворачивает вложенность. Фильтр по memberOf может не учитывать косвенное членство. Для критичных прав проверяйте фактическую поддержку nested groups и при необходимости используйте прямое членство.
Правила именования и разделения областей доступа
Используйте единый шаблон имен: сервис, окружение, роль. Например, app-prod-admins, app-test-operators. Разделяйте группы production и test, административные и пользовательские роли. Группа должна быть привязана к роли явно, без неочевидных совпадений по части имени.
Проверьте структуру каталога и атрибуты членства
Универсального LDAP-фильтра не существует. Набор атрибутов зависит от objectClass и типа каталога. Перед настройкой приложения посмотрите реальные записи через ldapsearch, затем переносите значения в конфигурацию сервиса.
Какие атрибуты встречаются в OpenLDAP и Active Directory
В OpenLDAP распространены:
memberдля DN участников групп (objectClass groupOfNames)uniqueMemberдля groupOfUniqueNamesmemberUidдля posixGroup (хранит короткие имена пользователей, а не DN)memberOfдля обратной связи от пользователя к группе, но его наличие не гарантируется и может зависеть от overlay
В Active Directory проверяйте member (DN участников), memberOf (обратное членство), groupType, sAMAccountName. Учитывайте, что memberOf в AD не возвращает группы, если пользователь является членом через вложенность, если не включена специальная опция.
Как проверить запись пользователя и группы через ldapsearch
Пример запроса пользователя:
ldapsearch -x -H ldap://ldap.example.com -b "dc=example,dc=com" "(uid=jdoe)"Пример запроса группы:
ldapsearch -x -H ldap://ldap.example.com -b "dc=example,dc=com" "(cn=app-admins)"Проверьте, возвращается ли нужный атрибут членства, совпадает ли DN пользователя со значением в группе и видит ли эти поля сервисная учетная запись.
Регистрозависимость, DN и нормализация значений
Полный DN, короткое имя и логин различаются. Фильтр должен сравнивать тот атрибут и тот формат значения, который реально возвращает каталог. Учитывайте спецсимволы, экранирование и пробелы в DN. Например, uid=jdoe,ou=Users,dc=example,dc=com не равен jdoe.
Настройте поиск пользователей, групп и LDAP-фильтры
Последовательность настройки: укажите LDAP или LDAPS endpoint, Base DN, bind-пользователя, область поиска пользователей, user filter, область поиска групп и group filter, атрибут логина и атрибут членства. Для каждого параметра проверьте ожидаемый результат в тестовом запросе. Синтаксис полей различается между продуктами, поэтому сверяйтесь с документацией конкретной версии.
Сервисная учетная запись и минимальные права поиска
Используйте отдельный bind-пользователь только для поиска, без права изменения пользователей и групп. Пароль храните в секретах или защищенном хранилище, контролируйте срок действия и ротацию.
Фильтр поиска пользователя
Ограничьте авторизацию только нужными объектами. Фильтры по uid, sAMAccountName, userPrincipalName и objectClass. Добавьте условия активности учетной записи, организационного подразделения или принадлежности к базовой группе, если это поддерживает каталог. Пример: (&(objectClass=person)(uid=jdoe)(memberOf=cn=app-users,ou=Groups,dc=example,dc=com)).
Фильтр поиска группы и способ проверки членства
Сервис может искать группу по участнику или читать список групп из записи пользователя. Варианты проверки:
- Поиск группы с фильтром
(member=uid=jdoe,ou=Users,dc=example,dc=com) - Чтение атрибута
memberOfиз записи пользователя - Для posixGroup использовать
memberUid=jdoe
Проверьте поддержку вложенных групп и ограничения по размеру ответа.
Проверка сетевого пути до LDAP
Проверьте DNS, маршрут и доступность нужного TCP-порта со стороны ОС, например через nmap. Если сервис размещен в инфраструктуре Selectel, учитывайте, что входящий и исходящий трафик фильтруется на границе интернет-сети, а часть TCP/UDP-портов может быть заблокирована. Недоступность порта, отсутствующего в опубликованном списке, следует дополнительно проверять со стороны ОС; запрос на разблокировку рассматривается индивидуально и не гарантирует результат. Не переносите ограничения SMTP-портов 25, 465 и 587 на диагностику LDAP: это отдельное правило для исходящего трафика к публичным IPv4- и IPv6-адресам.
Настройте разграничение прав доступа LDAP в приложении
Преобразуйте LDAP-группы в роли приложения. При неоднозначных результатах безопасное поведение - отказ в доступе.
Сопоставление групп с ролями
Пример таблицы соответствий:
| LDAP-группа | Роль | Используемое значение |
|---|---|---|
| cn=app-admins,ou=Groups,dc=example,dc=com | administrator | полный DN |
| cn=app-operators,ou=Groups,dc=example,dc=com | operator | полный DN |
| cn=app-readonly,ou=Groups,dc=example,dc=com | viewer | полный DN |
Уточните, используется ли полный DN группы, короткое имя или значение sAMAccountName.
Фильтры авторизации по ролям
Формируйте условия доступа для одной или нескольких групп. Используйте LDAP-условия AND и OR, фильтрацию по objectClass и имени группы, а также проверку пользователя через memberOf. Избегайте фильтров вроде cn=*admin*, которые могут выдать права группе с неожиданным именем.
Конфликт нескольких ролей и роль по умолчанию
Определите приоритет ролей заранее. Административная роль не должна назначаться автоматически из-за любого совпадения. Роль по умолчанию должна быть минимальной или отсутствовать. При конфликте применяйте явное правило отказа и документируйте результат.
Проверьте права доступа пользователей LDAP
Проверяйте настройку по матрице пользователей и ожидаемых ролей. Минимальный набор: пользователь-администратор, оператор, пользователь только для чтения, пользователь без группы и пользователь из запрещенной группы. Для каждого сценария зафиксируйте результат входа, назначенную роль, доступные операции и запись в журнале.
Тестовая матрица ролей и разрешений
Составьте таблицу с учетной записью, LDAP-группой, ожидаемой ролью, разрешенными и запрещенными действиями. Проверьте граничные операции: просмотр, изменение, удаление, управление пользователями и изменение конфигурации.
Проверка LDAP-запросов и журналов приложения
В логах ищите события: отказ bind, пустой результат user filter, недоступный group Base DN, отсутствие member или memberOf, неизвестная группа и отказ при назначении роли. Сопоставьте логи с ручными запросами ldapsearch.
Проверка после изменения состава группы
После добавления и удаления пользователя из группы проверьте повторный вход, завершение старой сессии, время обновления кэша и поведение нескольких экземпляров сервиса. Зафиксируйте, требуется ли перезапуск или принудительная инвалидация сессии.
Разберите типовые ошибки в LDAP-авторизации
Конфигурация выглядит корректной, но роль не назначается или пользователь получает лишние права. Разберем частые случаи.
Пользователь входит, но остается без роли
Проверьте, возвращается ли группа для пользователя, совпадает ли значение с mapping приложения, не используется ли memberUid вместо полного DN и не скрыта ли группа ограничениями ACL для bind-пользователя.
Пользователь получает роль администратора вместо ограниченной роли
Проверьте пересечение групп, порядок правил, слишком широкий wildcard-фильтр, поддержку вложенных групп и приоритет ролей. Запретите неявное повышение роли и добавьте отдельный тест на пользователя с несколькими группами.
Не работает вложенная группа
Проверьте, разворачивает ли сервис nested groups, возвращает ли каталог косвенное членство и какой фильтр используется. Для критичных разрешений используйте прямое членство или предварительно рассчитанную группу доступа.
LDAP недоступен или запрос завершается по таймауту
Проверьте DNS, маршрут, TCP-порт, TLS-сертификат, firewall и сетевые ограничения площадки. При размещении в Selectel учитывайте фильтрацию на бордерах и проверяйте доступность нужного порта через nmap. Отсутствие ответа не доказывает неверный group filter.
После изменения групп права не обновились
Проверьте время жизни LDAP-кэша, токена или сессии, состояние репликации и необходимость повторного входа. Удаление пользователя из группы тестируйте отдельно от добавления.
Закрепите безопасную эксплуатацию групп и ролей
Переведите разовую настройку в управляемый процесс с контролем изменений, защитой учетных данных и возможностью восстановления доступа.
Защитите канал и учетные данные
Используйте LDAPS или StartTLS с проверкой цепочки сертификатов, запретите небезопасный простой bind без шифрования и регулярно ротируйте пароль сервисной учетной записи.
Контролируйте изменения групп
Журналируйте изменения состава административных групп, периодически ревизуйте участников, владельца каждой группы и процедуру удаления доступа при увольнении или смене роли.
Итоговый чек-лист перед вводом в эксплуатацию
Проверьте сетевое соединение, TLS, bind, поиск пользователя, поиск группы, атрибут членства, mapping ролей, default deny, конфликт ролей, тест удаления из группы, логи и аварийный локальный доступ. Сверьте инструкцию с версией приложения и схемой каталога.
Дополнительно: используйте LDAPS или StartTLS с проверкой сертификата, ограничьте ACL сервисной учетной записи, не храните пароль в открытой конфигурации, ведите аудит изменений групп и регулярно проверяйте фактические права. Обеспечьте локальную аварийную учетную запись и документированный способ отката LDAP-настроек.