Présentation du RBAC des données
Le contrôle des accès basé sur les rôles aux données (RBAC aux données) 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 données (RBAC), 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 professionnelles.
Cette page présente le RBAC aux 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 système, mais ils se concentrent sur des aspects différents.
Le contrôle des fonctionnalités RBAC contrôle l'accès à des fonctionnalités spécifiques au sein d'un système. Il détermine les fonctionnalités accessibles aux utilisateurs en fonction de leur rôle. Par exemple, un analyste junior peut avoir uniquement accès aux tableaux de bord, mais pas à créer ou modifier des règles de détection, tandis qu'un analyste senior peut disposer des autorisations nécessaires pour créer et gérer des règles de détection. Pour en savoir plus sur le contrôle des accès 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. Elle détermine si un utilisateur peut afficher, modifier ou supprimer des données en fonction de ses rôles. Par exemple, dans un système de gestion de la relation client (CRM), un commercial peut avoir accès aux données de contact des clients, mais pas aux données financières, tandis qu'un responsable financier peut avoir accès aux données financières, mais pas aux données de contact client.
Le RBAC des données et le RBAC sont souvent utilisés conjointement pour fournir un système complet de contrôle des accès. Par exemple, un utilisateur peut être autorisé à accéder à une fonctionnalité spécifique (fonctionnalité RBAC), puis, au sein de cette fonctionnalité, son accès à des données spécifiques peut être limité en fonction de son rôle (RBAC pour les données).
Planifier l'implémentation
Pour planifier votre mise en œuvre, consultez la liste des rôles et autorisations Google SecOps prédéfinis correspondant aux exigences de votre organisation. Concevez une stratégie pour définir les champs d'application dont votre organisation a besoin et étiqueter les données entrantes. Identifiez 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 des 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 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 mondiaux et disposent d'un accès illimité à toutes les données dans Google SecOps. Les autorisations spécifiques associées à l'accès global sont détaillées dans le tableau suivant.
Les administrateurs Data RBAC peuvent créer des niveaux d'accès et les attribuer à des utilisateurs pour contrôler l'accès à leurs données dans Google SecOps. Pour limiter un utilisateur à certains champs d'application, vous devez lui attribuer le rôle d'accès restreint aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess), ainsi qu'un rôle prédéfini ou personnalisé. Le rôle d'accès restreint aux données de l'API Chronicle identifie un utilisateur en tant qu'utilisateur limité. Vous n'avez pas besoin d'attribuer le rôle d'accès restreint aux données Chronicle aux 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 | Les utilisateurs mondiaux peuvent se voir attribuer n'importe quel rôle IAM prédéfini. | |
| 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 limité personnalisé | 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 qui doivent 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 délimité et prédéfini:cet accès est destiné aux utilisateurs ayant besoin d'un accès en lecture seule. Le rôle "Accès restreint aux données" de l'API Chronicle identifie un utilisateur en tant qu'utilisateur limité. Le rôle de lecteur des accès restreints aux données de l'API Chronicle accorde un accès en lecture aux utilisateurs dans leurs fonctionnalités.
Accès personnalisé à un champ d'application:le rôle "Accès restreint aux données" de l'API Chronicle permet d'identifier un utilisateur en tant qu'utilisateur limité. 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 fonctionnalités.
Accès global personnalisé:cet accès est destiné aux utilisateurs qui ont besoin d'autorisations illimitées pour les fonctionnalités qui leur sont attribuées. Pour accorder à un utilisateur un accès global personnalisé, 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 définissent les données auxquelles un utilisateur situé dans le champ d'application a accès. Lors de l'ingestion, les 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 d'étiquettes par défaut appliquées aux données lors de 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 champs d'application et le niveau d'accès aux données qu'ils définiront.
Visibilité des données avec des étiquettes d'autorisation et de refus
Chaque champ d'application contient une ou plusieurs étiquettes d'autorisation d'accès et, éventuellement, des étiquettes de refus d'accès. Les libellés d'autorisation permettent aux utilisateurs d'accéder aux données qui leur sont associées. Les libellés de refus d'accès empêchent les utilisateurs d'accéder aux données qui leur sont associées. Les étiquettes de refus d'accès remplacent celles d'autorisation d'accès pour restreindre l'accès des utilisateurs.
Dans une définition de champ d'application, les étiquettes d'autorisation d'accès du même type (par exemple, le type de journal) sont combinées à l'aide de l'opérateur OU, tandis que les étiquettes de différents types (par exemple, le type de journal et une étiquette personnalisée) sont combinées à l'aide de l'opérateur ET. Les étiquettes de refus d'accès sont combinées à l'aide de l'opérateur OU. Lorsque plusieurs étiquettes de refus d'accès sont appliquées au sein d'un champ d'application, l'accès est refusé si elles correspondent à l'UN de ces libellés.
Prenons l'exemple d'un système Cloud Logging qui classe les journaux à l'aide des 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" doté de l'accès suivant:
| Type d'étiquette | 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 de sécurité qui ont été améliorés avec du contexte et des informations supplémentaires en plus des données de journaux brutes. Les événements enrichis ne sont accessibles dans un champ d'application que si son événement de base l'est dans le champ d'application et si l'un des libellés "surenrichis" n'inclut aucun des libellés de refus du champ d'application.
Prenons l'exemple d'un journal brut qui indique un échec de tentative de connexion à partir d'une adresse IP et qui comporte l'étiquette "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 tentatives de connexion ayant échoué des 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 les fonctionnalités de Google Security Operations. L'impact dépend de la manière dont la fonctionnalité est intégrée aux données sous-jacentes. Pour comprendre l'impact du RBAC des données sur chaque fonctionnalité, consultez la page Impact des fonctionnalités RBAC des données Google Security Operations.