Как структурировать представления в bigquery для эффективного управления доступом

Question

В BigQuery вы предоставляете пользователям / ролям (или авторизованным представлениям) доступ на уровне набора данных, а не на уровне представления / таблицы.Задача, которую я хочу решить, - это как управлять контролем доступа в больших запросах, когда у меня есть сотни таблиц и представлений и много разных ролей / отделов, которые должны иметь доступ как к представлениям, общим для всех отделов, так и представлениям только для определенной роли / отдела?

Пример: допустим, у меня есть исходный набор данных с исходными таблицами A-> D и три представления для каждой таблицы, представляющие различные поля в зависимости от чувствительности данных 1-> 3.Кроме того, у меня есть три роли (синий, зеленый, красный).Если бы я мог управлять доступом на уровне таблицы, это выглядело бы так:

Представление: роли

• A1: синий, красный

• A2: красный

• A3: красный

• B1: синий, зеленый, красный

• B2: зеленый, красный

• B3: красный

• C1: зеленый, красный

• C2: зеленый, красный

• C3: красный

• D1: красный

• D2:Красный

• D3: Красный

Учитывая эти требования, я не могу создавать наборы данных только на основе чувствительности (1-3) или источника (AD) и управлять доступом на основе этого.Единственное решение, которое я вижу в этом, - это создание набора данных для каждой роли.Это можно сделать вручную, если количество ролей и представлений немного, но при управлении более 10 ролями и более 50 представлений это становится более сложным.

Единственное решение, которое я могу предложить, - это настройка CI / CD (облачная сборка) с файлами / файлами, определяющими наборы данных (то есть роли), зависимости и DDL-оператор / ы.Позволяет скрипту / программе выполнять итерации по файлу / файлам, генерировать представления и предоставлять доступ (авторизованное представление) к источнику.Файл примера:

{"roles":["crm_analyst", "admin", "customer_service_agent"],
"ddl":"CREATE VIEW `myproject.'{role}'.newview` AS SELECT column_1, column_2, column_3 FROM myproject.mydataset.myview",
"dependencies":"myproject.mydataset.myview"}

Как другие компании решают эту проблему?Существуют крупные банки, которые перешли на большие запросы, в которых должно быть множество отделов и различная чувствительность наборов данных.

Answer 1

В итоге я написал скрипт на python, который читает определения представлений из json-файлов, а затем генерирует наборы данных и представления и дает правильные права доступа.Решение является несколько грубым и может использовать отображение зависимостей (когда представление запрашивает другое представление) вместо текущего решения, повторяющего представления, пока не будут сгенерированы все представления, или сценарий больше не сможет генерировать представления (нарушенные зависимости).Сценарий генерирует два набора данных для каждой группы, один с READER (суффикс '_ro') и один с WRITER (суффикс '_rw'), чтобы убедиться, что представления, сгенерированные командой данных, не могут быть изменены, и в то же время дают песочницу длягруппа.Группа должна быть группой электронной почты, а имя набора данных будет локальной частью адреса электронной почты.Сценарий выполняется сборкой облака Google и запускается нажатием на наше репозиторий github.

Пример определения представления (путь: views / view_test.json)

{
    "groups":["developers@datahem.org", "analysts@datahem.org"],
    "sql":"SELECT * FROM `{project}.shared_views.test_view`"
}

Создает следующие наборы данных (access) и views:

analysts_ro (analysts@datahem.org:READER):
- view_test

analysts_rw (analysts@datahem.org:WRITER):
(empty)

developers_ro (developers@datahem.org:READER):
- view_test

developers_rw (developers@datahem.org:WRITER):
(empty)

shared_views (analysts_ro.view_test:None, developers_ro.view_test:None):
- test_view

Я сделал скрипт python доступным на github в качестве открытого исходного кода как часть datahem , не стесняйтесь клонировать, улучшать и использоватьдля ваших собственных целей.

Answer 2

Другой вариант - настроить доступ на уровне строк и поместить все представления в один и тот же набор данных.

Макет таблицы access_control (пользователь, группы пользователей), например, для назначения:

SELECT 'userA@datahem.org' as user_name, ['developer','analyst'] as user_groups
UNION ALL
SELECT 'userB@datahem.org' as user_name, ['developer'] as user_groups

И создайте представление, которое имеет контроль доступа на уровне строк, добавив статический столбец с массивом user_groups и объединитесь с «таблицей» access_control, где хотя бы одна из групп текущего пользователя соответствует allow_groups:

SELECT c.* EXCEPT(allowed_groups) FROM (
  SELECT OrderReference, Date, ['developer', 'analyst'] AS allowed_groups 
  FROM `project.dataset.orders`) as c
INNER JOIN (
  SELECT user_name, user_group 
  FROM  `project.access.access_control`, UNNEST(user_groups) as user_group 
  WHERE SESSION_USER() = user_name) g
ON g.user_group IN UNNEST(c.allowed_groups)

Это хорошее решение, однако оно предоставляет пользователю все виды, даже если пользователь не имеет к нему доступа.Кроме того, пользователь сможет запускать запросы к представлению, к которому у него нет доступа (создание стоимости), но не получит никаких результатов обратно.С точки зрения удобства использования (только с отображением видов, к которым у пользователя есть доступ) мы выбрали решение, отмеченное выше.

Answer 3

Совместное использование наборов данных с группами вместо ролей.Иметь группу для каждой «роли»;красный, зеленый и синий.Создание наборов данных, имеющих только виды.Поделитесь исходными данными dataset.tables с представлениями.

• RED_DATASET: общий доступ: RED_GROUP ВИДЫ: A1-A3, B1-B3, C1-C3, D1-D3

• BLUE_DATASET: общий доступ:BLUE_GROUP VIEWS: A1, B1

• GREEN_DATASET: общий: GREEN_GROUP VIEWS: B1-B2, C1-C2

Обратите внимание, что представление B1 будет иметьтри его копии (по одной в каждом «view_dataset») и будут определены с помощью того же запроса.

Это рекомендуемая практика относительно контроля доступа для просмотра.