Appliquer le principe du moindre privilège avec les recommandations de rôle

Les recommandations de rôle vous aident à identifier et supprimer les autorisations en excès de vos membres, améliorant ainsi les configurations de sécurité de vos ressources.

Présentation des recommandations de rôle

Les recommandations de rôle sont l'un des types de recommandations générés par l'outil de recommandation.

Chaque recommandation de rôle vous suggère de supprimer ou de remplacer un rôle accordant des autorisations en excès à vos membres. À grande échelle, ces recommandations vous aident à appliquer le principe du moindre privilège en vous assurant que les membres disposent uniquement des autorisations dont ils ont réellement besoin.

L'outil de recommandation identifie les autorisations en excès à l'aide d'insights sur les stratégies. Les insights sur les stratégies sont des données basées sur le ML concernant l'utilisation des autorisations dans votre projet, votre dossier ou votre organisation.

Certaines recommandations sont également associées à des insights sur les mouvements latéraux. Ces insights identifient les rôles permettant aux comptes de service d'un projet d'emprunter l'identité des comptes de service d'un autre projet. Pour en savoir plus, consultez la section Comment les insights sur les mouvements latéraux sont-ils générés ?.

Comment les insights sur les stratégies sont-ils générés ?

L'outil de recommandation génère des insights sur les stratégies en comparant les autorisations utilisées par chaque membre au cours des 90 derniers jours avec la totalité des autorisations dont il dispose. Un membre peut utiliser une autorisation de différentes manières :

  • Directement, en appelant une API nécessitant l'autorisation

    Par exemple, la méthode roles.list de l'API REST IAM nécessite l'autorisation iam.roles.list. Lorsque vous appelez la méthode roles.list, vous utilisez l'autorisation iam.roles.list.

    De même, lorsque vous appelez la méthode testIamPermissions pour une ressource, vous utilisez effectivement toutes les autorisations que vous testez.

  • Indirectement, en utilisant Google Cloud Console pour travailler avec les ressources Google Cloud

    Par exemple, dans Cloud Console, vous pouvez modifier une instance de machine virtuelle (VM) Compute Engine, qui nécessite des autorisations différentes selon les paramètres que vous modifiez. Toutefois, Cloud Console affiche également les paramètres existants, ce qui nécessite l'autorisation compute.instances.get.

    Par conséquent, lorsque vous modifiez une instance de VM dans Cloud Console, vous utilisez l'autorisation compute.instances.get.

L'outil de recommandation utilise également le machine learning pour identifier les autorisations du rôle actuel d'un membre dont ce membre est susceptible d'avoir besoin à l'avenir, même s'il n'a pas utilisé ces autorisations au cours des 90 derniers jours. Pour plus d'informations, consultez la section Machine learning pour les insights sur les stratégies sur cette page.

Les insights sur les stratégies ne sont pas générés pour toutes les liaisons de rôles IAM. Pour en savoir plus sur la raison pour laquelle une liaison de rôle peut ne pas avoir d'insight sur les stratégies, consultez la section Disponibilité sur cette page.

Pour savoir comment gérer les insights sur les stratégies, consultez la section Gérer les insights sur les stratégies.

Machine learning pour les insights sur les stratégies

Dans certains cas, un membre aura probablement besoin de certaines autorisations incluses dans ses rôles actuels mais qui n'ont pas été utilisées récemment. Pour identifier ces autorisations, l'outil de recommandation utilise un modèle de machine learning (ML) lors de la génération des insights sur les stratégies.

Ce modèle de machine learning est entraîné à l'aide de plusieurs ensembles de signaux :

  • Schémas de co-occurrence courants dans l'historique en cours d'observation : le fait qu'un utilisateur ait utilisé les autorisations A, B et C par le passé suggère que celles-ci sont liées d'une manière ou d'une autre et qu'elles sont toutes nécessaires pour mener à bien une tâche sur Google Cloud. Si le modèle de ML constate ce schéma suffisamment fréquemment, la prochaine fois qu'un autre utilisateur utilisera les autorisations A et B, le modèle suggérera qu'il pourrait également avoir besoin de l'autorisation C.

  • Connaissance du domaine, telle qu'elle est encodée dans les définitions de rôle : Cloud IAM fournit des centaines de rôles prédéfinis différents, spécifiques à un service. Si un rôle prédéfini contient un ensemble d'autorisations, cela signifie très probablement que ces autorisations doivent être accordées ensemble.

