Планирование реализации Power BI: аудит на уровне клиента

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

Эта статья планирования аудита на уровне клиента в основном предназначена для следующих целей:

• администраторы Power BI: администраторы, ответственные за надзор за Power BI в организации. Администраторам Power BI может потребоваться совместная работа с ИТ,безопасностью, внутренним аудитом и другими соответствующими командами.
• Центр знаний, ИТ-отдел и команда бизнес-аналитики: команды, которые также отвечают за надзор за Power BI. Возможно, им потребуется сотрудничать с администраторами Power BI и другими соответствующими командами.

Внимание

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

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

Создание комплексного решения аудита, готового к работе, является значительным проектом, который занимает некоторое время. Подумайте об этом как о создании бизнес-аналитики на базе бизнес-аналитики (BI на BI). Сведения о том, почему данные аудита настолько ценны, см. в обзоре аудита и мониторинга.

Аудит на уровне отчета, предназначенный для создателей отчетов, см. в разделе "Аудит на уровне отчета".

Сведения об аудите ресурсов данных, предназначенных для создателей данных, см. в разделе "Аудит на уровне данных".

Оставшаяся часть этой статьи посвящена аудиту на уровне клиента.

Совет

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

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

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

• Этап 1. Планирование и принятие решений
  • Требования и приоритеты
  • Потребности в данных
  • Тип решения аудита
  • Разрешения и обязанности
  • Технические решения
  • Решения по источнику данных
• Этап 2. Предварительные требования и настройка
  • Создание учетной записи хранения
  • Установка программного обеспечения и настройка служб
  • Регистрация приложения Microsoft Entra
  • настройка параметров клиента Fabric
• Этап 3. Разработка решений и аналитика
  • Извлечение и хранение необработанных данных
  • Создайте курируемые данные
  • Создание модели данных
  • Улучшение модели данных
  • Создание аналитических отчетов
  • Действие на основе данных
• Этап 4. Обслуживание, улучшение и мониторинг
  • Эксплуатация и улучшение
  • Документация и поддержка
  • Включение оповещений
  • Текущее управление

Этап 1. Планирование и принятие решений

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

Требования и приоритеты

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

Ниже приведены некоторые вопросы, на которые вы должны ответить.

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

Совет

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

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

Контрольный список . При определении требований и приоритетов ключевые решения и действия включают:

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

Потребности в данных

Определив требования и приоритеты (описанные ранее), вы сможете определить необходимые данные. В этом разделе рассматриваются четыре категории данных.

• Данные о действиях пользователей
• Инвентаризация клиентов
• Пользователи и группы данных
• Данные безопасности

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

Данные о действиях пользователей

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

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

Ниже приведены некоторые распространенные вопросы, на которые могут ответить данные об активности пользователя.

• Найти лучших пользователей и лучший контент
  • Какой контент чаще всего просматривается и какими пользователями?
  • Каковы ежедневные, еженедельные и ежемесячные тенденции просмотра содержимого?
  • Наблюдается ли рост или снижение количества просмотров отчетов?
  • Сколько пользователей активно?
• Использование Azure Application Insights для анализа информации о том, как пользователи используют приложение
  • Какой тип безопасности чаще всего используется (приложения, рабочие области или общий доступ к элементам)?
  • Чаще всего пользователи используют браузеры или мобильные приложения?
  • Какие создатели контента наиболее активно публикуют и обновляют содержимое?
  • Какое содержимое публикуется или обновляется, когда и какими пользователями?
• Определение возможностей обучения и образования пользователей
  • Кто делится (слишком много) из своего личного рабочего пространства?
  • Кто делает значительный объем экспорта?
  • Кто регулярно загружает содержимое?
  • Кто публикует множество новых семантических моделей?
  • Кто использует подписки в значительной степени?
• Улучшение усилий по управлению и соответствию требованиям
  • Когда изменяются параметры клиента и с помощью какого администратора Power BI?
  • Кто начал пробную версию Power BI?
  • Какой контент доступен для внешних пользователей, кто, когда и как?
  • Кто добавил или обновил метку конфиденциальности?
  • Какой процент просмотров отчетов основан на сертифицированных семантических моделях?
  • Какой процент семантических моделей поддерживает несколько отчетов?
  • Когда создается или обновляется шлюз или источник данных, и каким пользователем?

Дополнительные сведения о способах использования этих данных см. в разделе "Общие сведения о шаблонах использования".

Внимание

Если вы еще не извлекаете и храните данные действий пользователей, сделайте это срочным приоритетом. Как минимум, убедитесь, что вы извлекаете необработанные данные и храните их в безопасном расположении. Таким образом, данные будут доступны, когда вы будете готовы к анализу. Журнал доступен в течение 28 дней или 90 дней в зависимости от используемого источника.

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

Инвентаризация клиентов

Часто второй приоритет — получить данные для создания инвентаризации клиентов. Иногда она называется инвентаризацией рабочих областей, метаданными рабочей области или метаданными клиента.

Инвентаризация арендатора — это моментальный снимок в определенный момент времени. В нем описывается, что опубликовано в арендаторе. Инвентаризация арендатора не включает фактические данные или отчеты. Скорее, это метаданные, описывающие все рабочие области и их элементы (например, семантические модели и отчеты).

Ниже приведены некоторые распространенные вопросы, на которые может ответить инвентаризация арендатора.

• Узнайте, сколько содержимого у вас есть и где
  • Какие рабочие области содержат больше всего содержимого?
  • Какой тип содержимого публикуется в каждой рабочей области (особенно при разделии рабочих областей отчетов и рабочих областей данных)?
  • Какие зависимости существуют между элементами (например, потоками данных, поддерживающими многие семантические модели, или семантической моделью, которая является источником для других составных моделей)?
  • Что такое происхождение данных (зависимости между элементами Power BI, включая внешние источники данных)?
  • Существуют ли потерянные отчеты (которые отключены от их семантической модели)?
• Общие сведения о соотношении семантических моделей с отчетами
  • Сколько повторного использования семантической модели происходит?
  • Существуют ли повторяющиеся или очень похожие семантические модели?
  • Существуют ли возможности консолидации семантических моделей?
• Общие сведения о тенденциях между точками во времени
  • Увеличивается ли количество отчетов с течением времени?
  • Увеличивается ли количество семантических моделей с течением времени?
• Поиск неиспользуемого содержимого
  • Какие отчеты не используются (или недостаточно используются)?
  • Какие семантические модели не используются (или не используются)?
  • Есть ли возможности для вывода контента из обращения?

Инвентаризация арендаторов помогает использовать актуальные наименования при анализе исторических действий. Моментальный снимок элементов в арендаторе содержит имена всех элементов в этот момент времени. Полезно использовать текущие имена элементов для исторических отчетов. Например, если отчет был переименован три месяца назад, журнал действий за это время записывает старое имя отчета. С правильно определенной моделью данных можно использовать последнюю инвентаризацию клиента для поиска элемента по текущему имени (а не его бывшего имени). Дополнительные сведения см. в разделе "Создание модели данных" далее в этой статье.

Дополнительные сведения о способах использования инвентаризации клиентов см. в разделе "Общие сведения о опубликованном содержимом".

Совет

Часто используется объединение событий действий пользователя (описанных в предыдущем разделе) и инвентаризации клиентов для создания полной картины. Таким образом, вы повышаете ценность всех данных.

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

Существует два основных способа создания инвентаризации клиентов. Дополнительные сведения о решениях и действиях, связанных с этим вопросом, см. в разделе Доступ к данным об инвентаризации арендаторов далее в этой статье.

Пользователи и группы данных

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

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

Ниже приведены некоторые распространенные вопросы, на которые может ответить Microsoft Graph.

• Определение пользователей и групп
  • Каковы полное имя пользователя (в дополнение к адресу электронной почты), отдел или местоположение, полученные из профиля пользователя?
  • Кто является членами группы безопасности?
  • Кто является владельцем группы безопасности (для управления участниками)?
• Получение дополнительных сведений о пользователе
  • Какие лицензии — Power BI Pro или Power BI Premium на пользователя (PPU) назначаются пользователям?
  • Какие пользователи чаще всего входят?
  • Какие пользователи не вошли в службу Power BI недавно?

Предупреждение

Некоторые старые методы (которые широко документированы в Интернете) для доступа к данным пользователей и групп не рекомендуется использовать. По возможности используйте Microsoft Graph в качестве авторитетного источника данных пользователей и групп.

Для получения дополнительной информации и рекомендаций по доступу к данным из Microsoft Graph см. раздел Доступ к данным пользователей и групп далее в этой статье.

Данные безопасности

Возможно, вам потребуется выполнить регулярные аудиты безопасности.

Ниже приведены некоторые распространенные вопросы, на которые могут отвечать REST API Power BI.

• Определение людей и приложений
  • К каким отчетам имеется доступ пользователя, группы или субъекта-службы?
  • Какие пользователи, группы или субъекты-службы являются подписчиками на получение отчетов по электронной почте?
• Общие сведения о разрешениях содержимого
  • Какие роли рабочей области назначаются пользователям и группам?
  • Какие пользователи и группы назначаются каждой аудитории приложений Power BI?
  • Какие разрешения для каждого элемента назначаются, для каких отчетов и для каких пользователей?
  • Какие разрешения для каждого элемента назначаются, для каких семантических моделей и для каких пользователей?
  • Какие семантические модели и метки данных определяют безопасность на уровне строк (RLS)?
  • Какие элементы разделены с пользователями всей организации?
  • Какие элементы публикуются публично в Интернете?
• Общие сведения о других разрешениях
  • Кто имеет разрешение на публикацию через конвейер развертывания?
  • У кого есть разрешение на управление шлюзами и подключениями к данным?
  • У кого есть разрешение на управление емкостью Premium?

Внимание

Иногда в этой статье упоминаются Power BI Premium и ее подписки на емкость (P SKU). Обратите внимание, что корпорация Майкрософт в настоящее время упрощает варианты покупки и выводит из обращения SKU Power BI Premium на единицу емкости. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на ёмкость Fabric (SKU F), как более предпочтительный вариант.

Дополнительные сведения см. в Важные обновления в лицензировании Power BI Premium и Часто задаваемые вопросы (FAQ) по Power BI Premium.

Совет

Дополнительные сведения о безопасности см. в статьях по планированию безопасности.

Эти распространенные вопросы не являются исчерпывающим списком; существует множество REST API Power BI. Дополнительные сведения см. в разделе "Использование REST API Power BI".

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

Контрольный список . При определении данных, необходимых для аудита, к ключевым решениям и действиям относятся:

• Определите конкретные потребности данных для данных о действиях пользователей: проверьте собранные требования. Определите, какие данные аудита необходимы для удовлетворения каждого требования к данным о действиях пользователя.
• определите конкретные потребности в данных инвентаризации клиентов: проверьте собранные требования. Определите, какие данные аудита необходимы для компиляции инвентаризации клиента.
• Определите конкретные потребности данных для пользователей и групп данных: проверьте собранные требования. Определите, какие данные аудита необходимы для удовлетворения каждого требования для пользователей и групп данных.
• Определите конкретные потребности в данных безопасности: проверьте собранные требования. Определите, какие данные аудита необходимы для удовлетворения каждого требования к данным безопасности.
• Проверить приоритеты: проверьте порядок приоритетов, чтобы вы знали, что нужно сначала разрабатывать.
• Решите, как часто записывать действия: решите, как часто записывать события действий (например, один раз в день).
• Решите, как часто записывать снимки: Определите интервал для создания снимков, таких как инвентаризация арендатора или данные пользователей и групп.

Тип решения аудита

Аудит на уровне клиента выполняется вручную или с помощью автоматизированных процессов.

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

Процессы аудита вручную

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

Аудит вручную лучше всего подходит для:

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

Автоматизированные процессы аудита

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

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

Автоматизированное аудит лучше всего подходит для:

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

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

Совет

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

Контрольный список . При рассмотрении типа решения аудита для разработки, к ключевым решениям и действиям относятся:

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

Разрешения и обязанности

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

Разрешения пользователей

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

Ниже приведены некоторые рекомендации, которые следует учитывать.

Прямой доступ к данным аудита

Вы должны решить, кто может получить доступ к данным аудита напрямую. Существует несколько способов подумать об этом.

• Кто должен быть администратором Power BI? Администратор Power BI имеет доступ ко всем метаданным клиента, включая API администратора. Дополнительные сведения о том, кто должен быть администратором Power BI, см. в разделе "Планирование безопасности на уровне клиента".
• Кто может использовать существующий служебный принципал? Чтобы использовать учетную запись службы (вместо разрешений пользователя) для доступа к данным аудита, необходимо предоставить секрет авторизованным пользователям, чтобы они могли выполнять аутентификацию с использованием пароля. Доступ к секретам (и ключам) должен быть очень жестко контролируемым.
• Требуется ли жестко контролировать доступ? Некоторые отрасли с нормативными требованиями и требованиями к соответствию должны контролировать доступ более тесно, чем другие отрасли.
• Существуют ли большие объемы данных о деятельности? Чтобы избежать достижения ограничений регулирования API, может потребоваться строго контролировать, кто может напрямую обращаться к API, которые создают данные аудита. В этом случае полезно убедиться, что нет повторяющихся или перекрывающихся усилий.

Доступ к извлеченным необработанным данным

Вы должны решить, кто может просматривать необработанные данные, извлеченные и записанные в хранилище. Чаще всего доступ к необработанным данным ограничен администраторами и аудиторами. Центр превосходства (COE) также может требовать доступа. Дополнительные сведения см. в разделе "Определение места хранения данных аудита" далее в этой статье.

Доступ к проверенным аналитическим данным

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

Роли и обязанности

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

Определите, какие пользователи или команда будут отвечать за следующие действия.

Роль	Типы обязанностей	Роль, как правило, выполняется
Коммуникация с заинтересованными сторонами	Обмен данными и сбор требований.	COE в партнерстве с ИТ. Может также включать отбор сотрудников из ключевых бизнес-подразделений.
Определите приоритеты и укажите направление на требования	Действия принятия решений, связанные с комплексным решением аудита, включая соответствие требованиям.	Команда, которая контролирует Power BI в организации, например COE. Исполнительный спонсор или руководящий комитет по управлению данными может принять участие в принятии критических решений или эскалации проблем.
Извлечение и хранение необработанных данных	Создание скриптов и процессов для доступа к данным и их извлечения. Также включает запись необработанных данных в хранилище.	Специалисты по проектированию данных, как правило, в ИТ и в партнерстве с COE.
Создание отобранных данных	Очистка, преобразование и формирование отборных данных в звёздной схеме.	Сотрудники по обработке данных, обычно в ИТ, сотрудничают с COE.
Создание модели данных	Создание аналитической модели данных на основе курированных данных.	Создатели контента Power BI, как правило, в департаменте ИТ или Центре компетенции (COE).
Создание отчетов аналитики	Создание отчетов для анализа проверенных данных. Текущие изменения отчетов на основе новых требований и когда новые данные аудита становятся доступными.	Создатели отчетов Power BI, как правило, из отделов ИТ или центра компетенций (COE).
Анализ данных и выполнение действий по результатам	Анализ данных и выполнение действий в ответ на данные аудита.	Команда, которая контролирует Power BI в организации, как правило, COE. Может также включать другие команды в зависимости от результатов аудита и предпринятых действий. Другие команды могут включать безопасность, соответствие требованиям, управление рисками или управление изменениями.
Тестирование и проверка	Проверьте, выполнены ли требования к аудиту и что представленные данные являются точными.	Создатели контента Power BI вместе с командой, которая контролирует Power BI в организации.
Защита данных	Настройте безопасность для каждого уровня хранилища и управляйте ими, включая необработанные данные и курированные данные. Управление доступом к семантических моделям, созданным для анализа данных.	Системный администратор системы, в которой хранятся данные, в партнерстве с командой, которая контролирует Power BI в организации.
Планирование и автоматизация	Инициализация решения и планирование процесса с помощью выбранного средства.	Специалисты по инженерии данных, как правило, работают в ИТ и в сотрудничестве с COE.
Поддержка решения	Отслеживайте решение аудита, включая запуски заданий, ошибки и решение технических проблем.	Команда, которая занимается поддержкой системы Power BI, что обычно делает ИТ-отдел или Центр передового опыта (COE).

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

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

