Права доступу до аналітичних даних

1. Загальний опис

Одним з елементів механізму розмежування прав доступу до даних аналітичної БД є визначення переліку представлень (views), доступних для кожної зі створених аналітичних ролей у базі даних.

Цей перелік визначається моделювальником даних через додатковий XML-шаблон для Liquibase (детальніше — див. розділ Налаштування доступу до аналітичних представлень).

Після публікації звітності, моделювальник регламенту має визначити відповідно бізнес-логіки реєстру, які ролі й до яких звітів матимуть доступ (детальніше — див. розділ Розмежування доступу до звітів на рівні регламенту).

2. Передумови

Для видачі або відкликання прав запита даних із представлень для певної ролі, мають виконуватися наступні умови:

  • Роль, для якої надається доступ, має існувати на рівні аналітичної бази даних.

  • Представлення, доступ до якого надається, має існувати на рівні аналітичної бази даних.

Порушення цих передумов генеруватиме помилку.

3. Налаштування доступу до аналітичних представлень

3.1. Теги доступу до певних аналітичних представлень

Наступна конструкція надаватиме право запита даних із представлень registry_data_v та registry_info_v для ролі analytics_officer_level_1, а також заборонятиме доступ до цих самих представлень для ролі analytics_officer_level_2.

Приклад 1. XML-шаблон зміни прав доступу для аналітичних ролей
<changeSet author="registry owner" id="grant/revoke analytics rights">
    <ext:grant>
        <ext:role name="analytics_officer_level_1">
            <ext:view name="registry_data"/>
            <ext:view name="registry_info"/>
        </ext:role>
    </ext:grant>
    <ext:revoke>
        <ext:role name="analytics_officer_level_2">
            <ext:view name="registry_data"/>
            <ext:view name="registry_info"/>
        </ext:role>
    </ext:revoke>
</changeSet>

Результатом виконання зазначеного шаблону Liquibase є згенерований нижче SQL-синтаксис, що містить DCL-оператори для визначення доступу до даних.

Приклад згенерованого SQL-синтаксису для зміни прав доступу для аналітичних ролей
GRANT SELECT ON registry_data_v TO analytics_officer_level_1;
GRANT SELECT ON registry_info_v TO analytics_officer_level_1;

REVOKE SELECT ON registry_data_v FROM analytics_officer_level_2;
REVOKE SELECT ON registry_info_v FROM analytics_officer_level_2;
За детальною інформацією щодо створення моделі даних за допомогою шаблонів Liquibase зверніться до сторінки Перелік розширених тегів Liquibase.

3.2. Теги доступу до усіх представлень

Якщо певна роль потребує доступу до всіх наявних аналітичних представлень, то за допомогою тегів grantAll та revokeAll є можливість надати та анулювати права на запит усіх даних, присутніх у представленнях репліки БД.

Ці теги вимагають застосування атрибута runAlways="true" на рівні changeset Liquibase. Якщо вказати значення false, то тег не працюватиме, і в результаті повернеться помилка. Якщо не встановити жодного значення для атрибута, то буде використане значення за замовчуванням, що також призведе до помилки.
Приклад 2. XML-шаблон для надання/видалення прав доступу до всіх аналітичних даних
<changeSet author="registry owner" id="grant all" context="sub" runAlways="true">
    <ext:grantAll>
        <ext:role name="analytics_officer_level_1"/>
    </ext:grantAll>
    <ext:revokeAll>
        <ext:role name="analytics_officer_level_2"/>
    </ext:revokeAll>
</changeSet>

Така конструкція має виконати DCL-оператори надання прав запита даних по кожному з представлень, що існують в аналітичній БД, для ролі analytics_officer_level_1 і анулювання таких прав для ролі analytics_officer_level_2.

Усі набори змін (changeSet) виконуються по черзі. Якщо додати нове аналітичне представлення після того, як виконався changeSet із grantAll або revokeAll, то воно створиться поверх усіх змін відповідно, та не матиме потрібних прав.

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

