Защита встраиваний Glarus BI¶
Защита встраиваний с помощью аутентификации и авторизации¶
Есть два базовых способа защитить доступ в интернете:
- Аутентификация (Authentication) определяет, кто перед нами (с помощью стандартов вроде JWT или SAML.
- Авторизация (Authorization) определяет, к чему у пользователя есть доступ (например, по стандартам вроде OAuth 2.0).
В этом руководстве будет рассмотрена в основном аутентификация.
Общедоступное встраивание¶
Общедоступное встраивание не использует ни аутентификацию, ни авторизацию. При общедоступном встраивании отображается доступная всем ссылка с уникальной строкой в конце, например:
Строка (в этом примере: 184f819c-2c80-4b2d-80f8-26bffaae5d8b) однозначно идентифицирует ваш запрос или дашборд Glarus BI. Поскольку общедоступные встраивания не используют ни аутентификацию, ни авторизацию, любой, кто получит URL, сможет посмотреть данные.
Пример: фильтры в общедоступных ссылках не защищают данные¶
Как можно злоупотребить общедоступной ссылкой? Допустим, у вас есть дашборд с данными Accounts:
| Account ID | Plan | Status |
|---|---|---|
| 1 | Basic | Active |
| 2 | Basic | Active |
| 3 | Basic | Inactive |
| 4 | Premium | Inactive |
| 5 | Premium | Active |
Вы хотите добавить фильтр "Status = Active" и отображать общедоступную ссылку дашборда во встраивании:
| Account ID | Plan | Status |
|---|---|---|
| 1 | Basic | Active |
| 2 | Basic | Active |
| 5 | Premium | Active |
Чтобы применить и скрыть фильтр "Status = Active", добавьте параметры запроса в конец общедоступной ссылки во встраивании:
https://my-glarus-bi.com/public/dashboard/184f819c-2c80-4b2d-80f8-26bffaae5d8b?status=active#hide_parameters=status
Даже если вы скрыли фильтр во встраивании, кто‑то может взять общедоступную ссылку, которая используется во встраивании, и удалить параметр запроса ?status=active:
Если открыть общедоступную ссылку без параметра запроса, фильтр "Status = Active" исчезнет. Пользователь получит доступ к исходным данным Accounts, включая строки с неактивными аккаунтами.
Статические встраивания авторизуются через JWT¶
Статическое встраивание использует JWT‑схему авторизации для двух задач:
- Подписывать ресурсы (например, URL диаграмм или дашбордов), чтобы только ваше приложение, выполняющее встраивание, могло запрашивать данные у Glarus BI.
- Подписывать параметры (например, фильтры дашборда), чтобы пользователи не могли изменять фильтры и получать доступ к другим данным.
В статическом встраивании нет пользовательских сессий¶
В статическом встраивании Glarus BI не аутентифицирует личность пользователя на своей стороне, поэтому статическое встраивание можно смотреть без создания учётной записи Glarus BI. Однако без учётной записи Glarus BI у системы нет способа «запомнить» пользователя или его сессию, а значит:
- разрешения и RLS не будут работать. Если вам нужно ограничить доступ к чувствительным данным, для каждого статического встраивания необходимо настроить заблокированные параметры;
- любые выбранные значения фильтров в статическом встраивании будут сбрасываться после истечения срока действия подписанного JWT;
- любое использование статического встраивания будет отображаться в коллекции "Аналитика использования" как "Внешний пользователь".
Безопасность в статическом встраивании¶
Статическое встраивание гарантирует только авторизованный доступ к данным Glarus BI (то есть вы решаете, что доступно).
Если вы хотите защищать статические встраивания на основании личности пользователя (то есть вы решаете, кто получает доступ к чему), вам нужно настроить собственный процесс аутентификации и вручную связать его с заблокированными параметрами для каждого статического встраивания. Учтите, что заблокированные параметры по сути являются фильтрами, поэтому в статическом встраивании можно настроить ограничения только на уровне строк.
Статическое встраивание с JWT‑авторизацией¶
Диаграмма показывает, как встраивание защищается подписанным JWT:
- Прибытие посетителя: ваш фронтенд получает запрос показать URL для встраивания Glarus BI.
- Подписанный запрос: ваш бэкенд генерирует URL для встраивания с подписанным JWT. Подписанный JWT должен кодировать параметры запроса, которые вы используете для фильтрации данных.
- Ответ: бэкенд Glarus BI возвращает данные на основе параметров запроса, закодированных в подписанном JWT.
- Успех: ваш фронтенд отображает встроенную страницу Glarus BI с корректными данными.
Пример: защита данных через заблокированные параметры в статическом встраивании¶
В примере с общедоступным встраиванием показано, как можно злоупотребить общедоступной ссылкой, изменяя параметры запроса.
Вернёмся к примеру с Accounts:
| Account ID | Plan | Status |
|---|---|---|
| 1 | Basic | Active |
| 2 | Basic | Active |
| 3 | Basic | Inactive |
| 4 | Premium | Inactive |
| 5 | Premium | Active |
Напомним: в общедоступном встраивании можно фильтровать данные, добавляя параметры запроса в конец URL для встраивания.
| Account ID | Plan | Status |
|---|---|---|
| 1 | Basic | Active |
| 2 | Basic | Active |
| 5 | Premium | Active |
В статическом встраивании есть возможность «заблокировать» фильтр, закодировав параметр запроса в подписанном JWT. Например, настроив фильтр "Status = Active" как заблокированный параметр. Параметр ?status=active будет закодирован в подписанном JWT, поэтому его не будет видно и его нельзя будет изменить в URL статического встраивания:
Если кто‑то попробует добавить (неподписанный) параметр запроса в конец URL статического встраивания, например так:
Glarus BI отклонит этот неавторизованный запрос данных, и строки с неактивными аккаунтами останутся скрыты во встраивании.
Пример: передача атрибутов пользователя в заблокированный параметр¶
Допустим, вы хотите дать клиентам доступ к таблице Accounts, чтобы они могли находить строку по Account ID.
| Account ID | Plan | Status |
|---|---|---|
| 1 | Basic | Active |
| 2 | Basic | Active |
| 3 | Basic | Inactive |
| 4 | Premium | Inactive |
| 5 | Premium | Active |
Если вы не хотите создавать учётную запись Glarus BI для каждого клиента, понадобится:
- встраиваемый дашборд с данными Accounts;
- заблокированный параметр для фильтра по Account ID;
- процесс входа в ваше приложение (веб‑приложение, в которое требуется встроить Glarus BI.
Процесс может выглядеть так:
- Клиент входит в ваше веб‑приложение.
- Бэкенд приложения находит
account_idклиента по email, который использовался при входе. - Бэкенд вашего приложения использует секретный ключ, чтобы сгенерировать URL для встраивания с подписанным JWT. Подписанный JWT кодирует параметры запроса так, чтобы фильтровать дашборд Accounts по условию
Account ID = account_id. - Glarus BI возвращает отфильтрованный дашборд по URL статического встраивания.
- Фронтенд приложения отображает отфильтрованный дашборд в iframe.
Примеры кода см. в эталонном приложении для статического встраивания Metabase (ссылка на github.com).