Gérer l’accès aux données Microsoft Sentinel par ressource

L’accès à un espace de travail est géré à l’aide de Azure RBAC. En règle générale, les utilisateurs qui ont accès à un espace de travail Log Analytics activé pour Microsoft Sentinel ont également accès à toutes les données de l’espace de travail, y compris au contenu de sécurité. Les administrateurs peuvent utiliser des rôles Azure pour configurer l’accès à des fonctionnalités spécifiques dans Microsoft Sentinel, en fonction des exigences d’accès au sein de leur équipe.

Toutefois, certains utilisateurs peuvent avoir besoin d’accéder uniquement à des données spécifiques dans votre espace de travail, mais qui ne doivent pas avoir accès à l’ensemble de l’environnement Microsoft Sentinel. Par exemple, vous souhaiterez peut-être fournir à une équipe d’opérations non liées à la sécurité (non-SOC) l’accès aux données d’événements Windows pour les serveurs dont elle est propriétaire.

Pour les utilisateurs qui n’ont besoin d’accéder qu’à des données spécifiques dans l’espace de travail, nous vous recommandons de configurer votre contrôle d’accès basé sur les rôles (RBAC) en fonction des ressources autorisées à ces utilisateurs, plutôt que de leur fournir l’accès à l’espace de travail ou à des fonctionnalités spécifiques de Microsoft Sentinel. Cette méthode est également connue sous le nom de mise en place du RBAC dans le contexte des ressources.

Lorsque les utilisateurs ont accès à Microsoft Sentinel données via les ressources auxquelles ils peuvent accéder au lieu de l’espace de travail, ils peuvent afficher les journaux et les classeurs à l’aide des méthodes suivantes :

Via la ressource elle-même, telle qu’une machine virtuelle Azure. Utilisez cette méthode pour afficher les journaux et les classeurs d’une ressource spécifique uniquement.
Via Azure Monitor. Utilisez cette méthode lorsque vous souhaitez créer des requêtes qui s’étendent sur plusieurs ressources et/ou groupes de ressources. Lorsque vous accédez aux journaux et aux classeurs dans Azure Monitor, définissez votre étendue à un ou plusieurs groupes de ressources ou ressources spécifiques.

Activez un RBAC dans le contexte de la ressource dans Azure Monitor. Pour plus d’informations, consultez Gérer l’accès aux données de journal et aux espaces de travail dans Azure Monitor.

Remarque

Si vos données ne sont pas une ressource Azure, telle que Syslog, CEF ou Microsoft Entra ID données, ou des données collectées par un collecteur personnalisé, vous devez configurer manuellement l’ID de ressource utilisé pour identifier les données et activer l’accès. Pour plus d'informations, consultez Configurer explicitement le RBAC basé sur le contexte des ressources pour les ressources non-Azure.

En outre, les fonctions et les recherches enregistrées ne sont pas prises en charge dans les contextes centrés sur les ressources. Par conséquent, les fonctionnalités de Microsoft Sentinel, telles que l’analyse syntaxique et la normalisation, ne sont pas prises en charge pour le RBAC basé sur le contexte des ressources dans Microsoft Sentinel.

Scénarios pour un RBAC dans le contexte de la ressource

Le tableau suivant met en évidence les scénarios dans lesquels le RBAC du contexte de ressource est le plus utile. Notez les différences dans les exigences d’accès entre les équipes SOC et les équipes non SOC.

Type d’exigence	Équipe SOC	Équipe hors SOC
Autorisations	L’espace de travail entier	Ressources spécifiques uniquement
Accès aux données	Toutes les données de l’espace de travail	Uniquement les données pour les ressources auxquelles l’équipe est autorisée à accéder
Expérience	L’expérience de Microsoft Sentinel complète, éventuellement limitée par les autorisations fonctionnelles attribuées à l’utilisateur	Requêtes de journal et classeurs uniquement

Si votre équipe a des exigences d’accès similaires à celles de l’équipe non SOC décrite dans le tableau ci-dessus, le RBAC du contexte de ressource peut être une bonne solution pour votre organization.

