Sécurité des données des journaux Azure Monitor

  • Article

Cet article explique comment Azure Monitor collecte, traite et sécurise les données de journal et décrit les fonctionnalités de sécurité que vous pouvez utiliser pour sécuriser davantage votre environnement Azure Monitor. Les informations contenues dans cet article sont spécifiques aux journaux Azure Monitor et complètent les informations sur le Centre de confidentialité Azure.

Les Journaux Azure Monitor gèrent vos données basées sur le cloud en toute sécurité en utilisant :

  • Ségrégation des données
  • Conservation des données
  • Sécurité physique
  • Gestion des incidents
  • Conformité
  • Certifications relatives aux normes de sécurité

Contactez-nous pour toute question, suggestion ou remarque concernant les informations fournies ci-dessous, y compris notre politique de sécurité dans Options de support Azure.

Envoi sécurisé de données via TLS 1.2

Pour garantir la sécurité des données en transit vers Azure Monitor, nous vous encourageons vivement à configurer l’agent de façon à utiliser au moins le protocole TLS (Transport Layer Security) 1.2. Les versions antérieures de TLS/SSL (Secure Sockets Layer) se sont avérées vulnérables et bien qu’elles fonctionnent encore pour assurer la compatibilité descendante, elles sont déconseillées et le secteur évolue rapidement vers un arrêt de la prise en charge de ces anciens protocoles.

Le PCI Security Standards Council a défini une échéance au 30 juin 30, 2018 pour désactiver les versions antérieures de TLS/SSL et effectuer une mise à niveau vers des protocoles plus sécurisés. Une fois qu’Azure aura arrêté la prise en charge des versions héritées, si vos agents ne peuvent pas communiquer via au moins le protocole TLS 1.2, vous ne serez plus en mesure d’envoyer des données aux Journaux Azure Monitor.

Nous vous recommandons de NE PAS définir explicitement votre agent pour qu’il utilise uniquement TLS 1.2, sauf si nécessaire. Il est préférable d’autoriser l’agent à détecter, négocier et tirer parti des normes de sécurité futures. 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.

Instructions spécifiques à la plateforme

Plateforme/Langage Support Informations complémentaires
Linux Les distributions de Linux s’appuient généralement sur OpenSSL pour la prise en charge de TLS 1.2. Vérifiez OpenSSL Changelog pour vous assurer que votre version d’OpenSSL est prise en charge.
Windows 8.0 - 10 Pris en charge, activé par défaut. Pour confirmer que vous utilisez toujours les paramètres par défaut.
Windows Server 2012 - 2016 Pris en charge, activé par défaut. Pour confirmer que vous utilisez toujours les paramètres par défaut
Windows 7 SP1 et Windows Server 2008 R2 SP1 Pris en charge, mais non activé par défaut. Consultez la page Paramètres de Registre de TLS pour plus d’informations sur l’activation.

Ségrégation des données

Une fois que vos données ont été ingérées par Azure Monitor, elles sont séparées logiquement sur chaque composant dans l’ensemble du service. Toutes les données sont balisées en fonction de l’espace de travail. Ce balisage est conservé tout au long du cycle de vie des données, et il est appliqué dans chaque couche du service. Vos données sont stockées dans une base de données dédiée dans le cluster de stockage de la région que vous avez sélectionnée.

Conservation des données

Les données indexées de recherche dans les journaux sont stockées et conservées en fonction de votre plan de tarification. Pour plus d’informations, consultez Tarification - Log Analytics.

Microsoft conserve vos données conformément aux termes de votre contrat d’abonnement. La suppression des données client n’entraîne pas de destruction de lecteurs physiques.

Le tableau ci-après répertorie certaines des solutions disponibles et fournit des exemples du type de données qu’elles collectent.

Solution Types de données
Capacity and Performance Données et métadonnées de performances
Update Management Métadonnées et données d'état
Gestion du journal Journaux des événements défini par l’utilisateur, journaux des événements Windows et/ou journaux d’activité IIS
Suivi des modifications Inventaire des logiciels, métadonnées de service Windows et de démon Linux, et métadonnées de fichiers Windows/Linux
Évaluation de SQL et d'Active Directory Données WMI, données du Registre, données de performances et résultats de vues de gestion dynamique de SQL Server

