Технический документ по безопасности Power BI

Сводка. Power BI — это онлайн-служба программного обеспечения (SaaS или программное обеспечение как услуга), которая позволяет легко и быстро создавать панели мониторинга бизнес-аналитики самообслуживания, отчеты, семантические модели (ранее известные как наборы данных) и визуализации. С помощью Power BI вы можете подключаться к различным источникам данных, объединять и формировать данные из этих подключений, а затем создавать отчеты и панели мониторинга, которые можно предоставить другим пользователям.

Писатели: Ицхак Кессельман, Пэдди Осборн, Мэтт Нили, Тони Бенсик, Srinivasan Turuvekere, Кристиан Петкулеску, Ади Регев, Навен Сиварадж, Бен Глаштейн, Евгений Тшиорни, Артхи Рамасубраманский Ийер, Сид Джаядеван, Рон Хадаван, Рон Хадаван, Рон Хадиван, Рон Хадайер, Рон Хадайер, Рон Хадиван, Рон Хадиван, Рон Хадаев, Майкл Ройт, Хейме Таркино, Геннади Пэтс, Орион Ли, Юри Березански, Майя Шэнхава, Ромита Чаттопадья, Ярив Маймон, Богдан Криват

Технические рецензенты: Кристиан Петкулеску, Амир Netz, Сергей Гандоров

Область применения: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Примечание.

Вы можете сохранить или распечатать этот белый документ , выбрав "Печать " в браузере, а затем нажмите кнопку "Сохранить как PDF".

Введение

Power BI — это онлайн-служба программного обеспечения (SaaS или программное обеспечение как услуга), которая позволяет легко и быстро создавать панели мониторинга бизнес-аналитики, отчеты, семантические модели и визуализации. С помощью Power BI вы можете подключаться к различным источникам данных, объединять и формировать данные из этих подключений, а затем создавать отчеты и панели мониторинга, которые можно предоставить другим пользователям.

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

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

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

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

Все начинается с фундамента. После грубого периода в начале 2000-х годов Корпорация Майкрософт сделала огромные инвестиции в решение своих уязвимостей безопасности, и в последующие десятилетия построил сильный стек безопасности, который идет так глубоко, как ядро ядра на биография микросхеме и расширяет весь путь до конечных пользователей. Эти глубокие инвестиции продолжаются, и сегодня более 3500 инженеров Майкрософт занимаются созданием и повышением стека безопасности Майкрософт и упреждающим решением постоянно изменяющегося ландшафта угроз. С миллиардами компьютеров, триллионами имен входа и бесчисленными zettabytes информации, доверенными защите Майкрософт, компания в настоящее время обладает самым передовым стеком безопасности в технологической отрасли и широко рассматривается как глобальный лидер в борьбе с вредоносными субъектами.

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

Чтобы обеспечить комплексное решение для защиты конфиденциальных активов, группа продуктов, необходимая для решения сложных проблем клиентов на нескольких одновременных фронтах:

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

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

Служба Power BI регулируется условиями использования веб-служб Майкрософт и заявлением о конфиденциальности Microsoft Enterprise. Сведения о расположении обработки данных см. в разделе "Расположение условий обработки данных" условий использования веб-служб Майкрософт и надстройки защиты данных. Для сведений о соответствии Центр управления безопасностью Майкрософт является основным ресурсом для Power BI. Команда Power BI трудится над тем, чтобы привлечь своих клиентов последние инновации и производительность. Дополнительные сведения о соответствии в предложениях соответствия требованиям Майкрософт.

Служба Power BI следует жизненному циклу разработки безопасности (SDL), строгим методикам безопасности, поддерживающим требования к обеспечению безопасности и соответствию требованиям. SDL помогает разработчикам создавать более безопасное программное обеспечение, уменьшая количество уязвимостей и степень серьезности уязвимостей в программном обеспечении, уменьшая затраты на разработку. Узнайте больше в Методики жизненного цикла разработки защищенных приложений Microsoft.

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

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

Кластер веб-интерфейса (WFE)

Кластер WFE предоставляет браузер пользователя с начальным содержимым HTML-страницы на загрузке сайта и указателями на содержимое CDN, используемое для отрисовки сайта в браузере.

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

Статические ресурсы, такие как *.js, *.css и файлы изображений, в основном хранятся в azure сеть доставки содержимого (CDN) и извлекаются непосредственно браузером. Обратите внимание, что развертывания кластеров для государственных организаций являются исключением из этого правила, и по соображениям соответствия требованиям cdN опущены и вместо этого используют кластер WFE из соответствующего региона для размещения статического содержимого.

Серверный кластер Power BI (BE)

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

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

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

Каждый серверный кластер состоит из нескольких виртуальных машин, объединенных в несколько масштабируемых наборов, настроенных для выполнения определенных задач, ресурсов с отслеживанием состояния, таких как базы данных SQL, учетные записи хранения, автобусы служб, кэши и другие необходимые облачные компоненты.

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

Внутренние функции обслуживаются микрослужбами, работающими на разных компьютерах в виртуальной сети кластера, которые недоступны извне, за исключением двух компонентов, к которым можно получить доступ из общедоступного Интернета:

• Служба шлюза
• Управление API Azure

Инфраструктура Power BI Premium

Power BI Premium предлагает услугу для подписчиков, которым требуются функции Power BI уровня "Премиум", такие как расширенный ИИ, распространение для нелицензированных пользователей и т. д. Когда клиент регистрирует подписку Power BI Premium, емкость Premium создается с помощью Azure Resource Manager.

Емкости Power BI Premium размещаются в внутренних кластерах, которые не зависят от обычной серверной части Power BI, см. выше). Это обеспечивает лучшую изоляцию, выделение ресурсов, поддержку, изоляцию безопасности и масштабируемость предложения Premium.

На следующей схеме показана архитектура инфраструктуры Power BI Premium:

Подключение к инфраструктуре Power BI Premium можно сделать различными способами в зависимости от сценария пользователя. Клиенты Power BI Premium могут быть браузером пользователя, обычной серверной частью Power BI, прямыми подключениями через клиенты XMLA, API ARM и т. д.

