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

Dans Cloud Platform, 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 IAM à différents niveaux de la hiérarchie des ressources. Celles-ci 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 IAM, et expose les bonnes pratiques à prendre en considération pour créer des ressources lors du déploiement d'IAM.

Prérequis

Contexte

Le diagramme suivant montre un exemple de hiérarchie de ressources Cloud Platform :

Hiérarchie des ressources

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 IAM attribués à ce niveau sont hérités par toutes les ressources relevant de l'organisation. Pour en savoir plus, consultez la page Contrôle d'accès pour les organisations utilisant 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 en savoir plus, consultez la page Contrôler l'accès aux dossiers à l'aide d'une stratégie 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 IAM attribués au niveau du projet sont hérités des ressources de ce projet. Pour en savoir plus, consultez la page Contrôle des accès aux projets avec l'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 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 : Cloud Pub/Sub

Dans Cloud 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 d'éditeur à bob@gmail.com et une stratégie sur "topic_a" attribuant le rôle de rédacteur à alice@gmail.com, vous attribuez en fait le rôle d'éditeur à bob@gmail.com et le rôle d'éditeur Pub/Sub à alice@gmail.com pour "topic_a".

Voici le diagramme correspondant à cet exemple :

Exemple Pub/Sub

Les rôles de propriétaire, d'éditeur et de lecteur sont concentriques : le rôle de propriétaire inclut les autorisations comprises dans le rôle d'éditeur, qui inclut à son tour les autorisations du rôle de 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@gmail.com le rôle d'éditeur au niveau du projet et le rôle de lecteur pour le sujet "topic_a", Bob reçoit en réalité le rôle d'éditeur pour "topic_a". En effet, vous avez déjà attribué à Bob le rôle d'éditeur pour "topic_a", et ce rôle est hérité de la stratégie définie sur "project_a".

Voici le diagramme correspondant à cet exemple :

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 d'administrateur des objets de l'espace 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 de 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.

Voici le diagramme correspondant à cet exemple :

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 d'administrateur de réseaux Compute au niveau de l'organisation et à alice@example.com le rôle d'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 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 IAM Cloud.

  • Accordez des rôles au plus petit champ d'application requis. Par exemple, si un utilisateur a besoin d'un accès uniquement pour ajouter des messages à un sujet Cloud Pub/Sub, accordez le rôle d'éditeur à l'utilisateur pour ce sujet.

  • N'oubliez pas qu'un ensemble de stratégies défini 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.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Cloud IAM