Доступ "Через роль БД"¶

На этой странице описан уровень разрешения "Просмотр данных", который называется "Через роль БД".

Через роль БД позволяет администраторам «делегировать» разрешения на просмотр данных ролям в вашей базе данных. Администраторы могут сопоставлять атрибуты пользователя с ролями и разрешениями, определёнными в базе данных. Если пользователь состоит в группе, где просмотр данных осуществляется через роль БД, он сможет просматривать и запрашивать данные на основе разрешений роли, указанной в его атрибуте пользователя.

Базы данных, которые поддерживают доступ "Через роль БД"¶

"Через роль БД" поддерживают следующие базы данных:

ClickHouse;
MySQL;
PostgreSQL. Если вы используете представления (views) в PostgreSQL, то политики безопасности на уровне строк (RLS) для представлений будут работать только в PostgreSQL версии 15 и выше;
Redshift;
Snowflake;
SQL Server.

"Через роль БД" и разграничение доступа к строкам¶

"Через роль БД" задаёт разрешения и для SQL‑редактора, и для конструктора запросов¶

"Через роль БД" работает на уровне базы данных. В СУБД установка роли до выполнения запроса может изменить результат, так как роль определяет разрешения, которые база данных должна использовать при выполнении SQL‑выражений.

Безопасность строк и столбцов применима только к запросам конструктора¶

Безопасность строк и столбцов работает на уровне Glarus BI. Так как Glarus BI не может разбирать код прямых запросов, чтобы определить, какие данные пользователь может видеть, безопасность строк и столбцов применяется только к запросам, составленным в конструкторе запросов (где Glarus BI может интерпретировать запросы).

Пример сценария для доступа "Через роль БД"¶

Предположим, есть таблица People, где хранятся строки с учётными записями клиентов из всех регионов. Допустим, вы хотите, чтобы ваш отдел продаж в Орле мог:

создавать запросы и через конструктор запросов, и через редактор прямых SQL‑запросов;
видеть только те строки клиентов в таблице People, которые относятся к Орлу.

Сначала следует настроить доступ к базе данных в СУБД, создав роль с политикой. Затем в Glarus BI потребуется установить "Просмотр данных" для этой базы данных в значение "Через роль БД", чтобы при выполнении запросов Glarus BI использовал эту роль и ограничивал просмотр данных.

Настройка подключения¶

Чтобы "Через роль БД" работала, нужно сначала настроить роли в базе данных, которые Glarus BI будет имперсонировать, а затем настроить Glarus BI так, чтобы он применял эти роли, когда пользователи просматривают данные или выполняют запросы.

Настройка подключения в Glarus BI к базе данных¶

"Через роль БД" использует роли базы данных для выполнения запросов, но при этом всё равно нужна роль по умолчанию: её будут использовать операции вроде синхронизации, сканирования и снятия слепков. Поэтому учётная запись, которую Glarus BI использует для подключения к базе данных, должна иметь доступ ко всему, что может понадобиться любой группе в Glarus BI, — так как именно эту учётную запись Glarus BI использует для синхронизации информации о таблицах.

Далее вы можете создать в базе данных роли с более ограничительным доступом (например, с доступом на уровне строк или таблиц). Когда такая роль будет передана базе данных "через роль БД", СУБД вернёт подмножество данных или вообще запретит выполнение запроса.

Примечание

Для работы "Через роль БД" с базами данных Redshift учётная запись пользователя, которую Glarus BI использует для подключения к вашей базе данных Redshift, должна быть суперпользователем, так как Glarus BI потребуется выполнить команду SET SESSION AUTHORIZATION (amazon.com), которую может выполнять только суперпользователь базы данных.

В базе данных настройте роли¶

В вашей СУБД (не в Glarus BI):

Создайте новую роль базы данных (в Redshift это будет новый пользователь).
Выдайте этой роли те разрешения, которые должны быть у пользователей при использовании "Через роль БД".

Точные шаги по созданию ролей и выдаче разрешений зависят от вашей СУБД, поэтому обратитесь к документации вашей базы данных. Также вам может помочь наша статья про пользователей, роли и привилегии.

Например, если вы используете PostgreSQL, то SQL ниже создаст роль orel_sales_team и разрешит этой роли выбирать только те строки из таблицы people, где значение в столбце region равно Orel:

CREATE ROLE orel_sales_team;

GRANT
SELECT ON ALL TABLES IN SCHEMA PUBLIC TO orel_sales_team;


CREATE POLICY orel ON people
FOR
SELECT TO orel_sales_team USING (region = 'Orel');


ALTER TABLE people ENABLE ROW LEVEL SECURITY;

Для Snowflake отключите secondary roles при использовании "Через роль БД"¶

Чтобы "Через роль БД" корректно работала с базами данных Snowflake, учётная запись, которую Glarus BI использует для подключения к Snowflake, должна быть настроена с отключёнными secondary roles. Отключить secondary roles можно так:

ALTER USER metabase_user SET DEFAULT_SECONDARY_ROLES = ();

Если secondary roles не отключить, то каждая имперсонируемая роль также получит разрешения всех остальных ролей, которые вы выдали учётной записи, которую Glarus BI использует для подключения к Snowflake.

Настройте группу в Glarus BI¶

Разрешения в Glarus BI, включая "Через роль БД", управляются через группы, поэтому вам нужно:

Создать новую группу (или выбрать существующую).
Добавить пользователей в эту группу.

Рекомендуем создать тестового пользователя и добавить его в группу, чтобы позже проверить, что "Через роль БД" работает корректно.

Назначьте пользователям в группе атрибут пользователя¶

