Office 365 管理活动 API 常见问题和疑难解答

Office 365 管理活动 API（也称为统一审核 API ）是 Office 365 安全与合规性产品的一部分，它：

• 允许以编程方式访问多个审核管道工作负载（例如 SharePoint 和 Exchange）

• 是各种第三方供应商产品使用的主要接口，用于聚合审核数据并对其编制索引

不应将管理活动 API 与 Office 365 服务通信 API 混淆。 管理活动 API 用于审核各种工作负载中的最终用户活动。 服务通信 API 用于审核由 Office 365 中的可用服务（例如 Dynamics CRM 或标识服务）发送的状态和消息。

有关 Office 365 管理活动 API 的常见问题解答

如何上手使用管理活动 API？

若要开始使用 Office 365 管理活动 API，请参阅 Office 365 管理 API 入门。

如果禁用 Office 365 组织审核，会出现什么情况？ 是否仍可通过管理活动 API 获得事件？

否。 必须为组织启用 Office 365 统一审核，才能通过管理活动 API 拉取记录。 有关说明，请参阅启用或禁用审核日志搜索。

要对特定 Office 365 服务审核什么事件？

“Office 365 管理活动 API 架构”一文列出了全部事件。 有关详细信息，请参阅 Office 365 管理活动 API 架构。 另请参阅在安全与合规中心内搜索审核日志中的“已审核的活动”部分，以获取大多数已审核的 Office 365 服务的事件列表。

管理活动 API 提取的记录与使用 Microsoft Purview 合规门户内的审核日志搜索工具返回的记录是否有何不同?

这两种方法返回的数据是相同的。 唯一的区别在于使用 API 只能获取过去 7 天的数据（下面的问题中提供了更多详细信息）。 在安全与合规中心内搜索审核日志（或在 Exchange Online PowerShell 中使用相应的 Search-unifiedauditlog cmdlet），可以获取生成数据时生效的保持期（对于例如 90 天或一年）的数据。

在发送有关给定 Office 365 事件的通知之前，我必须等待的最长时间是多长？

不存在通知发送的最长保证延迟（换句话说，没有 SLA）。 通常情况下，大多数通知在事件发生后的一个小时内发送。 通常，延迟要短得多，但可能比一小时更长，因为时间因工作负载而异。

事件需要多长时间才能显示在 Office 365 服务中？

Office 365 审核服务不保证传递事件的指定时间。 审核会尝试尽快传递数据。 但是，审核服务上游可能会出现一些问题（例如服务器中断），而这是不可避免的。 由于审核事件通常用于取证调查，因此 Microsoft 将优先考虑数据完整性而不是延迟。 对于核心服务 (例如 Exchange、SharePoint、OneDrive 和 Teams) 事件可用性通常为 60 到 90 分钟。 对于其他服务，事件可用性可能会更长。 虽然这些是典型的事件传递时间，我们也承认可能会发生异常。 出于这些原因，Microsoft 不会承诺特定的传递时间。

Webhook 通知不是更直接吗？

不是。 最近，与直接使用 /content 操作查询 API 相比，使用 Webhook 等待通知的时间更长。

可通过 API 获取内容的时长：

在通知内容可用后的 7 天内，都可以通过 API 获取内容。 即使通知延迟了很长的时间（例如服务中断的情况），你仍然可以在第一次收到通知后的 7 天内下载与原始事件相关的内容 blob。

我可以在管理活动 API 中查询内容 blob 中的特定事件 ID、RecordType 或其他属性吗？

否。 管理活动 API 提供特定日志的所有事件详细信息。 可以使用它来下载所有详细信息，然后你可以对下载的数据实施自己的查询逻辑；例如，通过使用自定义应用程序或第三方工具。

我如何知道来自我现有审核解决方案（该解决方案从管理活动 API 收集数据）的数据是否准确完整？

简单说，Microsoft 不提供允许你交叉检查任何给定应用程序或第三方 (ISV) 应用程序的任何类型的日志。 还有一些其他 Microsoft 安全产品可以从相同管道获取数据，但这些产品不属于本次讨论的范围，不能用于直接交叉检查管理活动 API。 如果担心现有解决方案提供的内容与预期内容之间存在差异，则应实施上述操作。 但这可能很困难，具体取决于你现有的工具或解决方案如何列出数据并对其编制索引。 如果现有解决方案仅显示按实际事件的创建时间排序的数据，则无法按事件创建时间查询 API，进而比较结果集。 在这种情况下，你必须连续数天收集通知的内容 blob，手动对它们编制索引或排序，然后进行手动比较。

管理活动 API 的限制是什么？

