Superviser un pare-feu Azure

  • Article

Cet article aborde les points suivants :

  • Types de données de monitoring que vous pouvez collecter pour ce service.
  • Comment analyser ces données.

Remarque

Si vous connaissez déjà ce service et/ou Azure Monitor et que vous voulez simplement savoir comment analyser les données de monitoring, consultez la section Analyser vers la fin de cet article.

Quand vous avez des applications critiques et des processus métier qui s’appuient sur des ressources Azure, vous devez monitorer votre système et obtenir des alertes. Le service Azure Monitor collecte et agrège les métriques et les journaux de chaque composant de votre système. Azure Monitor vous fournit une vue de la disponibilité, des performances et de la résilience, et vous avertit des problèmes. Vous pouvez utiliser le portail Azure, PowerShell, Azure CLI, l’API REST ou des bibliothèques de client pour configurer et visualiser les données de monitoring.

Vous pouvez utiliser les journaux et métriques du Pare-feu Azure pour surveiller votre trafic et vos opérations au sein du pare-feu. Ces journaux et métriques servent à plusieurs fins essentielles, notamment :

  • Analyse du trafic : utilisez les journaux d’activité pour examiner et analyser le trafic passant par le pare-feu. Cette analyse inclut l’examen du trafic autorisé et refusé, l’inspection des adresses IP source et destination, des URL, des numéros de port, des protocoles, etc. Ces aperçus sont essentiels pour comprendre les modèles de trafic, identifier les menaces de sécurité potentielles et résoudre les problèmes de connectivité.

  • Métriques de performances et d’intégrité : les métriques du Pare-feu Azure fournissent des métriques de performances et d’intégrité, telles que les données traitées, le débit, le nombre d’accès aux règles et la latence. Surveillez ces métriques pour évaluer l’intégrité globale de votre pare-feu, identifier les goulots d’étranglement des performances et détecter les anomalies.

  • Piste d’audit : les journaux d’activité permettent d’auditer les opérations liées aux ressources de pare-feu, de capturer des actions telles que la création, la mise à jour ou la suppression de règles et de stratégies de pare-feu. L’examen des journaux d’activité permet de conserver un enregistrement historique des modifications de configuration et garantit la conformité aux exigences de sécurité et d’audit.

Types de ressource

Azure utilise le concept de types de ressources et d’ID pour identifier tout dans un abonnement. Les types de ressource font également partie des ID de ressource pour chaque ressource exécutée dans Azure. Par exemple, le type de ressource pour une machine virtuelle peut être Microsoft.Compute/virtualMachines. Pour obtenir la liste des services et leurs types de ressource associés, consultez Fournisseurs de ressources.

Azure Monitor organise de même manière les données de supervision de base en métriques et journaux en fonction des types de ressources, également appelés espaces de noms. Différentes métriques et journaux sont disponibles pour les différents types de ressource. Votre service peut être associé à plusieurs types de ressource.

Pour plus d’informations sur les types de ressources de Pare-feu Azure, consultez Informations de référence sur les données de surveillance de Pare-feu Azure.

Stockage des données

Pour Azure Monitor :

  • Les données de métriques sont stockées dans la base de données des métriques Azure Monitor.
  • Les données de journal sont stockées dans le magasin de journaux Azure Monitor. Log Analytics est un outil du portail Azure qui peut interroger ce magasin.
  • Le journal d’activité Azure est un magasin distinct avec sa propre interface dans le portail Azure.

Vous pouvez aussi envoyer les données des métriques et des journaux d’activité vers le magasin de journaux Azure Monitor. Vous pouvez ensuite utiliser Log Analytics pour interroger les données et les mettre en corrélation avec d’autres données de journal.

De nombreux services peuvent utiliser les paramètres de diagnostic pour envoyer les données des métriques et des journaux vers d’autres emplacements de stockage en dehors d’Azure Monitor. Il peut ainsi s’agit du Stockage Azure, des systèmes partenaires hébergés et des systèmes partenaires non-Azure, en utilisant Event Hubs.

Pour plus d’informations sur la façon dont Azure Monitor stocke les données, consultez Plateforme de données Azure Monitor.

Métriques de plateforme Azure Monitor

