Аутентификация и авторизация

Эта тема направлена на предоставление последовательного руководства по лучшим практикам разработки вашего собственного рабочего процесса аутентификации и авторизации.

Подробные инструкции по каждой операции, упомянутой ниже, см. по ссылкам в разделе См. также.

Реальный корпоративный сценарий

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

• Упрощенное управление пользователями: Администраторам больше не нужно вручную создавать или удалять пользователей и назначать разрешения в нескольких системах. Управление жизненным циклом пользователей (например, прием/увольнение) становится бесшовным и удобным для аудита.
• Повышенная безопасность: Механизм единого входа (SSO) устраняет необходимость для пользователей управлять несколькими учетными данными, уменьшая поверхность атаки.
• Контроль доступа на основе ролей: Разрешения доступа обычно привязаны к роли или отделу пользователя. Хорошо структурированная система идентификации обеспечивает более простые и точные решения по авторизации.

Пример

Предположим, что три новых сотрудника присоединяются к разным отделам SaaS-компании: один специалист по маркетингу и два архитектора решений.

• Организационно они принадлежат к разным командам.
• С точки зрения идентификации их email-аккаунты служат учетными данными для входа на внутренние платформы.
• По правам доступа каждому из трех предоставлен доступ к различным платформам:
  • Специалист по маркетингу может войти в backend Hubspot для просмотра новых лидов.
  • Архитекторы решений могут получить доступ к консоли сервисов и управлять сервисами для назначенных клиентов.

Хотя все трое используют одного и того же провайдера идентификации, их права доступа строго соблюдаются:

• Специалист по маркетингу имеет доступ только к Hubspot.
• Архитекторы решений могут получить доступ к консоли сервисов, но они не могут получить доступ к сервису для пользователей, к которым они не назначены. Они также не могут получить доступ к Hubspot.

Три уровня контроля доступа

Этот пример подчеркивает три ключевых компонента в корпоративном потоке идентификации и доступа:

1. Аутентификация идентичности – "Я Петр, проверенный сотрудник SaaS-компании."
2. Аутентификация доступа – "Как архитектор решений, я уполномочен войти в консоль сервисов." (Не все проверенные сотрудники должны иметь доступ ко всем сервисам.)
3. Авторизация действий – "Как клиент SaaS-компании, я могу просматривать информацию нашего собственного сервиса, но не других клиентов."

В контексте базы данных

Эти уровни контроля доступа также применимы к системе баз данных:

1. Проверка идентичности: Подтверждение, что пользователь является действительным сотрудником со своим собственным паролем.
2. Аутентификация доступа: Проверка, что пользователь или его группа имеет разрешение войти в конкретный cluster.
3. Авторизация операций: Проверка, может ли пользователь выполнить запрос, загрузить данные и т.д.

Как вы можете видеть, аутентификация и авторизация тесно связаны на практике. Запрос аутентификации пользователя часто подразумевает более широкие требования к контролю доступа. Поэтому важно понимать полный поток доступа.

Ключевые концепции

LDAP

Lightweight Directory Access Protocol (LDAP) — это протокол для доступа и поддержки распределенной информации каталогов. Вы можете думать о нем как о глобальной адресной книге вашей организации:

• Каждый пользователь имеет уникальный путь (Distinguished Name, DN).
• LDAP хранит базовую информацию о пользователях, включая пароли.
• LDAP также управляет структурами групп и членством.
• Запросы ldapsearch могут извлекать пользователей или группы.

LDAP может использоваться:

• Как источник аутентификации (для проверки имен пользователей и паролей).
• Как провайдер информации о группах для контроля доступа.

UNIX Groups

Иногда пользователи дублируют группы LDAP локально (на хостовой ОС) по соображениям безопасности или изоляции, избегая прямого взаимодействия с внешними серверами LDAP. Эти локальные UNIX-группы могут использоваться для аутентификации или контроля доступа.

OAuth, OIDC и JWT

подсказка

Краткое объяснение терминов

• ID Token: Подтверждение личности (я — это я).
• Access Token: Подтверждение права доступа к определённым ресурсам (я могу делать определённые вещи).
• OAuth 2.0: Фреймворк авторизации, предоставляющий access-токены.
• OIDC: Слой аутентификации поверх OAuth. Предоставляет ID и Access токены.
• JWT: Формат токена. Используется как OAuth, так и OIDC.