Чтобы сопоставить пользователей в группе с ролью, созданной в базе данных, используйте атрибут пользователя.

Назначьте пользователям в группе атрибут пользователя:

Ключ атрибута может быть любым.
Значение атрибута должно совпадать с нужной ролью базы данных для каждого пользователя.

Настройка атрибута пользователя для "Через роль БД"

Например, если вы создали роль orel_sales_team в базе данных с доступом к подмножеству данных, относящихся к команде продаж в Орле (как в примере выше), вы можете добавить атрибут пользователя db_role (или любой другой ключ) и указать значение orel_sales_team в качестве значения.

Некоторые СУБД учитывают регистр, поэтому убедитесь, что значение атрибута и имя роли в базе данных совпадают точно.

Пользователи в одной группе могут иметь разные значения атрибутов, но ключ атрибута должен быть одинаковым.

Включите "Через роль БД"¶

В Glarus BI нажмите Cmd/Ctrl + K, чтобы открыть палитру команд, и найдите Разрешения, или перейдите в Управление > Разрешения > Данные.
Выберите группу, которую нужно связать с ролью базы данных.
Выберите базу данных, для которой вы настраиваете доступ.
В столбце Просмотр данных для этой базы данных выберите "Через роль БД". Эта опция будет доступна только если вы уже создали атрибут пользователя.

Выбор "Через роль БД" в разрешениях

Если у группы "Все пользователи" для этой базы данных задан более разрешающий доступ (например, "Возможен"), вы увидите предупреждение, потому что Glarus BI выдаёт пользователям наиболее разрешающий доступ по всем их группам. Перед настройкой "Через роль БД" убедитесь, что вы ограничили доступ группы "Все пользователи" к этой базе данных (см. разрешения на данные).

В выпадающем списке атрибутов пользователя выберите тот атрибут, который сопоставляется с ролью базы данных, которую вы хотите использовать при выполнении запросов.
Сохраните изменения.

Не забудьте также настроить разрешение "Создание запросов" для группы и базы данных. Например, если вы хотите, чтобы пользователи могли писать SQL при использовании имперсонируемых ролей, нужно установить "Создание запросов" в значение "Конструктор запросов и прямой запрос".

Проверьте, что "Через роль БД" работает¶

Администраторы не смогут проверить работу "Через роль БД" из своей учётной записи, поэтому создайте тестового пользователя, добавьте его в группу и задайте ему атрибуты пользователя.

Чтобы проверить, что "Через роль БД" работает:

Если для тестового пользователя "Создание запросов" установлено в значение "Конструктор запросов и прямой запрос", создайте SQL‑запрос и убедитесь, что тестовый пользователь видит только нужные данные.

Например, для роли orel_sales_team из примера выше выполните:

SELECT * FROM people;

и убедитесь, что тестовый пользователь видит только данные из Орла.

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

Пользователи в группе с "Через роль БД" могут иметь различные разрешения¶

Glarus BI будет использовать ту роль, которую вы укажете в атрибуте пользователя для каждого пользователя. Например, если вы выбрали атрибут db_role, у одного пользователя db_role может быть продажи, у другого — менеджмент или другое значение, которое сопоставляется с действительной ролью в вашей базе данных.

Используйте "Через роль БД", чтобы настроить доступ к SQL на уровне строк¶

Вы можете использовать "Через роль БД", чтобы дать пользователям доступ к редактору прямых запросов и при этом ограничить их доступ к данным на основе конкретной роли базы данных. Это может быть не только доступ на уровне таблиц, но и доступ на уровне строк — или любой другой доступ, который вы зададите разрешениями роли в базе данных. Вы можете получить эффект, похожий на безопасность строк и столбцов, но при этом разрешить пользователям работать с SQL. Отличие в том, что вместо настройки безопасности строк и столбцов в Glarus BI вам нужно настроить безопасность на уровне строк через разрешения, выданные роли в вашей базе данных.

Если вместо этого вы хотите дать группе SQL‑доступ только к части схем или таблиц в базе данных, вы можете создать дополнительную роль в базе данных, которая включает только подмножество таблиц (или даже отдельный доступ на уровне строк), а затем связать атрибут пользователя с "Через роль БД". По сути, Glarus BI возьмёт значение атрибута пользователя и передаст его как строку в команду SET ROLE или USE ROLE для базы данных до выполнения запроса.

"Через роль БД" подключения не применяется к пользователям в группе администраторов Glarus BI, так как их более разрешительные привилегии имеют приоритет.

Glarus BI предоставляет пользователям наиболее разрешительный доступ к данным во всех их группах¶

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

группа А с доступом "Через роль БД", который ограничивает, что пользователь может видеть;
группа Б с "Просмотр данных" = "Возможен" и "Создание запросов" = "Конструктор запросов и прямой запрос".

Более разрешительный доступ группы Б будет иметь приоритет и перекроет ограничения "Через роль БД".

Администраторы не увидят эффект "Через роль БД"¶

Администраторы никогда не увидят эффекты "Через роль БД", так как их разрешения перекрывают разрешения любых других групп, в которые они входят.

В группе "Администраторы" по умолчанию "Просмотр данных" = "Возможен" для всех баз данных. А так как Glarus BI выдаёт наиболее разрешительный доступ по всем группам пользователя, у любого администратора будет "Возможен", а не "Через роль БД", для этой базы данных.

Чтобы протестировать "Через роль БД", создайте тестового пользователя, задайте ему атрибут пользователя со значением роли базы данных и добавьте пользователя в группу с "Через роль БД". Затем войдите под тестовым пользователем и проверьте доступ к данным.