Azure Monitor fournit des métriques de plateforme pour la plupart des services. Ces mesures sont :

  • Définies individuellement pour chaque espace de noms.
  • Stockées dans la base de données de métriques de série chronologique Azure Monitor.
  • Légères et capables de prendre en charge les alertes en quasi-temps réel.
  • Utilisées pour suivre les performances d’une ressource au fil du temps.

Collecte : Azure Monitor collecte automatiquement les métriques de plateforme. Aucune configuration n'est requise.

Routage : en général, vous pouvez aussi envoyer les métriques de plateforme vers les journaux Azure Monitor/Log Analytics afin de pouvoir les interroger avec d’autres données de journal. Pour plus d’informations, consultez le paramètre de diagnostic des métriques. Pour savoir comment configurer des paramètres de diagnostic pour un service, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Pour obtenir la liste de toutes les métriques qu’il est possible de collecter pour toutes les ressources dans Azure Monitor, consultez Métriques prises en charge dans Azure Monitor.

Pour obtenir la liste des métriques disponibles de Pare-feu Azure, consultez Informations de référence sur les données d’analyse de Pare-feu Azure.

Journaux de ressources Azure Monitor

Les journaux de ressource fournissent des insights sur les opérations effectuées par une ressource Azure. Les journaux sont générés automatiquement, mais vous devez les router vers les journaux Azure Monitor pour les enregistrer ou les interroger. Les journaux d’activité sont organisés en catégories. Un espace de noms donné peut avoir plusieurs catégories de journal de ressource.

Collecte : les journaux de ressource ne sont pas collectés ni stockés tant que vous n’avez pas créé un paramètre de diagnostic et routé les journaux vers un ou plusieurs emplacements. Lorsque vous créez un paramètre de diagnostic, vous spécifiez les catégories de journaux à collecter. Il existe plusieurs façons de créer et gérer des paramètres de diagnostic, notamment le portail Azure, programmatiquement et avec Azure Policy.

Routage : la valeur par défaut suggérée est le routage des journaux de ressource vers les journaux Azure Monitor afin de pouvoir les interroger avec d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations, consultez Journaux de ressource Azure et Destinations des journaux de ressource.

Pour plus d’informations sur la collecte, le stockage et le routage des journaux de ressource, consultez Paramètres de diagnostic dans Azure Monitor.

Pour obtenir la liste de toutes les catégories de journal de ressource disponibles dans Azure Monitor, consultez Journaux de ressource pris en charge dans Azure Monitor.

Tous les journaux de ressource dans Azure Monitor ont les mêmes champs d’en-tête, suivis de champs propres au service. Le schéma commun est décrit dans Schéma des journaux des ressources Azure Monitor.

Pour les catégories de journaux d’activité des ressources disponibles, leurs tables Log Analytics associées et les schémas de journaux d’activité de Pare-feu Azure, consultez Informations de référence sur les données de surveillance Pare-feu Azure.

Le classeur Pare-feu Azure constitue un canevas flexible pour l’analyse de données du Pare-feu Azure. Il permet de créer des rapports visuels enrichis au sein du Portail Azure. Vous pouvez exploiter plusieurs pare-feu déployés à travers l’écosystème Azure et les combiner dans des expériences interactives unifiées.

Vous pouvez également vous connecter à votre compte de stockage et récupérer les entrées de journal d’activité JSON pour les journaux d’activité d’accès et des performances. Après avoir téléchargé les fichiers JSON, vous pouvez les convertir en CSV et les afficher dans Excel, PowerBI ou tout autre outil de visualisation de données.

Conseil

Si vous savez utiliser Visual Studio et les concepts de base de la modification des valeurs de constantes et variables en C#, vous pouvez utiliser les outils de convertisseur de journaux disponibles dans GitHub.

Journal des activités Azure

Le journal d’activité contient des évènements au niveau de l’abonnement qui suivent les opérations sur chaque ressource Azure qui sont vues comme extérieures à cette ressource, par exemple, la création d’une ressource ou le démarrage d’une machine virtuelle.

Collecte : les évènements de journal d’activité sont générés et collectés automatiquement dans un magasin distinct pour leur consultation dans le portail Azure.

Routage : vous pouvez envoyer les données de journal d’activité aux journaux Azure Monitor afin de pouvoir les analyser en même temps que d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations sur le routage du journal d’activité, consultez Vue d’ensemble du journal d’activité Azure.

Journaux de Pare-feu Azure structurés