Le tableau suivant répertorie des exemples de types de données :

Type de données Fields
Alerte Alert Name, Alert Description, BaseManagedEntityId, Problem ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity, Category, Owner, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount
Configuration CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Événement EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Remarque : quand vous consignez des événements avec des champs personnalisés dans le journal des événements Windows, Log Analytics les collecte.
Métadonnées BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, IP Address, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Performances ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
State StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Sécurité physique

Azure Monitor est géré par le personnel de Microsoft. Toutes les activités sont journalisées et peuvent faire l’objet d’un audit. Azure Monitor est utilisé sous la forme d’un Service Azure et satisfait à toutes les exigences en matière de conformité et de sécurité Azure. Vous pouvez afficher plus d'informations sur la sécurité physique des ressources Azure à la page 18 du document Vue d'ensemble de la sécurité de Microsoft Azure. Les droits d’accès physique aux zones sécurisées sont modifiés en l’espace d’un jour ouvrable pour toute personne n’assumant plus de responsabilité en relation avec le service Azure Monitor, transfert et arrêt compris. Pour en savoir plus sur notre infrastructure physique globale, découvrez les Centre de données Microsoft.

Gestion des incidents

Azure Monitor inclut un processus de gestion des incidents auquel tous les services Microsoft adhèrent. Pour résumer :

  • Nous appliquons un modèle de responsabilité partagée en vertu duquel une partie de la sécurité relève de la responsabilité de Microsoft, et une autre de celle du client.
  • Nous gérons les incidents de sécurité liés à Azure :
    • Nous lançons une investigation lors de la détection d’un incident.
    • Nous évaluons l’impact et la gravité d’un incident via l’intervention d’un membre de l’équipe chargée de répondre aux appels relatifs aux incidents. Selon les éléments de preuve apportés, l’évaluation peut ou non entraîner une réaffectation à l’équipe chargée de répondre aux problèmes de sécurité.
    • Nous diagnostiquons un incident en demandant à des experts en réponse aux problèmes de sécurité de mener les investigations informatiques ou techniques nécessaire, et d’identifier des stratégies d’autonomie, d’atténuation des risques et de contournement. Si l’équipe de sécurité estime que des données client risquent d’être exposées à une personne illégitime ou non autorisée, le processus de notification d’incident au client commence en parallèle.
    • Nous stabilisons l’incident et assurons la récupération. L’équipe de réponse aux incidents crée un plan de récupération pour atténuer le problème. Des mesures d’endiguement de crise telles que la mise en quarantaine des systèmes affectés peuvent être prises immédiatement et parallèlement au diagnostic. Des mesures d’atténuation à plus long terme peuvent être planifiées, qui se interviennent une fois passé le risque immédiat.
    • Nous clôturons l’incident, puis établissons un bilan. L’équipe de réponse aux incidents dresse un bilan décrivant l’incident en détail, dans le but de réviser les stratégies, procédures et processus de façon appropriée afin d’éviter que l’événement se reproduise.
  • Nous informons les clients des incidents de sécurité :
    • Nous identifions les clients affectés, et communiquons à toute personne concernée une notice aussi détaillée que possible.
    • Nous rédigeons une notice pour fournir aux clients des informations suffisamment détaillées pour qu’ils puissent mener une investigation de leur côté et respecter les engagements qu’ils ont envers leurs utilisateurs finaux sans retarder indûment le processus de notification.
    • Nous confirmons et déclarons l’incident si nécessaire.
    • Nous avertissons les clients à l’aide d’une notification d’incident sans délai déraisonnable, et conformément aux obligations légales ou contractuelles applicables. Les notifications d’incidents de sécurité sont adressées à un ou plusieurs des administrateurs du client par tout moyen que Microsoft juge opportun, y compris par courrier électronique.
  • Nous assurons la formation et la préparation de nos équipes :
    • Le personnel de Microsoft est tenu de suivre une formation en matière de sécurité et de sensibilisation, qui l’aide à identifier et à signaler d’éventuels problèmes liés à la sécurité.
    • Les opérateurs du service Microsoft Azure sont soumis à des obligations de formation supplémentaires en relation avec leur accès aux systèmes sensibles d’hébergement des données client.
    • Le personnel de réponse aux problèmes de sécurité de Microsoft reçoit une formation spécialisée en relation avec les rôles qui lui sont confiés.

