Power BI Security (Безопасность в Power BI)

Подробные сведения о безопасности Power BI см. в техническом документе по безопасности Power BI.

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

Служба Power BI основана на azure, облачной инфраструктуре и платформе облачных вычислений Майкрософт. Архитектура служба Power BI основана на двух кластерах:

• Кластер веб-интерфейса (WFE). Кластер WFE управляет начальным подключением и проверкой подлинности к служба Power BI.
• Внутренний кластер. После проверки подлинности внутренний интерфейс обрабатывает все последующие взаимодействия с пользователем. Power BI использует идентификатор Microsoft Entra для хранения удостоверений пользователей и управления ими. Идентификатор Microsoft Entra также управляет хранилищем данных и метаданными с помощью BLOB-объектов Azure и База данных SQL Azure соответственно.

Архитектура Power BI

Кластер WFE использует идентификатор Microsoft Entra для проверки подлинности клиентов и предоставляет маркеры для последующих подключений клиентов к служба Power BI. Power BI использует Диспетчер трафика Azure (Диспетчер трафика) для направления трафика пользователей в ближайший центр обработки данных. Диспетчер трафика направляет запросы с помощью записи DNS клиента, пытающейся подключиться, пройти проверку подлинности и скачать статическое содержимое и файлы. Power BI использует azure сеть доставки содержимого (CDN) для эффективного распределения необходимого статического содержимого и файлов пользователям на основе географического языкового стандарта.

Внутренний кластер определяет, как клиенты, прошедшие проверку подлинности, взаимодействуют с служба Power BI. Внутренний кластер управляет визуализациями, пользовательскими панелями мониторинга, семантической моделью, отчетами, хранилищем данных, подключениями к данным, обновлением данных и другими аспектами взаимодействия с служба Power BI. Роль шлюза выступает в качестве шлюза между запросами пользователей и служба Power BI. Пользователи не взаимодействуют напрямую с ролями, кроме роли шлюза. Azure Управление API в конечном итоге обрабатывает роль шлюза.

Важно!

Через общедоступный Интернет доступны только роли Azure Управление API и шлюза. Они обеспечивают проверку подлинности, авторизацию, защиту от атак DDoS, регулирование, балансировку нагрузки, маршрутизацию и другие возможности.

Безопасность служба хранилища данных

Power BI использует два основных репозитория для хранения и управления данными:

• Данные, отправленные пользователями, обычно отправляются в Хранилище BLOB-объектов Azure.
• Все метаданные, включая элементы для самой системы, хранятся в База данных SQL Azure.

Пунктирная линия, показанная на схеме внутреннего кластера, определяет границу между двумя компонентами, доступными пользователями слева от пунктирной линии. Роли, доступные только системой, отображаются справа. Когда пользователь, прошедший проверку подлинности, подключается к службе Power BI, подключение и любой запрос клиента принимается и управляется ролью шлюза, которая затем взаимодействует от имени пользователя с остальной частью службы Power BI. Например, когда клиент пытается просмотреть панель мониторинга, роль шлюза принимает этот запрос, а затем отдельно отправляет запрос роли презентации , чтобы получить данные, необходимые браузеру для отображения панели мониторинга. В конечном итоге подключения и клиентские запросы обрабатываются Управление API Azure.

проверка подлинности пользователей;

Power BI использует идентификатор Microsoft Entra для проверки подлинности пользователей, которые входят в служба Power BI. Учетные данные входа требуются всякий раз, когда пользователь пытается получить доступ к защищенным ресурсам. Пользователи войдите в служба Power BI с помощью адреса электронной почты, с помощью которого они установили свою учетную запись Power BI. Power BI использует те же учетные данные, что и эффективное имя пользователя , и передает его ресурсам всякий раз, когда пользователь пытается подключиться к данным. Затем действующее имя пользователя сопоставляется с именем участника-пользователя и разрешается связанной учетной записи домена Windows, к которой применяется проверка подлинности.

Для организаций, использующих рабочие адреса электронной почты для входа в Power BI, напримерdavid@contoso.com, эффективное имя пользователя для сопоставления имени участника-пользователя является простым. Для организаций, которые не использовали рабочие адреса электронной почты, например david@contoso.onmicrosoft.com сопоставление идентификатора Microsoft Entra и локальных учетных данных требует правильной работы синхронизации каталогов.

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

Безопасность данных и служб

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

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

Исключение заключается в подключении к службам SQL Server Analysis Services с помощью локального шлюза данных. Панели мониторинга кэшируются в Power BI, но доступ к базовым отчетам или семантическим моделям инициирует проверку подлинности для каждого пользователя, пытающегося получить доступ к отчету или семантической модели. Доступ будет предоставлен только в том случае, если у пользователя достаточно учетных данных для доступа к данным. Дополнительные сведения см . в статье о локальном шлюзе данных.

Принудительное использование версий TLS

Администраторы сети и ИТ-администраторы могут применять требования к использованию текущего протокола TLS для любой защищенной связи в сети. Windows предоставляет поддержку версий TLS через поставщика Microsoft Schannel, дополнительные сведения см. в разделе "Протоколы" в протоколе TLS/SSL (Schannel SSP).

Это принудительно реализуется путем административного задания разделов реестра. Дополнительные сведения о принудительном применении см. в разделе "Управление протоколами SSL/TLS" и наборами шифров для AD FS.

Для защиты конечных точек power BI Desktop требуется TLS (транспортная безопасность) версии 1.2 (или более поздней). Веб-браузеры и другие клиентские приложения, использующие версии TLS до TLS 1.2, не смогут подключаться. Если требуются более новые версии TLS, Power BI Desktop учитывает параметры раздела реестра, описанные в этих статьях, и только создает подключения, соответствующие требованиям к версии TLS, на основе этих параметров реестра при наличии.

Дополнительные сведения о настройке этих разделов реестра см. в параметрах реестра tls.