Sécuriser votre déploiement Azure Monitor

2025-06-19

Cet article fournit des instructions pour déployer Azure Monitor en toute sécurité et explique comment Microsoft sécurise Azure Monitor.

Ingestion et stockage de logs

Accorder l’accès aux données dans l’espace de travail en fonction du besoin

Définissez le mode de contrôle d’accès de l’espace de travail pour utiliser les autorisations de ressource ou d’espace de travail pour permettre aux propriétaires de ressources d’utiliser le contexte des ressources pour accéder à leurs données sans avoir accès explicite à l’espace de travail. Cela simplifie la configuration de votre espace de travail et permet de s’assurer que les utilisateurs n’ont accès qu’aux données dont ils ont besoin.
Instructions : Gérer l’accès aux espaces de travail Log Analytics
Attribuez le rôle intégré approprié pour accorder des autorisations d’espace de travail aux administrateurs au niveau de l’abonnement, du groupe de ressources ou de l’espace de travail en fonction de leur étendue de responsabilités.
Instructions : Gérer l’accès aux espaces de travail Log Analytics
Appliquez le RBAC au niveau table pour les utilisateurs qui ont besoin d’accéder à un ensemble de tables sur plusieurs ressources. Les utilisateurs avec des autorisations de table ont accès à toutes les données de la table, quelles que soient leurs autorisations de ressource.
Instructions : Gérer l’accès aux espaces de travail Log Analytics

Envoyer des données à votre espace de travail à l’aide du protocole TLS (Transport Layer Security) 1.2 ou version ultérieure

Si vous utilisez des agents, des connecteurs ou des API logs pour interroger ou envoyer des données à votre espace de travail, utilisez TLS (Transport Layer Security) 1.2 ou au moins la version 1.2 pour garantir la sécurité de vos données en transit. Les versions antérieures de TLS et SSL (Secure Sockets Layer) présentent des vulnérabilités et, bien qu’elles puissent encore fonctionner pour permettre la compatibilité descendante, elles ne sont pas recommandées et le secteur a rapidement migré pour abandonner la prise en charge de ces protocoles plus anciens.

Le Conseil des normes de sécurité PCI a fixé une échéance du 30 juin 2018 pour désactiver les versions antérieures de TLS/SSL et mettre à niveau vers des protocoles plus sécurisés. Une fois qu'Azure retire le support des fonctionnalités anciennes, si vos agents ne peuvent pas utiliser au minimum TLS 1.2, vous ne pourrez pas envoyer de données aux Logs Azure Monitor.

Ne configurez pas explicitement vos agents, connecteurs de données ou applications API pour utiliser TLS 1.2, sauf si nécessaire. Il est recommandé de les autoriser à détecter, négocier et tirer parti des futures normes de sécurité. Dans le cas contraire, vous risquez de manquer la sécurité accrue des normes plus récentes et peut-être de rencontrer des problèmes si TLS 1.2 est déprécié en faveur de ces dernières normes.

Important

Le 1er juillet 2025, conformément au retrait des versions héritées de TLS d'Azure, les versions 1.0 et 1.1 du protocole TLS seront supprimées dans Azure Monitor Logs. Pour assurer un chiffrement de premier ordre, les journaux Azure Monitor utilisent les mécanismes de chiffrement de Transport Layer Security (TLS) 1.2 et 1.3.

Pour obtenir des questions générales sur le problème TLS hérité ou sur la façon de tester les suites de chiffrement prises en charge, consultez Résolution des problèmes TLS et prise en charge d’Azure Resource Manager TLS.

Configurer l’audit des requêtes de journal

Configurez l’audit des requêtes de journal pour enregistrer les détails de chaque requête exécutée dans un espace de travail.
Instructions : Auditer les requêtes dans les journaux Azure Monitor
Traitez les données d’audit des requêtes de journal comme des données de sécurité et sécurisez l’accès à la table LAQueryLogs de manière appropriée.
Instructions : Configurez l’accès aux données dans l’espace de travail en fonction du besoin.
Si vous séparez vos données opérationnelles et de sécurité, envoyez les journaux d’audit de chaque espace de travail à l’espace de travail local ou consolidez dans un espace de travail de sécurité dédié.
Instructions : Configurez l’accès aux données dans l’espace de travail en fonction du besoin.
Utilisez les insights de l’espace de travail Log Analytics pour examiner régulièrement les données d’audit des requêtes de journal.
Instructions : Informations sur l’espace de travail Log Analytics.
Créez des règles d’alerte de recherche dans les journaux pour être averti si des utilisateurs non autorisés tentent d’exécuter des requêtes.
Instructions : Règles d’alerte de recherche dans les journaux.