Bien que cela soit rare, Microsoft informe chaque client sous 24 heures en cas de perte significative de ses données.

Pour plus d’informations sur la façon dont Microsoft répond aux incidents de sécurité, voir Microsoft Azure Security Response in the Cloud (en anglais).

Conformité

Le programme de sécurité et de gouvernance des informations de l’équipe de maintenance et de développement logiciel Azure Monitor prend en charge ses besoins commerciaux et respecte les lois et réglementations telles que décrites sur Centre de confidentialité Microsoft Azure et Microsoft Trust Center Compliance. Y est également décrite la façon dont Azure Monitor fixe les exigences de sécurité, identifie les contrôles de sécurité et gère et analyse les risques. Chaque année, nous révisons les stratégies, normes, procédures et directives.

Chaque membre de l’équipe de développement reçoit une formation formelle en matière de sécurité des applications. En interne, nous utilisons un système de contrôle de version pour le développement de logiciels. Chaque projet de logiciel est protégé par le système de contrôle de version.

Microsoft dispose d’une équipe dédiée à la sécurité et à la conformité, qui surveille et évalue tous les services chez Microsoft. Les responsables de la sécurité des informations qui constituent l’équipe ne sont pas associés aux équipes d’ingénierie qui développent Log Analytics. Les responsables de la sécurité ont leur propre chaîne de gestion, et effectuent des évaluations indépendantes des produits et services pour s’assurer de la sécurité et de la conformité de ceux-ci.

Le conseil d’administration de Microsoft est informé via un rapport annuel de l’ensemble des programmes relatifs à la sécurité des informations mis en œuvre au sein de Microsoft.

L’équipe de maintenance et de développement logiciel de Log Analytics travaille en étroite collaboration avec les équipes Microsoft chargées des aspects juridiques et de conformité, ainsi qu’avec d’autres partenaires du secteur, afin d’acquérir un éventail de certifications.

Certifications et attestations

Azure Log Analytics répond aux exigences suivantes :

Notes

Dans certaines certifications/attestations, les Journaux Azure Monitor sont listés sous leur ancien nom : Insights opérationnels.

Flux de données de sécurité du cloud computing

Le diagramme suivant montre une architecture de sécurité cloud comme étant le flux d’informations provenant de votre entreprise et la manière dont il est sécurisé à mesure qu’il progresse vers Azure Monitor, avant son affichage final dans le Portail Azure. Des informations complémentaires sur chaque étape sont présentées à suite du diagramme.

Image de la collecte de données et de la sécurité des Journaux Azure Monitor

1. Inscription à Azure Monitor et à la collecte des données

Pour que votre organisation puisse envoyer des données aux Journaux Azure Monitor, vous configurez un agent Windows ou Linux s’exécutant sur des machines virtuelles Azure, ou sur des ordinateurs virtuels ou physiques de votre environnement ou d’un autre fournisseur de services cloud. Si vous utilisez Operations Manager, vous configurez l’agent Operations Manager à partir du groupe d’administration. Les utilisateurs (vous-même, d’autres utilisateurs ou un groupe de personnes) créent un ou plusieurs espaces de travail Log Analytics et inscrivent des agents à l’aide de l’un des comptes suivants :

Un espace de travail Log Analytics correspond à l’emplacement où les données sont collectées, agrégées, analysées et présentées. Un espace de travail sert essentiellement à partitionner les données, et chaque espace de travail est unique. Par exemple, vous pouvez choisir de gérer vos données de production avec un espace de travail, et vos données de test avec un autre espace de travail. En outre, les espaces de travail aident un administrateur à contrôler l’accès des utilisateurs aux données. Chaque espace de travail peut être associé à plusieurs comptes d’utilisateur, et chaque compte d’utilisateur peut accéder à plusieurs espaces de travail Log Analytics. Vous créez des espaces de travail en fonction d’une région de centre de données.