Рассмотрим несколько примеров.

• пример 1: данные аудита показывают, что некоторые пользователи часто экспортируют данные в Excel. Принятые меры: COE обращается к конкретным пользователям, чтобы понять свои потребности и научить их лучшим альтернативам.
• Пример 2: данные аудита показывают, что доступ внешних пользователей осуществляется неожиданным образом. Действия: ИТ-системный администратор обновляет соответствующие параметры идентификатора Microsoft Entra для доступа внешних пользователей. Администратор Power BI обновляет параметр клиента, связанный с доступом внешних пользователей. COE обновляет документацию и проводит обучение для создателей контента, которые управляют безопасностью. Дополнительные сведения см. в статье "Стратегия для внешних пользователей".
• Пример 3: Данные аудита показывают, что несколько моделей данных по-разному определяют одну и ту же метрику (доступные из API для сканирования метаданных , если это разрешено детализированными настройками клиента метаданных). Меры. Комитет по управлению данными запускает проект для определения общих определений. COE обновляет документацию и обучающие материалы для создателей контента, создающих модели данных. COE также работает с создателями контента для обновления своих моделей. Дополнительные сведения о получении подробных метаданных см. в разделе "Доступ к данным инвентаризации арендаторов" в другой части этой статьи.

Примечание.

Настройка процессов извлечения данных обычно является однократной попыткой с случайными улучшениями и устранением неполадок. Анализ и выполнение данных — это постоянные усилия, требующие постоянных усилий на регулярной основе.

Контрольный список . При рассмотрении разрешений и обязанностей ключевые решения и действия включают:

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

Технические решения

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

Первый этап планирования включает принятие следующих решений.

• Выбор технологии для доступа к данным аудита
• Определение метода проверки подлинности
• Выбор API пользователя или API администратора
• Выберите API или командлеты PowerShell
• Определение места хранения данных аудита
• План по созданию курируемых данных

Выбор технологии для доступа к данным аудита

Первое, что необходимо решить, как получить доступ к данным аудита.

Самый простой способ приступить к работе — использовать предварительно созданные отчеты, доступные в рабочей области мониторинга администратора.

Если вам нужно получить доступ к данным напрямую и создать собственное решение, вы будете использовать API (интерфейс программы приложения). API предназначены для обмена данными через Интернет. REST API Power BI поддерживают запросы данных с помощью протокола HTTP. Любой язык или инструмент может вызывать REST API Power BI, когда он может отправлять HTTP-запрос и получать ответ JSON.

Совет

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

В этом разделе основное внимание уделяется выбору технологий. Рекомендации по источникам доступа к определённым типам данных аудита см. в разделе Принятие решений о данных далее в этой статье.

Параметры платформы

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

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

Технология	Хороший выбор для процессов аудита вручную	Хороший выбор для автоматизированных процессов аудита
Рабочая область мониторинга администратора
Попробуйте
PowerShell
Power BI Desktop
Power Automate
Предпочитаемая служба Azure
Предпочитаемое средство или язык
Поиск журнала аудита Microsoft Purview
Defender для облачных приложений
Microsoft Sentinel

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

Рабочая область мониторинга администратора

Административная рабочая область мониторинга содержит предварительно определенные отчеты и семантические модели в службе Power BI. Это удобный способ для администраторов Fabric просматривать последние данные аудита и помочь им понять действия пользователей.

Раздел "Попробовать" в документации по API

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

Можно использовать Try-it для следующего:

• Вручную отправьте запрос в API, чтобы определить, возвращает ли она нужную информацию.
• Узнайте, как создается URL-адрес перед написанием скрипта.
• Неформальный способ проверки данных.

Примечание.

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

Поскольку это интерактивное, инструмент Try-it лучше всего подходит для обучения, исследования и новых методов ручного аудита.

PowerShell и Azure Cloud Shell

Вы можете создавать и запускать скрипты PowerShell несколькими способами.

Ниже приведены несколько распространенных вариантов.

• Visual Studio Code: современный, упрощенный редактор исходного кода. Это свободно доступное средство с открытым исходным кодом, которое поддерживается на нескольких платформах, включая Windows, macOS и Linux. Visual Studio Code можно использовать со многими языками, включая PowerShell (с помощью расширения PowerShell).
• Azure Data Studio: средство создания скриптов и записных книжек. Он построен на основе Visual Studio Code. Azure Data Studio доступна независимо или с sql Server Management Studio (SSMS). Существует множество расширений, включая расширение для PowerShell.
• Azure Cloud Shell: альтернатива локальной работе с PowerShell. Доступ к Azure Cloud Shell можно получить из браузера.
• Функции Azure: альтернатива локальной работе с PowerShell. Функции Azure — это служба Azure, которая позволяет создавать и запускать код в бессерверной среде. PowerShell — это один из нескольких языков, поддерживаемых им.

Внимание

Мы рекомендуем использовать последнюю версию PowerShell (PowerShell Core) для всех новых работ по разработке. Следует прекратить использование Windows PowerShell (который не может запускать PowerShell Core) и вместо этого использовать один из современных редакторов кода, поддерживающих PowerShell Core. Обратите внимание на многие примеры в Интернете, которые используют Windows PowerShell (версия 5.1), так как они не могут использовать последние (и лучшие) подходы к коду.

PowerShell можно использовать различными способами. Для получения дополнительной информации об этом техническом решении см. раздел Выберите API или командлеты PowerShell ниже в этой статье.

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

Power BI Desktop

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

• Накопление истории. Поскольку журнал действий Power BI предоставляет до 28 дней данных, создание вашего полного решения для аудита включает в себя накопление набора файлов со временем, которые хранят все исторические события. Накопление исторических файлов проще для выполнения с другими инструментами.
• Безопасная обработка учетных данных и ключей. Многие решения, которые вы находите в Интернете от блоггеров сообщества, не защищены, так как они жестко прописывают учетные данные и ключи в виде открытого текста в запросах Power Query. Хотя этот подход прост, не рекомендуется, так как любой пользователь, получающий файл Power BI Desktop, может считывать значения. Пароль (при использовании проверки подлинности пользователя) или секрет (при использовании сервисного принципала) нельзя безопасно хранить в Power BI Desktop, если только вы не примете следующие меры.
  • Используйте настраиваемый соединитель, разработанный при помощи пакета SDK для Power Query. Например, настраиваемый соединитель может считывать конфиденциальные значения из Azure Key Vault или другой службы, которая безопасно сохраняет зашифрованное значение. Существуют также различные варианты пользовательского соединителя, доступные в глобальном сообществе Power BI.
  • Используйте параметр ApiKeyName, который хорошо работает в Power BI Desktop. Однако невозможно сохранить в службе Power BI значение ключа.
• Типы запросов. Вы можете столкнуться с некоторыми ограничениями для того, что можно запустить в Power BI Desktop. Например, Power Query не поддерживает каждый тип запроса API. Например, при использовании функции Web.Contents поддерживаются только запросы GET и POST. Для аудита обычно отправляются запросы GET.
• возможность обновления. Для успешного обновления семантической модели в службе Power BI необходимо следовать определенным шаблонам разработки Power Query. Например, опция RelativePath должна присутствовать при использовании Web.Contents, чтобы Power BI правильно проверил расположение источника данных, не вызывая ошибку в службе Power BI.

В большинстве случаев рекомендуется использовать Power BI Desktop только для двух целей. Его следует использовать для:

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

Power Automate

Вы можете использовать Power Automate с Power BI различными способами. В отношении аудита можно использовать Power Automate для отправки запросов в REST API Power BI, а затем хранить извлеченные данные в выбранном расположении.

Совет

Чтобы отправлять запросы в REST API Power BI, можно использовать настраиваемый соединитель для Power Automate для безопасной проверки подлинности и извлечения данных аудита. Кроме того, можно использовать Azure Key Vault для ссылки на пароль или секрет. Оба варианта лучше, чем хранить пароли и секреты в виде обычного текста в потоке Power Automate.

Для других идей о способах использования Power Automate выполните поиск Power BI в шаблонах Power Automate.

Предпочитаемая служба Azure

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

• Функции Azure
• Служба автоматизации Azure
• Фабрика данных Azure
• Azure Synapse Analytics

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

Предпочитаемое средство и (или) язык

Вы можете использовать предпочитаемое средство и предпочитаемый язык для отправки запросов в REST API Power BI. Это хороший подход, когда у вашей команды есть опыт с определенным инструментом или языком, например:

• Python
• C# на платформе .NET. При необходимости можно использовать пакет SDK для .NET Power BI, который выступает в качестве оболочки поверх REST API Power BI, чтобы упростить некоторые процессы и повысить производительность.
• JavaScript

Поиск аудита Microsoft Purview

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

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

Ниже приведены некоторые распространенные способы использования средства поиска по журналам аудита. Вы можете:

• Выберите рабочую нагрузку Power BI, чтобы просмотреть события для ряда дат.
• Найдите одну или несколько конкретных действий, например:
  • Удалённый отчет Power BI
  • Добавлен доступ администратора к личной рабочей области в Power BI
• Просмотр действий одного или нескольких пользователей.

Для администраторов с достаточными разрешениями инструмент поиска в журнале аудита в портале соответствия Microsoft Purview является хорошим вариантом для процессов аудита вручную. Дополнительные сведения см. в портале соответствия требованиям Microsoft Purview далее в этой статье.

Пользовательский интерфейс приложений Defender для облака

Microsoft Defender for Cloud Apps доступен администраторам в Microsoft Defender XDR (портал Microsoft 365). Он включает пользовательский интерфейс для просмотра и поиска журналов действий для различных облачных служб, включая Power BI. В нем отображаются те же события журнала, которые возникают в портале соответствия требованиям Microsoft Purview, помимо других событий, таких как действия пользователей при входе из Microsoft Entra ID.

Интерфейс журнала аудита в Microsoft Defender for Cloud Apps хорошо подходит для ручных аудиторских процессов. Дополнительные сведения см. в разделе Defender для облачных приложений далее в этой статье.

Microsoft Sentinel и KQL

Microsoft Sentinel — это служба Azure, которая позволяет собирать, обнаруживать, исследовать и реагировать на инциденты безопасности и угрозы. Power BI можно настроить в Microsoft Sentinel в качестве соединителя данных, чтобы журналы аудита передаются из Power BI в Microsoft Sentinel Azure Log Analytics (который является компонентом службы Azure Monitor ). Вы можете использовать язык запросов Kusto (KQL) для анализа событий журнала действий, хранящихся в Azure Log Analytics.

Использование KQL для поиска данных в Azure Monitor является хорошим вариантом для просмотра части журнала аудита. Это хороший вариант для процессов аудита вручную. Дополнительные сведения см. в разделе Microsoft Sentinel этой статьи.

Особенности платформы

Ниже приведены некоторые рекомендации по доступу к данным аудита.

• Реализуется ли процесс ручного или автоматического аудита? Некоторые инструменты тесно связаны с ручной обработкой или автоматической обработкой. Например, пользователь всегда работает с функцией Try-it в интерактивном режиме, поэтому она подходит только для процессов аудита вручную.
• Как пройти проверку подлинности? Не все параметры поддерживают каждый вариант проверки подлинности. Например, функция Try-it поддерживает только проверку подлинности пользователей.
• Как безопасно хранить учетные данные? Различные технологии имеют различные варианты хранения учетных данных. Дополнительные сведения см. в разделе "Определение метода проверки подлинности" далее в этой статье.
• С какой технологией уже работает ваша команда? Если есть инструмент, который ваша команда предпочитает и удобнее использовать, начните там.
• Что ваша команда может поддерживать? Если другая команда будет поддерживать развернутое решение, рассмотрите, может ли эта команда достаточно поддержать ее. Кроме того, учитывайте, что внутренние команды могут поддерживать разработку, выполняемую консультантами.
• Какой инструмент вам разрешено использовать? Для некоторых инструментов и технологий может потребоваться утверждение. Это может быть связано с стоимостью. Это также может быть связано с политиками безопасности ИТ.
• Каковы ваши предпочтения по планированию? Некоторые технологии принимают решение за вас. В других случаях вам придется принять ещё одно решение. Например, если вы решили написать скрипты PowerShell, можно запланировать их выполнение различными способами. И наоборот, если вы используете облачную службу, например Фабрика данных Azure, планирование встроено.

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

Контрольный список . При принятии решения о том, какая технология используется для доступа к данным аудита, к ключевым решениям и действиям относятся:

• Обсудите с ИТ-сотрудниками. Поговорите с ИТ-командами, чтобы узнать, есть ли определенные инструменты, утвержденные или предпочитаемые.
• Изучите варианты с небольшим доказательством концепции (POC): выполните некоторые эксперименты с техническим POC. Сначала сосредоточьтесь на обучении. Затем сосредоточьтесь на вашем решении о том, что следует использовать в будущем.

Определение метода проверки подлинности

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

Внимание

Обратитесь к ит-специалистам и группам безопасности по этому вопросу. Узнайте, как работает безопасность в идентификаторе Microsoft Entra.

Не каждый API в Интернете требует проверки подлинности. Однако для всех REST API Power BI требуется проверка подлинности. При доступе к данным аудита на уровне арендатора процесс проверки подлинности управляется идентификационной платформой Microsoft. Это эволюция службы удостоверений Microsoft Entra, построенной на стандартных отраслевых протоколах.

Совет

Платформа удостоверений Майкрософт глоссарий терминов — это ресурс, который поможет вам ознакомиться с основными понятиями.

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

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

Существует два типа маркеров доступа:

• Токены пользователей: выдаются от имени пользователя с удостоверённой личностью.
• Токены только для приложений: выданы от имени приложения Microsoft Entra (служебный принципал).

Для получения дополнительной информации см. Объекты приложения и учетной записи службы в Microsoft Entra ID.

Примечание.

Приложение Microsoft Entra — это конфигурация удостоверений, которая позволяет автоматическому процессу интегрироваться с идентификатором Microsoft Entra. В этой статье она называется регистрацией приложения. Термин субъект-служба также часто используется в этой статье. Эти термины подробно описаны далее в этом разделе.

Совет

Самый простой способ проверки подлинности — использовать командлет Connect-PowerBIServiceAccount из модуля управления Power BI. Другие командлеты, связанные с аутентификацией, могут отображаться в статьях и записях блога в интернете. Например, существуют Login-PowerBI и Login-PowerBIServiceAccount командлеты, которые являются псевдонимами для Connect-PowerBIServiceAccount командлетов. Существует также командлет Disconnect-PowerBIServiceAccount, который можно использовать, чтобы явно выйти после завершения процесса.

В следующей таблице описаны два варианта проверки подлинности.

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

Каждый параметр проверки подлинности подробно описан в следующем разделе.

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

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

• процессы аудита вручную. Вы хотите запустить скрипт с помощью разрешений пользователя. Разрешения могут находиться на одном из двух уровней в зависимости от типа запроса API:
  • разрешения администратора для API администрирования. Для отправки запроса API администрированиянеобходимо использовать разрешения администратора Power BI.
  • Права доступа пользователей для пользовательских API. Необходимо использовать права доступа пользователя Power BI для отправки запроса в пользовательский API. Дополнительные сведения см. в разделе "Выбор API пользователя" или API администрирования.
