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

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

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

Технические рецензенты: Кристиан Петкулеску, Амир 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-х годов корпорация Майкрософт вложила значительные средства в решение своих уязвимостей безопасности и в последующие десятилетия построила мощный стек безопасности, который идет так глубоко, как ядро BIOS на микросхеме, и простирается до непосредственного взаимодействия с конечными пользователями. Эти глубокие инвестиции продолжаются, и сегодня более 3500 инженеров Майкрософт занимаются созданием и повышением стека безопасности Майкрософт и упреждающим решением постоянно изменяющегося ландшафта угроз. С миллиардами компьютеров, триллионами логинов и бесчисленными зеттабайтами информации, доверенными под защиту компании Microsoft, в настоящее время она обладает самым передовым стеком безопасности в технологической отрасли и признана глобальным лидером в борьбе с вредоносными субъектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый серверный кластер состоит из нескольких виртуальных машин, объединенных в несколько масштабируемых наборов, оптимизированных для выполнения специфических задач, ресурсов, сохраняющих состояние, таких как базы данных 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.

Любой запрос, поступающий в инфраструктуру 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	Андроид	Виндоус
Power BI (вход в службу)	Поддерживается	Поддерживается	Не поддерживается
Локальные службы ADFS для SSRS (подключение к локальному серверу SSRS)	Не поддерживается	Поддерживается	Не поддерживается
Прокси приложения SSRS	Поддерживается	Поддерживается	Не поддерживается

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

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

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

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 (также известном как домашняя география), за исключением случаев, когда организации используют многогеографические развертывания.

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

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

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

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

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

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

Microsoft также предоставляет центры обработки данных для суверенных субъектов. Дополнительные сведения о доступности службы Power BI для национальных и региональных облаков см. в разделе «Национальные и региональные облака Power BI».

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

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

Данные в состоянии покоя

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

• Служба хранилища Azure
• Базы данных SQL Azure

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

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

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

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

Режим семантической модели (тип)	Данные, сохраненные в Power BI
Импорт	Да
Прямой запрос	нет
Live Connect	нет
Композитный	Если он содержит источник данных импорта
Стриминг	Если настроено сохранение

Независимо от используемого семантического режима модели 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, Security Assertion Markup Language (SAML) и идентификатор Microsoft Entra.

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

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

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

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

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

Если в указанных клиентом источниках данных требуются учетные данные для доступа, владелец или создатель потока данных предоставит их во время разработки. Они хранятся с помощью стандартного хранилища учетных данных на уровне продукта. См. сведения о проверке подлинности в источниках данных выше. Существуют различные подходы, которые пользователи могут настроить для оптимизации сохраняемости и доступа к данным. По умолчанию данные помещаются в учетную запись хранения Power BI, принадлежащей и защищенной. Шифрование включается в контейнерах BLOB-хранилища для защиты данных в режиме покоя. См. сведения о неактивных данных ниже. Однако пользователи могут настроить собственную учетную запись хранения, связанную с собственной подпиской Azure. При этом субъекту служба Power BI предоставляется доступ к этой учетной записи хранения, чтобы он мог записывать данные во время обновления. В этом случае владелец ресурса хранилища отвечает за настройку шифрования в настроенной учетной записи Azure Data Lake Storage. Данные всегда передаются в хранилище 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 Framework. Обработка и выполнение отчетов с разбивкой на страницы выполняются в изолированной среде.

Определения отчетов с разбивкой на страницы (.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 через порталы, настроенные их предприятиями и ИТ-отделами. Все политики и возможности Power BI, описанные в этом документе, такие как RLS и OLS, автоматически применяются ко всем пользователям независимо от того, обращаются ли они к Power BI через портал Power BI или через настраиваемые порталы.

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

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

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

Функции ИИ

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

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

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

Для обучения и применения модели AutoML Power BI использует Azure AutoML SDK и выполняет все обучение в пределах ресурсов Power BI клиента. Во время итерации обучения Power BI вызывает экспериментальную службу Azure Machine Learning, чтобы выбрать подходящую модель и гиперпараметры для текущей итерации. В этом исходящем вызове отправляются только соответствующие метаданные эксперимента (например, точность, алгоритм машинного обучения, параметры алгоритма и т. д.) из предыдущей итерации. Обучение 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) правила, клиенты могут разрешить или запретить трафик соответствующей службы. Корпорация Майкрософт управляет префиксами адресов, охватываемым тегом службы, и автоматически обновляет тег службы по мере изменения адресов.

Интеграция Private Link

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

Private Link гарантирует, что пользователи Power BI используют частную сетевую магистраль Microsoft при переходе к ресурсам в службе Power BI.

Использование Private Link для Power BI обеспечивает следующие преимущества:

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

Дополнительные сведения см. в разделе Частные ссылки для безопасного доступа к Fabric.

Подключение к Виртуальной Сети

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

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

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

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

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 гарантирует, что когда метка в семантической модели применяется или изменяется, она автоматически будет применена или изменена на все связанное с семантической моделью содержимое.

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

Правила защиты от потери данных (DLP) Microsoft Purview для Power BI

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

При настройке политик DLP для Power BI.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как Power BI кэширует данные отчетов, панелей мониторинга или моделей, и является ли это безопасным?

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

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

• Когда браузерные клиенты получают доступ к Power BI, веб-серверы Power BI настраивают директиву Cache-Control на no-store. Директива 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".

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

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

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

• Во время установки и настройки шлюза администраторы вводят ключ восстановления шлюза. Этот ключ восстановления используется для создания строгого симметричного ключа 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 Maps и ESRI передают данные из службы Power BI для визуальных элементов, использующих эти службы.

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

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

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

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

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

• Некоторые клиенты в определенных географических регионах могут создать клиент в национальном или региональном облаке, где хранение и обработка данных хранятся отдельно от всех других центров обработки данных. Национальные или региональные облака имеют немного другой тип безопасности, так как отдельный попечитель данных управляет национальным или региональным облаком служба 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
• справочник по API Power BI
• Локальный шлюз данных
• Национальные и региональные облака Power BI
• Основы безопасности Microsoft Fabric
• Конфиденциальность, безопасность и ответственное использование Copilot в Power BI