Pour Operations Manager, le groupe de gestion établit une connexion avec le service Azure Monitor. Vous configurez ensuite les systèmes gérés par un agent dans le groupe d’administration qui sont autorisés à collecter et envoyer des données au service. Selon la solution que vous avez activée, les données de ces solutions sont soit envoyées directement du serveur de gestion Operations Manager au service Azure Monitor, soit, en raison du volume de données collectées par le système géré par l’agent, envoyées directement au service à partir de l’agent. Dans le cas des systèmes non supervisés par Operations Manager, chaque système se connecte directement au service Azure Monitor en toute sécurité.

Toutes les communications entre les systèmes connectés et le service Azure Monitor sont chiffrées. Le protocole TLS (HTTPS) est utilisé pour le chiffrement. Le processus Microsoft SDL est suivi pour s’assurer que Log Analytics est à jour avec les dernières avancées en matière de protocoles cryptographiques.

Chaque type d’agent collecte des données de journal pour Azure Monitor. Le type de données collectées dépend de la configuration de votre espace de travail et d’autres fonctionnalités d’Azure Monitor.

2. Envoyer des données à partir d'agents

Vous enregistrez tous les types d’agents avec une clé d’inscription et une connexion sécurisée est établie entre l’agent et le service Azure Monitor à l’aide de l’authentification par certificat et TLS avec le port 443. Azure Monitor utilise un magasin de secrets pour générer et gérer les clés. Les clés privées sont remplacées tous les 90 jours, stockées dans Azure, et gérées par des opérations Azure qui suivent des pratiques réglementaires et de conformité strictes.

Avec Operations Manager, le groupe d’administration qui est inscrit auprès d’un espace de travail Log Analytics établit une connexion HTTPS sécurisée avec un serveur d’administration Operations Manager.

Pour les agents Windows ou Linux s’exécutant sur des machines virtuelles Azure, une clé de stockage en lecture seule est utilisée pour lire des événements de diagnostic dans des tables Azure.

Tout agent rendant compte à un groupe de gestion d’Operations Manager qui est intégré à Azure Monitor, si le serveur de gestion ne parvient pas à communiquer avec le service pour une raison quelconque, les données collectées sont stockées localement dans un cache temporaire du serveur de gestion. Les données feront alors l’objet d’une nouvelle tentative d’envoi toutes les huit minutes pendant deux heures. Dans le cas des données qui contournent le serveur de gestion et qui sont envoyées directement à Azure Monitor, le comportement est cohérent avec l’agent Windows.

Les données mises en cache de l’agent Windows ou du serveur d’administration sont protégées par le magasin d’informations d’identification du système d’exploitation. Si le service ne peut pas traiter les données au bout de deux heures, les agents mettent celles-ci en file d’attente. En cas de saturation de la file d’attente, l’agent commence à supprimer certains types de données, en commençant par les données de performances. La limite de file d’attente de l’agent est une clé de Registre que vous pouvez modifier si nécessaire. Étant donné que les données collectées sont compressées et envoyées au service en contournant les bases de données du groupe d’administration Operations Manager, aucune charge n’est ajoutée à ces données. Une fois que les données collectées sont envoyées, elles sont supprimées du cache.

Comme décrit ci-dessus, les données provenant d’agents du serveur d’administration ou d’agents connectés directement sont envoyées par le biais du protocole TLS aux centres de données Microsoft Azure. Vous pouvez également utiliser ExpressRoute pour sécuriser davantage les données. ExpressRoute vous permet de vous connecter directement à Azure à partir de votre réseau étendu (WAN) existant, comme un VPN MPLS fourni par un fournisseur de services réseau. Pour plus d’informations, consultez ExpressRoute et Le trafic de mon agent utilise-t-il ma connexion Azure ExpressRoute ?.

3. Le service Azure Monitor reçoit et traite les données

Le service Azure Monitor s’assure que les données entrantes proviennent d’une source approuvée en validant des certificats et l’intégrité des données à l’aide de l’authentification Azure. Les données brutes non traitées sont ensuite stockées dans des hubs d’événements Azure de la région dans laquelle les données finissent par être stockées au repos. Le type des données stockées dépend des types de solutions qui ont été importées et utilisées pour collecter des données. Ensuite, le service Azure Monitor traite les données brutes et les ingère dans la base de données.