Garantir l’immuabilité des données d’audit

Azure Monitor est une plateforme de données d’ajout uniquement, mais inclut des dispositions pour supprimer des données à des fins de conformité. Pour sécuriser vos données d’audit :

Définissez un verrou sur votre espace de travail Log Analytics pour bloquer toutes les activités susceptibles de supprimer des données, notamment le vidage, la suppression de table et les modifications de rétention des données au niveau de l’espace de travail. Toutefois, gardez à l’esprit que ce verrou peut être supprimé.
Instructions : Verrouiller vos ressources pour protéger votre infrastructure
Si vous avez besoin d'une solution entièrement inviolable, nous vous recommandons d’exporter vos données vers une solution de stockage immuable :
1. Déterminez les types de données spécifiques qui doivent être exportés. Tous les types de journaux n’ont pas la même pertinence pour la conformité, l’audit ou la sécurité.
2. Utilisez l’exportation de données pour envoyer des données à un compte de stockage Azure.
  Instructions : Exportation des données de l’espace de travail Log Analytics dans Azure Monitor
3. Définissez des stratégies d’immuabilité pour vous protéger contre la falsification des données.
  Instructions : Configurer des stratégies d’immuabilité pour les versions des blobs

Filtrer ou masquer les données sensibles dans votre espace de travail

Si vos données de journal incluent des informations sensibles :

Filtrez les enregistrements qui ne doivent pas être collectés en utilisant la configuration de la source de données particulière.
Utilisez une transformation si seules les colonnes particulières des données doivent être supprimées ou obfusquées.
Instructions : Transformations dans Azure Monitor
Si vous avez des standards qui impliquent que les données d’origine ne soient pas modifiées, utilisez le littéral « h » dans les requêtes KQL pour obfusquer les résultats de requête affichés dans les classeurs.
Instructions : littéraux de chaîne obfusqués

Vider les données sensibles collectées accidentellement

Vérifiez régulièrement les données privées susceptibles d’être collectées accidentellement dans votre espace de travail.
Utilisez le vidage des données pour supprimer les données indésirables. Notez que les données des tables avec le plan auxiliaire ne peuvent pas être purgées actuellement.
Instructions : Gestion des données personnelles dans les journaux Azure Monitor et Application Insights

Lier votre espace de travail à un cluster dédié pour renforcer la sécurité

Azure Monitor chiffre toutes les données au repos et les requêtes enregistrées en utilisant des clés gérées par Microsoft (MMK). Si vous collectez suffisamment de données pour un cluster dédié, liez votre espace de travail à un cluster dédié pour des fonctionnalités de sécurité améliorées, notamment :

Clés gérées par le client pour une plus grande flexibilité et un contrôle du cycle de vie des clés. Si vous utilisez Microsoft Sentinel, vérifiez que vous êtes familiarisé avec les points à prendre en compte sur Configurer une clé gérée par le client Microsoft Sentinel.
Customer Lockbox pour Microsoft Azure afin d’examiner et d’approuver ou de rejeter les demandes d’accès aux données client. La fonctionnalité Customer Lockbox est utilisée lorsqu’un ingénieur Microsoft a besoin d’accéder aux données client, que ce soit en réponse à un ticket de support initié par le client ou à un problème identifié par Microsoft. Lockbox ne peut actuellement pas être appliqué à des tables avec le plan auxiliaire.

Instructions : Créer et gérer un cluster dédié dans Azure Monitor Logs

Bloquer l’accès de l’espace de travail à partir de réseaux publics à l’aide d’Azure Private Link