En plus de ces signaux, le modèle utilise également le plongement lexical pour calculer dans quelle mesure les autorisations sont sémantiquement similaires. Les autorisations sémantiquement similaires se "rapprochent" après le plongement et sont plus susceptibles d'être accordées ensemble. Par exemple, bigquery.datasets.get et bigquery.tables.list seront très proches l'une de l'autre après le plongement.

Toutes les données utilisées dans le pipeline de machine learning de l'outil de recommandation disposent du k-anonymat, ce qui signifie que l'identité des personnes de l'ensemble de données anonymisé ne peut pas être restaurée. Pour atteindre ce niveau d'anonymat, nous supprimons toutes les informations personnelles, telles que l'ID utilisateur associé à chaque modèle d'utilisation des autorisations. Nous supprimons ensuite tous les modèles d'utilisation qui ne s'affichent pas assez souvent dans Google Cloud. Le modèle global est entraîné à l'aide de ces données anonymisées.

Le modèle global peut être personnalisé davantage pour chaque organisation à l'aide de l'apprentissage fédéré, un processus de machine learning qui entraîne des modèles de machine learning sans exporter de données.

Comment les recommandations de rôle sont-elles générées ?

Si un insight sur une stratégie indique qu'un membre n'a pas besoin de toutes les autorisations de son rôle, l'outil de recommandation évalue le rôle pour déterminer s'il peut être révoqué ou s'il existe un autre rôle plus adapté. Si le rôle peut être révoqué, l'outil de recommandation génère une recommandation de rôle pour révoquer le rôle. Si un autre rôle est plus adapté, l'outil de recommandation génère une recommandation de rôle pour remplacer le rôle par un rôle suggéré. Ce rôle suggéré peut être un nouveau rôle personnalisé, un rôle personnalisé existant, ou un ou plusieurs rôles prédéfinis. Sauf dans le cas des recommandations pour les comptes de service gérés par Google, une recommandation de rôle ne suggère jamais de modification qui augmente le niveau d'accès d'un membre.

Les recommandations de rôle sont générées uniquement sur la base des contrôles d'accès IAM. Elles ne tiennent pas compte d'autres types de contrôles d'accès, tels que les listes de contrôle d'accès (LCA) et le contrôle des accès basé sur les rôles (RBAC) Kubernetes. Si vous utilisez d'autres types de contrôles d'accès, soyez particulièrement vigilant lorsque vous examinez les recommandations et prenez en compte le rapport entre ces contrôles d'accès et vos stratégies IAM.

De plus, les recommandations de rôle ne sont pas générées pour toutes les liaisons de rôles IAM. Pour en savoir plus sur la raison pour laquelle une liaison de rôle peut ne pas avoir de recommandation de rôle, consultez la section Disponibilité sur cette page.

Nouveaux rôles personnalisés dans les recommandations de rôle

Lorsque l'outil de recommandation suggère des remplacements pour un rôle, il suggère toujours un rôle personnalisé existant, ou un ou plusieurs rôles prédéfinis, qui semblent mieux correspondre aux besoins du membre.

Si l'outil de recommandation identifie un modèle d'utilisation des autorisations commun dans votre organisation qui ne correspond pas à un rôle prédéfini ou personnalisé existant, il peut également vous recommander de créer un nouveau rôle personnalisé au niveau du projet. Ce rôle personnalisé n'inclut que les autorisations recommandées. Vous pouvez modifier la recommandation de rôle personnalisé en ajoutant ou en supprimant des autorisations.

