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

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

Сценарии

Power BI недавно представила больше средств управления с помощью GA Workspaces V2. Советуем использовать готовые к использованию функции, особенно роль участника, обсуждаемую здесь.

В нашем сценарии проблема заключается в том, что рабочие пространства V1 не имеют одинаковых возможностей управления, и любой пользователь Power BI Pro может создать группу Team или O365, и он автоматически станет администратором соответствующего рабочего пространства Power BI (V1), которое создается. Мы хотим отслеживать любые наборы данных, создаваемые в рабочих пространствах V1, и иметь возможность удалять их, хотя мы НЕ являемся администратором в этих рабочих пространствах. Это невозможно без вмешательства, которое будет описано ниже. Конечно, я хочу иметь возможность связаться с этими пользователями и обучить их использованию новых рабочих пространств V2.

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

Три простых шага

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

Три шага выглядят следующим образом:

• Необходимо зарегистрировать приложение в Azure Active Directory, чтобы можно было использовать API управления Office 365, API Graph и API Power BI. Вам потребуется глобальный администратор, предоставляющий набор разрешений для этого приложения перед шагами 2 и 3.
• В Microsoft Flow (или в Azure Logic Apps) импортируйте предоставленный «Поток», который содержит всю логику, необходимую для этого.
• Используйте Postman (или инструмент выбора REST API), чтобы вызвать API-интерфейс управления O365, чтобы установить поток, созданный на шаге 2, в качестве «webhook» для любых событий журнала аудита O365 (который, конечно, включает «PowerBI-CreateDataset»).

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

Давайте начнем!

Настройка Azure Active Directory (разрешения O365)

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

Перейдите на портал Azure, а из Azure Active Directory перейдите в раздел “App registrations” и нажмите “New registration”. Дайте ему уникальное имя, а URL перенаправления может быть просто localhost

После регистрации откройте его и запишите / скопируйте следующие свойства в диалоговом окне «Overview»:

Application (client) ID

Directory (tenant) ID

Вам понадобятся оба этих GUID позже.

Перейдите в диалог «certificates & secrets» и создайте «new client secret». Также запишите или скопируйте это значение. Позже в этом посте он будет называться App Secret”, и он нам понадобится.

В диалоговом окне «API permissions» необходимо добавить разрешения для 3 служб:  Office 365 Management API, Graph API, Power BI Service. Они должны быть перечислены как группы, из которых вы можете выбрать определенные разрешения. На приведенном ниже снимке экрана показаны разрешения для каждой группы, в которой вы нуждаетесь. Обратите внимание на индикатор “Type”: Application или Delegated.

До этого момента вы могли бы быть удивлены тем, что смогли сделать все это без глобального администратора. Что ж, ничего из этого не будет работать, если вы не выполнили очень важную задачу, нажав кнопку  “Grant Consent” в нижней части этой диалоговой страницы. Этого не будет существовать, или будет недоступно, если вы не администратор.

Примечание. Вернитесь в диалоговое окно обзора этого приложения и просто обратите внимание на кнопку “Endpoints” в верхней части. Это разные конечные точки авторизации API для разных сервисов. Здесь предоставлено то, что вам нужно в исходном коде для Flow и Postman, но хорошо было бы знать, как вернуться, чтобы проверить это позже, если что-то не работает для вас.

Вернитесь в Azure Active Directory и в левой навигационной панели перейдите к “Users”.

Нам нужно найти администратора Power BI, для которого мы не против записать значение пароля для использования в нашем приложении Flow. Часто это будет какая-то служебная учетная запись, которая будет использоваться ТОЛЬКО для целей API и имеет различные ограничения на ротацию паролей и т. Д. Это должно иметь привилегии «Power BI Admin».

В нашем примере мы будем использовать ту же учетную запись, что и учетная запись службы администратора Power BI и уведомление по электронной почте Power BI Admin, но в реальной жизни вам это не нужно. Получите «Object ID» из диалогового окна « Profile» и запишите / скопируйте его для дальнейшего использования.

Вот и все. Первый шаг выполнен.

Импортируйте пакет в Microsoft Flow и настройте его.

В репозитории исходного кода на GitHub предоставлены как Zip-файл, так и JSON-файл, который можно использовать. Файл JSON протестирован не полностью, так как он должен позволять вам импортировать напрямую в приложения логики. Microsoft Flow, в конце концов, построен на основе логических приложений, поэтому, если вы предпочитаете этот путь, можете выбрать его. В этом сообщении мы будем использовать zip-файл (он же пакет).

Два соединения, которые используемые в этом потоке, о которых вы должны знать: «Office 365» и “Flow Approvals”.