• интерактивный вход: вы хотите входить в интерактивный режим, который требует ввода адреса электронной почты и пароля. Например, вы должны выполнить интерактивный вход, чтобы использовать возможность Try-it, которая находится в документации по API Microsoft.
• Отслеживание доступа к метаданным клиента. Когда отдельные пользователи и администраторы отправляют запросы API, может потребоваться проверить, кто является этими пользователями. При аутентификации с помощью учетной записи службы (описано далее), идентификатор пользователя, который сохраняется в журнале действий, это идентификатор приложения. Если несколько администраторов проходят аутентификацию с помощью одного сервисного принципала, может быть трудно узнать, какой администратор обратился к данным.
• учетная запись общего администратора. Некоторые ИТ-команды используют учетную запись общего администратора. В зависимости от того, как он реализуется и контролируется, это может не быть лучшей практикой. Вместо общей учетной записи следует рассмотреть возможность использования Microsoft Entra Управление привилегированными удостоверениями (PIM), которая может временно предоставлять права администратора Power BI для пользователя.
• API, которые поддерживают только проверку подлинности пользователей: Иногда может потребоваться использовать API, который не поддерживает проверку подлинности с помощью учетной записи службы. В документации каждый API отмечает, может ли субъект-служба вызывать его.

Внимание

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

Аутентификация служебной учетной записи

Большинство организаций имеют одного клиента Microsoft Entra, поэтому термины регистрация приложения и основной службы обычно используются взаимозаменяемо. При регистрации приложения Microsoft Entra существует два компонента.

• Регистрация приложений: регистрация приложения является глобально уникальной. Это глобальное определение зарегистрированного приложения Microsoft Entra, которое может использоваться несколькими клиентами. Регистрация приложения может также называться клиентским приложением или агентом. Как правило, клиентское приложение означает компьютер пользователя. Однако это не ситуация для регистрации приложений. На портале Azure приложения Microsoft Entra можно найти на странице Регистрации приложений в Microsoft Entra ID.
• учетная запись службы: учетная запись службы — это локальное представление регистрации приложения для использования в вашем конкретном арендаторе. Принципал службы выводится из зарегистрированного приложения Microsoft Entra. Для организаций с несколькими клиентами Microsoft Entra одна и та же регистрация приложения может использоваться несколькими служебными принципалами. В портале Azure принципы обслуживания можно найти на странице корпоративных приложений в Microsoft Entra ID.

Поскольку субъект-служба является локальным представлением, термин проверка подлинности субъекта-службы является наиболее распространенным способом обозначения входов в систему.

Совет

Администратор Microsoft Entra может сообщить вам, кому разрешено создавать и предоставлять согласие на регистрацию приложения в вашей организации.

Проверка подлинности служебного принципала полезна в следующих ситуациях.

• автоматизированные процессы аудита: вы хотите запустить несопровождаемый процесс по расписанию.
• Нет необходимости входить в службу Power BI: необходимо подключить и извлечь данные. Субъект-служба не может войти в служба Power BI.
• Общий доступ к данным: Вы (лично) не администратор Power BI, но вы авторизованы использовать служебного принципала. Служебный принципал имеет разрешение на выполнение административных API для получения данных уровня арендатора (или других специфических разрешений).
• Использование несколькими администраторами: Вы хотите разрешить нескольким администраторам или пользователям использовать одну и ту же учетную запись службы.
• технические блокировщики. Существует технический блокировщик, который предотвращает использование проверки подлинности пользователей. К общим техническим блокировщикам относятся:
  • многофакторная аутентификация (MFA): автоматизированные процессы аудита (которые выполняются без вмешательства) не могут аутентифицироваться с помощью учетной записи пользователя, когда включена многофакторная аутентификация.
  • синхронизация хэша паролей: идентификатор Microsoft Entra ID требует синхронизации хэша паролей для проверки подлинности учетной записи пользователя. Иногда ИТ-отдел или группа кибербезопасности могут отключить эту функцию.

Назначение регистрации приложений и соглашение об именовании

Каждая регистрация приложения должна иметь четкое имя, описывающее его назначение и целевую аудиторию (кто может использовать регистрацию приложения).

Рассмотрите возможность реализации соглашения об именовании, например: <Рабочая нагрузка> — <назначение> — <целевая аудитория> — <тип объекта>

Ниже приведены части соглашения об именовании.

• рабочей нагрузки: обычно эквивалентно источнику данных (например, данным Power BI или данным Microsoft Graph).
• назначение: аналогично уровню разрешений (например, Read и ReadWrite). Как описано ниже, цель помогает следовать принципу наименьших привилегий при создании отдельных регистраций приложений, которые могут считывать только данные.
• целевая аудитория: необязательно. В зависимости от рабочей нагрузки и цели целевая аудитория позволяет определить предполагаемых пользователей регистрации приложения.
• тип объекта: EntraApp включен для ясности.

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

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

Имя регистрации приложения	Целевые назначения	Целевая аудитория
PowerBIData-Read-AdminAPIs-EntraApp	Извлечение метаданных на уровне клиента для аудита и администрирования Power BI. API администратора всегда доступны только для чтения и могут не иметь предоставленных разрешений в Microsoft Entra ID (только в параметрах арендатора Power BI).	Администраторы Power BI и Центр передового опыта
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Управление клиентом Power BI. Требуется разрешение на чтение и запись для создания или обновления ресурсов.	Администраторы Power BI и Центр передового опыта
GraphData-Read-PowerBIAdministrators-EntraApp	Извлеките данные пользователей и групп для аудита и администрирования Power BI. Требуется разрешение на чтение.	Администраторы Power BI и Центр передового опыта

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

• Узнайте, для чего предназначена регистрация приложения и почему: когда вы увидите в данных аудита идентификатор клиента из регистрации приложения, вы поймете, для чего он использовался и почему. Значительное преимущество заключается в создании отдельных регистраций приложений (вместо использования только одной для всех целей).
• Узнайте, для кого предназначена регистрация приложения: Когда вы увидите идентификатор клиента из регистрации приложения в ваших данных аудита, вы сможете понять, кто его использовал.
• Избегайте чрезмерного выделения разрешений. Вы можете следовать принципу наименьших привилегий, предоставив отдельные регистрации приложений различным группам людей с разными потребностями. Вы можете избежать избыточного предоставления разрешений, регистрируя приложение только для чтения, когда разрешения на запись не требуются. Например, у вас могут быть некоторые высококомпетентные пользователи самообслуживания, которые хотят собирать данные о своих семантических моделях; им нужен доступ к учётной записи службы с разрешением на чтение. Возможно, есть вспомогательные члены Центра превосходства, работающие в финансовой группе, программно управляющие семантическими моделями, которым нужен доступ к субъекту-службе с разрешением на запись.
• Знать, кому следует передать секрет: секрет каждой регистрации приложения должен быть известен только тем, кому он необходим. При смене секрета (описанного далее в этом разделе), влияние будет меньше при использовании отдельных регистраций приложений для различных потребностей. Это полезно, если необходимо сменить секрет, так как пользователь покидает организацию или изменяет роль.

Разрешения для регистрации приложений

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

• Разрешения только для приложений: Доступ и авторизация обрабатываются служебным принципалом без аутентифицированного пользователя. Этот метод проверки подлинности полезен для сценариев автоматизации. При использовании разрешений только для приложений важно понимать, что разрешения не назначаются в Microsoft Entra ID. Скорее, разрешения назначаются одним из двух способов:
  • Для запуска API администрирования: некоторые параметры клиента Fabric позволяют получать доступ к конечным точкам для API администрирования (возвращающие метаданные аудита на уровне клиента). Дополнительные сведения см. в разделе Настройка параметров клиента Fabric далее в этой статье.
  • Для запуска пользовательских API: применяются разрешения рабочей области Power BI и элементов. Стандартные разрешения Power BI определяют, какие данные могут быть возвращены сервисному принципалу при использовании пользовательских API (которые возвращают данные аудита на основе разрешений пользователя или сервисного принципала, вызывающего API).
• делегированные разрешения: используются разрешения на основе области действия. Служебный принципал обращается к данным от имени пользователя, который в данный момент вошел в систему. Это означает, что субъект-служба не может получить доступ ни к чему большему, чем то, к чему имеет доступ вошедший в систему пользователь. Помните, что это отличается от концепции проверки подлинности только для пользователей, описанной ранее. Так как пользовательское приложение требуется для правильной обработки сочетания разрешений пользователя и приложения, делегированные разрешения редко используются для сценариев аудита. Эта концепция часто неправильно понимается, что приводит к множеству регистраций приложений с избыточными разрешениями.

Внимание

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

Дополнительные сведения см. в разделе "Регистрация приложения Microsoft Entra" далее в этой статье.

Секреты регистрации приложений

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

Вам также нужно беспокоиться о том, где безопасно хранить секрет. Хранилище паролей организации, например Azure Key Vault, отлично подходит.

Совет

В качестве альтернативного подхода к использованию секрета можно использовать управляемое удостоверение. Управляемое удостоверение устраняет необходимость управления учетными данными. Если вы планируете использовать такие службы, как Azure Functions или Azure Data Factory для извлечения данных, управляемое удостоверение является хорошим вариантом для рассмотрения.

Безопасное управление учетными данными

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

Внимание

Первое правило заключается в том, что многие люди нарушают: пароли и ключи никогда не должны отображаться в виде открытого текста в скрипте. Многие статьи, блоги и примеры в Интернете делают это для простоты. Однако это плохая практика, которую следует избежать. Любой пользователь, получающий скрипт (или файл), может получить доступ к тем же данным, к которым у автора есть доступ.

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

• Интеграция с Azure Key Vault или другой системой хранилища паролей организации по возможности.
• Используйте учетные данные и безопасные строки в скриптах PowerShell. Учетные данные подходят как для проверки подлинности пользователя, так и для проверки подлинности служебного объекта. Однако вы не можете использовать учетные данные, если для учетной записи пользователя включена многофакторная проверка подлинности.
• Запрос пароля в скрипте PowerShell или использование интерактивной проверки подлинности в браузере.
• Используйте модуль управления секретами для PowerShell, опубликованный корпорацией Майкрософт. Он может хранить значения с помощью локального хранилища данных. Кроме того, он может интегрироваться с удаленным хранилищем ключей Azure, что полезно при наличии нескольких администраторов в организации, которые работают с одними и теми же скриптами.
• Создайте настраиваемый соединитель для Power BI Desktop, чтобы обеспечить безопасную обработку учетных данных. Некоторые пользовательские соединители доступны участникам сообщества (обычно на GitHub).

Совет

Рекомендуется обратиться к ит-специалистам и группам безопасности, чтобы выбрать лучший метод или убедиться, что решение управляет учетными данными безопасным способом.

Библиотека проверки подлинности Майкрософт

Поддержка библиотеки аутентификация Azure AD (ADAL) закончилась в декабре 2022 года. Теперь следует использовать библиотеку проверки подлинности Майкрософт (MSAL). Команда безопасности в вашей организации должна быть знакома с этим значительным изменением.

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

• Используйте последнюю версию модуля управления Power BI при проверке подлинности с помощью командлета Connect-PowerBIServiceAccount PowerShell. Он переключился с ADAL на MSAL версии 1.0.946 (26 февраля 2021 г.).
• Используйте конечную точку Microsoft Entra версии 2 для аутентификации непосредственно в вашем скрипте. Конечная точка Microsoft Entra версии 2 использует MSAL, а конечная точка Microsoft Entra V1 использует ADAL.
• Прекратить использование API и модулей, которые устарели. Дополнительные сведения см. в статье об устаревших API и модулях далее в этой статье.
• Если вы найдете решение сообщества в Интернете, убедитесь, что оно использует MSAL для проверки подлинности, а не ADAL.

Контрольный список . При выборе способа управления проверкой подлинности ключевые решения и действия включают:

• решите, какой тип проверки подлинности следует использовать. Определите, подходит ли проверка подлинности пользователя или проверка подлинности от имени службы в зависимости от типа создаваемого решения аудита.
• Планирование регистрации приложений, необходимых: учитывайте требования, рабочие нагрузки и целевую аудиторию (пользователи каждой регистрации приложения). Запланируйте количество регистраций приложений, необходимых для поддержки этих потребностей.
• создать соглашение об именовании для регистраций приложений: настройте соглашение об именовании, которое упрощает понимание целевой цели и предполагаемых пользователей каждой регистрации приложения.
• Планирование безопасного управления учетными данными. Рассмотрите способы безопасного управления паролями, секретами и ключами. Рассмотрим, какая документация и обучение могут потребоваться.
• Подтвердите использование MSAL. Определите, существуют ли существующие решения ручного или автоматического аудита, использующие ADAL. При необходимости создайте план для перезаписи этих решений для использования новой библиотеки проверки подлинности MSAL.

Выбор API пользователя или API администратора

При планировании получения данных аудита важно использовать правильный тип API.

Существует два типа API для рассмотрения.

• API-интерфейсы пользователей: Опирайтесь на разрешения пользователя, вошедшего в систему (или служебного пользователя), для отправки запросов в API. Например, одним из способов возврата списка семантических моделей в рабочей области является API пользователя. Разрешение на чтение семантических моделей можно предоставить с помощью роли рабочей области или разрешений для каждого элемента. Существует два способа запуска API-интерфейсов пользователей:
  • Аутентификация пользователя: Вошедший в систему пользователь должен иметь разрешение на доступ к рабочей области или элементу.
  • Аутентификация служебного принципала. Служебный принципал должен иметь разрешение на доступ к рабочей области или элементу.
• API администрирования: получение метаданных из клиента. Иногда это называется областью организации. Например, чтобы вернуть список всех семантических моделей в клиенте, используйте API администратора. Существует два способа запуска API администрирования:
  • проверка подлинности пользователей: Вошедший в систему пользователь должен быть администратором Power BI, чтобы запускать API администрирования.
  • проверка подлинности субъекта-службы. Субъект-служба должен иметь разрешение на запуск API администрирования (без использования разрешений безопасности, таких как API пользователя).

Совет

Все API администрирования принадлежат группе операций администрирования. Любой API с суффиксом "Администратор " является API администратора. Все остальные API являются ПОЛЬЗОВАТЕЛЬСКИми API.

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

Название API	Тип API	Область применения	Число семантических моделей
Получение набора данных	Пользователь	Личная рабочая область	Единица
Получение наборов данных	Пользователь	Личная рабочая область	Все
Получение набора данных в группе	Пользователь	Одна рабочая область	Один вариант возможен, если вошедший в систему пользователь имеет разрешение на чтение семантической модели.
Получите наборы данных в группе	Пользователь	Одна рабочая область	Все, при условии, что вошедший пользователь имеет разрешение на чтение каждой семантической модели.
Получение наборов данных в группе от имени администратора	Администратор	Одна рабочая область	Все
Получение наборов данных от имени администратора	Администратор	Весь арендатор	Все

Примечание.

Некоторые имена API включают термин "Группа " в качестве ссылки на рабочую область. Этот термин был создан из исходной модели безопасности Power BI, которая опиралась на группы Microsoft 365. Хотя модель безопасности Power BI значительно развивалась на протяжении многих лет, существующие имена API остаются неизменными, чтобы избежать нарушения существующих решений.

Сведения о параметрах клиента см. в разделе Настройка параметров клиента Fabric далее в этой статье.

Контрольный список . При выборе того, следует ли использовать API пользователя или API администратора, к ключевым решениям и действиям относятся:

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

Выберите API или командлеты PowerShell

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

PowerShell — это решение для автоматизации задач. Термин PowerShell — это коллективный термин, который относится к языку сценариев, приложению оболочки командной строки и платформе управления конфигурацией. PowerShell Core — это новая версия PowerShell, которая работает в Windows, Linux и macOS.

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

Модуль PowerShell создает слой абстракции по API. Например, командлет Get-PowerBIActivityEvent извлекает (или получает) события аудита для клиента Power BI. Этот командлет PowerShell извлекает данные из REST API Get Activity Events. Как правило, проще приступить к работе с помощью командлетов, так как они упрощают доступ к базовым API.

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

