Gruppi di azioni

Quando i dati di Monitoraggio di Azure indicano che potrebbe verificarsi un problema con l'infrastruttura o l'applicazione, viene attivato un avviso. Un gruppo di azioni consente di inviare una notifica, ad esempio una chiamata vocale, un SMS o un e-mail, quando l'avviso viene attivato oltre all'avviso stesso. I gruppi di azioni sono una raccolta di preferenze e azioni di notifica. Monitoraggio di Azure, integrità dei servizi di Azure e Azure Advisor usano i gruppi di azioni per notificare agli utenti l'avviso ed eseguire un'azione. Questo articolo illustra come creare e gestire gruppi di azioni.

Ogni azione è costituita da:

• Tipo: Notifica inviata o azione eseguita. Ad esempio, l'invio di una chiamata vocale, un SMS o un messaggio di posta elettronica. Puoi anche attivare vari tipi di azioni automatizzate.
• Nome: un identificatore univoco all'interno del gruppo di azione.
• Dettagli: Dettagli corrispondenti che variano in base al tipo.

In generale, un gruppo di azioni è un servizio globale. L’impegno per renderli più disponibili a livello di area è in fase di sviluppo.

Le richieste globali dai client possono essere elaborate dai servizi del gruppo di azioni in qualsiasi area. Se un'area del servizio del gruppo di azioni è inattiva, il traffico viene indirizzato ed elaborato automaticamente in altre aree. Come servizio globale, un gruppo di azioni consente di fornire una soluzione di ripristino di emergenza. Le richieste a livello di area si basano sulla ridondanza della zona di disponibilità per soddisfare i requisiti di privacy e offrono una soluzione di ripristino di emergenza simile.

• Puoi aggiungere fino a cinque gruppi di azioni a una regola di avviso.
• I gruppi di azioni vengono eseguiti simultaneamente, senza un ordine specifico.
• Più regole di avviso possono usare lo stesso gruppo di azioni.
• I gruppi di azioni sono definiti dal set univoco di azioni e dagli utenti che devono ricevere una notifica. Ad esempio, se si vuole inviare tramite e-mail una notifica a User1, User2 e User3, per due regole di avviso diverse, è sufficiente creare un gruppo di azioni applicabile a entrambe le regole di avviso.

Creare un gruppo di azioni nel portale di Azure

1. Vai al portale di Azure.

2. Cercare e selezionare Monitoraggio. Il riquadro Monitoraggio consolida tutte le impostazioni e i dati di monitoraggio in una vista.

3. Selezionare Avvisi, quindi selezionare gruppi di azioni.

   

4. Seleziona Crea.

   

5. Configurare le impostazioni di base del gruppo di azioni. Nella sezione Dettagli progetto:

   • Selezionare i valori per Sottoscrizione e Gruppodi risorse.
   • Seleziona l'area.

   Nota

   Gli avvisi di integrità dei servizi sono supportati solo nei cloud pubblici all'interno dell'area globale. Affinché i gruppi di azioni funzionino correttamente in risposta a un avviso di integrità dei servizi, l'area del gruppo di azioni deve essere impostata come "Globale".

   Opzione	Comportamento
   Generale	Il servizio gruppi di azioni decide dove archiviare il gruppo di azioni. Il gruppo di azioni viene mantenuto in almeno due aree per garantire la resilienza a livello di area. L'elaborazione delle azioni può essere eseguita in qualsiasi area geografica. Le azioni voce, SMS e posta elettronica eseguite come risultato degli avvisi di integrità dei servizi sono resilienti agli incidenti del sito attivo di Azure.
   Regional	Il gruppo di azioni viene archiviato all'interno dell'area selezionata. Gruppo di azioni con ridondanza della zona. Usa questa opzione se vuoi assicurarti che l'elaborazione del gruppo di azioni venga eseguita all'interno di un limite geografico specifico. È possibile selezionare una di queste aree per l'elaborazione dei gruppi di azioni a livello di area: - Stati Uniti orientali - Stati Uniti occidentali - Stati Uniti orientali 2 - Stati Uniti occidentali 2 - Stati Uniti centro-meridionali - Stati Uniti centro-settentrionali - Svezia centrale - Germania centro-occidentale - India centrale - India meridionale Vengono aggiunte continuamente altre aree per l'elaborazione dei dati dei gruppi di azioni a livello di area.

   Il gruppo di azioni viene salvato nella sottoscrizione, nell'area e nel gruppo di risorse selezionati.