所有组织最初每分钟分配 2000 个请求基线。 然后，根据各种因素（包括组织中的席位数量）组合来调整限流。 此外，Office 365 E5 和 Microsoft 365 E5 组织获得的带宽是非 E5 组织的约两倍。 这也是最大宽带的上限，以保护服务的健康。

注意

尽管每个租户最初每分钟最多可提交 2000 个请求，Microsoft 也无法保证响应速率。 响应速率取决于各种因素，如客户端系统性能、网络容量和网络速度。

我在使用管理活动 API 时遇到了限制错误。 该怎么办？

开启 Microsoft 支持票证，申请新限制，并添加提高限制的正当业务理由。 我们将会评估申请，如果接受，便会提高限制。

为什么 TargetUpdatedProperties 不再出现在Microsoft Entra活动的审核日志中的 ExtendedProperties 中？

TargetUpdatedProperties 显示在 ExtendedProperties 中。 但是，它们将从 ExtendedProperties 中删除，并且现在将显示在 ModifiedProperties 中。

为什么不能使用 UserAccountNotFound“LogonError”审核通过管理活动 API Microsoft Entra登录活动的日志？

从 2020 年 11 月开始，Microsoft Entra登录活动的审核日志将从 Microsoft Entra 事件中心引入到统一审核日志中。 由于此更改，无法使用 UserAccountNotFound 值填充 "LogonError" 属性。 从 2021 年 2 月的第一周开始，Microsoft Entra登录审核架构中的 ErrorCode 属性现在与 AADSTS 错误代码匹配。 此外，UserId 参数不会使用 UserAccountNotFound 错误尝试登录的用户名填充，因为该用户名不存在于组织的 Microsoft Entra 目录中。

Office 365 管理活动 API 疑难解答

对于任何开始使用 Office 365 管理活动 API 的人来说，应该明确的一点是，没有按事件细节（例如事件发生的日期、可能触发事件的网站集或者事件类型）进行查询的概念。 相反，可以创建特定工作负荷的订阅 (例如 SharePoint 或 Microsoft Entra ID) ，并且每个订阅都是每个租户的。

以下各节概述了使用 Office 365 管理活动 API 的客户最常见问题：

• 关于第三方工具和客户端的问题

• 在 Office 365 中启用统一审核日志记录

• 连接到 API

• 检查订阅

• 新建订阅

• 检查内容可用性

• 使用 Webhook

• 请求内容 Blob 和限制

• 服务标记

我们将展示一系列简单的 PowerShell 脚本，可以帮助你回答客户提出的最常见问题，或者通过演示主要操作开始实施自定义解决方案。 并非所有操作都在这些章节中做了相关解释，但它们在 Office 365 管理活动 API 参考中均有列出。

关于第三方工具和客户端的问题

最常见问题类别来自使用第三方产品下载和汇总审核数据的客户。 根据第三方产品，客户可能会遇到设置问题或这些产品中暴露的数据出现中断或不一致的情况。 这里应该指出，此类客户首先应采取的措施是联系其供应商的支持部门。 通常情况下，特定租户的供应商配置或服务问题就是客户投诉的原因。

在 Office 365 中启用统一审核日志记录

如果你刚刚设置了一个正在尝试使用管理活动 API 的应用程序，但它无法正常工作，请确保已针对你的 Office 365 组织启用统一审核日志记录。 可通过启用 Office 365 审核日志来实现此操作。 有关说明，请参阅打开或关闭 Office 365 审核日志搜索。

注意

统一审核日志配置更改最多可能需要 60 分钟才能生效。

如果未启用统一审核，通常会收到包含以下字符串的错误： Microsoft.Office.Compliance.Audit``.DataServiceException: Tenant <tenantID> does not exist.

连接到 API

大多数应用程序使用简单直观的客户端凭据 OAuth2 流连接到 API。 因此，第一步是创建一个Microsoft Entra应用程序，该应用程序具有访问管理活动 API 数据所需的权限。 本文不介绍创建Microsoft Entra应用注册的步骤。 有关详细信息，请参阅将应用程序注册到Microsoft Entra租户。

Azure 应用程序权限

当前用于 Office 365 管理活动 API 的三个权限是：

1. 为组织读取活动数据

2. 为组织读取服务运行状况信息

3. 读取数据丢失防护 (DLP) 策略事件，包括检测到的敏感信息

注意

你应至少为上述权限集的前两个启用“应用程序权限”和“委派权限”。 仅在你对 DLP 工作负载感兴趣时才需要读取 DLP 策略事件。

获取访问令牌

