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.

Dans ce cas, nous vous recommandons de configurer votre contrôle d’accès en fonction du rôle (RBAC) en fonction des ressources autorisées pour vos utilisateurs, au lieu de leur fournir l’accès à l’espace de travail ou à des fonctionnalités Microsoft Sentinel spécifiques. Cette méthode est également appelée configuration du RBAC du contexte de ressource.

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 le contrôle d’accès en fonction du contexte de 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 contrôle d’accès en fonction du 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, Microsoft Sentinel fonctionnalités telles que l’analyse et la normalisation ne sont pas prises en charge pour le contrôle d’accès en fonction du contexte de ressource dans Microsoft Sentinel.

Scénarios de RBAC de contexte de 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 non 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 cette image :

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.

Ce RBAC d’abonnement et de contexte de ressource distinct permet à ces équipes d’afficher 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 d’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 contrôle d’accès en fonction du contexte des ressources pour les ressources non Azure

Azure ressources disposent d’une prise en charge intégrée du contrôle d’accès en fonction du contexte de ressource, mais peuvent nécessiter un réglage supplémentaire lors de l’utilisation de ressources non Azure. Par exemple, les données de votre espace de travail Log Analytics activées pour les Microsoft Sentinel qui ne sont pas Azure ressources incluent les données Syslog, CEF ou AAD, ou les données collectées par un collecteur personnalisé.

Procédez comme suit si vous souhaitez configurer le contrôle d’accès en fonction du contexte de ressource, mais que vos données ne sont pas une ressource Azure.

Pour configurer explicitement le contrôle d’accès en fonction du contexte de ressource :

Vérifiez que vous avez activé le contrôle d’accès en fonction du 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 le cas, assurez-vous que votre équipe dispose d’autorisations de lecteur de journal directement sur les ressources auxquelles vous souhaitez qu’elle accède.

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

ID de ressource 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, lorsqu’une machine virtuelle cef ou syslog réacheminant écoute les sources qui envoient des événements Syslog et les transfère à Microsoft Sentinel, l’ID de ressource de machine virtuelle de transfert du journal est affecté à tous les événements qu’elles transfèrent.

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 machine virtuelle de transfert de journaux, envisagez de créer un groupe de machines virtuelles identiques pour collecter vos journaux CEF et Syslog.

ID de ressource avec la collection 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 contrôle d’accès en fonction du contexte de ressource et que vous souhaitez que les événements collectés par l’API soient disponibles pour des utilisateurs spécifiques, utilisez l’ID de ressource du groupe de ressources que vous avez créé pour vos utilisateurs.

Par exemple, le code suivant montre un exemple de fichier de configuration Logstash :

 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.

ID de ressource avec la collection d’API Log Analytics

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

Alternatives au RBAC du contexte de ressource

Selon les autorisations requises dans votre organization, l’utilisation du contrôle d’accès en fonction du contexte de ressource peut ne pas fournir une solution complète. Par exemple, déterminez si le organization dont l’architecture est décrite dans la section précédente doit également accorder l’accès aux journaux d’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 souhaiterez peut-être 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-04-23