Когда вы импортируете пакет, вам нужно будет использовать существующие соединения для них или создать их в разделе «Data».

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

Ссылка «select during import» для связанных ресурсов - это место, где вы можете определить новые соединители, если у вас их еще нет в разделе «Data» вашего приложения Flow.

После импорта наведите курсор мыши на элемент Flow, и вы увидите значок  “Edit”, щелкните по нему.

Ниже приведен снимок экрана даже не всего потока, только около 90% его, потому что он был слишком большим, чтобы уменьшить масштаб. Вы можете видеть, что он довольно сложен.

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

1. Поток запускается через веб-перехватчик O365 (который мы настроим позже). Каждый раз, когда в O365 создается событие аудита (которое включает в себя события Power BI), этот поток запускается.
2. Переменные должны быть установлены (некоторые вещи, которые вы записали ранее, должны быть заполнены здесь…мы объясним ниже). Эти переменные управляют связью с API, которые нам нужны, чтобы все использовали настройку прав доступа на шаге 1.
3. Вызовите API Get Log Event из API управления O365 и передайте ему токен авторизации и contentUri из события триггера (это фактически ссылка для поиска того, что произошло).
4. При синтаксическом анализе ответа события журнала будет возвращено несколько записей. Он вводится для каждого цикла, и если «Operation equals CreateDataset», мы проводим дальнейшую проверку события, в противном случае мы ничего не делаем. Обратите внимание, что вы можете изменить это, чтобы искать любые события, перечисленные здесь. Событие «CreateGateway» приходит на ум как хорошее для уведомления администратора BI. 
5. Для нашего сценария, если мы найдем событие CreateDataset, мы хотим проверить, является ли созданная группа рабочим пространством V1 или V2. Это делается в два этапа.
1. Вызовите Graph API, чтобы получить (“GET”) группу (в Power BI мы называем их рабочими пространствами, но в O365/Graph они являются группами).
2. Если рабочая область, в которой был создан набор данных, является рабочей областью V2, нам все равно, поскольку у нас там уже есть элементы управления, такие как роль Contributor и параметр администратора, позволяющий ограничивать создание рабочих областей пользователями. Рабочие пространства V2 не отображаются в O365/Graph, поэтому, если мы не получим код состояния 200 (что означает, что вызов был успешным), то можно предположить, что это рабочее пространство V2, и, следовательно, мы можем остановить обработку. Примечание. В конце тестирования мы также обнаружили, что наборы данных, созданные в  “My Workspace”, также будут выдавать код состояния, отличный от 200, поэтому мы не проверяем и наборы данных.
6. Если это рабочее пространство V1, мы будем использовать API-интерфейс Graph для добавления нашей учетной записи службы администратора Power BI в это рабочее пространство. Мы должны сделать это, потому что если мы решим отклонить этот набор данных от имени администратора, API Power BI НЕ удастся удалить набор данных, если пользователь не является администратором этого рабочего пространства. Добавление этой учетной записи также дает администратору Power BI возможность войти в систему с этой учетной записью службы и выполнить проверку вручную перед тем, как одобрить / отклонить.
7. Теперь мы проверяем код состояния 204, который указывает, что мы успешно добавили/создали назначение пользователя. Если это не удается, это может означать, что наша учетная запись службы администратора Power BI уже была администратором этого рабочего пространства (может быть редко, но может случиться). Если это произойдет, то появится ошибка 400. Мы не будем проводить дальнейшую проверку на ошибку 400, поэтому учтите, что что-то еще может вызвать это и испортить ваш поток. Если выброшено 400, можно установить переменную через элемент «Compose», чтобы указать, что пользователь уже является членом / администратором группы. Используем это позже. Если у нас не было 204, и мы не получили 400, скорее всего произошла какая-то другая ошибка, и мы отправляем электронное письмо администратору Power BI о том, что поток имеет сбои.
8. Теперь мы отправляем вежливое предупреждение по электронной почте пользователю, который создал неавторизованный набор данных в рабочей области V1, и сообщаем ему, что он будет рассмотрен администратором.
9. Мы начинаем процесс утверждения, который отправляет электронное письмо на адрес электронной почты администратора Power BI, который был задан в разделе «Variables» на шаге № 2, со всей важной информацией о наборе данных. Примечание. По какой-то причине ReportName и ReportId не работают, поэтому ссылка на элемент не работает. Нужно исправить это.
10. Если администратор нажимает кнопку «Approve» в сообщении электронной почты, пользователю, создавшему набор данных, отправляется письмо с подтверждением, в противном случае переходите к шагу # 11.
11. Теперь нам нужно вызвать API Power BI для автоматического удаления набора данных. Мы отправляем пользователю электронное письмо с отказом, чтобы он знал, что оно было удалено. Примечание. Маловероятно, что в рабочих пространствах V1 разрешено использование принципалов пользователя для авторизации, поэтому на шаге 2 нам пришлось установить идентификатор и пароль учетной записи службы Power BI Admin. Лучше было бы вообще не иметь идентификатора пользователя и просто использовать разрешения приложения.
12. Проверьте переменную, которую мы установили в Шаге 7, чтобы увидеть, нужно ли удалять учетную запись службы power bi admin из группы, и если это так, мы используем Graph API для этого, чтобы не было остаточного эффекта для этого O365 / Team из Процесс проверки администратором Power BI после его завершения.

