Безопасность 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 также управляет хранением данных и метаданными, используя Azure Blob и базу данных Azure SQL соответственно.

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

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

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

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

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, например [email protected], сопоставление актуального имени пользователя с UPN является простым процессом. Для организаций, которые не использовали рабочие адреса электронной почты, например [email protected], сопоставление между идентификатором 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).