Когда бизнес-аналитика внедряется как корпоративный инструмент, ее пользователями становятся сотни или даже тысячи людей из разных подразделений. Кроме этого нередко результаты прогнозов, расчетов и визуализаций все чаще выкладывают прямо на порталы или открывают к ним доступ без авторизации, чтобы сторонние наблюдатели могли получить важную для себя информацию. Все это порождает проблемы конфиденциальности, которые раньше решались с помощью дублирования данных и создания нескольких контуров BI. Но, как говорится, «есть способ лучше»! Сегодня мы поговорим про механизм Row Level Security (RLS), который позволяет и BI предложить сразу всем, и доступ разграничить, и не плодить лишние сущности. Ну а подопытным, которому мы будем ограничивать доступ в наших примерах, как вы уже догадались, будет Александр Сергеевич.

На самом деле задачи разграничения доступа практически неизбежно появляются в том случае, если практики бизнес-аналитики достигают корпоративного уровня: у вас есть единое хранилище, в которое стекается информация из самых разных систем – CRM, ERP, MES (если есть), HR, а также из отчетов сотрудников, данных с различных датчиков, через коннекторы из 1С и так далее. И если генеральный директор должен видеть всю эту информацию, руководитель подразделения из Кемерово вряд ли должен видеть данные по отделу в Краснодаре, если, конечно, это не требуется по должностным инструкциям. А когда аналитикой начинают пользоваться даже линейные сотрудники для изучения показателей своих отделов (а это вполне реально, если BI-платформа позволяет реализовать нормальный Self-Service), вопрос доступа к лишней информации становится еще острее. 

Подобные вопросы еще недавно решались за счет дублирования BI-контуров (когда требования к доступу очень жесткие) или за счет организации отдельных СУБД и отдельных дата-сетов, в которые переносятся только доступные для подразделения данные. Давайте разберемся, что не так с дубликатами данных и разными контурами BI? Тут есть три нюанса:

1. Усложненная структура, в которой работают несколько BI-платформ, как одной и той же разработки так и нескольких вендоров, требует больше лицензий, больше ресурсов администраторов

2. Двойной или тройной BI как минимум занимает больше места на дисках и съедает больше процессорного времени на расчеты, и когда мы переходим к BigData, это становится проблемой

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

ДанКо дает RLS

Наши пользователи еще несколько лет назад начали задавать вопрос о том, как проще и надежнее решить эту задачу. И это стало возможно с появлением нового движка ДанКо, о котором можно подробнее почитать здесь. Архитектура ДанКо подразумевает доступ к СУБД ClickHouse через промежуточный слой, а значит каждый пользователь может обратиться только к тем данным, которые ему положено видеть согласно корпоративным политикам безопасности. 

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

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

Как это реализовать на практике

«Включить» такое разграничение доступа на практике очень просто. Администратор, которому видны все данные, может добавить правила в статике или в динамике.  

Статическая модель использует фиксированное правило для определения прав пользователей.

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

Давайте посмотрим наглядно, как это происходит. Представьте, что у вас в компании работает некто Александр Сергеевич Пушкин, и ему не нужно видеть определенные данные. Мало ли по какой причине – чтобы не впасть в ностальгию, чтобы не иммигрировать во францию, чтобы не расстроиться. :)

RLS в статике

Итак, в аккаунте администратора мы открываем дашборд. На этом этапе на нем видны все данные. Как вы видите, речь идет о продажах различных товаров. И если сотрудник не имеет отношения к той или иной категории, можно легко закрыть ему доступ к этим данным, и они перестанут появляться на дашбордах. Как будто и нет этой информации в базе. Чтобы сделать это, выбираем пункт «Роли безопасности».

В выпадающем меню мы можем создать новую роль.

В разделе «Управление ролями» имеется возможность настроить доступ к определенным наборам данных. Для этого нужно создать новые роли, которые как раз будут характеризовать ограничения доступа.

Например, создадим роль «Доступ к Contoso и A.Datum» и для этой роли добавим пользователя или группу пользователей. В нашем случае в группу входит только один пользователь – это Александр Сергеевич Пушкин. В целом можно включить в группу любое количество пользователей.

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

Для настроек используется синтаксис DAX, и прямо под окошком для скрипта находятся пояснения, как настраивать фильтрацию.

В нашем примере мы фильтруем доступ по idproduct, выбираем brandname и определяем, что пользователю видны только категории по Contoso и A.Datum.

И вот Александр Сергеевич входит на портал…

И он видит совсем не ту картину, что и администратор, а только те столбцы, к которым у него есть доступ.  

RLS в динамике

Но если даже для начала при регулировании доступа к данным используется статическая модель назначения ролей, часто по мере «прорастания» практик BI в корпоративную среду более актуальной становится контроль доступа в соответствии с централизованными политиками. Они могут приходить из любого каталога пользователей, например AD или LDAP. 

Для динамического регулирования в Visiology используется два дополнительных атрибута:

• USERATTRIBUTE -- для настройки доступа на отдельные значения 

• USERATTRIBUTEASARRAY -- для настройки доступа на набор значений 

Давайте рассмотрим их применение более подробно. Допустим, мы хотим, чтобы роль «Москва» получала доступ только к тем значениям, которые относятся к этому городу. Для этого нужно написать следующий фильтр:

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

Обычно в этом случае в набор входит сразу несколько элементов. Например, если у нас есть такие страны как Россия, Китай и Куба, они все будут элементами этого набора значений. 

Настроить разграничение доступа в Visiology получится через внешний сервис авторизации KEYCLOAK.

На странице Visiology мы выбираем пользователя через KEYCLOAK.

И да, мы снова фильтруем доступ для Александра Сергеевича. ?

Если заглянуть в атрибуты пользователя, по ключу countries будут видны страны: «Россия», «Китай», «Куба».

Если посмотреть на общий дашборд, то на нем мы увидим еще данные по Франции. Но, согласитесь, где Александр Сергеевич, а где – Франция (отбросим конспирологические теории, что Александр Дюма и Александр Пушкин – одно и то же лицо)! Нам нужно отфильтровать данные так, чтобы А. С. не видел данные по Франции.

Для этого мы заходим снова в «Управление ролями».

Делаем примерно то же самое, что и в статике: выбираем Александра Сергеевича.

Определяем для него доступ к странам.

Для этого выбираем разграничение по параметру «Локация», и в выражении DAX выбираем страны. Кстати, сами по себе локации также могут приходить из внешней системы и меняться динамически – все это можно прописать в формуле DAX.

И вот Александр Сергеевич снова заходит на портал…

И опять мы получаем нужный дашборд, без лишних данных, к которым у пользователя нет доcтупа.

Заключение

Использование RLS позволяет реализовать очень гибкие схемы доступа к данным в рамках единых наборов. С одной и той же информацией будут работать и топ-менеджеры, и аналитики, и руководители подразделений, и линейные сотрудники, и даже внешние пользователи, которым вы предоставили доступ через онлайн-портал. При этом сохраняется скорость работы (а почему ДАнКо не тормозит, можно почитать здесь). При этом достигается одновременно как возможность работы с постоянно растущими объемами данных, так и определенный политиками доступа уровень конфиденциальности. 

Что важно, именно RLS является ключом к процессу внедрения BI по всей компании, потому что проблема «мы не можем предоставить доступ к чувствительным данным всем сотрудникам» снимается с повестки дня.

Ну и, конечно, Александр Сергеевич будет меньше переживать, если не будет видеть лишних данных на своих дашбордах! ?