Présentation du contrôle RBAC des données

Compatible avec :

Le contrôle des accès basé sur les rôles pour les données (contrôle RBAC des données) est un modèle de sécurité qui utilise les rôles des utilisateurs individuels pour limiter leur accès aux données au sein d'une organisation. Grâce au contrôle RBAC des données, les administrateurs peuvent définir des niveaux d'accès et les attribuer aux utilisateurs pour s'assurer qu'ils n'ont accès qu'aux données nécessaires à leurs fonctions.

Cette page présente le contrôle RBAC des données et vous aide à comprendre comment les libellés et les niveaux d'accès fonctionnent ensemble pour définir les autorisations d'accès aux données.

Différence entre le contrôle RBAC des données et le contrôle RBAC des fonctionnalités

Le contrôle RBAC des données et le contrôle RBAC des fonctionnalités sont deux méthodes permettant de contrôler l'accès au sein d'un système, mais elles se concentrent sur des aspects différents.

Le contrôle RBAC des fonctionnalités 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 leurs rôles. Par exemple, un analyste junior peut n'avoir accès qu'à l'affichage 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 contrôle RBAC des fonctionnalités, consultez Configurer le contrôle des accès aux fonctionnalités à l'aide d'IAM.

Le contrôle RBAC des données contrôle l'accès à des données ou 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. 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 des clients.

Le contrôle RBAC des données et le contrô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 (contrôle RBAC des fonctionnalités), puis, au sein de cette fonctionnalité, son accès à des données spécifiques peut être limité en fonction de son rôle (contrôle RBAC des données).

Planifier votre implémentation

Pour planifier votre implémentation, consultez la liste des rôles et autorisations Google Security Operations prédéfinis et alignez-les sur les besoins de votre organisation. Élaborez une stratégie pour définir des niveaux d'accès et libeller les données entrantes. Assurez-vous de disposer du rôle Lecteur de rôle (roles/iam.roleViewer) pour gérer les niveaux d'accès. Identifiez les membres qui doivent avoir accès aux données dans ces niveaux d'accès.

Si votre organisation nécessite des règles IAM au-delà des rôles Google SecOps prédéfinis, créez des rôles personnalisés pour répondre à des exigences spécifiques.

Rôles utilisateur

Les utilisateurs peuvent disposer d'un accès aux données limité (utilisateurs limités) ou d'un accès aux données global (utilisateurs globaux).

  • Les utilisateurs limités disposent d'un accès limité aux données en fonction des niveaux d'accès attribués. Ces niveaux d'accès 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 ne disposent d'aucun niveau d'accès 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.

L'accès global remplace l'accès limité. Si un utilisateur se voit attribuer à la fois un rôle global et un rôle limité, il a accès à toutes les données, quelles que soient les restrictions imposées par le rôle limité.

Les administrateurs du contrôle RBAC des données peuvent créer des niveaux d'accès et les attribuer aux utilisateurs pour contrôler leur accès aux données dans Google SecOps. Pour limiter un utilisateur à certains niveaux d'accès, vous devez lui attribuer le rôle Accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess), 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 limité. Vous n'avez pas besoin d'attribuer le rôle Accès limité aux données de l'API Chronicle aux utilisateurs qui ont besoin d'un accès global aux données.

Les rôles suivants peuvent être attribués aux utilisateurs :

Type d'accès Rôles Autorisations
Accès global prédéfini Les utilisateurs globaux peuvent se voir attribuer n'importe quel rôle IAM prédéfini.
Accès en lecture seule limité 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 limité personnalisé Accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess) et rôle personnalisé (pour la définition du contrôle RBAC des fonctionnalités) Autorisations personnalisées dans les fonctionnalités
Accès global personnalisé Autorisation chronicle.globalDataAccessScopes.permit et Accès global aux données de l'API Chronicle (roles/globalDataAccess) Autorisations globales dans les fonctionnalités

Voici 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 limité prédéfini : 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 limité. Le rôle Lecteur de l'API Chronicle avec accès limité aux données permet aux utilisateurs d'afficher les données dans leurs fonctionnalités.

Accès limité personnalisé : le rôle Accès limité aux données de l'API Chronicle identifie un utilisateur comme un utilisateur limité. Le rôle personnalisé spécifie les fonctionnalités auxquelles l'utilisateur peut accéder. Les niveaux d'accès ajoutés au rôle Accès limité aux données de l'API Chronicle spécifient les données auxquelles les utilisateurs peuvent accéder dans les fonctionnalités.

Pour vérifier que les niveaux d'accès personnalisés du contrôle RBAC fonctionnent correctement, incluez l'autorisation chronicle.dataAccessScopes.list lorsque vous créez les rôles personnalisés. Toutefois, n'incluez pas les autorisations chronicle.DataAccessScopes.permit ni chronicle.globalDataAccessScopes.permit. 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é qui lui est attribué.

Rôles utilisateur pour les tableaux de bord

L'accès aux tableaux de bord est contrôlé par deux facteurs principaux : le rôle fonctionnel d'un utilisateur et son niveau d'accès aux données. La combinaison de ces deux éléments détermine l'accès au tableau de bord. Le rôle attribué à un utilisateur modifie directement son interface utilisateur et ses fonctionnalités disponibles. Voici les rôles prédéfinis les plus courants qui permettent aux utilisateurs d'accéder aux tableaux de bord :

