Gérer l’accès aux données de Microsoft Sentinel par ressources
L’accès à un espace de travail est géré en utilisant le contrôle d’accès en fonction du rôle Azure (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 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.
Remarque
Si vos données ne sont pas des ressources Azure, telles que les données Syslog, CEF ou Microsoft Entra ID, ou les données recueillies par un collecteur personnalisé, vous devrez configurer manuellement l’ID de ressource utilisé pour identifier les données et en autoriser l’accès. Pour plus d’informations, consultez Configurer explicitement le système RBAC du contexte de 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 et la normalisation ne sont pas prises en charge pour le RBAC dans le contexte de la ressource 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 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.
| 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 de ressources auxquelles l’équipe est autorisée à accéder |
| Expérience | Expérience 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é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 :
Assurez-vous que vous avez activé un RBAC dans le contexte de la ressource dans Azure Monitor.
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.
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
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.
Conseil
- Quand vous utilisez une machine virtuelle locale ou une autre machine virtuelle dans le cloud, telle que AWS, en tant que redirecteur de journal, assurez-vous qu’elle possède un ID de ressource en implémentant Azure Arc.
- Pour mettre à l’échelle votre environnement de machine virtuelle de transfert de journal, pensez à créer un groupe de machines virtuelles identiques 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 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>
}
}
Conseil
Vous pouvez ajouter plusieurs sections output pour différencier les balises appliquées à différents événements.
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 :
| Scénario | Solution |
|---|---|
| Une filiale a une équipe SOC qui requiert une expérience Microsoft Sentinel complète. | Dans ce cas, utilisez une architecture à plusieurs espaces de travail pour séparer vos autorisations de données. Pour plus d’informations, consultez : |
| Vous souhaitez donner accès à un type d’événement spécifique. | Par exemple, accorder à un administrateur Windows l’accès aux événements de sécurité Windows dans tous les systèmes. Dans de tels cas, utilisez un RBAC au niveau des tables afin de définir des autorisations pour chaque table. |
| Limiter l’accès à un niveau plus granulaire, soit non basé sur la ressource, soit uniquement à un sous-ensemble des champs d’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, vous pouvez donner accès aux données en utilisant l’intégration avec les tableaux de bord et rapports Power bi. |
| Limiter l’accès par groupe d’administration | Placez Microsoft Sentinel dans un groupe de gestion distinct dédié à la sécurité, en veillant à ce que seules les autorisations minimales soient accordées aux membres du groupe. Au sein de votre équipe de sécurité, attribuez des autorisations à différents groupes selon la fonction de chacun. Étant donné que toutes les équipes ont accès à l’ensemble de l’espace de travail, elles auront accès à l’intégralité de l’expérience Microsoft Sentinel, limitée uniquement par les rôles Microsoft Sentinel qui leur ont été attribués. Pour plus d’informations, consultez Autorisations dans Microsoft Sentinel. |
Contenu connexe
Pour plus d’informations, consultez l’article suivant :