Безопасность Power BI: доступ, RLS, OLS, аудит и восстановление

Обновлено 3 сентября 2026 года.

Безопасность Power BI складывается из нескольких уровней: вход пользователя, доступ к рабочей области и отдельным объектам, ограничения внутри модели, передача данных во внешние файлы и приложения. Дополнительно нужно управлять подключениями, изменениями, журналами и восстановлением.

У отчёта нет универсальной кнопки «поставить пароль», а срез или скрытая страница не защищают данные модели. Ниже — практический порядок настройки и проверки для Power BI service. Для Power BI Report Server и внешних моделей Analysis Services часть механизмов отличается.

Карта механизмов защиты

1. Вход и MFA настраиваются в Entra ID

MFA означает многофакторную аутентификацию, а не «одношаговую». Для входа в Power BI service используются механизмы Microsoft Entra ID. Администратор выбирает подходящую схему, например Security defaults либо политики Conditional Access, с учётом лицензирования и правил организации.

Не ищите отдельный переключатель MFA в вымышленном меню «Настройки безопасности Power BI». Базовые меры Entra описаны в документации Security defaults. Проверяйте вход обычного пользователя и административных учётных записей, регистрацию методов и процедуру восстановления доступа.

У каждого сотрудника должна быть собственная учётная запись. Для автоматизации используйте поддерживаемый тип идентичности и необходимые ему разрешения. Пароли, токены и секреты приложений нельзя помещать в текст M-запроса, общий PBIX, репозиторий или страницу отчёта. Отдельно назначьте владельца секрета и порядок его замены при компрометации или окончании срока действия.

2. Разделите права авторов и зрителей

Рабочая область имеет роли Admin, Member, Contributor и Viewer. Права могут приходить напрямую и через группы. Если человек входит в несколько групп, учитывается совокупность назначений; удаление одной записи в списке доступа не обязательно лишает его остальных прав.

Точный состав действий и условия лицензирования — в таблице ролей Microsoft. Для широкой аудитории рассматривайте распространение через приложение Power BI с нужными разрешениями, не выдавая всем права разработчика.

Отдельно проверяйте разрешения семантической модели: Read, Build, Reshare и Write. Build позволяет создавать собственные аналитические материалы на основе модели, включая Analyze in Excel; оно не отменяет RLS для зрителя. Отсутствие Build не следует использовать как единственную защиту конфиденциальных полей. Разрешения семантической модели.

3. RLS: правила строк и назначение пользователей

RLS фильтрует строки семантической модели. Типовой процесс: определить роли и правила в Desktop, опубликовать модель, назначить пользователей или поддерживаемые группы на странице Security модели в сервисе и проверить результат.

Для пользователей рабочей области RLS действует на Viewer. На Admin, Member и Contributor эти ограничения не распространяются, поскольку у них есть права редактирования модели. В случае live connection к Analysis Services правила задаются в исходной модели. Документация RLS.

Небольшой пример проверки

В учебной Import-модели Sales две строки: North с Amount = 100 и South с Amount = 200. Мера Total Amount = SUM(Sales[Amount]) без фильтров даёт 300. Создайте две роли и задайте для таблицы Sales соответствующий фильтр:

// Роль NorthOnly
Sales[Region] = "North"

// Роль SouthOnly
Sales[Region] = "South"

Это отдельные выражения фильтра для двух ролей; не вставляйте оба одновременно как одну формулу. После публикации проверьте такие ситуации:

Несколько RLS-ролей дают объединение разрешённых строк. «Запрещающая» роль не перекрывает автоматически другую разрешающую. Поэтому проверяйте прямые назначения и членство в группах. Это поведение разобрано в рекомендациях по проектированию RLS.

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

Используйте View as/Test as role и затем реальный вход тестового зрителя. Test as role не покрывает все сценарии; например, для DirectQuery с SSO у него есть ограничения. Удалите тестовый доступ после проверки и сохраните ожидаемые результаты для повторного контроля после изменений.

4. OLS и скрытие элементов интерфейса

OLS ограничивает доступ к таблицам, столбцам и их метаданным. В текущей документации Microsoft предусмотрена настройка через TMDL view или Tabular Editor. После публикации необходимо назначить участников ролей. Визуал, использующий недоступный объект, может выдавать ошибку: дизайн отчёта должен учитывать разные аудитории. Документация OLS.

Скрытый столбец в панели полей, скрытая страница, срез, закладка или визуальное маскирование не являются равноценной заменой OLS/RLS. Если исходное значение осталось в модели и пользователь имеет путь доступа к нему, отсутствие поля на экране не делает его защищённым.

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

5. Метки конфиденциальности и protection policies

Метка помогает классифицировать содержимое. Защищённая метка может ограничивать её изменение и защищать файлы на поддерживаемых путях экспорта. Нельзя считать одно название «Конфиденциально» на отчёте доказательством, что все остальные способы доступа закрыты. Защищённые метки в Fabric и Power BI.

