アクション グループ

Azure Monitor データがインフラストラクチャまたはアプリケーションで潜在的な問題を示すと、アラートがトリガーされます。 タイムリーな応答を確保するために、これらのアラート (通知設定と自動アクションのコレクション) にアクション グループをアタッチできます。

アクション グループは、通知を受け取るユーザーと、アラートが発生したときに実行されるアクションを定義します。 音声通話、SMS、プッシュ通知、電子メール、自動アクション (Webhook や Azure 関数のトリガーなど) など、複数の通知の種類がサポートされています。 これらのグループは、Azure Monitor、 Azure Service Health、 Azure Advisor などのサービス間で使用されます。

各アクションは、次で構成されます。

• 型: 通知または自動化の種類。
• 名前: アクション グループ内の一意識別子。
• 詳細: アクションの種類に基づく特定の構成。

この記事では、アクション グループを作成および管理する方法について説明します。

グローバルな可用性と回復性

クライアントからのグローバルな要求は、任意のリージョンのアクション グループ サービスで処理できます。 アクション グループ サービスの 1 つのリージョンがダウンした場合、トラフィックは自動的にルーティングされ、他のリージョンによって処理されます。 グローバル サービスとして、アクション グループは ディザスター リカバリー ソリューションの提供を支援します。

再利用性と実行

• 1 つのアラート ルールに最大 5 つのアクション グループを追加できます。
• アクション グループは、特定の順序はなく、同時に実行されます。
• 複数の警告ルールで同じアクション グループを使用できます。
• アクション グループは、一意のアクションセットと、通知を受けるユーザーによって定義されます。
  例： 2 つの異なるアラート ルールについて User1、User2、User3 に電子メールで通知するには、アクション グループを 1 つだけ作成し、両方のアラート ルールに適用する必要があります。

Azure portal でアクション グループを作成する

1. Azure ポータルにアクセスします。

2. [モニター] を検索して選択します。 [モニター] ウィンドウでは、すべての監視設定とデータが 1 つのビューにまとめられています。

3. [アラート] を選択し、[アクション グループ] を選択します。

   

4. 上部のアクション バーから [ 作成 ] を選択します。

5. 基本アクション グループ設定を構成します。 [プロジェクトの詳細] セクションで、次の手順を実行します。

   • [サブスクリプション] と [リソース グループ] の値を選択します。
   • リージョンを選択します。

   Note

   Service Health アラートは、グローバル リージョン内のパブリック クラウドでのみサポートされます。 アクション グループがサービス正常性アラートに応答して適切に機能するには、アクション グループのリージョンを グローバルに設定する必要があります。

   Option	Behavior
   Global	アクション グループ サービスは、アクション グループを格納する場所を決定します。 リージョンの回復性を確保するために、アクション グループは少なくとも 2 つのリージョンに保持されます。 アクションの処理は、任意の地理的リージョンで実行できます。 サービス正常性アラートの結果として実行される音声、SMS、電子メールのアクションは、Azure のライブ サイト インシデントに対して回復性があります。
   Regional	アクション グループは、選択したリージョン内に格納されます。 アクション グループはゾーン冗長です。 アクション グループの処理が確実に特定の地理的境界内で実行されるようにするには、このオプションを使用します。 アクション グループのリージョン処理には、次のいずれかのリージョンを選択できます。 • 米国東部 • 米国西部 • 米国東部 2 • 米国西部 2 • 米国中南部 • 米国中北部 • スウェーデン中部 • ドイツ中西部 • インド中部 • インド南部 アクション グループの地域データ処理のために、追加の地域を継続的に追加しています。

   アクション グループは、選択したサブスクリプション、リージョン、リソース グループに保存されます。

6. [インスタンスの詳細] セクションで、[アクション グループ名] と [表示名] の値を入力します。 表示名は、グループを使用して通知を送信するときに、完全なアクション グループ名の代わりに使用されます。

   

