작업 그룹

Azure Monitor 데이터가 인프라 또는 애플리케이션에 문제가 있을 수 있음을 나타내면 경고가 트리거됩니다. 경고 자체 외에도 경고가 트리거될 때 작업 그룹을 사용하여 음성 통화, SMS 또는 전자 메일과 같은 알림을 보낼 수 있습니다. 작업 그룹은 알림 기본 설정 및 작업의 컬렉션입니다. Azure Monitor, Azure Service Health, Azure Advisor는 작업 그룹을 사용하여 사용자에게 경고에 대해 알리고 작업을 수행합니다. 이 문서에서는 작업 그룹을 만들고 관리하는 방법을 보여 줍니다.

각 작업은 다음으로 구성됩니다.

• 형식: 전송된 알림 또는 수행된 작업입니다. 예를 들어 음성 통화, SMS 또는 이메일 보내기가 있습니다. 다양한 형식의 자동화된 작업을 트리거할 수도 있습니다.
• 이름: 작업 그룹 내의 고유 식별자입니다.
• 세부 정보: 유형에 따라 달라지는 해당 세부 정보입니다.

일반적으로 작업 그룹은 전역 서비스입니다. 지역적으로 더 많이 사용할 수 있도록 하기 위한 노력이 진행 중입니다.

클라이언트의 전역 요청은 모든 지역의 작업 그룹 서비스에서 처리할 수 있습니다. 작업 그룹 서비스의 한 지역이 다운되면 트래픽이 자동으로 라우팅되고 다른 지역에서 처리됩니다. 글로벌 서비스로서 작업 그룹은 재해 복구 솔루션을 제공하는 데 도움을 줍니다. 지역별 요청은 가용성 영역 중복에 의존하여 개인 정보 보호 요구 사항을 충족하고 유사한 재해 복구 솔루션을 제공합니다.

• 경고 규칙에는 최대 5개의 작업 그룹을 추가할 수 있습니다.
• 작업 그룹은 특정 순서 없이 동시에 실행됩니다.
• 여러 경고 규칙에서 동일한 작업 그룹을 사용할 수 있습니다.
• 작업 그룹은 고유한 작업 집합과 알림을 받을 사용자로 정의됩니다. 예를 들어, User1, User2 및 User3에게 두 개의 서로 다른 경고 규칙에 대해 이메일로 알리려면 두 경고 규칙 모두에 적용할 수 있는 작업 그룹을 하나만 만들면 됩니다.

Azure Portal에서 작업 그룹 만들기

1. Azure Portal로 이동합니다.

2. 모니터를 검색하고 선택합니다. 모니터 창은 모든 모니터링 설정과 데이터를 하나의 보기로 통합합니다.

3. 경고를 선택한 다음 작업 그룹을 선택합니다.

   

4. 만들기를 실행합니다.

   

5. 기본 작업 그룹 설정을 구성합니다. 프로젝트 세부 정보 섹션에서 다음을 수행합니다.

   • 구독 및 리소스 그룹 값을 선택합니다.
   • 지역을 선택합니다.

   참고 항목

   Service Health 경고는 글로벌 지역 내의 퍼블릭 클라우드에서만 지원됩니다. Service Health 경고에 대한 응답으로 작업 그룹이 제대로 작동하려면 작업 그룹의 지역을 "글로벌"로 설정해야 합니다.

   옵션	동작
   전역	작업 그룹 서비스는 작업 그룹을 저장할 위치를 결정합니다. 작업 그룹은 지역 복원력을 보장하기 위해 두 개 이상의 지역에 유지됩니다. 작업 처리는 모든 지역에서 수행할 수 있습니다. 서비스 상태 경고의 결과로 수행되는 음성, SMS 및 이메일 작업은 Azure 라이브 사이트 인시던트에 탄력적입니다.
   지역	작업 그룹은 선택한 영역에 저장됩니다. 작업 그룹은 영역 중복입니다. 작업 그룹이 특정 지리적 경계 내에서 처리되도록 하려면 이 옵션을 사용합니다. 작업 그룹의 지역 처리를 위해 다음 지역 중 하나를 선택할 수 있습니다. - 미국 동부 - 미국 서부 - 미국 동부2 - 미국 서부2 - 미국 중남부 - 미국 중북부 - 스웨덴 중부 - 독일 중서부 - 인도 중부 - 인도 남부 작업 그룹의 지역 데이터 처리를 위한 지역을 지속적으로 추가하고 있습니다.

   작업 그룹은 선택한 구독, 지역 및 리소스 그룹에 저장됩니다.

