Utiliser la hiérarchie des ressources pour le contrôle des accès

Dans Google Cloud, les ressources sont organisées de façon hiérarchique. Le nœud de l'organisation constitue le nœud racine de la hiérarchie, les projets représentent les enfants de l'organisation et les autres ressources sont les enfants des projets. Vous pouvez définir des stratégies Cloud Identity and Access Management (Cloud IAM) à différents niveaux de la hiérarchie des ressources. Les ressources héritent des stratégies de la ressource parente. La stratégie applicable à une ressource combine la stratégie définie pour celle-ci et la stratégie héritée de la ressource parente.

Cette page présente plusieurs exemples illustrant le mécanisme d'héritage des stratégies Cloud IAM, et expose les bonnes pratiques à prendre en considération pour créer des ressources lors du déploiement de Cloud IAM.

Prérequis

Contexte

Le schéma suivant montre un exemple de hiérarchie de ressources Google Cloud.

De haut en bas, la hiérarchie inclut les organisations, les dossiers, les projets et les ressources spécifiques aux services.

Cloud IAM vous permet de définir des stratégies aux niveaux suivants de la hiérarchie des ressources :

  • Niveau Organisation : La ressource Organisation représente votre entreprise. Les rôles Cloud IAM attribués à ce niveau sont hérités par toutes les ressources relevant de l'organisation. Pour plus d'informations, consultez la section Contrôle d'accès pour les organisations utilisant Cloud IAM.

  • Niveau Dossier : Un dossier peut contenir des projets, d'autres dossiers ou une combinaison des deux. Les rôles attribués au niveau de dossier le plus élevé sont hérités par les projets ou les autres dossiers contenus dans le dossier parent. Pour plus d'informations, consultez la section Contrôler l'accès aux dossiers à l'aide d'une stratégie Cloud IAM.

  • Niveau Projet : Les projets représentent une limite de confiance au sein de votre entreprise. Les services d'un même projet présentent un niveau de confiance par défaut. Par exemple, les instances App Engine peuvent accéder aux buckets Cloud Storage qui appartiennent au même projet qu'elles. Les rôles Cloud IAM attribués au niveau du projet sont hérités des ressources de ce projet. Pour plus d'informations, consultez la section Contrôle des accès aux projets Cloud IAM.

  • Niveau Ressource : Outre les systèmes de LCA Cloud Storage et BigQuery existants, des ressources supplémentaires telles que les ensembles de données Genomics, les sujets Pub/Sub et les instances Compute Engine prennent en charge des rôles de niveau inférieur, ce qui vous permet d'accorder à certains utilisateurs une autorisation sur une ressource unique au sein d'un projet.

Les stratégies Cloud IAM sont hiérarchiques et se propagent dans la structure. La stratégie applicable à une ressource combine la stratégie définie pour celle-ci et la stratégie héritée de la ressource parente.

Les exemples suivants montrent concrètement comment fonctionne l'héritage de stratégies.

Exemple : Pub/Sub

Dans Pub/Sub, les sujets et les abonnements sont des ressources qui appartiennent à un projet. Supposons que le projet "project_a" a sous lui un sujet "topic_a". Si vous définissez une stratégie sur "project_a" attribuant le rôle Éditeur à bob@example.com et une stratégie sur "topic_a" attribuant le rôle Rédacteur à alice@example.com, vous attribuez en fait le rôle Éditeur à bob@example.com et le rôle Rédacteur à alice@example.com pour "topic_a".

Le schéma suivant illustre l'exemple précédent.

Exemple Pub/Sub.

Les rôles Propriétaire, Éditeur et Lecteur sont concentriques : le rôle Propriétaire inclut les autorisations comprises dans le rôle Éditeur, qui inclut à son tour les autorisations du rôle Lecteur. Si vous tentez d'attribuer un rôle large et un rôle limité à une même personne (par exemple, Éditeur et Lecteur), seul le rôle le plus large lui est attribué. Par exemple, si vous attribuez à bob@example.com le rôle Éditeur au niveau du projet et le rôle Lecteur pour le sujet "topic_a", Bob reçoit en réalité le rôle Éditeur pour "topic_a". En effet, vous avez déjà attribué à Bob le rôle Éditeur pour "topic_a", et ce rôle est hérité de la stratégie définie sur "project_a".

Le schéma suivant illustre l'exemple précédent.

Exemple Pub/Sub.

Exemple : Cloud Storage

Dans Cloud Storage, les buckets et les objets constituent des ressources, les buckets étant les conteneurs dans lesquels sont placés les objets. Un exemple d'utilisation de Cloud IAM avec Cloud Storage consiste dans la gestion des autorisations d'accès en lecture aux fichiers téléchargés.