6. Nella sezione Dettagli istanza, immetti i valori per Nome gruppo di azioni e Nome visualizzato. Il nome visualizzato viene usato al posto di un nome completo del gruppo di azioni quando il gruppo viene usato per inviare notifiche.

   

7. Configurare le notifiche. Selezionare Avanti: Notificheoppure selezionare la scheda Notifiche nella parte superiore della pagina.

8. Definisci un elenco di notifiche da inviare quando viene attivato un avviso.

9. Per ogni notifica:

   1. Selezionare il tipo di notifica e quindi compilare gli appositi campi per tale notifica. Le opzioni disponibili sono:

      Tipo di notifica	Descrizione	Campi
      Invia un messaggio di posta elettronica al ruolo di Azure Resource Manager	Invia un messaggio di posta elettronica ai membri dell’abbonamento in base al ruolo. Vedi E-mail.	Immetti l'indirizzo e-mail principale configurato per l'utente di Microsoft Entra. Vedi E-mail.
      Indirizzo e-mail	Assicurati che i filtri di posta elettronica e i servizi di prevenzione malware/posta indesiderata siano configurati in modo appropriato. I messaggi di posta elettronica vengono inviati dagli indirizzi di posta elettronica seguenti: * azure-noreply@microsoft.com * azureemail-noreply@microsoft.com * alerts-noreply@mail.windowsazure.com	Immetti l’e-mail a cui deve essere inviata la notifica.
      SMS	Le notifiche SMS supportano la comunicazione bidirezionale. L'SMS Contiene le informazioni seguenti: * Nome breve del gruppo di azioni a cui è stato inviato l'avviso * Titolo dell'avviso. L’utente può rispondere a un SMS per: * Annullare la sottoscrizione a tutti gli avvisi SMS per tutti i gruppi di azioni o per un singolo gruppo di azioni. * Ripetere la sottoscrizione agli avvisi * Richiedere assistenza. Per altre informazioni sulle risposte SMS supportate, vedi Risposte SMS.	Immetti il codice paese e il numero di telefono del destinatario dell’SMS. Se non puoi selezionare il codice paese/area geografica nel portale di Azure, l'SMS non è supportato per il paese o l'area geografica. Se il codice paese/area geografica non è disponibile, puoi votare in Condividi le tue idee perché il tuo paese o area geografica venga aggiunto. Come soluzione alternativa fino a quando il tuo paese non sarà supportato, configura il gruppo di azioni per chiamare un webhook in un provider SMS di terze parti che supporta il paese o l'area geografica.
      Notifiche push dell'app Azure	Invia notifiche all'app per dispositivi mobili di Azure. Per abilitare le notifiche push sull'app per dispositivi mobili di Azure, inserisci Per altre informazioni sull'app per dispositivi mobili di Azure, vedi App per dispositivi mobili di Azure.	Nel campo e-mail dell'account Azure, immetti l'indirizzo e-mail usato come ID account quando configuri l'app per dispositivi mobili di Azure.
      Voce	Notifica vocale.	Immetti il codice paese e il numero di telefono del destinatario della notifica. Se non puoi selezionare il codice paese/area geografica nel portale di Azure, le notifiche vocali non sono supportate per il paese o l'area geografica. Se il codice paese/area geografica non è disponibile, puoi votare in Condividi le tue idee perché il tuo paese o area geografica venga aggiunto. Come soluzione alternativa fino a quando il tuo paese non sarà supportato, configura il gruppo di azioni per chiamare un webhook in un provider chiamate vocali di terze parti che supporta il paese o l'area geografica.

   2. Selezionare se si vuole abilitare lo schema di avviso comune. Lo schema di avviso comune è un singolo payload di avviso estendibile e unificato che può essere usato in tutti i servizi di avviso in Monitoraggio di Azure. Per altre informazioni sullo schema comune, vedere Schema di avviso comune.

      

   3. Seleziona OK.