Модули PowerShell

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

Совет

Помимо модулей, опубликованных корпорацией Майкрософт, доступны модули и скрипты PowerShell, опубликованные (как правило, на GitHub) участниками сообщества Power BI, партнерами и MVP.

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

Модуль управления Power BI

Модуль управления Power BI — это объединяющий модуль, который содержит определенные модули Power BI для администрирования, мощностей, рабочих областей и т. д. Вы можете установить модуль свертки для получения всех модулей или установить определенные модули. Все модули управления Power BI поддерживаются как в Windows PowerShell, так и в PowerShell Core.

Внимание

Рекомендуется прекратить использование Windows PowerShell (который не может запускать PowerShell Core). Вместо этого используйте один из современных редакторов кода, поддерживающих PowerShell Core. Среда сценариев Windows PowerShell (интегрированная среда сценариев) может работать только с PowerShell версии 5.1, которая больше не обновляется. Windows PowerShell теперь устарел, поэтому мы рекомендуем использовать PowerShell Core для всех новых работ по разработке.

Ниже приведены несколько часто используемых командлетов, которые можно использовать для получения данных аудита.

Модуль управления	Cmdlet	Целевые назначения
Профиль	Connect-PowerBIServiceAccount (соединение с аккаунтом Power BI Service)	Аутентификация пользователя или субъекта-службы Power BI.
Администратор	Get-PowerBIActivityEvent	Просмотр или извлечение событий журнала действий Power BI для клиента.
Пространства для работы	Get-PowerBIWorkspace	Скомпилируйте список рабочих областей.
Отчеты	Get-PowerBIReport	Скомпилируйте список отчетов для рабочей области или клиента.
Данные	Get-PowerBIDataset	Скомпилируйте список семантической модели для рабочей области или клиента.
Профиль	Invoke-PowerBIRestMethod	Отправьте запрос REST API (команда). Этот командлет является хорошим вариантом, так как он может вызывать любой из REST API Power BI. Это также хороший выбор, если вы хотите использовать более простую форму проверки подлинности с помощью Connect-PowerBIServiceAccount командлета и иметь возможность вызывать API, который не имеет соответствующего командлета PowerShell. Дополнительные сведения см. в разделе «Рекомендации по использованию командлетов PowerShell» ниже в этом разделе.

Совет

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

Модуль управления Power BI можно скачать из галереи PowerShell. Самый простой способ установки модулей — использовать PowerShellGet.

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

Внимание

Убедитесь, что модули обновлены на каждом сервере, пользовательском компьютере и облачной службе (например, служба автоматизации Azure), где используется PowerShell. Если модули не обновляются регулярно, могут возникнуть непредсказуемые ошибки или проблемы. Некоторые средства (например, Visual Studio Code) помогают обновлять модули. Кроме того, помните, что PowerShellGet не удаляет более старые версии модуля при установке или обновлении более новой версии. Он устанавливает более новые версии вместе со старыми версиями. Рекомендуется проверять установленные версии и периодически удалять старые версии.

Модуль шлюза данных

Модуль шлюза данных содержит командлеты, которые извлекают данные из локального шлюза данных и его источников данных. Модуль шлюза данных поддерживается только в PowerShell Core. Он не поддерживается в Windows PowerShell.

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

Предупреждение

Невозможно назначить субъект-службу администратором шлюза (даже если субъект-служба является членом группы безопасности). Поэтому планируйте использовать учетные данные пользователя при получении сведений о шлюзах данных.

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

Cmdlet	Целевые назначения
Connect-DataGatewayServiceAccount	Проверка подлинности пользователя Power BI (обычно требует, чтобы пользователь принадлежал роли администратора шлюза).
Get-DataGatewayCluster	Скомпилируйте список кластеров шлюза.
Get-DataGatewayClusterDataSource	Скомпилируйте список источников данных для кластера шлюза.
Get-DataGatewayInstaller	Проверьте, какие пользователи могут устанавливать и регистрировать шлюзы в организации.

Вы можете скачать модуль шлюза данных из галереи PowerShell.

Методы использования PowerShell

PowerShell можно использовать различными способами. Решение, которое вы делаете, является важным.

В следующей таблице описаны три различных метода использования PowerShell.

Техника	Description	Пример
Используйте командлеты PowerShell для упрощения проверки подлинности и вызова API напрямую. Рекомендуемый подход	Благодаря этому методу существует баланс простоты и гибкости. Командлет Invoke-PowerBIRestMethod доступен из модуля профиля менеджмента Power BI. Этот командлет часто называют "швейцарским армейским ножом", поскольку он может использоваться для вызова любого из REST API Power BI. Преимуществом этого метода является упрощение проверки подлинности, а затем вызов любого из REST API Power BI. Настоятельно рекомендуется использовать этот метод.	После проверки подлинности с помощью командлета Connect-PowerBIServiceAccount используйте командлет Invoke-PowerBIRestMethod для получения данных из предпочтительного API (например, Get Pipeline Users As Admin).
Используйте командлеты PowerShell как можно больше для проверки подлинности и получения данных.	С помощью этого метода PowerShell широко используется. PowerShell используется для координации выполнения скрипта, а модули PowerShell используются всякий раз, когда это возможно для доступа к данным. Это создает большую зависимость от PowerShell из нескольких аспектов.	После проверки подлинности с помощью командлета Connect-PowerBIServiceAccount используйте командлет (например, Get-PowerBIActivityEvent), чтобы получить данные.
Используйте PowerShell только для координации выполнения процесса. Модули PowerShell используются как можно меньше.	В этом методе меньше зависимостей от PowerShell в качестве инструмента, так как его основное использование — оркестрация вызовов API. Для доступа к API используется только один универсальный модуль PowerShell (ни один из модулей управления Power BI не используется).	После аутентификации с помощью Библиотеки проверки подлинности Microsoft (MSAL) вызовите предпочитаемый API (например, Get Pipeline Users As Admin) с помощью общего командлета Invoke-RestMethod для получения данных.

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

Совет

Командлет Invoke-ASCmd PowerShell можно использовать для создания и выполнения скриптов DAX, XMLA и TMSL. Однако эти варианты использования недоступны для этой статьи. Дополнительные сведения о запросах динамических административных представлений (ДПП) см. в разделе Аудит уровня данных.

Технические пользователи (и администраторы) могут использовать модули управления Power BI для получения данных или автоматизации определенных аспектов управления содержимым.

• для администраторов: Установите параметр -Scope на Organization для доступа к сущностям в рамках всего клиента (например, чтобы получить список всех рабочих пространств).
• Для технических пользователей: задайте параметру -Scope значение Individual (или опустите параметр), чтобы получить доступ к сущностям, принадлежащим пользователю (например, для получения списка рабочих областей , к которым у пользователя есть доступ).

Рассмотрим сценарий, в котором необходимо получить список семантических моделей. Если вы решили работать непосредственно с API, необходимо указать, какой API следует вызывать. Однако если вы решили использовать командлет Get-PowerBIDataset, можно задать параметр -Scope для получения списка семантических моделей, специфичных для пользователя или для арендатора. Выбор зависит от того, как использовать PowerShell (в предыдущей таблице).

В следующей таблице описывается, как используемые параметры в командлете PowerShell переводятся на вызовы API PowerShell.

Параметры командлета	API, используемый командлетом	Тип API	Область применения	Извлеченные элементы
-DatasetID {DatasetID} -Scope Individual	Получение набора данных	Пользователь	Личное рабочее пространство	Одна семантическая модель
-Scope Individual	Получение наборов данных	Пользователь	Личное рабочее пространство	Все семантические модели
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Получение набора данных в группе	Пользователь	Одна рабочая область	Одна семантическая модель, при условии, что пользователь, вошедшего в систему, имеет разрешение на чтение семантической модели.
-GroupID {WorkspaceID}	Получите наборы данных в группе	Пользователь	Одна рабочая область	Все семантические модели доступны пользователю, при условии, что он вошел в систему и имеет разрешение на доступ к рабочей области и право чтения семантической модели.
-GroupID {WorkspaceID} -Scope Organization	Получение наборов данных в группе от имени администратора	Администратор	Одно рабочее пространство	Все семантические модели
-Scope Organization	Получение наборов данных от имени администратора	Администратор	Весь арендатор	Все семантические модели

Учитываемые моменты при использовании командлетов PowerShell

Командлеты PowerShell Power BI проще использовать, так как они скрывают некоторые сложности вызовов REST API.

Вот некоторые способы, с помощью которых командлеты упрощают доступ к данным аудита.

• Аутентификация: Самый простой способ аутентификации в скрипте PowerShell — это использовать командлет Connect-PowerBIServiceAccount.
• Простота: Проще приступать к работе, так как методы извлечения данных аудита просты. Учитывайте, что при использовании командлета Get-PowerBIActivityEvent вы получите данные аудита за один день. Если вы непосредственно вызываете REST API получения событий, вы извлекаете один час данных аудита. Таким образом, при использовании REST API для получения одного дня данных аудита необходимо использовать цикл для вызова API 24 раз, чтобы извлечь каждый час дня.
• Пагинация больших наборов данных: большие наборы данных эффективно извлекаются с помощью пагинации. Пагинация включает получение одного блока результатов за раз. Командлеты автоматически управляют разбиением на страницы за вас. Однако при непосредственном использовании REST API скрипт должен проверить маркер продолжения, чтобы определить, есть ли какие-либо дополнительные результаты. Скрипт должен продолжать получать фрагменты результатов до тех пор, пока токен продолжения не будет получен. Для примера использования маркера продолжения см. раздел Activity Events REST API.
• срок действия маркера доступа: после проверки подлинности возвращается маркер доступа. По умолчанию срок действия истекает через один час. Командлеты для вас обрабатывают срок действия токена доступа. Таким образом, вам не нужно писать логику для запроса токена обновления.
• Форматирование: Данные, возвращаемые командлетом, немного лучше форматируются, чем данные, возвращаемые REST API. Выходные данные являются более понятными для пользователей. Для автоматизированных процессов аудита это, скорее всего, не будет проблемой. Однако для ручного аудита более приятное форматирование может оказаться полезным.

Рекомендации по прямому использованию интерфейсов REST API

Иногда есть преимущества в использовании REST API Power BI напрямую.

• множество доступных API-интерфейсов. Существует больше интерфейсов REST API, чем командлеты PowerShell. Однако не забывайте о гибкости командлета Invoke-PowerBIRestMethod , который можно использовать для вызова любого из REST API Power BI.
• частота обновлений. Корпорация Майкрософт обновляет ИНТЕРФЕЙСы REST API чаще, чем обновляет модули PowerShell. Например, если новый атрибут добавляется в ответ API Get Dataset, может пройти некоторое время, прежде чем он станет доступен в результатах командлета Get-PowerBIDataset.
• Меньше зависимости от языка или инструментов: Если вы используете интерфейсы REST API напрямую (вместо командлета), вам не нужно использовать PowerShell. Кроме того, вы можете использовать PowerShell только для оркестрации вызовов многих API в скрипте. Удаляя (или избегая) любой зависимости от PowerShell, в будущем можно перезаписать логику на другом языке. Когда у вашего IT-отдела или команды разработчиков есть сильные предпочтения в инструментах и языках, уменьшение зависимости становится важным фактором для учета.

Независимо от того, какой метод вы решили использовать, ИНТЕРФЕЙСы REST API могут изменяться с течением времени. Когда технология развивается, API -интерфейсы (и модули PowerShell) могут быть устаревшими и заменены. Поэтому рекомендуется специально создавать скрипты, которые являются простыми для поддержания и устойчивости к изменению.

Контрольный список - При выборе доступа к REST API напрямую или с помощью командлетов PowerShell, ключевые решения и действия включают:

• Обратитесь к ИТ-специалистам по использованию PowerShell. Обратитесь к соответствующим ИТ-командам, чтобы определить, существуют ли внутренние требования или предпочтения по использованию PowerShell.
• Решите, как использовать PowerShell: определите, какие методы PowerShell следует использовать, и следует ли намеренно увеличивать или уменьшать зависимость от PowerShell. Рассмотрите необходимость внутреннего взаимодействия или обучения.
• обновление до PowerShell Core: исследование с помощью PowerShell Core. Определите, нужно ли обновлять компьютеры администратора. Рассмотрим, какие существующие скрипты необходимо протестировать. Определите, требуются ли администраторы или разработчики дополнительного обучения для обновления своих навыков.
• определите, какие модули PowerShell следует использовать. Рассмотрите, будут ли использоваться модули управления Power BI и (или) модуль шлюза данных.
• Решите, разрешены ли проекты сообщества. Определите, разрешено ли вам (или даже рекомендуется) использовать модули PowerShell, доступные в Интернете (а не модули, опубликованные корпорацией Майкрософт). Обратитесь к ИТ-специалистам, чтобы определить, существуют ли критерии для проектов сообщества, полученных в Интернете.
• Уточните, как поддерживать проекты сообщества. Если разрешены проекты сообщества PowerShell, рассмотрите, кто будет отвечать за их поддержку после их использования внутри системы.
• Выполнить небольшую проверку концепции (POC): провести эксперимент с техническим POC. Подтвердите предпочитаемые клиентские средства и метод доступа к данным.
• Определите, как поддерживать опытных пользователей. Рассмотрите, как вы собираетесь поддерживать технических пользователей, которые создают автоматизацию самостоятельно с помощью пользовательских API.

Определение места хранения данных аудита

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

При извлечении необработанных данных аудита, упростите процесс. Рекомендуется не выбирать определенные атрибуты, выполнять преобразования или применять форматирование при первоначальном извлечении данных. Вместо этого извлеките все доступные атрибуты и сохраните данные в исходном состоянии.

Ниже приведены некоторые причины, по которым хранение необработанных данных в исходном состоянии рекомендуется.

• все данные, доступные в истории: новые атрибуты и новые типы событий будут доступны со временем. Хранение всех необработанных данных — это хороший способ обеспечить всегда доступ к любым данным, доступным в момент извлечения. Даже если вам потребуется время ( это может быть несколько недель или месяцев), чтобы понять, что доступны новые атрибуты данных, можно проанализировать их исторически, так как вы их захватили в необработанных данных.
• Устойчивый к изменениям: если формат необработанных данных изменяется, процесс извлечения данных не затрагивается. Так как некоторые данные аудита чувствительны к времени, важно убедиться, что вы разрабатываете процесс извлечения данных, который не завершится ошибкой при изменении в источнике.
• роли и обязанности: различные члены команды (например, инженеры данных или администраторы Структуры) могут отвечать за создание процессов для доступа, извлечения и хранения необработанных данных аудита. Упрощение процесса извлечения данных упрощает совместную работу нескольких команд.

Ниже приведены некоторые варианты хранения необработанных данных.

• озера данных или хранилища объектов: облачная служба, например OneLake, которая специализируется на хранении файлов любой структуры. Это идеальный выбор для хранения необработанных данных аудита. В архитектуре озера данных необработанные данные должны храниться в бронзовом слое.
• файловая система: файловая система (например, Windows или Linux) рассматривается как распространенный выбор для хранения необработанных данных аудита.
• база данных: можно хранить данные JSON в реляционной базе данных, например базе данных SQL Azure. Однако это менее распространено, чем хранение данных в озере данных или файловой системе. Это связано с тем, что запросы и обслуживание данных JSON могут стать сложными и дорогостоящими, особенно по мере роста томов данных.

Совет

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