Si vous souhaitez appliquer le principe du moindre privilège aussi strictement que possible, choisissez le nouveau rôle personnalisé. L'outil de recommandation crée le rôle personnalisé au niveau du projet. Vous êtes responsable de la gestion et de la mise à jour des rôles personnalisés pour vos projets.

Si vous préférez utiliser un rôle géré par Google, choisissez le rôle prédéfini. Google Cloud met régulièrement à jour ces rôles en ajoutant ou en supprimant des autorisations. Pour être informé de ces mises à jour, abonnez-vous au flux d'actualités du journal des modifications des autorisations. Lorsque vous choisissez le rôle prédéfini, le membre conserve au moins quelques autorisations qu'il n'a pas utilisées, et potentiellement un grand nombre de celles-ci.

L'outil de recommandation ne recommande pas de nouveaux rôles personnalisés dans les cas suivants :

  • La recommandation concerne un rôle au niveau d'un dossier ou d'une organisation.
  • Votre organisation dispose déjà d'au moins 100 rôles personnalisés.
  • Votre projet dispose déjà d'au moins 25 rôles personnalisés.

En outre, l'outil de recommandation ne recommande pas plus de cinq nouveaux rôles personnalisés par jour dans chaque projet et pas plus de 15 nouveaux rôles personnalisés dans toute l'organisation.

Comment les insights sur les mouvements latéraux sont-ils générés ?

Le déplacement latéral fait référence à la capacité d'un compte de service à emprunter l'identité d'autres comptes de service pour plusieurs projets d'une organisation. Par exemple, un compte de service peut avoir été créé dans le projet A, mais dispose des autorisations nécessaires pour emprunter l'identité d'un compte de service dans le projet B.

Les mouvements latéraux peuvent augmenter les risques internes, car ils permettent à un pirate informatique de se déplacer latéralement dans les projets d'une organisation.

L'outil de recommandation génère des insights sur les mouvements latéraux en identifiant les liaisons de rôle au niveau du projet et du compte de service qui répondent aux critères suivants :

  • Le membre figurant dans la liaison de rôle est un compte de service qui n'a pas été créé dans le projet.
  • Le rôle inclut l'une des autorisations suivantes, qui permettent à un membre d'emprunter l'identité d'un compte de service :

    • iam.serviceAccounts.actAs
    • iam.serviceAccounts.getAccessToken
    • iam.serviceAccounts.getOpenIdToken
    • iam.serviceAccounts.implicitDelegation
    • iam.serviceAccounts.signBlob
    • iam.serviceAccounts.signJwt

Si une liaison de rôle répond à ces critères, l'outil de recommandation génère un insight de mouvement ultérieur pour la liaison. Cet insight contient des informations sur les capacités d'emprunt d'identité du compte de service, y compris sur les comptes de service qu'il peut emprunter et si des autorisations d'emprunt d'identité ont été utilisées au cours des 90 derniers jours.

L'outil de recommandation n'utilise pas lui-même les insights sur les mouvements latéraux pour générer de nouvelles recommandations de rôle. En effet, si un compte de service utilise ses autorisations d'emprunt d'identité, l'outil de recommandation ne peut pas suggérer de les supprimer en toute sécurité. Toutefois, si une recommandation de rôle suggère de supprimer ces autorisations parce qu'elles ne sont pas utilisées, l'outil de recommandation associera l'insight de déplacement latéral à cette recommandation. Cette association vous permet de hiérarchiser les recommandations de rôles pour les comptes de service disposant d'autorisations d'emprunt d'identité puissantes et inutilisées pour l'ensemble des projets.

Pour savoir comment gérer les insights sur les mouvements latéraux, consultez la page Gérer les insights sur les mouvements latéraux.

Disponibilité

Les insights sur les stratégies et les recommandations de rôle ne sont pas générés pour chaque liaison de rôle. Lisez les sections suivantes pour comprendre les liaisons de rôle pour lesquelles des insights et des recommandations de stratégie sont générés.

Disponibilité des insights sur les stratégies