6. 인스턴스 세부 정보 섹션에서 작업 그룹 이름 및 표시 이름 값을 입력합니다. 그룹이 알림을 보내는 데 사용될 때 전체 작업 그룹 이름 대신 표시 이름이 사용됩니다.

   

7. 알림 구성 다음: 알림을 선택하거나 페이지 맨 위에 있는 알림 탭을 선택합니다.

8. 경고가 트리거될 때 보낼 알림 목록을 정의합니다.

9. 각 알림에 대해 다음을 수행합니다.

   1. 알림 유형을 선택한 다음, 해당 알림에 대한 적절한 필드를 입력합니다. 사용 가능한 옵션은 다음과 같습니다.

      알림 유형	설명	필드
      이메일 Azure Resource Manager 역할	구성원의 역할에 따라 구독 구성원에게 이메일을 보냅니다. 이메일을 참조하세요.	Microsoft Entra 사용자에 대해 구성된 기본 이메일 주소를 입력합니다. 이메일을 참조하세요.
      메일	이메일 필터링 및 맬웨어/스팸 방지 서비스가 적절하게 구성되었는지 확인합니다. 이메일은 다음 이메일 주소에서 전송됩니다. : : :	알림을 보낼 이메일을 입력합니다.
      SMS	SMS 알림은 양방향 통신을 지원합니다. SMS에는 다음 정보가 포함됩니다. * 이 경고가 전달된 작업 그룹의 짧은 이름 * 알림의 제목 사용자는 SMS에 응답하여 다음을 수행할 수 있습니다. * 모든 작업 그룹 또는 단일 작업 그룹에 대한 모든 SMS 경고를 구독 취소합니다. * 경고 재구독 * 도움 요청 지원되는 SMS 회신에 대한 자세한 내용은 SMS 회신을 참조하세요.	SMS 수신자의 국가 번호와 전화 번호를 입력합니다. Azure Portal에서 국가/지역 코드를 선택할 수 없는 경우 해당 국가/지역에서 SMS가 지원되지 않습니다. 국가/지역 코드를 사용할 수 없는 경우 아이디어 공유에서 국가/지역을 추가하도록 투표할 수 있습니다. 해당 국가가 지원될 때까지의 해결 방법으로 해당 국가/지역을 지원하는 타사 SMS 공급자에 대한 웹후크를 호출하도록 작업 그룹을 구성합니다.
      Azure 앱 푸시 알림	Azure 모바일 앱에 알림을 보냅니다. Azure 모바일 앱에 대한 푸시 알림을 사용하도록 설정하려면 Azure 모바일 앱에 대한 자세한 내용은 Azure 모바일 앱을 참조하세요.	Azure 계정 이메일 필드에 Azure 모바일 앱을 구성할 때 계정 ID로 사용하는 이메일 주소를 입력합니다.
      음성	음성 알림입니다.	알림 수신자의 국가 번호와 전화 번호를 입력합니다. Azure Portal에서 국가/지역 코드를 선택할 수 없는 경우 해당 국가/지역에 대해 음성 알림이 지원되지 않는 것입니다. 국가/지역 코드를 사용할 수 없는 경우 아이디어 공유에서 국가/지역을 추가하도록 투표할 수 있습니다. 해당 국가가 지원될 때까지의 해결 방법으로 해당 국가/지역을 지원하는 타사 음성 통화 공급자에게 웹후크를 호출하도록 작업 그룹을 구성합니다.

   2. 일반 경고 스키마를 사용하도록 설정할지 선택합니다. 일반 경고 스키마는 Azure Monitor의 모든 경고 서비스에서 사용할 수 있는 확장 가능하고 통합된 단일 경고 페이로드입니다. 공통 스키마에 대한 자세한 내용은 공통 경고 스키마를 참조하세요.

      

   3. 확인을 선택합니다.

