Configurer la délimitation de Microsoft Sentinel (RBAC au niveau des lignes)

Le périmètre de Microsoft Sentinel permet un contrôle d’accès en fonction des rôles (RBAC) au niveau des lignes, offrant ainsi un accès granulaire au niveau des lignes sans nécessiter de séparer les espaces de travail. La définition du périmètre dans Microsoft Sentinel permet à plusieurs équipes d’opérer en toute sécurité dans un environnement Microsoft Sentinel partagé, tout en utilisant des définitions de périmètre cohérentes et réutilisables dans l’ensemble des tables et des expériences utilisateur.

Configurez le périmètre dans le portail Microsoft Defender. Sentinel dans le portail Azure (Ibiza) ne prend pas en charge la définition d’un périmètre. Avant de commencer, assurez-vous de remplir les prérequis pour configurer le cadrage.

Qu’est-ce que la délimitation du périmètre dans Microsoft Sentinel ?

La définition du périmètre dans Microsoft Sentinel étend la gestion des autorisations dans le portail Defender afin que l’administrateur puisse accorder des autorisations sur des sous-ensembles spécifiques de données dans les tables Sentinel. Pour créer des périmètres, procédez comme suit :

• Définir des étendues logiques : créez des définitions d’étendue qui s’alignent sur votre structure organisationnelle (par unité commerciale, région ou sensibilité aux données)
• Affecter des utilisateurs ou des groupes à des étendues : affecter des utilisateurs ou des groupes spécifiques à une ou plusieurs étendues à l’aide du contrôle d’accès en fonction du rôle (RBAC unifié)
• Étiqueter les lignes de données au moment de l’ingestion : appliquer des balises d’étendue aux lignes des tables à l’aide de la gestion des tables, ce qui vous permet de créer des règles qui balisent automatiquement les données nouvellement ingérées
• Restreindre l’accès par étendue : limiter l’accès des utilisateurs aux alertes, incidents, requêtes de chasse et exploration de lac de données en fonction de l’étendue qui leur est attribuée

Remarque

Les portées s’additionnent entre elles. Les utilisateurs auxquels plusieurs rôles sont attribués obtiennent les autorisations les plus larges disponibles pour toutes leurs attributions. Par exemple, si vous occupez à la fois un rôle de lecteur global Entra et un rôle Defender URBAC qui fournit des permissions à portée sur les tables Système, vous n'êtes pas limité par les champs de portée des tables Système grâce au rôle Entra. Un autre exemple est que si vous avez les mêmes permissions de rôle dans Microsoft Defender pour un espace de travail, avec deux portées différentes, vous avez cette permission pour les deux portées.

Les étendues concernent les tables Sentinel compatibles avec les transformations lors de l’ingestion.

Cas d’utilisation pour la définition du périmètre de Microsoft Sentinel

Le cadrage de Microsoft Sentinel est utile dans les scénarios suivants :

• Équipes SOC distribuées ou fédérées : les grandes entreprises et les MSSP voient souvent fonctionner des modèles SOC fédérés où différentes équipes sont responsables de régions, d’unités commerciales ou de clients spécifiques. Le cloisonnement permet à chaque équipe SOC d’opérer de manière autonome au sein d’un espace de travail Sentinel partagé, afin qu’elle puisse enquêter sur les menaces relevant de son domaine et y répondre sans accéder à des données sans rapport.
• Accès étendu pour les équipes externes et non liées à la sécurité : Les équipes telles que la mise en réseau, les opérations informatiques ou la conformité nécessitent souvent l’accès à des sources de données brutes spécifiques sans avoir besoin de visibilité sur le contenu de sécurité plus large. Le filtrage au niveau des lignes permet à ces équipes externes d’accéder en toute sécurité uniquement aux données nécessaires à leur fonction.
• Protection des données sensibles : protégez certaines données ou tables en appliquant une approche d’accès aux données de privilège minimum, ce qui garantit que les informations sensibles sont uniquement accessibles aux utilisateurs autorisés.

Prérequis

Avant de commencer, vérifiez les prérequis suivants :