Par exemple, l’image suivante montre une version simplifiée d’une architecture d’espace de travail où les équipes de sécurité et d’exploitation ont besoin d’accéder à différents ensembles de données, et où le RBAC du contexte de ressource est utilisé pour fournir les autorisations requises.

Dans l’exemple de diagramme d’architecture RBAC ressource-contexte :

L’espace de travail Log Analytics activé pour Microsoft Sentinel est placé dans un abonnement distinct pour mieux isoler les autorisations de l’abonnement que les équipes d’applications utilisent pour héberger leurs charges de travail.
Les équipes d’applications ont accès à leurs groupes de ressources respectifs, où elles peuvent gérer leurs ressources.

Placer l’espace de travail dans un abonnement séparé et utiliser le RBAC en contexte ressource permet aux équipes d’application de consulter les journaux générés par toutes les ressources auxquelles elles ont accès, même lorsque les journaux sont stockés dans un espace de travail où ils n’ont pas accès direct. Les équipes d’applications peuvent accéder à leurs journaux via la zone Journaux de l’Portail Azure, pour afficher les journaux d’activité d’une ressource spécifique, ou via Azure Monitor, pour afficher tous les journaux auxquels elles peuvent accéder en même temps.

Configurer explicitement le RBAC de contexte de ressource pour les ressources non Azure

Les ressources Azure prennent nativement en charge le RBAC basé sur le contexte de la ressource, mais peuvent nécessiter des ajustements supplémentaires lors de l’utilisation de ressources non Azure. Par exemple, les données dans votre espace de travail Log Analytics activé pour Microsoft Sentinel qui ne sont pas des ressources Azure incluent les données Syslog, CEF ou Microsoft Entra ID, ou les données collectées par un collecteur personnalisé.

Pour configurer le RBAC contextuel ressource pour les données non-Azure, complétez la procédure suivante.

Pour configurer explicitement le RBAC de contexte de ressource :

Assurez-vous d’avoir activé le contrôle d’accès en fonction du rôle (RBAC) avec contexte de ressource dans Azure Monitor.
Créez un groupe de ressources pour chaque équipe d’utilisateurs qui doivent accéder à vos ressources sans l’ensemble de l’environnement Microsoft Sentinel.

Attribuez des autorisations de lecteur de journal pour chacun des membres de l’équipe.
Affectez des ressources aux groupes d’équipe de ressources que vous avez créés et étiquetez les événements avec les ID de ressource appropriés.

Lorsque Azure ressources envoient des données à Microsoft Sentinel, les enregistrements de journal sont automatiquement étiquetés avec l’ID de ressource de la source de données.

Conseil

Nous vous recommandons de regrouper les ressources auxquelles vous accordez l’accès sous un groupe de ressources spécifique créé à cet effet.

Si ce n’est pas possible, assurez-vous que votre équipe dispose d’autorisations de lecture de journal directement sur les ressources auxquelles vous souhaitez qu’elle puisse accéder.

Pour plus d’informations sur les ID de ressources, consultez :

ID de ressources avec transfert de journal

Lorsque des événements sont collectés à l’aide du format CEF (Common Event Format) ou Syslog, le transfert de journal est utilisé pour collecter des événements à partir de plusieurs systèmes sources.

Par exemple, quand une machine virtuelle de transfert CEF ou Syslog écoute les sources qui envoient des événements Syslog et les transfère à Microsoft Sentinel, l’ID de ressource de la machine virtuelle de transfert de journal est attribué à tous les événements qu’elle transfère.

Si vous avez plusieurs équipes, assurez-vous d’avoir des machines virtuelles de transfert de journal distinctes qui traitent les événements pour chaque équipe distincte.

Par exemple, la séparation de vos machines virtuelles garantit que les événements Syslog qui appartiennent à l’équipe A sont collectés à l’aide de la machine virtuelle du collecteur A.

Conseil

Lorsque vous utilisez une machine virtuelle locale ou une autre machine virtuelle cloud, telle qu’AWS, comme votre redirecteur de journal, vérifiez qu’elle dispose d’un ID de ressource en implémentant Azure Arc.
Pour mettre à l’échelle votre environnement de VM pour le transfert de journaux, envisagez de créer un ensemble de VM à l’échelle pour collecter vos journaux CEF et Syslog.