Type d'accès Rôles Description
Lecteur roles/chroniclesiem.viewer Accorde un accès en lecture seule. Les utilisateurs peuvent ouvrir et interagir avec tous les tableaux de bord, mais ne peuvent pas les créer ni les modifier.
Éditeur roles/chroniclesiem.editor Accorde l'accès à toutes les données et à toutes les autorisations, y compris la possibilité de créer, de modifier et de supprimer des tableaux de bord personnalisés.
Administrateur roles/chroniclesiem.admin Accorde des autorisations complètes, semblables à celles du rôle Éditeur, avec accès à toutes les données.
Lecteur limité roles/chroniclesiem.restrictedViewer Semblable au rôle Lecteur, mais toutes les données affichées dans le tableau de bord sont filtrées en fonction du champ d'action des journaux attribué à l'utilisateur (contrôle RBAC des données).

Pour en savoir plus sur le contrôle RBAC des données et le contrôle RBAC des fonctionnalités, consultez Différence entre le contrôle RBAC des données et le contrôle RBAC des fonctionnalités.

Autorisations pour les rôles personnalisés

Vous pouvez définir des autorisations précises en créant des rôles personnalisés.

Les autorisations suivantes s'appliquent aux tableaux de bord :

  • chronicle.dashboards.list : permet aux utilisateurs de voir la liste des tableaux de bord disponibles.

  • chronicle.dashboards.get : permet aux utilisateurs d'ouvrir et d'afficher le contenu d'un tableau de bord.

  • chronicle.dashboards.create : permet aux utilisateurs de créer des tableaux de bord.

  • chronicle.dashboards.update : permet aux utilisateurs de modifier et d'enregistrer les modifications apportées aux tableaux de bord existants.

  • chronicle.dashboards.delete : permet aux utilisateurs de supprimer des tableaux de bord personnalisés.

Par exemple, vous pouvez créer un rôle personnalisé Créateur de tableaux de bord avec uniquement chronicle.dashboards.create et chronicle.dashboards.list permissions. Un utilisateur disposant de ce rôle peut créer un tableau de bord, mais pas en modifier un existant.

Contrôle des accès avec des niveaux d'accès et des libellés

Google SecOps vous permet de contrôler l'accès aux données des utilisateurs à l'aide de niveaux d'accès. Les niveaux d'accès sont définis à l'aide de libellés qui définissent les données auxquelles un utilisateur du niveau d'accès a accès. Lors de l'ingestion, des métadonnées sont attribuées aux données sous 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 qui sont 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 niveaux d'accès et le niveau d'accès aux données qu'ils définiront.

Visibilité des données avec les libellés d'autorisation et de refus

Chaque niveau d'accès contient un ou plusieurs libellés d'autorisation d'accès et, éventuellement, des libellés de refus d'accès. Les libellés d'autorisation d'accès accordent aux utilisateurs l'accès aux données associées au libellé. Les libellés de refus d'accès refusent aux utilisateurs l'accès aux données associées au libellé. Les libellés de refus d'accès remplacent les libellés d'autorisation d'accès en limitant l'accès des utilisateurs.

Dans une définition de niveau d'accès, 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 OR, 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 AND. Les libellés de refus d'accès sont combinés à l'aide de l'opérateur OR. Lorsque plusieurs libellés de refus d'accès sont appliqués dans un niveau d'accès, 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 de libellés suivants :

Type de journal : Accès, Système, Pare-feu

Espace de noms : App1, App2, Base de données

Gravité : Critique, Avertissement

Prenons l'exemple d'un niveau d'accès appelé Journaux limités qui dispose 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 App2, Base de données
Gravité Avertissement Critique

La définition du niveau d'accès 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 niveau d'accès :

  • Journal d'accès d'App1 avec Gravité : Avertissement
  • Journal de pare-feu d'App1 avec Gravité : Avertissement

Exemples de journaux ne correspondant pas au niveau d'accès :

  • Journal système d'App1 avec Gravité : Avertissement
  • Journal d'accès de la base de données avec Gravité : Avertissement
  • Journal de pare-feu d'App2 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 un contexte et des informations supplémentaires au-delà de ce que contiennent les données brutes des journaux. Les événements enrichis ne sont accessibles dans un niveau d'accès que si leur événement de base est accessible dans le niveau d'accès et si aucun des libellés enrichis n'inclut l'un des libellés de refus du niveau d'accès.

Prenons l'exemple d'un journal brut qui indique une tentative de connexion ayant échoué à partir d'une adresse IP et qui comporte un libellé enrichi user_risk: high (indique un utilisateur à haut risque). Un utilisateur disposant d'un niveau d'accès comportant le libellé de refus user_risk: high ne peut pas voir les tentatives de connexion ayant échoué des utilisateurs à haut risque.

Impact du contrôle RBAC des données sur les fonctionnalités de Google Security Operations

Une fois le contrô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 contrôle RBAC des données sur chaque fonctionnalité, consultez Impact du contrôle RBAC des données sur les fonctionnalités de Google Security Operations.

Étape suivante

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.