Partager via

Configurer la portée de Microsoft Sentinel (contrôle RBAC au niveau des lignes) (version d'évaluation)

La fonctionnalité de délimitation de Microsoft Sentinel permet un contrôle d’accès basé sur les rôles (RBAC) au niveau des lignes, offrant ainsi un accès fin sans nécessiter de cloisonnement des espaces de travail. Cette fonctionnalité permet à plusieurs équipes de fonctionner en toute sécurité dans un environnement 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 l’étendue de Microsoft Sentinel ?

Microsoft Sentinel étend la gestion des autorisations dans le portail Defender afin que l’administrateur puisse accorder des autorisations à des sous-ensembles de données spécifiques dans les tables Sentinel. Pour créer des étendues, procédez comme suit :

Note

Les portées s’additionnent entre elles. Les utilisateurs affectés à plusieurs rôles obtiennent les autorisations les plus larges à leur disposition à partir de toutes leurs attributions. À titre d’exemple, si vous disposez simultanément d’un rôle de lecteur global Microsoft Entra et d’un rôle URBAC Defender XDR accordant des autorisations restreintes sur les tables système, les limitations d’étendue ne s’appliquent pas à ces tables grâce au rôle Microsoft Entra. Un autre exemple est que si vous détenez les mêmes autorisations de rôle dans Microsoft Defender XDR pour un espace de travail, avec deux étendues différentes, vous disposez de cette autorisation pour les deux étendues.

Les étendues concernent les tables Sentinel compatibles avec les transformations lors 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é cloud gèrent souvent 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. La définition de portée permet à chaque équipe SOC de fonctionner indépendamment au sein d'un espace de travail Sentinel partagé, afin qu'elles puissent examiner et répondre aux menaces au sein de leur domaine sans accéder aux données non liées.
  • Accès étendu pour les équipes externes, 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. La portée 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 de privilège minimum, ce qui garantit que les informations sensibles sont uniquement accessibles aux utilisateurs autorisés.

Prerequisites

Avant de commencer, vérifiez les conditions préalables suivantes :

  • Accès au portail Microsoft Defender : https://security.microsoft.com
  • Espaces de travail Microsoft Sentinel intégrés au portail Defender : les espaces de travail Sentinel doivent être disponibles dans le portail Defender avant que les rôles et les autorisations puissent être attribués
  • Sentinel activée dans RBAC unifié : vous devez activer Microsoft Sentinel dans URBAC avant d’utiliser cette fonctionnalité.
  • Autorisations requises pour la personne affectant l’étendue et les tables de balisage :
    • Permission « Gestion des autorisations de sécurité » (URBAC) pour créer des étendues et des affectations
    • Autorisation Opérations de données (Gérer) (URBAC) pour 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 auxautorisations>.
  2. Sélectionnez Microsoft Defender XDR.
  3. Ouvrez l’onglet Scopes.
  4. Sélectionnez Ajouter une portée Sentinel.
  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.

Note

Vous pouvez créer jusqu’à 100 étendues Sentinel uniques par locataire.

Capture d’écran de l’onglet et de la boîte de dialogue Ajouter une étendue Sentinel.

Étape 2 : Affecter 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.

    Capture d’écran de la boîte de dialogue permettant de créer un nom et une description d’un rôle personnalisé.

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

    Capture d’écran de la boîte de dialogue permettant d’attribuer des autorisations à un rôle personnalisé.

  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 simultanément à plusieurs étendues sur plusieurs espaces de travail, avec des droits d’accès agrégés sur toutes les étendues affectées. Les utilisateurs restreints peuvent uniquement accéder aux données SIEM associées à leurs étendues affectées.

Capture d’écran de l’attribution des périmètres Sentinel à un rôle personnalisé.

Étape 3 : Appliquer une étendue aux tables

Les étendues sont mises en place en balisant les données au moment de leur 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 auxtables>.

  2. Choisissez une table prenant en charge les transformations à l’ingestion.

  3. Sélectionnez la règle de balisage d’étendue.

    Capture d’écran illustrant l’onglet de la règle de balisage d’étendue.

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

  5. Activez l'option Règle de balise de portée.

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

    Exemple pour cadrer par lieu :

    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, la nouvelle règle peut prendre jusqu’à une heure pour prendre effet.

Conseil / Astuce

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

Capture d’écran de la règle de balise de portée de table.

É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 étendus peuvent accéder aux expériences 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. Toutes les données non explicitement délimitées ne sont pas visibles pour les utilisateurs délimités. Les utilisateurs non-scopés ont une visibilité sur toutes les données de la zone de travail

Les utilisateurs soumis à une étendue peuvent :

  • Afficher les alertes générées à partir de données délimitées
  • Gérer les alertes s'ils ont accès à tous les événements liés à l'alerte en question
  • 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 analyser les 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 le champ d'application.

Le SentinelScope_CF champ personnalisé est disponible pour une utilisation dans les requêtes et les règles de détection pour référencer l’étendue dans votre analytique.

Note

Lorsque vous créez des détections et des règles d’analytique personnalisées, vous devez projeter la SentinelScope_CF colonne dans son KQL pour rendre les alertes déclenchées visibles par les analystes délimités. Si cette colonne n’est pas projetée, les alertes échappent à l’étendue et restent invisibles pour les utilisateurs concernés par une étendue.

Capture d’écran des alertes filtrées par étendue Sentinel.

Limites

Les limites suivantes s'appliquent :

  • Données historiques : seules les données nouvellement ingérées sont concernées. Les données précédemment ingérées ne sont pas incluses et ne peuvent pas être prises en compte de manière rétroactive.
  • Prise en charge des tables : seules les tables compatibles avec les transformations lors de l’ingestion peuvent recevoir un balisage. Les tables personnalisées (CLv1) ne sont pas prises en charge. Les tables CLv2 sont prises en charge.
  • Placement des transformations : 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 permet pas la configuration des étendues. 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 30 jours et non des données comprises entre 0 et 30 jours.
  • Aucun héritage d’étendue automatique : les tables SecurityAlerts Log Analytics et SecurityIncidents n’héritent pas automatiquement de l’étendue des données/tables brutes à partir de laquelle elles ont été générées. Par conséquent, les utilisateurs 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 les tables XDR AlertsInfo et AlertsEvidence, pour lesquelles l’étendue est héritée automatiquement, ou
    • Appliquez l’étendue à ces tables Log Analytics manuellement (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 : les étendues Sentinel ne peuvent être attribuées qu’aux rôles RBAC Defender XDR. Les autorisations RBAC Azure 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 RBAC au niveau des lignes, telles que les notebooks Jupyter, ne permettent pas aux utilisateurs limités à un certain périmètre de voir les données de ces espaces de travail.

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 de l’incident et disposent de l’autorisation requise.
  • L'utilisateur à portée limitée ne peut voir que les données associées à leur portée. 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 étendre une table entière, utilisez une règle qui correspond à toutes les lignes (par exemple, à l’aide d’une condition toujours vraie). Les données déjà ingérées ne peuvent pas être soumises rétroactivement à une étendue.
  • Les utilisateurs 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

  • Last updated on