Отдельный механизм Microsoft Purview protection policies для Fabric связывает метку с ограничением доступа к поддерживаемым объектам. На дату проверки среди объектов Power BI поддерживаются семантические модели, но не отчёты и dashboards. Для политики нужны настройки и лицензии; она сохраняет существующие права разрешённым пользователям, а не выдаёт их с нуля.

У этого механизма есть существенные особенности: пользователь, применивший метку, не блокируется политикой; внешние гости не поддерживаются; enforcement может начаться не сразу. Поэтому проверяйте фактическое действие политики на нужном объекте и на каждом типе пользователя. Не переносите ожидания от защищённого файла Office на все объекты Power BI.

6. Экспорт, публикация и встраивание

Проверьте настройки экспорта, скачивания PBIX, Analyze in Excel, повторного предоставления доступа и внешних пользователей. Состав доступных действий зависит от прав, настроек организации и типа содержимого. Для конфиденциальной модели составьте список разрешённых способов выдачи данных и проверьте каждый.

Publish to web делает содержимое доступным в интернете без обычной авторизации зрителя. Его нельзя применять для внутренней финансовой отчётности, персональных данных или коммерческих деталей. Наличие ссылки только у коллег не превращает такую публикацию в закрытую. Документация Publish to web.

Встраивание обычного отчёта в SharePoint или Teams требует соответствующего доступа в Power BI. Для приложения с Power BI Embedded отдельно проектируют авторизацию и область действия токенов. Фильтр в URL или скрытая кнопка не заменяют ограничения данных. Практические варианты — в руководстве по интеграциям.

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

7. Шифрование и доступ к источнику

Сохраняемые Power BI service данные по умолчанию шифруются ключами Microsoft; связь браузера с сервисом использует HTTPS/TLS. Это не функция, которую нужно вручную включать для каждого отчёта. Пользовательские ключи и другие специальные схемы требуют отдельной конфигурации. Архитектура безопасности Power BI.

Отдельно проверьте участок между источником и шлюзом, настройки конкретного драйвера и сертификаты. Защищённая страница Power BI не доказывает, что подключение шлюза к старой базе тоже зашифровано. Ошибку сертификата следует устранять проверкой цепочки доверия и имени сервера, а не постоянным отключением проверки.

В Import модель содержит загруженную копию данных. Ограничения SQL Server или CRM, применённые к учётной записи загрузчика, не превращаются автоматически в персональные права каждого зрителя. Для DirectQuery способ применения прав источника зависит от аутентификации и настройки SSO. Проверяйте, от чьего имени реально выполняется запрос.

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

8. Аудит: какие события действительно доступны

Для просмотра действий используют средства аудита Microsoft Purview и API активности Power BI/Fabric, в зависимости от задачи и разрешений. Это не вымышленная вкладка «Аудит действий» с произвольным сроком хранения в настройках каждого отчёта. Отслеживание пользовательской активности.

Power BI Admin API Get Activity Events позволяет запрашивать события за последние 28 дней; начало и конец запроса должны относиться к одному дню UTC. При выгрузке нужно учитывать continuation token и ограничения запросов. Для более долгой истории организуйте регулярное сохранение в защищённое хранилище. Спецификация Activity Events.

Не смешивайте срок доступности этого API со сроком хранения Purview Audit: это разные механизмы с собственными условиями. Журнал событий также не равен резервной копии и не содержит автоматически все старые значения строк CRM.

Практические сценарии мониторинга: выдача внешнего доступа, создание публичного embed-кода, выгрузки, изменение прав и неуспешные обновления. Наличие журнала само по себе не создаёт оповещение: нужны правило, ответственный и проверенный порядок реакции.

9. Что резервировать и как проверять восстановление

Microsoft описывает Backup/Restore семантических моделей через XMLA и Azure Data Lake Storage Gen2 для поддерживаемой Premium/PPU-конфигурации. Перед выбором схемы проверьте применимость к вашей модели, ёмкости и настройкам. Документация резервного копирования моделей.

Для пробного восстановления используйте отдельную рабочую область. Проверьте модель, отчёты, связи, RLS/OLS, обновление и итоговые показатели. Зафиксируйте, сколько данных допустимо потерять и сколько времени можно восстанавливать работу; частота копий должна соответствовать этим требованиям.

10. Качество данных, обновления и ответственность

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

Обновляйте Desktop, шлюз, драйверы и используемые расширения с проверкой совместимости. Power BI Report Server и соответствующий ему Desktop имеют свой цикл версий. Перед заменой рабочего решения проверьте подключение, обновление, права и контрольные итоги в отдельной среде.

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

Проверка перед передачей отчёта пользователям

1. Обычный зритель видит только разрешённые строки и поля.
2. Назначения через группы и несколько ролей дают ожидаемый результат.
3. Скрытие страницы или фильтр нельзя использовать для обхода правил модели.
4. Разрешённые экспорт и Analyze in Excel сохраняют ожидаемые ограничения данных.
5. Внешний пользователь и пользователь без назначения проверены отдельно.
6. Обновление работает от правильной идентичности; ошибка становится известна ответственному.
7. Есть проверенная версия для восстановления и инструкция возврата в рабочее состояние.
8. После отзыва доступа проверены все пути его получения, включая группы и прямое предоставление.

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