以下 PowerShell 脚本使用应用 ID 和客户端密码从管理活动 API 身份验证端点获取 OAuth2 令牌。 然后，它将访问令牌放置到 $headerParams 数组变量，该变量将附加到 HTTP 请求中。 对于 API 终结点的值（在 $resource 变量中），请使用基于组织的 Microsoft 365 或 Office 365 订阅计划的以下任一值:

• 企业版计划：manage.office.com

• GCC 政府版计划：manage-gcc.office.com

• GCC 高级政府版计划: 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 订阅未启用 webhook (null)，而 SharePoint 订阅已启用 webhook，并显示已注册端点的地址。

新建订阅

要创建新订阅，请使用 /start 操作。 对于 API 终结点，请使用基于订阅计划的以下任一值:

• 企业版计划：manage.office.com

• GCC 政府版计划：manage-gcc.office.com

• GCC 高级政府版计划: 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。 然后，可以使用本文的“检查订阅”部分中的代码检查订阅。

检查内容可用性

要检查在特定时间段内创建了哪些内容 Blob，可以将以下行添加到脚本中的“连接到 API”部分。

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

前面的示例将获取今天可用的所有内容通知，即从 UTC 时间中午 12:00 到当前时间。 如果要指定不同的时间段（请记住，可以查询的最长时间段为 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 属性是你可以从中检索内容 blob 的 URI。 blob 本身包含事件详细信息，它将包含有关 1 - N 事件的详细信息。 虽然集合中可能有 30 个 JSON 对象，但在这 30 个内容 URI 中可能详述了更多事件。

• contentCreated 属性不是创建所通知的事件的日期， 而是创建通知的日期。 可以在创建内容 blob 之前创建该 blob 中详述的事件。 因此，永远不能直接查询任何给定时间段内发生的事件的 API。

繁忙租户的页面内容

许多较大的 Office 365 租户每小时都会生成数千个事件。 如果你的组织就是这种情况，并且你尝试执行上述示例中的 24 小时周期查询，则可能需要检索比一个响应中返回的通知更多的通知。 在这种情况下，需要实现某种逻辑循环，每次都检查 NextPageUrl: 标头值的响应头。 有关详细信息，请参阅 Office 365 管理活动 API 参考中的分页部分。

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 标头。

使用 Webhook

有两种方法可以获得已创建内容 blob 的通知。 推送方法是使用 webhook 端点实现的，该端点是你自己创建和托管的 Web 应用程序或云平台上的 Web 应用程序。 在创建针对已审核内容类型的订阅时注册 webhook。 还可以使用下面显示的方法向现有订阅添加 webhook 注册。 拉取方法要求使用 /content 操作查询特定时间段（不超过 24 小时）。 该响应将告诉你在指定时间段内创建了哪些内容 blob。

在添加 webhook 之前，请注意以下两个问题：

1. 由于调试和疑难解答过程存在困难，因此 Microsoft 不再强调 Webhook。 通常，你应该托管响应传入请求的 Web API 端点。 许多客户使用托管环境（他们没有完全控制权限）或本地环境（难以允许传入的 HTTP 请求）。 支持部门已经发现许多问题，其中来自 Office 365 审核管道的传入请求已被防火墙或路由器阻止。 在这种情况下，API 将实现退避算法，这可能会令人困惑，并可能导致禁用订阅中的 webhook。

2. 执行启动操作后，webhook 必须准备好立即响应验证请求。 如果 webhook 应用程序中存在错误，则验证将失败，并且不会启用 webhook。 有关验证请求架构的信息，请参阅 Office 365 管理活动 API 参考中的 Webhook 验证部分。 你应该认真考虑生成生产就绪型 webhook 以响应管理活动 API 通知所面临的挑战。

如果你决定实现 webhook，则应对其进行测试，以验证在首次调用指定 webhook 端点的任何 /start 操作之前，端点是否已准备好响应针对验证请求和正常通知请求的 HTTP 200 响应。 通常，你将使用来自 API 的模拟请求来测试此准备情况。 仔细阅读并遵守 Office 365 管理活动 API 参考中的 Webhook 验证和检索内容部分，以了解这两种请求类型的架构。

要使用 webhook 端点添加订阅，请将 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/ … 发送验证请求，并且应根据 Office 365 管理活动 API 参考中的 Webhook 验证部分中的说明准备好用于响应的侦听器。 侦听器必须通过 HTTP 200 进行响应。 如果此时立即运行 /list 操作，则在成功返回验证之前，不会看到 Webhook 显示为 null。

检查 Webhook 的通知