В рабочем процессе единственным разделом, который требует настройки, является “Set Variables”  во втором действии. Нажмите на нее, чтобы разбить «Scope».

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

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

Client Key – (aka App Secret) Вы записали это в первом разделе. Часто они будут иметь специальные символы, поэтому нам нужно html кодировать его. Используйте https://www.url-encode-decode.com/ и закодируйте свой клиентский ключ, примите это значение и вставьте его сюда.

Client ID – вставьте в точности как скопировано (не должно содержать специальных символов).

Tenant ID –  вставьте в точности как скопировано.

Power BI Admin ID (для Graph) –  Object ID для учетной записи службы администратора в точности как скопировано.

Power BI Admin email-username (для Power BI API) – адрес электронной почты учетной записи службы администратора, описанной в первом разделе.

Power BI Admin Password (для Power BI API) –  это пароль учетной записи службы, описанной в первом разделе.

Power BI Admin Email (for Flow Approvals) – это адрес электронной почты РЕАЛЬНОГО ЧЕЛОВЕКА, который проверяет электронную почту в этой учетной записи. Кто-то, кто может принять решение утвердить / отклонить наборы данных. Это может быть список рассылки или группа безопасности? Возможно, попробуйте, узнаете.

После того, как вы обновили эти переменные, вы завершили настройку вашего Flow (или приложения логики). Последнее, что вам нужно сделать, - это перейти к первому действию в вашем потоке (триггере) и скопировать URL-адрес HTTP POST. Это «webhook», который вам нужен для шага № 3.

В верхней части страницы нажмите «Save».

 Шаг № 2 завершен.

Создайте Webhook

Это, безусловно, самый простой и короткий шаг из трех ... однако он может быть пугающим, если вы не знакомы с API-интерфейсами REST и такими инструментами, как Postman. Здесь знакомый с разработой может очень быстро выполнить эту задачу.

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

Следует отметить одну вещь, касающуюся событий Power BI: для появления события в журналах аудита может потребоваться до 30 минут после возникновения события. Сразу после этого срабатывает webhook, но когда вы приступите к тестированию, поймите, что пройдет довольно много 20-30 минут, прежде чем ваш Flow будет запущен.

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

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

В этой коллекции находится папка API управления O365, в которой есть «Auth», а затем API «Create Webhook», который необходимо выполнить, чтобы подключить ваш поток к URL-адресу, который мы записали в конце шага # 2.

Сначала запустите «Auth». Когда вы запустите его, вы заметите, что мы использовали переменные для URL и тела (x-www-form-urlencoded).

Создайте среду с этими переменными или просто замените эти значения на значения, записанные на шаге 1. Для redirectUri просто используйте http: //localhost или пользовательское значение, которое вы использовали при настройке регистрации вашего приложения на шаге # 1.

Отправьте запрос (должен быть POST) и скопируйте значение, возвращенное в «access_token». Это значение используется для авторизации последующих вызовов API управления O365. Он работает в течение одного часа и содержит информацию о разрешениях, которые есть у вашего приложения (те разрешения API, которые вы настроили на шаге 1).

Теперь откройте запрос «Create Webhook». На вкладке «Authorization» замените значение «Token» на только что записанный access_token. В поле «Body» замените переменную {{flowurl}} на URL-адрес триггера потока, который вы записали в конце шага # 2. Замените {{activityfeedauthid}} некоторым произвольным именем. Мы использовали «angrygovernance»

Если вы добились успеха, ваш webhook должен быть создан, и вы готовы к тестированию.

Шаг № 3 завершен!

Тестирование

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

Вы увидите другие «успешные» прогоны вашего потока, которые не важны. Это другие события, происходящие в O365, такие как сохранение вашего потока… У нас есть условие, которое ищет только события «PowerBI-CreateDataset», прежде чем мы начнем процесс утверждения.

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

Заключение

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

No Comments