Вопросы и ответы по API действий управления Office 365, а также устранение неполадок, связанных с ним

API действий управления Office 365 (другое название — API единого аудита), входящий в состав предложений для обеспечения безопасности и соответствия требованиям в Office 365:

• предоставляет программный доступ к нескольким рабочим нагрузкам конвейера аудита (например, SharePoint и Exchange);

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

API действий управления не следует путать с API связи со службой Office 365. API действий управления используется для аудита действий пользователей в различных рабочих нагрузках. API связи со службой предназначен для аудита состояния и сообщений, отправляемых службами, которые доступны в Office 365 (например, Dynamics CRM или службой идентификации).

API действий управления Office 365: вопросы и ответы

Как подключиться к API действий управления?

Сведения о том, как начать работу с API действий управления Office 365, см. в статье Начало работы с API управления Office 365.

Что произойдет, если я отключу аудит для своей организации Office 365? Буду ли я по-прежнему получать события через API действий управления?

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

В случае каких событий проводится аудит для определенной службы Office 365?

В документации по схеме API действий управления Office 365 приведен полный список событий. Дополнительные сведения см. в статье "Схема API действий управления Office 365". Кроме того, в статьеПоиск по журналу аудита в Центре безопасности и соответствия требованиям в разделе "Подлежащие аудиту действия" приводится список событий для большинства служб Office 365, которые подлежат аудиту.

Существуют ли какие-либо различия в записях, извлекаемых API действий управления, по сравнению с записями, возвращаемыми с помощью средства поиска в журнале аудита на портале соответствия требованиям Microsoft Purview?

В обоих случаях возвращаются одни и те же данные. Единственное отличие заключается в том, что с помощью API можно получить данные только за последние 7 дней (дополнительные сведения см. в вопросах ниже). При поиске в журнале аудита в Центре безопасности и соответствия требованиям (или при использовании соответствующего командлета Search-UnifiedAuditLog в Exchange Online PowerShell) вы можете получить данные за период хранения, действующий в момент создания данных (например, 90 дней или год).

Каков максимальный период ожидания отправки уведомления о том или ином событии Office 365?

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

Через какое время события отобразятся в службе Office 365?

Служба аудита Office 365 не гарантирует точное время доставки событий. Аудит старается предоставить данные как можно быстрее. Однако некоторые проблемы могут возникнуть (например, сбои в работе сервера) выше по течению от службы аудита и неизбежны. Поскольку события аудита часто используются для криминалистических расследований, Майкрософт отдает приоритет полноте данных, а не задержке. Для основных служб (таких как Exchange, SharePoint, OneDrive и Teams) сроки доставки событий обычно составляют 60–90 минут. Для других служб сроки доставки событий могут быть дольше. Хотя это типичные сроки доставки событий, мы понимаем, что могут возникать аномалии. По этим причинам корпорация Майкрософт не устанавливает конкретных сроков доставки.

Разве использование уведомлений веб-перехватчиков не предполагает более быстрое получение результатов?

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

Как долго контент будет оставаться доступным для получения через API?

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

Можно ли запросить у API действий управления определенный ИД события, RecordType или другие свойства большого двоичного объекта контента?

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

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

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

Каково ограничение на регулирование для API действий управления?

Для всех организаций изначально выделяется базовый уровень 2 000 запросов в минуту. Затем ограничение регулирования изменяется в зависимости от сочетания факторов, в том числе от количества мест в организации. Кроме того, организации Office 365 E5 и Microsoft 365 E5 получат примерно вдвое большую пропускную способность, чем организации без плана E5. Для защиты работоспособности службы также будет использоваться ограничение максимальной пропускной способности.

Примечание.

Хотя каждый клиент может изначально отправлять до 2 000 запросов в минуту, корпорация Майкрософт не может гарантировать скорость отклика. Она зависит от различных факторов, таких как производительность клиентской системы, а также мощность и скорость сети.

У меня возникла ошибка регулирования в API действий управления. Что делать?

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

Почему TargetUpdatedProperties больше не отображается в расширенных свойствах в журналах аудита для Microsoft Entra действий?

TargetUpdatedProperties отображались в объекте ExtendedProperties. Однако они были удалены из свойства ExtendedProperties и теперь отображаются в свойстве ModifiedProperties.

Почему журналы аудита с userAccountNotFound "LogonError" для Microsoft Entra действий входа не доступны через API действий управления?