Microsoft sécurise les connexions aux points de terminaison publics avec le chiffrement de bout en bout. Si vous avez besoin d’un point de terminaison privé, utilisez une liaison privée Azure pour autoriser les ressources à se connecter à votre espace de travail Log Analytics via des réseaux privés autorisés. Vous pouvez également utiliser Private Link pour forcer l’ingestion de données de l’espace de travail sur ExpressRoute ou un VPN.

Instructions : Concevoir votre configuration Azure Private Link

Ingestion TLS pour Application Insights

Configurations TLS prises en charge

Application Insights utilise TLS (Transport Layer Security) 1.2 et 1.3. En outre, les suites de chiffrement et les courbes elliptiques suivantes sont également prises en charge dans chaque version.

Version	Suites de chiffrement	Courbes elliptiques
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

Dépréciation des configurations TLS (Transport Layer Security)

Important

Pour améliorer la sécurité, Azure met hors service les configurations TLS suivantes pour Application Insights le 1er mai 2025. Cette modification fait partie du retrait des anciens protocoles TLS sur Azure :

Versions du protocole TLS 1.0 et TLS 1.1
Suites de chiffrement TLS 1.2 et TLS 1.3 héritées
Courbes elliptiques TLS héritées

TLS 1.0 et TLS 1.1

TLS 1.0 et 1.1 sont en cours de retrait.

TLS 1.2 et TLS 1.3

Version	Suites de chiffrement	Courbes elliptiques
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • Protocole de sécurité TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_RSA_WITH_AES_256_GCM_SHA384 • TLS_RSA_WITH_AES_128_GCM_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA256 • TLS_RSA_WITH_AES_128_CBC_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA • TLS_RSA_WITH_AES_128_CBC_SHA	• curve25519
TLS 1.3		• curve25519

Pour plus d’informations, consultez la prise en charge de TLS dans application Insights FAQ.

Alertes

Contrôler les autorisations de règle d’alerte de recherche dans les journaux à l’aide d’identités managées

Un défi courant pour les développeurs est la gestion des secrets, des informations d’identification, des certificats et des clés utilisés pour sécuriser la communication entre les services. Les identités managées éliminent la nécessité pour les développeurs de gérer ces informations d’identification. La définition d’une identité managée pour vos règles d’alerte de recherche dans les journaux vous donne un contrôle et une visibilité sur les autorisations exactes de votre règle d’alerte. À tout moment, vous pouvez afficher les autorisations de requête de votre règle et ajouter ou supprimer des autorisations directement de son identité managée.

L’utilisation d’une identité managée est requise si la requête de votre règle accède à Azure Data Explorer (ADX) ou Azure Resource Graph (ARG).

Instructions : créez ou modifiez une règle d’alerte de recherche dans les journaux.

Attribuer le rôle Lecteur de surveillance à tous les utilisateurs qui n’ont pas besoin de privilèges de configuration

Améliorez la sécurité en donnant aux utilisateurs les privilèges minimum requis pour leur rôle.

Instructions : Rôles, autorisations et sécurité dans Azure Monitor.

Utiliser des actions de webhook sécurisées lorsque cela est possible

Si votre règle d’alerte contient un groupe d’actions qui utilise des actions webhook, préférez utiliser des actions webhook sécurisées pour une authentification plus forte.

Instructions : Configurer l’authentification pour le webhook sécurisé.

Utiliser des clés gérées par le client si vous avez besoin de votre propre clé de chiffrement pour protéger les données et les requêtes enregistrées dans vos espaces de travail

Azure Monitor chiffre toutes les données et requêtes enregistrées au repos à l’aide de clés gérées par Microsoft (MMK). Si vous avez besoin de votre propre clé de chiffrement et que vous collectez suffisamment de données pour un cluster dédié, utilisez des clés gérées par le client pour plus de flexibilité et de contrôle du cycle de vie des clés.

Instructions : clés gérées par le client.

Si vous utilisez Microsoft Sentinel, consultezConfigurer la clé gérée par le client Microsoft Sentinel.

Surveillance des machines virtuelles

Implémenter la surveillance de la sécurité des machines virtuelles à l’aide des services de sécurité Azure