Іншими словами — спочатку створіть усі Search Conditions, а вже потім надайте необхідні права доступу до них.

4. Розмежування доступу до звітів на рівні регламенту

Для того, щоб налаштувати доступ до звітів Redash для кількох ролей, необхідно визначити окрему папку для кожної ролі в теці reports регламенту реєстру.

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

  • "name": "officer-level-1. Тестовий дашборд-1";

  • "name": "officer-level-2. Тестовий дашборд-1";

    У цьому випадку показано 2 однакові (за id) дашборди, але з різними іменами (name) шляхом додавання префіксів.

Теки повинні відповідати ролям користувачів, для яких надається доступ до дашбордів (наприклад, officer, officer-level-1, officer-level-2 тощо).

Важливо також впевнитися, що назви папок відповідають назвам ролей користувачів, які мають доступ до відповідних дашбордів. Ролі користувачів визначаються у сервісі Keycloak, у реалмі <назва-вашого-реєсру>-officer, тому рекомендується перевірити, що назви папок точно відповідають назвам ролей, які призначені для доступу до цих даних.

Детальніше про ролі користувачів — див. на сторінці Створення окремого користувача та надання прав доступу.

Якщо надати доступ декільком ролям до звітів з однаковими назвами звіту або запита, то в результаті одна з ролей переміститься до архіву і більше не буде показуватися в redash-viewer, а для іншої ролі звіт не показуватиметься.

Так відбувається саме через механізм оновлення звітів:

  1. Перед публікацією звіту знаходиться його попередня версія у базі за його назвою і архівується.

  2. Далі публікується оновлений звіт.

Пошук старого звіту проходить незалежно від ролі, для якої повинен бути опублікований новий звіт.

Припустимо, що для ролі "officer_level_1" додається новий звіт "registry_data", хоча у ролі "officer_level_2" звіт з такою самою назвою вже існує. То для ролі "officer_level_2" звіт зникне (архівується, наче, це стара версія) і публікується новий звіт для ролі "officer_level_1".
Приклад 3. Структура каталогу звітів reports з розмежуванням доступів до звітів за ролями представлено нижче.
structure

  • officer-level-1, officer-level-2, role-3 — назва ролі, що зазначена в налаштуваннях файлів roles/citizen.yaml або roles/officer.yaml;

  • test1.json, test2.json, test3.json — назва звітів Redash, де в налаштуваннях самого файлу параметр name містить назву звіту (тут — registry_data) та назву запита в параметрі query.name (тут — View all report registry_data).

    Зміст файлу зі звітом (дашбордом) 
    {
  "id": 3,
  "name": "registry_data",
  "slug": "test",
  "created_at": "2022-07-07T10:57:27.718",
  "updated_at": "2022-07-07T10:57:54.956",
  "tags": [],
  "widgets": [
    {
      "text": "",
      "options": {
        "parameterMappings": {},
        "isHidden": false,
        "position": {
          "autoHeight": true,
          "sizeX": 3,
          "sizeY": 32,
          "maxSizeY": 1000,
          "maxSizeX": 6,
          "minSizeY": 1,
          "minSizeX": 2,
          "col": 0,
          "row": 0
        }
      },
      "width": 1,
      "dashboard_id": 3,
      "visualization_id": null,
      "visualization": {
        "query_id": null,
        "name": "Table",
        "type": "TABLE",
        "description": "",
        "options": {},
        "query": {
          "id": 9,
          "data_source_id": 1,
          "name": "View all report registry_data",
          "query": "select * from registry.report_koatuu_test1_v;",
          "description": null,
          "options": {
            "parameters": []
          },
          "draft": false
        }
      }
    }
  ],
  "options": null,
  "is_draft": false
}

  • citizen.yaml, officer.yaml — файли з переліком ролей для користувачів реєстру.

Додаткову інформацію щодо доступу до даних та розмежування прав ви можете переглянути за посиланням: