Présentation du RBAC pour les données
Le contrôle des accès basé sur les rôles pour les données (RBAC pour les données) est un modèle de sécurité qui utilise des rôles d'utilisateur individuels pour restreindre l'accès des utilisateurs aux données d'une organisation. Le contrôle RBAC des données permet aux administrateurs de définir des niveaux d'accès et de 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 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 RBAC des données et le RBAC des fonctionnalités
Le RBAC pour les données et le RBAC pour les 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 RBAC des fonctionnalités contrôle l'accès à des 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 être autorisé à afficher des tableaux de bord, mais pas à créer ni à modifier des règles de détection. En revanche, un analyste senior peut être autorisé à 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 informations spécifiques dans 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. À l'inverse, un responsable financier peut avoir accès aux données financières, mais pas aux données de contact des clients.
Le RBAC pour les données et le RBAC pour les 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 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 (RBAC des données).
Planifier votre implémentation
Pour planifier votre implémentation, consultez la liste des rôles et autorisations Google SecOps prédéfinis de Google Security Operations et alignez-les sur les besoins de votre organisation. Élaborez une stratégie pour définir les niveaux d'accès et étiqueter les données entrantes. Assurez-vous de disposer du rôle Lecteur de rôle (roles/iam.roleViewer) pour gérer les autorisations.
Identifiez les membres qui doivent avoir accès aux données dans ces champs d'application.
Si votre organisation a besoin de stratégies IAM au-delà des rôles SecOps Google 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 avec un accès limité aux données en fonction des niveaux d'accès qui leur sont attribués. Ces niveaux d'accès limitent la visibilité et les actions des utilisateurs à des données spécifiques. Les autorisations spécifiques associées à l'accès limité sont détaillées dans le tableau ci-dessous.
Les utilisateurs globaux n'ont aucun 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 ci-dessous.
L'accès mondial 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 RBAC des données peuvent créer des portées et les attribuer à des 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 Lecteur de l'API Chronicle avec accès limité aux données (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 restreint aux données 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 mondial prédéfini | Les utilisateurs globaux peuvent se voir attribuer l'un des rôles IAM prédéfinis. | |
| 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 personnalisé | Accès limité aux données de l'API Chronicle (roles/chronicle.restrictedDataAccess) et rôle personnalisé (pour la définition RBAC de la fonctionnalité)
|
Autorisations personnalisées dans les fonctionnalités |
| Accès mondial personnalisé | Autorisation chronicle.globalDataAccessScopes.permit et accès global aux données de l'API Chronicle (roles/globalDataAccess)
|
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 prédéfini et limité : 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'accéder à leurs fonctionnalités en mode lecture.
Accès limité personnalisé : le rôle "Accès limité aux données de l'API Chronicle" identifie un utilisateur comme un utilisateur à accès 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.
Pour vérifier que les niveaux d'accès personnalisés 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é les rôles prédéfinis Éditeur d'API Chronicle ou Administrateur d'API Chronicle 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 champ d'application de l'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 l'interface utilisateur et les fonctionnalités dont il dispose. 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 tous les tableaux de bord et interagir avec eux, mais ils 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, modifier et 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. |
| Spectateur avec accès limité | roles/chroniclesiem.restrictedViewer |
Ce rôle est semblable à celui de lecteur, mais toutes les données affichées dans le tableau de bord sont filtrées en fonction du champ d'application des journaux attribué à l'utilisateur (RBAC des données). |
Pour en savoir plus sur le contrôle des accès basé sur les rôles pour les données et les fonctionnalités, consultez Différence entre le contrôle des accès basé sur les rôles pour les données et les 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 les tableaux de bord existants et d'enregistrer les modifications.chronicle.dashboards.delete: permet aux utilisateurs de supprimer des tableaux de bord personnalisés.
Par exemple, vous pouvez créer un rôle personnalisé de 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 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 niveaux d'accès sont définis à l'aide d'étiquettes 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 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 niveaux d'accès aux données et les champs d'application qu'ils définiront.
Visibilité des données avec les 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'accès permettent aux utilisateurs d'accéder aux données associées au libellé. Les libellés d'accès refusé empêchent les utilisateurs d'accéder aux données associées au libellé. Les libellés "Refuser l'accès" remplacent les libellés "Autoriser l'accès" pour restreindre l'accès des utilisateurs.
Dans une définition de champ d'application, les libellés 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 d'accès refusé sont combinés à l'aide de l'opérateur OR. Lorsque plusieurs libellés "Refuser l'accès" sont appliqués dans un champ d'application, 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, Database
Gravité : critique, avertissement
Prenons l'exemple d'un champ d'application appelé "Journaux restreints" qui dispose de l'accès suivant :
| 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 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 d'accès depuis App1 avec le niveau de gravité "Avertissement"
- Journal de pare-feu de l'application 1 avec le niveau de gravité "Avertissement"
Exemples de journaux ne correspondant pas au champ d'application :
- Journal système de l'application 1 avec le niveau de gravité "Avertissement"
- Journal d'accès de la base de données avec le niveau de gravité "Avertissement"
- Journal de pare-feu d'App2 avec le 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 au-delà de ce que contiennent les données brutes des journaux. Les événements enrichis ne sont accessibles dans un champ d'application que si leur événement de base est accessible dans le champ d'application et si aucun des libellés enrichis n'inclut l'un des libellés de refus du champ d'application.
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 (indiquant un utilisateur à haut risque).
Un utilisateur dont le champ d'application comporte le libellé de refus user_risk: high ne peut pas voir les tentatives de connexion infructueuses des utilisateurs à haut risque.
Impact du 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 les 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 du RBAC sur les données pour chaque fonctionnalité, consultez Impact du RBAC sur les données pour les fonctionnalités Google Security Operations.
Étapes suivantes
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.