Présentation du contrôle des accès basé sur les rôles pour les données
Le contrôle des accès basé sur les rôles (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 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 libellés et les champs d'application fonctionnent ensemble pour définir les autorisations d'accès aux données.
Différence entre RBAC des données et RBAC des éléments géographiques
Le RBAC des données et le RBAC des fonctionnalités sont tous deux des méthodes de contrôle des accès au sein d'un système, mais ils se concentrent sur différents aspects.
Le RBAC de fonctionnalité contrôle l'accès à des fonctionnalités ou fonctionnalités spécifiques d'un système. Elle détermine les fonctionnalités auxquelles les utilisateurs ont accès en fonction de leurs rôles. Par exemple, un analyste junior peut n'avoir accès qu'à la consultation des tableaux de bord, mais pas à la création ni à la modification de règles de détection, tandis qu'un analyste senior peut avoir les autorisations nécessaires pour créer et gérer des règles de détection. Pour en savoir plus sur le RBAC des fonctionnalités, consultez Configurer le contrôle des accès aux fonctionnalités à l'aide d'IAM.
Le RBAC des données contrôle l'accès à des données ou des informations spécifiques dans un système. Il 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 représentant 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 des clients.
Le RBAC des données et le RBAC des fonctionnalités sont souvent utilisés ensemble pour fournir un système de contrôle des accès complet. 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 votre implémentation
Pour planifier votre implémentation, comparez la liste des rôles et autorisations Google SecOps prédéfinis à vos exigences organisationnelles. Élaborez une stratégie pour définir les champs d'application dont votre organisation a besoin et pour é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 nécessite des règles 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 avoir un accès aux données limité (utilisateurs limités) ou un accès aux données global (utilisateurs globaux).
Les utilisateurs disposant de champs d'application ont un accès limité aux données en fonction des champs d'application attribués. Ces habilitations 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.
Les utilisateurs globaux n'ont pas de champ d'application attribué et ont un accès illimité à toutes les données de Google SecOps. Les autorisations spécifiques associées à l'accès global sont détaillées dans le tableau suivant.
Les administrateurs RBAC des données peuvent créer des champs d'application et les attribuer aux utilisateurs pour contrôler leur accès aux données dans Google SecOps. Pour limiter un utilisateur à certains champs d'application, vous devez lui attribuer le rôle "Accès limité aux données" (roles/chronicle.restrictedDataAccess) de l'API Chronicle, ainsi qu'un rôle prédéfini ou personnalisé. Le rôle "Accès limité aux données" de l'API Chronicle identifie un utilisateur comme un utilisateur à portée limitée. Vous n'avez pas besoin d'attribuer le rôle "Accès aux données limité Chronicle" aux utilisateurs qui ont besoin d'un accès aux données global.
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 prédéfini | Accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess) et lecteur de l'API Chronicle avec accès limité aux données (roles/chronicle.restrictedDataAccessViewer)
|
Lecteur de l'API Chronicle avec accès limité aux données |
| Accès de portée personnalisée | Accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess) 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 dans les fonctionnalités |
Vous trouverez ci-dessous une description de chaque type d'accès présenté dans le tableau:
Accès global prédéfini:cet accès est généralement requis pour les utilisateurs qui 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 à portée prédéfinie:cet accès est destiné aux utilisateurs qui ont besoin d'un accès en lecture seule. Le rôle "Accès limité aux données" de l'API Chronicle identifie un utilisateur comme un utilisateur à champ d'application défini. Le rôle de lecteur de l'API Chronicle avec accès limité aux données permet aux utilisateurs de consulter leurs fonctionnalités.
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 d'accès aux données restreint de l'API Chronicle spécifient les données auxquelles les utilisateurs peuvent accéder dans les fonctionnalités.
Pour vous assurer que les portées personnalisées RBAC fonctionnent correctement, n'incluez pas les autorisations chronicle.DataAccessScopes.permit ou chronicle.globalDataAccessScopes.permit lorsque vous créez les rôles personnalisés. Ces autorisations peuvent être incluses si vous avez utilisé l'éditeur d'API Chronicle ou l'administrateur d'API Chronicle prédéfinis comme point de départ pour vos rôles personnalisés.
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é à un utilisateur, vous devez spécifier l'autorisation chronicle.globalDataAccessScopes.permit en plus du rôle personnalisé attribué à l'utilisateur.
Contrôle des accès avec des champs d'application et des libellés
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 d'étiquettes qui définissent les données auxquelles un utilisateur du champ d'application a accès. Lors de l'ingestion, des métadonnées sont attribuées aux données sous la forme de libellés tels 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 lors de l'ingestion. Vous pouvez également créer des libellés personnalisés. Vous pouvez utiliser des libellés par défaut et personnalisés pour définir vos champs d'application et le niveau d'accès aux données qu'ils définiront.
Visibilité des données avec des libellés d'autorisation et de refus
Chaque champ d'application contient un ou plusieurs libellés Autoriser l'accès et éventuellement des libellés Refuser l'accès. Les libellés d'autorisation d'accès permettent aux utilisateurs d'accéder aux données associées au libellé. Les libellés d'accès "Refuser" empêchent les utilisateurs d'accéder aux données associées au libellé. Les libellés d'accès refusés remplacent les libellés d'accès autorisés pour limiter l'accès des utilisateurs.
Dans une définition de champ d'application, les libellés d'autorisation d'accès du même type (par exemple, le type de journal) sont combinés à l'aide de l'opérateur OU, tandis que les libellés de différents types (par exemple, le type de journal et un libellé personnalisé) sont combinés à l'aide de l'opérateur ET. Les libellés d'accès refusés sont combinés à l'aide de l'opérateur OU. Lorsque plusieurs libellés d'accès refusé sont appliqués dans une portée, l'accès est refusé s'ils correspondent à l'UN de ces libellés.
Prenons l'exemple d'un système Cloud Logging qui catégorise les journaux à l'aide des types d'étiquettes 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 | App2, Database |
| Gravité | Avertissement | Critique |
La définition de la portée 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 gravité: avertissement
- Journal de pare-feu d'App1 avec gravité: avertissement
Exemples de journaux qui ne correspondent pas au champ d'application:
- Journal système de l'application 1 avec gravité: avertissement
- Journal des accès de la base de données avec gravité: avertissement
- Journal de pare-feu de l'appli 2 avec 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 au-delà de ce que contiennent les données de journal brutes. Les événements enrichis ne sont accessibles dans un champ d'application que si l'événement de base est accessible dans ce champ d'application et que les libellés enrichis n'incluent aucun des libellés de refus du champ d'application.
Prenons l'exemple d'un journal brut qui indique une tentative de connexion infructueuse à partir d'une adresse IP et qui comporte un libellé enrichi user_risk: high (indique un utilisateur à haut risque).
Un utilisateur dont le champ d'application est associé au libellé de refus user_risk: high ne peut pas voir les tentatives de connexion échouées des utilisateurs à haut risque.
Impact de la RBAC des données sur les fonctionnalités de Google Security Operations
Une fois le contrôle des accès basé sur les rôles des données configuré, les utilisateurs commencent à voir des données filtrées dans les fonctionnalités 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 de la RBAC des données sur chaque fonctionnalité, consultez la page Impact de la RBAC des données sur les fonctionnalités Google Security Operations.