能够区分 /notifications 操作和 /content 操作很重要。 仅当通过 webhook 端点进行订阅时才需要检查通知。 此操作让你了解尝试向 webhook 发送的通知是否成功。 此操作不应用于列出可用内容。 要根据 webhook 中已收到内容交叉检查内容的可用性，你可以使用 /content 操作。 但请务必先使用 /notifications 操作检查失败的通知。

请求内容 Blob 和限制

获取内容 URI 列表后，必须请求 URI 指定的 blob。 下面是使用 PowerShell 请求内容 Blob（使用适用于企业组织的 manage.office.com API 终结点）的示例。 此示例假定你已使用本文获取访问令牌部分中的上 一个 示例来获取访问令牌，并已正确填充变量 $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 将在针对你上次调用 /content 端点的响应的 contentUri 属性中返回。 显示的占位符令牌仅用于说明。

在尝试检索可用内容 blob 时，许多客户（大多数与繁忙租户合作）遇到如下错误：

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

这可能因限制所致。 请注意，Publisherid 参数的值可能表示客户端未在请求中指定 PublisherIdentifier。 此外，请记住，正确的参数名称是 PublisherIdentifier，即使你在 403 错误响应中看到列出 PublisherId 也是如此。

注意

在 API 参考中，在 API 的每个操作中均会列出 PublisherIdentifier 参数，但在检索内容 blob 时，它也应包含在针对 contentUri URL 的 GET 请求中。

如果你正在进行简单的 API 调用来解决问题（例如，检查给定订阅是否处于活动状态），则可以安全地省略 PublisherIdentifier 参数，但在每次调用时，任何最终用于生产用途的代码绝对都应该包括 PublisherIdentifier 参数。

如果你正在为公司的租户实现客户端，则 PublisherIdentifier 是租户 GUID。 如果要为多个客户创建 ISV 应用程序或外接程序，则 PublisherIdentifier 应该是 ISV 的租户 GUID，而不是最终用户公司的租户 GUID。

如果包含有效的 PublisherIdentifier，则会位于每个租户每分钟分配 6 万个请求的池中。 请求的量是极大的。 但是，如果未包含 PublisherIdentifier 参数，则会在所有租户的常规池中分配每分钟 60K 个请求。 在这种情况下，你很可能发现你的呼叫受到限制。 为了防止出现这种情况，以下是使用 PublisherIdentifier 请求内容 blob 的方法：

$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 下载该 blob，并将其放入 $contents 变量中。 代码可能会遍历 contentUri 集合，针对每个 contentUri 发出 GET。

服务标记

Office 365 管理活动 API 和 Office 365 管理活动 API Webhook 现在支持 服务标记，可查找需要通过防火墙允许的必需 IP 地址前缀。 服务标记表示由 Microsoft 管理和更新的一组预定义 IP 地址前缀。 服务标记有助于最大程度地降低安全规则创建的复杂性。

以下服务标记包括支持 Office 365 管理活动 API 和 Office 365 管理活动 API Webhook 的 IP 地址前缀：

• M365ManagementActivityApi

• M365ManagementActivityApiWebhook

有关前面的服务标记包含的 IP 地址前缀的列表，请下载以下文件之一：

• Microsoft Azure IP 范围和服务标签 – 公共云

• Microsoft Azure IP 范围和服务标签 - 美国政府云

• Microsoft Azure IP 范围和服务标签 – 中国云

下载相应的文件后，搜索字符串“M365ManagementActivityApi”和“M365ManagementActivityApiWebhook”，以查找包含每个服务标记的 IP 地址前缀的部分。

为网络安全组配置服务标记

可以使用 Az 或 AzureRM PowerShell cmdlet 来设置具有服务标记的网络安全组规则。 可以使用服务标记配置安全组规则，然后将这些规则添加到新的网络安全组。 一些资源（如 Azure Functions）还提供了一个服务标记选项，可使用 Azure 门户配置网络安全组

有关使用 Az 或 AzureRM PowerShell 设置网络安全规则和网络安全组的信息，请参阅：

• New-AzureRmNetworkSecurityRuleConfig

• New-AzureRmNetworkSecurityGroup

• New-AzNetworkSecurityRuleConfig

• New-AzNetworkSecurityGroup

下面是 AzureRM PowerShell 脚本的示例，该脚本将出站流量限制为除 M365ManagementActivityApi 服务标记中包含的前缀之外的所有 IP 地址前缀。 示例脚本创建了两个出站网络安全组规则。 第一个规则允许流向 M365ManagementActivityApi 服务标记中包含的 IP 地址前缀的出站流量。 第二个规则拒绝流向 Internet 的出站流量。 然后，这些规则将添加到网络安全组，然后可以将其配置为特定的 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 的流量的入站规则。