Les journaux structurés constituent un type de données de journal organisées dans un format spécifique. Ils utilisent un schéma prédéfini pour structurer des données de journal d’une manière qui facilite la recherche, le filtrage et l’analyse. Contrairement aux journaux non structurés, qui se composent d’un texte libre, les journaux structurés ont un format cohérent que des machines peuvent analyser.

Les journaux structurés de Pare-feu Azure fournissent une vue plus détaillée des événements de pare-feu. Ils incluent des informations telles que des adresses IP sources et de destination, des protocoles, des numéros de port et des actions effectuées par le pare-feu. Ils incluent également d’autres métadonnées, telles que l’heure de l’événement et le nom de l’instance Pare-feu Azure.

Actuellement, les catégories de journaux de diagnostic suivantes sont disponibles pour le Pare-feu Azure :

  • Journal de règles d’application
  • Journal de règles de réseau
  • Journal du proxy DNS

Ces catégories de journaux utilisent le mode Diagnostics Azure. Dans ce mode, toutes les données, quel que soit le paramètre de diagnostic, sont collectées dans la table AzureDiagnostics.

Avec des journaux structurés, vous pouvez choisir d’utiliser des Tables spécifiques aux ressources au lieu de la table AzureDiagnostics existante. Si les deux ensembles de journaux sont requis, au moins deux paramètres de diagnostic doivent être créés par pare-feu.

Mode spécifique des ressources

En mode Spécifique aux ressources, les tables individuelles de l’espace de travail sélectionné sont créées pour chaque catégorie sélectionnée dans le paramètre de diagnostic. Cette méthode est recommandée, car elle :

  • Peut réduire les coûts globaux de journalisation jusqu’à 80 %.
  • facilite beaucoup l’utilisation des données dans les requêtes de journal.
  • facilite la découverte de schémas et leur structure.
  • améliore les performances au niveau de la latence d’ingestion et des délais de requêtes.
  • vous permet d’accorder des droits RBAC Azure sur une table spécifique.

De nouvelles tables spécifiques aux ressources sont désormais disponibles dans le paramètre Diagnostic qui vous permet d’utiliser les catégories suivantes :

  • Journal des règles réseau : contient toutes les données du journal des règles réseau. Chaque correspondance entre le plan de données et la règle réseau crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.
  • Journal des règles NAT : contient toutes les données du journal des événements DNAT (traduction d’adresses réseau de destination). Chaque correspondance entre le plan de données et la règle DNAT crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.
  • Journal des règles d’application : contient toutes les données du journal des règles d’application. Chaque correspondance entre le plan de données et la règle d’application crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.
  • Journal de renseignement sur les menaces : contient tous les événements de renseignement sur les menaces.
  • Journal IDPS : contient tous les paquets de plan de données qui ont été mis en correspondance avec une ou plusieurs signatures IDPS.
  • Journal du proxy DNS : contient toutes les données du journal des événements du proxy DNS.
  • Journal des échecs de résolution du nom de domaine complet interne : contient toutes les demandes de résolution de nom de domaine complet du pare-feu internes qui ont entraîné l’échec.
  • Journal d’agrégation des règles d’application : contient des données de journal des règles d’application agrégées pour Policy Analytics.
  • Journal d’agrégation des règles réseau : contient des données de journal des règles réseau agrégées pour Policy Analytics.
  • Journal d’agrégation des règles de traduction d'adresses réseau : contient des données de journal des règles de traduction d'adresses réseau agrégées pour Policy Analytics.
  • Journal des flux principaux : le journal des flux principaux (flux FAT) montre les principales connexions qui contribuent au débit le plus élevé à travers le pare-feu.
  • Trace de flux : contient les informations de flux, des indicateurs et la période pendant laquelle les flux ont été enregistrés. Vous pouvez voir des informations complètes de flux telles que SYN, SYN-ACK, FIN, FIN-ACK, RST, INVALID (flux).

Activer les journaux structurés

Pour activer des journaux structurés du Pare-feu Azure, vous devez d’abord configurer un espace de travail Log Analytics dans votre abonnement Azure. Cet espace de travail est utilisé pour stocker les journaux structurés générés par Pare-feu Azure.

Après avoir configuré l’espace de travail Log Analytics, vous pouvez activer des journaux structurés dans Pare-feu Azure en accédant à la page Paramètres de diagnostic du pare-feu dans le Portail Azure. À partir de là, vous devez sélectionner la table de destination Spécifique à la ressource et sélectionner le type d’événements que vous souhaitez journaliser.

