Présentation de l'impact du contrôle RBAC des données sur les fonctionnalités
Le contrôle des accès aux données basé sur les rôles (RBAC des données) est un modèle de sécurité qui limite l'accès des utilisateurs aux données en fonction de leurs rôles individuels au sein d'une organisation. Une fois le RBAC des données configuré dans un environnement, vous commencez à voir les données filtrées dans les fonctionnalités de Google Security Operations. Le RBAC des données contrôle l'accès des utilisateurs en fonction des champs d'application qui leur sont attribués et garantit qu'ils ne peuvent accéder qu'aux informations autorisées. Cette page présente l'impact du RBAC des données sur chaque fonctionnalité de Google SecOps.
Pour comprendre le fonctionnement du RBAC des données, consultez la présentation du RBAC des données.
Rechercher
Les données renvoyées dans les résultats de recherche sont basées sur les niveaux d'accès aux données de l'utilisateur. Les utilisateurs ne peuvent voir que les résultats des données correspondant aux champs d'application qui leur sont attribués. Si plusieurs champs d'application sont attribués aux utilisateurs, la recherche est exécutée sur les données combinées de tous les champs d'application autorisés. Les données appartenant à des champs d'application auxquels l'utilisateur n'a pas accès n'apparaissent pas dans les résultats de recherche.
Accès aux demandes d'assistance
La recherche de cas et de l'historique des cas dans la recherche SIEM n'est pas compatible avec les champs d'application du contrôle RBAC des données. Un utilisateur autorisé à effectuer une recherche SIEM peut rechercher des demandes et l'historique des demandes dans tous les champs d'application des données.
Règles
Les règles sont des mécanismes de détection qui analysent les données ingérées et aident à identifier les menaces de sécurité potentielles. Les règles peuvent être classées comme suit :
Règles limitées : associées à un champ d'application de données spécifique. Les règles limitées ne peuvent s'appliquer qu'aux données qui entrent dans la définition de ce champ d'application. Les utilisateurs ayant accès à un champ d'application peuvent afficher et gérer ses règles.
Règles globales : avec une visibilité plus large, ces règles peuvent s'appliquer aux données de tous les champs d'application. Pour maintenir la sécurité et le contrôle, seuls les utilisateurs disposant d'un champ d'application global peuvent afficher et créer des règles globales.
La génération d'alertes est limitée aux événements qui correspondent au champ d'application de la règle. Si une règle n'a pas de champ d'application attribué, elle s'exécute dans le champ d'application global et s'applique à toutes les données.
Le contrôle RBAC des données a les impacts suivants sur les règles :
Le contrôle RBAC des données est activé avant l'attribution de champs d'application aux règles : toutes les règles existantes se voient automatiquement attribuer un champ d'application global. Attribuez des champs d'application à chaque règle en fonction de vos exigences de contrôle des accès aux données.
Le contrôle RBAC des données est activé après l'attribution de niveaux d'accès aux règles : les règles limitées s'appliquent aux données ingérées en fonction de leurs niveaux d'accès définis, même avant l'activation du contrôle RBAC des données. Cela permet aux utilisateurs de voir les détections générées après les attributions de champ d'application.
Le champ d'application associé à une règle détermine la manière dont les utilisateurs globaux et limités peuvent interagir avec elle. Les autorisations d'accès sont résumées dans le tableau suivant :
| Action | Utilisateur global | Utilisateur limité |
|---|---|---|
| Peut afficher les règles limitées | Oui | Oui (uniquement si le champ d'application de la règle se trouve dans les champs d'application attribués à l'utilisateur)
Par exemple, un utilisateur disposant des champs d'application A et B peut voir une règle avec le champ d'application A, mais pas une règle avec le champ d'application C. |
| Peut afficher les règles globales | Oui | Non |
| Peut créer et mettre à jour des règles limitées | Oui | Oui (uniquement si le champ d'application de la règle se trouve dans les champs d'application attribués à l'utilisateur)
Par exemple, un utilisateur disposant des champs d'application A et B peut créer une règle avec le champ d'application A, mais pas avec le champ d'application C. |
| Peut créer et mettre à jour des règles globales | Oui | Non |
Détections
Les détections sont des alertes qui signalent des menaces de sécurité potentielles. Les détections sont déclenchées par des règles personnalisées, créées par votre équipe de sécurité pour votre environnement Google SecOps.
Les détections sont générées lorsque les données de sécurité entrantes correspondent aux critères définis dans une règle. Avant l'activation du RBAC des données, tous les utilisateurs peuvent voir toutes les détections, quel que soit le tag de champ d'application. Une fois le contrôle RBAC des données activé, les utilisateurs ne peuvent voir que les détections provenant de règles associées aux niveaux d'accès qui leur ont été attribués.
Par exemple, un analyste de sécurité disposant du champ d'application des données financières ne voit que les détections générées par les règles attribuées au champ d'application des données financières, et ne voit pas les détections d'autres règles.
Les actions qu'un utilisateur peut effectuer sur une détection (par exemple, marquer une détection comme résolue) sont également limitées au champ d'application dans lequel la détection s'est produite.
Détections optimisées
Les détections sont déclenchées par des règles personnalisées créées par votre équipe de sécurité, tandis que les détections optimisées sont déclenchées par des règles fournies par l'équipe Google Cloud Threat Intelligence (GCTI). Dans le cadre des détections optimisées, GCTI fournit et gère un ensemble de règles YARA-L pour vous aider à identifier les menaces de sécurité courantes dans votre environnement Google SecOps. Pour en savoir plus, consultez Utiliser des détections optimisées pour identifier les menaces.
Les détections optimisées ne sont pas compatibles avec le RBAC des données. Seuls les utilisateurs disposant d'un champ d'application global peuvent accéder aux détections optimisées.
Impact du contrôle RBAC des données sur les cas et les alertes first party
Cette section explique comment configurer le RBAC des données pour les alertes et les cas first party dans Google Security Operations.
Les principaux thèmes abordés sont les suivants :
- Prérequis : exigences pour les instances SIEM et SOAR unifiées, compatibilité des connecteurs et implications de l'activation irréversible des fonctionnalités.
- Activation : étapes de configuration pour activer l'application de l'accès aux données pour les scénarios d'application SIEM existants et nouveaux.
- Mappage d'environnement : instructions pour établir des limites de données en mappant les niveaux d'accès SIEM définis aux environnements SOAR.
- Évaluation de l'accès : explications sur la propagation du champ d'application, la logique d'accès et les règles régissant le regroupement des entités et des cas.
- Gestion du cycle de vie : consignes pour modifier les mappages d'environnement, créer des demandes manuelles, gérer les scénarios de dépassement et traiter les suppressions de champ d'application.
- Surveillance de l'interface : comment vérifier et filtrer les niveaux d'accès aux données dans l'interface utilisateur de Case Management.
Pour en savoir plus, consultez Contrôler l'accès aux demandes et aux alertes first party.
Agent de triage
L'agent de triage est un assistant optimisé par l'IA intégré à Google Security Operations. Il examine les alertes de sécurité pour déterminer s'il s'agit de vrais ou de faux positifs, et fournit un résumé de son évaluation.
Lorsque le contrôle RBAC des données est activé, seuls les utilisateurs disposant d'un accès global aux données peuvent déclencher et afficher les investigations de l'agent de tri. Pour en savoir plus, consultez Rôles utilisateur.
Journaux bruts
Lorsque le contrôle RBAC des données est activé, les journaux bruts analysés et non analysés ne sont accessibles qu'aux utilisateurs disposant d'un champ d'application global.
Tables de données
Les tables de données sont des structures de données multicolonnes qui vous permettent d'importer vos propres données dans Google SecOps. Elles peuvent servir de tables de conversion avec des colonnes définies et des données stockées dans les lignes. En attribuant des champs d'application à une table de données, vous pouvez contrôler quels utilisateurs et ressources peuvent y accéder et l'utiliser.
Autorisations d'accès pour les utilisateurs dans les tableaux de données
Les champs d'application associés à une table de données déterminent la manière dont les utilisateurs globaux et limités peuvent interagir avec elle. Les autorisations d'accès sont résumées dans le tableau suivant :
| Action | Utilisateur global | Utilisateur limité |
|---|---|---|
| Peut créer une table de données limitée | Oui | Oui (uniquement avec des champs d'application qui correspondent à ceux qui leur sont attribués ou qui en sont un sous-ensemble) Par exemple, un utilisateur limité aux champs d'application A et B peut créer un tableau de données avec le champ d'application A ou les champs d'application A et B, mais pas avec les champs d'application A, B et C. |
| Peut créer une table de données sans champ d'application | Oui | Non |
| Peut mettre à jour la table de données limitée | Oui | Oui (uniquement avec des champs d'application qui correspondent à ceux qui leur sont attribués ou qui en sont un sous-ensemble) Par exemple, un utilisateur disposant des champs d'application A et B peut modifier une table de données avec le champ d'application A ou avec les champs d'application A et B, mais pas une table de données avec les champs d'application A, B et C. |
| Peut mettre à jour une table de données sans champ d'application | Oui | Non |
| Peut convertir une table de données limitée en table non limitée | Oui | Non |
| Peut afficher et utiliser le tableau de données limité | Oui | Oui (s'il existe au moins un champ d'application correspondant entre l'utilisateur et la table de données) Par exemple, un utilisateur disposant des champs d'application A et B peut utiliser un tableau de données avec les champs d'application A et B, mais pas un tableau de données avec les champs d'application C et D. |
| Peut afficher et utiliser un tableau de données sans champ d'application | Oui | Oui |
| Peut exécuter des requêtes de recherche avec des tables de données sans champ d'application | Oui | Oui |
| Peut exécuter des requêtes de recherche avec des tables de données limitées | Oui | Oui (s'il existe au moins un champ d'application correspondant entre l'utilisateur et la table de données) Par exemple, un utilisateur disposant du champ d'application A peut exécuter des requêtes de recherche avec des tables de données des champs d'application A, B et C, mais pas avec des tables de données des champs d'application B et C. |
Listes de référence
Les listes de référence sont des collections de valeurs utilisées pour la mise en correspondance et le filtrage des données dans la recherche UDM et les règles de détection. L'attribution de champs d'application à une liste de référence (liste limitée) restreint son accès à des utilisateurs et des ressources spécifiques, tels que les règles et la recherche UDM. Une liste de référence sans champ d'application est appelée "liste sans champ d'application".
Autorisations d'accès pour les utilisateurs des listes de référence
Les champs d'application associés à une liste de référence déterminent la manière dont les utilisateurs globaux et limités peuvent interagir avec elle. Les autorisations d'accès sont résumées dans le tableau suivant :
| Action | Utilisateur global | Utilisateur limité |
|---|---|---|
| Peut créer une liste limitée | Oui | Oui (avec des champs d'application qui correspondent à ceux qui leur sont attribués ou qui en sont un sous-ensemble)
Par exemple, un utilisateur soumis aux niveaux d'accès A et B peut créer une liste de référence avec le niveau d'accès A ou les niveaux d'accès A et B, mais pas avec les niveaux d'accès A, B et C. |
| Peut créer une liste sans niveau d'accès | Oui | Non |
| Peut modifier la liste limitée | Oui | Oui (avec des champs d'application qui correspondent à ceux qui leur sont attribués ou qui en sont un sous-ensemble)
Par exemple, un utilisateur disposant des niveaux d'accès A et B peut modifier une liste de référence avec le niveau d'accès A ou les niveaux d'accès A et B, mais pas une liste de référence avec les niveaux d'accès A, B et C. |
| Peut mettre à jour une liste non limitée | Oui | Non |
| Peut mettre à jour une liste limitée pour la rendre non limitée | Oui | Non |
| Peut afficher et utiliser la liste limitée | Oui | Oui (s'il existe au moins un champ d'application correspondant entre l'utilisateur et la liste de référence)
Par exemple, un utilisateur disposant des champs d'application A et B peut utiliser une liste de référence avec les champs d'application A et B, mais pas une liste de référence avec les champs d'application C et D. |
| Peut afficher et utiliser la liste sans champ d'application | Oui | Oui |
| Peut exécuter des requêtes de recherche et de tableau de bord UDM avec des listes de référence sans champ d'application | Oui | Oui |
| Peut exécuter des recherches UDM et des requêtes de tableau de bord avec des listes de référence limitées | Oui | Oui (s'il existe au moins un champ d'application correspondant entre l'utilisateur et la liste de référence)
Par exemple, un utilisateur disposant du champ d'application A peut exécuter des requêtes de recherche UDM avec des listes de référence ayant les champs d'application A, B et C, mais pas avec des listes de référence ayant les champs d'application B et C. |
Autorisations d'accès aux règles dans les listes de référence
Une règle limitée peut utiliser une liste de référence s'il existe au moins un niveau d'accès correspondant entre la règle et la liste de référence. Par exemple, une règle avec le niveau d'accès A peut utiliser une liste de référence avec les niveaux d'accès A, B et C, mais pas une liste de référence avec les niveaux d'accès B et C.
Une règle avec un niveau d'accès global peut utiliser n'importe quelle liste de référence.
Flux et redirecteurs
Le contrôle RBAC des données n'affecte pas directement l'exécution du flux et du redirecteur. Toutefois, lors de leur configuration, les utilisateurs peuvent attribuer les étiquettes par défaut (type de journal, espace de noms ou étiquettes d'ingestion) aux données entrantes. Le contrôle RBAC des données est ensuite appliqué aux caractéristiques à l'aide de ces données étiquetées.
Tableaux de bord
Utilisez les tableaux de bord pour créer des visualisations à partir de différentes sources de données. Chaque tableau de bord est composé de différents graphiques.
Les tableaux de bord sont entièrement compatibles avec le RBAC des données. Ce modèle de sécurité filtre les informations affichées dans les widgets du tableau de bord en fonction des champs d'application qui vous sont attribués.
- Visibilité des données : les widgets n'affichent que les résultats des données qui correspondent aux champs d'application qui vous sont attribués. Si un tableau de bord repose sur une requête YARA-L, celle-ci ne s'exécute que sur les données autorisées.
- Chevauchement des champs d'application : si vous avez plusieurs champs d'application, le tableau de bord affiche les données combinées de tous les champs d'application autorisés.
- Contrôle des accès : alors que le RBAC des fonctionnalités détermine qui peut créer ou modifier un tableau de bord, le RBAC des données détermine les données spécifiques visibles dans les graphiques et les tableaux.
Le champ d'application spécifique associé à un tableau de bord détermine le niveau d'interaction autorisé pour les utilisateurs globaux et limités :
Utilisateurs globaux : ils conservent une visibilité et des capacités de gestion complètes sur tous les tableaux de bord, quel que soit leur champ d'application.
Utilisateurs limités : l'interaction est limitée en fonction des champs d'application attribués à l'utilisateur.
Accès aux demandes d'assistance
Les tableaux de bord contenant des données SOAR, telles que les cas, l'historique des cas, les playbooks et les alertes, ne sont visibles que par les utilisateurs globaux.
Renseignements sur les menaces appliqués et correspondances IOC
Les données d'IoC et de renseignement sur les menaces avancées (ATI) fournissent des informations essentielles sur les menaces de sécurité potentielles dans votre environnement.
Les détections optimisées ATI sont déclenchées par des règles fournies par l'équipe ATI. Ces règles utilisent les renseignements sur les menaces de Mandiant pour identifier de manière proactive les menaces hautement prioritaires. Pour en savoir plus, consultez Présentation du renseignement sur les menaces appliqué.
Les correspondances d'IOC et les données ATI dérivées des journaux client nécessitent un champ d'application global pour la visibilité et ne sont pas disponibles pour les utilisateurs disposant de champs d'application restreints.
Analyse du comportement des utilisateurs et des entités (UEBA)
La catégorie "Analyse des risques pour l'UEBA" propose des ensembles de règles prédéfinis pour détecter les menaces de sécurité potentielles. Ces ensembles de règles utilisent le machine learning pour déclencher de manière proactive des détections en analysant les schémas de comportement des utilisateurs et des entités. Pour en savoir plus, consultez Présentation de la catégorie "Analyse des risques pour l'UEBA".
L'UEBA n'est pas compatible avec le RBAC des données. Seuls les utilisateurs disposant d'un champ d'application global peuvent accéder à la catégorie "Analyse des risques pour l'UEBA".
Détails des entités dans Google SecOps
Les champs suivants, qui décrivent un élément ou un utilisateur, apparaissent sur plusieurs pages de Google SecOps, comme le panneau Contexte de l'entité dans la recherche UDM. Avec le contrôle RBAC des données, les champs ne sont disponibles que pour les utilisateurs disposant d'un niveau d'accès global.
- Première occurrence
- Dernière activité
- Prévalence
Les utilisateurs limités peuvent afficher les données de première et de dernière consultation des utilisateurs et des éléments si ces données sont calculées à partir des données des champs d'application attribués à l'utilisateur.
Étapes suivantes
Configurer le RBAC des données pour les utilisateurs
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.