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

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 le 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 de leur équipe.

Toutefois, il se peut que certains utilisateurs aient besoin d’accéder uniquement à des données spécifiques dans votre espace de travail, sans pour autant avoir accès à l’ensemble de l’environnement Microsoft Sentinel. Par exemple, vous pouvez autoriser une équipe d’opérations autres que de sécurité à accéder 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) sur la base des ressources auxquelles vos utilisateurs sont autorisés à accéder, plutôt que de leur donner accès à l’espace de travail ou à des fonctionnalités spécifiques de Microsoft Sentinel. Cette méthode est également appelée configuration de RBAC dans le contexte de la ressource.

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

• Via la ressource elle-même, par exemple, une machine virtuelle Azure. Utilisez cette méthode pour afficher uniquement les journaux et classeurs d’une ressource spécifique.

• Via Azure Monitor. Utilisez cette méthode quand vous souhaitez créer des requêtes qui s’étendent sur plusieurs ressources et/ou groupes de ressources. Quand vous accédez à des journaux et classeurs dans Azure Monitor, définissez votre étendue sur 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 du journal et aux espaces de travail dans Azure Monitor.

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

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

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

Par exemple, l’image suivante montre une version simplifiée de l’architecture d’un espace de travail dans lequel les équipes chargées de la sécurité et des opérations ont besoin d’accéder à différents ensembles de données, et le RBAC de contexte de ressources est utilisé pour fournir les autorisations nécessaires.

Dans cette image :

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

Cet abonnement distinct et le RBAC du contexte de ressource permettent à ces équipes d’afficher les journaux générés par les ressources auxquelles elles ont accès, même lorsque les journaux sont stockés dans un espace de travail où elles n’ont pas d’accès direct. Les équipes d’applications peuvent accéder à leurs journaux via la zone journaux d’activité du portail Azure, pour afficher les journaux d’activité d’une ressource spécifique, ou via Azure Monitor, pour afficher tous les journaux d'activité auxquels elles peuvent accéder en même temps.

Configurer explicitement le système RBAC du contexte de ressources pour les ressources non-Azure

Les ressources Azure offrent une prise en charge intégrée du contrôle d’accès en fonction du rôle (RBAC) de contexte de ressource, mais peuvent nécessiter un réglage plus précis lors de l’utilisation de ressources non Azure. Par exemple, les données de votre espace de travail Log Analytics activé pour Microsoft Sentinel qui ne sont pas des ressources Azure comprennent les données Syslog, CEF ou AAD, ou les données recueillies par un collecteur personnalisé.

Suivez les étapes suivantes si vous souhaitez configurer un RBAC dans le contexte de la ressource tandis que vos données ne sont pas des ressources Azure.

Pour configurer explicitement un RBAC dans le contexte de la ressource :

1. Assurez-vous que vous avez activé un RBAC dans le contexte de la ressource dans Azure Monitor.

2. Créez un groupe de ressources pour chaque équipe d’utilisateurs qui a besoin d’accéder à vos ressources, mais pas à l’intégralité de l’environnement Microsoft Sentinel.

   Attribuez des autorisations de lecture du journal à chacun des membres de l’équipe.

3. Attribuez des ressources aux groupes d’équipes de ressources que vous avez créés et balisez les événements avec les ID de ressource appropriés.

   Quand des ressources Azure envoient des données à Microsoft Sentinel, les enregistrements de journal sont automatiquement marqué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 les rubriques suivantes :

   • ID de ressources avec transfert de journal
   • ID de ressources avec collecte Logstash
   • ID de ressources avec la collecte de l’API Log Analytics

ID de ressources avec transfert de journal

Quand les événements sont collectés à l’aide de Common Event Format (CEF) ou de Syslog, un transfert de journal est utilisé pour collecter les événements 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 que vous avez des machines virtuelles de transfert de journal distinctes traitant les événements pour chaque équipe.

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 collecteur A.

ID de ressource avec collecte Logstash

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

Si vous utilisez un RBAC dans le contexte de la ressource et 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 illustre 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

ID de ressource avec collecte de l’API Log Analytics

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

Si vous utilisez un RBAC dans le contexte de la ressource et 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.

Alternatives au RBAC par contexte de ressources

Selon les autorisations requises dans votre organisation, il se peut que l’utilisation d’un RBAC dans le contexte de la ressource n’offre pas une solution complète. Considérons par exemple que l’organisation 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’ensemble de la table OfficeActivity, sans accorder d’autorisations à aucune autre table.

La liste suivante décrit des situations dans lesquelles d’autres solutions d’accès aux données peuvent mieux répondre à vos besoins :

Étapes suivantes

Pour plus d’informations, consultez Autorisations dans Microsoft Sentinel.