Безопасность Power BI

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

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

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

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

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

Схема, показывающая архитектуру Power BI, ориентированную на кластер WFE.

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

Схема архитектуры Power BI, ориентированная на кластер Back-End.

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Power BI Desktop учитывает параметры раздела реестра, описанные в этих статьях, и создает подключения только с использованием разрешенной версии TLS на основе этих параметров реестра, если они есть.

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