Инфраструктура Power BI Premium в регионе Azure состоит из нескольких кластеров Power BI Premium (минимальное значение — одно). Большинство ресурсов Класса Premium инкапсулируются в кластере (например, вычисление), а также существуют некоторые общие региональные ресурсы (например, хранилище метаданных). Инфраструктура уровня "Премиум" позволяет двумя способами достижения горизонтальной масштабируемости в регионе: увеличение ресурсов внутри кластеров и /или добавление дополнительных кластеров по требованию по мере необходимости (если ресурсы кластера приближаются к их ограничениям).

Основой каждого кластера являются вычислительные ресурсы, управляемые Масштабируемые наборы виртуальных машин и Azure Service Fabric. Масштабируемые наборы виртуальных машин и Service Fabric позволяют быстро и безболезненно увеличивать вычислительные узлы по мере роста использования и оркестрации развертывания, управления и мониторинга служб и приложений Power BI Premium.

Существует множество связанных ресурсов, которые обеспечивают безопасную и надежную инфраструктуру: подсистемы балансировки нагрузки, виртуальные сети, группы безопасности сети, служебной шины, хранилища и т. д. Все секреты, ключи и сертификаты, необходимые для Power BI Premium, управляются исключительно Azure Key Vault . Любая проверка подлинности выполняется через интеграцию с идентификатором Microsoft Entra (ранее известным как Azure Active Directory).

Любой запрос, поступающий в инфраструктуру Power BI Premium, сначала переходит к интерфейсным узлам — они единственные узлы, доступные для внешних подключений. Остальные ресурсы скрыты за виртуальными сетями. Интерфейсные узлы проходят проверку подлинности запроса, обрабатывают его или перенаправляют его на соответствующие ресурсы (например, серверные узлы).

Внутренние узлы предоставляют большую часть возможностей и функций Power BI Premium.

Power BI Mobile

Power BI Mobile — это коллекция приложений, предназначенных для трех основных мобильных платформ: Android, iOS и Windows (UWP). Вопросы безопасности для приложений Power BI Mobile делятся на две категории:

• Взаимодействие устройств
• Приложение и данные на устройстве

Для связи с устройствами все приложения Power BI Mobile взаимодействуют с служба Power BI и используют те же последовательности подключения и проверки подлинности, используемые браузерами, которые подробно описаны ранее в этом техническом документе. Мобильные приложения Power BI для iOS и Android создают сеанс браузера в самом приложении, в то время как мобильное приложение Windows открывает брокер для установления канала связи с Power BI (для процесса входа).

В следующей таблице показана поддержка проверки подлинности на основе сертификатов (CBA) для Power BI Mobile на основе платформы мобильных устройств:

Поддержка CBA	iOS	Android	Окна
Power BI (вход в службу)	Поддерживается	Поддерживается	Не поддерживается
Локальные службы ADFS SSRS (подключение к серверу SSRS)	Не поддерживается	Поддерживается	Не поддерживается
Прокси приложения SSRS	Поддерживается	Поддерживается	Не поддерживается

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

Приложение Power BI хранит данные на устройстве, которое упрощает использование приложения:

• Идентификатор и маркеры обновления Microsoft Entra хранятся в защищенном механизме на устройстве с помощью стандартных мер безопасности.
• Данные и параметры (пары "ключ-значение" для конфигурации пользователя) кэшируются в хранилище на устройстве и могут быть зашифрованы ОС. В iOS это выполняется автоматически, когда пользователь задает секретный код. В Android это можно настроить в параметрах. В Windows она выполняется с помощью BitLocker.
• Для приложений Android и iOS данные и параметры (пары "ключ-значение" для конфигурации пользователя) кэшируются в хранилище на устройстве в песочнице и внутреннем хранилище, доступном только приложению. Для приложения Windows данные доступны только пользователем (и системным администратором).
• Геолокация включается или отключается самим пользователем. Если включено, данные геолокации не сохраняются на устройстве и не передаются в Microsoft.
• Уведомления включаются или отключаются самим пользователем. Если этот параметр включен, Android и iOS не поддерживают требования к месту расположения географических данных для уведомлений.

Шифрование данных можно улучшить, применяя шифрование на уровне файлов с помощью Microsoft Intune, программной службы, которая обеспечивает управление мобильными устройствами и приложениями. Все три платформы, для которых Power BI Mobile доступна поддержка Intune. С включенным и настроенным Intune данные на мобильном устройстве шифруются, и само приложение Power BI не может быть установлено на SD-карта. Дополнительные сведения о Microsoft Intune.

Приложение Windows также поддерживает Windows Information Protection (WIP).

Для реализации единого входа некоторые защищенные значения хранилища, связанные с проверкой подлинности на основе маркеров, доступны для других сторонних приложений Майкрософт (например, Microsoft Authenticator) и управляются библиотекой проверки подлинности Майкрософт (MSAL).

Кэшированные данные Power BI Mobile удаляются при удалении приложения, когда пользователь выходит из Power BI Mobile или когда пользователь не сможет войти (например, после истечения срока действия маркера или изменения пароля). Кэш данных включает панели мониторинга и отчеты, которые ранее были доступны из приложения Power BI Mobile.

Power BI Mobile не обращается к другим папкам приложений или файлам на устройстве.

Приложения Power BI для iOS и Android позволяют защитить данные путем настройки дополнительной идентификации, например предоставления идентификатора лица, Touch ID или секретного кода для iOS и биография метрических данных (идентификатор отпечатка пальца) для Android. Дополнительные сведения о дополнительной идентификации.

Проверка подлинности в служба Power BI

Проверка подлинности пользователя в служба Power BI состоит из ряда запросов, ответов и перенаправлений между браузером пользователя и служба Power BI или службами Azure, используемыми Power BI. Эта последовательность описывает процесс проверки подлинности пользователей в Power BI, который следует потоку предоставления кода проверки подлинности Microsoft Entra. Дополнительные сведения о параметрах моделей проверки подлинности пользователей организации (модели входа) см. в разделе "Выбор модели входа для Microsoft 365".

Последовательность проверки подлинности

Последовательность проверки подлинности пользователя для служба Power BI происходит, как описано в следующих шагах, которые показаны на изображении, следующем за ними.