Практическое применение:

• OAuth-вход: Перенаправляет на внешнюю страницу входа (например, Google), затем обратно в cluster. Требует доступа к браузеру и предварительной настройки redirect URL.
• JWT-вход: Пользователь передаёт токен напрямую в cluster, что требует предварительной настройки публичного ключа или endpoint.

Возможности

Система поддерживает все три уровня контроля доступа:

1. Аутентификация пользователя – "Я тот, за кого себя выдаю."
2. Авторизация входа – "Мне разрешено получить доступ к этому cluster." (Это зависит от индивидуального или группового членства.)
3. Авторизация операций – "Я могу выполнить этот запрос или загрузить этот набор данных." (Авторизация может быть основана на идентичности или групповой принадлежности.)

Начиная с версии 3.5, Selena предоставляет модульную, компонуемую модель для поддержки различных комбинаций компонентов управления идентификацией и доступом.

Соответствие функций

С точки зрения функциональности:

1. Провайдер аутентификации – Поддерживаемые протоколы: Native user, LDAP, OIDC и OAuth 2.0.
2. Провайдер групп – Поддерживаемые источники: LDAP, операционная система и файловая конфигурация.
3. Система авторизации – Поддерживаемые системы: Native RBAC & IBAC и Apache Ranger.

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

Сравнение поддерживаемых режимов аутентификации:

Метод	CREATE USER (Нативный пользователь)	CREATE SECURITY INTEGRATION (Временный пользователь на основе сессии)
Описание	Вручную создает пользователей в cluster. Вы можете связать их с внешними системами аутентификации. Пользователь существует явно в cluster.	Определяет интеграцию внешней аутентификации. Cluster не хранит никакой информации о пользователях. Вы можете опционально объединить это с провайдером групп для определения разрешенных пользователей.
Процесс входа	Пользователи должны быть предварительно созданы в cluster. Во время входа пользователь аутентифицируется через Selena или через настроенную внешнюю систему аутентификации (например, LDAP). Только предварительно созданные пользователи могут войти.	При входе Selena аутентифицирует пользователя с использованием внешних систем идентификации. В случае успеха создается временный "временный пользователь" с областью действия сессии внутренне. Этот пользователь удаляется после окончания сессии.
Процесс авторизации	Поскольку пользователи существуют в cluster, разрешения могут быть назначены заранее с использованием либо нативной системы авторизации, либо Apache Ranger.	Хотя пользователи не сохраняются, вы можете предопределить сопоставления ролей с группами. Когда пользователь входит, система назначает роли на основе их группы, включая RBAC. Apache Ranger также может использоваться параллельно.
Плюсы и минусы, Случаи использования	Плюсы: Полная гибкость—поддерживает как нативные, так и внешние системы авторизации. Минусы: Требует ручных усилий для создания пользователей, что может быть обременительным. Рекомендуется для: Небольших пользовательских баз или случаев, когда cluster обрабатывает контроль доступа.	Плюсы: Легко настраивается; требуется только конфигурация внешней аутентификации и определения разрешенных групп. Рекомендуется для: Идеально для больших пользовательских баз с сопоставлениями роль-группа.

Эти режимы аутентификации могут сосуществовать. Когда пользователь пытается войти:

1. Cluster сначала проверяет, существует ли пользователь как нативный пользователь, и пытается аутентифицировать соответственно.
2. Если пользователь не найден, cluster продолжает по authentication_chain, как определено в конфигурации.

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

Вариант 1: Создание нативного пользователя с внешней системой аутентификации

Например, вы можете использовать следующий синтаксис для создания нативного пользователя с LDAP:

CREATE USER <username> IDENTIFIED WITH authentication_ldap_simple AS 'uid=tom,ou=company,dc=example,dc=com';

Затем вы можете GRANT привилегии или роли пользователю или делегировать авторизацию внешним системам, таким как Apache Ranger.

Вариант 2: Использование интеграции безопасности с внешней системой аутентификации

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