10. 작업을 구성합니다. 다음: 작업을 선택합니다. 또는 페이지 맨 위에 있는 작업 탭을 선택합니다.

11. 경고가 트리거될 때 트리거할 작업 목록을 정의합니다. 작업 유형을 선택하고 각 작업의 이름을 입력합니다.

    동작 유형	세부 정보
    자동화 Runbook	Automation Runbook을 사용하여 메트릭을 기준으로 작업을 자동화합니다. 예를 들어 관련 예산의 특정 임계값이 충족되면 리소스를 종료합니다. 자동화 Runbook 페이로드 제한에 대한 자세한 내용은 자동화 제한을 참조하세요.
    Event Hubs	Event Hubs 작업은 Event Hubs에 알림을 게시합니다. Event Hubs에 대한 자세한 내용은 Azure Event Hubs - 빅 데이터 스트리밍 플랫폼 및 이벤트 수집 서비스를 참조하세요. 이벤트 수신기에서 경고 알림 스트림을 구독할 수 있습니다.
    함수	함수에서 기존 HTTP 트리거 엔드포인트를 호출합니다. 자세한 내용은 Azure Functions를 참조하세요. 함수 작업을 정의하면 함수의 HTTP 트리거 엔드포인트와 액세스 키가 작업 정의에 저장됩니다(예: https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>). 함수에 대한 액세스 키를 변경하는 경우 작업 그룹에서 함수 동작을 제거하고 다시 만들어야 합니다. 엔드포인트는 HTTP POST 메서드를 지원해야 합니다. 함수에는 스토리지 계정에 대한 액세스 권한이 있어야 합니다. 액세스 권한이 없으면 키를 사용할 수 없으며 함수 URI에 액세스할 수 없습니다. 스토리지 계정에 대한 액세스 복원에 대해 알아봅니다.
    ITSM	ITSM 작업에는 ITSM 연결이 필요합니다. ITSM 연결을 만드는 방법을 알아보려면 ITSM 통합을 참조하세요.
    논리 앱	Azure Logic Apps를 사용하여 통합을 위한 워크플로를 빌드 및 사용자 지정하고 경고 알림을 사용자 지정할 수 있습니다.
    보안 웹후크	보안 웹후크 작업을 사용하는 경우 Microsoft Entra ID를 사용하여 작업 그룹과 보호된 웹 API인 엔드포인트 간의 연결을 보호해야 합니다. 보안 웹후크에 대한 인증 구성을 참조하세요. 보안 웹후크는 기본 인증을 지원하지 않습니다. 기본 인증을 사용하는 경우 웹후크 작업을 사용합니다.
    웹후크	웹후크 작업을 사용하는 경우 대상 웹후크 엔드포인트는 다른 경고 원본에서 내보내는 다양한 JSON 페이로드를 처리할 수 있어야 합니다. 웹후크 작업을 통해 보안 인증서를 전달할 수 없습니다. 기본 인증을 사용하려면 URI를 통해 자격 증명을 전달해야 합니다. 웹후크 엔드포인트에 특정 스키마(예: Microsoft Teams 스키마)가 필요한 경우 Logic Apps 작업 유형을 사용하여 경고 스키마를 조작해 대상 웹후크의 필요를 충족합니다. 웹후크 작업 다시 시도에 사용되는 규칙에 대한 자세한 내용은 웹후크를 참조하세요.

    

12. 선택 사항입니다. 작업 그룹에 키-값 쌍을 할당하여 Azure 리소스를 분류하려면 다음: 태그 또는 태그 탭을 선택합니다. 그렇지 않은 경우, 이 단계를 건너뜁니다.

    

13. 검토 + 만들기를 선택하여 설정을 검토합니다. 이 단계에서는 입력을 빠르게 확인하여 필요한 모든 정보를 입력했는지 확인합니다. 문제가 있는 경우 여기에 보고됩니다. 설정을 검토한 후 만들기를 선택하여 작업 그룹을 만듭니다.

    

    참고 항목

    이메일 또는 SMS로 사람에게 알리도록 작업을 구성하면 작업 그룹에 추가되었음을 나타내는 확인 메시지가 수신됩니다.

Azure Portal에서 작업 그룹 테스트

Azure Portal에서 작업 그룹을 만들거나 업데이트할 때 작업 그룹을 테스트할 수 있습니다.

