Планирование реализации 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 в БИЗНЕС-аналитике). Сведения о том, почему данные аудита настолько ценны, см. в обзоре аудита и мониторинга.

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

Совет

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

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

Дополнительные сведения об использовании 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 for Cloud Apps
Microsoft Sentinel

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

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

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

Документация по API с пробной версией

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

Для этого можно использовать следующее:

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

Примечание.

Для использования try-it необходимо быть лицензированным и прошедшим проверку подлинности пользователем Power BI. Он следует стандартной модели разрешений, что означает, что API-интерфейсы пользователей полагаются на разрешения пользователей, а API администраторов требуют разрешений администратора Power BI. Вы не можете пройти проверку подлинности с помощью 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 предоставляет до 30 дней данных, создание всего решения аудита включает в себя накопление набора файлов с течением времени, в течение всего хранения всех исторических событий. Накопление исторических файлов проще для выполнения с другими инструментами.
• Безопасная обработка учетных данных и ключей. Многие решения, которые вы найдете в Интернете от блоггеров сообщества, не защищены, так как они жестко кодируют учетные данные и ключи в виде открытого текста в запросах 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 для облака

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

Интерфейс журнала аудита в Defender для облака 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 Entra, построенной на стандартных отраслевых протоколах.

Совет

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

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

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

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

• Маркеры пользователей: выданы от имени пользователя с известным удостоверением.
• Маркеры только для приложений: выданы от имени приложения Microsoft Entra (субъект-служба).

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

Примечание.

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

Совет

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

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

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

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

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

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

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

Внимание

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

Аутентификация субъекта-службы

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

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

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

Совет

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

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

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

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

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

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

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

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

Соглашение об именовании может быть более конкретным, если у вас несколько клиентов или несколько сред (например, разработка и производство).

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

Совет

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

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

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

Внимание

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

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

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

Совет

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

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

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

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

• Используйте последнюю версию модуля управления Power BI при проверке подлинности с помощью командлета PowerShell Подключение-PowerBIServiceAccount. Он переключился с 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 с суффиксом As Администратор является API администратора; все остальные API являются ПОЛЬЗОВАТЕЛЬСКИми API.

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

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

Примечание.

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

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

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

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

Модуль управления	Командлет	Целевые назначения
Профиль	Подключение-PowerBIServiceAccount	Проверка подлинности пользователя Или субъекта-службы Power BI.
Администрирование	Get-PowerBIActivityEvent	Просмотр или извлечение событий журнала действий Power BI для клиента.
Рабочие области	Get-PowerBIWorkspace	Скомпилируйте список рабочих областей.
Отчеты	Get-PowerBIReport	Скомпилируйте список отчетов для рабочей области или клиента.
Data	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 шлюза) требуется, чтобы у пользователя были права администратора шлюза.

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

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

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

Командлет	Целевые назначения
Подключение-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. Настоятельно рекомендуется использовать этот метод.	После проверки подлинности с помощью командлета Подключение-PowerBIServiceAccount используйте командлет Invoke-PowerBIRestMethod для получения данных из предпочтительного API (например, получение пользователей конвейера как Администратор).
Используйте командлеты PowerShell как можно больше для проверки подлинности и получения данных.	С помощью этого метода PowerShell широко используется. PowerShell используется для координации выполнения скрипта, а модули PowerShell используются всякий раз, когда это возможно для доступа к данным. Это создает большую зависимость от PowerShell из нескольких аспектов.	После проверки подлинности с помощью командлета Подключение-PowerBIServiceAccount используйте командлет (например, Get-PowerBIActivityEvent), чтобы получить данные.
Используйте PowerShell только для координации выполнения процесса. Модули PowerShell используются как можно меньше.	В этом методе меньше зависимостей от PowerShell в качестве инструмента, так как его основное использование — оркестрация вызовов API. Для доступа к API используется только один универсальный модуль PowerShell (ни один из модулей управления Power BI не используется).	После проверки подлинности с помощью библиотеки проверки подлинности Майкрософт (MSAL) вызовите предпочитаемый API (например, получение пользователей конвейера как Администратор) с помощью универсального командлета Invoke-RestMethod для получения данных.

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

Совет

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

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

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

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

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

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

Рекомендации по использованию командлетов PowerShell

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

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

• Проверка подлинности. Самый простой способ проверки подлинности в скрипте PowerShell — использовать Connect-PowerBIServiceAccount командлет.
• Простота. Проще приступить к работе, так как методы извлечения данных аудита просты. Учитывайте, что при использовании командлета Get-PowerBIActivityEvent вы получите один день данных аудита. Однако при непосредственном вызове REST API получения событий действий извлекается один час данных аудита. Таким образом, при использовании REST API для получения одного дня данных аудита необходимо использовать цикл для вызова API 24 раз, чтобы извлечь каждый час дня.
• Разбивка на страницы больших результирующих наборов: большие результирующие наборы эффективно извлекаются по разбивке на страницы. Разбиение на страницы включает получение одного блока результатов за раз. Командлеты автоматически управляют разбиением на страницы. Однако при непосредственном использовании REST API скрипт должен проверка маркер продолжения, чтобы определить, есть ли какие-либо дополнительные результаты. Скрипт должен продолжать получать фрагменты результатов до тех пор, пока маркер продолжения не будет получен. Пример использования маркера продолжения см. в разделе 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-PowerBIDataset .
• Меньше зависимостей языка или инструментов: если вы используете ИНТЕРФЕЙСы REST API напрямую (вместо командлета), вам не нужно использовать PowerShell. Кроме того, вы можете использовать PowerShell только для оркестрации вызовов многих API в скрипте. Удаляя (или избегая) любой зависимости от PowerShell, в будущем можно перезаписать логику на другом языке. Если ит-отдел или команда разработчиков имеют сильные предпочтения для инструментов и языков, меньше зависимостей может быть важно учитывать.

