Présentation du RBAC des données
Le contrôle des accès basé sur les rôles aux données (contrôle des accès aux données RBAC) est un modèle de sécurité qui utilise des rôles utilisateur individuels pour restreindre l'accès des utilisateurs aux données au sein d'une organisation. Avec le contrôle des accès basé sur les rôles (RBAC) pour les données, les administrateurs peuvent définir des champs d'application et les attribuer aux utilisateurs pour s'assurer qu'ils ne peuvent accéder qu'aux données nécessaires à leurs fonctions.
Cette page présente le RBAC des données et vous aide à comprendre comment les étiquettes et les champs d'application fonctionnent ensemble pour définir les autorisations d'accès aux données.
Différence entre le RBAC des données et le RBAC des fonctionnalités
Le RBAC des données et le RBAC sont tous deux des méthodes permettant de contrôler l'accès au sein d'un mais elles se concentrent sur des aspects différents.
Le RBAC de fonctionnalité contrôle l'accès à des fonctionnalités ou fonctionnalités spécifiques d'un système. Il détermine les fonctionnalités accessibles aux utilisateurs en fonction de leur de rôles. Par exemple, un analyste junior peut n’avoir accès qu’à des tableaux de bord mais pas pour créer ou modifier des règles de détection, alors qu'un analyste senior peut les autorisations nécessaires pour créer et gérer des règles de détection. Pour en savoir plus sur RBAC aux fonctionnalités, consultez la section Configurer le contrôle des accès aux fonctionnalités à l'aide d'IAM.
Le contrôle des accès basé sur les données (RBAC) contrôle l'accès à des données ou à des informations spécifiques au sein d'un système. Il détermine si un utilisateur peut afficher, modifier ou supprimer des données en fonction de ses rôles. Pour exemple, dans un système de gestion de la relation client (CRM), une équipe de vente un représentant de l'entreprise peut avoir accès aux données de contact des clients, données financières, tandis qu'un directeur financier peut y avoir accès mais pas les données de contact du client.
Les RBAC des données et des fonctionnalités RBAC sont souvent utilisés conjointement pour fournir une système de contrôle des accès. Par exemple, un utilisateur peut être autorisé à accéder à une fonctionnalité spécifique (RBAC de fonctionnalité), puis, dans cette fonctionnalité, son accès à des données spécifiques peut être limité en fonction de son rôle (RBAC de données).
Planifier l'implémentation
Pour planifier votre implémentation, consultez la liste des ressources Google SecOps rôles et autorisations Google SecOps prédéfinis par rapport aux exigences de votre organisation. Élaborez une stratégie pour définir les portées dont votre organisation a besoin et d'étiqueter les données entrantes. Identification les membres de votre organisation qui doivent avoir accès aux données associées ces champs d'application. Si votre organisation a besoin de stratégies IAM différentes les rôles Google SecOps prédéfinis, créez des rôles personnalisés pour répondre à ces exigences.
Rôles utilisateur
Les utilisateurs peuvent disposer d'un accès limité aux données (utilisateurs concernés) ou d'un accès global aux données (utilisateurs mondiaux).
Les utilisateurs restreints ont un accès limité aux données en fonction des champs d'application attribués. Ces les champs d'application limitent leur visibilité et leurs actions à des données spécifiques. Les autorisations spécifiques associées à l'accès limité sont détaillées dans le tableau suivant.
Aucun champ d'application n'est attribué aux utilisateurs globaux et disposent d'un accès illimité à toutes les données dans Google SecOps. Les autorisations spécifiques associées des accès sont détaillés dans le tableau suivant.
Les administrateurs Data RBAC peuvent créer des niveaux d'accès et les attribuer à des utilisateurs
leur accès aux données dans Google SecOps. Pour limiter l'accès d'un utilisateur
vous devez leur attribuer l'accès restreint aux données de l'API Chronicle
(roles/chronicle.restrictedDataAccess) et
un rôle prédéfini ou personnalisé. Rôle d'accès restreint aux données de l'API Chronicle
identifie un utilisateur comme un utilisateur limité. Vous n'avez pas besoin d'attribuer
Rôle d'accès restreint aux données pour les utilisateurs ayant besoin d'un accès mondial aux données.
Les rôles suivants peuvent être attribués aux utilisateurs :
| Type d'accès | Rôles | Autorisations |
|---|---|---|
| Accès mondial prédéfini | Vous pouvez attribuer à des utilisateurs globaux l'un des rôles IAM prédéfinis. | |
| Accès en lecture seule limité prédéfini | Accès restreint aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess) et Lecteur de l'accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccessViewer)
|
Lecteur de l'API Chronicle pour l'accès restreint aux données |
| Accès de portée personnalisée | Accès restreint aux données (roles/chronicle.restrictedDataAccess) de l'API Chronicle et rôle personnalisé
|
Autorisations personnalisées dans les fonctionnalités |
| Accès mondial personnalisé | Autorisation chronicle.globalDataAccessScopes.permit et rôle personnalisé
|
Autorisations globales au sein des fonctionnalités |
Vous trouverez ci-dessous une description de chaque type d'accès présenté dans le tableau:
Accès mondial prédéfini:cet accès est généralement requis pour les utilisateurs ont besoin d'accéder à toutes les données. Vous pouvez attribuer un ou plusieurs rôles un utilisateur en fonction des autorisations requises.
Accès en lecture seule prédéfini:cet accès est destiné aux utilisateurs ayant besoin d'un accès en lecture seule y accéder. Le rôle "Accès restreint aux données" de l'API Chronicle identifie un utilisateur en tant que un utilisateur limité. Le rôle Lecteur de l'accès restreint aux données de l'API Chronicle permet d'afficher l'accès aux utilisateurs dans leurs caractéristiques.
Accès à portée personnalisée : le rôle "Accès limité aux données de l'API Chronicle" identifie un utilisateur comme un utilisateur à portée. Le rôle personnalisé spécifie les fonctionnalités auxquelles l'utilisateur peut accéder. Les champs d'application ajoutés au rôle "Accès restreint aux données de l'API Chronicle" spécifient les données auxquelles les utilisateurs peuvent accéder dans les caractéristiques.
Accès global personnalisé : cet accès est destiné aux utilisateurs qui ont besoin d'autorisations illimitées dans les fonctionnalités qui leur sont attribuées. Pour accorder un accès global personnalisé
utilisateur, vous devez spécifier l'autorisation chronicle.globalDataAccessScopes.permit
en plus du rôle personnalisé attribué à l'utilisateur.
Contrôle des accès à l'aide de champs d'application et d'étiquettes
Google SecOps vous permet de contrôler l'accès des utilisateurs aux données à l'aide de champs d'application. Les champs d'application sont définis à l'aide de libellés, qui indiquent les données qu'un utilisateur accessibles dans le champ d'application. Lors de l'ingestion, des métadonnées sont attribuées aux données sous la forme d'étiquettes telles que l'espace de noms (facultatif), les métadonnées d'ingestion (facultatif), et le type de journal (obligatoire). Il s'agit de libellés par défaut appliqués aux données pendant l'ingestion. Vous pouvez également créer des étiquettes personnalisées. Vous pouvez utiliser des étiquettes par défaut et personnalisées pour définir les portées et les données. niveau d'accès défini par les niveaux d'accès.
Visibilité des données avec des libellés d'autorisation et de refus
Chaque champ d'application contient un ou plusieurs libellés d'autorisation d'accès et, éventuellement, refus d'accès. Les libellés d'accès permettent aux utilisateurs d'accéder aux données associées à l'étiquette. Les libellés de refus d'accès empêchent les utilisateurs d'accéder aux données est associée à l'étiquette. Les étiquettes de refus d'accès remplacent celles d'autorisation d'accès des étiquettes pour restreindre l'accès des utilisateurs.
Dans une définition de champ d'application, autorisez les étiquettes d'accès du même type (par exemple, type de journal) sont combinés à l'aide de l'opérateur OR, tandis que les étiquettes de différents types (par exemple, le type de journal et une étiquette personnalisée) sont combinés à l'aide de l'opérateur AND. Les étiquettes de refus d'accès sont combinées à l'aide de l'opérateur OU. Lorsque plusieurs refus d'accès sont appliquées au sein d'un champ d'application, l'accès est refusé s'ils correspondent à l'UN de ces étiquettes.
Prenons l'exemple d'un système Cloud Logging qui classe les journaux à l'aide du types de libellés suivants:
Type de journal:Accès, Système, Pare-feu
Espace de noms:App1, App2, Database
Gravité:Critique, Avertissement
Prenons l'exemple d'un champ d'application appelé "Journaux restreints" qui dispose des droits d'accès suivants :
| Type de libellé | Valeurs autorisées | Valeurs refusées |
|---|---|---|
| Type de journal | Accès, pare-feu | Système |
| Espace de noms | App1 | Application2, base de données |
| Gravité | Avertissement | Critique |
La définition du champ d'application se présente comme suit:
Autoriser : (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")
Refuser:Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"
Exemples de journaux correspondant au champ d'application:
- Journal des accès de l'application 1 avec niveau de gravité: avertissement
- Journal de pare-feu de l'application App1 avec niveau de gravité: avertissement
Exemples de journaux ne correspondant pas au champ d'application:
- Journal système de l'application 1 avec niveau de gravité: avertissement
- Journal des accès de la base de données présentant un niveau de gravité: avertissement
- Journal de pare-feu de l'application App2 avec niveau de gravité: critique
Visibilité des données dans les événements enrichis
Les événements "enrichis" sont des événements liés à la sécurité qui ont été améliorés du contexte et des informations au-delà de ce que contiennent les données de journaux brutes. Les événements enrichis ne sont accessibles dans un champ d'application que si l'événement de base est accessible dans le champ d'application et si aucun des libellés enrichis n'inclut les libellés de refus du champ d'application.
Prenons l'exemple d'un journal brut qui indique l'échec d'une tentative de connexion depuis une adresse IP
associée au libellé "Enrichi" user_risk: high (indique un utilisateur à haut risque).
Un utilisateur dont le champ d'application comporte l'étiquette de refus user_risk: high ne peut pas voir les échecs
de tentatives de connexion d'utilisateurs à haut risque.
Impact du RBAC des données sur les fonctionnalités Google Security Operations
Une fois le RBAC des données configuré, les utilisateurs commencent à voir des données filtrées dans Google Security Operations. L'impact dépend de la manière dont la fonctionnalité est intégrée avec les données sous-jacentes. Pour comprendre l'impact du RBAC des données sur chaque fonctionnalité, consultez Impact des données sur les fonctionnalités RBAC de Google Security Operations