Начиная с ноября 2020 г. журналы аудита для Microsoft Entra действий входа в систему попадают в единый журнал аудита из центров событий Microsoft Entra. В результате этого изменения заполнение свойства LogonError значением UserAccountNotFound невозможно. Начиная с первой недели февраля 2021 г. свойство ErrorCode в схеме аудита Microsoft Entra входа теперь соответствует кодам ошибок AADSTS. Кроме того, параметр UserId не будет заполнен именем пользователя из попытки входа для ошибок UserAccountNotFound, так как это имя пользователя не существует в каталоге Microsoft Entra организации.

Устранение неполадок, связанных с API действий управления Office 365

Каждому, кто начинает работать с API действий управления Office 365, следует понимать, что в этом интерфейсе отсутствует возможность запрашивать события по конкретным характеристикам, например дате события, семейству веб-сайтов, в котором оно произошло, или типу события. Вместо этого вы создаете подписки на определенные рабочие нагрузки (например, SharePoint или Microsoft Entra ID), и каждая подписка зависит от клиента.

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

• Вопросы о сторонних средствах и клиентах

• Включение единого ведения журнала аудита в Office 365

• Подключение к API

• Проверка подписок

• Создание подписки

• Проверка доступности содержимого

• Использование веб-перехватчиков

• Запрос больших двоичных объектов и регулирование содержимого

• Теги служб

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

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

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

Включение единого ведения журнала аудита в Office 365

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

Примечание.

Изменение конфигурации единого журнала аудита может занять до 60 минут.

Если единый аудит не включен, обычно появляется сообщение об ошибке, содержащее следующую строку: Microsoft.Office.Compliance.Audit``.DataServiceException: Tenant <tenantID> does not exist.

Подключение к API

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

Разрешения приложений Azure

В настоящее время для API действий управления Office 365 используются следующие три разрешения:

1. чтение данных о действиях в организации;

2. чтение сведений о работоспособности служб в организации;

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

Примечание.

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

Получение токена доступа

В приведенном ниже скрипте PowerShell используются идентификатор приложения и секрет клиента, чтобы получить токен OAuth2 из конечной точки проверки подлинности для API действий управления. Затем маркер доступа помещается в переменную массива $headerParams, которую вы вложите в свой HTTP-запрос. В качестве значения конечной точки API (в переменной $resource) используйте одно из указанных ниже значений в зависимости от плана подписки на Microsoft 365 или Office 365:

• План для предприятий: manage.office.com

• План для государственных организаций (GCC): manage-gcc.office.com

• План для государственных организаций (GCC High): manage.office365.us

• План для государственных организаций (DoD): manage.protection.apps.mil

# Create app of type Web app / API in Azure AD, generate a Client Secret, and update the client id and client secret here
$ClientID = "<YOUR_APPLICATION_ID"
$ClientSecret = "<YOUR_CLIENT_SECRET>"
$loginURL = "https://login.microsoftonline.com/"
$tenantdomain = "<YOUR_DOMAIN>.onmicrosoft.com"
# Get the tenant GUID from Properties | Directory ID under the Azure Active Directory section. For $resource, use one of these endpoint values based on your subscription plan: Enterprise - manage.office.com; GCC - manage-gcc.office.com; GCC High: manage.office365.us; DoD: manage.protection.apps.mil
$TenantGUID = "<YOUR_TENANT_GUID>"
$resource = "https://<YOUR_API_ENDPOINT>"
# auth
$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body
$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"} 

Переменная $oauth будет содержать объект отклика, у которого есть ряд свойств, в том числе маркер доступа. Вот пример такого отклика:

token_type     : Bearer
expires_in     : 3599
ext_expires_in : 0
expires_on     : 1508285860
not_before     : 1508281960
resource       : https://manage.office.com
access_token   : eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjJLVmN1enFBaWRPTHFXU2FvbDd3Z0ZSR0NZbyIsImtpZCI6IjJLVmN1enFBaWRPTHFXU2FvbDd3Z0ZSR0NZbyJ9.eyJhdWQiOiJodHRwczov…

Проверка подписок

Если произойдет перебой потока данных в имеющиеся клиент или решение, использующие API действий управления, вы можете подумать, что с вашей подпиской что-то не так. Чтобы проверить активные подписки, добавьте к предыдущему скрипту следующий код:

Invoke-WebRequest -Headers $headerParams -Uri "$resource/api/v1.0/$tenantGUID/activity/feed/subscriptions/list" 

Пример отклика