Рассмотрим пример, связанный с необработанной зоной данных в озере данных. В зоне имеется иерархия папок для хранения данных журнала действий: Raw > ActivityLog > YYYY > MM. Папки секционируются по годам и месяцам. Файл, хранящийся в папке месяца, использует следующий формат: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDDD представляет фактические данные, а YYYYMMDDTT представляет метку времени извлечения. Включив метку времени извлечения, можно определить, какой файл является последним (в случае, если необходимо снова извлечь данные). Например, если вы извлекаете данные в 9 утра (UTC) 25 апреля 2023 г. для активности 23 апреля 2023 г., имя файла будет PBIActivityLog-20230423-202304250900.

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

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

Ниже приведены некоторые рекомендации, которые помогут вам выбрать хранилище необработанных данных.

• Это ручной или автоматизированный процесс аудита? Процесс автоматического аудита обычно имеет более строгие требования к тому, как и где хранятся данные.
• Является ли область темы особенно чувствительной? В зависимости от типа данных и их конфиденциальности ваша организация может иметь требование о том, как и где он хранится. Данные аудита Power BI содержат сведения о пользователях и IP-адресах, поэтому они должны храниться в безопасной области.
• Есть ли предпочтительная технология хранения? В организации может существовать существующая технология хранения, которая используется в организации, поэтому это логический выбор.
• Будут ли пользователи получать доступ к хранилищу напрямую? Модель безопасности является важным фактором. Как правило, очень мало пользователей получают доступ к необработанным данным. Доступ к курируемым данным обычно предоставляется создателям содержимого Power BI, которые отвечают за создание централизованной модели данных (семантической модели, которая служит слоем отчетов).
• У вас есть требования к месту размещения данных? Некоторые организации имеют юридические или нормативные требования к месту размещения данных для хранения данных в определенном регионе данных.
• Как будут организованы данные? Использование архитектуры медальона является распространенной практикой, особенно в реализации озера данных и хранилища на основе озера данных. Цель заключается в хранении данных в бронзовых, серебряных и золотых слоях данных. Бронзовый слой содержит исходные необработанные данные. Серебряный слой содержит проверенные и дедупликированные данные, используемые для преобразований. Золотой слой содержит проверенные, высокоуровневые данные, готовые к анализу.

Контрольный список . При планировании расположения для хранения необработанных данных ключевые решения и действия включают:

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

План создания отобранных данных

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

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

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

Озеро данных

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

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

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

Модель данных Power BI

Возможно, вы сможете завершить все операции преобразования в Power BI. Используйте Power Query для доступа к данным и преобразования данных из его необработанного состояния в проверенный формат.

Используйте модель данных Power BI, когда:

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

Совет

При создании курируемых данных настройте его таким образом, чтобы можно было легко повторно запустить процесс для более ранних диапазонов дат. Например, если вы обнаружите, что новый атрибут появился в журналах аудита три месяца назад, вам захочется проанализировать его с момента его первого появления. Возможность перезагрузить журнал проверенных данных является одной из нескольких причин, по которым важно хранить необработанные данные в исходном состоянии (описано выше в этой статье).

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

Контрольный список — при планировании создания курируемых данных ключевые решения и действия включают:

• определите, где должны выполняться преобразования. Рассмотрим, на каком этапе системы следует выполнить работу по преобразованию, и как это укладывается в ваш план для всей архитектуры.
• Решите, какой инструмент использовать для преобразования данных в звёздную схему: подтвердите, какие инструменты и службы будут использоваться для преобразования необработанных данных в кураторские данные.
• Решите, где должны храниться проверенные данные: определите оптимальный выбор для хранения необработанных данных, преобразованных в формат схемы звездочки. Определите, полезен ли промежуточный серебряный слой в комплексной архитектуре.
• Создание соглашения об именовании. Определение соглашения об именовании, используемого для курированных файлов и папок данных (если применимо). Добавьте сведения в техническую документацию.
• Рассмотрим, как безопасность для курируемых данных будет работать: при проектировании расположения для хранилища данных, необходимо указать, кто должен получить доступ к данным и каким образом будет назначена безопасность.

Решения по источнику данных

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

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

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

Power BI интегрирует свои журналы с единым журналом аудита Microsoft Purview (прежнее название — единый журнал аудита Microsoft 365). Эта интеграция является преимуществом, так как это означает, что каждая служба в Microsoft 365 не требует реализации собственного уникального способа ведения журнала. По умолчанию он включен.

Внимание

Если вы еще не извлекаете данные о действиях пользователя, сделайте это срочным приоритетом. Данные о действиях пользователя доступны в течение последних 30 или 90 дней (в зависимости от источника). Даже если вы не готовы к глубокой аналитике, важно приступить к извлечению и хранению данных как можно скорее. Таким образом, ценная история будет доступна для анализа.

У вас есть несколько вариантов получения данных о действиях пользователей.

Техника	Description	Доступные дни истории по умолчанию	Хороший выбор для процессов аудита вручную	Хороший выбор для автоматизированных процессов аудита	Хороший выбор для настройки оповещений	Хороший выбор, чтобы быстро приступить к работе
Вручную (пользовательский интерфейс)	Портал соответствия требованиям Microsoft Purview	девяносто
Вручную (пользовательский интерфейс)	Defender для облачных приложений	30
Программный	Журнал активности в Power BI (API или командлет PowerShell)	28
Программный	API управляемой активности Office 365	7
Программный	Microsoft Sentinel (Azure Monitor)	30

Оставшаяся часть этого раздела содержит все методы, представленные в таблице.

Портал соответствия требованиям Microsoft Purview

Средство поиска аудита в портале соответствия требованиям Microsoft Purview (прежнее название — Центр соответствия требованиям Microsoft 365) — это удобное место для просмотра действий и оповещений. Это средство не требует создания скрипта для извлечения и скачивания данных. Вы можете выбрать рабочую нагрузку Power BI, чтобы просмотреть все записи журнала аудита в течение определенного диапазона времени. Вы также можете сузить результаты, выбрав определенные действия и пользователей. Например, менеджер просит узнать, кто удалил рабочую область ранее в тот день, чтобы они могли быстро связаться с человеком, чтобы обсудить ситуацию.

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

Существуют требования к лицензированию для доступа к журналам аудита в Портал соответствия требованиям Microsoft Purview. Для доступа к журналам аудита также требуются повышенные разрешения Exchange Online.

Совет

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

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

Defender для облачных приложений

Портал в Defender для облачных приложений — это удобное место для просмотра действий и оповещений без необходимости создания скрипта для извлечения и загрузки данных. Он также позволяет просматривать данные из журнала действий Power BI и входа пользователей.

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

Как и Портал соответствия требованиям Microsoft Purview (описано в предыдущем разделе), Defender для облака Apps имеет доступный для поиска пользовательский интерфейс. Однако параметры фильтра отличаются. Помимо стандартной 30-дневной истории, вы можете использовать Defender для облачных приложений для просмотра до шести месяцев журнала действий (с интервалом в семь дней).

Существуют требования к лицензированию для доступа к приложениям Defender для облака. Также требуются отдельные разрешения .

Совет

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

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

Журнал действий Power BI

Журнал действий Power BI создается из единого журнала аудита. Он содержит только действия пользователей, связанные с служба Power BI.

Совет

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

У вас есть два варианта доступа к журналу действий Power BI.

• Используйте REST API для получения событий активности с помощью выбранного вами средства.
• Используйте командлет PowerShell Get-PowerBIActivityEvent. Он доступен в модуле администратора управления Power BI.

Сведения о том, какой вариант можно использовать, см. в разделе "Выбор API" или командлетов PowerShell, приведенных ранее в этой статье.

Совет

Примеры доступa к журналу действий Power BI с помощью PowerShell см. в Доступ к журналу действий Power BI.

Данные журнала действий Power BI доступны всем администраторам Fabric и администраторам Power Platform. Доступ к данным можно получить из единого журнала аудита, доступного для определенных ролей Exchange Online. Дополнительные сведения см. в разделе "Отслеживание действий пользователей" в Power BI.

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

Примечание.

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

API управляемой активности Office 365

Вы можете извлечь данные из единого журнала аудита для других служб, таких как SharePoint Online, Teams, Exchange Online, Dynamics 365 и Power BI. При реализации решения аудита и мониторинга для нескольких служб рекомендуется использовать API действий управления Office 365. Так как этот API возвращает данные из многих служб, он называется API единого аудита (или единый журнал аудита). Это один из API управления Office 365.

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

Доступ к данным можно получить одним из двух способов.

• Вызовите API действий управления Office 365 напрямую с помощью выбранного средства. По умолчанию API возвращает 24 часа данных. Вы можете получить доступ не более чем к семи дням истории.
• Используйте командлет PowerShell Search-UnifiedAuditLog. Это командлет PowerShell для Exchange Online. Вы можете получить максимум 90 дней истории.

Внимание

Командлет Search-UnifiedAuditLog плохо масштабируется, и требуется реализовать стратегию повторения, чтобы преодолеть его ограничение в 5000 строк. По этим причинам он подходит для случайных запросов или для небольших организаций, которые испытывают низкую активность. Когда вам нужны только данные Power BI, мы рекомендуем вместо этого использовать командлет Get-PowerBIActivityEvent.

Как правило, приступить к работе с API управления действиями Office 365 сложнее, чем использовать журнал активности Power BI, о котором упоминалось ранее. Это связано с тем, что API возвращает большие двоичные объекты содержимого, а каждый большой двоичный объект содержимого содержит отдельные записи аудита. Для крупных организаций в день могут быть тысячи блобов содержимого. Поскольку клиенты и сторонние приложения часто используют этот API, корпорация Майкрософт вводит ограничение, чтобы гарантировать, что использование ими службы не оказывает негативного влияния на других (известная как проблема шумных соседей). Таким образом, получение больших объемов истории может быть проблемой в крупных организациях. Дополнительные сведения см. в этой статье по устранению неполадок.

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

Совет

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

Получение данных аудита программным способом из API действий управления Office 365 — это хороший выбор, когда ИТ-отделу необходимо извлечь и сохранить журналы аудита из различных служб (за пределами Power BI).

Microsoft Sentinel

Microsoft Sentinel — это служба Azure, которая позволяет собирать, обнаруживать, исследовать и реагировать на инциденты безопасности и угрозы. Power BI можно настроить в Microsoft Sentinel в качестве соединителя данных. При подключении журналы аудита (содержащие подмножество данных) передаются из Power BI в Azure Log Analytics, что является возможностью Azure Monitor.

Совет

Azure Log Analytics основан на той же архитектуре, которая используется журналами событий семантической модели на уровне рабочей области. Дополнительные сведения о журналах событий семантической модели см. в разделе "Аудит на уровне данных".

Поскольку это отдельная служба Azure, всем администраторам или пользователям, которым необходимо выполнять запросы на языке запросов Kusto (KQL), нужно предоставить разрешения в Azure Log Analytics (Azure Monitor). Если у них есть разрешение, они могут запрашивать данные аудита, хранящиеся в таблице PowerBIActivity . Однако помните, что в большинстве случаев вам следует предоставлять пользователям доступ к курируемым данным на золотом слое, а не к необработанным данным в бронзовом слое.

Для анализа событий журнала действий, хранящихся в Azure Log Analytics, используется KQL. Если у вас есть опыт SQL, вы найдете много сходств с KQL.

Существует несколько способов доступа к событиям, хранящимся в Azure Log Analytics. Вы можете использовать:

• Предустановленное шаблонное приложение Log Analytics для семантических моделей Power BI.
• Коннектор Power BI Desktop для Azure Data Explorer (Kusto).
• Веб-интерфейс запросов в Azure Data Explorer.
• Любое средство запроса, которое может отправлять запросы KQL.

Внимание

Помните, что в Azure Monitor хранится только подмножество данных журнала действий Power BI. При планировании комплексного анализа использования и внедрения Power BI в организации рекомендуется использовать другие параметры (описанные ранее в этом разделе) для получения данных о действиях.

Период истории, который можно получить, зависит от политики хранения данных для рабочей области Azure Log Analytics. Учитывайте затраты и доступ к необработанным данным при выборе объема сохраненных данных.

Microsoft Sentinel и Azure Monitor являются хорошими вариантами, когда ИТ-служба уже сделала инвестиции в Microsoft Sentinel, уровень детализации отвечает вашим потребностям, и такие действия, как обнаружение угроз, являются приоритетом. Однако, так как Microsoft Sentinel не записывает все данные о действиях Power BI, он не поддерживает комплексный анализ использования и внедрения Power BI.

Рекомендации по данным о действиях пользователей

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

• Будет ли это процесс ручного или автоматического аудита? Параметры пользовательского интерфейса хорошо работают для процессов аудита вручную и случайных одноуровневых запросов, особенно если необходимо исследовать определенное действие. Процесс автоматического аудита, который извлекает данные о действиях пользователя по расписанию, также потребуется для поддержки анализа исторических данных.
• Как часто требуются данные о действиях пользователя? Для процессов автоматического аудита запланируйте извлечение данных, которые были извлечены, по крайней мере, за один день до текущей даты, используя универсальное координированное время (UTC), вместо локального времени. Например, если процесс выполняется в пятницу утром (UTC), вы должны извлечь данные за среду. Существует несколько причин, по которым следует извлекать данные с задержкой в один день.
  • Ваши файлы будет легче обрабатывать, если вы всегда извлекаете полные 24 часа за раз, что позволяет избегать частичных результатов дня.
  • Вы сведёте к минимуму риск упустить некоторые события аудита. Обычно события аудита поступают в течение 30 минут. Иногда некоторым событиям может потребоваться до 24 часов, чтобы дойти до единого журнала аудита.
• Нужны ли вам дополнительные данные Power BI? Рассмотрите наиболее эффективный способ доступа к нужным ресурсам.
  • Если вам нужны только данные о действиях пользователя Power BI, используйте журнал действий Power BI.
  • Если вам нужны журналы аудита из нескольких служб, используйте API действий управления Office 365 для доступа к единому журналу аудита.
• Кто будет разрабатывать решение? Планируйте инвестировать некоторое время, чтобы построить решение. Для создания сценария, готового к работе, может потребоваться значительное количество усилий.

Контрольный список . При планировании доступа к данным о действиях пользователей, к ключевым решениям и действиям относятся:

• Уточняйте область потребностей. Определите, требуется ли доступ только к записям аудита Power BI или данным аудита для нескольких служб.
• Консультируйтесь с ИТ: Узнайте, извлекает ли IT журналы аудита, и можно ли получить доступ к необработанным данным, чтобы не нужно было создавать новое решение.
• Определите источник данных. Определите лучший источник для доступа к данным о действиях пользователей.
• Завершить проверку концепции: Запланировать выполнение небольшого технического подтверждения концепции (POC). Используйте его для проверки ваших решений о том, как будет создано окончательное решение.
• Отслеживание дополнительных потребностей в данных. Вы можете сопоставить данные журнала действий с другими источниками, чтобы повысить ценность данных. Следите за этими возможностями по мере их возникновения, чтобы они могли добавляться в область вашего проекта.

Доступ к данным инвентаризации клиентов

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

Действия пользователей (ранее описанные) являются событиями аудита; Это запись действий, выполняемых пользователем по определенной дате и времени. Однако инвентаризация арендаторов отличается. Инвентаризация клиента — это моментальный снимок в определенный момент времени. В нем описывается текущее состояние всех опубликованных элементов в службе Power BI во время его извлечения.

Примечание.

Документация по REST API Power BI ссылается на опубликованные элементы как артефакты.

Совет

Многие организации считают полезным извлекать инвентаризацию аренда в одно и то же время каждую неделю.

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

Для получения дополнительной информации о значении инвентаризации арендаторов см. раздел "Инвентаризация арендаторов" ранее в этой статье.

Совет

Вы можете использовать API Get Unused Artifacts as Admin для поиска элементов, у которых не было активности пользователя за последние 30 дней. Однако вы не можете настроить этот период времени. Например, у вас может быть критически важное содержимое, которое используется только ежеквартально. Объединяя инвентаризацию арендаторов с данными о действиях пользователей, вы можете находить неиспользуемые элементы с возможностью настройки.

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