Независимо от того, какой метод вы решили использовать, ИНТЕРФЕЙСы 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 могут стать сложными и дорогостоящими, особенно по мере роста томов данных.

Совет

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

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

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

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

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

• Это ручной или автоматизированный процесс аудита? Процесс автоматического аудита обычно имеет более строгие требования к тому, как и где хранятся данные.
• Особенно учитывается ли область темы? В зависимости от типа данных и их конфиденциальности ваша организация может иметь требование о том, как и где он хранится. Данные аудита 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	90
Вручную (пользовательский интерфейс)	Defender for Cloud Apps	30
Программный	Журнал действий Power BI (командлет API или PowerShell)	30
Программный	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 for Cloud Apps

Портал в Defender для облака Apps — это удобное место для просмотра действий и оповещений без необходимости создания скрипта для извлечения и скачивания данных. Он также позволяет просматривать данные из журнала действий 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 событий получения действий с помощью выбранного средства.
• Используйте командлет Get-PowerBIActivityEvent PowerShell. Он доступен в модуле управления Power BI Администратор.

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

Совет

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

Данные журнала действий Power BI доступны всем администраторам Power BI, администраторам 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. Это командлет Exchange Online PowerShell. Вы можете получить не более 90 дней журнала.

Внимание

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

Как правило, приступая к работе с API действий управления Office 365, сложнее, чем использование журнала действий Power BI (описано ранее). Это связано с тем, что API возвращает большие двоичные объекты содержимого, а каждый большой двоичный объект содержимого содержит отдельные записи аудита. Для крупных организаций в день может быть тысячи BLOB-объектов содержимого. Так как клиенты и сторонние приложения часто используют этот 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 Обозреватель (Kusto).
• Веб-интерфейс запросов в Обозреватель данных Azure.
• Любое средство запроса, которое может отправлять запросы 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 или данным аудита для нескольких служб.
• Обратитесь к ИТ: узнайте, извлекает ли ИТ-специалисты журналы аудита и можно ли получить доступ к необработанным данным, чтобы вам не нужно создавать новое решение.
• Определите источник данных: определите лучший источник для доступа к данным о действиях пользователей.
• Полное доказательство концепции: план для выполнения небольшого технического подтверждения концепции (POC). Используйте его для проверки ваших решений о том, как будет создано окончательное решение.
• Отслеживание дополнительных потребностей в данных. Вы можете сопоставить данные журнала действий с другими источниками, чтобы повысить ценность данных. Следите за этими возможностями, чтобы они могли добавляться в область проекта.

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

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

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

Примечание.

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

Совет

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

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

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

Совет

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

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

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

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

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

Чтобы получить список рабочих областей, можно использовать один из нескольких ИНТЕРФЕЙСОВ REST API, таких как API получения групп как Администратор API (с помощью выбранного средства). Результаты включают дополнительные метаданные, такие как описание и хранение рабочей области в емкости Premium.

Примечание.

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

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

Вы также можете использовать командлет Get-PowerBIWorkspace PowerShell. Это из модуля рабочих областей управления 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-интерфейсы сканера могут получать детализированные сведения (например, таблицы, столбцы и выражения мер), предоставляя разрешение двумя параметрами клиента для подробных метаданных. И наоборот, самый низкий уровень детализации, доступный с Get Groups as Admin помощью REST API, а Get-PowerBIWorkspace командлет — по типу элемента (например, списку отчетов в рабочей области).

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

Примечание.

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

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

Совет

Дополнительные сведения о пользователях, субъектах-службах и группах см. в разделе "Интеграция с идентификатором Записи Майкрософт".

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

Для аудита на уровне клиента 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 Обозреватель — это средство разработчика, которое позволяет узнать об 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. Так как 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.

Начиная с Az версии 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. (Идентификатор Microsoft Entra теперь называется Идентификатором Microsoft Entra.)
• Модуль 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 ключевые решения и действия включают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Какое соглашение об именовании будет использоваться? Для файловой системы соглашение об именовании необходимо для файлов, папок и зон озера данных. Для базы данных требуется соглашение об именовании для таблиц и столбцов.
• Какой формат будет использоваться для хранения необработанных данных? Поскольку Power BI продолжает вводить новые функции, новые действия будут отображаться, которые сейчас не существуют. По этой причине рекомендуется извлечь и сохранить исходные результаты JSON. Не анализируйте, фильтруйте или отформатируйте данные во время извлечения. Таким образом, можно использовать исходные необработанные данные для повторного создания проверенных данных аудита.
• Какое расположение хранилища будет использоваться? Озеро данных или хранилище BLOB-объектов обычно используется для хранения необработанных данных. Дополнительные сведения см. в разделе "Определение места хранения данных аудита" ранее в этой статье.
• Сколько будет храниться история? Экспортируйте данные аудита в расположение, в котором можно хранить журнал. Планируйте накапливать по крайней мере два года истории. Таким образом можно проанализировать тенденции и изменения за пределами 30-дневного периода хранения по умолчанию. Вы можете сохранить данные на неопределенный срок или выбрать более короткий период в зависимости от политик хранения данных для вашей организации.
• Как вы будете отслеживать время последнего запуска процесса? Настройте файл конфигурации или эквивалент, чтобы записать метки времени при запуске и завершении процесса. При следующем запуске процесса он может получить эти метки времени. Особенно важно хранить метки времени при извлечении данных с помощью 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 возвращают правильные данные.

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

Рассмотрите возможность пересчета и тенденций.

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

Совет

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

Чтобы узнать, как создавать аналитические отчеты, ознакомьтесь с эффективными отчетами в схеме обучения Power BI .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

Эксплуатация и улучшение

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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