7. 通知を構成します。 [次へ: 通知] を選択するか、ページの上部にある [通知] タブを選択します。

8. アラートがトリガーされたときに送信する通知の一覧を定義します。

9. 通知ごとに次の手順を実行します。

   1. [通知の種類] を選択し、その通知の適切なフィールドに入力します。 使用可能なオプションは次のとおりです。

      通知の種類	Description	Fields
      Azure Resource Manager ロールへのメール	それぞれのロールに基づいて、サブスクリプション メンバーに電子メールを送信します。 電子メールを参照してください。	Microsoft Entra ユーザー用に構成されたプライマリ メール アドレスを入力します。 電子メールを参照してください。
      Email	メール フィルタリングとマルウェア/スパム防止サービスが適切に構成されていることを確認します。 電子メールは、次の電子メール アドレスから送信されます。 • azure-noreply@microsoft.com • azureemail-noreply@microsoft.com • alerts-noreply@mail.windowsazure.com	通知を送信するメール アドレスを入力します。
      SMS	SMS 通知では双方向通信がサポートされます。 SMS には、次の情報が含まれています。 • このアラートが送信されたアクション グループの短い名前 • アラートのタイトル。 ユーザーは、次のことを行うために SMS に応答できます。 •すべてのアクショングループまたは単一のアクショングループのすべてのSMSアラートから購読を解除します。 • アラートに再登録する • ヘルプを要求します。 サポートされている SMS の返信の詳細については、「SMS の返信」を参照してください。	SMS 受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、SMS は国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの SMS プロバイダーに Webhook を呼び出すようにアクション グループを構成します。
      Azure アプリのプッシュ通知	Azure モバイル アプリに通知を送信します。	[Azure アカウントの電子メール] フィールドに、Azure mobile app を構成するときにアカウント ID として使用するメール アドレスを入力します。
      Voice	音声通知。	通知の受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、音声通知はご利用の国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの音声通話プロバイダーに Webhook を呼び出すようにアクション グループを構成します。

   2. 共通アラート スキーマを有効にするかどうかを選択します。 共通アラート スキーマは、Azure Monitor のすべてのアラート サービスで使用できる、拡張可能で統合された単一のアラート ペイロードです。 共通スキーマの詳細については、「共通アラート スキーマ」を参照してください。

      

   3. [OK] を選択.

10. アクションを構成します。 [次へ: アクション] を選択します。 または、ページの上部にある [アクション] タブを選択します。

11. アラートがトリガーされたときにトリガーするアクションの一覧を定義します。 アクションの種類を選択し、各アクションの名前を入力します。

    アクションの種類	Details
    自動化運用手順書	Automation Runbook を使用して、メトリックに基づいてタスクを自動化します。 たとえば、関連付けられている予算の特定のしきい値が満たされたときにリソースをシャットダウンします。 Automation Runbook ペイロードの制限の詳細については、「Automation の制限」を参照してください。
    イベントハブ	Event Hubs アクションは、通知を Event Hubs に発行します。 これは、 Azure Private Link と ネットワーク セキュリティ境界 (NSP) をサポートする唯一のアクションの種類です。 Event Hubs の詳細については、「Azure Event Hubs - ビッグ データ ストリーミング プラットフォームとイベント インジェスト サービス」 を参照してください。 イベント受信者からアラート通知ストリームをサブスクライブできます。
    Functions	関数で既存の 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」を参照してください。

    

12. (省略可能)キーと値のペアをアクション グループに割り当てて Azure リソースを分類する場合は、[ 次へ: タグ ] タブまたは [ タグ ] タブを選択します。それ以外の場合は、この手順をスキップします。

13. [確認 + 作成] を選んで、設定を確認します。 この手順では、入力をすばやく確認して、必要なすべての情報を入力したことを確認します。 問題がある場合は、ここで報告されます。 設定を確認したら、[ 作成 ] を選択してアクション グループを作成します。

    Note

    電子メールまたは SMS でユーザーに通知するようアクションを構成すると、ユーザーは自分がアクション グループに追加されたことを示す確認メッセージを受け取ります。