Техника	Description	Наиболее подходит для	Хороший выбор для процессов аудита вручную	Хороший выбор для автоматизированных процессов аудита
Программный подход	Get Groups as Admin API или Get-PowerBIWorkspace командлет PowerShell могут предоставлять список рабочих областей для всего клиента. При необходимости можно включить отдельные элементы (например, семантические модели и отчеты) для каждой рабочей области.	Небольшие организации или низкий объем данных
Программный	Набор асинхронных административных API, совокупно известных как API-интерфейсы сканирования метаданных или API сканера, может возвращать список рабочих областей и отдельных элементов. Кроме того, можно включить подробные метаданные (например, таблицы, столбцы и выражения мер).	Организации с большим объемом данных и/или необходимость получения подробных результатов

Оставшаяся часть этого раздела содержит все методы, представленные в таблице.

Командлеты API для групп или рабочих областей

Чтобы получить список рабочих областей, можно использовать один из нескольких REST API, таких как API для получения групп с правами администратора (с помощью средства на ваш выбор). Результаты включают дополнительные метаданные, такие как описание и информация о том, хранится ли рабочая область в емкости Premium.

Примечание.

Именованный API включает термин group в качестве ссылки на рабочее пространство. Этот термин был создан из исходной модели безопасности Power BI, которая опиралась на группы Microsoft 365. Хотя модель безопасности Power BI значительно развивалась на протяжении многих лет, существующие имена API остаются неизменными, чтобы избежать нарушения существующих решений.

Get Groups as Admin REST API включает полезный $expand параметр. Этот параметр позволяет дополнительно расширить результаты, чтобы они включали список элементов, опубликованных в рабочей области (например, семантические модели и отчеты). Вы также можете передать тип данных users параметру $expand, чтобы включить пользователей, которым назначена роль в рабочей области.

Вы также можете использовать командлет PowerShell Get-PowerBIWorkspace. Это из модуля управления рабочими областями Power BI. При настройке -Scope параметра organizationон работает так же, как Get Groups as Admin API. Командлет также принимает параметр -Include (который соответствует параметру $expand в REST API) для включения в рабочую область элементов, таких как семантические модели и отчеты.

Совет

Передав параметры, можно использовать командлет различными способами. В этом разделе основное внимание уделяется получению инвентаризации на уровне арендатора. Дополнительные сведения об использовании параметра -Scope см. в разделе "Выберите API пользователя или API администратора" в начале этой статьи.

Чтобы помочь вам выбрать, какую опцию использовать, см. Выбор API или командлетов PowerShell ранее в этой статье.

Get Groups as Admin REST API или Get-PowerBIWorkspace командлет PowerShell лучше всего подходит для ручного аудита и разовых расследований. Крупные организации с большим объемом данных обычно находят эти варианты сложно использовать. REST API и командлет всегда извлекают полный набор данных, поэтому их выполнение может занять много времени. Таким образом, скорее всего, крупные организации столкнутся с ограничениями на количество запросов, разрешенного в час (известного как дросселирование, которое осуществляется для защиты работоспособности службы). API-интерфейсы сканирования метаданных (описанные далее) предоставляют более надежную и масштабируемую альтернативу.

API проверки метаданных

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

Примечание.

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

Существует две основные причины, по которым следует рассмотреть возможность использования API-интерфейсов проверки метаданных вместо Get Groups as Admin REST API или командлета Get-PowerBIWorkspace (описано ранее).

• инкрементальная выборка данных. API сканера извлекает только измененные данные, начиная с последнего запуска. И наоборот, Get Groups as Admin REST API и Get-PowerBIWorkspace командлет являются синхронными операциями, которые извлекают полный набор данных при каждом запуске.
• Более детализированный уровень: API сканера могут получать детальные сведения (такие как таблицы, столбцы и выражения мер) при условии, что разрешение на это предоставлено двумя параметрами клиента для детализированных метаданных. И наоборот, самый низкий уровень детализации, доступный при использовании REST API и командлета, — по типу элемента (например, списку отчетов в рабочей области).

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

Ниже приведена последовательность шагов, которые следует выполнить при использовании API сканера.

1. Войдите: Войдите в службу Power BI с помощью учетной записи администратора Power BI или учетной записи службы с разрешением на запуск административных API. Дополнительные сведения см. в разделе "Определение метода проверки подлинности" ранее в этой статье.
2. Получите идентификаторы рабочих областей: отправьте запрос на получение списка идентификаторов рабочих областей. При первом запуске у вас не будет измененной даты, поэтому она вернет полный список рабочих областей. Обычно вы указываете дату изменения, чтобы получить только те рабочие области, которые изменились с этого момента во времени. Дата изменения должна находиться в течение последних 30 дней.
3. инициировать проверку метаданных: инициируйте вызов запрашивать проверку сведений о рабочей области путем передачи идентификаторов рабочей области, полученных на шаге 2. Обратите внимание, что это API POST (вместо API GET , который чаще всего используется при получении данных аудита). API POST — это HTTP-запрос, который создает или записывает данные для указанного ресурса. Этот запрос задает уровень детализации, который будет извлечен, например сведения о источнике данных, схеме семантической модели, выражениях семантической модели или пользователях. При отправке API возвращает идентификатор для сканирования. Он также возвращает дату и время сканирования, которые необходимо записать как дату моментального снимка.
4. Проверьте статус сканирования. Используйте идентификатор сканирования, полученный на шаге 3, чтобы получить статус сканирования . Возможно, вам потребуется вызвать этот API несколько раз. Когда возвращенный статус успешный, можно перейти к следующему шагу. Время сканирования зависит от объема запрашиваемого объема данных.
5. Получить результаты: Используйте идентификатор сканирования, полученный на шаге 3, чтобы получить результат сканирования и извлечь данные. Этот шаг необходимо выполнить в течение 24 часов после завершения шага 4. Помните, что метка времени моментального снимка должна быть сопоставлена с шагом 3, а не шагом 5 (при наличии значительной задержки). Таким образом, у вас будет точную метку времени моментального снимка. Сохраните результаты в предпочтительном расположении хранилища данных. Как уже описано в этой статье, рекомендуется хранить необработанные данные в исходном состоянии.
6. Подготовка к следующему процессу: запишите метку времени сканирования на шаге 3, чтобы использовать его в шаге 2 при следующем запуске процесса. Таким образом, вы будете извлекать только измененные данные с момента этого момента. В дальнейшем все последующие извлечения данных будут инкрементальными изменениями, а не полными копиями.

Контрольный список . При планировании доступа к данным инвентаризации клиентов, к ключевым решениям и действиям относятся:

• Подтвердите требования: Уточните потребности для составления инвентаризации арендаторов и аналитических требований к данным.
• Определите частоту извлечения инвентаря арендаторов: Убедитесь, что вам нужна новая инвентаризация арендаторов (например, каждую неделю).
• Определите, как извлекать инвентаризацию арендаторов: убедитесь, какой метод вы будете использовать для получения данных инвентаризации арендаторов (API, командлет или метод API для сканирования метаданных).
• Завершить проверку концепции: Запланировать выполнение небольшого технического подтверждения концепции (POC). Используйте его для проверки ваших решений о том, как будет создано окончательное решение.

Доступ к данным пользователей и групп

Помимо сведений об идентификации (например, адреса электронной почты), включенных в данные действий пользователя, важно получить дополнительные сведения, такие как расположение или сведения о организации. Microsoft Graph можно использовать для получения данных о пользователях, группах, доверенных лицах-служб и лицензиях. Microsoft Graph состоит из набора API и клиентских библиотек, которые позволяют извлекать данные аудита из различных служб.

Ниже приведены некоторые сведения о объектах Microsoft Entra, к которым можно получить доступ.

• пользователя: учетная запись, которая существует в системе Microsoft Entra ID в качестве рабочей, учебной или учетной записи Майкрософт. Термин "пользователь домена" часто используется для описания пользователей организации, а формальный термин — имя участника-пользователя (UPN). Имя UPN обычно совпадает с адресом электронной почты пользователя (однако, если адрес электронной почты изменяется, имя UPN не изменяется, так как оно неизменяемо). Существует также уникальный идентификатор Microsoft Graph для каждого пользователя. Часто учетная запись пользователя связана с одним человеком. Некоторые организации создают пользователей, которые являются учетными записями служб, которые используются для автоматизированных действий или для административных задач.
• служебный принципал: другой тип идентификатора, который создается при создании регистрации приложения. Учётная запись службы предназначена для автоматических задач, выполняемых без участия человека. Дополнительные сведения см. в разделе "Определение метода проверки подлинности" ранее в этой статье.
• Группа: коллекция пользователей и сервисных руководителей. Существует несколько типов групп , которые можно использовать для упрощения управления разрешениями. Дополнительные сведения см. в статье "Стратегия использования групп".

Примечание.

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

Извлекаемые данные пользователей и групп — это моментальный снимок , описывающий текущее состояние в определенный момент времени.

Совет

Дополнительные сведения о пользователях, принципалах службы и группах см. в Интеграция с Microsoft Entra ID.

Аналитические атрибуты

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

• полное имя пользователей: многие источники данных включают только адрес электронной почты пользователя, который выполнил действие или которому назначена роль. Используйте этот атрибут, если вы хотите отобразить полное имя (отображаемое имя) в аналитических отчетах. Использование полного имени делает отчеты более понятными для пользователей.
• Другие свойства пользователей: другие описательные атрибуты о пользователях могут быть доступны в идентификаторе Microsoft Entra. Некоторые примеры встроенных атрибутов профиля пользователя, которые имеют аналитическое значение, включают название задания, отдел, менеджер, регион и расположение офиса.
• Члены группы безопасности: Большинство источников данных предоставляют имя группы (например, записи журнала действий Power BI, в которых указано, что группа безопасности была назначена на роль в рабочей области). Получение членства в группе улучшает ваши возможности для полного анализа того, что делает отдельный пользователь или к чему он имеет доступ.
• лицензии пользователей: полезно проанализировать, какие лицензии пользователей— бесплатные, Power BI Pro или Power BI Premium на пользователя (PPU) — назначены пользователям. Эти данные помогут определить, кто не использует свою лицензию. Он также помогает анализировать всех пользователей (отдельных пользователей с лицензией) и активных пользователей (с недавними действиями). Если вы планируете добавлять или расширять лицензии Power BI Premium, рекомендуется анализировать данные лицензии пользователя вместе с данными о действиях пользователя для выполнения анализа затрат.
• Члены ролей администратора. Вы можете составить список администраторов Power BI (включая администраторов Power Platform).

Достоверную ссылку на сведения о лицензии Power BI, которые можно найти в данных аудита из Microsoft Graph, см. в разделе "Имена продуктов" и идентификаторы плана обслуживания для лицензирования.

Совет

Получение участников из групп является одним из наиболее сложных аспектов получения данных аудита. Для выравнивания всех вложенных элементов и вложенных групп необходимо выполнить транзитивный поиск . Вы можете выполнить транзитивный поиск участников группы. Этот тип поиска особенно сложно, если в организации есть тысячи групп. В этом случае можно рассмотреть более альтернативные варианты получения данных. Одним из вариантов является извлечение всех групп и членов группы из Microsoft Graph. Однако это может оказаться нецелесообразным, если для безопасности Power BI используется только небольшое количество групп. Другой вариант — предварительно создать список ссылочных групп, которые используются любым типом безопасности Power BI (роли рабочей области, разрешения приложения, общий доступ к элементам, безопасность на уровне строк и т. д.). Затем можно выполнить перебор по списку ссылок, чтобы получить участников группы из Microsoft Graph.

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

• пользовательский тип: пользователи либо члены, либо гости. Чаще всего члены являются внутренними пользователями и гостями— это внешние (B2B) пользователи. Хранение типа пользователя полезно, если необходимо проанализировать действия внешних пользователей.
• изменения ролей. При выполнении аудита безопасности полезно понять, когда пользователь изменил роли в организации (например, при передаче в другой отдел). Таким образом, можно проверить, были ли параметры безопасности Power BI обновлены или должны быть обновлены.
• отключенные пользователи: когда пользователь покидает организацию, администратор отключает свою учетную запись. Вы можете создать процесс, чтобы проверить, являются ли отключенные пользователи администраторами рабочей области или владельцами семантических моделей.

Совет

Журнал действий Power BI включает событие, которое записывается при регистрации пользователя на пробную лицензию. Это событие можно объединить с данными лицензии пользователя (источником из идентификатора Microsoft Entra) для создания полной картины.

Получение данных пользователей и групп

Данные о пользователях и группах можно получить разными способами.

Техника	Description	Хороший выбор для процессов аудита вручную	Хороший выбор для автоматизированных процессов аудита
Руководство	Обозреватель Graph
Программный	API и пакеты SDK Для Microsoft Graph
программатика	Модуль Az PowerShell

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

Примечание.

Будьте осторожны при чтении информации в Интернете, так как многие имена инструментов похожи. Некоторые средства в экосистеме Майкрософт включают термин Graph в их имени, например Azure Resource Graph , GraphQL и API Microsoft Security Graph. Эти средства не связаны с Microsoft Graph, и они не относятся к этой статье.

Microsoft Graph Explorer

Microsoft Graph Explorer — это средство разработчика, которое позволяет узнать об API Microsoft Graph. Это простой способ начать работу, так как он не требует других средств или настройки на компьютере. Вы можете войти, чтобы получить данные от вашего арендатора или извлечь примеры данных от арендатора по умолчанию.

Обозреватель Graph можно использовать для следующих способов:

• Вручную отправьте запрос в API Microsoft Graph, чтобы проверить, возвращает ли он нужные сведения.
• Узнайте, как создать URL-адрес, заголовки и текст перед написанием скрипта.
• Неформальный способ проверки данных.
• Определите, какие разрешения необходимы для каждого API. Вы также можете предоставить согласие на новые разрешения.
• Получите фрагменты кода для использования при создании скриптов.

Используйте эту ссылку , чтобы открыть обозреватель Graph.

API и пакеты SDK Для Microsoft Graph

Используйте API Microsoft Graph для получения данных пользователей и групп. Вы также можете использовать его для получения данных из таких служб, как Идентификатор Microsoft Entra, SharePoint Online, Teams, Exchange, Outlook и многое другое.

Пакеты SDK Microsoft Graph действуют в качестве оболочки API на основе базовых API Microsoft Graph. Пакет SDK — это пакет средств разработки программного обеспечения, который объединяет средства и функциональные возможности. Пакеты SDK Microsoft Graph предоставляют весь набор API Microsoft Graph.

Вы можете отправлять запросы непосредственно в API. Кроме того, можно добавить слой упрощения с помощью предпочитаемого языка и одного из пакетов SDK. Дополнительные сведения см. в разделе Выбор API или командлетов PowerShell ранее в этой статье.

Пакеты SDK Microsoft Graph поддерживают несколько языков, а также модули Microsoft Graph PowerShell . Другие пакеты SDK доступны для Python, C# и других языков.

Внимание

Модуль Microsoft Graph PowerShell заменяет модули Azure AD PowerShell и модули MSOnline (MSOL), которые являются устаревшими. Не следует создавать новые решения с устаревшими модулями. Модуль Microsoft Graph PowerShell имеет множество функций и преимуществ. Дополнительные сведения см. в статье Об обновлении Azure AD PowerShell до Microsoft Graph PowerShell.

Модули Microsoft Graph PowerShell можно установить из PowerShell Gallery. Так как Microsoft Graph работает со многими службами Microsoft 365, вы устанавливаете множество модулей PowerShell.

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

• Проверка подлинности (для входа)
• Пользователи
• Группы
• Приложения (и служебные учетные записи)
• Объекты каталога (и сведения о лицензии)

Совет