• Accès au portail Microsoft Defender :https://security.microsoft.com
• Microsoft Sentinel espaces de travail intégrés au portail Defender : les espaces de travail Sentinel doivent être disponibles dans le portail Defender avant de pouvoir attribuer des rôles et des autorisations.
• Sentinel activé dans RBAC unifié : vous devez activer Microsoft Sentinel dans URBAC avant d’utiliser cette fonctionnalité.
• Autorisations requises pour la personne qui attribue l’étendue et les tables d’étiquetage :
  • Autorisation de sécurité (Gérer) (URBAC) pour créer des périmètres et des affectations
  • Permissions d’opérations de données (gestion) et d’alertes (gestion ) (URBAC) pour la gestion de tables
  • Propriétaire de l’abonnement ou affecté avec l’autorisation Microsoft.Insights/DataCollectionRules/Write de créer des règles de collecte de données (DCR)

Étape 1 : Créer une étendue Sentinel

Pour créer une étendue Sentinel, procédez comme suit :

1. Dans le portail Microsoft Defender, accédez àAutorisations>.
2. Sélectionnez Microsoft Defender XDR.
3. Ouvrez l’onglet Périmètres.
4. Sélectionnez Ajouter une étendue Sentinel.
5. Entrez un nom de portée et une description facultative.
6. Sélectionnez Créer une étendue.

Vous pouvez créer plusieurs étendues et définir des noms et descriptions d’étendue personnalisés pour chaque étendue afin de refléter votre structure organisationnelle et vos stratégies.

Remarque

Vous pouvez créer jusqu’à 100 périmètres Sentinel uniques par locataire.

Étape 2 : Affecter des balises d’étendue à des utilisateurs ou des groupes

Pour affecter des balises d’étendue à des utilisateurs ou des groupes, procédez comme suit :

1. Dans Autorisations, ouvrez l’onglet Rôles .

2. Sélectionnez Créer un rôle personnalisé.

3. Entrez le nom et la description du rôle, puis sélectionnez Suivant.

   

4. Attribuez les autorisations requises au rôle, puis sélectionnez Appliquer.

   

5. Dans Affectations, entrez un nom et sélectionnez :

   • Utilisateurs ou groupes d’utilisateurs (groupes Microsoft Entra ID)
   • Sources de données et collections de données (espaces de travail Sentinel)

6. Sous Étendue, sélectionnez Modifier.

7. Sélectionnez une ou plusieurs étendues à attribuer à ce rôle.

8. Enregistrez le rôle.

Vous pouvez attribuer des utilisateurs à plusieurs périmètres simultanément dans plusieurs espaces de travail, et les droits d’accès sont cumulés à partir de tous les périmètres attribués. Les utilisateurs restreints peuvent uniquement accéder aux données SIEM associées aux étendues qui leur sont attribuées.

Remarque

Vous ne pouvez attribuer des étendues Sentinel qu’aux rôles RBAC de Defender XDR. Les autorisations Azure RBAC sur les espaces de travail et les autorisations du rôle global Entra ne sont pas prises en charge. Les expériences qui ne peuvent pas utiliser RBAC au niveau des lignes, telles que les notebooks Jupyter, n’autorisent pas les utilisateurs limités à afficher les données de ces espaces de travail.

Étape 3 : Baliser les tableaux avec l’attribut scope

Appliquer les périmètres d'application en marquant les données lors de leur ingestion. Ce processus d’étiquetage crée une règle de collecte de données (DCR) qui applique des balises d’étendue aux données nouvellement ingérées.

Gardez à l’esprit les limites suivantes avant de baliser une table :

• Seules les tables qui prennent en charge les transformations au moment de l’ingestion peuvent être marquées. Les tables personnalisées basées sur CLv1 ne sont pas prises en charge ; Les tables CLv2 sont prises en charge.
• Les tables XDR ne sont pas prises en charge, y compris la rétention étendue des tables XDR dans le lac.
• Vous ne pouvez ajouter des transformations que dans le même abonnement Azure qui contient l’espace de travail cible.
• Vous ne pouvez étiqueter que les données nouvellement ingérées. Les données précédemment ingérées ne sont pas incluses et ne peuvent pas être étendues rétroactivement.
• Les tables Log Analytics SecurityAlerts et SecurityIncidents n’héritent pas automatiquement du périmètre des tables brutes sources qui les ont générées ; les utilisateurs soumis à ce périmètre n’y ont donc pas accès par défaut. À titre de solution de contournement, soit :
  • Utilisez les tables XDR AlertsInfo et AlertsEvidence, où la portée est héritée automatiquement, ou
  • Définissez manuellement le périmètre pour ces tables Log Analytics. Cette méthode est limitée aux attributs de la table et peut ne pas être équivalente à l’héritage des tables de données sources.