StatusCode        : 200
Status Description : OK
Content           : [{"contentType":"Audit.Exchange","status":"enabled","webhook":null},{"contentType":"Audit.SharePoint","status":"enabled","webhook":{"authId":"","address":"https://mvcwebapiwebhookreceiver.azurewebsite...
RawContent        : HTTP/1.1 200 OK
                    Pragma: no-cache
                    Content-Length: 266
                    Cache-Control: no-cache
                    Content-Type: application/json; charset=utf-8
                    Expires: -1
                    Server: Microsoft-IIS/8.5,Microsoft-IIS/8.5
                    X-AspNet-Versi...
Forms             : {}
Headers           : {[Pragma, no-cache], [Content-Length, 266], [Cache-Control, no-cache], [Content-Type, application/json; charset=utf-8]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 266

Это означает, что для клиента включены подписки Audit.Exchange и Audit.SharePoint. Для подписки Exchange веб-перехватчик не включен (null), а для подписки SharePoint включен веб-перехватчик с адресом зарегистрированной конечной точки.

Создание подписки

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

• План для предприятий: manage.office.com

• План для государственных организаций (GCC): manage-gcc.office.com

• План для государственных организаций (GCC High): manage.office365.us

• План для государственных организаций (DoD): manage.protection.apps.mil

Invoke-WebRequest -Method Post -Headers $headerParams -Uri "https://<YOUR_API_ENDPOINT>/api/v1.0/$tenantGUID/activity/feed/subscriptions/start?contentType=Audit.AzureActiveDirectory"

Примечание.

Помните, что $headerParams он был заполнен в первой части скрипта, указанного в разделе Подключение к API этой статьи.

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

Проверка доступности содержимого

Чтобы проверить, какие большие двоичные объекты с контентом были созданы за определенный период, вы можете добавить следующую строку в скрипт из раздела "Подключение к API".

Invoke-WebRequest -Method GET -Headers $headerParams -Uri "$resource/api/v1.0/$tenantGUID/activity/feed/subscriptions/content?contentType=Audit.SharePoint"

В приведенном выше примере показано, как получить все уведомления о контенте, который стал доступен сегодня, то есть с 12:00 (в формате UTC) по текущее время. Если вы хотите указать другой временной период (учитывая, что максимальный период запроса составляет 24 часа), добавьте параметры starttime и endtime к URI. Пример:

Invoke-WebRequest -Method GET -Headers $headerParams -Uri "$resource/api/v1.0/$tenantGUID/activity/feed/subscriptions/content?contentType=Audit.SharePoint&startTime=2017-10-13T00:00&endTime=2017-10-13T11:59"

Примечание.

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

[{		"contentUri" : "https://<your_API_endpoint>/api/v1.0/<your_tenant_guid>/activity/feed/audit/20171014180051748005825$20171014180051748005825$audit_sharepoint$Audit_SharePoint",
		"contentId" : "20171014180051748005825$20171014180051748005825$audit_sharepoint$Audit_SharePoint",
		"contentType" : "Audit.SharePoint",
		"contentCreated" : "2017-10-13T18:00:51.748Z",
		"contentExpiration" : "2017-10-20T18:00:51.748Z",
}]

Важно!

• Свойство contentUri — это URI, из которого можно получить большой двоичный объект с контентом. Сам объект содержит сведения о 1–N событиях. Коллекция может содержать до 30 объектов JSON, но в этих 30 URI контента может быть указано намного больше событий.

• Свойство contentCreated — это не дата создания события, соответствующего уведомлению. Это дата создания уведомления. События, описываемые в большом двоичном объекте, могли быть созданы задолго до создания самого объекта. Следовательно, из API невозможно напрямую запрашивать события, произошедшие за тот или иной период.

Содержимое страницы для занятых клиентов

Во многих крупных клиентах Office 365 каждый час происходят тысячи событий. Если это верно для вашей организации, при попытке выполнить запрос для 24-часового периода, как в приведенном выше примере, может потребоваться получить больше уведомлений, чем можно вернуть в одном отклике. В этом случае вам потребуется реализовать некий логический цикл, каждый раз проверяя заголовки отклика на наличие значения заголовка NextPageUrl:. Дополнительные сведения см. в разделе "Разбивка на страницы" справочника по API действий управления Office 365.

IF the NextPageUrl header is present in the response... 

THEN issue a new request substituting the Uri parameter in the above Invoke-WebRequest example for the value of the NextPageUrl header...
 
ELSE exit the loop

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

Использование веб-перехватчиков

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

Прежде чем добавлять веб-перехватчик, учтите следующие две проблемы:

1. Корпорация Майкрософт отходит от использования веб-перехватчиков из-за сложности отладки и устранения неполадок. Как правило, размещается конечная точка WebApi, отвечающая на входящие запросы. Многие клиенты используют либо среды внешнего размещения (которые они не полностью контролируют), либо локальные среды (которые с трудом пропускают входящие HTTP-запросы). Сотрудники службы поддержки часто сталкиваются с проблемами, когда входящие запросы из конвейера аудита Office 365 блокируются брандмауэром или маршрутизатором. В этом случае API реализует алгоритм отхода, который может быть запутанным и приводить к отключению веб-перехватчика в подписке.

2. Веб-перехватчик должен быть готов сразу ответить на отклик о проверке после выполнения операции запуска. Если в приложении веб-перехватчика возникнет ошибка, то проверка завершится сбоем, а веб-перехватчик не будет включен. Сведения о схеме запросов на проверку см. в разделе "Проверка веб-перехватчиков" справочника по API действий управления Office 365. Вам следует серьезно отнестись к трудностям при создании готового к работе веб-перехватчика для ответа на уведомления API действий управления.

Если вы решите реализовать веб-перехватчик, его следует протестировать, чтобы убедиться, что конечная точка готова вернуть отклик HTTP 200 как на запрос проверки, так и на обычные запросы уведомлений перед операцией /start, указывающей, что конечная точка веб-перехватчика вызывается впервые. Как правило, для тестирования готовности используется макет запроса от API. Внимательно прочтите и соблюдайте инструкции из разделов Проверка веб-перехватчиков и Получение контента справочника по API действий управления Office 365, чтобы понять схему запросов этих двух типов.

Чтобы добавить подписку с конечной точкой веб-перехватчика, добавьте параметр body в запрос POST к конечной точке /start. Пример:

$body = '{
    "webhook" : {
        "address": "https://webhook.myapp.com/o365/",
        "authId": "o365activityapinotification",
        "expiration": ""
    }}'
$uri = "https://manage.office.com/api/v1.0/$tenantGUID/activity/feed//subscriptions/start?contentType=Audit.SharePoint"
Invoke-RestMethod -Method Post -uri $uri -Headers $headerParams -Body $body

Сразу после этого вызова будет отправлен запрос на проверку по адресу https://webhook.myapp.com/o365/ …, где должен находиться готовый к ответу прослушиватель, как описано в разделе Проверка веб-перехватчиков справочника по API действий управления Office 365. В ответ прослушиватель отправит отклик HTTP 200. Если вы немедленно выполните операцию /list на этом этапе, вы не увидите веб-перехватчик, отличный от null, пока проверка не будет успешно возвращена.

Проверка уведомлений в веб-перехватчиках

Важно понимать разницу между операциями /notifications и /content. Проверка уведомлений уместна только при наличии подписки на конечную точку веб-перехватчика. Эта операция сообщит вам, были ли успешными попытки отправки уведомлений вашему веб-перехватчику. Эту операцию не следует использовать для получения списка доступного контента. Для перекрестной проверки доступности контента относительно данных, уже полученных веб-перехватчиком, следует использовать операцию /content. Но сначала следует проверить наличие неудачных уведомлений с помощью операции /notifications.

Запрос больших двоичных объектов и регулирование содержимого

Получив список URI контента, необходимо запросить объекты, указанные этими URI. Ниже приведен пример запроса большого двоичного объекта с контентом (с использованием конечной точки API manage.office.com для организаций с планом для предприятий) с помощью PowerShell. В этом примере предполагается, что вы уже использовали предыдущий пример в разделе Получение маркера доступа этой статьи для получения маркера доступа и заполнили $headerParams переменную соответствующим образом.

# Get a content blob
$uri = 'https://manage.office.com/api/v1.0/<<your-tenant-guid>>/activity/feed/audit/<<ContentID>$audit_sharepoint$Audit_SharePoint'
$contents = Invoke-WebRequest -Method GET -Headers $headerParams -Uri $uri

Обратите внимание на следующие особенности переменной $uri в предыдущем примере:

• Мы использовали одинарные кавычки, чтобы среда PowerShell не интерпретировала символы $ как переменные.

• Весь URI будет возвращен в свойстве contentUri отклика на предыдущий вызов конечной точки /content. Маркеры-заполнители представлены исключительно для примера.

При попытке получить доступные большие двоичные объекты многие пользователи (особенно работающие с нагруженными клиентами) сталкивались примерно с такими ошибками:

Response Code 403: {'error':{'code':'AF429','message':'Too many requests. Method=GetBlob, PublisherId=00000000-0000-0000-0000-000000000000'}}

Скорее всего, это вызвано регулированием. Обратите внимание, что значение параметра PublisherId с большой вероятностью указывает, что клиент не указал параметр PublisherIdentifier в запросе. Кроме того, учтите, что правильное имя параметра — PublisherIdentifier, несмотря на то что в откликах об ошибке 403 указывается имя PublisherId.

Примечание.

В справочнике по API параметр PublisherIdentifier указан в каждой операции API, но его также следует включить в запрос GET к URL-адресу contentUri при получении объекта с контентом.

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

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

Если включить допустимый PublisherIdentifier, вы будете находиться в пуле, которому выделяется 60 тыс. запросов в минуту на каждого клиента. Это исключительно большое количество запросов. Однако если не включить параметр PublisherIdentifier , вы будете находиться в общем пуле, отведенном 60 тыс. запросов в минуту для всех клиентов. В этом случае вы, скорее всего, обнаружите, что ваши звонки регулируются. Во избежание этого вы можете запросить большой двоичный объект с контентом при помощи параметра PublisherIdentifier следующим образом:

$contentUri = ($response.Content | ConvertFrom-Json).contentUri[0]
$uri = $contentUri + '?PublisherIdentifier=82b24b6d-0591-4604-827b-705d55d0992f'
$contents = Invoke-WebRequest -Method GET -Headers $headerParams -Uri $uri

В предыдущем примере предполагается, что переменная $response содержит отклик на запрос к конечной точке /content, а переменная $headerParams включает действительный маркер доступа. Скрипт получает из отклика первый элемент массива URI контента, а затем отправляет запрос GET, чтобы скачать этот объект и добавить переменную $contents. Скорее всего, код циклически просмотрит коллекцию contentUri, отправляя запрос GET для каждого значения contentUri.

Теги служб

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

Следующие теги службы содержат префиксы IP-адресов, которые поддерживают API действий управления Office 365 и веб-перехватчик API действий управления Office 365:

• M365ManagementActivityApi

• M365ManagementActivityApiWebhook

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

• Диапазоны IP-адресов и теги служб Microsoft Azure — общедоступное облако

• Диапазоны IP-адресов и теги служб Microsoft Azure — облако для государственных организаций США

• Диапазоны IP-адресов и теги служб Microsoft Azure — облако в Китае

Скачав соответствующий файл, найдите строки "M365ManagementActivityApi" и "M365ManagementActivityApiWebhook", чтобы отыскать раздел, содержащий префиксы IP-адресов для каждого тега службы.

Настройка тегов служб для групп безопасности сети

Командлеты PowerShell Az или AzureRM можно использовать для установки правила группы безопасности сети с тегом службы. Можно настроить правила группы безопасности с тегами службы, а затем добавить эти правила в новую группу сетевой безопасности. Некоторые ресурсы, например Функции Azure, также предоставляют возможность тега службы для настройки групп сетевой безопасности с помощью портала Azure.

Чтобы узнать больше об использовании PowerShell Az или AzureRM для настройки правил сетевой безопасности и групп сетевой безопасности, см.:

• New-AzureRmNetworkSecurityRuleConfig

• New-AzureRmNetworkSecurityGroup

• New-AzNetworkSecurityRuleConfig

• New-AzNetworkSecurityGroup

Вот пример скрипта PowerShell AzureRM, который запрещает исходящий трафик для всех префиксов IP-адресов, за исключением тех, которые включены в тег службы M365ManagementActivityApi. В примере скрипт создает два правила группы безопасности сети для исходящих подключений. Первое правило разрешает исходящий трафик на префиксы IP-адресов, входящие в тег службы M365ManagementActivityApi. Второе правило запрещает исходящий трафик в Интернет. Затем правила добавляются в группу сетевой безопасности, которую можно настроить на определенные службы Azure.

$allowMyServiceRule = New-AzureRmNetworkSecurityRuleConfig ` -Name "AllowMyService"  -Access Allow  -Protocol Tcp  -Direction Outbound  -Priority 100 -DestinationAddressPrefix M365ManagementActivityApi  -SourcePortRange * -SourceAddressPrefix * -DestinationPortRange *
$denyInternetRule = New-AzureRmNetworkSecurityRuleConfig -Name "denyInternetOut" -Access Deny `
-Protocol Tcp -Direction Outbound  -Priority 4000 -DestinationAddressPrefix Internet -SourcePortRange * -SourceAddressPrefix * -DestinationPortRange *
$nsg = New-AzureRmNetworkSecurityGroup `
-ResourceGroupName $resourceGroupName `
-Location $location `
-Name $nsgName `
-SecurityRules $denyInternetRule,$allowMyServiceRule

Аналогично можно настроить правило входящих подключений для приема трафика только из M365ManagementActivityApiWebhook.