Prenons un scénario dans lequel de nombreux utilisateurs peuvent télécharger des fichiers dans un bucket, sans qu'aucun d'eux ait la possibilité de lire ou de supprimer les fichiers téléchargés par les autres utilisateurs. Votre experte en traitement de données doit être autorisée à supprimer les fichiers téléchargés, mais pas à supprimer des buckets, car d'autres utilisateurs utilisent l'emplacement de ces buckets pour importer leurs fichiers. Dans un tel scénario, il vous faudrait définir les stratégies relatives au projet comme suit :

  • Attribuez le rôle Administrateur des objets de l'espace de stockage à votre experte en traitement de données, Alice (alice@example.com).
    • Alice dispose de droits d'administrateur d'objets au niveau du projet, et peut donc lire, ajouter et supprimer tout objet dans n'importe quel bucket du projet.
  • Attribuez le rôle Créateur des objets de l'espace de stockage à un groupe d'utilisateurs (data_uploaders@example.com).
    • Cette stratégie signifie que n'importe quel utilisateur membre du groupe data_uploaders@example.com peut télécharger des fichiers dans le bucket.
    • Un membre du groupe est propriétaire des fichiers qu'il télécharge, mais il ne peut ni lire, ni supprimer les fichiers téléchargés par d'autres utilisateurs.

Le schéma suivant illustre l'exemple précédent.

Exemple Cloud Storage.

Exemple : Compute Engine

Dans les grandes entreprises, la gestion des ressources réseau et de sécurité, telles que les pare-feu, est généralement confiée à une équipe dédiée, distincte de l'équipe de développement. Les équipes de développement peuvent cependant souhaiter avoir la possibilité de lancer des instances et d'effectuer d'autres actions liées aux instances de leurs projets. En attribuant à bob@example.com le rôle Administrateur de réseaux Compute au niveau de l'organisation et à alice@example.com le rôle Administrateur d'instances Compute sur son projet "project_2", vous autorisez Alice à exécuter des actions sur les instances tout en l'empêchant de modifier les ressources réseau associées à son projet. Seul Bob peut apporter des modifications aux ressources réseau de l'organisation ainsi qu'à tous les projets relevant de cette organisation.

Exemple Cloud Storage.

Bonnes pratiques

  • Veillez à ce que la structure de la hiérarchie des stratégies IAM Cloud reflète la structure de votre organisation. La hiérarchie de la stratégie IAM Cloud doit refléter la structure de votre entreprise, qu'il s'agisse d'une start-up, d'une PME ou d'une grande entreprise. Une start-up peut démarrer avec une hiérarchie de stratégies plate dépourvue de ressource Organisation. Par la suite, avec l'augmentation du nombre de projets et de personnes collaborant sur des projets, il peut être judicieux d'introduire une ressource Organisation. Une ressource Organisation est recommandée pour les grandes entreprises comptant plusieurs départements et différentes équipes assumant chacune la responsabilité de son propre ensemble d'applications et de services.

  • Utilisez des projets pour regrouper des ressources partageant la même limite de confiance. Par exemple, les ressources d'un même produit ou d'un même microservice peuvent appartenir au même projet.

  • Définissez les stratégies au niveau de l'organisation ou du projet plutôt qu'au niveau de la ressource. À mesure que de nouvelles ressources sont ajoutées, il peut être judicieux de faire en sorte qu'elles héritent automatiquement des stratégies de leur ressource parente. Par exemple, lorsque de nouvelles machines virtuelles sont ajoutées au projet par autoscaling, elles héritent automatiquement de la stratégie définie au niveau du projet.

  • Lors de l'attribution de rôles Cloud IAM, appliquez le principe de sécurité du moindre privilège en accordant le niveau d'accès minimal nécessaire à vos ressources.

  • Attribuez des rôles à un groupe Google plutôt qu'à des utilisateurs individuels lorsque cela est possible. Il est plus facile de gérer les membres d'un groupe Google que de mettre à jour une stratégie IAM Cloud.

  • Contrôlez la propriété du groupe Google utilisé dans les stratégies Cloud IAM.

  • Accordez des rôles au plus petit champ d'application requis. Par exemple, si un utilisateur n'a besoin que d'un accès lui permettant de publier des messages dans un sujet Pub/Sub, accordez-lui simplement le rôle Éditeur Pub/Sub pour ce sujet.

  • N'oubliez pas qu'un ensemble de stratégies définies sur une ressource enfant ne peut pas restreindre l'accès accordé au niveau de sa ressource parente. Vérifiez la stratégie accordée sur chaque ressource en tenant compte de l'héritage hiérarchique.

  • Si vous devez attribuer à un utilisateur ou à un groupe un rôle couvrant plusieurs projets, définissez ce rôle au niveau du dossier plutôt qu'au niveau du projet.

  • Recourez à des libellés pour annoter, grouper et filtrer les ressources.

  • Auditez vos stratégies pour assurer la conformité. Les journaux d'audit contiennent tous les appels setIamPolicy(), ce qui vous permet de connaître le moment où une stratégie a été créée ou modifiée.

  • Auditez la propriété et la composition des groupes Google utilisés dans les stratégies.

  • Si vous souhaitez limiter la création de projets dans votre organisation, modifiez la règle d'accès de l'organisation pour attribuer le rôle de créateur de projet à un groupe que vous gérez.