La période de rétention des données collectées stockées dans la base de données varie selon le plan de tarification. Dans le cas du niveau gratuit, les données collectées restent disponibles pendant sept jours. Dans le cas du niveau payant, les données collectées restent disponibles pendant 31 jours par défaut, mais cette durée peut être étendue à 730 jours. Les données au repos sont chiffrées et stockées dans le stockage Azure pour garantir leur confidentialité et permettre leur réplication dans la région locale à l’aide du stockage localement redondant (LRS) ou du stockage redondant interzone (ZRS) dans les régions prises en charge. Pendant les deux dernières semaines, les données sont également stockées dans le cache sur disque SSD et ce cache est chiffré.

Les données du stockage de base de données ne sont pas modifiables une fois ingérées, mais sont supprimables par le chemin de l’API purge. Bien que les données ne soient pas modifiables, certaines certifications exigent qu’elles soient immuables et ne puissent être ni modifiées ni supprimées dans le stockage. L’immuabilité des données peut être obtenue à l’aide de l’exportation de données dans un compte de stockage configuré comme stockage immuable.

4. Utiliser Azure Monitor pour accéder aux données

Pour accéder à votre espace de travail Log Analytics, vous vous connectez au portail Azure à l’aide du compte professionnel ou d’un compte Microsoft que vous avez configuré précédemment. La totalité du trafic entre le Portail et le service Azure Monitor est envoyée par le biais d’un canal HTTPS sécurisé. Lorsque vous utilisez le portail, un ID de session est généré sur le client utilisateur (navigateur web), et les données sont stockées dans un cache local jusqu’à la fin de la session. Ensuite, le cache est supprimé. Les cookies côté client qui ne contiennent pas d’informations d’identification personnelle ne sont pas supprimés automatiquement. Les cookies de session sont marqués HTTPOnly et sécurisés. Après une période d’inactivité prédéfinie, la session du Portail Azure prend fin.

Clés (de sécurité) gérées par le client

Les données dans Azure Monitor sont chiffrées avec des clés gérées par Microsoft. Vous pouvez utiliser des clés de chiffrement gérées par le client pour protéger les données et les requêtes enregistrées dans vos espaces de travail. Les clés gérées par le client dans Azure Monitor vous offrent une plus grande flexibilité pour gérer les contrôles d’accès aux journaux.

Une fois les clés configurées, les nouvelles données ingérées dans les espaces de travail liés sont chiffrées avec votre clé stockée dans Azure Key Vault ou dans le HSM managé Azure Key Vault.

Stockage privé

Les journaux Azure Monitor s’appuient sur stockage Azure dans certains scénarios. Utilisez un stockage privé/géré par le client pour gérer votre compte de stockage chiffré personnellement.

La mise en réseau d’Azure Private Link vous permet de lier en toute sécurité les services PaaS Azure (notamment Azure Monitor) à votre réseau virtuel à l’aide de points de terminaison privés.

Customer Lockbox pour Microsoft Azure

Customer Lockbox pour Microsoft Azure fournit une interface permettant de vérifier et d’approuver ou refuser les demandes d’accès aux données client. Elle 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. Pour activer Customer Lockbox, vous avez besoin d’un cluster dédié.

Protection contre la falsification et immuabilité

Azure Monitor est une plateforme de données d’ajout uniquement mais qui inclut des dispositions pour supprimer des données à des fins de conformité. Vous pouvez définir un verrou sur votre espace de travail Log Analytics pour bloquer toutes les activités susceptibles de supprimer des données : purger, supprimer des tables et modifier la conservation des données au niveau de l’espace de travail. Toutefois, ce verrou peut toujours être supprimé.

Pour protéger totalement votre solution de supervision contre la falsification, nous vous recommandons d’exporter vos données vers une solution de stockage immuable.

Forum aux questions

Cette section fournit des réponses aux questions fréquentes.

Le trafic de mon agent utilise-t-il ma connexion Azure ExpressRoute ?

Le trafic vers Azure Monitor utilise le circuit ExpressRoute de peering Microsoft. Consultez la documentation ExpressRoute pour une description des différents types de trafic ExpressRoute.