Configurer Microsoft Sentinel étendue (RBAC au niveau des lignes) (préversion)

Microsoft Sentinel’étendue fournit un contrôle d’accès en fonction du rôle (RBAC) au niveau des lignes, ce qui permet un accès granulaire au niveau des lignes sans nécessiter la séparation de l’espace de travail. Cette fonctionnalité permet à plusieurs équipes de fonctionner en toute sécurité dans un environnement de Microsoft Sentinel partagé tout en utilisant des définitions d’étendue cohérentes et réutilisables entre les tables et les expériences.

L’étendue est configurée dans le portail Microsoft Defender.

Qu’est-ce que Microsoft Sentinel’étendue ?

Microsoft Sentinel étendue étend la gestion des autorisations dans le portail Defender afin que l’administrateur puisse accorder des autorisations à des sous-ensembles spécifiques de données dans Sentinel tables. Pour créer des étendues, 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 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

Les étendues s’appliquent aux tables Sentinel qui prennent en charge les transformations au moment de l’ingestion.

Cas d'utilisation

• Équipes SOC distribuées/fédérées : les grandes entreprises et les fournisseurs de services de sécurité réseau mettent souvent en œuvre 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. L’étendue permet à chaque équipe SOC de fonctionner indépendamment au sein d’un espace de travail Sentinel partagé, garantissant ainsi qu’elle peut examiner et répondre aux menaces au sein de son domaine sans accéder à des données non liées.
• 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. L’étendue au niveau des lignes permet à ces équipes externes d’accéder en toute sécurité uniquement aux données pertinentes pour leur fonction.
• Protection des données sensibles : protégez certaines données/tables en appliquant une approche d’accès aux données avec privilège minimum, garantissant ainsi que les informations sensibles ne sont accessibles qu’aux utilisateurs autorisés.

Configuration requise

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 : Sentinel espaces de travail doivent être disponibles dans le portail Defender avant que des rôles et des autorisations puissent être attribués
• 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 étendues et des affectations
  • Autorisation d’opérations de données (Gérer) (URBAC) pour la gestion des 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

1. Dans le portail Microsoft Defender, accédez àAutorisationssystème>.
2. Sélectionnez Microsoft Defender XDR.
3. Ouvrez l’onglet Étendues .
4. Sélectionnez Ajouter Sentinel étendue.
5. Entrez un nom d’étendue et une description facultative.
6. Sélectionnez Créer une étendue.

Vous pouvez créer plusieurs étendues et définir vos propres valeurs pour chaque étendue afin de refléter votre structure organisationnelle et vos stratégies.

Étape 2 : Attribuer des balises d’étendues à des utilisateurs ou des groupes

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

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

3. Configurez 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, donnez-lui un nom et sélectionnez :

   • Utilisateurs ou groupes d’utilisateurs (groupes Azure AD)
   • 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.

Les utilisateurs peuvent être affectés à plusieurs étendues simultanément sur plusieurs espaces de travail, avec des droits d’accès agrégés sur toutes les étendues attribuées. Les utilisateurs restreints peuvent uniquement accéder aux données SIEM associées aux étendues qui leur sont attribuées.

Étape 3 : Étiqueter les tables avec l’étendue

Vous appliquez des étendues en étiquetant les données pendant l’ingestion. Ce balisage crée une règle de collecte de données (DCR) qui applique des balises d’étendue aux données nouvellement ingérées.

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 d’étendue.

   

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

5. Activez le bouton bascule de règle de balise d’étendue .

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.

Seules les données nouvellement ingérées sont étiquetées. Les données précédemment ingérées ne sont pas incluses. Après l’étiquetage, l’application de la nouvelle règle peut prendre jusqu’à une heure.

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

Une fois les étendues créées, affectées et appliquées aux tables, les utilisateurs délimités peuvent accéder à Sentinel expériences en fonction de l’étendue qui leur est attribuée. Toutes les données nouvellement ingérées sont automatiquement étiquetées avec l’étendue. Les données historiques (précédemment ingérées) ne sont pas incluses. Les données qui ne sont pas explicitement délimitées ne sont pas visibles par les utilisateurs délimités. Les utilisateurs sans étendue ont une visibilité sur toutes les données de l’espace de travail

Les utilisateurs délimités peuvent :

• Afficher les alertes générées à partir de données délimitées
• Gérer les alertes si elles ont accès à tous les événements liés à cette alerte
• Afficher les incidents qui contiennent au moins une alerte délimitée
• Gérer les incidents s’ils ont accès à toutes les alertes sous-jacentes et disposent de l’autorisation requise
• Exécuter des requêtes de repérage avancées sur des lignes délimitées uniquement
• Interroger et explorer des données dans le lac Sentinel (tables avec étendue)
• Filtrer les alertes et les incidents en fonction de leur étendue Sentinel

Les alertes héritent de l’étendue des données sous-jacentes. Les incidents sont visibles si au moins une alerte se trouve dans l’étendue.

Le SentinelScope_CF champ personnalisé peut être utilisé dans les requêtes et les règles de détection pour référencer l’étendue dans votre analytique.

Limitations

Les limitations suivantes s'appliquent :

• Données historiques : seules les données nouvellement ingérées sont délimitées. Les données précédemment ingérées ne sont pas incluses et ne peuvent pas être étendues rétroactivement.
• Prise en charge des tables : seules les tables qui prennent en charge les transformations au moment de l’ingestion peuvent être étiquetées. Les tables personnalisées (CLv1) ne sont pas prises en charge. Les tables CLv2 sont prises en charge.
• Placement de transformation : les transformations peuvent uniquement être ajoutées dans le même abonnement que l’abonnement de l’utilisateur.
• Étendues maximales : vous pouvez créer un maximum de 100 étendues Sentinel uniques par locataire.
• Portail Defender uniquement : Sentinel dans le Portail Azure (Ibiza) ne prend pas en charge l’étendue. Utilisez plutôt le portail Defender.
• Tables XDR non prises en charge : les tables XDR ne sont pas directement prises en charge. Si vous étendez la rétention des tables XDR dans Log Analytics, vous pouvez baliser, mais uniquement les données avec une rétention de plus de 30 jours, et non les données comprises entre 0 et 30 jours.
• Aucun héritage d’étendue automatique : les tables SecurityAlerts Log Analytics n’héritent SecurityIncidents pas automatiquement de l’étendue des données brutes/tables à partir desquelles elles ont été générées. Par conséquent, les utilisateurs délimités ne peuvent pas y accéder par défaut. Pour contourner ce problème, vous pouvez effectuer l’une des actions suivantes :
  • Utilisez le XDR AlertsInfo et AlertsEvidence les tables où l’étendue est automatiquement héritée, ou
  • Appliquez manuellement l’étendue à 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 qui ont généré ces alertes).
• Expériences prises en charge : Sentinel étendues ne peuvent être affectées qu’à Defender XDR rôles RBAC. Azure les autorisations RBAC sur les espaces de travail ou les autorisations de rôle global Entra ne sont pas prises en charge. Les expériences qui ne peuvent pas utiliser le RBAC au niveau des lignes, telles que les notebooks Jupyter, ne permettent pas aux utilisateurs limités à une étendue d’afficher les données de ces espaces de travail respectifs.

Autorisations et accès

• 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 délimité peut uniquement voir les données associées à son étendue. Si l’alerte contient des entités auxquelles l’utilisateur n’a pas accès, l’utilisateur ne peut pas les voir. 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

• Passez en revue la liste des tables qui prennent en charge les transformations au moment de l’ingestion
• Planifier les noms d’étendue et la logique avant de baliser 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 XDR