Аутентификация

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

Поддерживаются следующие режимы аутентификации:

Аутентификация с использованием стороннего IAM-провайдера

  • Access Token — параметром для клиента (SDK или CLI) задается фиксированный токен, который передается в запросы.
  • Refresh Token — параметром для клиента (SDK или CLI) задается OAuth токен персональной учетной записи, на основании которого клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы.
  • Service Account Key — параметром для клиента (SDK или CLI) задаются атрибуты сервисной учетной записи и ключ для подписи, на основании которых клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы.
  • Metadata — клиент (SDK или CLI) периодически обращается к локальному сервису для ротации (получения следующего) токена, передаваемого в запросы.
  • OAuth 2.0 token exchange - клиент (SDK или CLI) обменивает токен другого типа на access token по протоколу обмена токенов OAuth 2.0, который затем передаётся в запросы YDB API.

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

Режимы аутентификации с ротацией токена Refresh Token и Service Account Key обеспечивают больший уровень безопасности по сравнению с режимом с фиксированным токеном Access Token, так как на сервер YDB по сети передаются только короткоживущие секреты.

Максимальная безопасность и производительность обеспечивается при использовании режима Metadata, так как он исключает необходимость работы с секретами при развертывании приложения, а также позволяет обратиться к IAM и закешировать токен заранее, до запуска приложения.

При выборе режима аутентификации среди поддерживаемых сервером и окружением, следует руководствоваться следующими рекомендациями:

  • Anonymous обычно применяется на самостоятельно разворачиваемых локальных кластерах YDB, недоступных по сети.
  • Access Token применяется при отсутствии поддержки других режимов на стороне сервера или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдаваемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново.
  • Refresh Token может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации.
  • Service Account Key применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим Metadata, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог Refresh Token для сервисных учетных записей. В отличие от персональной учетной записи, объекты доступа и роли сервисной учетной записи могут быть ограничены.
  • Metadata применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в Cloud Functions Yandex.Cloud.

Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка YDB. В частности, для сервиса YDB в Yandex.Cloud применяется Yandex.Passport OAuth и сервисные аккаунты Yandex.Cloud. При использовании YDB в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации.

При использовании режимов, предусматривающих обращение клиента YDB к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По умолчанию в существующих SDK и CLI производится попытка обращения к API IAM Yandex.Cloud, размещенному на iam.api.cloud.yandex.net:443.

Аутентификация по логину и паролю

Процесс аутентификации по логину и паролю включает следующие шаги:

  1. Клиент обращается к БД и передает логин и пароль пользователя сервису аутентификации YDB.

    Имя пользователя может содержать только строчные буквы латинского алфавита и цифры. Требования к паролю не предъявляются, пароль может быть пустым.

  2. Сервис аутентификации передает аутентификационные данные в компонент аутентификации YDB.

  3. Компонент валидирует аутентификационные данные, при успешном сопоставлении создает токен и возвращает его сервису аутентификации.

    Использование токена ускоряет процесс аутентификации и повышает безопасность. Время жизни токена по умолчанию 12 часов. Для ротации токенов YDB SDK самостоятельно обращается к сервису аутентификации.

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

  4. Сервис аутентификации возвращает токен клиенту.

  5. Клиент обращается к БД, передавая в качестве аутентификационной информации токен.

Для включения аутентификации по логину и паролю укажите значение true для ключа enforce_user_token_requirement в конфигурационном файле кластера.

Об управлении ролями и пользователями читайте в Управление доступом.

Взаимодействие с LDAP каталогом

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

Примеры поддерживаемых реализаций LDAP каталогов: OpenLdap, Active Directory.

Аутентификация

Аутентификация с помощью LDAP протокола похожа на процесс аутентификации по логину и паролю. Отличие заключается лишь в том, что роль компонента аутентификации играет LDAP каталог. LDAP каталог используется только для проверки пары логин/пароль.

Примечание

Так как LDAP каталог является внешним независимым сервисом, YDB не имеет возможности управлять учетными записями пользователей в каталоге. Для успешной аутентификации пользователь уже должен быть создан в LDAP каталоге. Использование команд CREATE USER, CREATE GROUP, ALTER USER, ALTER GROUP, DROP USER, DROP GROUP не окажет влияния на список пользователей и групп в каталоге. Информацию об управлении учетными записями необходимо искать в документации используемого LDAP каталога.

На данный момент YDB поддерживает только один способ LDAP аутентификации, так называемый search+bind метод, состоящий из нескольких шагов. После получения логина и пароля пользователя, которого нужно аутентифицировать, выполняется операция bind с заранее определенными в секции ldap_authentication учетными данными специального сервисного аккаунта. Учетные данные такого сервисного аккаунта задаются через параметры конфигурации bind_dn и bind_password. После успешной аутентификации сервисного пользователя от его имени выполняется поиск в LDAP каталоге пользователя, который пытается аутентифицироваться в системе. Операция search выполняется для всего поддерева, корень которого берется из параметра конфигурации base_dn. Поиск записи в поддереве осуществляется в соответствии с фильтром, задаваемым в параметре конфигурации search_filter. После того как запись пользователя была найдена, YDB выполняет повторную операцию bind от лица этого найденного пользователя, используя ранее запрошенный пароль. Успех аутентификации пользователя определяется результатом повторной операции bind.