10. Configura le azioni. Al termine, selezionare Avanti: Azioni. o seleziona la scheda Azioni nella parte superiore della pagina.

11. Definisci un elenco di azioni da attivare quando viene attivato un avviso. Seleziona un tipo di azione e immetti un nome per ogni azione.

    Tipo di azione	Dettagli
    Runbook di Automazione	Usare Runbook di Automazione per automatizzare le attività in base alle metriche. Ad esempio, arrestare le risorse quando nel budget associato viene raggiunta una determinata soglia. Per informazioni sui limiti dei payload del runbook di Automazione, vedi Limiti di automazione.
    Hub eventi	Un'azione di Hub eventi pubblica le notifiche in Hub eventi. Per altre informazioni su Hub eventi, vedere Hub eventi di Azure: una piattaforma di streaming di Big Data e un servizio di inserimento di eventi. Puoi sottoscrivere il flusso di notifica degli avvisi dal ricevitore di eventi.
    Funzioni	Chiama un endpoint trigger HTTP esistente nelle funzioni. Per altre informazioni, vedi Funzioni di Azure. Quando definisci l'azione della funzione, l'endpoint del trigger HTTP e la chiave di accesso della funzione vengono salvati nella definizione dell'azione, ad esempio, https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>. Se modifichi la chiave di accesso per la funzione, devi rimuovere e ricreare l'azione della funzione nel gruppo di azioni. L'endpoint deve supportare il metodo HTTP POST. La funzione deve avere accesso all'account di archiviazione. Se non ha accesso, le chiavi non sono disponibili e l'URI della funzione non è accessibile. Scopri come ripristinare l’accesso all'account di archiviazione.
    Gestione dei servizi IT	Un’azione Gestione dei servizi IT richiede un collegamento a Gestione dei servizi IT. Per scoprire come creare un collegamento a Gestione dei servizi IT, vedi Integrazione di Gestione dei servizi IT.
    App per la logica	Puoi usare App per la logica di Azure per creare e personalizzare flussi di lavoro per l'integrazione e per personalizzare le notifiche sugli avvisi.
    Webhook protetto	Quando usi un'azione webhook sicura, devi usare Microsoft Entra ID per proteggere la connessione tra il gruppo di azioni e l'endpoint, ovvero un'API Web protetta. Vedi Configurare l'autenticazione per il webhook protetto. Il webhook sicuro non supporta l'autenticazione di base. Se usi l'autenticazione di base, usa l'azione Webhook.
    Webhook	Se usi l'azione webhook, l'endpoint webhook di destinazione deve essere in grado di elaborare i vari payload JSON generati da origini di avviso diverse. Non è possibile passare certificati di sicurezza tramite un'azione webhook. Per usare l'autenticazione di base, devi passare le credenziali tramite l'URI. Se l'endpoint webhook prevede uno schema specifico, ad esempio lo schema di Microsoft Teams, usa il tipo di azione App per la logica per modificare lo schema di avviso e soddisfare le aspettative del webhook di destinazione. Per informazioni sulle regole usate per ripetere le azioni webhook, vedi Webhook.

    

12. Facoltativo. Se si vuole assegnare una coppia chiave-valore al gruppo di azioni per classificare le risorse di Azure, selezionare Avanti: Tag o la scheda Tag. In caso contrario, ignorare questo passaggio.

    

13. Seleziona Rivedi e crea per rivedere le impostazioni. Questo passaggio controlla rapidamente gli input per assicurarti di aver immesso tutte le informazioni necessarie. Se sono presenti problemi, vengono segnalati qui. Dopo aver rivisto le impostazioni, seleziona Crea per creare il gruppo di azioni.

    

    Nota

    Quando si configura un'azione per notificare a una persona tramite e-mail o SMS, questa persona riceve una conferma indicante che è stata aggiunta al gruppo di azioni.

Testare un gruppo di azioni nel portale di Azure

Quando si crea o si aggiorna un gruppo di azioni nel portale di Azure, è possibile sottoporlo a test.