1. Azure Portal에서 작업 그룹을 만듭니다.

   참고 항목

   테스트하기 전에 작업 그룹을 만들고 저장해야 합니다. 기존 작업 그룹을 편집하는 경우 테스트하기 전에 변경 내용을 작업 그룹에 저장합니다.

2. 작업 그룹 페이지에서 테스트 작업 그룹을 선택합니다.

   

3. 테스트할 샘플 형식과 알림 및 작업 형식을 선택합니다. 그런 다음 테스트를 선택합니다.

   

4. 테스트를 실행하는 동안 창을 닫거나 테스트 설정 뒤로를 선택하면 테스트가 중지되고 테스트 결과가 표시되지 않습니다.

   

5. 테스트가 완료되면 성공 또는 실패 테스트 상태가 나타납니다. 테스트에 실패한 경우 자세한 정보를 보려면 세부 정보 보기를 선택합니다.

   

   오류 세부 정보 섹션의 정보를 사용하여 문제를 이해할 수 있습니다. 그런 다음 작업 그룹을 편집하고 변경 내용을 저장하고 다시 테스트할 수 있습니다.

   테스트를 실행하고 알림 형식을 선택하면 제목에 "테스트"라는 메시지가 표시됩니다. 테스트는 프로덕션 환경에서 사용하도록 설정하기 전에 작업 그룹이 예상대로 작동하는지 확인하는 방법을 제공합니다. 테스트 이메일 알림의 모든 세부 정보와 링크는 샘플 참조 집합에서 가져왔습니다.

테스트 작업 그룹에 대한 역할 요구 사항

다음 표에서는 테스트 작업 기능에 필요한 역할 멤버 자격 요구 사항을 설명합니다.

