Contrôler l'accès aux cas et aux alertes 1P
Ce guide s'adresse aux administrateurs et aux analystes de sécurité Google SecOps qui souhaitent contrôler l'accès aux requêtes et aux alertes propriétaires à l'aide du contrôle des accès basé sur les rôles (RBAC) pour les données. Il explique comment configurer des niveaux d'accès aux données dans la partie SIEM de la plate-forme et les mapper aux environnements SOAR afin que les utilisateurs ne puissent voir que les alertes et les cas dérivés des données auxquelles ils sont autorisés à accéder. Cette méthode vous permet d'appliquer des règles de gouvernance des données et d'améliorer la sécurité. Une fois cette étape terminée, les organisations peuvent limiter la visibilité des données en fonction des rôles et des responsabilités, ce qui améliore la conformité et réduit le risque d'exposition des données.
Terminologie clé
Les termes suivants sont utilisés tout au long de ce guide pour décrire les concepts et les composants du contrôle des accès basé sur les rôles pour les données.
- Alertes first party (1P) : détections générées par le moteur de détection Google SecOps SIEM, telles que les règles, les correspondances avec les renseignements sur les menaces ou les analyses de sécurité. Lorsque ces détections SIEM sont ingérées dans le composant SOAR à l'aide du connecteur Google SecOps, elles forment des alertes first party et sont regroupées dans des cas first party.
- Alertes tierces : alertes ingérées directement dans le composant SOAR à partir d'outils de sécurité externes (par exemple, des pare-feu tiers ou des agents de détection des points de terminaison) à l'aide d'intégrations SOAR distinctes. Ces alertes contournent le moteur de détection du SIEM et ne sont pas soumises aux niveaux d'accès aux données du SIEM.
Pour les alertes first party, Google SecOps propage les portées de données associées des événements sous-jacents au composant SOAR. Cette propagation permet aux analystes de consulter les alertes et les demandes associées uniquement s'ils ont accès aux niveaux de données des événements sous-jacents. Par exemple, un utilisateur du service financier peut avoir accès aux données financières ingérées dans Google SecOps, mais pas aux données de contact des clients. L'utilisateur financier ne peut voir que les alertes et les demandes associées aux données financières. Il ne peut pas voir les alertes ni les demandes associées aux données de contact du client.
Avant de commencer
Avant de configurer le RBAC des données pour les cas et les alertes 1P, assurez-vous de remplir les conditions suivantes :
- Votre instance Google SecOps doit être unifiée (SIEM et SOAR activés).
- Comportement du SIEM multi-instance : si vous avez plusieurs instances SIEM connectées à une seule instance SOAR, la propagation et l'application du champ d'application ne s'appliquent qu'à l'instance SIEM principale. Les niveaux d'accès des instances SIEM secondaires sont ignorés côté SOAR. Les alertes correspondantes sont visibles par tous les utilisateurs ayant accès à leur environnement attribué dans SOAR.
- Connecteur Chronicle : le connecteur Chronicle qui relie le composant SIEM au composant SOAR utilise l'API Chronicle moderne. Avant d'activer cette fonctionnalité, assurez-vous que le connecteur est mis à niveau de l'ancienne API Backstory vers l'API Chronicle. Pour en savoir plus, consultez Passer à l'API Chronicle.
Activer le contrôle RBAC des données pour les alertes et les cas first party
Les administrateurs Google SecOps (rôle "Administrateur de l'API Chronicle" dans Google Cloud IAM) peuvent activer le contrôle RBAC des données pour les alertes et les cas propriétaires dans leur instance. Deux scénarios sont possibles :
Scénario A : L'accès aux données SIEM est déjà appliqué
Si les contrôles d'accès aux données sont déjà actifs dans le composant SIEM, procédez comme suit pour étendre l'application aux alertes et aux cas propriétaires dans le composant SOAR :
- Connectez-vous à Google SecOps.
- Vérifiez que vos niveaux d'accès sont correctement configurés dans Paramètres du SIEM > Accès aux données.
- Attribuez des niveaux d'accès aux données aux utilisateurs dans la console Google Cloud à l'aide d' Google Cloud IAM.
- Dans Google SecOps, accédez à Paramètres SIEM > Accès aux données, puis cliquez sur Activer l'accès aux données dans SOAR.
- Mappez vos niveaux d'accès SIEM aux environnements SOAR, comme décrit dans Mapper les niveaux d'accès aux environnements.
L'accès aux données est désormais appliqué aux alertes et aux cas first party dans le composant SOAR. Cela s'applique à toutes les nouvelles alertes et à tous les nouveaux cas, ainsi qu'à ceux créés après l'application initiale de l'accès aux données SIEM.
Scénario B : L'accès aux données SIEM n'est PAS encore appliqué
Si vous n'avez pas encore activé les contrôles d'accès aux données dans SIEM, l'application sera activée simultanément pour SIEM et SOAR.
- Connectez-vous à Google SecOps.
- Vérifiez que vos niveaux d'accès sont correctement configurés dans Paramètres du SIEM > Accès aux données.
- Attribuez des niveaux d'accès aux données aux utilisateurs dans la console Google Cloud à l'aide d' Google Cloud IAM.
- Dans Google SecOps, accédez à Paramètres SIEM > Accès aux données, puis cliquez sur Appliquer l'accès aux données.
- Mappez vos niveaux d'accès SIEM aux environnements SOAR, comme décrit dans Mapper les niveaux d'accès aux environnements.
L'accès aux données est désormais appliqué dans le composant SIEM, ainsi que pour les nouvelles alertes et les nouveaux cas first party dans le composant SOAR.
Mapper les niveaux d'accès aux environnements
Pour associer les niveaux d'accès aux données SIEM à SOAR, mappez vos niveaux d'accès aux données SIEM aux environnements SOAR.
- Accédez à Paramètres SOAR > Environnements pour accéder à la page de configuration des environnements.
- Sélectionnez un environnement existant à modifier ou cliquez sur Ajouter un environnement.
- Associez des comptes en associant un ou plusieurs comptes SIEM à cet environnement.
- Recherchez le champ Champs d'application de l'accès aux données et sélectionnez le ou les champs d'application SIEM requis.
- Règles de mappage :
- Un niveau d'accès ne peut être mappé qu'à un seul environnement.
- Plusieurs niveaux d'accès peuvent être associés à un même environnement.
- Cliquez sur Enregistrer pour appliquer le mappage entre le champ d'application et l'environnement.
Mappage de secours de l'environnement
Lorsque le mappage du niveau d'accès à l'environnement est configuré, les alertes SIEM avec un niveau d'accès mappé sont automatiquement attribuées à l'environnement SOAR associé. Ce paramètre remplace les paramètres d'environnement du connecteur Chronicle.
Si une alerte SIEM n'est pas associée à un champ d'application (global) ou si son champ d'application n'est pas mappé à un environnement, elle est acheminée vers l'environnement de secours. L'environnement de secours est défini par le paramètre Environment ou Environment Field Name dans le connecteur Chronicle.
Comprendre l'évaluation des accès
Cette section décrit comment Google SecOps évalue l'accès des utilisateurs aux requêtes et aux alertes en fonction des environnements et des niveaux d'accès attribués. Pour afficher une demande ou une alerte 1P, un utilisateur doit disposer des autorisations d'environnement et de portée.
Logique de propagation du champ d'application
- Champ d'application des alertes : une alerte ingérée est associée au niveau d'accès aux données qui lui est attribué par les règles de détection Google SecOps SIEM.
- Périmètre d'une demande : une demande hérite automatiquement de l'union de tous les périmètres de ses alertes associées. Par exemple, si un cas regroupe l'alerte 1 (champ d'application A) et l'alerte 2 (champ d'application B), il hérite des deux champs d'application.
Règles d'accès
Pour accéder à une ressource (demande ou alerte), un utilisateur doit disposer des éléments suivants :
- Accès à l'environnement SOAR attribué à la ressource.
- Accès à tous les niveaux d'accès aux données attribués à la ressource.
Scénarios d'évaluation
Le tableau suivant montre comment l'accès des utilisateurs est évalué dans différents scénarios :
| Alertes sur les demandes | Champs d'application des demandes | Portées attribuées à l'utilisateur | Niveau d'accès de l'utilisateur | Accès accordé à la demande et aux alertes associées ? | Explication |
|---|---|---|---|---|---|
| Alerte 1 (champ d'application 1) | Champ d'application 1 | Champ d'application 1 | Utilisateur avec accès limité | Oui | L'utilisateur a accès au champ d'application unique attribué à la demande. |
| Alerte 1 (périmètre 1) et alerte 2 (périmètre 2) | Émissions de scope 1 et de scope 2 | Champ d'application 1 | Utilisateur avec accès limité | Non | Il manque le niveau 2 à l'utilisateur. Il doit avoir accès à tous les niveaux attribués à la demande. |
| Alerte 1 (périmètre 1) et alerte 2 (périmètre 2) | Émissions de scope 1 et de scope 2 | Émissions de scope 1 et de scope 2 | Utilisateur avec accès limité | Oui | L'utilisateur a accès à tous les niveaux d'accès attribués à la demande. |
| Alerte 1 (périmètre 1) et alerte 2 (périmètre 2) | Émissions de scope 1 et de scope 2 | Monde | Utilisateur global | Oui | Les utilisateurs globaux contournent le filtrage du champ d'application et peuvent voir toutes les demandes. |
| Alerte 1 (niveau d'accès global) | Monde | Monde | Utilisateur global | Oui | Les utilisateurs globaux contournent le filtrage du champ d'application et peuvent voir toutes les demandes. |
| Alerte 1 (champ d'application 1) et alerte 2 (champ d'application global) | Monde | Champ d'application 1 | Utilisateur avec accès limité | Non | Les demandes à portée mondiale sont réservées aux utilisateurs mondiaux. |
| Alerte 1 (champ d'application 1) et alerte 2 (champ d'application global) | Monde | Monde | Utilisateur global | Oui | Les utilisateurs globaux contournent le filtrage du champ d'application et peuvent voir toutes les demandes. |
| Alerte 1 (niveau d'accès global) | Monde | Champ d'application 1 | Utilisateur avec accès limité | Non | Les demandes à portée mondiale sont réservées aux utilisateurs mondiaux. |
Règles de regroupement des cas et de définition du champ d'application des entités
- Regroupement limité par l'environnement : les alertes ne peuvent être regroupées dans une seule demande que si leurs niveaux d'accès mappés les redirigent vers le même environnement.
- Accumulation de portées : lorsque des alertes avec des portées différentes sont mappées au même environnement et regroupées dans une demande, la demande hérite de toutes ces portées.
- Impact des alertes sans champ d'application : si une alerte sans champ d'application est regroupée avec une alerte avec champ d'application dans l'environnement de secours, la demande hérite du champ d'application global, ce qui la rend visible uniquement pour les utilisateurs globaux.
- Définition du champ d'application des entités uniques : une entité unique hérite des champs d'application de toutes les alertes dans lesquelles elle apparaît.
- Définition du champ d'application des entités concernées : les entités concernées n'héritent que du champ d'application de leur alerte parente.
Modifier les mappages entre les portées et les environnements
Lorsque vous modifiez ou supprimez un mappage de portée, l'impact dépend de la nouveauté ou de l'ancienneté des alertes et des demandes.
- Déplacer un niveau d'accès : modifier le mappage d'un niveau d'accès de l'environnement A vers l'environnement B :
- Nouvelles alertes et nouvelles demandes : elles sont transférées vers l'environnement B.
- Alertes et demandes existantes : elles restent dans l'environnement A. Les utilisateurs peuvent y accéder s'ils disposent des autorisations pour l'environnement A et pour le champ d'application attribué.
- Supprimer un mappage de champ d'application : dissocier un champ d'application d'un environnement :
- Nouvelles alertes et demandes : elles sont redirigées vers l'environnement de secours. Visible uniquement pour les utilisateurs mondiaux et ceux ayant accès à l'environnement de secours.
- Alertes et demandes existantes : elles restent dans leur environnement d'origine, mais ne sont visibles que par les utilisateurs globaux, car le champ d'application n'est plus mappé.
Gérer les cas manuels et de dépassement
Cette section explique comment gérer les demandes créées manuellement ou résultant d'un trop grand nombre d'alertes.
Créer des demandes manuelles
- Dans l'onglet Demandes, cliquez sur Créer une demande manuelle.
- Sélectionnez l'environnement cible.
- Sélectionnez un niveau d'accès aux données. La liste affiche les portées mappées à l'environnement et celles attribuées à votre compte utilisateur.
- S'il n'existe aucun champ d'application chevauchant, la liste est vide et vous ne pouvez pas envoyer la demande.
- Les utilisateurs globaux peuvent sélectionner n'importe quel champ d'application mappé à l'environnement.
- Saisissez les détails de la demande, puis cliquez sur Envoyer. Le cas et son alerte manuelle héritent du champ d'application sélectionné.
Demandes de débordement
Les cas de dépassement regroupent les alertes dans plusieurs champs d'application sans suivre le modèle d'entité partagée. Ils sont associés au champ d'application global et ne sont visibles que par les utilisateurs globaux.
Rechercher des portées sur la page "Demandes"
Vous pouvez afficher les niveaux d'accès aux données attribués à une demande à plusieurs endroits de l'interface Google SecOps.
En-tête de la demande
Les niveaux d'accès attribués s'affichent sous forme de libellés en lecture seule à côté du champ Environnement. Maintenez le pointeur sur la zone pour afficher la liste complète.
Table "Liste des demandes"
Vous pouvez également afficher les niveaux d'accès directement dans le tableau "Liste des demandes" :
- Une colonne Niveaux d'accès aux données est disponible dans le tableau "Liste des demandes".
- Cette colonne affiche les champs d'application attribués à la demande (séparés par une virgule s'il y en a plusieurs).
- Vous pouvez filtrer votre file d'attente en saisissant le nom ou les noms de portée dans le filtre de texte de la colonne.
Gérer les suppressions de portée
Cette section explique ce qui se passe pour les cas et les alertes existants lorsqu'un niveau d'accès données est supprimé du côté SIEM de la plate-forme.
Si un administrateur supprime un niveau d'accès aux données dans Paramètres SIEM > Accès aux données :
- La portée est automatiquement dissociée de tout environnement SOAR.
- Application de l'accès : étant donné que le champ d'application est supprimé du composant SIEM et de Cloud IAM, seuls les utilisateurs globaux (ou ceux qui détiennent encore la revendication de jeton mise en cache) pourront accéder à ces alertes et cas historiques.
Dépannage
Cette section décrit les performances attendues et fournit des solutions en libre-service pour les problèmes de déploiement courants.
Latence et limites
La propagation des modifications apportées aux mappages entre les portées et les environnements ou à l'activation initiale peut prendre jusqu'à 30 secondes.
Validation et test
Pour valider votre configuration, testez l'accès aux requêtes et aux alertes à l'aide de comptes utilisateur disposant de différentes autorisations d'environnement et de portée. Vérifiez que les utilisateurs ne peuvent voir que les données pour lesquelles ils sont autorisés.
Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.