CREATE SECURITY INTEGRATION <security_integration_name> 
PROPERTIES (
    "type" = "authentication_ldap_simple",
    "authentication_ldap_simple_server_host" = "",
    "authentication_ldap_simple_server_port" = "",
    "authentication_ldap_simple_bind_base_dn" = "",
    "authentication_ldap_simple_user_search_attr" = ""
    "authentication_ldap_simple_bind_root_dn" = "",
    "authentication_ldap_simple_bind_root_pwd" = "",
    "authentication_ldap_simple_ssl_conn_allow_insecure" = "{true | false}",
    "authentication_ldap_simple_ssl_conn_trust_store_path" = "",
    "authentication_ldap_simple_ssl_conn_trust_store_pwd" = "",
    "comment" = ""
);

После этого вам нужно настроить параметр FE authentication_chain и включить интеграцию безопасности для вашего cluster.

ADMIN SET FRONTEND CONFIG (
    "authentication_chain" = "<security_integration_name>[... ,]"
);

Провайдер групп (необязательно, но рекомендуется)

Информация о группах в cluster отделена как от систем аутентификации, так и от систем авторизации. Она служит общим слоем, который может быть независимо настроен и затем использован как для контроля входа, так и для контроля доступа.

Как используются группы

• Этап аутентификации

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

• Этап авторизации

  Членство в группе автоматически учитывается во время авторизации. Если привилегии предоставлены группе, все пользователи в этой группе унаследуют разрешения при проверках доступа.

Примечания по конфигурации

• При настройке провайдера групп вы должны указать:
  • Группы, используемые для определения кто может войти (область входа)
  • Группы, используемые для определения кто может получить доступ к конкретным ресурсам (авторизация)
• Важно: Идентификатор пользователя (например, имя пользователя или ID), возвращаемый провайдером групп, должен совпадать с идентификатором, используемым во время аутентификации и авторизации. Несогласованные идентификаторы приведут к сбоям разрешений или входа.

Пример

Следующий пример основан на LDAP.

1. Создайте провайдера групп.

   -- LDAP Group Provider
   CREATE GROUP PROVIDER <group_provider_name> 
   PROPERTIES (
       "type" = "ldap",
       ldap_info,
       ldap_search_group_arg,
       ldap_search_attr,
       [ldap_cache_attr]
   )
   
   ldap_info ::=
       "ldap_conn_url" = "",
       "ldap_bind_root_dn" = "",
       "ldap_bind_root_pwd" = "",
       "ldap_bind_base_dn" = "",
       ["ldap_conn_timeout" = "",]
       ["ldap_conn_read_timeout" = ""]
   
   ldap_search_group_arg ::= 
       { "ldap_group_dn" = "" 
       | "ldap_group_filter" = "" }, 
       "ldap_group_identifier_attr" = ""
   
   ldap_search_user_arg ::=
       "ldap_group_member_attr" = "",
       "ldap_user_search_attr" = ""
   
   ldap_cache_arg ::= 
       "ldap_cache_refresh_interval" = ""

2. Интегрируйте провайдера групп с интеграцией безопасности.

   ALTER SECURITY INTEGRATION <security_integration_name> SET
   (
       "group_provider" = "",
       "permitted_groups" = ""
   )

3. Интегрируйте провайдера групп с системой авторизации. Вы можете использовать либо нативную авторизацию, либо Apache Ranger.

   • Нативная авторизация:

     Роли могут быть назначены группам. При входе пользователи автоматически получают роли на основе членства в группе.

     GRANT role TO EXTERNAL GROUP <group_name>

   • Apache Ranger:

     Как только пользователь входит, Selena передает информацию о группах в Ranger для оценки политики.

Авторизация

Selena поддерживает как внутренние, так и внешние механизмы авторизации, которые могут использоваться независимо или в комбинации:

• Внутренняя авторизация

  Selena предоставляет встроенную систему RBAC (Role-Based Access Control — контроль доступа на основе ролей) и IBAC (Identity-Based Access Control — контроль доступа на основе идентичности).

  • RBAC: Назначает роли пользователям или группам и предоставляет привилегии этим ролям.
  • IBAC: Предоставляет привилегии непосредственно пользователям.

• Внешняя авторизация

  Selena интегрируется с Apache Ranger для поддержки централизованного и унифицированного управления авторизацией.