Remarque

Il n’est pas nécessaire d’activer cette fonctionnalité avec un indicateur de fonctionnalité ou des commandes Azure PowerShell.

Capture d’écran de la page des Paramètres de diagnostic.

Requêtes de journaux structurés

Une liste de requêtes prédéfinies est disponible dans le Portail Azure. Cette liste comporte une requête de journal KQL (Langage de requête Kusto) prédéfinie pour chaque catégorie et requête jointe montrant l’ensemble des événements de journalisation du Pare-feu Azure en mode unique.

Capture d’écran montrant des requêtes du Pare-feu Azure.

Classeur du Pare-feu Azure

Le classeur Pare-feu Azure constitue un canevas flexible pour l’analyse de données du Pare-feu Azure. Il permet de créer des rapports visuels enrichis au sein du Portail Azure. Vous pouvez exploiter plusieurs pare-feux déployés dans Azure et les combiner dans des expériences interactives unifiées.

Pour déployer le nouveau classeur qui utilise des journaux structurés Pare-feu Azure, consultez Classeur Azure Monitor pour Pare-feu Azure.

Journaux de Diagnostics Azure hérités

Les journaux de diagnostic Azure hérités sont les requêtes de journal du Pare-feu Azure d’origine qui génèrent des données de journal dans un format texte non structuré ou libre. Les catégories de journaux héritées du Pare-feu Azure utilisent le mode de diagnostics Azure, en collectant des données complètes dans la table AzureDiagnostics. Si les journaux structurés et de diagnostic sont tous deux requis, au moins deux paramètres de diagnostics doivent être créés par pare-feu.

Les catégories de journaux suivantes sont prises en charge dans les journaux de diagnostic :

  • Règle d’application de pare-feu Azure
  • Règle de réseau de pare-feu Azure
  • Proxy DNS du Pare-feu Azure

Pour savoir comment activer la journalisation des diagnostics à l’aide du portail Azure, consultez Activer les journaux structurés.

Journal de règles d’application

Le journal de règles d’application est enregistré dans un compte de stockage, transmis en continu au service Event Hubs et/ou envoyé vers les journaux Azure Monitor uniquement si vous l’activez pour chaque Pare-feu Azure. Chaque nouvelle connexion qui correspond à l’une de vos règles d’application configurées entraîne un journal pour la connexion acceptée/refusée. Les données sont journalisées au format JSON, comme indiqué dans les exemples suivants :

Category: application rule logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

{
 "category": "AzureFirewallApplicationRule",
 "time": "2018-04-16T23:45:04.8295030Z",
 "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
 "operationName": "AzureFirewallApplicationRuleLog",
 "properties": {
     "msg": "HTTPS request from 10.1.0.5:55640 to mydestination.com:443. Action: Allow. Rule Collection: collection1000. Rule: rule1002"
 }
}

{
  "category": "AzureFirewallApplicationRule",
  "time": "2018-04-16T23:45:04.8295030Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallApplicationRuleLog",
  "properties": {
      "msg": "HTTPS request from 10.11.2.4:53344 to www.bing.com:443. Action: Allow. Rule Collection: ExampleRuleCollection. Rule: ExampleRule. Web Category: SearchEnginesAndPortals"
  }
}

Journal de règles de réseau

Le journal de règles de réseau est enregistré dans un compte de stockage, transmis en continu au service Event Hubs et/ou envoyé vers les journaux Azure Monitor uniquement si vous l’activez pour chaque Pare-feu Azure. Chaque nouvelle connexion qui correspond à l’une de vos règles de réseau configurées entraîne un journal pour la connexion acceptée/refusée. Les données sont consignées au format JSON, comme indiqué dans l’exemple suivant :

Category: network rule logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

{
 "category": "AzureFirewallNetworkRule",
 "time": "2018-06-14T23:44:11.0590400Z",
 "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
 "operationName": "AzureFirewallNetworkRuleLog",
 "properties": {
     "msg": "TCP request from 111.35.136.173:12518 to 13.78.143.217:2323. Action: Deny"
 }
}

Journal du proxy DNS