После успешной аутентификации пользователя формируется токен. Далее этот токен используется вместо логина и пароля. Оперирование токеном ускоряет процесс аутентификации и повышает безопасность.

Примечание

При использовании LDAP-аутентификации, никакие пароли пользователей в YDB не хранятся.

Проверка токена

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

Группы, как и сам пользователь, являются субъектами выполнения операций над объектами схемы базы данных. Для разграничения доступа к различным ресурсам базы данных субъектам могут назначаться права доступа. И в соответствии со списком назначенных прав субъекты будут авторизованы на выполнение тех или иных операций.

Процесс получения списка групп пользователя из LDAP каталога похож на те действия, которые выполняются при аутентификации. Сначала выполняется операция bind для сервисного пользователя, учетные данные которого записаны в параметрах bind_dn и bind_password секции ldap_authentication файла конфигурации. После успешной аутентификации выполняется поиск записи пользователя, для которого был ранее сформирован токен. Поиск также выполняется в соответствии с параметром search_filter. Если пользователь всё ещё существует, то в качестве возвращаемого результата операции search будет список значений атрибута, записанного в параметре requested_group_attribute. В случае, если этот параметр пуст, то аттрибутом обратного членства в группе будет являться memberOf. Атрибут memberOf хранит уникальные имена (Distinguished Name, DN) групп, в которых состоит пользователь.

Получение групп

По умолчанию YDB выполняет поиск только тех групп, в которых пользователь состоит непосредственно. С помощью включения флага extended_settings.enable_nested_groups_search секции ldap_authentication YDB будет пытаться получить группы на всех уровнях вложенности, а не только те, в которые пользователь входит напрямую. Если YDB настроен для работы с Active Directory, для поиска всех вложенных групп будет использовано специфичное для Active Directory правило соответствия LDAP_MATCHING_RULE_IN_CHAIN. Это правило позволяет получить все вложенные группы одним запросом. Для LDAP-серверов на основе OpenLDAP поиск групп будет выполнен рекурсивным обходом графа, что в общем случае требует выполнения нескольких запросов. Как для Active Directory, так и для OpenLDAP поиск групп будет выполнен только для поддерева, корень которого берётся из параметра конфигурации base_dn.

Примечание

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

Пример:

cn=Developers,ou=Groups,dc=mycompany,dc=net@ldap

Примечание

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

Важно

Нужно заметить, что на данный момент YDB не имеет возможности отслеживать переименования групп, сделанные на стороне LDAP сервера. Тем самым, группа с новым именем не будет обладать теми же правами, которые были у группы с прежним именем.

LDAP пользователи и группы в YDB

Так как YDB позволяет использовать различные способы аутентификации пользователя (аутентификация по логину и паролю, использование IAM провайдера, LDAP каталог), то, оперируя именами пользователей и групп, часто бывает полезно различать, где именно аутентифицировался пользователь. Для всех видов аутентификации, кроме аутентификации по логину и паролю, имена групп и пользователей дополняются суффиксом вида <имя_пользователя>@<domain>.

Для LDAP пользователей domain задается в параметре конфигурации ldap_authentication_domain. По умолчанию имеет значение ldap, поэтому все имена пользователей, аутентифицированных с помощью LDAP каталога, и имена групп, в которых они состоят, в YDB будут иметь следующий вид:

  • user1@ldap
  • group1@ldap
  • group2@ldap

Важно

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

Ниже приведены примеры аутентификации пользователя user1 используя YDB CLI:

  • Аутентификация пользователя из LDAP каталога: ydb --user user1@ldap -p ydb_profile scheme ls
  • Аутентификация пользователя внутренним механизмом YDB: ydb --user user1 -p ydb_profile scheme ls

TLS соединение

В зависимости от указанных параметров конфигурации YDB может устанавливать либо зашифрованное либо незашифрованное соединение. Зашифрованное соединение с LDAP сервером устанавливается с использованием протокола TLS. Такой способ рекомендуется использовать для production кластеров. Существует два способа включить TLS соединение:

  • Автоматически. Используется схема соединения ldaps
  • Использование расширения LDAP протокола StartTls

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

LDAPS

Для того чтобы YDB автоматически установила зашифрованное соединение с LDAP-сервером, необходимо в параметре конфигурации scheme установить значение ldaps. TLS-диалог будет инициирован на порту, указанном в конфигурации. Если порт не указан, для схемы ldaps будет применён порт по умолчанию 636. LDAP-сервер должен быть настроен на приём TLS-соединений на указанных портах.

Расширение LDAP протокола StartTls

StartTls — это расширение протокола LDAP, используемое для шифрования сообщений по протоколу TLS. Оно позволяет передавать в рамках одного соединения с LDAP-сервером одни сообщения в зашифрованном виде, а другие — открыто. Сообщение с этим расширением отправляется от YDB к LDAP-серверу для инициирования TLS-соединения. В случае YDB не предусмотрено включение и выключение TLS-соединения в рамках одного соединения. Поэтому при использовании расширения StartTls после установления зашифрованного соединения YDB будет отправлять все дальнейшие сообщения к LDAP-серверу в зашифрованном виде. Одним из преимуществ использования данного расширения вместо схемы ldaps (при соответствующей настройке LDAP-сервера) является возможность установить TLS-соединение на нешифрованном порту. Расширение включается в секции use_tls файла конфигурации.

Предыдущая
Соединение с БД
Следующая
Модель данных и схема