Pour que l'outil de recommandation génère un insight sur une stratégie pour une liaison de rôle, les conditions suivantes doivent être remplies :

  • La liaison de rôle doit exister au niveau du projet, du dossier ou de l'organisation. L'outil de recommandation ne génère pas d'insights sur les stratégies pour les rôles accordés sur des ressources spécifiques à un service au sein d'un projet.
  • La liaison de rôle ne doit pas avoir de condition. L'outil de recommandation ne génère pas d'insights sur les stratégies pour les liaisons de rôle conditionnelles.

La génération des insights sur les stratégies pour une nouvelle liaison de rôle peut prendre jusqu'à 10 jours.

Disponibilité des informations sur les mouvements latéraux

Pour que l'outil de recommandation puisse générer des insights sur les mouvements latéraux pour une liaison de rôle, celle-ci doit exister au niveau du projet ou du compte de service.

Disponibilité des recommandations de rôle

Pour que l'outil de recommandation génère une recommandation de rôle pour une liaison de rôle, les conditions suivantes doivent être remplies :

  • La liaison de rôle doit être associée à un insight sur une stratégie. Cet insight sur une stratégie sert de base pour la recommandation.
  • La liaison de rôle doit dater de plus de 90 jours. Cela garantit que l'outil de recommandation dispose de suffisamment de données d'utilisation pour émettre une recommandation.
  • Si le membre dans la liaison de rôle est un compte de service géré par Google, la liaison de rôle doit être "propriétaire", "éditeur" ou "lecteur". L'outil de recommandation ne génère pas de recommandations de rôle pour les comptes de service gérés par Google associés à d'autres rôles. Pour en savoir plus, consultez la section Recommandations de rôles pour les comptes de service gérés par Google.

Si une liaison de rôle n'a aucun insight ou n'existe pas depuis au moins 90 jours, la colonne Autorisations analysées dans Cloud Console affiche une icône .

Dans certains cas, l'outil de recommandation ne génère pas de recommandations de rôle pour une liaison de rôle datant de plus de 90 jours et associée à un insight. Cette situation peut se produire pour les raisons suivantes :

  • Aucun rôle IAM prédéfini n'est plus approprié que le rôle actuel : Si un membre dispose déjà d'un rôle prédéfini qui minimise ses autorisations ou inclut moins d'autorisations que les autres rôles prédéfinis, l'outil de recommandation ne peut pas recommander un rôle prédéfini différent.

    Vous pouvez peut-être réduire le nombre d'autorisations du membre en lui créant un rôle personnalisé.

  • Le membre est un compte de service géré par Google et le rôle n'est pas un rôle de base. L'outil de recommandation ne génère des recommandations de rôle pour les comptes de service gérés par Google que si le compte de service dispose d'un rôle de base (propriétaire, éditeur ou lecteur). Pour en savoir plus, consultez la section Recommandations de rôles pour les comptes de service gérés par Google.

  • Aucun autre membre ne dispose du rôle de base Propriétaire pour le projet : au moins un membre doit disposer du rôle Propriétaire (roles/owner) pour chaque projet. Si un seul membre dispose de ce rôle, l'outil de recommandation ne vous recommandera pas de révoquer ou de remplacer le rôle.

Dans ces cas, la colonne Autorisations analysées dans Cloud Console indique l'utilisation des autorisations du membre, mais ne comporte pas l'icône Recommandation disponible .

Priorité et gravité

La priorité des recommandations et le niveau de gravité des insights vous aident à comprendre l'urgence d'une recommandation ou d'un insight, et à hiérarchiser les insights en conséquence.

Priorité des recommandations de rôle

Les recommandations se voient attribuer des niveaux de priorité en fonction de leur degré d'urgence perçue. Les niveaux de priorité vont de P0 (priorité la plus élevée) à P4 (priorité la plus basse).

Les recommandations IAM peuvent avoir un niveau de priorité de P2 ou P4. Les recommandations pour les liaisons de rôles avec des rôles de base (Propriétaire, Éditeur et Lecteur) sont associées à la priorité P2. Ces recommandations sont associées à une priorité élevée, car les rôles de base sont très permissifs et l'application de recommandations à ces rôles peut réduire considérablement les autorisations accordées en excès. Toutes les autres recommandations ont une priorité de P4.