ID de ressource avec collecte Logstash

Si vous collectez vos données à l’aide du plug-in de sortie Microsoft Sentinel Logstash, utilisez le champ azure_resource_id pour configurer votre collecteur personnalisé afin d’inclure l’ID de ressource dans votre sortie.

Si vous utilisez le RBAC en contexte ressource et souhaitez que les événements collectés par l’API soient accessibles à des utilisateurs spécifiques, utilisez l’identifiant de ressource du groupe de ressources configuré dans Configurez explicitement le RBAC en contexte ressource pour les ressources non-Azure.

Par exemple, le fichier de configuration Logstash suivant montre comment ingérer les événements via une entrée Beats et les envoyer à un espace de travail Log Analytics via le plugin de sortie Microsoft Sentinel, avec le azure_resource_id champ défini pour taguer les événements avec un groupe de ressources spécifique pour le RBAC contextuel ressource :

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Conseil

Vous pouvez ajouter plusieurs output sections pour différencier les balises appliquées à différents événements.

Identifiants de ressource avec la collection d’API de Log Analytics

Lors de la collecte via l’API du collecteur de données Log Analytics, vous pouvez associer un ID de ressource à des événements à l’aide de l’en-tête de requête HTTP x-ms-AzureResourceId.

Alternatives au RBAC au niveau du contexte des ressources

Selon les autorisations requises dans votre organisation, l’utilisation du RBAC en contexte ressource peut ne pas satisfaire pleinement à toutes les exigences d’accès aux données de votre organisation. Par exemple, considérons si une organisation utilisant l’architecture d’espace de travail à abonnement séparé décrite dans Scénarios pour le RBAC en contexte ressource doit également accorder l’accès aux journaux Office 365 à une équipe d’audit interne. Dans ce cas, ils peuvent utiliser le RBAC au niveau de la table pour accorder à l’équipe d’audit l’accès à l’intégralité de la table OfficeActivity , sans accorder d’autorisations à une autre table.

La liste suivante décrit les scénarios dans lesquels d’autres solutions d’accès aux données peuvent mieux répondre à vos besoins :

Scénario	Solution
Une filiale dispose d’une équipe SOC qui nécessite une expérience complète Microsoft Sentinel.	Dans ce cas, utilisez une architecture multi-espaces de travail pour séparer vos autorisations de données. Pour plus d’informations, reportez-vous aux rubriques suivantes : Étendre Microsoft Sentinel entre les espaces de travail et les locataires > Travailler avec des incidents dans de nombreux espaces de travail à la fois
Vous souhaitez fournir l’accès à un type spécifique d’événement.	Par exemple, fournissez à un administrateur Windows l’accès aux événements Sécurité Windows dans tous les systèmes. Dans ce cas, utilisez RBAC au niveau de la table pour définir des autorisations pour chaque table.
Limiter l’accès à un niveau plus granulaire, non basé sur la ressource ou uniquement à un sous-ensemble des champs dans un événement	Par exemple, vous pourriez souhaiter limiter l’accès aux journaux Office 365 en fonction de la filiale d’un utilisateur. Dans ce cas, fournissez l’accès aux données à l’aide de l’intégration intégrée aux tableaux de bord et rapports Power BI.
Limiter l’accès par groupe d’administration	Placez Microsoft Sentinel sous un groupe d’administration distinct dédié à la sécurité, en veillant à ce que seules les autorisations minimales soient héritées des membres du groupe. Au sein de votre équipe de sécurité, attribuez des autorisations à différents groupes en fonction de chaque fonction de groupe. Étant donné que toutes les équipes ont accès à l’ensemble de l’espace de travail, elles ont accès à l’expérience de Microsoft Sentinel complète, limitée uniquement par les rôles Microsoft Sentinel qui leur sont attribués. Pour plus d’informations, consultez Autorisations dans Microsoft Sentinel.

Pour plus d’informations, reportez-vous aux rubriques suivantes :

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-08-14