Le journal du proxy DNS est enregistré dans un compte de stockage, transmis en continu au service Event Hubs et/ou envoyé vers les journaux Azure Monitor uniquement si vous l’activez pour chaque pare-feu Azure. Ce journal effectue le suivi des messages DNS envoyés à un serveur DNS configuré à l’aide du proxy DNS. Les données sont journalisées au format JSON, comme indiqué dans les exemples suivants :

Category: DNS proxy logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

Réussite :

{
  "category": "AzureFirewallDnsProxy",
  "time": "2020-09-02T19:12:33.751Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallDnsProxyLog",
  "properties": {
      "msg": "DNS Request: 11.5.0.7:48197 – 15676 AAA IN md-l1l1pg5lcmkq.blob.core.windows.net. udp 55 false 512 NOERROR - 0 2.000301956s"
  }
}

Échec :

{
  "category": "AzureFirewallDnsProxy",
  "time": "2020-09-02T19:12:33.751Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallDnsProxyLog",
  "properties": {
      "msg": " Error: 2 time.windows.com.reddog.microsoft.com. A: read udp 10.0.1.5:49126->168.63.129.160:53: i/o timeout”
  }
}

Format de message :

[client’s IP address]:[client’s port] – [query ID] [type of the request] [class of the request] [name of the request] [protocol used] [request size in bytes] [EDNS0 DO (DNSSEC OK) bit set in the query] [EDNS0 buffer size advertised in the query] [response CODE] [response flags] [response size] [response duration]

Analyser les données de surveillance

Il existe de nombreux outils pour analyser les données de supervision.

Outils Azure Monitor

Azure Monitor prend en charge les outils de base suivants :

Les outils qui permettent une visualisation plus complexe sont notamment :

  • Les tableaux de bord, qui vous permettent de combiner différentes sortes de données dans un même volet du portail Azure.
  • Les workbooks, des rapports personnalisables que vous pouvez créer dans le portail Azure. Les workbooks peuvent inclure du texte, des métriques et des requêtes de journal.
  • Grafana, un outil de plateforme ouvert, parfait pour les tableaux de bord opérationnels. Vous pouvez utiliser Grafana pour créer des tableaux de bord à partir de données de plusieurs sources autres qu’Azure Monitor.
  • Power BI, un service d’analyse métier qui fournit des visualisations interactives pour diverses sources de données. Vous pouvez configurer Power BI pour importer automatiquement les données de journal à partir d’Azure Monitor afin de tirer parti de ces visualisations supplémentaires.

Outils d’exportation Azure Monitor

Vous pouvez extraire des données d’Azure Monitor dans d’autres outils en utilisant les méthodes suivantes :

Pour bien démarrer avec l’API REST pour Azure Monitor, consultez Procédure pas à pas de l’API REST d’analyse Azure.

Requêtes Kusto

Vous pouvez analyser les données de supervision dans les journaux Azure Monitor ou le magasin Log Analytics à l’aide du langage de requête Kusto (KQL).

Important

Quand vous sélectionnez Journaux dans le menu du service dans le portail, Log Analytics s’ouvre avec l’étendue de requête définie sur le service actuel. Cette étendue signifie que les requêtes de journal ont seulement des données de ce type de ressource. Si vous voulez exécuter une requête qui comprend des données d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.

Pour obtenir la liste des requêtes courantes pour n’importe quel service, consultez l’Interface de requêtes Log Analytics.

Alertes

Azure Monitor vous alerte de façon proactive quand des conditions spécifiques sont détectées dans vos données de monitoring. Les alertes permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos clients ne les remarquent. Pour plus d’informations, consultez Alertes Azure Monitor.

Il existe de nombreuses sources d’alertes courantes pour les ressources Azure. Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal. Le site Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée pour implémenter les alertes, les tableaux de bord et les recommandations associés·es les plus importants·es aux métriques de plateforme. Le site s’applique à un sous-ensemble des services Azure en constante expansion, y compris tous les services qui font partie de la zone d’atterrissage Azure (ALZ).

Le schéma d’alerte commun standardise la consommation de notifications d'alerte pour Azure Monitor. Pour plus d’informations, consultez Schéma d’alerte courant.

Types d'alertes

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor. Il existe de nombreux types d’alertes différents en fonction des services que vous monitorez et des données de monitoring que vous collectez. Les différents types d’alertes ont divers avantages et inconvénients. Pour plus d’informations, consultez Choisir le bon type d’alerte de monitoring.