Vous pouvez afficher le niveau de priorité de vos recommandations en répertoriant vos recommandations à l'aide de l'outil gcloud ou de l'API REST.

Niveau de gravité des insights

Les insights se voient attribuer des niveaux de gravité en fonction de leur degré d'urgence perçue. Les niveaux de gravité peuvent être LOW, MEDIUM, HIGH ou CRITICAL.

Les insights sur les stratégies peuvent avoir le niveau de gravité LOW ou HIGH. Les insights sur les liaisons de rôles avec des rôles de base (Propriétaire, Éditeur et Lecteur) ont le niveau de gravité HIGH. Ces insights sont associés à un niveau de gravité élevé, car les rôles de base sont très permissifs et l'adressage des insights pour ces rôles peut considérablement réduire les autorisations accordées en excès. Tous les autres insights présentent le niveau de gravité LOW.

Tous les insights sur les mouvements latéraux ont une gravité de LOW.

Comment les recommandations de rôle sont-elles appliquées ?

L'outil de recommandation n'applique pas automatiquement les recommandations. Au lieu de cela, vous devez examiner vos recommandations et décider de les appliquer ou de les ignorer. Pour savoir comment examiner, appliquer et ignorer des recommandations de rôle, consultez la section Examiner et appliquer les recommandations.

Journaux d'audit

Lorsque vous appliquez ou ignorez une recommandation, l'outil de recommandation crée une entrée de journal. Vous pouvez afficher ces entrées dans l'historique des recommandations du projet ou les consulter dans vos journaux d'audit Google Cloud.

Sous-types de recommandations de rôle

Les recommandations de rôle sont divisées en plusieurs sous-types différents en fonction de l'action qu'elles recommandent. Si vous utilisez l'outil gcloud ou l'API REST, vous pouvez utiliser ces sous-types pour filtrer vos recommandations.

Sous-type Description
REMOVE_ROLE Recommandation pour supprimer le rôle du membre.
REPLACE_ROLE Recommandation pour remplacer le rôle du membre par un rôle plus restrictif. Le remplacement recommandé peut être un nouveau rôle personnalisé, un rôle personnalisé existant, ou un ou plusieurs rôles prédéfinis.
SERVICE_AGENT_WITH_DEFAULT_ROLE Recommandation pour remplacer le rôle "Propriétaire", "Éditeur" ou "Lecteur" d'un compte de service géré par Google par le rôle attribué automatiquement au compte de service lors de sa création. Pour en savoir plus, consultez la section Recommandations pour les comptes de service gérés par Google.
SERVICE_AGENT_WITHOUT_DEFAULT_ROLES Recommandation pour remplacer le rôle "Propriétaire", "Éditeur" ou "Lecteur" d'un compte de service géré par Google par un rôle plus restrictif. Pour en savoir plus, consultez la section Recommandations pour les comptes de service gérés par Google.

Recommandations de rôle pour les comptes de service gérés par Google

Pour les comptes de service gérés par Google, l'outil de recommandation ne fournit que des recommandations pour les liaisons de rôles avec des rôles de base (propriétaire, éditeur ou lecteur).

Les recommandations pour les comptes de service gérés par Google sont divisées en deux sous-types de recommandations.

SERVICE_AGENT_WITH_DEFAULT_ROLE

Certains comptes de service gérés par Google se voient automatiquement attribuer un rôle d'agent de service lors de leur création afin de garantir le bon fonctionnement des services Google Cloud. Si vous remplacez ce rôle par un rôle de base (propriétaire, éditeur ou lecteur), l'outil de recommandation peut vous suggérer de restaurer le rôle d'agent de service d'origine pour supprimer les autorisations en excès, même si l'agent de service dispose d'autorisations qui ne sont pas incluses dans le rôle de base. Ces recommandations sont associées au sous-type SERVICE_AGENT_WITH_DEFAULT_ROLE. Elles vous aident à supprimer les autorisations en excès en toute sécurité, tout en vous assurant que l'ensemble des services Google Cloud fonctionnent correctement.