1. Creare un gruppo di azioni nel portale di Azure.

   Nota

   Il gruppo di azioni deve essere creato e salvato prima del test. Se si modifica un gruppo di azioni esistente, prima di eseguire il test salvare le modifiche apportate al gruppo di azioni.

2. Nella pagina del gruppo di azioni selezionare Test gruppo di azioni.

   

3. Selezionare un tipo di esempio e i tipi di notifica e azione da testare. Selezionare quindi Test.

   

4. Se si chiude la finestra o si seleziona Torna a installazione test mentre il test è in esecuzione, il test viene arrestato e non si ottengono i risultati del test.

   

5. Al termine del test, viene visualizzato lo stato di test Operazione riuscita o Non riuscito. Se il test non è riuscito e si vogliono ottenere altre informazioni, selezionare Visualizza dettagli.

   

   Per comprendere il problema, è possibile usare le informazioni nella sezione Dettagli errore. È quindi possibile modificare, salvare le modifiche e testare di nuovo il gruppo di azioni.

   Quando si esegue un test e si seleziona un tipo di notifica, viene visualizzato un messaggio contenente "Test" nell'oggetto. I test consentono di verificare che il gruppo di azioni funzioni come previsto, prima di abilitarlo in un ambiente di produzione. Tutti i dettagli e i collegamenti nelle notifiche di posta elettronica del test provengono da un set di riferimenti di esempio.

Requisiti di ruolo per testare i gruppi di azione

La tabella seguente descrive i requisiti di appartenenza ai ruoli necessari per la funzionalità delle azioni del test:

¹ Il ruolo personalizzato deve disporre dell’autorizzazione Microsoft.Insights/createNotifications/*.

Creare un gruppo di azione con un modello di Resource Manager

È possibile usare un modello di Azure Resource Manager per configurare i gruppi di azione. I modelli consentono di configurare automaticamente i gruppi di azione che possono essere riusati in determinati tipi di avvisi. Questi gruppi di azione assicurano che tutte le parti corrette vengano notificate all'attivazione di un avviso.

I passaggi di base sono:

1. Creare un modello come file JSON che descriva come creare il gruppo di azione.
2. Distribuire il modello con un metodo di distribuzione qualsiasi.

Modelli di Resource Manager del gruppo di azioni

Per creare un gruppo di azione usando un modello di Resource Manager, si crea una risorsa di tipo Microsoft.Insights/actionGroups. Compilare quindi tutte le proprietà correlate. Ecco due modelli di esempio che creano un gruppo di azione.

Il primo modello descrive come creare un modello di Resource Manager per un gruppo di azione, in cui le definizioni di azioni sono hardcoded nel modello. Il secondo modello descrive come creare un modello che accetta le informazioni di configurazione webhook come parametri di input quando viene distribuito il modello.

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

Gestire i gruppi di azioni

Dopo aver creato un gruppo di azioni, è possibile visualizzarlo nel portale:

1. Vai al portale di Azure.

2. Nella pagina Monitoraggio, selezionare Avvisi.

3. Selezionare i Gruppi di azioni.

4. Selezionare il gruppo di azioni che si desidera gestire. È possibile:

   • Aggiungere, modificare o rimuovere azioni.
   • Eliminare il gruppo di azione.

Limiti del servizio per le notifiche

Nei gruppi di azioni è possibile includere un numero di telefono o un messaggio di posta elettronica, per numerose sottoscrizioni. Monitoraggio di Azure usa la limitazione della velocità per sospendere le notifiche, nei casi in cui a un determinato numero di telefono, indirizzo di posta elettronica o dispositivo sono inviate troppe notifiche. La limitazione assicura che gli avvisi siano gestibili ed eseguibili.

La limitazione della velocità si applica alle notifiche SMS, voce e posta elettronica. Tutte le altre azioni di notifica non sono soggette a limitazione di velocità. La limitazione della frequenza viene applicata a tutte le sottoscrizioni. Al raggiungimento della soglia viene applicata la limitazione della velocità, anche se i messaggi vengono inviati da più sottoscrizioni. Quando un indirizzo di posta elettronica è soggetto a limitazione di velocità, viene inviata una notifica di limitazione, sia all’applicazione, sia alla scadenza.

Per informazioni sui limiti della velocità, vedere Limiti del servizio Monitoraggio di Azure.

Email Azure Resource Manager

Quando si usa Azure Resource Manager per le notifiche tramite posta elettronica, è possibile inviare e-mail ai membri del ruolo di una sottoscrizione. L’email viene inviata all’utente Microsoft Entra ID o ai membri del gruppo per il ruolo. Questo include il supporto per i ruoli assegnati tramite Azure Lighthouse.

Se l’email primaria non riceve notifiche, configurarla per il ruolo Indirizzo e-mail di Azure Resource Manager:

1. Nel portale di Azure passare a Microsoft Entra ID.

2. A sinistra, selezionare Tutti gli utenti. A destra viene visualizzato un elenco di utenti.

3. Selezionare l'utente per cui si desidera rivedere l’indirizzo e-mail primario.

   

4. Nel profilo utente, in Informazioni contatto, cercare un valore Email. Se è vuoto:

   1. Nella parte superiore della pagina selezionare Modifica.
   2. Immettere un indirizzo e-mail.
   3. Nella parte superiore della pagina selezionare Salva.

   

È possibile che vi sia una limitata disponibilità di azioni e-mail per gruppo di azioni. Per verificare i limiti applicabili alla situazione, vedere Limiti del servizio Monitoraggio di Azure.

Quando si configura il ruolo Resource Manager:

1. Assegnare al ruolo un'entità di tipo Utente o Gruppo.
2. Impostare l'assegnazione a livello di sottoscrizione.
3. Accertare che per l'utente, nel profilo Microsoft Entra, sia configurato un indirizzo e-mail.

• Se un utente non è membro delle precedenti appartenenze ai ruoli con le autorizzazioni corrette per generare questa notifica, l'autorizzazione minima necessaria per testare un gruppo di azioni è "Microsoft.Insights/createNotifications/*"
• È possibile eseguire un numero limitato di test per periodo di tempo. Per verificare quali limiti si applicano alla situazione, vedere Limiti del servizio Monitoraggio di Azure.
• Quando si configura un gruppo di azioni nel portale, è possibile acconsentire esplicitamente o rifiutare lo schema di avviso comune.
  • Per trovare esempi di schemi comuni per tutti i tipi di esempio, vedere Definizioni comuni dello schema di avviso per il gruppo di azioni del test.
  • Per trovare le definizioni di avviso dello schema non comuni, vedere Definizioni di schema di avviso non comuni per il gruppo di azioni del test.

SMS

Potrebbe essere disponibile un numero limitato di azioni SMS per gruppo di azioni.

• Per informazioni sui limiti della velocità, vedere Limiti del servizio Monitoraggio di Azure.
• Per informazioni importanti sull'uso delle notifiche SMS nei gruppi di azioni, vedere Comportamento degli avvisi SMS nei gruppi di azioni.

Risposte SMS

Queste risposte sono supportate per le notifiche SMS. Il destinatario dell'SMS può rispondere all'SMS con questi valori:

Paesi/aree geografiche con supporto per le notifiche SMS

Voce

Potrebbe essere disponibile un numero limitato di azioni voce per gruppo di azioni. Per informazioni importanti sui limiti della velocità, vedere Limiti del servizio Monitoraggio di Azure.

Paesi/aree geografiche con supporto per le notifiche Voce

Per informazioni sui prezzi per paesi/aree geografiche supportate, vedere Prezzi di Monitoraggio di Azure.

Webhook

• Quando viene richiamato un webhook, se la prima chiamata ha esito negativo, viene ritentata almeno 1 volta e fino a 5 volte (5 tentativi) con vari intervalli di ritardo (5, 20, 40 secondi).
  • Il ritardo tra il primo e il secondo tentativo è di 5 secondi
  • Il ritardo tra il secondo e il terzo tentativo è di 20 secondi
  • Il ritardo tra il terzo e il quarto tentativo è di 5 secondi
  • Il ritardo tra il quarto e il quinto tentativo è di 40 secondi
  • Il ritardo tra il quinto e il sesto tentativo è di 5 secondi
• Dopo diversi tentativi di chiamata al webhook, nessun gruppo di azioni chiama l'endpoint per 15 minuti.
• La logica di retry presuppone che sia possibile riprovare la chiamata. I codici di stato: 408, 429, 503, 504 o HttpRequestException, WebException, TaskCancellationException consentono di ritentare la chiamata".

Configurare l'autenticazione per Webhook protetto

L'azione del webhook protetto esegue l'autenticazione all'API protetta usando un'istanza dell'Entità servizio nel tenant Microsoft Entra dell'applicazione "Webhook Microsoft Entra AZNS" di Microsoft Entra. Per consentire il funzionamento del gruppo di azioni, è necessario aggiungere l'Entità servizio Webhook Microsoft Entra come membro di un ruolo nell'applicazione Microsoft Entra di destinazione che concede l'accesso all'endpoint di destinazione.

Per una panoramica delle applicazioni e delle entità servizio di Microsoft Entra, vedere Panoramica di Microsoft Identity Platform (v2.0). Seguire questa procedura per sfruttare la funzionalità del webhook protetto.

1. Creare un'applicazione Microsoft Entra per l'API Web protetta. Per altre informazioni, vedere API Web protetta: Registrazione app. Configurare l'API protetta che deve essere chiamata da un'app daemon ed esporre le autorizzazioni dell'applicazione, non quelle delegate. Per altre informazioni su queste autorizzazioni, vedere Se l'API Web viene chiamata da un servizio o da un'app daemon.

   Nota

   Configurare l'API Web protetta per accettare i token di accesso V2.0. Per altre informazioni su questa impostazione, vedere Manifesto dell'app Microsoft Entra.

2. Per consentire al gruppo di azioni di usare l'applicazione Microsoft Entra, usare lo script di PowerShell che segue questa procedura.

   Nota

   Per eseguire questo script, è necessario che sia stato assegnato il ruolo di amministratore di applicazione Microsoft Entra.

   1. Modificare la chiamata Connect-AzureAD dello script di PowerShell per usare l'ID tenant di Microsoft Entra.
   2. Modificare la variabile $myAzureADApplicationObjectId dello script di PowerShell per usare l'ID oggetto dell'applicazione Microsoft Entra.
   3. Eseguire lo script modificato.

   Nota

   Per poter creare o modificare l'azione del webhook protetto nel gruppo di azioni, all'entità servizio deve essere assegnato un ruolo di proprietario dell'applicazione Microsoft Entra.

3. Configurare l'azione del webhook protetto.

   1. Copiare il valore $myApp.ObjectId presente nello script.
   2. Nella definizione dell'azione webhook, immettere il valore copiato nella casella ID oggetto.

   

Script di PowerShell per il webhook protetto

Come eseguire?

1. Copiare e incollare nel computer lo script seguente
2. Sostituire tenantId e ObjectID nella registrazione dell'app
3. Salva con nome *.ps1
4. Aprire il comando PowerShell dal computer ed eseguire lo script *.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 "================================================================================================="

Eseguire la migrazione dell'azione Runbook da "Account RunAs" a "Esegui identità gestita"

1. Modificare il gruppo di azioni aggiungendo una nuova azione con tipo di azione "Runbook di Automazione", quindi dall’elenco a discesa scegliere lo stesso runbook. (Tutti i 5 runbook nell'elenco a discesa sono stati riconfigurati in back-end per l'autenticazione tramite Identità gestita anziché con account RunAs. L'identità gestita assegnata dal sistema nell'account di Automazione sarebbe abilitata con ruolo Collaboratore VM, a livello di sottoscrizione, assegnato automaticamente).

   

   

2. Eliminare l'azione del runbook precedente con collegamento al runbook "Account RunAs".

3. Salvare il gruppo di azioni.

Passaggi successivi

• Ottenere una panoramica degli avvisi e informazioni sulla ricezione degli avvisi.
• Altre informazioni su Connettore di Gestione dei servizi IT.
• Informazioni su schema webhook degli avvisi del log attività.