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

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

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

• Анонимный доступ — включен по умолчанию и доступен сразу после установки кластера.
• Аутентификация с использованием стороннего IAM-провайдера, например Yandex Identity and Access Management.
• Аутентификация по логину и паролю.
• Аутентификация с использованием LDAP каталога.

Аутентификация с использованием стороннего 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 каталог используется только для проверки пары логин/пароль.

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

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

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

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

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

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

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

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

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