Pour catégoriser une table, procédez comme suit :

1. Dans Microsoft Sentinel, accédez à Tables de configuration>.

2. Sélectionnez une table qui prend en charge les transformations au moment de l’ingestion.

3. Sélectionnez Règle de balise de portée.

   

4. Activez le bouton Autoriser l’utilisation des balises d’étendue pour RBAC.

5. Activez l’interrupteur Règle de balise de portée.

6. Définissez une expression KQL qui sélectionne des lignes à l’aide des opérateurs et des limites pris en charge par transformKQL.

   Exemple d’étendue par emplacement :

   Location == 'Spain'
   

7. Sélectionnez l’étendue à appliquer aux lignes correspondant à l’expression.

8. Enregistrez la règle.

Vous ne pouvez étiqueter que les données nouvellement ingérées. Les données précédemment ingérées ne sont pas incluses. Après avoir sauvegardé une règle de balise de scope, il peut falloir jusqu’à une heure pour que cette règle entre en vigueur.

Conseil

Vous pouvez créer plusieurs règles de balise d’étendue sur la même table pour étiqueter différentes lignes avec des étendues différentes. Les enregistrements peuvent appartenir à plusieurs étendues simultanément.

Étiquette manuelle des données à l’aide d’un DCR

Si votre organisation gère les schémas de tables et les transformations de temps d’ingestion en dehors du portail Microsoft Defender, vous pouvez appliquer directement les balises de portée dans Azure Monitor. Cette option prend en charge à la fois la configuration directe et les flux de travail automatisés de déploiement, y compris CI/CD. Complétez le schéma de la table et la configuration DCR avant d’activer l’accès à portée de vue pour la table dans Microsoft Sentinel.

1. Ajoutez une colonne personnalisée nommée SentinelScope_CF avec le string type de données au schéma de table. Pour plus d’informations, consultez Gérer les tables dans un espace de travail Log Analytics.

2. Créez ou mettez à jour un DCR pour la table. Ajoutez une transformation qui se remplit SentinelScope_CF avec les valeurs de portée Microsoft Sentinel pour chaque ligne. Pour des conseils sur la sélection et la configuration du DCR, voir Configurer la transformation de vos données.

3. Dans le portail Microsoft Defender, accédez à Microsoft Sentinel>Configuration>Tables.

4. Sélectionnez la table, puis sélectionnez la règle de la balise de portée.

5. Réglez l’accès au contrôle avec les balises de portée sur Activé. Laisser le statut de la règle défini sur Désactivé car le DCR applique les tags.

   

6. Cliquez sur Enregistrer.

Remarque

Activer l’accès Contrôle avec des balises de portée permet un accès à portée pour les lignes taguées par le DCR. Il ne crée pas la SentinelScope_CF colonne ni ne met à jour le DCR.

Étape 4 : Accéder aux données délimitées

Une fois que vous avez créé, affecté et appliqué des étendues à des tables, les utilisateurs étendus peuvent accéder à des expériences Microsoft Sentinel en fonction de leur étendue affectée. Toutes les nouvelles données ingérées reçoivent automatiquement une balise d’étendue. Les données historiques (précédemment ingérées) ne sont pas incluses. Les utilisateurs délimités ne peuvent pas voir les données qui ne sont pas explicitement délimitées. Les utilisateurs non limités à un périmètre ont accès à toutes les données dans l’espace de travail.

Les utilisateurs délimités peuvent :

• Affichez les alertes générées à partir de données délimitées.
• Gérez les alertes si vous avez accès à tous les événements associés à cette alerte.
• Affichez les incidents qui contiennent au moins une alerte délimitée.
• Gérez les incidents s’ils ont accès à toutes les alertes sous-jacentes et disposent de l’autorisation requise.
• Exécutez des requêtes de recherche avancée uniquement sur les lignes incluses dans le périmètre défini.
• Interroger et analyser les données dans le lac Sentinel (tables avec étendue).
• Filtrez les alertes et les incidents en fonction de leur étendue Sentinel.