La liste suivante décrit les types d’alertes Azure Monitor que vous pouvez créer :

  • Les alertes de métrique évaluent les métriques de ressource à intervalles réguliers. Les métriques peuvent être des métriques de plateforme, des métriques personnalisées, des journaux provenant d’Azure Monitor convertis en métriques ou des métriques Application Insights. Les alertes de métriques peuvent également appliquer plusieurs conditions et seuils dynamiques.
  • Les alertes de journal permettent aux utilisateurs d’utiliser une requête Log Analytics pour évaluer les journaux de ressource à une fréquence prédéfinie.
  • Les alertes de journal d’activité sont déclenchées quand un nouvel événement de journal d’activité correspond à des conditions définies. Les alertes Resource Health et les alertes Service Health sont des alertes de journal d’activité qui concernent l’intégrité de votre service et de vos ressources.

Certains services Azure prennent également en charge les alertes de détection intelligente, les alertes Prometheus ou les règles d’alerte recommandées.

Pour certains services, vous pouvez opérer une surveillance à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type qui existent dans la même région Azure. Les notifications individuelles sont envoyées pour chaque ressource supervisée. Pour connaître les services et clouds Azure pris en charge, consultez Monitorer plusieurs ressources avec une seule règle d’alerte.

Alerte sur les métriques du Pare-feu Azure

Les métriques fournissent des signaux critiques pour suivre l’intégrité de vos ressources. Il est donc important de surveiller les métriques de votre ressource et de détecter les anomalies. Mais que se passe-t-il si les métriques du Pare-feu Azure cessent de circuler ? Cela peut indiquer un problème de configuration potentiel ou un problème plus inquiétant tel qu’une panne. Des métriques manquantes peuvent se produire en raison de la publication d’itinéraires par défaut qui empêchent le Pare-feu Azure de charger des métriques ou si le nombre d’instances intègres atteint zéro. Dans cette section, vous apprenez à configurer des métriques sur un espace de travail Log Analytics et à alerter sur les métriques manquantes.

Configurer des métriques dans un espace de travail Log Analytics

La première étape consiste à configurer la disponibilité des métriques dans l’espace de travail Log Analytics à l’aide des paramètres de diagnostic dans le pare-feu.

Pour configurer les paramètres de diagnostic, comme illustré dans la capture d’écran suivante, accédez à la page de ressources de Pare-feu Azure. Cette opération envoie (push) les métriques de pare-feu à l’espace de travail configuré.

Remarque

Les paramètres de diagnostic des métriques doivent être une configuration distincte des journaux. Les journaux de pare-feu peuvent être configurés pour utiliser des diagnostics Azure ou des ressources spécifiques. Toutefois, les métriques de pare-feu doivent toujours utiliser des diagnostics Azure.

Capture d’écran du paramètre de diagnostic du pare-feu Azure.

Créer une alerte pour suivre la réception des métriques de pare-feu sans échec

Accédez à l’espace de travail configuré dans les paramètres de diagnostic des métriques. Vérifiez si les métriques sont disponibles à l’aide de la requête suivante :

AzureMetrics
| where MetricName contains "FirewallHealth"
| where ResourceId contains "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/PARALLELIPGROUPRG/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/HUBVNET-FIREWALL"
| where TimeGenerated > ago(30m)

Ensuite, créez une alerte pour les métriques manquantes sur une période de 60 minutes. Pour configurer de nouvelles alertes sur les métriques manquantes, accédez à la page Alerte de l’espace de travail Log Analytics.

Capture d’écran montrant la page Modifier une règle d’alerte.

Règles d’alerte de Pare-feu Azure

Vous pouvez définir des alertes pour n’importe quelle métrique, entrée de journal ou entrée de journal d’activité répertoriée dans Informations de référence sur les données de surveillance de Pare-feu Azure.

Recommandations d’Advisor

Pour certains services, si des conditions critiques ou des changements imminents se produisent pendant des opérations de ressources, une alerte s’affiche dans la page Vue d’ensemble du service concerné dans le portail. Des informations supplémentaires et les correctifs recommandés pour l’alerte sont disponibles dans les Recommandations Advisor sous Surveillance dans le menu de gauche. Pendant les opérations normales, aucune recommandation Advisor ne s’affiche.

Pour plus d’informations sur Azure Advisor, consultez Vue d’ensemble d’Azure Advisor.

Contenu connexe