Корпорация Майкрософт регулярно обновляет модули Microsoft Graph PowerShell. Иногда модули предварительной версии становятся доступными на стадии предварительной разработки или в бета-версии интерфейса. Вам может потребоваться указать нужную версию при установке и обновлении модулей. Кроме того, при просмотре онлайн-документации обратите внимание, что номер текущей версии автоматически добавляется в конец URL-адреса (поэтому будьте осторожны при сохранении или обмене URL-адресами).

Модуль Az PowerShell

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

Внимание

Модуль Az PowerShell заменяет модули AzureRM PowerShell, которые устарели. Не следует создавать новые решения с устаревшими модулями.

Вы можете использовать командлет Invoke-AzRestMethod, если для API нет соответствующего командлета. Это гибкий подход, позволяющий отправлять запрос в любой API Microsoft Graph с помощью модуля Az PowerShell.

Начиная с версии 7, командлеты Az теперь ссылаются на API Microsoft Graph. Поэтому модуль Az выступает в качестве оболочки API на вершине Microsoft Graph. Модули Az имеют подмножество функций, содержащихся в API Microsoft Graph и модулях PowerShell. Для новых решений рекомендуется использовать пакет SDK Microsoft Graph PowerShell.

Устаревшие API и модули

Вы можете найти статьи и записи блога в Интернете, которые предлагают альтернативные варианты, которые не представлены в этом разделе. Настоятельно рекомендуется не создавать новые решения (или переносить существующие решения) с помощью любого из следующих API или модулей.

• модули AzureRM PowerShell: устаревшие и будут прекращены. Они были заменены модулем Az PowerShell.
• API Azure AD Graph и модуль Azure AD PowerShell: не рекомендуется и будет прекращен. Это изменение является результатом миграции из Azure AD Graph в Microsoft Graph (обратите внимание, что Graph отображается в обоих именах, но Microsoft Graph — это будущее направление). Все будущие инвестиции в PowerShell будут осуществляться в SDK Microsoft Graph PowerShell.
• Модуль PowerShell MS Online (MSOL): устаревший и будет выведен из эксплуатации. Все будущие инвестиции в PowerShell будут осуществляться в SDK Microsoft Graph PowerShell.

Внимание

Обязательно подтвердите состояние любого нерекомендуемого API или модуля, который вы используете в настоящее время. Дополнительные сведения о выходе на пенсию AzureRM см. это объявление.

Дополнительные сведения об идентификаторе Microsoft Entra ID и MSOL см. в этой публикации об окончании поддержки.

Если у вас есть вопросы или требуется уточнение в будущем направлении программного доступа к данным, обратитесь к группе учетной записи Майкрософт.

Контрольный список . При планировании доступа к данным пользователей и группам, к ключевым решениям и действиям относятся:

• Подтвердите требования: Уточните потребности в сборе данных о пользователях, группах и лицензиях.
• Приоритизация требований: Убедитесь, какие приоритеты являются основными, чтобы знать, на что тратить время в первую очередь.
• Определите частоту извлечения данных. Определите, как часто требуется новый моментальный снимок данных пользователей и групп (например, каждую неделю или каждый месяц).
• Решите, как извлечь данные с помощью Microsoft Graph: определите, какой метод будет использоваться для извлечения данных.
• Завершите проверку концепции: Запланируйте завершение небольшой технической проверки концепции (POC) для извлечения данных о пользователях и группах. Используйте его для проверки ваших решений о том, как будет создано окончательное решение.

Доступ к данным из REST API Power BI

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

Например, можно получить данные о следующих возможностях:

• Все приложения в организации.
• Все импортированные семантические модели в организации.
• Все потоки развертывания в организации.
• Все Premium возможности в организации.

Во время аудита безопасности может потребоваться определить следующее:

• Элементы, широко разделяемые всей организацией.
• Объекты, доступные в общедоступном Интернете с помощью публикации в веб.

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

Контрольный список. При планировании доступа к данным из API Power BI, к ключевым решениям и действиям относятся:

• Сбор требований: Составление аналитических требований по мере их возникновения. Следите за ними в списке дел.
• Приоритеты требований. Задайте приоритеты для новых требований, возникающих.

Этап 2. Предварительные требования и настройка

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

Создание учетной записи хранения

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

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

Контрольный список . При создании учетной записи хранения ключевые решения и действия включают:

• создание учетной записи хранения: создание или отправка запроса для создания учетной записи хранения. По возможности используйте неизменяемые параметры хранилища для необработанных данных.
• Задать разрешения. Определите, какие разрешения следует задать для учетной записи хранения.
• Тест доступа: Выполните небольшой тест, чтобы убедиться, что вы можете читать и записывать данные в учетную запись хранения.
• Утвердить обязанности. Убедитесь, что вы четко знаете, кто будет ответственным за управление учетной записью хранения на постоянной основе.

Установка программного обеспечения и настройка служб

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

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

Если вы приняли решение (предыдущее описание) использовать PowerShell, необходимо установить PowerShell Core и необходимые модули PowerShell в:

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

Если вы решили использовать любые службы Azure (например, Функции Azure, служба автоматизации Azure, Фабрика данных Azure или Azure Synapse Analytics), необходимо подготовить и настроить их.

Контрольный список . При установке программного обеспечения и настройке служб ключевые решения и действия включают:

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

Регистрация приложения Microsoft Entra

На этом этапе вы решили , как пройти проверку подлинности. Мы рекомендуем зарегистрировать приложение Microsoft Entra (учетная запись службы). Обычно это называется регистрацией приложения , должна использоваться для операций, которые будут выполняться автоматически.

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

Контрольный список . При регистрации приложения Microsoft Entra ключевые решения и действия включают:

• Проверьте наличие текущей регистрации приложения: уточните в IT, имеется ли активная регистрация приложения для использования администраторских API. Если да, определите, следует ли использовать существующую или следует ли создать новую.
• Создать новую регистрацию приложения: Зарегистрируйте приложение, когда это необходимо. Рекомендуется использовать имя приложения, например PowerBI-AdminAPIs-EntraApp, которое четко описывает его назначение.
• создайте секрет для регистрации приложения: как только регистрация приложения существует, создайте для него секрет. Задайте дату окончания срока действия на основе частоты смены секрета.
• Безопасно сохраните значения: сохраните секрет, идентификатор приложения (идентификатор клиента) и идентификатор арендатора, так как они понадобятся для аутентификации с учетной записью службы. Используйте безопасное расположение, например хранилище паролей организации. (Если вам нужно запросить создание регистрации приложения от ИТ-отдела, укажите, что вам нужно вернуть эти значения.)
• создание группы безопасности. Создание (или запрос) группы безопасности, которая будет использоваться для Power BI. Рекомендуется использовать имя группы, например субъекты-службы администратора Power BI, что означает, что группа будет использоваться для доступа к метаданным на уровне клиента.
• Добавление субъекта-службы в качестве члена группы безопасности. Используйте идентификатор приложения (идентификатор клиента), чтобы добавить новый (или существующий) субъект-службу в качестве члена новой группы безопасности.
• Обновите параметр клиента API администрирования в Fabric. На портале администрирования Fabric добавьте группу безопасности в параметр клиента "Разрешить субъектам-службам использовать API администратора Power BI только для чтения".
• Пропустите назначение разрешений в Azure: Не назначайте никаких разрешений для регистрации приложения (оно получит доступ к данным аудита уровня клиента Power BI с помощью Разрешить служебным учётным записям использовать API администратора Power BI только для чтения и параметра клиента).
• Определите, должен ли регистрация приложения получить доступ к подробным метаданным.Определите, нужно ли извлекать подробные сведения о таблицах, столбцах и выражениях мер при создании инвентаризации арендаторов.
• Обновление подробных настроек клиента метаданных в Power BI. При необходимости в портале администрирования Fabric добавьте группу безопасности в настройку клиента Улучшенные ответы API администратора с подробными метаданными, а также в настройку клиента Улучшенные ответы API администратора с DAX и выражениями mashup.
• Протестируйте учетную запись службы. Создайте простой скрипт для входа с помощью учетной записи службы и проверьте, что он может получить данные из административного API.
• Создание процесса для управления секретами регистрации приложений: создание документации и процесс регулярного смены секретов. Определите способ безопасного обмена данными с новым секретом для всех администраторов и разработчиков, которым он нужен.

Настройка параметров клиента Fabric

На портале администрирования Fabric есть несколько параметров клиента, которые относятся к извлечению данных аудита на уровне клиента.

API администрирования

Существует три параметра клиента, которые относятся к запуску API администрирования.

Внимание

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

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

Примечание.

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

Настройка клиента «Улучшение ответов API администратора с подробной метаданной» позволяет определить, какие пользователи и субъекты служб могут получать подробные метаданные. Метаданные извлекаются с помощью API-интерфейсов сканирования метаданных и включают таблицы, столбцы и многое другое. Этот параметр также позволяет Microsoft Purview получать доступ к сведениям на уровне схемы о семантических моделях Power BI, чтобы он смог сохранить его в каталоге данных.

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

Примечание.

Параметр арендатора Разрешить служебным учётным записям использовать администраторские API Power BI только для чтения предназначен специально для доступа к администраторским API. Его имя очень похоже на параметр клиента, предназначенный для доступа к api-интерфейсам пользователя (описано далее). Дополнительные сведения о различиях между API администрирования и API пользователей см. в разделе «Выбор API пользователя или API администрирования» ранее в этой статье.

API-интерфейсы пользователей

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

Параметр клиента «Разрешить служебным принципам использовать API Power BI» позволяет определить, какие служебные принципы имеют доступ к запуску REST API (за исключением административных API, предоставляемых другим параметром клиента, упомянутым выше).

Существуют другие параметры клиента, связанные с API, которые позволяют получить доступ к внедренным API, API потоковой передачи, экспорту API и API выполнения запросов . Однако эти API-интерфейсы недоступны для этой статьи.

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

контрольный список. При настройке параметров клиента Fabric ключевые решения и действия включают:

• Убедитесь, что каждая учетная запись службы находится в правильной группе: Подтвердите, что группа учетных записей службы администратора Power BI включает правильные учетные записи службы.
• Обновление параметра клиента API администрирования в Power BI. Добавьте группу безопасности в Разрешить служебным участникам использовать только для чтения API администрирования Power BI в настройке клиента, что позволяет использовать API администрирования для получения метаданных на уровне клиента.
• Обновите параметры арендатора для подробных метаданных в Power BI: При необходимости добавьте группу безопасности в параметры арендатора Улучшение ответов API администратора с подробной метаданной и Улучшение ответов API администратора с помощью выражений DAX и mashup.
• убедитесь, какие API-интерфейсы пользователей будут доступны: проверьте, потребуется ли один или несколько API-интерфейсов пользователей (кроме использования API администрирования).
• Обновите параметр арендатора API пользователя в Power BI: добавьте группу безопасности в параметр «Разрешить использованием Power BI API доверенными субъектами», который предназначен для пользовательских API.

Этап 3. Разработка решений и аналитика

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

Извлечение и хранение необработанных данных

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

Как и в случае с данными, возвращаемыми большинством API Майкрософт, аудит данных форматируется как JSON. Форматированные в формате JSON данные являются самоописыванием, так как это удобочитаемый человеком текст, содержащий структуру и данные.

JSON представляет объекты данных, состоящие из пар атрибутов и массивов. Например, "state": "Active" это пример, в котором значение атрибута состояния — "Активный". Массив JSON содержит упорядоченный список элементов, разделенных запятой, и которые заключены в скобки ([ ]). Обычно в результатах JSON можно найти вложенные массивы. Как только вы ознакомитесь с иерархической структурой результата JSON, легко понять структуру данных, например список (массив) семантических моделей в рабочей области.

Ниже приведены некоторые рекомендации по извлечению и хранению необработанных данных, полученных из API.

• Какое соглашение об именовании будет использоваться? Для файловой системы соглашение об именовании необходимо для файлов, папок либо зон Data Lake. Для базы данных требуется соглашение об именовании для таблиц и столбцов.
• Какой формат будет использоваться для хранения необработанных данных? Поскольку Power BI продолжает вводить новые функции, новые действия будут отображаться, которые сейчас не существуют. По этой причине рекомендуется извлечь и сохранить исходные результаты JSON. Не анализируйте, фильтруйте или отформатируйте данные во время извлечения. Таким образом, можно использовать исходные необработанные данные для повторного создания проверенных данных аудита.
• Какое расположение хранилища будет использоваться? Озеро данных или BLOB-хранилище обычно используется для хранения необработанных данных. Дополнительные сведения см. в разделе "Определение места хранения данных аудита" ранее в этой статье.
• Сколько истории вы сохраните? Экспортируйте данные аудита в расположение, в котором можно хранить историю. Планируйте накапливать по крайней мере два года истории. Таким образом можно проанализировать тенденции и изменения за пределами 28-дневного периода хранения по умолчанию. Вы можете сохранить данные на неопределенный срок или выбрать более короткий период в зависимости от политик хранения данных для вашей организации.
• Как вы будете отслеживать время последнего запуска процесса? Настройте файл конфигурации или эквивалент, чтобы записать метки времени при запуске и завершении процесса. При следующем запуске процесса он может получить эти метки времени. Особенно важно хранить метки времени при извлечении данных с помощью API-интерфейсов сканирования метаданных.
• Как вы планируете справляться с ограничением пропускной способности? Некоторые REST API Power BI и API Microsoft Graph реализуют ограничение частоты запросов. Вы получите ошибку 429 (слишком много запросов), если запрос API ограничен по частоте. Дросселирование может быть распространенной проблемой для крупных организаций, которым необходимо получить большой объем данных. Как вы избегаете неудачных попыток из-за ограничения скорости, зависит от технологии, которую вы используете для доступа и извлечения данных. Одним из вариантов является разработка логики в скриптах, которая отвечает на ошибку 429 "Слишком много запросов", повторив попытку после периода ожидания.
• Требуются ли данные аудита для соответствия требованиям? Многие организации используют необработанные записи журнала аудита для выполнения аудита соответствия требованиям или реагирования на расследования безопасности. В этих случаях настоятельно рекомендуется хранить необработанные данные в неизменяемом хранилище. Таким образом, после записи данных его нельзя изменить или удалить администратором или другим пользователем.
• Какие уровни хранилища необходимы для поддержки ваших требований? Лучшие места для хранения необработанных данных — это озеро данных (например, Azure Data Lake Storage 2-го поколения) или хранилище объектов (например, Хранилище BLOB-объектов Azure). Файловая система также может использоваться, если облачные службы не являются вариантом.

Контрольный список . При извлечении и хранении необработанных данных ключевые решения и действия включают:

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

Для получения дополнительной информации о том, как решение для аудита и мониторинга развивается со временем, см. раздел «Внедрение и совершенствование» далее в этой статье.

Создание отобранных данных

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

Совет

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

Контрольный список . При создании курированного слоя данных ключевые решения и действия включают:

• подтвердите требования и приоритеты. Если вы планируете использовать промежуточный серебряный слой для преобразованных данных, укажите требования и цели для того, что необходимо выполнить.
• Настройте процесс преобразования необработанных данных и их загрузки в упорядоченную зону данных: создайте процесс для преобразования и загрузки данных в "звездную схему" . Проверьте, работает ли процесс должным образом.
• Создание расписания для выполнения процессов: настройте повторяющееся расписание для заполнения курированного слоя данных.
• убедитесь, что безопасность настроена правильно. Убедитесь, что разрешения доступа настроены правильно для проверенных данных. Убедитесь, что разработчики модели данных могут получить доступ к курированным данным.

Создание модели данных

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

В контексте аудита и мониторинга модель данных получает данные из курированного (золотого) уровня данных. Если вы решили не создавать курируемый уровень данных, модель данных получает свои данные непосредственно из сырых данных.

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

Совет