1. Пользователь инициирует подключение к служба Power BI из браузера, введя адрес Power BI в адресной строке или выбрав вход на страницу маркетинга Power BI (https://powerbi.microsoft.com). Подключение устанавливается с помощью TLS и HTTPS, а все последующие связи между браузером и служба Power BI используют ПРОТОКОЛ HTTPS.

2. Диспетчер трафика Azure проверка записи DNS пользователя, чтобы определить наиболее подходящий (обычно ближайший) центр обработки данных, в котором развернут Power BI, и отвечает на DNS с IP-адресом кластера WFE, в который должен отправляться пользователь.

3. Затем WFE возвращает HTML-страницу клиенту браузера, который содержит ссылку на библиотеку MSAL.js, необходимую для запуска потока входа.

4. Клиент браузера загружает HTML-страницу, полученную из WFE, и перенаправляет пользователя на страницу входа в Microsoft Online Services.

5. После проверки подлинности пользователя страница входа перенаправляет пользователя на страницу WFE Power BI с кодом проверки подлинности.

6. Клиент браузера загружает HTML-страницу и использует код проверки подлинности для запроса маркеров (доступа, идентификатора, обновления) из идентификатора Microsoft Entra.

7. Идентификатор клиента пользователя используется клиентом браузера для запроса глобальной службы Power BI, которая поддерживает список клиентов и их расположения серверного кластера Power BI. Глобальная служба Power BI определяет, какой серверный кластер службы Power BI содержит клиент пользователя и возвращает URL-адрес внутреннего кластера Power BI обратно клиенту.

8. Теперь клиент может взаимодействовать с API внутреннего кластера Power BI, используя маркер доступа в заголовке авторизации для HTTP-запросов. Маркер доступа Microsoft Entra будет иметь дату окончания срока действия в соответствии с политиками Microsoft Entra, а для поддержания текущего сеанса клиент Power BI в браузере пользователя будет выполнять периодические запросы на продление маркера доступа до истечения срока его действия.

В редких случаях, когда проверка подлинности на стороне клиента завершается сбоем из-за непредвиденной ошибки, код пытается вернуться к использованию проверки подлинности на стороне сервера в WFE. Дополнительные сведения о потоке проверки подлинности на стороне сервера см. в разделе "Вопросы и ответы" в конце этого документа.

Место расположения данных

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

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

Несколько географических регионов (с несколькими географическими регионами)

Некоторые организации имеют глобальное присутствие и могут требовать служба Power BI в нескольких географических регионах Azure. Например, бизнес может иметь свои штаб-квартиры в США, но также может заниматься бизнесом в других географических районах, таких как Австралия. В таких случаях для бизнеса может потребоваться, чтобы некоторые данные Power BI оставались неактивными в удаленном регионе, чтобы соответствовать местным нормативным требованиям. Эта функция служба Power BI называется несколькими географическими.

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

Дополнительные сведения о создании развертываний Power BI и управлении ими, охватывающих несколько географических регионов Azure, см. в статье "Настройка поддержки нескольких регионов Azure" для Power BI Premium .

Регионы и центры обработки данных

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

Корпорация Майкрософт также предоставляет центры обработки данных для независимых сущностей. Дополнительные сведения о доступности служба Power BI для национальных и региональных облаков см. в разделе "Национальные и региональные облака Power BI".

Обработка данных

В этом разделе описаны методики обработки данных Power BI, когда речь идет о хранении, обработке и передаче данных клиента.

Неактивные данные

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

• Хранилище Azure
• Базы данных SQL Azure

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

Все данные, сохраненные Power BI, шифруются по умолчанию с помощью ключей, управляемых Корпорацией Майкрософт. Данные клиента, хранящиеся в База данных SQL Azure, полностью зашифрованы с помощью технологии прозрачное шифрование данных (TDE) Azure SQL. Данные клиента, хранящиеся в хранилище BLOB-объектов Azure, шифруются с помощью шифрования служба хранилища Azure.

При необходимости организации могут использовать Power BI Premium для шифрования неактивных данных, импортированных в семантику модели. Этот подход часто описывается как собственный ключ (BYOK). Использование BYOK помогает гарантировать, что даже в случае ошибки оператора службы данные клиента не будут предоставляться — то, что невозможно легко достичь с помощью прозрачного шифрования на стороне службы. Дополнительные сведения см. в статье "Создание собственных ключей шифрования для Power BI ".

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

Режим семантической модели (тип)	Данные, сохраненные в Power BI
Import	Да
DirectQuery	No
Live Подключение	No
Составной	Если содержится источник данных импорта
Потоковая передача	Если настроено сохранение

Независимо от используемого семантического режима модели Power BI может временно кэшировать все извлеченные данные для оптимизации производительности запросов и отчетов.

Обработка данных

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

Передаваемые данные

Для Power BI требуется шифрование всего входящего HTTP-трафика с помощью TLS 1.2 или более поздней версии. Все запросы, пытающиеся использовать службу с TLS 1.1 или более поздней, будут отклонены.

Проверка подлинности в источниках данных

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

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

Если источник данных подключен непосредственно с помощью предварительно настроенных учетных данных, предварительно настроенные учетные данные используются для подключения к источнику данных при просмотре данных пользователем. Если источник данных подключен непосредственно с помощью единого входа, учетные данные текущего пользователя используются для подключения к источнику данных при просмотре данных пользователем. При использовании с единым входом безопасность на уровне строк (RLS) и /или безопасность на уровне объектов (OLS) можно реализовать в источнике данных. Это позволяет пользователям просматривать только данные, к которых они имеют права доступа. При подключении к источникам данных в облаке проверка подлинности Microsoft Entra используется для единого входа; для локальных источников данных, Kerberos, языка разметки утверждений безопасности (SAML) и идентификатора Microsoft Entra поддерживаются.

Если источник данных — Azure Analysis Services или локальные службы Analysis Services, а также RLS и/или OLS настроен, служба Power BI будет применять этот уровень безопасности строк, и пользователи, у которых нет достаточных учетных данных для доступа к базовым данным (которые могут быть запросом, используемым на панели мониторинга, отчете или другом артефакте данных), не будут видеть данные, для которых они не имеют достаточных привилегий.

Функции уровня "Премиум"

Архитектура потоков данных

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

Каждый настроенный источник данных привязан к клиентской технологии для доступа к такому источнику данных. Структура учетных данных, необходимых для доступа к ним, формируется для сопоставления необходимых сведений о реализации источника данных. Логика преобразования применяется службами Power Query во время выполнения данных. Для потоков данных класса Premium службы Power Query выполняются на внутренних узлах. Данные могут быть извлечены непосредственно из облачных источников или через шлюз, установленный в локальной среде. При извлечении непосредственно из облачного источника в службу или шлюз транспорт использует методологию защиты, относящаяся к клиентской технологии, если применимо. При передаче данных из шлюза в облачную службу он шифруется. См. приведенный выше раздел " Данные в транзите ".

Если в указанных клиентом источниках данных требуются учетные данные для доступа, владелец или создатель потока данных предоставит их во время разработки. Они хранятся с помощью стандартного хранилища учетных данных на уровне продукта. См. приведенный выше раздел "Проверка подлинности в источниках данных". Существуют различные подходы, которые пользователи могут настроить для оптимизации сохраняемости и доступа к данным. По умолчанию данные помещаются в учетную запись хранения Power BI, принадлежащей и защищенной. служба хранилища шифрование в контейнерах хранилища BLOB-объектов для защиты данных во время его хранения. См. раздел " Данные в неактивных данных" ниже. Однако пользователи могут настроить собственную учетную запись хранения, связанную с собственной подпиской Azure. При этом субъекту служба Power BI предоставляется доступ к этой учетной записи хранения, чтобы он мог записывать данные во время обновления. В этом случае владелец ресурса хранилища отвечает за настройку шифрования в настроенной учетной записи хранения ADLS. Данные всегда передаются в хранилище BLOB-объектов с помощью шифрования.

Так как производительность при доступе к учетным записям хранения может быть неоптимальной для некоторых данных, пользователи также могут использовать подсистему вычислений, размещенную в Power BI, для повышения производительности. В этом случае данные избыточно хранятся в базе данных SQL, доступной для DirectQuery через доступ к серверной системе Power BI. Данные всегда шифруются в файловой системе. Если пользователь предоставляет ключ для шифрования данных, хранящихся в базе данных SQL, этот ключ будет использоваться для удвоения шифрования.

При запросе с помощью DirectQuery протокол HTTPS зашифрованного транспортного протокола используется для доступа к API. Все дополнительное или косвенное использование DirectQuery контролируется теми же элементами управления доступом, которые ранее описаны. Так как потоки данных всегда привязаны к рабочей области, доступ к данным всегда заключается ролью пользователя в этой рабочей области. Пользователь должен иметь по крайней мере доступ на чтение, чтобы иметь возможность запрашивать данные с помощью любых средств.

Когда Power BI Desktop используется для доступа к данным в потоке данных, сначала он должен пройти проверку подлинности пользователя с помощью идентификатора Microsoft Entra, чтобы определить, имеет ли пользователь достаточные права для просмотра данных. В этом случае ключ SaS приобретается и используется для доступа к хранилищу непосредственно с помощью протокола HTTPS зашифрованного транспортного протокола.

Обработка данных на протяжении всего конвейера выдает события аудита Office 365. Некоторые из этих событий будут записывать операции, связанные с безопасностью и конфиденциальностью.

Отчеты, разбитые на страницы

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

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

Выражения создаются автором отчета с доступом к широкому спектру возможностей платформы .NET. Обработка и выполнение отчетов с разбивкой на страницы выполняется в песочнице.

Определения отчетов с разбивкой на страницы (RDL) хранятся в Power BI, а также для публикации отчета с разбивкой на страницы, который пользователь должен пройти проверку подлинности и авторизацию таким же образом, как описано в разделе проверки подлинности в службе Power BI выше.

Маркер Microsoft Entra, полученный во время проверки подлинности, используется для обмена данными непосредственно из браузера с кластером Power BI Premium.

В Power BI Premium среда выполнения служба Power BI предоставляет соответствующую изолированную среду выполнения для каждого отчета. К ним относятся случаи, когда отчеты, отрисовываемые, принадлежат рабочим областям, назначенным той же емкости.

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

Для поддержки таких функций, как карты Bing или вызовы к Функции Azure, песочница имеет доступ к Интернету.

Встроенная аналитика Power BI

Независимые поставщики программного обеспечения (независимые поставщики программного обеспечения) и поставщики решений имеют два основных режима внедрения артефактов Power BI в веб-приложения и порталы: внедрение для вашей организации и внедрение для клиентов. Артефакт внедрен в IFrame на портале или приложении. IFrame не допускается считывать или записывать данные из внешнего веб-приложения или портала, а взаимодействие с IFrame выполняется с помощью пакета SDK клиента Power BI с помощью сообщений POST.

В случае внедрения для вашей организации пользователи Microsoft Entra получают доступ к своему содержимому Power BI через порталы, настроенные их предприятиями и ITs. Все политики и возможности Power BI, описанные в этом документе, такие как безопасность на уровне строк (RLS) и безопасность на уровне объектов (OLS), автоматически применяются ко всем пользователям независимо от того, обращаются ли они к Power BI через портал Power BI или через настраиваемые порталы.

В сценарии внедрения для клиентов поставщики программного обеспечения обычно имеют клиенты Power BI и элементы Power BI (панели мониторинга, отчеты, семантические модели и другие). Это ответственность внутренней службы isV для проверки подлинности своих конечных пользователей и принятия решения о том, какие артефакты и какой уровень доступа подходит для этого конечного пользователя. Решения политики поставщика программного обеспечения шифруются в токене внедрения, созданном Power BI, и передаются в серверную часть isV для дальнейшего распространения конечным пользователям в соответствии с бизнес-логикой поставщика программного обеспечения. Конечные пользователи, использующие браузер или другие клиентские приложения, не могут расшифровывать или изменять маркеры внедрения. Клиентские пакеты SDK, такие как API клиента Power BI, автоматически добавляют зашифрованный маркер внедрения в запросы Power BI в качестве авторизации: заголовок EmbedToken . На основе этого заголовка Power BI будет применять все политики (например, доступ или RLS), точно так же, как было указано поставщиком программного обеспечения во время создания.

Чтобы включить внедрение и автоматизацию, а также создать маркеры внедрения, описанные выше, Power BI предоставляет широкий набор ИНТЕРФЕЙСов REST API. Эти ИНТЕРФЕЙСы REST API Power BI поддерживают как делегированные пользователем, так и методы проверки подлинности и авторизации субъекта-службы Microsoft Entra.

Встроенная аналитика Power BI и интерфейсы REST API поддерживают все возможности сетевой изоляции Power BI, описанные в этой статье: например, теги служб и Приватный канал.

Функции ИИ

В настоящее время Power BI поддерживает две широкие категории функций ИИ в продукте: визуальные элементы ИИ и обогащения ИИ. Функции искусственного интеллекта визуального уровня включают такие возможности, как ключевые факторы влияния, декомпозиция-дерево, smart-Narrative, обнаружение аномалий, R-visual, Python-visual, кластеризация, прогнозирование, Q&A, быстрый Аналитика и т. д. Возможности обогащения ИИ включают такие возможности, как AutoML, Машинное обучение Azure, CognitiveServices, преобразования R/Python и т. д.

Большинство функций, которые упоминание выше, поддерживаются как в общих, так и в премиум рабочих областях. Однако AutoML и CognitiveServices поддерживаются только в рабочих областях Premium из-за ограничений IP-адресов. Сегодня с интеграцией AutoML в Power BI пользователь может создавать и обучать пользовательскую модель машинного обучения (например, прогнозирование, классификацию, регрессию и т. д.) и применять ее для получения прогнозов при загрузке данных в поток данных, определенный в рабочей области Premium. Кроме того, пользователи Power BI могут применять несколько API CognitiveServices, например TextAnalytics и ImageTagging, для преобразования данных перед загрузкой в модель потока данных или семантической модели, определенной в рабочей области Premium.

Функции обогащения ИИ класса Premium можно лучше рассматривать как коллекцию функций и преобразований без отслеживания состояния, которые могут использоваться пользователями Power BI в конвейерах интеграции данных, используемых семантической моделью Или потоком данных Power BI. Обратите внимание, что к этим функциям также можно обращаться из текущих сред разработки потоков данных и семантических моделей в службе Power BI и Power BI Desktop. Эти функции и преобразования ИИ всегда выполняются в рабочей области класса Premium или емкости. Эти функции отображаются в Power BI в качестве источника данных, для которого требуется маркер Microsoft Entra для пользователя Power BI, используюющего функцию ИИ. Эти источники данных искусственного интеллекта являются особыми, так как они не отображают какие-либо собственные данные, и они предоставляют только эти функции и преобразования. Во время выполнения эти функции не делают исходящие вызовы другим службам для передачи данных клиента. Давайте рассмотрим сценарии premium отдельно, чтобы понять шаблоны связи и соответствующие сведения, связанные с безопасностью, относящиеся к ним.

Для обучения и применения модели AutoML Power BI использует пакет SDK для Azure AutoML и выполняет все учебные курсы в емкости Power BI клиента. Во время итерации обучения Power BI вызывает службу экспериментирования Машинное обучение Azure, чтобы выбрать подходящую модель и гиперпараметров для текущей итерации. В этом исходящем вызове отправляются только соответствующие метаданные эксперимента (например, точность, алгоритм машин, параметры алгоритма и т. д.) из предыдущей итерации. Обучение AutoML создает модель ONNX и данные отчета об обучении, которые затем сохраняются в потоке данных. Позже пользователи Power BI могут применить обученную модель машинного обучения в качестве преобразования для эксплуатации модели машинного обучения на запланированной основе. Для API-интерфейсов TextAnalytics и ImageTagging Power BI не вызывает API-интерфейсы службы CognitiveServices, а использует внутренний пакет SDK для запуска API в емкости Power BI Premium. Сегодня эти API поддерживаются как в потоках данных Power BI, так и в семантических моделях. При создании модели данных в Power BI Desktop пользователи могут получить доступ только к этой функции, если у них есть доступ к рабочей области Power BI premium. Поэтому клиентам предлагается предоставить свои учетные данные Microsoft Entra.

Сетевая изоляция

В этом разделе описаны расширенные функции безопасности в Power BI. Некоторые функции имеют определенные требования к лицензированию. Дополнительные сведения см. в разделах ниже.

Теги служб

Тег службы представляет группу префиксов IP-адресов из определенной службы Azure. Это помогает свести к минимуму сложность частых обновлений правил безопасности сети. Клиенты могут использовать теги служб для определения элементов управления доступом к сети в группах безопасности сети или Брандмауэр Azure. Клиенты могут использовать теги служб вместо определенных IP-адресов при создании правил безопасности. Указав имя тега службы (например PowerBI, в соответствующем поле источника или назначения (для API) правила, клиенты могут разрешить или запретить трафик соответствующей службы. Корпорация Майкрософт управляет префиксами адресов, входящих в тег службы, и автоматически обновляет этот тег при изменении адресов.

интеграция Приватный канал

Сеть Azure предоставляет функцию Приватный канал Azure, которая позволяет Power BI обеспечить безопасный доступ через частные конечные точки сети Azure. При использовании Приватный канал Azure и частных конечных точек трафик данных отправляется в частном порядке с помощью магистральной сетевой инфраструктуры Майкрософт, поэтому данные не проходят через Интернет.

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

Использование Приватный канал с Power BI обеспечивает следующие преимущества:

• Приватный канал гарантирует, что трафик будет передаваться через магистраль Azure в частную конечную точку для облачных ресурсов Azure.
• Для изоляции сетевого трафика от инфраструктуры, не основанной на Azure, например локального доступа, клиентам потребуется настроить ExpressRoute или виртуальную частную сеть (VPN).

Дополнительные сведения см . по приватным ссылкам для доступа к Power BI .

Подключение к виртуальной сети (предварительная версия — скоро)

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

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

Ниже приведен обзор того, что происходит при взаимодействии с отчетом Power BI, подключенным к источнику данных в виртуальной сети с помощью шлюзов виртуальных сетей:

1. Облачная служба Power BI (или одна из других поддерживаемых облачных служб) запускает запрос и отправляет запрос, сведения об источнике данных и учетные данные в службу виртуальной сети Power Platform (VNet PP).

2. Затем служба виртуальной сети PP безопасно внедряет контейнер, на котором запущен шлюз виртуальной сети, в подсеть. Теперь этот контейнер может подключаться к службам данных, доступным из этой подсети.

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

4. Шлюз виртуальной сети получает запрос и подключается к источникам данных с этими учетными данными.

5. Запрос затем отправляется в источник данных для выполнения.

6. После выполнения результаты отправляются в шлюз виртуальной сети, а служба виртуальной сети PP безопасно отправляет данные из контейнера в облачную службу Power BI.

Эта функция будет доступна в общедоступной предварительной версии в ближайшее время.

Субъекты-службы

Power BI поддерживает использование субъектов-служб. Сохраните все учетные данные субъекта-службы, используемые для шифрования или доступа к Power BI в Key Vault, назначьте правильные политики доступа в хранилище и регулярно просматривайте разрешения на доступ.

Дополнительные сведения см. в статье "Автоматизация рабочих областей Premium" и задач семантической модели с помощью субъектов-служб.

Microsoft Purview для Power BI

Защита информации Microsoft Purview

Power BI глубоко интегрирован с Защита информации Microsoft Purview. Защита информации Microsoft Purview позволяет организациям иметь единое интегрированное решение для классификации, маркировки, аудита и соответствия требованиям в Azure, Power BI и Office.

Если в Power BI включена защита информации:

• Конфиденциальные данные, как в служба Power BI, так и в Power BI Desktop, можно классифицировать и помечать с помощью одинаковых меток конфиденциальности, используемых в Office и Azure.
• Политики управления можно применять при экспорте содержимого Power BI в Excel, PowerPoint, PDF, Word или PBIX-файлы , чтобы обеспечить защиту данных даже при выходе из Power BI.
• Легко классифицировать и защищать PBIX-файлы в Power BI Desktop, как и в приложениях Excel, Word и PowerPoint. Файлы можно легко пометить в соответствии с уровнем конфиденциальности. Кроме того, они могут быть зашифрованы, если они содержат конфиденциальные бизнес-данные, гарантируя, что только авторизованные пользователи могут изменять эти файлы.
• Книги Excel автоматически наследуют метки конфиденциальности при подключении к Power BI (предварительная версия), что позволяет поддерживать сквозную классификацию и применять защиту при анализе семантических моделей Power BI в Excel.
• Метки конфиденциальности, применяемые к отчетам и панелям мониторинга Power BI, отображаются в мобильных приложениях Power BI и Android.
• Метки конфиденциальности сохраняются при внедрении отчета Power BI в Teams, SharePoint или защищенного веб-сайта. Это помогает организациям поддерживать классификацию и защиту при экспорте при внедрении содержимого Power BI.
• Наследование меток при создании нового содержимого в служба Power BI гарантирует, что метки, примененные к семантических моделях или меткам данных в служба Power BI, будут применяться к новому содержимому, созданному поверх этих семантических моделей и меток данных.
• API проверки администратора Power BI могут извлекать метку конфиденциальности элемента Power BI, позволяя администраторам Power BI и InfoSec отслеживать метки в служба Power BI и создавать отчеты исполнительной власти.
• API администрирования Power BI позволяют центральным командам программно применять метки конфиденциальности к содержимому в служба Power BI.
• Центральные команды могут создавать политики обязательных меток для применения меток к новому или измененном содержимому в Power BI.
• Центральные команды могут создавать политики меток по умолчанию, чтобы гарантировать применение метки конфиденциальности ко всем новым или измененным содержимому Power BI.
• Автоматическая метка конфиденциальности нижнего потока в служба Power BI гарантирует, что при применении или изменении метки на семантической модели или datamart метка будет автоматически применена или изменена на всех подчиненных содержимом, подключенных к семантической модели или datamart.

Дополнительные сведения см. в разделе "Метки конфиденциальности" в Power BI.

политики Защита от потери данных Microsoft Purview (DLP) для Power BI (предварительная версия)

Политики защиты от потери данных Microsoft Purview могут помочь организациям снизить риск утечки конфиденциальных бизнес-данных из Power BI. Политики защиты от потери данных могут помочь им соответствовать требованиям правительственных или отраслевых правил, таких как GDPR (Общее регулирование защиты данных Европейского союза) или CCPA (Закон о конфиденциальности потребителей Калифорнии) и убедиться, что их данные в Power BI управляются.

При настройке политик защиты от потери данных для Power BI выполните следующие действия.

• Все семантические модели в рабочих областях, указанных в политике, оцениваются политикой.
• Вы можете определить, когда конфиденциальные данные передаются в емкости Premium. Политики защиты от потери данных могут обнаруживать следующее:
  • Метки конфиденциальности.
  • Типы конфиденциальной информации. Поддерживаются более 260 типов. Обнаружение типов конфиденциальной информации зависит от сканирования содержимого Microsoft Purview.
• При обнаружении семантической модели, определяемой как конфиденциальной, можно увидеть настраиваемый совет политики, который помогает понять, что нужно сделать.
• Если вы являетесь владельцем семантической модели, вы можете переопределить политику и предотвратить определение семантической модели как "конфиденциальной", если у вас есть допустимая причина для этого.
• Если вы являетесь владельцем семантической модели, вы можете сообщить о проблеме с политикой, если заключить, что тип конфиденциальной информации был ложно идентифицирован.
• Можно вызвать автоматическое устранение рисков, например оповещения администратора безопасности.

Дополнительные сведения см. в политиках защиты от потери данных для Power BI.

Microsoft Defender для облака приложения для Power BI

Microsoft Defender для облака Apps является одним из ведущих брокеров безопасности доступа к облаку, названных лидером в Gartner Magic Quadrant для рынка брокера безопасности доступа к облаку (CASB). Defender для облака Приложения используются для защиты использования облачных приложений. Она позволяет организациям отслеживать и контролировать сеансы Power BI в режиме реального времени, такие как доступ пользователей с неуправляемых устройств. Администраторы безопасности могут определять политики для управления действиями пользователей, такими как скачивание отчетов с конфиденциальной информацией.

С помощью приложений Defender для облака организации могут получить следующие возможности защиты от потери данных:

• Задайте элементы управления в режиме реального времени для принудительного применения рискованных сеансов пользователей в Power BI. Например, если пользователь подключается к Power BI из-за пределов страны или региона, сеанс можно отслеживать с помощью элементов управления Defender для облака Apps в режиме реального времени и рискованных действий, таких как загрузка данных с меткой конфиденциальности с меткой конфиденциальности "Строго конфиденциально".
• Изучите действия пользователя Power BI с помощью журнала действий Defender для облака Apps. Журнал действий Defender для облака Apps включает действие Power BI, записанное в журнале аудита Office 365, которое содержит сведения обо всех действиях пользователя и администратора, а также сведения о метках конфиденциальности для соответствующих действий, таких как применение, изменение и удаление меток. Администратор могут использовать расширенные фильтры Defender для облака Приложения и быстрые действия для эффективного исследования проблем.
• Создайте настраиваемые политики для оповещения о подозрительных действиях пользователей в Power BI. Функцию политики действий Defender для облака Приложения можно использовать для определения собственных пользовательских правил, чтобы помочь определить поведение пользователя, которое отклоняется от нормы, и даже, возможно, действовать автоматически, если кажется слишком опасным.
• Обратитесь к встроенному обнаружению аномалий Defender для облака Apps. Политики обнаружения аномалий приложений Defender для облака предоставляют нестандартную аналитику поведения пользователей и машинное обучение, чтобы вы были готовы к выполнению расширенного обнаружения угроз в облачной среде. Если политика обнаружения аномалий идентифицирует подозрительное поведение, он активирует оповещение системы безопасности.
• Роль администратора Power BI на портале Defender для облака Apps. Defender для облака Приложения предоставляют роль администратора для конкретного приложения, которую можно использовать для предоставления администраторам Power BI только необходимых им разрешений на доступ к данным Power BI на портале, таким как оповещения, пользователи, подверженные риску, журналы действий и другие сведения, связанные с Power BI.

Дополнительные сведения см. в разделе "Использование элементов управления приложениями Microsoft Defender для облака" в Power BI.

Предварительный просмотр функций безопасности

В этом разделе перечислены функции, которые планируется выпускать до марта 2021 года. Так как в этом разделе перечислены функции, которые, возможно, еще не выпущены, временная шкала доставки могут изменяться и прогнозируемые функциональные возможности могут быть выпущены позже марта 2021 года или не могут быть выпущены вообще. Дополнительные сведения о предварительных версиях см. в разделе "Условия веб-служб".

Создание собственной службы Log Analytics (BYOLA)

Использование Собственной службы Log Analytics позволяет интегрировать Power BI и Azure Log Analytics. Эта интеграция включает расширенный аналитический механизм Azure Log Analytics, язык интерактивных запросов и встроенные конструкции машинного обучения.

Вопросы и ответы на вопросы безопасности Power BI

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

Как пользователи подключаются и получают доступ к источникам данных при использовании Power BI?

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

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

  Для отчетов, подключенных к DirectQuery, источник данных подключается непосредственно с помощью предварительно настроенных учетных данных, предварительно настроенные учетные данные используются для подключения к источнику данных при просмотре данных пользователем. Если источник данных подключен непосредственно с помощью единого входа, учетные данные текущего пользователя используются для подключения к источнику данных при просмотре данных пользователем. При использовании единого входа в источник данных можно реализовать безопасность на уровне строк (RLS) и /или безопасность на уровне объектов (OLS), и это позволяет пользователям просматривать данные, к которым у них есть права доступа. При подключении к источникам данных в облаке проверка подлинности Microsoft Entra используется для единого входа; Поддерживаются для локальных источников данных, Kerberos, SAML и Идентификатора Microsoft Entra.

  При подключении к Kerberos имя участника-пользователя передается шлюзу и использует ограниченное делегирование Kerberos, пользователь олицетворен и подключен к соответствующим источникам данных. SAML также поддерживается в шлюзе для источника данных SAP HANA. Дополнительные сведения см. в обзоре единого входа для шлюзов.

  Если источником данных является Azure Analysis Services или локальные службы Analysis Services и безопасность на уровне строк (RLS) и /или безопасность на уровне объектов (OLS), служба Power BI будет применять этот уровень строки безопасности, и пользователи, у которых нет достаточных учетных данных для доступа к базовым данным (которые могут быть запросом, используемым в панели мониторинга, отчете или другом артефакте данных), не будут видеть данные, для которых пользователь не имеет достаточных привилегий.

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

  Безопасность на уровне объектов (OLS) может использоваться для защиты конфиденциальных таблиц или столбцов. Однако, в отличие от безопасности на уровне строк, безопасность на уровне объектов также защищает имена объектов и метаданные. Это помогает предотвратить обнаружение вредоносных пользователей даже существования таких объектов. Защищенные таблицы и столбцы скрываются в списке полей при использовании таких средств отчетов, как Excel или Power BI, а пользователи без разрешений не могут получить доступ к защищенным объектам метаданных с помощью DAX или любого другого метода. С точки зрения пользователей без соответствующих разрешений доступа защищенные таблицы и столбцы просто не существуют.

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

Как данные передаются в Power BI?

• Все запрошенные и передаваемые Power BI данные шифруются при передаче с помощью HTTPS (за исключением случаев, когда источник данных, выбранный клиентом, не поддерживает HTTPS) для подключения из источника данных к служба Power BI. Безопасное подключение устанавливается с поставщиком данных, и только один раз, когда подключение будет установлено, будет проходить через сеть.

Как данные кэша Power BI, панели мониторинга или модели защищены?

• При доступе к источнику данных служба Power BI следует процессу, описанном в разделе "Проверка подлинности в источниках данных" ранее в этом документе.

Кэшируют ли клиенты данные веб-страницы локально?

• Когда клиенты браузера получают доступ к Power BI, веб-серверы Power BI задают директиву Cache-Control без хранения. Директива no-store указывает браузерам не кэшировать веб-страницу, просматриваемую пользователем, и не хранить веб-страницу в папке кэша клиента.

Что такое безопасность на основе ролей, общий доступ к отчетам или панелям мониторинга и подключениям к данным? Как это работает с точки зрения доступа к данным, просмотра панелей мониторинга, доступа к отчетам или обновления?

• Для источников данных, не относящихся к уровням ролей (RLS ), если панель мониторинга, отчет или модель данных предоставляется другим пользователям через Power BI, данные будут доступны для пользователей, с которыми он предоставляет общий доступ для просмотра и взаимодействия. Power BI не выполняет повторную проверку подлинности пользователей в исходном источнике данных. После отправки данных в Power BI пользователь, прошедший проверку подлинности в исходных данных, отвечает за управление тем, какие другие пользователи и группы могут просматривать данные.

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

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

Наши пользователи подключаются к тем же источникам данных все время, некоторые из которых требуют учетных данных, которые отличаются от учетных данных домена. Как они могут избежать ввода этих учетных данных при каждом подключении к данным?

• Power BI предлагает Личный шлюз Power BI, который позволяет пользователям создавать учетные данные для нескольких разных источников данных, а затем автоматически использовать эти учетные данные при последующем доступе к каждому из этих источников данных. Дополнительные сведения см. в статье Power BI Personal Gateway.

Какие порты используются локальным шлюзом данных и личным шлюзом? Существуют ли доменные имена, которые должны быть разрешены в целях подключения?

• Подробный ответ на этот вопрос доступен по следующей ссылке: порты шлюза

При работе с локальным шлюзом данных, как используются ключи восстановления и где они хранятся? Что такое безопасное управление учетными данными?

• Во время установки и настройки шлюза администраторы введите ключ восстановления шлюза. Этот ключ восстановления используется для создания строгого симметричного ключа AES. Асимметричный ключ RSA также создается одновременно.

  Эти созданные ключи (RSA и AES) хранятся в файле, расположенном на локальном компьютере. Этот файл также зашифрован. Содержимое файла можно расшифровать только с помощью определенного компьютера Windows и только этой учетной записи службы шлюза.

  Когда пользователь вводит учетные данные источника данных в пользовательском интерфейсе служба Power BI, учетные данные шифруются с помощью открытого ключа в браузере. Шлюз расшифровывает учетные данные с помощью закрытого ключа RSA и повторно шифрует их симметричным ключом AES, прежде чем данные хранятся в служба Power BI. С помощью этого процесса служба Power BI никогда не имеет доступа к незашифрованным данным.

Какие протоколы связи используются локальным шлюзом данных и как они защищены?

• Шлюз поддерживает следующие два протокола связи:

  • AMQP 1.0 — TCP+TLS: для исходящего обмена данными требуется порты 443, 5671-5672 и 9350-9354. Этот протокол предпочтителен, так как он имеет более низкую нагрузку на связь.

  • HTTPS — WebSockets по протоколу HTTPS + TLS: этот протокол использует только порт 443. WebSocket инициируется одним сообщением HTTP CONNECT. После установки канала обмен данными по сути является TCP+TLS. Шлюз можно принудительно использовать этот протокол, изменив параметр, описанный в статье о локальном шлюзе.

Какова роль Azure CDN в Power BI?

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

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

Для визуальных элементов Power BI корпорация Майкрософт выполняет любую оценку безопасности или конфиденциальности пользовательского визуального кода перед публикацией элементов в коллекции?

• № Ответственность клиента заключается в проверке и определении того, следует ли полагаться на пользовательский визуальный код. Весь пользовательский визуальный код работает в изолированной среде, чтобы любой неуправляемый код в пользовательском визуальном элементе не негативно влиял на остальную часть служба Power BI.

Существуют ли другие визуальные элементы Power BI, которые отправляют информацию за пределы клиентской сети?

• Да. Визуальные элементы Bing Карты и ESRI передают данные из служба Power BI для визуальных элементов, использующих эти службы.

Для приложений-шаблонов корпорация Майкрософт выполняет оценку безопасности или конфиденциальности приложения-шаблона перед публикацией элементов в коллекции?

• № Издатель приложения несет ответственность за содержимое, пока он несет ответственность за проверку и определение того, следует ли доверять издателю приложения-шаблона.

Существуют ли приложения-шаблоны, которые могут отправлять информацию за пределы клиентской сети?

• Да. Это ответственность клиента за проверку политики конфиденциальности издателя и определение того, следует ли устанавливать приложение-шаблон на клиенте. Издатель отвечает за информирование клиента о поведении и возможностях приложения.

Что касается суверенитета данных? Можем ли мы подготавливать клиентов в центрах обработки данных, расположенных в определенных географических регионах, чтобы гарантировать, что данные не покидают границы страны или региона?

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

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

Как Корпорация Майкрософт обрабатывает подключения для клиентов, имеющих подписки Power BI Premium? Отличаются ли эти подключения от установленных для служба Power BI, отличных от уровня "Премиум"?

• Подключения, установленные для клиентов с подписками Power BI Premium, реализуют процесс авторизации Microsoft Entra business-to-business (B2B), используя идентификатор Microsoft Entra для включения контроля доступа и авторизации. Power BI обрабатывает подключения от подписчиков Power BI Premium к ресурсам Power BI Premium так же, как и любой другой пользователь Microsoft Entra.

Как работает проверка подлинности на стороне сервера в WFE?

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

1. Пользователь инициирует подключение к служба Power BI из браузера, введя адрес Power BI в адресной строке или выбрав вход на страницу маркетинга Power BI (https://powerbi.microsoft.com). Подключение устанавливается с помощью TLS 1.2 и HTTPS, а все последующие связи между браузером и служба Power BI используют HTTPS.

2. Диспетчер трафика Azure проверка записи DNS пользователя, чтобы определить наиболее подходящий (обычно ближайший) центр обработки данных, в котором развернут Power BI, и отвечает на DNS с IP-адресом кластера WFE, в который должен отправляться пользователь.

3. Затем WFE перенаправляет пользователя на страницу входа в Microsoft Online Services.

4. После проверки подлинности пользователя страница входа перенаправляет пользователя в ранее определенный ближайший служба Power BI кластер WFE с кодом проверки подлинности.

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

6. Теперь, когда браузер клиента требует данных клиента, он отправит запросы на внутренний адрес кластера с маркером доступа Microsoft Entra в заголовке авторизации. Серверный кластер Power BI считывает маркер доступа Microsoft Entra и проверяет подпись, чтобы убедиться, что удостоверение запроса является допустимым. Маркер доступа Microsoft Entra будет иметь дату окончания срока действия в соответствии с политиками Microsoft Entra, а для поддержания текущего сеанса клиент Power BI в браузере пользователя будет выполнять периодические запросы на продление маркера доступа до истечения срока его действия.

Дополнительные ресурсы

Дополнительные сведения о Power BI см. в следующих ресурсах.

• Начало работы с Power BI Desktop
• REST API Power BI — обзор
• справочник по API Power BI
• Локальный шлюз данных
• Национальные и региональные облака Power BI
• Power BI Premium
• Обзор единого входа для шлюзов в Power BI