Azureポータルでアクショングループをテストする。

Azure portal でアクション グループを作成または更新する場合、アクション グループを [テスト] できます。

1. Azure portal でアクション グループを作成します。

   Note

   アクション グループは、テスト前に作成して保存する必要があります。 既存のアクション グループを編集している場合、テストする前にアクション グループへの変更を保存してください。

2. [ アクション グループ ] ページで、アクション グループを選択し、上部のアクション バーから [テスト ] を選択します。

3. テストするサンプルの種類と、通知の種類とアクションの種類を選択します。 次に、[テスト] を選択します。

   

4. テストの実行中にウィンドウを閉じるか、[テスト設定に戻る] を選択すると、テストは停止し、テスト結果は表示されません。

   

5. テストが完了すると、成功または失敗のいずれかのテスト状態が表示されます。 テストが失敗し、詳細情報を取得する場合は、[詳細の表示] を選択ます。

   

   [エラーの詳細] セクションの情報を使用して問題を把握できます。 その後、アクション グループを編集し、変更を保存し、再度テストできます。

   テストを実行して通知の種類を選択すると、件名に 「Test」 というメッセージが表示されます。 テストは、運用環境でアクション グループを有効にする前に、アクション グループが期待どおりに動作することを確認する方法を提供します。 テスト用のメール通知に含まれるすべての詳細とリンクは、サンプル参照セットからのものです。

Azure アクション グループでマネージド ID を使用する (プレビュー)

Azure アクション グループでは、ダウンストリーム サービスを呼び出すときに、セキュリティで保護された資格情報のない認証のための マネージド ID が サポートされるようになりました。 この機能はプレビューで利用できるようになりました。

アクション グループで既存のマネージド ID を使用する

1. アクション グループ内の各アクションに対して、事前に指定された ID を使用するようにアクション グループを構成する。
2. 選択した ID に必要なロールが割り当てられていることを確認する
3. マネージド ID に、認証呼び出しのリソース (アクションの種類) へのアクセス権を付与します (詳細)。

サポートされているアクションの種類

現在、マネージド ID では次のアクションの種類がサポートされています。

テスト アクション グループのロール要件

次の表では、 テスト アクション 機能に必要なロール メンバーシップの要件について説明します。