Обзор схемы звездной см. в статье Понять звездную схему и её важность для Power BI.

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

Ниже приведены некоторые полезные таблицы измерений, которые можно включить в модель данных.

• дата: набор атрибутов даты для анализа и разделения данных по дням, неделям, месяцам, кварталам, годам и другим периодам времени.
• время. Если необходимо проанализировать по времени суток и у вас есть очень большой объем данных аудита, рассмотрите возможность хранения части времени отдельно от даты. Этот подход может помочь повысить производительность запросов.
• пользователи: атрибуты, описывающие пользователей (например, отдел и географический регион), которые могут использоваться для фильтрации множества объектов аудита данных. Цель состоит в том, чтобы удалить все сведения пользователя из таблиц фактов и сохранить их в этой таблице измерений, чтобы они могли фильтровать множество таблиц фактов. Вы также можете хранить учетные данные службы в этой таблице.
• мероприятия деятельности: атрибуты, которые группируют и описывают мероприятия деятельности (операции). Чтобы улучшить отчеты, можно создать словарь данных, описывающий каждое событие действия. Вы также можете создать иерархию, которая группирует и классифицирует аналогичные события действий. Например, можно сгруппировать все события создания элементов, удалить события и т. д.
• рабочие области: список рабочих областей арендатора и свойства рабочей области, такие как тип (личные или стандартные) и описание. Некоторые организации записывают дополнительные сведения о рабочих областях (возможно, с помощью списка SharePoint). Эти сведения можно интегрировать в эту таблицу измерений. Необходимо решить, хранит ли эта таблица измерений только текущее состояние рабочей области или хранит ли она данные версии, которые отражают значительные изменения рабочей области с течением времени. Например, если имя рабочей области изменяется, показывают ли в исторических отчетах текущее имя рабочей области или то, которое было актуально в то время? Дополнительные сведения о версионировании см. в «Медленно меняющиеся измерения».
• типы элементов: список типов элементов Power BI (семантические модели, отчеты и другие).
• емкости: перечень емкостей Premium в арендаторе.
• шлюзы: список шлюзов данных в клиенте.
• источники данных: список источников данных, используемых любой семантической моделью, потоком данных или datamart.

Ниже приведены некоторые полезные таблицы фактов (темы), которые можно включить в модель данных.

• действия пользователя: фактические данные, извлечённые из исходного файла JSON. Все атрибуты, не имеющие аналитического значения, удаляются. Все атрибуты, принадлежащие таблицам измерений (выше), также удаляются.
• Инвентаризация арендатора: моментальный снимок всех элементов, опубликованных в арендаторе. Дополнительные сведения см. в разделе Инвентаризация арендаторов ранее в этой статье.
• семантические модели: включает действия пользователя с использованием семантических моделей (например, изменения семантической модели) или связанных источников данных.
• Обновления семантической модели: хранит операции обновления данных, включая сведения о типе (запланированном или по запросу), длительности, состоянии и пользователе, инициировавшем операцию.
• роли рабочей области: текущее состояние назначений ролей в рабочей области.
• лицензии пользователей: моментальный снимок лицензий пользователей на определенный момент времени. Хотя вы можете заманчиво хранить лицензию пользователя в таблице измерений "Пользователи" , этот подход не будет поддерживать анализ изменений лицензий и тенденций с течением времени.
• членство в группах пользователей: снимок на определенный момент времени пользователей (и служебных субъектов), назначенных группе безопасности.
• мероприятия сообщества: включает в себя факты, связанные с сообществом, такие как учебные мероприятия. Например, можно проанализировать действия пользователей Power BI по сравнению с посещаемостью обучения. Эти данные могут помочь Центру превосходства определить потенциальных новых чемпионов.

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

Например, таблица измерений Users будет связана с каждой таблицей фактов. Он должен быть связан с таблицей фактов действий пользователей (кто выполнял действие), таблицей фактов инвентаризации клиента (кто создал опубликованный элемент) и всеми другими таблицами фактов. При фильтрации отчета пользователем в таблице измерений "Пользователи " визуальные элементы в этом отчете могут отображать факты для этого пользователя из любой связанной таблицы фактов.

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

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

Рассмотрите возможность настройки безопасности на уровне строк (RLS), чтобы другие пользователи ( за пределами Центра превосходства, аудиторов и администраторов) могли анализировать и сообщать о данных аудита. Например, можно использовать правила RLS, чтобы разрешить создателям контента и потребителям сообщать о своих действиях пользователей или усилиях по разработке.

Контрольный список . При создании модели данных ключевые решения и действия включают:

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

улучшать модели данных;

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

Создание классификаций

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

Вы можете классифицировать пользователей на основе их уровня использования или классифицировать содержимое на основе его уровня использования.

Классификация пользователей

Рассмотрим следующие классификации для использования пользователем.

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

Совет

Полезно знать, кто ваши случайные или неактивные пользователи, особенно если у них есть лицензии Pro или PPU (которые включают затраты). Кроме того, полезно знать, кто являются вашими частыми и наиболее активными пользователями. Попробуйте пригласить их присоединиться к офисным часам или принять участие в обучении. Ваши самые активные создатели контента могут быть кандидатами на присоединение к вашей сети чемпионов.

Классификация использования содержимого

Рассмотрим следующие классификации для использования содержимого.

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

Классификация типов пользователей

Рассмотрим следующие классификации для типа пользователя.

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

Рассмотрите недавние события и тенденции.

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

Рассмотрим некоторые примеры, демонстрирующие, как простая логика классификации может искажать реальность.

• Менеджер просматривал один отчет на этой неделе. Однако до этой недели менеджер не просматривал никаких отчетов за последние шесть месяцев. Не стоит считать этого менеджера частым пользователем только на основе недавнего использования.
• Создатель отчета публикует новый отчет каждую неделю. При анализе использования частыми пользователями, постоянная активность автора отчета оказывается положительной. Однако после дальнейшего исследования вы обнаружите, что этот пользователь повторно публикует новый отчет (с новым именем отчета) каждый раз, когда он редактирует отчет. Было бы полезно для создателя отчета иметь больше обучения.
• Руководитель время от времени просматривает отчет, поэтому его классификация использования часто изменяется. Может потребоваться проанализировать определенные типы пользователей, например руководителей, по-другому.
• Внутренний аудитор рассматривает критические отчеты один раз в год. Внутренний аудитор может быть неактивным пользователем из-за их редкого использования. Кто-то может предпринять шаги по удалению лицензии Pro или PPU. Или кто-то может поверить, что отчет должен быть снят с учета, так как он используется редко.

Совет

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

Контрольный список . При создании классификации данных об использовании ключевые решения и действия включают:

• Получить консенсус по определениям классификации: обсудить определения классификации с соответствующими заинтересованными лицами. Убедитесь, что при принятии решений есть соглашение.
• создание документации. Убедитесь, что определения классификации включены в документацию для создателей контента и потребителей.
• Создание цикла отзывов. Убедитесь, что пользователи могут задавать вопросы или предлагать изменения определений классификации.

Создание аналитических отчетов

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

Сосредоточьтесь на ключевых сведениях, наиболее важных для каждой аудитории. У вас может быть несколько аудиторий для отчетов аудита. Каждая аудитория будет заинтересована в разных сведениях и для разных целей. Аудитории, которые можно обслуживать с отчетами, включают:

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

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

• Самые просматриваемые материалы: С течением времени ваш исполнительный спонсор и руководящие команды могут быть особенно заинтересованы в сводной информации и тенденциях. Администраторы рабочей области, разработчики и создатели содержимого будут более заинтересованы в деталях.
• основные действия пользователей: Ваш Центр превосходства будет заинтересован в том, кто использует Power BI, как и когда. Администраторы премиум-емкости будут заинтересованы в том, кто использует емкость для обеспечения её работоспособности и стабильности.
• инвентарь арендатора. Администраторы Power BI, администраторы рабочих областей и аудиторы будут заинтересованы в понимании того, какое содержимое существует, где оно находится, его происхождение и параметры его безопасности.

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

Совет

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

Чтобы узнать, как создавать аналитические отчеты, пройдите учебный путь Design effective reports in Power BI.

Контрольный список . При планировании аналитических отчетов аудита ключевые решения и действия включают:

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

Действие на основе данных

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

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

Использование содержимого

Ниже приведены некоторые действия, которые можно предпринять в зависимости от того, как используется содержимое.

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

Действия пользователей

Ниже приведены некоторые действия, которые можно предпринять на основе действий пользователей.

• Первое действие публикации новым пользователем: Определите, когда тип пользователя изменяется с потребителя на создателя, что можно определить, когда пользователь впервые публикует контент. Это отличная возможность отправить им стандартную электронную почту, которая предоставляет рекомендации и ссылки на полезные ресурсы.
• Вовлечение с наиболее активными авторами контента: пригласите самых активных создателей присоединиться к сети чемпионов или к сообществу практики .
• Управление лицензиями: Проверьте, нужно ли неактивным создателям по-прежнему иметь лицензию Pro или PPU.
• активация пробной версии для пользователя. Активация пробной лицензии может заставить вас назначить пользователю постоянную лицензию до окончания пробного периода.

Возможности обучения пользователей

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

• большое количество семантических моделей, опубликованных тем же создателем содержимого: узнайте пользователей о общих семантических моделях и почему важно избежать создания повторяющихся семантических моделей.
• Чрезмерное предоставление общего доступа из личной рабочей области. Обратитесь к пользователю, который делает много общего доступа из своей личной рабочей области. Научите их стандартным рабочим областям.
• Значительные просмотры отчетов в личном рабочем пространстве: Обратитесь к пользователю, которому принадлежит контент с большим количеством просмотров отчетов. Узнайте, как стандартные рабочие области лучше, чем личные рабочие области.

Совет

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

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

Ниже приведены некоторые ситуации безопасности, которые могут потребоваться активно отслеживать.

• Слишком много пользователей, назначенных на роль администратора Fabric с высокими привилегиями.
• Слишком много администраторов в рабочей области (если роль "Участник", "Автор" или "Наблюдатель" будет достаточной).
• Чрезмерные разрешения на сборку, предоставленные семантическим моделям (если достаточно разрешений на чтение).
• Высокое использование разрешений на уровне объекта, когда разрешения приложения Power BI или роль Просмотрщика рабочей области было бы лучшим выбором для потребителей содержимого.
• Как содержимое предоставляется внешним пользователям.

Дополнительные сведения см. в статьях по планированию безопасности.

Управление и устранение рисков

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

• Большое количество представлений для отчетов (и базовых семантических моделей), которые не одобрены.
• Значительное использование неизвестных или неуправляемых источников данных.
• Расположения файлов, которые не соответствуют рекомендациям по управлению, где должны находиться исходные файлы.
• Имена рабочих областей не соответствуют требованиям к управлению.
• Метки конфиденциальности используются для защиты информации.
• Постоянные сбои обновления данных.
• Значительное и повторяющееся использование печати.
• Непредвиденное или чрезмерное использование подписок.
• Непредвиденное использование личных шлюзов.

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

Контрольный список . При планировании потенциальных действий на основе данных аудита ключевые решения и действия включают:

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

Этап 4. Обслуживание, улучшение и мониторинг

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

Реализация и улучшение

Процессы аудита обычно считаются выполняемыми в рабочей среде при завершении начальной разработки и тестирования, и вы автоматически выполнили этот процесс. Автоматизированные процессы аудита, выполняемые в рабочей среде, имеют больше ожиданий (чем ручные процессы) для качества, надежности, стабильности и поддержки.

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

• Защищённые: учетные данные надежно хранятся и управляются. Скрипты не содержат пароли или ключи в виде открытого текста.
• Планирования: существует надежная система планирования.
• управление изменениями. Использование методов управления изменениями и нескольких сред используется для обеспечения защиты рабочей среды. Вы также можете работать с средами разработки и тестирования или просто средой разработки.
• Поддержка: команда, отвечающая за поддержку решения, четко определена. Участники группы были обучены, и они понимают операционные ожидания. Идентифицированы резервные участники, а взаимное обучение происходит при необходимости.
• оповещения: когда что-то идёт не так, оповещения автоматически уведомляют команду поддержки. Предпочтительно оповещение включает как журналы, так и электронную почту (а не только электронную почту). Лог полезен для анализа записанных в нем ошибок и предупреждений.
• Журналирование. Процессы регистрируются для ведения истории обновлений данных аудита. Зарегистрированные сведения должны записывать время начала, время окончания и удостоверение пользователя или приложения, выполняющего процесс.
• обработка ошибок: скрипты и процессы корректно обрабатывают и регистрируют ошибки (например, следует ли немедленно выйти, продолжить или подождать и повторить попытку). Уведомления об оповещениях отправляются группе поддержки при возникновении ошибки.
• стандарты программирования: используются хорошие методы кодирования, которые обеспечивают высокую производительность. Например, циклы намеренно избегаются, за исключением случаев, когда это необходимо. Согласованные стандарты программирования, комментарии, форматирование и синтаксис используются таким образом, чтобы решение было проще поддерживать и поддерживать.
• Повторное использование и модульность. Чтобы свести к минимуму дублирование, код и значения конфигурации (например, строки подключения или адреса электронной почты для уведомлений) модульно структурированы так, чтобы их могли повторно использовать другие скрипты и процессы.

Совет

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

Контрольный список . При планировании эксплуатации и улучшении решения аудита ключевые решения и действия включают:

• Оценить уровень существующих решений. Определите, существуют ли возможности для улучшения и стабилизации существующих решений аудита, которые автоматизированы.
• установить стандарты уровня производства. Определите, какие стандарты требуется использовать для автоматизированных процессов аудита. Учтите улучшения, которые можно будет со временем реально внедрить.
• создание плана улучшения. Планирование улучшения качества и стабильности решений для аудита производства.
• Определите, требуется ли отдельная среда разработки: оцените уровень риска и зависимость от рабочих данных. Определите, когда следует создавать отдельные среды разработки и рабочей среды (и тестировать).
• Рассмотрим стратегию хранения данных. Определите, нужно ли реализовать процесс хранения данных, который очищает данные через определенный период времени или по запросу.

Документация и поддержка

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

Техническая документация

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

Техническая документация должна включать:

• Сводка компонентов архитектуры и предварительных условий.
• Кто владеет решением и управляет им.
• Кто поддерживает решение.
• Схема архитектуры.
• Решения по проектированию, включая цели, причины, по которым были сделаны определенные технические варианты, и ограничения (например, затраты или навыки).
• Решения и варианты безопасности.
• Используемые соглашения об именовании.
• Кодирование и технические стандарты и рекомендации.
• Требования к управлению изменениями.
• Инструкции по развертыванию, настройке и установке.
• Известные области технического долга (области, которые могут быть улучшены, если есть возможность сделать это).

Документация по поддержке

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

Документация по поддержке иногда называется база знаний или runbook. Эта документация ориентирована на службу технической поддержки или службу поддержки, и она должна включать:

• Рекомендации по устранению неполадок, когда что-то пойдет не так. Например, при сбое обновления данных.
• Действия, которые необходимо предпринять на постоянной основе. Например, может быть несколько ручных действий, которые кто-то должен выполнять регулярно, пока проблема не будет устранена.

Документация по создателю содержимого

Вы извлекаете больше ценности из вашего решения для аудита, предоставляя аналитику использования и внедрения другим командам в организации (с применением обязательной безопасности на уровне строк при необходимости).

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

Контрольный список . При планировании документации и поддержке решения аудита ключевые решения и действия включают:

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

Включение оповещений

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

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

Текущее управление

Необходимо выполнить текущее управление всем решением аудита. Возможно, вам потребуется расширить или изменить решение аудита, если:

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

Внимание

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

Контрольный список . При планировании текущего управления решением аудита ключевые решения и действия включают:

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

Связанный контент

В следующей статье этой серии вы узнаете о мониторинге на уровне клиента.