Les recommandations SERVICE_AGENT_WITH_DEFAULT_ROLE sont les seules à pouvoir suggérer des rôles dont les autorisations ne figurent pas dans le rôle actuel.

SERVICE_AGENT_WITHOUT_DEFAULT_ROLE

Si un compte de service géré par Google ne se voit pas automatiquement attribuer un rôle lors de sa création, les recommandations pour ce compte sont basées exclusivement sur les autorisations utilisées par le compte de service. Ces recommandations sont associées au sous-type SERVICE_AGENT_WITHOUT_DEFAULT_ROLE.

Exemples de recommandations de rôles

Les exemples suivants illustrent les types de recommandations que vous pouvez recevoir.

Révoquer un rôle existant

Le rôle Navigateur a été attribué à l'utilisateur my-user@example.com sur un projet. Le rôle Navigateur inclut six autorisations permettant à l'utilisateur d'afficher les ressources du projet. Cependant, au cours des 90 derniers jours, my-user@example.com n'a vu aucune ressource.

Par conséquent, l'outil de recommandation génère une recommandation de rôle qui suggère de révoquer le rôle Navigateur de my-user@example.com :

Remplacer un rôle existant

Le rôle Éditeur (roles/editor) a été attribué à un compte de service sur un projet. Ce rôle de base comprend plus de 3 000 autorisations et accorde un accès étendu au projet. Toutefois, au cours des 90 derniers jours, le compte de service n'a utilisé que certaines de ces autorisations.

Par conséquent, l'outil de recommandation génère une recommandation de rôle qui vous suggère de révoquer le rôle Éditeur et de le remplacer par une combinaison de deux autres rôles, ce qui supprime des milliers d'autorisations en excès :

Créer un rôle personnalisé

L'utilisateurmy-user@example.com s'est vu attribuer le rôle Administrateur Cloud Trace (roles/cloudtrace.admin) sur un projet. Ce rôle inclut plus de 10 autorisations, mais un insight sur une stratégie indique qu'au cours des 90 derniers jours, my-user@example.com n'a utilisé que quatre de ces autorisations.

Par conséquent, l'outil de recommandation génère une recommandation de rôle suggérant de créer un rôle personnalisé qui n'inclut que les autorisations réellement utilisées par my-user@example.com :

L'outil de recommandation propose également une autre option, qui consiste à remplacer le rôle existant par le rôle Utilisateur Cloud Trace (roles/cloudtrace.user). Ce rôle prédéfini inclut un nombre d'autorisations légèrement inférieur à celui du rôle Administrateur Cloud Trace.

Remplacer des rôles avec des autorisations suggérées par le machine learning

Le rôle Éditeur (roles/editor) a été attribué à un compte de service sur un projet. Ce rôle de base comprend plus de 3 000 autorisations et accorde un accès étendu à un projet. Toutefois, un insight sur une stratégie indique que le compte de service a utilisé moins de 10 autorisations au cours des 90 derniers jours.

L'insight sur les stratégies met également en évidence plusieurs autorisations dont le compte de service est susceptible d'avoir besoin à l'avenir. L'outil de recommandation a identifié ces autorisations à l'aide du machine learning.

L'outil de recommandation génère une recommandation de rôle qui suggère de révoquer le rôle Éditeur et de le remplacer par le rôle Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin), qui accorde un contrôle total sur les objets d'un bucket Cloud Storage. Cette modification supprime des milliers d'autorisations en excès, tout en incluant toujours les autorisations utilisées par le compte de service et celles dont le compte de service est susceptible d'avoir besoin à l'avenir.

L'outil de recommandation utilise une icône Machine learning pour identifier les autorisations ajoutées en fonction du machine learning de l'outil de recommandation plutôt qu'en fonction de l'utilisation des autorisations. Dans cet exemple, nous avons recommandé l'autorisation resourcemanager.projects.get sur la base du machine learning :

Étape suivante