Безопасность на уровне строк в Power BI: кто фильтруется, а кто нет

1. Развилка: может ли этот человек редактировать модель или только читать?

Перед объяснением один вопрос, на который стоит ответить по памяти. Вспомните последний отчет Power BI, которым вы с кем-то поделились. Скажите, может ли этот человек открыть базовую модель и изменить показатель или он может только посмотреть на то, что вы построили.

Этот вопрос, а не правило, которое вы написали, решает, делает ли вообще что-либо безопасность на уровне строк. Есть два ответа.

Ответ один: они умеют только читать. Их роль в рабочей области — «Просмотрщик», или они получили отчет через опубликованное приложение. Если это правда, каждое написанное вами правило применяется к каждому запросу, который они делают, и они видят только те строки, которые разрешены их ролью.

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

Выбор между ними решает раскрывающийся список на панели доступа к рабочему пространству, который обычно устанавливается тем, кто добавил человека, часто несколько месяцев назад, а не тем, кто написал правило безопасности. Именно в этом разрыве между двумя решениями это и не получается.

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

2. Что на самом деле представляет собой роль

Роль — это имя плюс один или несколько фильтров, каждый из которых прикреплен к таблице. Фильтр представляет собой выражение DAX, которое запрашивается о каждой отдельной строке и должно отвечать ИСТИНА или ЛОЖЬ. Формулировка Майкрософт заслуживает внимания: «Фильтр DAX оценивает ВЕРНО/ЛОЖЬ для каждой строки. Видны только строки, которые возвращают TRUE. Все остальное полностью удаляется».

Полностью удалена та часть, за которую нужно держаться. Это не фильтр отчета, который может очистить пользователь, и это не фильтр по умолчанию, который можно переопределить на панели «Фильтры». Строки исчезают до того, как визуальный элемент будет нарисован.

Самое простое полезное правило, введенное в редакторе DAX в разделе «Моделирование › Управление ролями», — это сравнение:

[Region] = "East"

Скажите вслух, что это за заказ 1004 — лампа Севера. ЛОЖЬ, поэтому строка удаляется. Заказ 1013 — это восточная лампа, поэтому ИСТИНА, поэтому ряд остается. Шестнадцать вопросов, четыре ответа типа «ИСТИНА», а модель, которую запрашивает участник роли «Восток», имеет четыре строки в разделе «Заказы» и общее количество 3040.

Одно правило именования, которое цепляет людей, и оно документировано, а не фольклорно: имя роли не может содержать запятую. London,ParisRole отклонено.

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

3. Два инструмента, два шага: где живут роли и где работают люди

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

Вы не можете назначать пользователям роли в Рабочий стол. Эта опция не скрыта и не скрыта, ее нет, поскольку Рабочий стол не знает, кто работает в вашей организации. А страница «Безопасность» в Службе отображается только для моделей, для которых уже определены роли, поэтому модель без ролей не дает вам ничего нажимать и не дает никаких объяснений.

Два небольших факта, которые всплывают. Добавлять участников в роли может только владелец семантической модели или администратор рабочей области. А группы Майкрософт 365 вообще нельзя использовать для членства в ролях; группы безопасности, группы рассылки и группы с включенной поддержкой почты могут.

Любой, кто опубликовал модель, но никому не назначил ее, получает результат, который выглядит как ошибка, но таковой не является. Пользователь, не имеющий никакой роли, обычно видит ничего, а не все, поскольку правило применяется, и ни одна роль не разрешает какую-либо строку.

4. Провал: менеджер Востока, увидевший 9890

Здесь это проработано от начала до конца, и именно такая версия и происходит на самом деле.

Прия управляет Восточным регионом. Вы строите модель, пишите [Region] = "East" в роль Восток, опубликуйте ее, добавьте Прию к роли в Сервисе и протестируйте ее. Тест пройден: четыре заказа, 3040.

Однако несколькими неделями ранее в рабочую область была добавлена ​​Прия, чтобы она могла открыть три других отчета, которые команда хранит там. Ей дали Член. Никто не связывал эти два решения, потому что они были приняты разными людьми по разным причинам в разные дни.