Les alertes héritent de la portée des données sous-jacentes. Les incidents sont visibles si au moins une alerte se trouve dans le périmètre.

Utilisez le champ personnalisé SentinelScope_CF dans les requêtes et les règles de détection pour faire référence à la portée dans vos analyses.

Remarque

Lorsque vous créez des règles personnalisées de détection et d’analyse, vous devez projeter la SentinelScope_CF colonne dans le KQL pour ces règles afin que les alertes héritent correctement de la portée. Si vous n’incluez pas cette colonne, même les règles avec portée définie produisent des alertes sans portée définie qui ne sont pas visibles pour les utilisateurs relevant de cette portée.

Limitations de la définition de l’étendue dans Microsoft Sentinel

1. Si vous êtes un utilisateur sans périmètre, vous pouvez également sélectionner Toutes les données. En sélectionnant Toutes les données, la règle n’est pas portée par scope, s’exécute sur toutes les données, et n’est visible et modifiable que par les utilisateurs non scalés.

2. Suivez les étapes de l'assistant jusqu'au bout, puis enregistrez la règle.

   

Gardez à l’esprit les limites suivantes pour les détections personnalisées délimitées :

• Détections personnalisées sur-dessus AlertInfo et AlertEvidence ignorant les oscillations, puis vérifiez toutes les données.
• Ne créez pas de détections délimitées sur des tables non étendues. Ces détections ne donnent toujours aucun résultat.
• Les détections à portée de portée ne peuvent pas utiliser de fréquence personnalisée avec les tables XDR. Les tables XDR ne sont pas à portée de champ dans Sentinel, donc seules les détections non délimitées peuvent les interroger.

Créer des règles d’automatisation délimitées

Pour créer des règles d’automatisation étendues, procédez comme suit :

1. Dans le portail Microsoft Defender, accédez à Microsoft Sentinel>Configuration>Automation.

2. Ouvrez l’onglet Règles améliorées .

   

3. Sélectionnez Créer pour ajouter une règle d’automatisation, puis renseignez les détails de votre règle d’automatisation.

   

4. Sélectionnez l’étendue Sentinel à appliquer à la règle :

   • Si vous êtes un utilisateur délimité (vous avez une ou plusieurs étendues Sentinel affectées à vous), vous devez choisir une étendue.
   • Si vous êtes un utilisateur sans périmètre, vous pouvez choisir tous les périmètres Sentinel disponibles et futurs.

   

5. Enregistrez la règle.

La règle d’automatisation s’applique aux données associées au scope Sentinel que vous avez sélectionné pour la règle et n’est visible que pour les utilisateurs assignés à ce scope.

Remarque

Les playbooks et les intégrations ne prennent pas encore en charge la définition d’un périmètre pour Sentinel.

Fonctionnement des autorisations et de l’accès avec des données délimitées

Les points suivants décrivent comment les autorisations et l’accès délimité se comportent dans Microsoft Sentinel :

• Les utilisateurs peuvent afficher un incident s’ils ont accès à au moins une alerte dans l’incident. Ils peuvent gérer l’incident uniquement s’ils ont accès à toutes les alertes dans l’incident et disposent de l’autorisation requise.
• L’utilisateur associé à un périmètre ne peut voir que les données associées à son périmètre. Si l’alerte contient des entités auxquelles l’utilisateur n’a pas accès, l’utilisateur ne peut pas voir ces entités. Si l’utilisateur a accès à au moins une des entités associées, il peut voir l’alerte elle-même.
• Pour définir l’étendue d’une table entière, utilisez une règle qui correspond à toutes les lignes (par exemple, à l’aide d’une condition qui a toujours la valeur true). Les données précédemment ingérées ne peuvent pas être étendues rétroactivement.
• Les utilisateurs délimités ne peuvent pas gérer les ressources (telles que les règles de détection, les playbooks, les règles d’automatisation), sauf si l’autorisation leur est attribuée dans une attribution de rôle distincte.

Étapes suivantes

Utilisez les ressources suivantes pour continuer à planifier votre déploiement d’étendue :

• Passez en revue la liste des tables qui prennent en charge les transformations au moment de l’ingestion
• Planifier les noms de portée et la logique avant d’étiqueter les données
• Commencer par une étendue pilote pour une petite équipe ou un sous-ensemble de données
• En savoir plus sur le RBAC unifié dans Microsoft Defender