¹ カスタム ロールには Microsoft.Insights/ActionGroups/* アクセス許可が追加されている必要があります。これにより、ユーザーはアクション グループを更新および削除することもできます。 ユーザーがアクション グループのみをテストできるように制限を追加するには、カスタム ロールの [JSON ] タブの下に次を追加します。

{
    "properties": {
        "roleName": "",
        "description": "",
        "assignableScopes": [
            "/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Insights/ActionGroups/*"
                ],
                "notActions": [
                    "Microsoft.Insights/ActionGroups/write",
                    "Microsoft.Insights/ActionGroups/delete"
                ],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Resource Manager テンプレートを使用したアクション グループの作成

Azure Resource Manager テンプレート を使用し、アクション グループを構成できます。 テンプレートを使用することで、特定の種類のアラートで再利用できるアクション グループを自動的に設定できます。 このようなアクション グループを使用することで、アラートがトリガーされたときに、すべての適切な関係者が通知を確実に受け取ることができます。

基本的な手順は次のとおりです。

1. アクション グループの作成方法が記述された JSON ファイルとしてテンプレートを作成します。
2. 任意のデプロイ方法を使用してテンプレートをデプロイします。

アクション グループの Resource Manager テンプレート

Resource Manager テンプレートを使用してアクション グループを作成するには、Microsoft.Insights/actionGroups 型のリソースを作成します。 次に、関連するすべてのプロパティを入力します。 次に、アクション グループを作成するサンプル テンプレートを 2 つ示します。

テンプレート 1

このテンプレートでは、アクション定義がテンプレートにハードコーディングされているアクション グループの Resource Manager テンプレートを作成する方法について説明します。

{
  "$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'))]"
      }
  }
}

テンプレート 2

このテンプレートでは、テンプレートのデプロイ時に 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."
      }
    },
    "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'))]"
      }
  }
}

アクション グループの管理

アクション グループを作成した後、ポータルで表示できます。

1. Azure ポータルにアクセスします。

2. [監視] ページで、[アラート] を選択します。

3. [アクション グループ] を選択します。

4. 管理するアクション グループを選択します。 次のようにすることができます。

   • アクションの追加、編集、または削除。
   • アクション グループの削除。

通知のサービス制限

電話番号またはメール アドレスを、多数のサブスクリプションのアクション グループに含めることができます。 Azure Monitor では、特定の電話番号、電子メール アドレス、またはデバイスに送信される通知が多すぎる場合に、レート制限を使用して通知を中断します。 レート制限によって、アラートを管理しやすくなりアクション可能な状態が保証されます。

レート制限は、SMS、音声、プッシュ、および電子メール通知に適用されます。 その他のすべての通知アクションは、レート制限を受けません。 レート制限はすべてのサブスクリプションに対して適用されます。 メッセージが複数のサブスクリプションから送信された場合であっても、しきい値に達するとただちにレート制限が適用されます。 メール アドレスがレート制限を受ける場合、レート制限が適用されたこと、およびレート制限の有効期限を伝える通知が送信されます。

レート制限の詳細については、「Azure Monitor サービスの制限」を参照してください。

Azure Resource Managerにメールを送信

メール通知に Azure Resource Manager を使用すると、サブスクリプションのロールのメンバーに電子メールを送信できます。 電子メールは、ロールの Microsoft Entra ID ユーザーまたはグループ メンバーに送信されます。 これには、Azure Lighthouse を介して割り当てられたロールのサポートが含まれます。

プライマリ メールに通知が届かない場合は、Email Azure Resource Manager ロールのメール アドレスを設定します。

1. Azure portal で、[Microsoft Entra ID] に移動します。

2. 左側のメニューで [ ユーザー ] を選択すると、すべてのユーザーの一覧が表示されます。

3. "メインの電子メール" を確認したいユーザーを選択します。

   

4. ユーザー プロファイルの [プロパティ] で、[ 連絡先情報] で 電子メール の値を確認します。 空白の場合:

   1. ページの上部にある [ プロパティの編集] を選択します。
   2. 電子メール アドレスを入力します。
   3. ページの最上部で [保存] を選択します。

   

アクショングループごに制限された数の電子メール アクションを保持できます。 ご自分の状況に適用される制限をチェックするには、「Azure Monitor サービスの制限」を参照してください。

Resource Manager の役割を設定する場合は、次のようになります。

• User または Group 型のエンティティをロールに割り当てます。
• サブスクリプション レベルで割り当てを行います。
• Microsoft Entra プロファイル でユーザーの電子メール アドレスが構成されていることを確認します。

SMS

アクショングループごに制限された数の SMS アクションを保持できます。

• レート制限の詳細については、「Azure Monitor サービスの制限」を参照してください。
• アクション グループでの SMS 通知の使用に関する重要な情報については、 Azure portal でのアクション グループの作成の手順 9 の表を参照してください。

SMS 応答

これらの返信は、SMS 通知でサポートされています。 SMS の受信者は、こちらの値を使用して SMS に返信できます。

アクショングループごに制限された数の Azure app アクションを保持できます。

SMS 通知がサポートされている国およびリージョン

Voice

アクショングループごとに音声アクションの数が制限されている可能性があります。 レート制限に関する重要な情報については、「Azure Monitor サービスの制限」を参照してください。

Voice 通知がサポートされている国およびリージョン

サポートされている国/地域の価格の詳細については、「Azure Monitor の価格」を参照してください。

Webhook

Webhook アクション グループでは通常、呼び出されたときに次の規則に従います。

• Webhook が呼び出されると、最初の呼び出しが失敗すると、少なくとも 1 回再試行され、さまざまな遅延間隔 (5、20、40 秒) で最大 5 回 (5 回再試行) されます。

  Attempts	Delay
  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 AAD Webhook Microsoft Entra アプリケーションの Microsoft Entra テナントのサービス プリンシパル インスタンスを使用して、保護された API に対して認証されます。 アクション グループを機能させるには、この Microsoft Entra Webhook サービス プリンシパルを、ターゲット エンドポイントへのアクセスを許可するターゲット Microsoft Entra アプリケーションのロールのメンバーとして追加する必要があります。

Microsoft Entra アプリケーションとサービス プリンシパルの概要については、Microsoft ID プラットフォーム (v2.0) の概要に関するページを参照してください。 次の手順に従って、セキュリティで保護された Webhook 機能を利用します。

Webhook アクションを使用する場合、ターゲット Webhook エンドポイントは、さまざまなアラート ソースが出力する、さまざまな JSON ペイロードを処理できる必要があります。 Webhook エンドポイントが特定のスキーマ (Microsoft Teams スキーマなど) を必要とする場合は、Logic Apps アクションを使用して、ターゲット Webhook の想定に合わせてアラート スキーマを変換する必要があります。

1. 保護された Web API 用の Microsoft Entra アプリケーションを作成します。 詳細については、「保護された Web API: アプリの登録」 を参照してください。 デーモン アプリによって呼び出されるように保護された API を構成し、委任されたアクセス許可ではなく、アプリケーションのアクセス許可を公開します。

   Tip

   V2.0 アクセス・トークンを受け入れるように保護された Web API を構成します。 この設定の詳細については、「Microsoft Entra アプリ マニフェスト」を 参照してください。

2. アクション グループが Microsoft Entra アプリケーションを使用できるようにするには、次の手順にフォローする PowerShell スクリプトを使用します。

   Note

   • このスクリプトを実行するには、Microsoft Entra アプリケーション管理者ロールが割り当てられている必要があります。

   • アクション グループでセキュリティで保護された Webhook アクションを作成、変更、またはテストできるようにするには、サービス プリンシパルに Microsoft Entra アプリケーションの 所有者ロール を割り当てる必要があります。

3. セキュリティで保護された Webhook アクションを構成します。

   1. スクリプト内の $myApp.ObjectId 値をコピーします。
   2. Webhook アクション定義の [オブジェクト ID] ボックスに、コピーした値を入力します。

   

Secure Webhook PowerShell スクリプト

実行方法

1. 次のスクリプトをコピーしてコンピューターに貼り付けます。
2. アプリ登録であなたのtenantIdとObjectIDを置き換えてください。
3. *.ps1 として保存
4. コンピューターから 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 アクションを "アカウントとして実行" から "マネージド ID として実行" に移行する

Runbook アクションの使用を継続できるようにするには、以下を行う必要があります。

1. アクションの種類 が Automation Runbook の新しいアクションを追加してアクション グループを編集し、ドロップダウンから同じ Runbook を選択します。

   Note

   ドロップダウンの 5 つの Runbook はすべて、実行アカウントではなくマネージド ID を使用して認証するようにバックエンドで再構成されています。 Automation アカウントでシステム割り当てのマネージド ID が有効化されると、サブスクリプション レベルで VM 共同作成者のロールが自動的に割り当てられます。

   

   

2. "実行アカウント" の Runbook にリンクされている古い Runbook アクションを削除します。

3. アクション グループを保存します。

次のステップ

• アラートの概要を把握し、アラートを受信する方法について学習します。
• ITSM Connector について学習します。
• アクティビティ ログ アラート webhook スキーマについて学習します。