Прия открывает свою региональную карточку. Он читает 9,890.

Прежде чем читать дальше, скажите, почему отчет не дает ей ни малейшего понятия. Правило по-прежнему существует, роль по-прежнему назначена, и она по-прежнему является его участником.

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

Исправление — это один раскрывающийся список, которого нет в модели. На панели доступа к рабочей области измените Прия с Член на Зритель. Она сохраняет отчеты, не теряет ничего из того, что использует, и правило начинает действовать. Если ей нужно построить свои собственные отчеты на основе модели, дайте ей разрешение «Просмотр плюс сборка» для семантической модели, поскольку RLS по-прежнему применяется к средствам просмотра, у которых есть «Сборка». Майкрософт прямо заявляет об этом, в том числе для анализа в Эксель.

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

5. Две роли — это союз, а не пересечение

Прежде чем объяснение, предсказание. Кто-то находится в роли, которая разрешает Восток, и вы также добавляете его в роль, которая разрешает лампы. Скажите, увидят ли они в конечном итоге только восточные лампы или что-то большее.

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

Рекомендации Майкрософт однозначны: «Когда пользователю отчета назначено несколько ролей, фильтры RLS становятся аддитивными. Это означает, что пользователи отчета могут видеть строки таблицы, которые представляют собой объединение этих фильтров». А предложение сразу после него следует запомнить, поскольку оно указывает на нарушение допущения: «в отличие от разрешений, применяемых к объектам базы данных SQL Server (и других моделей разрешений), принцип «однажды отклонено, всегда запрещено» не применяется».

Работал над приборкой. Роль «Восток» разрешает заказы 1003, 1006, 1010 и 1013. Роль «Лампы» разрешает каждый заказ лампы, то есть 1004, 1008, 1009 и 1013.

Ожидалось 600, доставлено 4040, и 4040 минус 600 = 3440 строк, которые никто не собирался передавать. Добавление второй роли расширило доступ, что противоположно тому, как звучит «добавление ограничения».

Собственная иллюстрация этого Майкрософт более яркая, чем моя, и ее стоит держать в голове как крайний случай. Роль Рабочие ограничивает таблицу расчета заработной платы правилом FALSE(), поэтому он вообще не возвращает строк. Роль менеджеров использует TRUE(), поэтому он возвращает все. Тот, кто сопоставляет обе роли, видит всю таблицу заработной платы. Отрицание не побеждает. Нет никаких отрицаний.

Исправление — это правило дизайна, а не настройка: один человек, одна роль. Если человеку нужен Восток и лампы вместе, создайте единую роль, которая несет в себе оба фильтра, по одному на каждом столе, чтобы оба условия применялись одновременно. Руководство Майкрософт рекомендует именно это, и стоит отметить причину, по которой оно приводится: пользователь может получить вторую роль косвенно, через группу безопасности, и никто не решит поместить его туда.

6. Динамический СБН и опечатка, открывающая всю таблицу

Написание одной роли для каждого региона не выходит за рамки нескольких. Динамический RLS — это одна роль для всех, где правило сравнивает столбец со всеми, кто вошел в систему.

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

[UserEmail] = USERPRINCIPALNAME()

USERPRINCIPALNAME не принимает аргументов и возвращает имя участника-пользователя во время подключения, которое выглядит как адрес электронной почты. Фильтр попадает в таблицу сопоставления, таблица сопоставления связана с регионом, а фильтр перемещается вниз по этой связи к заказам. Одна роль, одно правило, и добавление нового менеджера становится строкой в ​​таблице, а не изменением модели.

Существует более старая функция USERNAME, и эта разница — настоящая ловушка, а не мелочь. В ИМЯ ПОЛЬЗОВАТЕЛЯ Рабочий стол Power BI возвращает DOMAIN\User. В службе ИМЯ ПОЛЬЗОВАТЕЛЯ Power BI и USERPRINCIPALNAME возвращают имя участника-пользователя. Таким образом, правило, созданное и протестированное со значением доменного типа в Рабочий стол, после публикации может вести себя по-другому. Используйте USERPRINCIPALNAME и сохраните соответствующие значения в таблице сопоставления.

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