¹ 사용자 지정 역할에는 Microsoft.Insights/createNotifications/* 권한이 있어야 합니다.

리소스 관리자 템플릿을 사용하여 작업 그룹 만들기

Azure Resource Manager 템플릿을 사용하여 작업 그룹을 구성할 수 있습니다. 템플릿을 사용하면 특정 유형의 경고에서 다시 사용할 수 있는 작업 그룹을 자동으로 설정할 수 있습니다. 이러한 작업 그룹은 경고가 트리거될 때 올바른 당사자가 모두 알림을 받을 수 있도록 합니다.

기본 단계는 다음과 같습니다.

1. 작업 그룹을 만드는 방법을 설명하는 JSON 파일로 템플릿을 만듭니다.
2. 배포 방법을 사용하여 템플릿을 배포합니다.

작업 그룹 Resource Manager 템플릿

리소스 관리자 템플릿을 사용하여 작업 그룹을 만들려면 Microsoft.Insights/actionGroups 종류의 리소스를 만듭니다. 그런 다음 모든 관련된 속성을 입력합니다. 다음은 작업 그룹을 만드는 두 가지 예제 템플릿입니다.

첫 번째 템플릿은 작업 정의가 템플릿에 하드 코딩된 작업 그룹에 대한 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'))]"
      }
  }
}

{
  "$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 Portal로 이동합니다.

2. 모니터 페이지에서 경고를 선택합니다.

3. 작업 그룹을 선택합니다.

4. 관리할 작업 그룹을 선택합니다. 마케팅 목록의 구성원을 관리할 수 있습니다.

   • 작업을 추가, 편집 또는 제거합니다.
   • 작업 그룹을 삭제합니다.

알림에 대한 서비스 제한

전화 번호 또는 메일은 많은 구독에서 작업 그룹에 속할 수 있습니다. Azure Monitor는 특정 전화 번호, 메일 주소 또는 디바이스에 너무 많은 알림이 전송되는 경우 속도 제한을 사용하여 알림을 일시 중단합니다. 속도를 제한하면 경고를 관리하고 실행할 수 있게 됩니다.

속도 제한은 SMS, 음성 및 메일 알림에 적용됩니다. 다른 모든 알림 작업은 속도가 제한되지 않습니다. 속도 제한은 모든 구독에 걸쳐 적용됩니다. 여러 구독에서 메시지가 전송되는 경우에도 임계값에 도달하면 속도 제한이 즉시 적용됩니다. 메일 주소의 속도가 제한되면 속도 제한이 적용되었다는 사실과 속도 제한이 만료되는 시점을 알리는 알림이 전송됩니다.

속도 제한에 대한 내용은 Azure Monitor 서비스 제한을 참조하세요.

메일 Azure Resource Manager

메일 알림을 위해 Azure Resource Manager를 사용하는 경우 구독 역할의 멤버에게 메일을 보낼 수 있습니다. 이메일은 역할의 Microsoft Entra ID 사용자 또는 그룹 멤버에게만 전송됩니다. 여기에는 Azure Lighthouse를 통해 할당된 역할에 대한 지원이 포함됩니다.

기본 메일 주소로 알림을 받지 못하는 경우 메일 Azure Resource Manager 역할에 대한 메일 주소를 구성합니다.

1. Azure Portal에서 Microsoft Entra ID로 이동합니다.

2. 왼쪽에서 모든 사용자를 선택합니다. 오른쪽에 사용자 목록이 나타납니다.

3. 검토하려는 기본 이메일의 사용자를 선택합니다.

   

4. 사용자 프로필의 연락처 정보에서 이메일 값을 찾습니다. 비어 있는 경우:

   1. 페이지 상단에서 편집을 선택합니다.
   2. 전자 메일 주소를 입력합니다.
   3. 페이지 맨 위에서 저장을 선택합니다.

   

작업 그룹당 제한된 수의 이메일 작업이 있을 수 있습니다. 상황에 적용되는 제한을 확인하려면 Azure Monitor 서비스 제한을 참조하세요.

Resource Manager 역할을 설정할 때:

1. 사용자 또는 그룹 형식의 엔터티를 역할에 할당합니다.
2. 구독 수준에서 할당합니다.
3. 사용자의 프로필에서 메일 주소가 구성되어 있는지 확인합니다.

• 사용자가 이 알림을 만들 수 있는 올바른 권한을 가진 위 역할 멤버 자격의 멤버 자격이 아닌 경우 작업 그룹을 테스트하는 데 필요한 최소 권한은 "Microsoft.Insights/createNotifications/*"입니다.
• 기간당 제한된 수의 테스트를 실행할 수 있습니다. 상황에 적용되는 제한을 확인하려면 Azure Monitor 서비스 제한을 참조하세요.
• 포털에서 작업 그룹을 구성할 때 공통 경고 스키마를 옵트인하거나 옵트 아웃할 수 있습니다.
  • 모든 샘플 형식에 대한 공통 스키마 샘플을 찾으려면 테스트 작업 그룹에 대한 공통 경고 스키마 정의를 참조하세요.
  • 일반적이지 않은 스키마 경고 정의를 찾으려면 테스트 작업 그룹에 대한 일반적이지 않은 경고 스키마 정의를 참조하세요.

SMS

작업 그룹당 제한된 수의 SMS 작업이 있을 수 있습니다.

• 속도 제한에 대한 내용은 Azure Monitor 서비스 제한을 참조하세요.
• 작업 그룹에서 SMS 알림 사용에 대한 중요한 정보는 작업 그룹에서 SMS 경고 동작을 참조하세요.

SMS 회신

이러한 회신은 SMS 알림에 대해 지원됩니다. SMS 받는 사람은 다음 값으로 SMS에 회신할 수 있습니다.

SMS 알림 지원 국가/지역

음성

작업 그룹당 제한된 수의 음성 작업이 있을 수 있습니다. 속도 제한에 대한 중요한 정보는 Azure Monitor 서비스 제한을 참조하세요.

음성 알림 지원 국가/지역

지원되는 국가/지역의 가격 책정에 대한 자세한 내용은 Azure Monitor 가격 책정을 참조하세요.

웹후크

• 웹후크가 호출될 때 첫 번째 호출이 실패하면 다양한 지연 간격(5초, 20초, 40초)에서 최소 1회 이상, 최대 5회(5회 다시 시도) 다시 시도합니다.
  • 1번째 시도와 2번째 시도 사이의 대기 시간은 5초입니다.
  • 2번째 시도와 3번째 시도 사이의 대기 시간은 20초입니다.
  • 3번째 시도와 4번째 시도 사이의 대기 시간은 5초입니다.
  • 4번째와 5번째 시도 사이의 대기 시간은 40초입니다.
  • 5번째와 6번째 시도 사이의 대기 시간은 5초입니다.
• 웹후크 호출 다시 시도가 실패한 후 15분 동안 엔드포인트를 호출하는 작업 그룹이 없습니다.
• 재시도 논리는 호출을 다시 시도할 수 있다고 가정합니다. 상태 코드: 408, 429, 503, 504 또는 HttpRequestException, WebException, TaskCancellationException은 호출을 다시 시도하도록 허용합니다."

보안 웹후크에 대한 인증 구성

보안 웹후크 작업은 "AZNS Microsoft Entra Webhook" Microsoft Entra 애플리케이션의 Microsoft Entra 테넌트에서 서비스 주체 인스턴스를 사용하여 보호된 API에서 인증을 받습니다. 작업 그룹이 작동하도록 하려면 이 Microsoft Entra Webhook 서비스 주체를 대상 엔드포인트에 대한 액세스 권한을 부여하는 대상 Microsoft Entra 애플리케이션의 역할 멤버로 추가해야 합니다.

Microsoft Entra 애플리케이션 및 서비스 주체에 대한 개요는 Microsoft ID 플랫폼(v2.0) 개요를 참조하세요. 보안 웹후크 기능을 활용하려면 다음 단계를 따릅니다.

1. 보호된 웹 API에 대한 Microsoft Entra 애플리케이션을 만듭니다. 자세한 내용은 보호된 웹 API: 앱 등록을 참조하세요. 디먼 앱에서 호출하도록 보호된 API를 구성하고 위임된 권한이 아닌 애플리케이션 권한을 노출합니다. 이러한 권한에 대한 자세한 내용은 웹 API가 서비스 또는 디먼 앱에서 호출되는 경우를 참조하세요.

   참고 항목

   V2.0 액세스 토큰을 허용하도록 보호된 웹 API를 구성합니다. 이 설정에 대한 자세한 내용은 Microsoft Entra 앱 매니페스트를 참조하세요.

2. 작업 그룹이 Microsoft Entra 애플리케이션을 사용할 수 있도록 하려면 이 프로시저를 따르는 PowerShell 스크립트를 사용합니다.

   참고 항목

   이 스크립트를 실행하려면 Microsoft Entra 애플리케이션 관리자 역할을 할당받아야 합니다.

   1. Microsoft Entra 테넌트 ID를 사용하도록 PowerShell 스크립트의 Connect-AzureAD 호출을 수정합니다.
   2. Microsoft Entra 애플리케이션의 개체 ID를 사용하도록 PowerShell 스크립트의 $myAzureADApplicationObjectId 변수를 수정합니다.
   3. 수정된 스크립트를 실행합니다.

   참고 항목

   작업 그룹에서 보안 웹후크 작업을 만들거나 수정할 수 있으려면 서비스 주체에게 Microsoft Entra 애플리케이션의 소유자 역할을 할당해야 합니다.

3. 보안 웹후크 작업을 구성합니다.

   1. 스크립트에 있는 $myApp.ObjectId 값을 복사합니다.
   2. 웹후크 작업 정의의 개체 ID 상자에 복사한 값을 입력합니다.

   

보안 웹후크 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"로 마이그레이션

1. 작업 유형이 "Automation Runbook"인 새 작업을 추가하여 작업 그룹을 편집하고 드롭다운에서 동일한 Runbook을 선택합니다. (드롭다운의 5개 Runbook은 모두 실행 계정 대신, 관리 ID를 사용하여 인증하도록 백 엔드에서 다시 구성되었습니다. 구독 수준에서 VM 기여자 역할이 자동으로 할당되면서 Automation 계정의 시스템 할당 관리 ID가 사용하도록 설정됩니다.)

   

   

2. "실행 계정" Runbook에 연결되는 이전 Runbook 작업을 삭제합니다.

3. 작업 그룹을 저장합니다.

다음 단계

• 경고의 개요를 확인하고 경고를 받는 방법에 대해 알아보세요.
• ITSM 커넥터에 대해 자세히 알아봅니다.
• 활동 로그 경고 웹후크 스키마에 대해 알아봅니다.