動作群組
當 Azure 監視器資料指出基礎結構或應用程式可能有問題時,就會觸發警示。 除了警示本身之外,您還可以使用動作群組在觸發警示時傳送通知,例如語音通話、簡訊或電子郵件。 動作群組是通知喜好設定和動作的集合。 Azure 監視器、Azure 服務健康狀態和 Azure Advisor 會使用動作群組來通知使用者相關警示並採取動作。 本文說明如何建立及管理動作群組。
每個動作的組成為:
- 類型:已傳送的通知,或已執行的動作。 範例包括傳送語音通話、簡訊或電子郵件。 您也可以觸發各種類型的自動化動作。
- 名稱:動作群組內的唯一識別碼。
- 詳細資料:依類型而有所不同的對應詳細資料。
一般而言,動作群組是全域服務。 正在努力開發使其更具區域可用性。
用戶端的全域要求可由任何區域中的動作群組服務處理。 如果動作群組服務的某個區域關閉,流量會自動在其他區域中路由處理。 作為全域服務,動作群組可協助提供災害復原解決方案。 區域要求依賴可用性區域備援來符合隱私權需求,並提供類似的災害復原解決方案。
- 您可以將最多五個動作群組新增至警示規則。
- 動作群組會同時執行 (沒有特定順序)。
- 多個警示規則可以使用相同的動作群組。
- 動作群組是由唯一的一組動作和要通知的使用者所定義。 例如,如果您想要透過電子郵件通知 User1、User2 和 User3 兩個不同的警示規則,則您只需要建立一個動作群組,即可套用至這兩個警示規則。
建立 Azure 入口網站中的動作群組
前往 Azure 入口網站。
搜尋並選取 [監視]。 [監視器] 頁面會將您的所有監視設定與資料合併在一個檢視中。
選取 [警示],然後選取 [動作群組]。
選取 建立。
設定基本動作群組設定。 在 [專案詳細資料] 區段中:
- 選取 [訂用帳戶] 和 [資源群組]的值。
- 選取區域。
注意
服務健康情況警示僅在全域區域內的公用雲端中受到支援。 若要讓動作群組在回應服務健康情況警示時正常運作,動作群組的區域必須設定為「全域」。
選項 行為 全球 動作群組服務會決定儲存動作群組的位置。 動作群組會在至少兩個區域中保存,以確保區域復原能力。 可以在任何地理區域中處理動作。
因服務健康情況警示結果而執行的語音、SMS 和電子郵件動作,可復原 Azure 即時網站事件。地區 動作群組儲存在選取的區域內。 動作群組是區域備援。 如果您想要確保動作群組的處理是在特定的地理界限內執行,請使用此選項。 您可以選擇下列其中一個區域,以進行動作群組的區域處理:
- 美國東部
- 美國西部
- 美國東部 2
- 美國西部 2
- 美國中南部
- 美國中北部
- 瑞典中部
- 德國中西部
- 印度中部
- 印度南部
我們會持續為動作群組的區域資料處理新增更多區域。動作群組會儲存於您所選取的 [訂閱]、[區域] 和 [資源群組] 中。
在 [執行個體詳細資料] 區段中,輸入 [動作群組名稱] 和 [顯示名稱] 的值。 當群組用來傳送通知時,顯示名稱會用來取代完整動作群組名稱。
設定通知。 選取頁面頂端的 [下一步: 通知] 或 [通知] 索引標籤。
定義觸發警示時,要傳送的通知清單。
針對每個通知:
選取通知類型,然後填入該通知的適當欄位。 可用的選項如下:
通知類型 描述 欄位 寄送電子郵件給 Azure Resource Manager 角色 根據訂用帳戶成員的角色傳送電子郵件給訂用帳戶成員。
請參閱電子郵件。輸入為 Microsoft Entra 使用者設定的主要電子郵件位址。 請參閱電子郵件。 電子郵件 請確定您已正確設定電子郵件篩選和任何惡意程式碼/垃圾郵件預防服務。 電子郵件會從下列電子郵件地址傳送:
%
%
%輸入應收到通知的電子郵件。 SMS SMS 通知支援雙向通訊。 SMS 包含下列資訊:
* 會收到此警示的動作群組簡稱
* 警示標題。
使用者可以回應 SMS 以:
* 取消訂閱所有動作群組或單一動作群組的所有 SMS 警示。
* 重新訂閱警示
* 要求說明。
如需受支援 SMS 回覆的詳細資訊,請參閱 SMS 回覆。輸入 SMS 收件者的 [國碼 (地區碼)] 和 [電話號碼]。 如果您無法在 Azure 入口網站中選取您的國碼 (地區碼),即表示您的國家/地區不支援 SMS。 如果您的國碼 (地區碼) 無法使用,您可以在 [分享您的想法] 投票以新增您的國家/地區。 作為因應措施,直到支援您的國家/地區為止,請將動作群組設定為將 Webhook 呼叫給支援您國家/地區的第三方 SMS 提供者。 Azure 應用程式推播通知 將通知傳送至 Azure 行動應用程式。 若要啟用 Azure 行動應用程式的推播通知,請提供 Azure 行動應用程式的詳細資訊,請參閱 Azure 行動應用程式。 在 [Azure 帳戶電子郵件] 欄位中,輸入您在設定 Azure 行動應用程式時用來作為帳戶識別碼的電子郵件地址。 語音 語音通知。 輸入通知收件者的 [國碼 (地區碼)] 和 [電話號碼]。 如果您無法在 Azure 入口網站中選取您的國碼 (地區碼),即表示您的國家/地區不支援語音通知。 如果您的國碼 (地區碼) 無法使用,您可以在 [分享您的想法] 投票以新增您的國家/地區。 作為因應措施,直到支援您的國家/地區為止,請將動作群組設定為將 Webhook 呼叫給支援您國家/地區的第三方語音電話提供者。 選取是否要啟用通用警示結構描述。 一般警示結構描述是單一可擴充且已整合的警示承載,可用於跨 Azure 監視器的所有警示服務。 如需通用結構描述的詳細資訊,請參閱一般警示結構描述。
選取 [確定]。
設定動作。 選取 [下一步:動作]。 或選取頁面頂端的 [動作] 索引標籤。
定義觸發警示時,要觸發的動作清單。 選取動作類型,然後輸入每個動作的名稱。
動作類型 詳細資料 自動化 Runbook 使用自動化 Runbook 以根據計量自動執行工作。 例如,在符合相關預算中的特定閾值時關閉資源。 如需自動化 Runbook 承載限制的相關資訊,請參閱自動化限制。 事件中樞 [事件中樞] 動作會將通知發佈至 [事件中樞]。 如需事件中樞的詳細資訊,請參閱 Azure 事件中樞 — 巨量資料串流平台和事件擷取服務。 您可以從事件接收者訂閱警示通知資料流程。 函式 在函式中呼叫現有的 HTTP 觸發程序端點。 如需詳細資訊,請參閱 Azure Functions。
當您定義函式動作時,函式的 HTTP 觸發程序端點和存取金鑰會儲存在動作定義中,例如https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>
。 如果您變更函式的存取金鑰,則必須移除並重新建立動作群組中的函式動作。
您的端點必須支援 HTTP POST 方法。
函式必須具有儲存體帳戶的存取權。 如果沒有存取權,則無法使用金鑰,且無法存取函式 URI。
了解如何還原儲存體帳戶的存取權。ITSM ITSM 動作需要 ITSM 連線。 若要了解如何建立 ITSM 連線,請參閱 ITSM 整合。 邏輯應用程式 您可以使用 Azure Logic Apps 來建置和自訂整合的工作流程,以及自訂警示通知。 安全 Webhook 當您使用安全 Webhook 動作時,必須使用 Microsoft Entra ID 來保護動作群組與端點之間的連線,這是受保護的 Web API。 請參閱設定安全 Webhook 的驗證。 安全 Webhook 不支援基本驗證。 如果您使用基本驗證,請使用 Webhook 動作。 Webhook 如果您使用 Webhook 動作,您的目標 Webhook 端點必須能夠處理不同警示來源發出的各種 JSON 承載。
您無法透過 Webhook 動作傳遞安全性憑證。 若要使用基本驗證,您必須透過 URI 傳遞認證。
如果 Webhook 端點需要特定結構描述,例如 Microsoft Teams 結構描述,請使用 Logic Apps 動作類型來操作警示結構描述,以符合目標 Webhook 的期望。
如需用於重試 Webhook 動作規則的相關資訊,請參閱 Webhook。(選擇性。)如果您要將索引鍵/值組指派給動作群組,以分類 Azure 資源,請選取 [下一步:標籤] 或 [標籤] 索引標籤。否則,請略過此步驟。
選取 [檢閱 + 建立] 來檢閱您的設定。 此步驟會快速檢查您的輸入,以確定您已輸入所有必要的資訊。 如果發生問題,則會在這裡回報。 在您檢閱設定之後,請選取 [建立] 以建立動作群組。
注意
當您設定一個動作,透過電子郵件或 SMS 來通知某人時,他們會收到確認,並指出已新增至動作群組。
測試 Azure 入口網站中的動作群組
在 Azure 入口網站中建立或更新動作群組時,您可以測試動作群組。
-
注意
測試之前,必須先建立並儲存動作群組。 如果您要編輯現有的動作群組,請先將變更儲存至動作群組,再進行測試。
在動作群組頁面上,選取 [測試動作群組]。
選取範例類型,以及您想要測試的通知和動作類型。 然後選取 [測試]。
如果您關閉視窗,或在測試執行時選取 [返回測試設定],系統會停止測試,且不會取得測試結果。
測試結束時,會顯示 [成功] 或 [失敗] 的測試狀態。 如果測試失敗,而您想要取得更多詳細資訊,請選取 [檢視詳細資料]。
您可以使用 [錯誤詳細資料] 區段中的資訊來了解問題。 然後您可以再次編輯,儲存變更和測試動作群組。
當您執行測試並選取通知類型時,您會收到一則主旨含有「測試」的訊息。 測試提供了一種方法,讓您在生產環境中啟用動作群組之前,檢查動作群組是否如預期運作。 測試電子郵件通知中的所有詳細資料和連結皆來自範例參考集。
測試動作群組的角色需求
下表描述「測試動作」功能所需的角色成員資格需求:
角色成員資格 | 現有的動作群組 | 現有的資源群組和新動作群組 | 新資源群組和新動作群組 |
---|---|---|---|
訂用帳戶參與者 | 支援 | 支援 | 支援 |
資源群組參與者 | 支援 | 支援 | 不適用 |
動作群組資源參與者 | 支援 | 不適用 | 不適用 |
Azure 監視器參與者 | 支援 | 支援 | 不適用 |
自訂角色1 | 支援 | 支援 | 不適用 |
1 自訂角色必須具有 Microsoft.Insights/createNotifications/* 權限。
注意
- 如果使用者不是上述角色成員資格的成員,且不具有產生此通知的正確權限,則測試動作群組所需的最低權限為 "Microsoft.Insights/createNotifications/*"
- 您可以在每個時間週期執行次數有限的測試。 若要查看哪些限制適用於您的情況,請參閱 Azure 監視器服務限制。
- 當您在入口網站中設定動作群組時,可以加入或退出常見的警示結構描述。
- 若要尋找所有範例類型的常見結構描述範例,請參閱測試動作群組的常見警示結構描述定義。
- 若要尋找非通用架構警示定義,請參閱測試動作群組的非一般警示結構描述定義。
使用 Resource Manager 範本建立動作群組
您可以使用 Azure Resource Manager 範本設定動作群組。 您可以透過範本自動設定可在特定類型的警示中重複使用的動作群組。 這些動作群組能確定觸發警示時,所有正確的對象都會收到通知。
基本步驟為:
- 建立一個描述如何建立動作群組的範本作為 JSON 檔案。
- 使用任何部署方法部署範本。
動作群組 Resource Manager 範本
若要使用 Resource Manager 範本建立動作群組,您要建立 Microsoft.Insights/actionGroups
類型的資源。 然後要填入所有相關的屬性。 以下是兩個建立動作群組的範例範本。
第一個範本,說明如何建立動作群組的 Resource Manager 範本,其中的動作定義硬式編碼在範本中。 第二個範本,說明如何建立範本部署時,採用 Webhook 設定資訊作為輸入參數的範本。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"actionGroupName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"actionGroupShortName": {
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/actionGroups",
"apiVersion": "2021-09-01",
"name": "[parameters('actionGroupName')]",
"location": "Global",
"properties": {
"groupShortName": "[parameters('actionGroupShortName')]",
"enabled": true,
"smsReceivers": [
{
"name": "contosoSMS",
"countryCode": "1",
"phoneNumber": "5555551212"
},
{
"name": "contosoSMS2",
"countryCode": "1",
"phoneNumber": "5555552121"
}
],
"emailReceivers": [
{
"name": "contosoEmail",
"emailAddress": "devops@contoso.com",
"useCommonAlertSchema": true
},
{
"name": "contosoEmail2",
"emailAddress": "devops2@contoso.com",
"useCommonAlertSchema": true
}
],
"webhookReceivers": [
{
"name": "contosoHook",
"serviceUri": "http://requestb.in/1bq62iu1",
"useCommonAlertSchema": true
},
{
"name": "contosoHook2",
"serviceUri": "http://requestb.in/1bq62iu2",
"useCommonAlertSchema": true
}
],
"SecurewebhookReceivers": [
{
"name": "contososecureHook",
"serviceUri": "http://requestb.in/1bq63iu1",
"useCommonAlertSchema": false
},
{
"name": "contososecureHook2",
"serviceUri": "http://requestb.in/1bq63iu2",
"useCommonAlertSchema": false
}
],
"eventHubReceivers": [
{
"name": "contosoeventhub1",
"subscriptionId": "replace with subscription id GUID",
"eventHubNameSpace": "contosoeventHubNameSpace",
"eventHubName": "contosoeventHub",
"useCommonAlertSchema": true
}
]
}
}
],
"outputs":{
"actionGroupId":{
"type":"string",
"value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
}
}
}
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"actionGroupName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"actionGroupShortName": {
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
},
"webhookReceiverName": {
"type": "string",
"metadata": {
"description": "Webhook receiver service Name."
}
},
"webhookServiceUri": {
"type": "string",
"metadata": {
"description": "Webhook receiver service URI."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/actionGroups",
"apiVersion": "2021-09-01",
"name": "[parameters('actionGroupName')]",
"location": "Global",
"properties": {
"groupShortName": "[parameters('actionGroupShortName')]",
"enabled": true,
"smsReceivers": [
],
"emailReceivers": [
],
"webhookReceivers": [
{
"name": "[parameters('webhookReceiverName')]",
"serviceUri": "[parameters('webhookServiceUri')]",
"useCommonAlertSchema": true
}
]
}
}
],
"outputs":{
"actionGroupResourceId":{
"type":"string",
"value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
}
}
}
管理動作群組
建立動作群組之後,您可以在入口網站中檢視群組:
前往 Azure 入口網站。
從 [監視] 頁面,選取 [警示]。
選取 [動作群組]。
選取您要管理的動作群組。 您可以:
- 新增、編輯或移除動作。
- 刪除動作群組。
通知的服務限制
電話號碼或電子郵件包含在許多訂用帳戶動作群組內。 Azure 監視器使用速率限制,在傳送了太多通知給特定電話號碼、電子郵件地址或裝置時會通知暫停。 速率限制可確保警示為可管理且可採取動作。
速率限制適用於 SMS、語音和電子郵件通知。 所有其他通知動作的速率都不受限制。 速率限制適用於所有訂用帳戶。 速率限制適用於觸達閾值時,即使是從多個訂用帳戶傳送訊息。 當電子郵件地址受到速率限制時,將會傳送通知來溝通,表示已套用速率限制,以及速率限制到期時間。
如需速率限制詳細資訊,請參閱 Azure 監視器服務限制。
寄送電子郵件給 Azure Resource Manager
當您使用 Azure Resource Manager 電子郵件通知時,可以將電子郵件傳送給訂閱角色的成員。 電子郵件會傳送給 Microsoft Entra ID 使用者或群組角色的成員。 這包括對透過 Azure Lighthouse 所指派的角色支援。
注意
動作群組僅支援傳送電子郵件給下列角色:擁有者、參與者、讀者、監視參與者、監視讀者。
如果您的主要電子郵件未收到通知,請設定電子郵件 Azure Resource Manager 角色的電子郵件位址:
在 Azure 入口網站中,移至 [Microsoft Entra ID]。
選取左邊的 [所有使用者]。 右側會出現使用者清單。
選取您想檢閱其「主要電子郵件」的使用者。
在使用者設定檔中,查看 [連絡資訊] 底下是否有電子郵件的值。 如果欄位空白:
- 在頁面頂端選取 [編輯]。
- 輸入電子郵件地址。
- 在頁面頂端,選取 [儲存]。
您在每個動作群組中的電子郵件動作數量可能會有限制。 若要查看哪些限制適用於您的情況,請參閱 Azure 監視器服務限制。
您在設定 Resource Manager 角色時:
- 將使用者或群組類型的實體指派給角色。
- 在訂閱層級進行角色指派。
- 請確保在使用者的 Microsoft Entra 設定檔中為其設定電子郵件地址。
- 如果使用者不是上述角色成員資格的成員,且不具有產生此通知的正確權限,則測試動作群組所需的最低權限為 "Microsoft.Insights/createNotifications/*"
- 您可以在每個時間週期執行次數有限的測試。 若要查看哪些限制適用於您的情況,請參閱 Azure 監視器服務限制。
- 當您在入口網站中設定動作群組時,可以加入或退出常見的警示結構描述。
- 若要尋找所有範例類型的常見結構描述範例,請參閱測試動作群組的常見警示結構描述定義。
- 若要尋找非通用架構警示定義,請參閱測試動作群組的非一般警示結構描述定義。
注意
在客戶將新的 Azure Resource Manager 角色新增至其訂閱之後,可能需要 24 小時才能開始接收通知。
SMS
您在每個動作群組中的簡訊動作數量可能會有限制。
- 如需速率限制詳細資訊,請參閱 Azure 監視器服務限制。
- 如需在動作群組中使用簡訊通知的重要資訊,請參閱動作群組中的簡訊警示行為。
注意
如果您無法在 Azure 入口網站中選取您的國碼 (地區碼),即表示您的國家/地區不支援 SMS。 如果您的國碼 (地區碼) 無法使用,您可以在 [分享您的想法] 投票以新增您的國家/地區。 同時,有個因應措施是將您的動作群組設定為向第三方簡訊提供者 (可在您的國家/區域提供支援) 呼叫 Webhook。
SMS 回覆
SMS 通知支援這些回覆。 SMS 的收件者可以使用下列值回覆 SMS:
REPLY | 描述 |
---|---|
DISABLE <Action Group Short name> |
停用來自動作群組的其他 SMS |
ENABLE <Action Group Short name> |
重新啟用來自動作群組的 SMS |
停止 | 停用來自所有動作群組的其他 SMS |
START | 重新啟用來自所有動作群組的 SMS |
HELP | 使用者將會收到包含本文連結的回應。 |
注意
如果使用者已取消訂閱 SMS 警示,但又加入新的動作群組;則他們會接收到新動作群組的 SMS 警示,但對於所有之前的動作群組,仍是取消訂閱狀態。 您在每個動作群組中的 Azure 應用程式動作數量可能會有限制。
支援 SMS 通知的國家/區域
國碼 (地區碼) | Country |
---|---|
61 | 澳洲 |
43 | 奧地利 |
32 | 比利時 |
55 | 巴西 |
1 | 加拿大 |
56 | 智利 |
86 | 中國 |
420 | 捷克共和國 |
45 | 丹麥 |
372 | 愛沙尼亞 |
358 | 芬蘭 |
33 | 法國 |
49 | 德國 |
852 | 香港特別行政區 |
91 | 印度 |
353 | 愛爾蘭 |
972 | 以色列 |
39 | 義大利 |
81 | 日本 |
352 | 盧森堡 |
60 | 馬來西亞 |
52 | 墨西哥 |
31 | 荷蘭 |
64 | 紐西蘭 |
47 | 挪威 |
351 | 葡萄牙 |
1 | 波多黎各 |
40 | 羅馬尼亞 |
7 | 俄羅斯 |
65 | 新加坡 |
27 | 南非 |
82 | 南韓 |
34 | 西班牙 |
41 | 瑞士 |
886 | 台灣 |
971 | 阿拉伯聯合大公國 |
44 | 英國 |
1 | 美國 |
語音
您在每個動作群組中的語音動作數量可能會有限制。 如需速率限制的重要資訊,請參閱 Azure 監視器服務限制。
注意
如果您無法在 Azure 入口網站中選取您的國家/地區代碼,代表不支援您國家/地區的語音通話。 如果您的國碼 (地區碼) 無法使用,您可以在 [分享您的想法] 投票以新增您的國家/地區。 同時,有個因應措施是將您的動作群組設定為向第三方語音電話提供者 (可在您的國家/區域提供支援) 呼叫 Webhook。 如果國家/地區標有 '*',則通話將來自美國的電話號碼。
SMS 通知支持的國家/地區
國碼 (地區碼) | Country |
---|---|
61 | 澳洲 |
43 | 奧地利 |
32 | 比利時 |
55 | 巴西 |
1 | 加拿大 |
56 | 智利 |
86 | 中國* |
420 | 捷克共和國 |
45 | 丹麥 |
372 | 愛沙尼亞 |
358 | 芬蘭 |
33 | 法國 |
49 | 德國 |
852 | 香港* |
91 | 印度* |
353 | 愛爾蘭 |
972 | 以色列 |
39 | 義大利* |
81 | 日本* |
352 | 盧森堡 |
60 | 馬來西亞 |
52 | 墨西哥 |
31 | 荷蘭 |
64 | 紐西蘭 |
47 | 挪威 |
351 | 葡萄牙 |
40 | 羅馬尼亞* |
7 | 俄羅斯* |
65 | 新加坡 |
27 | 南非 |
82 | 南韓 |
34 | 西班牙 |
46 | 瑞典 |
41 | 瑞士 |
886 | 台灣* |
971 | 阿拉伯聯合大公國* |
44 | 英國 |
1 | 美國 |
如需支援國家/地區定價的相關資訊,請參閱 Azure 監視器定價。
Webhook
注意
如果您使用 Webhook 動作,您的目標 Webhook 端點必須能夠處理不同警示來源發出的各種 JSON 承載。 Webhook 端點也必須可公開存取。 您無法透過 Webhook 動作傳遞安全性憑證。 若要使用基本驗證,您必須透過 URI 傳遞認證。 如果 Webhook 端點預期特定結構描述 (例如,Microsoft Teams 結構描述),請使用 Logic Apps 動作來轉換警示結構描述,以符合目標 Webhook 的預期。 呼叫 Webhook 動作群組時,通常會遵循下列規則:
- 叫用 Webhook 時,如果第一次呼叫失敗,則會重試至少 1 次,並在各種延遲間隔中重試最多 5 次 (5 次重複嘗試) (5 秒、20 秒、40 秒)。
- 第 1 到 2 次嘗試之間的延遲為 5 秒
- 第 2 到 3 次嘗試之間的延遲為 20 秒
- 第 3 到 4 次嘗試之間的延遲為 5 秒
- 第 4 到 5 次嘗試之間的延遲為 40 秒
- 第 5 到 6 次嘗試之間的延遲為 5 秒
- 如果嘗試呼叫 Webhook 失敗,則 15 分鐘內不會有任何動作群組呼叫端點。
- 重試邏輯假設可以重試呼叫。 狀態代碼:408、429、503、504 或 HttpRequestException、WebException,
TaskCancellationException
允許重試呼叫。
設定安全性 Webhook 的驗證
安全的 Webhook 動作會使用「AZNS Microsoft Entra Webhook」Microsoft Entra 應用程式的 Microsoft Entra 租用戶中的服務主體執行個體,向受保護的 API 進行驗證。 若要讓動作群組運作,此 Microsoft Entra Webhook 服務主體必須新增為目標 Microsoft Entra 應用程式上角色的成員,以授與目標端點的存取權。
如需 Microsoft Entra 應用程式和服務主體的概觀,請參閱 Microsoft 身分識別平台 (v2.0) 概觀。 請遵循下列步驟來利用安全 Webhook 功能。
注意
SecureWebhook
不支援基本身份驗證。 若要使用基本驗證,您必須使用 Webhook
。
如果您使用 Webhook 動作,您的目標 Webhook 端點必須能夠處理不同警示來源發出的各種 JSON 承載。 如果 Webhook 端點預期特定結構描述 (例如,Microsoft Teams 結構描述),請使用 Logic Apps 動作來轉換警示結構描述,以符合目標 Webhook 的預期。
注意
自 2024 年 3 月 30 日起,Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解,請閱讀淘汰更新。 在此日期之後,對這些模組的支援僅限於對 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 淘汰的模組將繼續運作至 2025 年 3 月 30 日。
我們建議移轉至 Microsoft Graph PowerShell 以與 Microsoft Entra ID (以前稱為 Azure AD) 互動。 如需了解常見的移轉問題,請參閱移轉常見問題。 注意:MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。
為受保護的 Web API 建立 Microsoft Entra 應用程式。 如需更多資訊,請參閱受保護的 Web API:應用程式註冊。 將受保護的 API 設為由精靈應用程式呼叫,並公開應用程式權限,而非委派權限。 如需這些權限的詳細資訊,請參閱如果您的 Web API 是由服務或精靈應用程式呼叫。
注意
將受保護的 Web API 設為接受 V2.0 存取權杖。 如您設定的詳細資訊,請參閱 Microsoft Entra 應用程式指令清單。
若要讓動作群組能夠使用您的 Microsoft Entra 應用程式,請使用遵循此程序的 PowerShell 指令碼。
注意
您必須被指派 Microsoft Entra 應用程式系統管理員角色,才能執行此指令碼。
- 修改 PowerShell 指令碼的
Connect-AzureAD
呼叫,以使用您的 Microsoft Entra 租用戶識別碼。 - 修改 PowerShell 指令碼的
$myAzureADApplicationObjectId
變數,以使用 Microsoft Entra 應用程式的物件識別碼。 - 執行修改過的指令碼。
注意
服務主體必須指派 Microsoft Entra 應用程式擁有者角色,才能在動作群組中建立或修改安全 Webhook 動作。
- 修改 PowerShell 指令碼的
設定安全 Webhook 動作。
- 複製指令碼中的
$myApp.ObjectId
值。 - 在 Webhook 動作定義中的 [物件識別碼] 方塊中,輸入您複製的值。
- 複製指令碼中的
安全 Webhook PowerShell 指令碼
如何執行?
- 將以下指令碼複製並貼到您的機器
- 取代您的 tenantId 和您的應用程式註冊中的 ObjectID
- 另存成 *.ps1
- 從您的機器中開啟 PowerShell 命令,然後執行 *.ps1 指令碼
Write-Host "================================================================================================="
$scopes = "Application.ReadWrite.All"
$myTenantId = "<<Customer's tenant id>>"
$myMicrosoftEntraAppRegistrationObjectId = "<<Customer's object id from the app registration>>"
$actionGroupRoleName = "ActionGroupsSecureWebhook"
$azureMonitorActionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a" # Required. Do not change.
Connect-MgGraph -Scopes $scopes -TenantId $myTenantId
Function CreateAppRole([string] $Name, [string] $Description)
{
$appRole = @{
AllowedMemberTypes = @("Application")
DisplayName = $Name
Id = New-Guid
IsEnabled = $true
Description = $Description
Value = $Name
}
return $appRole
}
$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
$myActionGroupServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$azureMonitorActionGroupsAppId'"
Write-Host "App Roles before addition of new role.."
foreach ($role in $myAppRoles) { Write-Host $role.Value }
if ($myAppRoles.Value -contains $actionGroupRoleName)
{
Write-Host "The Action Group role is already defined. No need to redefine.`n"
# Retrieve the application again to get the updated roles
$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
}
else
{
Write-Host "The Action Group role is not defined. Defining the role and adding it."
$newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
$myAppRoles += $newRole
Update-MgApplication -ApplicationId $myApp.Id -AppRole $myAppRoles
# Retrieve the application again to get the updated roles
$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
}
$myServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($myApp.AppId)'"
if ($myActionGroupServicePrincipal.DisplayName -contains "AzNS AAD Webhook")
{
Write-Host "The Service principal is already defined.`n"
Write-Host "The action group Service Principal is: " + $myActionGroupServicePrincipal.DisplayName + " and the id is: " + $myActionGroupServicePrincipal.Id
}
else
{
Write-Host "The Service principal has NOT been defined/created in the tenant.`n"
$myActionGroupServicePrincipal = New-MgServicePrincipal -AppId $azureMonitorActionGroupsAppId
Write-Host "The Service Principal is been created successfully, and the id is: " + $myActionGroupServicePrincipal.Id
}
# Check if $myActionGroupServicePrincipal is not $null before trying to access its Id property
# Check if the role assignment already exists
$existingRoleAssignment = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id | Where-Object { $_.AppRoleId -eq $myApp.AppRoles[0].Id -and $_.PrincipalId -eq $myActionGroupServicePrincipal.Id -and $_.ResourceId -eq $myServicePrincipal.Id }
# If the role assignment does not exist, create it
if ($null -eq $existingRoleAssignment) {
Write-Host "Doing app role assignment to the new action group Service Principal`n"
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id -AppRoleId $myApp.AppRoles[0].Id -PrincipalId $myActionGroupServicePrincipal.Id -ResourceId $myServicePrincipal.Id
} else {
Write-Host "Skip assigning because the role already existed."
}
Write-Host "myServicePrincipalId: " $myServicePrincipal.Id
Write-Host "My Azure AD Application (ObjectId): " $myApp.Id
Write-Host "My Azure AD Application's Roles"
foreach ($role in $myAppRoles) { Write-Host $role.Value }
Write-Host "================================================================================================="
將 Runbook 動作從「執行身分帳戶」移轉至「以受控識別執行」
注意
Azure 自動化「執行身分帳戶」已於 2023 年 9 月 30 日淘汰,這會影響以動作類型「Automation Runbook」建立的動作。 淘汰之後,不支持連結至「執行身分帳戶」Runbook 的現有動作。 不過,這些 Runbook 會繼續執行,直到自動化帳戶的「執行身分」憑證到期為止。 若要確保可以繼續使用 Runbook 動作,您需要:
新增動作類型為「Automation Runbook」的新動作,然後從下拉式清單中選擇相同的 Runbook,以編輯動作群組。 (下拉式清單中的所有 5 個 Runbook 都已重新設定在後端,以使用受控識別進行驗證,而不是執行身分帳戶。自動化帳戶中系統指派的受控識別會使用訂用帳戶層級的 VM 參與者角色來啟用。)
刪除連結至「執行身分帳戶」Runbook 的舊 Runbook 動作。
儲存動作群組。
下一步
- 取得警示的概觀,並了解如何收到警示。
- 深入了解 ITSM 連接器。
- 深入了解活動記錄警示 Webhook 結構描述。