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

Необходимое условие

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

Сценарий

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

В представленной организационной структуре Билл должен видеть только одну запись данных. Марк должен увидеть три записи: 2 записи для себя и 1 запись от Билла (потому что Билл сообщает напрямую Марку). Лейла должна увидеть 4 записи: одна запись для нее, 2 записи для Марка и одна запись для Билла. Вот как должна работать иерархическая организационная безопасность на уровне строк.

Таблица пользователей

Вот пример данных в пользовательской таблице:

Как видите, у нас есть две основные колонки: ID сотрудника и ID менеджера, который указывает на запись, которая является записью менеджера.

Таблица транзакций продаж

Для каждого сотрудника может быть одна или несколько транзакций продаж в таблице транзакций:

Схема модели

Две таблицы здесь создают очень простую схему, подобную следующей:

Образец отчета

Вот пример образца отчета: в нем есть все записи всех сотрудников, а также организационная иерархия:

Функции Path в DAX

Для реализации безопасности на уровне строк в этом сценарии одним из наиболее распространенных способов является использование функций Path в DAX. Функции Path - это мощные функции, которые могут перемещаться по неизвестному уровню иерархии на основе идентификатора и структуры родительского идентификатора. структура вашей таблицы данных обычно строится на основе двух столбцов; ID и Manager ID, как показано ниже:

Чтобы узнать, как работают функции Path, давайте рассмотрим пару из этих функций:

Path()

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

Эта функция даст вам полный путь для иерархии с текстовым значением с разделителями. Идентификатор каждого сотрудника в пути разделен в этом тексте вертикальной линией (|).

PathItem ()

Функция PathItem () даст вам определенный элемент в пути. Если вы хотите узнать, кто является менеджером уровня 1, или уровня 2 или 3, вы можете использовать PathItem для его извлечения. Вот пример:

В коде выше; 2 - это индекс уровня (2 означает второй уровень управления), а 1 - тип данных вывода (1 означает целое число).

Затем вы можете объединить этот метод с функцией LookupValue, чтобы узнать имя человека на этом уровне:

Это означает, что вы можете создавать вычисляемые столбцы для каждого уровня иерархии организации:

PathContains ()

Теперь важной функцией этого поста является PathContains. PathContains проверит, существует ли идентификатор в пути или нет. Это функция, которая необходима для обеспечения безопасности на уровне строк. Все, что вам нужно узнать, это идентификатор человека, который вошел в систему. Мы уже знаем, как получить адрес электронной почты человека, который вошел в систему, мы используем функцию UserName () или UserPrincipalName ().

Узнать личность человека, вошедшего в систему

Вы можете использовать функцию Filter и Iterator в DAX, чтобы узнать, кто вошел в систему, функцию filter для фильтрации пользователя с функцией PrincipalUserName (), а функция Iterator извлекла идентификатор этой оставшейся записи.

Вот как используется функция фильтра для извлечения записей пользователя, вошедшего в систему:

Найдя запись для текущего пользователя, вы можете использовать MaxX или MinX, чтобы узнать идентификатор этого пользователя;

и наконец, теперь вы можете использовать этот идентификатор в функциях PathContains, чтобы проверить, существует ли идентификатор пользователя в пути или нет:

Вам необходимо добавить эту логику в качестве роли в пользовательской таблице:

Это выражение DAX проверит полный путь иерархии организации, чтобы увидеть, есть ли какие-либо записи в таблице пользователей, которые имеют этот идентификатор пользователя в своем столбце пути или нет.

Результат тестирования

В результате, если вы переключитесь на этого пользователя, вы увидите только зарегистрированного пользователя с записями, связанными с ним / ней.

Существуют другие способы реализации такой логики, вы можете использовать другие функции и выражения, чтобы найти идентификатор текущей записи. Этот пост объяснил один из способов сделать это. Как вы можете видеть на приведенном выше снимке экрана, Реза имеет доступ только для просмотра записей для себя, Эми и Дэвида (его прямые отчеты) и Линдси (который подчиняется непосредственно Эми).

Резюме

Применение безопасности на уровне строк имеет много вариантов. В этом посте вы узнали о том, как использовать организационную иерархию и функции Path в DAX для реализации безопасности на уровне строк на основе иерархии.

No Comments