Bien qu’Azure Monitor puisse collecter des événements de sécurité à partir de vos machines virtuelles, il n’est pas destiné à être utilisé pour la surveillance de la sécurité. Azure inclut plusieurs services, tels que Microsoft Defender pour le cloud et Microsoft Sentinel, qui fournissent une solution complète de surveillance de la sécurité lorsqu’ils sont utilisés ensemble. Pour une comparaison de ces services, consultez Surveillance de la sécurité.

Connecter des machines virtuelles à Azure Monitor via un point de terminaison privé à l’aide d’Azure Private Link

Instructions : Concevoir votre configuration Azure Private Link

Supervision de conteneur

Connecter des clusters à Container Insights à l’aide de l’authentification d’identité managée

L’authentification par identité managée est la méthode d’authentification par défaut pour les nouveaux clusters. Si vous utilisez l’authentification héritée, migrez vers l’identité managée pour supprimer l’authentification locale basée sur un certificat.

Instructions : Migrer vers l’authentification d’identité managée

Envoyer des données à partir de clusters vers Azure Monitor via un point de terminaison privé à l’aide d’Azure Private Link

Le service managé Azure pour Prometheus stocke ses données dans un espace de travail Azure Monitor, qui utilise un point de terminaison public par défaut. Microsoft sécurise les connexions aux points de terminaison publics avec le chiffrement de bout en bout. Si vous avez besoin d’un point de terminaison privé, utilisez une liaison privée Azure pour permettre à votre cluster de se connecter à l’espace de travail via des réseaux privés autorisés. Private Link peut également être utilisé pour forcer l’ingestion de données de l’espace de travail sur ExpressRoute ou un VPN.

Instructions : Consultez Activer une liaison privée pour la surveillance Kubernetes dans Azure Monitor pour plus d’informations sur la configuration de votre cluster pour une liaison privée. Consultez Utiliser des points de terminaison privés pour l’espace de travail Prometheus managé et Azure Monitor pour plus d’informations sur l’interrogation de vos données à l’aide d’une liaison privée.

Surveiller le trafic réseau vers et depuis des clusters à l’aide de l’analytique du trafic

Traffic Analytics analyse les journaux de flux NSG Azure Network Watcher pour fournir des insights sur le flux de trafic dans votre cloud Azure. Utilisez cet outil pour vous assurer qu’il n’existe aucune exfiltration de données pour votre cluster et détecter si des adresses IP publiques inutiles sont exposées.

Activer l’observabilité réseau

Le module complémentaire d’observabilité réseau pour AKS offre une observabilité sur les plusieurs couches de la pile de mise en réseau Kubernetes. Surveillez et observez l’accès entre les services du cluster (trafic est-ouest).

Instructions : Configurer l’observabilité du réseau de conteneurs pour Azure Kubernetes Service (AKS)

Sécuriser votre espace de travail Log Analytics

Container Insights envoie des données à un espace de travail Log Analytics. Veillez à sécuriser les ingestions et le stockage des journaux dans votre espace de travail Log Analytics.

Instructions : Journalisation et stockage des données.

Comment Microsoft sécurise Azure Monitor

Les instructions de cet article s’appuient sur le modèle de responsabilité de sécurité Microsoft. Dans le cadre de ce modèle de responsabilité partagée, Microsoft fournit ces mesures de sécurité aux clients Azure Monitor :

Conseils et bonnes pratiques de sécurité Azure

Les instructions de déploiement sécurisé Azure Monitor sont basées et cohérentes avec les recommandations complètes en matière de sécurité cloud d’Azure, notamment :

Cloud Adoption Framework qui fournit des conseils de sécurité pour les équipes qui gèrent l’infrastructure de technologie.
Azure Well-Architected Framework qui offre les meilleures pratiques architecturales pour générer des applications sécurisées.
Point de référence de sécurité Microsoft Cloud (MCSB) qui décrit les fonctionnalités de sécurité disponibles et les configurations optimales recommandées.
Principes de sécurité Confiance Zéro qui fournit des conseils aux équipes de sécurité pour implémenter des fonctionnalités techniques afin de prendre en charge une initiative de modernisation Confiance Zéro.

Étape suivante

En savoir plus sur la prise en main d’Azure Monitor.