Реализация динамической безопасности на уровне строк в Power BI и Microsoft Fabric: архитектура, шаблоны DAX и корпоративное управление
By Mirko Peters · · Updated
Реализуйте динамическую безопасность на уровне строк в Power BI и Microsoft Fabric, чтобы контролировать доступ пользователей к данным, обеспечивать соответствие требованиям и адаптироваться к изменениям в организации.
Automatically translated with AI from the original post. Read the English original
Динамическую безопасность на уровне строк стоит рассматривать как систему, которая меняется. Она растёт и развивается вместе с вашей организацией. На то, как работает безопасность в Power BI и Microsoft Fabric, влияют проектирование модели данных, выражения DAX, идентификация пользователя и управление. Если настроить всё правильно, вы сможете определять, кто получает доступ к тем или иным данным.
Ключевая область | Влияние на RLS |
|---|---|
Фильтрует данные по пользователю с помощью DAX в модели | |
Управление | Обеспечивает соответствие доступа правилам и его защищённость |
Проектирование модели | Позволяет контролировать, кто видит конфиденциальные данные |
Главное
Динамическая безопасность на уровне строк меняется вместе с потребностями вашей компании. Она позволяет выбирать, кто может видеть определённые данные. Для этого проверяется идентификация каждого пользователя.
Для безопасности в облаке используйте USERPRINCIPALNAME(). Эта функция позволяет пользователям видеть только собственные данные. Она помогает защитить вашу информацию.
Регулярно проверяйте настройки безопасности и группы пользователей. Это не даст людям увидеть данные, которые им не положено видеть. Так вы сохраните защиту данных.
Создавайте понятные таблицы безопасности для управления разрешениями пользователей. Это поможет контролировать, кто что видит, по мере роста компании.
Тестируйте правила безопасности в облаке с реальными пользователями. Так вы убедитесь, что данные защищены и пользователи видят только то, что им разрешено.
Переосмысление систем безопасности на уровне строк
Безопасность как система, управляемая моделью
Безопасность на уровне строк связывает разные части вашей аналитической платформы. Создавая модель данных, вы начинаете строить безопасность данных. То, как вы настраиваете таблицы, связываете их и создаёте роли, определяет, что видят пользователи. Если компания растёт или к работе подключаются новые команды, правила безопасности нужно обновлять. Безопасность на уровне строк — не то, что настраивают один раз и забывают. Она меняется вместе с бизнесом и новыми задачами.
Совет: регулярно проверяйте модель данных. Хорошая модель упрощает настройку безопасности и помогает избежать ошибок.
В модели должны быть понятные связи и специальные таблицы безопасности. Это позволяет контролировать, кто видит определённые данные, и защищает конфиденциальную информацию. Динамическая безопасность на уровне строк может сопоставлять то, что видит пользователь, с его группой или должностью в Fabric. Так вы быстро меняете разрешения, когда меняется компания.
Статическая и динамическая безопасность на уровне строк
Есть два основных способа настройки безопасности данных: статическая и динамическая безопасность на уровне строк. Статическая безопасность использует заранее заданные правила: для каждой группы создаются роли и фильтры. Это хорошо для небольших команд или когда доступ меняется мало. Динамическая безопасность использует данные о вошедшем пользователе и таблицы сопоставления. Она проверяет пользователя и сразу меняет то, какие данные он видит. Это лучше подходит для крупных компаний с большим числом пользователей и меняющимися правилами.
Характеристика | RLS (статическая) | DLS (динамическая) |
|---|---|---|
Гибкость | Низкая | Высокая |
Настройка | Ручные роли | На основе правил с сопоставлением пользователей |
Лучший сценарий использования | Немного пользователей / фиксированный доступ | Много пользователей / персонализированный доступ |
Динамическая безопасность на уровне строк даёт больше возможностей для управления доступом. Она использует такие средства, как USERPRINCIPALNAME() и таблицы сопоставления, чтобы связать пользователей с нужными данными. Статическая безопасность проста, но плохо работает, когда компания растёт или часто меняется.
Статическая безопасность на уровне строк ограничивает данные с помощью заданных правил.
Динамическая безопасность на уровне строк меняет то, что видит пользователь, в зависимости от того, кто он.
Динамическая безопасность лучше всего подходит крупным компаниям с большим количеством правил.
Чтобы защитить данные, выбирайте подход, который подходит именно вам. Хорошее планирование и продуманная модель помогут защитить конфиденциальные данные и сохранить безопасность аналитики.
Шаблоны динамической безопасности на уровне строк в Fabric
Функции DAX: USERPRINCIPALNAME() против USERNAME()
Важно понимать, как работает идентификация в Fabric. Для настройки безопасности на уровне строк используются две основные функции: USERPRINCIPALNAME() и USERNAME(). Обе функции определяют, кто смотрит отчёт. USERPRINCIPALNAME() возвращает адрес электронной почты пользователя из облака. USERNAME() часто возвращает имя локальной учётной записи, чаще всего в Power BI Desktop. Если использовать USERNAME() в облаке, результат может быть некорректным. Это может снизить защищённость данных.
Совет: для динамической безопасности на уровне строк в Fabric всегда используйте USERPRINCIPALNAME(). Эта функция сопоставляет облачный адрес электронной почты пользователя и помогает защитить ваши данные.
Функция | Возвращает | Лучший сценарий использования |
|---|---|---|
USERPRINCIPALNAME() | Облачный адрес электронной почты | Fabric, облачный Power BI |
USERNAME() | Имя локальной учетной записи | Только для тестирования в Desktop |
Если использовать не ту функцию, пользователи могут увидеть данные, которые им видеть не положено. Безопасность нужно тестировать в облаке, а не только в Desktop.
Безопасные шаблоны DAX и антишаблоны
Вы хотите, чтобы ваши данные оставались в безопасности. Для динамической безопасности на уровне строк нужны надежные шаблоны DAX. Лучший способ — использовать таблицы сопоставления и динамические правила. Так вы контролируете, кто что видит.
Фильтры строк ограничивают то, что видят пользователи. Вы можете скрыть данные по региону, подразделению или учетной записи.
Маски столбцов позволяют скрывать или изменять данные в зависимости от того, кто является пользователем.
Хороший шаблон DAX использует поиск, чтобы сопоставить пользователей с их группами. Это хорошо работает в компаниях с большим количеством групп. Вот хороший пример:
Organizations[Id] = LOOKUPVALUE(
AspNetUsers[OrganizationId],
AspNetUsers[Email],
USERPRINCIPALNAME()
)
Этот шаблон проверяет адрес электронной почты пользователя и находит его группу. Так можно показывать только нужные данные. Этот подход лучше простого сопоставления адресов электронной почты. Он хорошо масштабируется по мере роста компании и защищает ваши данные.
Примечание: не жестко прописывайте адреса электронной почты и не используйте вычисляемые столбцы для управления доступом. Такие способы могут перестать работать, если пользователи изменятся или компания вырастет.
Некоторые плохие шаблоны могут привести к утечке данных:
Использование USERNAME() в облаке.
Жесткое прописывание адресов электронной почты пользователей или доменов.
Размещение логики безопасности в вычисляемых столбцах.
Всегда используйте динамические правила и таблицы сопоставления. Так модель данных остается простой, а данные — в безопасности.
Иерархии и функция PATH()
Иногда нужна безопасность для руководителей, команд или подразделений. Для этого подходят иерархии. Функция PATH() в DAX позволяет строить связи «родитель — потомок». С ее помощью можно контролировать, кто что видит на каждом уровне.
Например, можно создать таблицу с идентификаторами сотрудников и их руководителей. PATH() строит цепочку от каждого сотрудника до его руководителя. Затем с помощью DAX можно фильтровать данные для каждого уровня.
PATH(Employee[EmployeeID], Employee[ManagerID])
Эта функция помогает настроить динамическую безопасность на уровне строк для крупных компаний. Руководители могут видеть данные своей команды, а обычные сотрудники — не получать лишнего доступа.
Совет: используйте PATH() для безопасности в иерархиях. Это делает модель данных гибкой и помогает защищать ваши данные.
Фильтры строк, маски столбцов и функции иерархии можно использовать вместе. Это помогает защищать конфиденциальные данные и контролировать доступ по мере роста компании.
Архитектура ролей и связей
Проектирование таблиц безопасности
Для динамической безопасности на уровне строк нужны таблицы безопасности. Они показывают, какие пользователи могут видеть какие данные. Используйте столбцы для адреса электронной почты пользователя, группы и уровня доступа. Такая структура помогает сохранять безопасность данных по мере роста компании.
При создании ролей разделяйте строгие и открытые роли. Если одна роль позволяет видеть все, другие роли с безопасностью на уровне строк могут работать некорректно. Чтобы сохранить безопасность данных, не допускайте конфликтов между ролями.
Создавайте таблицы безопасности с понятными столбцами для пользователя и разрешений.
Разделяйте роли, чтобы они не пересекались и не вызывали проблем.
Регулярно проверяйте таблицы безопасности, чтобы они соответствовали изменениям.
Связи в модели данных
То, как вы строите модель данных, определяет, как вы контролируете доступ. Используйте односторонние связи между таблицами. Так модель остается простой, и проще избежать ошибок.
Лучше использовать специальные таблицы безопасности, а не размещать разрешения в таблицах фактов. Таблицу безопасности можно связать с другими таблицами, например с подразделением или регионом. Так можно фильтровать данные для каждого пользователя или группы.
Совет: используйте мостовые таблицы для связи пользователей с данными. Это помогает работе динамической безопасности на уровне строк и защищает ваши данные.
Гранулярность ролей: небольшие и крупные роли
Вам нужно решить, насколько подробными должны быть ваши роли. Узкие роли дают больше контроля. Доступ можно выдавать по должности или по группе. Широкие роли охватывают больше людей, но могут быть рискованными, если что-то меняется.
Регулярно проверяйте, кто имеет каждую роль. Так ваши данные остаются в безопасности, и вы можете что-то изменить при необходимости.
Выбирайте узкие роли для большего контроля и простых обновлений. Широкие роли могут подойти для простых групп, но в крупных компаниях они могут создавать проблемы.
Назначение пользователей и групп в Fabric
Группы Azure AD и отдельные пользователи
Доступ в Fabric выдаётся добавлением пользователей в группы Azure AD. Так можно управлять данными сразу для многих людей. Использовать группы безопаснее, чем добавлять каждого человека по отдельности. Группы помогают управлять системой с меньшими затратами труда. Когда состав команды меняется, группы можно быстро обновить. Связывание групп с ролями упрощает моделирование данных. Ваши правила безопасности на уровне строк остаются понятными и простыми.
Совет: используйте группы Azure AD для управления доступом. Это помогает допускать меньше ошибок и экономит время.
Пересекающиеся группы и теневой доступ
Нужно следить за пересекающимися группами. Иногда пользователь состоит в нескольких группах. Это может открыть ему доступ к данным, которые ему видеть не положено. Теневой доступ возникает, когда такая ошибка позволяет пользователям видеть лишние данные. Чтобы этого избежать, регулярно проверяйте списки групп. Используйте таблицы, чтобы отслеживать, какие пользователи входят в каждую группу. Хорошее моделирование данных помогает находить проблемы на раннем этапе. Удаляйте пользователей из групп, которые им больше не нужны, чтобы сохранить безопасность данных.
Проблема | Решение |
|---|---|
Пересекающиеся группы | Регулярно проверяйте списки групп |
Теневой доступ | Проверяйте состав групп |
Примечание: теневой доступ может открыть приватные данные. Устраняйте пересечения групп, чтобы система оставалась безопасной.
Плановые проверки доступа
Планируйте регулярные проверки доступа. Периодически проверяйте, кто входит в каждую группу. Попросите владельцев групп подтвердить, кому должен быть предоставлен доступ. Это поддерживает работу динамической безопасности на уровне строк по мере роста компании. Используйте инструменты Fabric для помощи в этих проверках. Удаляйте старых пользователей, чтобы повысить безопасность данных. Это поддерживает аналитическую систему в порядке и безопасности. Сделайте проверки доступа обычной частью вашей работы с бизнес-аналитикой.
Назначьте даты проверки всех групп.
Используйте инструменты Fabric для проверки групп.
Попросите владельцев подтвердить, кто входит в каждую группу.
Внимание: регулярные проверки помогают находить ошибки до того, как они приведут к проблемам.
Определение идентичности: Desktop и Fabric
Функции идентификации и различия облачной среды
Важно понимать, как работает идентификация в Power BI Desktop и Microsoft Fabric. В Power BI Desktop функция USERNAME() обычно возвращает имя вашего компьютера. В Microsoft Fabric функция USERPRINCIPALNAME() возвращает ваш облачный адрес электронной почты. Эта разница важна для защиты данных. Если использовать USERNAME() в облаке, данные могут увидеть не те люди. Для облачных отчётов всегда используйте USERPRINCIPALNAME(). Это помогает защищать данные и соответствует системе идентификации вашей компании.
Совет: проверяйте правила безопасности на уровне строк в облаке. Тесты в Desktop не показывают реальный доступ пользователей.
Владелец набора данных и параметры клиента
Нужно знать, кто владеет вашим набором данных. Владелец может менять настройки обновления и влиять на то, кто видит данные. Если сменить владельца, можно изменить и то, кто видит приватные данные. Параметры клиента также важны. Они определяют, как работают идентификаторы в вашей компании. Проверяйте параметры клиента перед публикацией отчётов. Убедитесь, что модель данных соответствует правилам безопасности вашей компании.
Параметр | Влияние на безопасность данных |
|---|---|
Владелец набора данных | Управляет обновлением и доступом |
Параметры клиента | Управляет организацией идентификации |
Частые причины утечек RLS
Можно потерять контроль над безопасностью на уровне строк, если не тестировать в облаке. Иногда пользователи видят больше данных, чем должны. Это может произойти, если использовать неправильную функцию идентификации или забыть обновить членство в группах. Утечки также возможны, если изменить модель данных, не проверив таблицы безопасности. Всегда проверяйте настройки безопасности данных после изменений. Используйте облачное тестирование и регулярные аудиты, чтобы находить проблемы на раннем этапе.
Внимание: утечки данных могут раскрыть конфиденциальную информацию. Регулярно проверяйте настройки, чтобы защитить организацию.
Тестирование, аудит и управление
Тестирование RLS в облаке
Проверяйте безопасность на уровне строк в облаке. Так вы убедитесь, что ваши данные защищены для реальных пользователей. Инструмент «View As» в Desktop показывает только предварительный просмотр. Он не показывает, как правила работают в Microsoft Fabric. После публикации отчёта проверьте его с реальными пользователями и группами. Так вы увидите, какие данные доступны каждому человеку. Используйте тестовые учётные записи, чтобы убедиться, что пользователи видят только свои данные. Всегда повторяйте проверку после изменения ролей или обновления модели. Тестирование в облаке помогает находить проблемы до того, как они нанесут ущерб вашему бизнесу.
Совет: всегда тестируйте с реальными пользователями в облаке, а не только в Desktop. Так ваша безопасность данных будет надёжной.
Автоматизация аудитов и проверок
Вы можете использовать автоматизацию, чтобы упростить аудиты и проверки в Fabric. Автоматизация по расписанию проверяет разрешения рабочих областей, потоки данных и метки конфиденциальности. Microsoft Purview предоставляет панели мониторинга для отслеживания правил на всей платформе. Вы можете использовать журналы действий и Admin API, чтобы находить проблемы с соответствием требованиям. Автоматизация помогает выявлять проблемы на раннем этапе и экономит время. Аудиторы могут увидеть полный путь конфиденциальных столбцов от источника до отчёта. Это делает проверки быстрее и точнее. Автоматизация также упрощает и удешевляет соблюдение таких правил, как GDPR и HIPAA.
Настройте автоматические проверки разрешений и потоков данных.
Используйте панели мониторинга, чтобы отслеживать изменения правил безопасности.
Просматривайте журналы действий, чтобы быстро находить проблемы.
Документация и управление изменениями
Для того чтобы система безопасности данных оставалась понятной, нужны качественные записи. Записывайте правила безопасности, списки групп и изменения ролей. Обновляйте заметки при изменении модели или добавлении новых пользователей. Четкие записи помогают отслеживать, кто к каким данным имеет доступ. Они также помогают новым членам команды разобраться в вашей системе. Управление изменениями означает, что обновления проверяются и утверждаются до выхода в работу. Это сохраняет безопасность вашей защиты на уровне строк по мере роста компании.
Задача | Польза |
|---|---|
Документируйте изменения | Предотвращает путаницу |
Проверяйте обновления | Блокирует нежелательный доступ |
Отслеживайте назначения | Делает данные безопаснее |
Внимание: поддерживайте записи в актуальном состоянии. Это защищает ваши данные и помогает быстрее устранять проблемы.
Безопасность на уровне строк нужно рассматривать как нечто, что меняется вместе с вашими данными и компанией. Продуманная настройка помогает защищать конфиденциальную информацию. Использование правильных шаблонов DAX и грамотное управление удостоверениями пользователей защищают ваши данные. Регулярная проверка безопасности и документирование изменений помогают вовремя замечать проблемы. Если planировать заранее, вы сможете контролировать, кто видит данные, и защищать вашу аналитику.
Регулярно проверяйте настройки безопасности.
Меняйте правила, чтобы лучше защищать данные.
Всегда ставьте конфиденциальность на первое место.
Часто задаваемые вопросы
Что такое динамическая безопасность на уровне строк в Power BI и Fabric?
Динамическая безопасность на уровне строк позволяет управлять доступом к данным в зависимости от того, кто просматривает отчёт. Вы используете функции DAX и таблицы сопоставления, чтобы связать пользователей с нужными данными.
Почему следует использовать USERPRINCIPALNAME() вместо USERNAME()?
USERPRINCIPALNAME() возвращает облачный адрес электронной почты пользователя. Это лучше всего работает в Power BI и Fabric. USERNAME() может возвращать локальное имя, что может создать проблемы с безопасностью в облаке.
Как группы Azure AD помогают в обеспечении безопасности?
Группы Azure AD позволяют управлять доступом сразу для многих пользователей. Вы добавляете пользователей в группы и назначаете роли. Это делает настройку безопасности проще и надёжнее.
Что такое таблица безопасности и зачем она нужна?
Таблица безопасности содержит список пользователей, групп и разрешений. Она используется для управления доступом к определённым данным. Это помогает защищать данные по мере роста компании.
Как часто нужно проверять безопасность на уровне строк в облаке?
Проверять безопасность на уровне строк нужно каждый раз при изменении ролей, групп или модели данных. Тестирование в облаке показывает, что видят реальные пользователи, и помогает вовремя находить проблемы.