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 d'autorisation à différents niveaux de la hiérarchie des ressources. Les ressources héritent des stratégies d'autorisation de la ressource parente. La stratégie d'autorisation applicable à une ressource combine la stratégie d'autorisation définie pour celle-ci et la stratégie d'autorisation héritée de la ressource parente.

Cette page présente plusieurs exemples illustrant le mécanisme d'héritage des stratégies d'autorisation, et expose les bonnes pratiques à prendre en considération pour créer des ressources lors du déploiement d'Identity and Access Management (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 d'autorisation 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 plus d'informations, consultez la page Contrôle des 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. 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 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 d'autorisation sont hiérarchiques et se propagent dans la structure. La stratégie d'autorisation applicable à une ressource combine la stratégie d'autorisation définie pour celle-ci et la stratégie d'autorisation héritée de la ressource parente.

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

Exemple : Pub/Sub

Dans Pub/Sub, les sujets et les abonnements sont des ressources qui appartiennent à un projet. Supposons que le projet "project_1" a sous lui un sujet "topic_a". Si vous définissez une stratégie d'autorisation sur "project_1" attribuant le rôle Éditeur à bob@example.com et une stratégie d'autorisation 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'autorisation 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, et les objets se trouvent dans des buckets. Un exemple d'utilisation de Cloud IAM avec Cloud Storage réside dans la gestion des autorisations d'accès en lecture aux fichiers importés.

Prenons un scénario dans lequel de nombreux utilisateurs peuvent importer des fichiers dans un bucket, sans qu'aucun d'eux ait la possibilité de lire ou de supprimer les fichiers importés par les autres utilisateurs. Votre experte en traitement de données doit être autorisée à supprimer les fichiers importé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 d'autorisation 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 d'autorisation signifie que n'importe quel utilisateur membre du groupe data_uploaders@example.com peut importer des fichiers dans le bucket.
    • Un membre du groupe est propriétaire des fichiers qu'il importe, mais il ne peut ni lire, ni supprimer les fichiers importé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 Compute Engine.

Autorisations pour l'affichage des règles héritées

Pour afficher les stratégies IAM héritées d'une ressource parente, vous devez disposer de l'autorisation d'afficher la stratégie IAM de la ressource parente. Par exemple, pour afficher toutes les stratégies IAM héritées d'un projet, vous devez être autorisé à afficher la stratégie IAM de l'organisation parente du projet et à afficher les stratégies IAM de tous les dossiers parents.

Pour obtenir les autorisations nécessaires pour afficher les stratégies IAM héritées des ressources parentes, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour afficher les stratégies IAM héritées des ressources parentes. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Vous devez disposer des autorisations suivantes pour afficher les stratégies IAM héritées des ressources parentes :

  • Afficher une stratégie IAM héritée d'une organisation : resourcemanager.organizations.getIamPolicy sur l'organisation
  • Afficher une stratégie IAM héritée d'un dossier : resourcemanager.folders.getIamPolicy sur le dossier
  • Afficher une stratégie IAM héritée d'un projet : resourcemanager.projects.getIamPolicy sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Bonnes pratiques

  • Veillez à ce que la structure de la hiérarchie des ressources Google Cloud reflète la structure votre organisation. La hiérarchie des ressources Google Cloud doit refléter l'organisation 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 ressources 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.

  • Attribuez des rôles à un groupe plutôt qu'à des utilisateurs individuels lorsque cela est possible. Il est plus facile de gérer les membres d'un groupe que de mettre à jour une stratégie d'autorisation. Veillez à contrôler la propriété du groupe utilisé dans les stratégies d'autorisation.

    Pour en savoir plus sur la gestion des groupes Google, consultez l'aide de Google Groupes.

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

    Pour déterminer le rôle prédéfini approprié, consultez la documentation de référence sur les rôles prédéfinis. Si aucun rôle prédéfini n'est approprié, vous pouvez également créer vos propres rôles personnalisés.

  • 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 que les stratégies d'autorisation des ressources enfants héritent des stratégies d'autorisation de leurs ressources parentes. Par exemple, si la stratégie d'autorisation d'un projet autorise un utilisateur à administrer des instances de machine virtuelle (VM) Compute Engine, il peut administrer n'importe quelle VM Compute Engine de ce projet, quelle que soit la stratégie d'autorisation définie sur chaque VM.

  • Sur chaque projet, assurez-vous qu'au moins deux comptes principaux disposent du rôle Propriétaire (roles/owner). Vous pouvez également attribuer le rôle de propriétaire à un groupe qui contient au moins deux comptes principaux.

    Cette pratique permet de s'assurer que si l'un des comptes principaux quitte votre entreprise, vous disposez toujours d'un moyen de gérer votre projet.

  • 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 d'autorisation 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 d'autorisation a été créée ou modifiée.

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

  • 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.