Apache Ranger может использоваться либо как интегральное решение само по себе, либо вместе с нативной системой авторизации Selena.

• Полная авторизация Ranger Как внутренние таблицы, так и внешние таблицы (например, Hive) авторизуются через Ranger.
  • Разрешения для внутренних таблиц используют плагин Selena для Ranger.
  • Разрешения для внешних таблиц могут управляться либо через плагин Selena, либо через другие плагины внешних сервисов (например, плагин Hive).
• Гибридная авторизация
  • Внутренние таблицы: Авторизуются нативной системой Selena (RBAC/IBAC).
  • Внешние таблицы: Авторизуются через Ranger. Разрешения для внешних таблиц по-прежнему могут управляться либо с использованием плагина Selena, либо через соответствующий внешний сервис (например, Hive, HDFS).

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

Комбинированные решения

Вы можете выбрать решение в зависимости от того, как вы хотите завершить свой рабочий процесс аутентификации и авторизации.

Решение 1: Внешняя аутентификация + Внешняя авторизация

Вы можете полностью использовать внешние системы аутентификации и авторизации для контроля входа и разрешений доступа к cluster. Общий процесс следующий:

1. Используйте интеграцию безопасности для установления соединения с внешней системой аутентификации.
2. Настройте необходимую информацию о группах для аутентификации и авторизации в провайдере групп.
3. Определите группу(ы), которым разрешено входить в cluster, в интеграции безопасности. Пользователи, принадлежащие к этим группам, получат доступ для входа.
4. Создайте сервис Selena в Apache Ranger для управления контролем доступа как для внутренних, так и для внешних таблиц. Для внешних таблиц вы также можете повторно использовать существующие сервисы для авторизации.
5. Когда пользователь отправляет запрос, система отправит идентификатор пользователя вместе с его членством в группах (как настроено в провайдере групп) в Ranger для авторизации.
6. Если проверка авторизации пройдена, система продолжит выполнение запроса.

примечание

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

Решение 2: Внешняя аутентификация (нативный пользователь) + Внутренняя авторизация

Если вы предпочитаете использовать встроенную систему авторизации, но все еще полагаетесь на внешнюю аутентификацию, вы можете следовать этому подходу:

1. Вручную создайте пользователей и укажите метод внешней аутентификации для каждого пользователя.
2. После создания пользователя используйте стандартные операторы GRANT для назначения ролей или привилегий.
3. После аутентификации пользователь будет авторизован на основе нативной системы разрешений cluster.

подсказка

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

Решение 3: Внешняя аутентификация (внешняя идентичность) + Внутренняя авторизация

Если вы предпочитаете использовать встроенную систему авторизации Selena, но все еще полагаетесь на внешнюю аутентификацию, вы можете следовать этому подходу:

1. Используйте интеграцию безопасности для установления соединения с внешней системой аутентификации.
2. Настройте необходимую информацию о группах для аутентификации и авторизации в провайдере групп.
3. Определите группу(ы), которым разрешено входить в cluster Selena, в интеграции безопасности. Пользователи, принадлежащие к этим группам, получат доступ для входа.
4. Создайте необходимые роли в Selena и предоставьте их внешним группам.
5. Когда пользователь пытается войти, он должен как пройти аутентификацию, так и принадлежать к авторизованной группе. После успешного входа Selena автоматически назначит соответствующие роли на основе членства в группе.
6. Во время выполнения запроса Selena будет применять внутреннюю авторизацию на основе RBAC как обычно.
7. Кроме того, вы можете объединить Ranger с этим решением. Например, используйте нативный RBAC Selena для авторизации внутренних таблиц и используйте Ranger для авторизации внешних таблиц. При выполнении авторизации через Ranger, Selena все равно передаст идентификатор пользователя и соответствующую информацию о группах в Ranger для контроля доступа.

Смотрите также

• Аутентификация
  • Нативная аутентификация
  • Интеграция безопасности
  • LDAP-аутентификация
  • OAuth 2.0 аутентификация
  • Аутентификация JSON Web Token
• Провайдер групп
• Авторизация
  • Нативная авторизация
  • Плагин Apache Ranger