IF (
    USERNAME () = "Worker",
    [Type] = "Internal",
    TRUE ()
)

Рабочие видят внутренние ряды. Все остальные, то есть менеджеры, все видят. Но «все остальные» — это не список менеджеров. Это каждое значение, которое не является строкой. Worker, так Wrker попадает в ветку Еще и возвращает TRUE для каждой строки. В руководстве Майкрософт используется именно этот пример, и его исправление состоит в том, чтобы проверить каждое ожидаемое значение и запретить провал:

IF (
    USERNAME () = "Worker",
    [Type] = "Internal",
    IF (
        USERNAME () = "Manager",
        TRUE (),
        FALSE ()
    )
)

За этим стоит привычка: в правиле безопасности последняя ветвь — это та, которая запускается, когда вы об этом не подумали. Заставьте его ничего не возвращать.

7. Что доказывает точка зрения, а что нет

На рабочем столе на ленте «Моделирование» есть «Просмотр как», а на странице «Безопасность» модели у службы есть роль «Тестировать как». Оба действительно полезны, и оба доказывают меньше, чем думают люди.

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

Чего они не доказывают, и это документально, а не фольклорно:

• Они не могут сказать вам роль человека на рабочем месте. Вся ошибка в разделе 4 невидима для обоих инструментов, поскольку оба имитируют правило, и ни один из них не имитирует обход.
• Для динамического RLS тест использует вашу собственную личность. USERPRINCIPALNAME возвращает ваше имя для входа, а не то, которое вы пытаетесь имитировать. Итак, прохождение теста покажет вам, что правило работает для вас.
• Не каждая поверхность покрыта. Тестирование в качестве роли не работает для отчетов с разбивкой на страницы и не проверяет визуальные элементы вопросов и ответов, Краткая информация или Второй пилот. Это также не работает для моделей ДиректЗапрос с единым входом.

Тест, который восполняет пробел, непривлекательный и занимает две минуты: поместите в отчет карточку, показывающую USERPRINCIPALNAME(), опубликуйте и попросите одного реального человека из каждой аудитории открыть его и рассказать вам, что там написано рядом с их итоговыми данными. Руководство Майкрософт по устранению неполадок предлагает ту же меру, названную примерно так: «Кто я». Настоящая сессия пользователя — единственное, что тренирует обе половины одновременно.

8. Четыре вещи, которых не делает RLS

Каждый из этих дней — чей-то разочарованный день.

Он не скрывает столбцы или меры. Майкрософт прямо говорит об этом: RLS «фильтрует строки таблицы. Их нельзя настроить для ограничения доступа к объектам модели, включая таблицы, столбцы или меры». Если человек видит строку, он может видеть каждый столбец в этой строке, включая зарплату. Функция скрытия столбца — это безопасность на уровне объекта, и она является отдельной.

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

Он не может быть переопределен DAX ни в каком направлении. Это касается обоих путей, и его стоит знать. Ни одна мера не может обойти RLS, и Майкрософт идет еще дальше: выражение DAX «даже не может определить, что RLS применяется». Таким образом, невозможно написать более разумную меру, чтобы обойти эту проблему, и в равной степени нельзя случайно проделать в ней дыру с помощью ВСЕХ или УДАЛЕННЫХ ФИЛЬТРОВ. Если вам нужна механика того, что может и не может видеть мера, то это РАСЧЕТ и фильтрация контекста.

Модель не везде следует этой модели. Живые подключения к службам Аналитические услуги обеспечивают безопасность в этой модели, а не в Power BI, а параметр «Безопасность» даже не отображается. Публикация в Интернете вообще не работает с RLS. Субъекты-службы не могут быть добавлены в роль, поэтому приложение, проверяющее подлинность таким образом, не фильтруется по ним.