Google Cloud pour les utilisateurs professionnels d'AWS : gestion

Document mis à jour le 17 mars 2017

Comparez les services de gestion fournis par Amazon et Google dans leurs environnements cloud respectifs. Si vous connaissez déjà la mise en œuvre de la gestion des identités et des accès (IAM) d'Amazon Web Services (AWS), cet article vous présente en détail la gestion de l'authentification et des accès (IAM) de Google. Google Cloud et AWS proposent des solutions IAM similaires. Elles vous permettent de créer et de gérer des autorisations pour les ressources cloud, y compris les données et les applications.

Avec AWS et Google Cloud, vous pouvez accorder des autorisations aux utilisateurs, aux groupes et aux applications. Ces autorisations offrent à l'entité concernée un accès clairement défini à vos ressources cloud.

Le tableau suivant fournit une comparaison globale des termes et concepts AWS avec leurs équivalents Google Cloud.

Concept AWS Google Cloud
Identité automatisée Rôle IAM et profil d'instance Compte de service IAM
Identité des utilisateurs Gérée au sein d'IAM. Identité fédérée au système externe de gestion des identités. Gérée hors d'IAM. Identité fédérée au système externe de gestion des identités.
Stratégie Document qui répertorie explicitement les autorisations. Liste de liaisons. Une liaison associe une liste de membres à un rôle.
Rattachement de stratégie Stratégie associée à un utilisateur ou groupe IAM, ou à une ressource. Stratégie associée à une ressource.

Évaluation de la stratégie Refus par défaut. Refus par défaut.
Collecte d'autorisations Stratégie Rôle
Ensemble d'autorisations prédéfini Stratégies gérées Rôles prédéfinis
Contrôle des appels IAM AWS CloudTrail Journaux d'audit
Gestion des versions Oui Non

Gestion et intégration des ressources

Cette section vous aide à comprendre la façon dont chaque fournisseur cloud gère les ressources.

Comptes multiples dans AWS

Avec AWS, il est recommandé de configurer plusieurs comptes pour chaque équipe. Vous pouvez ensuite accorder des autorisations et des stratégies à chaque compte. Vous pouvez faciliter la gestion de plusieurs comptes AWS en configurant une facturation consolidée et en activant AWS Organizations.

Organiser des projets et des stratégies dans Google Cloud

Google Cloud fournit des ressources de conteneurs, telles que des organisations, des dossiers et des projets, qui vous permettent de regrouper et hiérarchiser les autres ressources Google Cloud, telles que les sujets Pub/Sub et les instances de machine virtuelle Compute Engine. Cette organisation hiérarchique vous aide à gérer les aspects communs de vos ressources, tels que le contrôle des accès et les paramètres de configuration.

Toutes les ressources Google Cloud appartiennent à une ressource de projet, et un compte Google individuel peut gérer plusieurs projets. Vous pouvez gérer les projets individuellement. Vous pouvez regrouper des projets similaires ou connexes dans des dossiers et les gérer à partir du dossier. De plus, vous pouvez gérer à la fois les dossiers et les projets sous une ressource "Organisation".

Le schéma suivant présente un exemple de différentes ressources ainsi que leur organisation hiérarchique dans Google Cloud. Pour interagir avec les ressources Google Cloud, vous devez fournir des informations permettant l'identification du projet pour chaque requête.

Exemple de hiérarchie de ressources Google Cloud.

Héritage des stratégies

AWS vous permet de spécifier des autorisations basées sur des ressources (qui s'appliquent directement aux ressources) ou des autorisations pour des actions spécifiques pouvant être effectuées sur une ressource donnée. La manière dont les autorisations peuvent être spécifiées dépend du service.

L'héritage de la stratégie Google Cloud IAM est complété par son organisation de ressources. Dans Google Cloud, les ressources sont organisées de façon hiérarchique. Vous pouvez donc définir des stratégies IAM qui sont diffusées à partir du nœud d'organisation. Si vous souhaitez disposer de stratégies IAM à l'échelle de l'organisation, vous pouvez les attribuer à la ressource "Organisation". Si vous souhaitez définir des stratégies pour plusieurs équipes et projets, vous pouvez utiliser les dossiers Google Cloud pour ce faire. Vous pouvez ensuite attribuer des autorisations au niveau du projet, puis au niveau des ressources au sein du projet pour un niveau de contrôle plus précis.

Identités

Les identités permettant d'accéder aux ressources cloud se divisent en deux catégories :

  • Les identités des utilisateurs finaux, représentées par leurs connexions d'entreprise habituelles. Dans le cas d'AWS, les utilisateurs finaux peuvent également être représentés par des comptes IAM.
  • Les identités automatisées, qui permettent au code de l'application d'accéder aux ressources cloud.

Identités des utilisateurs finaux dans AWS

AWS gère le compte racine requis pour chaque compte créé. AWS propose une liste de bonnes pratiques qui permettent de protéger les clés d'accès racine de votre compte AWS.

Pour autoriser l'accès à vos ressources AWS, vous pouvez configurer des utilisateurs IAM, qui sont des identités créées dans AWS, ou vous pouvez configurer la fédération à partir de votre annuaire d'entreprise. Vous pouvez faire appel à un fournisseur d'identités tiers. Dans ce cas, vous devez créer un rôle IAM, puis définir des autorisations pour ce rôle. Lorsqu'un utilisateur fédéré se connecte à AWS, il est associé au rôle et obtient les autorisations définies dans celui-ci.

Accès des utilisateurs finaux dans Google Cloud

Avec Google Cloud, vous disposez de deux options principales pour attribuer la propriété d'un projet :

  • Vous pouvez créer un projet avec un ou plusieurs propriétaires qui disposent d'un accès complet aux ressources du projet.
  • Vous pouvez créer des projets sans propriétaire explicite. Cette approche peut être utile lorsque le projet fait partie d'une organisation et que vous souhaitez que tous les projets soient détenus par celle-ci.

IAM ne vous permet pas de gérer les identités des utilisateurs finaux. Il vous permet d'accorder un accès aux utilisateurs que vous créez et gérez par d'autres moyens. Lorsque vous utilisez IAM, vous pouvez par défaut accorder l'accès aux types d'identités suivants :

  • Compte Google
  • Compte de service
  • Groupe Google
  • Domaine Google Workspace

Le service Google Groupes est l'outil recommandé pour appliquer une stratégie d'accès à un ensemble d'utilisateurs. Il vous permet d'accorder et de modifier des contrôles d'accès pour tout un groupe à la fois, plutôt que d'effectuer cette action pour chaque compte de service ou utilisateur individuel. Vous pouvez aussi ajouter des membres à un groupe Google et en supprimer facilement : il n'est pas nécessaire de mettre à jour une stratégie IAM pour ajouter ou supprimer des utilisateurs.

Si vous n'utilisez pas déjà un domaine Google Workspace pour gérer vos utilisateurs, vous pouvez fédérer votre sous-ensemble existant d'utilisateurs opérationnels à partir de nombreux annuaires d'utilisateurs populaires tels qu'Active Directory. Cette approche vous permet d'utiliser vos identités d'entreprise existantes. Vous devez d'abord faire valider votre nom de domaine auprès de Google.

Le tableau suivant répertorie et décrit les méthodes de fédération des utilisateurs dans Google Cloud.

Technique de fédération Description
Google Cloud Directory Sync Outil fourni par Google, compatible avec la plupart des services d'annuaire LDAP commerciaux et d'entreprise. Google Cloud Directory Sync vous permet d'ajouter, de modifier et de supprimer des utilisateurs, des groupes et des contacts externes afin de synchroniser les données de votre domaine Google Cloud avec votre serveur d'annuaire LDAP à l'aide de requêtes LDAP. Les données du serveur d'annuaire LDAP ne sont en aucun cas modifiées ni altérées.
Connecteurs d'identités tiers Connecteurs natifs pouvant proposer un fournisseur d'identités, lequel est directement associé au domaine provisionné dans Google Cloud. Voici quelques exemples :

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
API Google Apps Offre à une organisation le contrôle automatisé de la gestion des utilisateurs et des groupes.

Vous pouvez ensuite ajouter les identités, sous la forme d'adresses e-mail, à Google Groupes pour leur accorder l'accès aux ressources Google Cloud.

Identités automatisées dans AWS

Si vous souhaitez appeler les API AWS à partir d'une application qui ne s'exécute pas sur les ressources informatiques AWS, vous devez créer un utilisateur IAM. Vous téléchargez ensuite les clés appropriées afin que votre application appelle les API AWS.

Si vous souhaitez utiliser une identité automatisée sur une instance EC2, vous devez également créer un profil d'instance associé à celle-ci. Ce profil contient un rôle IAM et peut en fournir les identifiants à une application hébergée sur l'instance.

Un rôle IAM permet à un utilisateur ou à un groupe IAM, ou à une application s'exécutant sur EC2 ou sur un appareil mobile, d'assumer les autorisations définies par le rôle. Des identifiants temporaires sont créés et fournis à l'entité qui assume le rôle.

L'utilisation des rôles IAM permet également aux utilisateurs IAM de changer de rôle et de recevoir temporairement les autorisations associées à celui-ci lorsqu'ils agissent sur la console. Dans ce cas, les utilisateurs abandonnent leurs autorisations d'origine et obtiennent les autorisations du rôle concerné. Lorsque les utilisateurs quittent le rôle, ils perdent ces autorisations.

Identités automatisées dans Google Cloud

Avec Google Cloud, un compte de service est un compte Google spécial que les applications peuvent utiliser pour accéder aux services Google par programmation. Ce compte appartient à votre application ou à une instance Compute Engine plutôt qu'à un utilisateur final individuel.

Un compte de service peut contenir des paires de clés de compte de service, qui permettent de s'authentifier auprès de Google. Une clé de compte de service est une paire de clés publiques/privées générée par Google. Nous conservons la clé publique, tandis que l'utilisateur reçoit la clé privée.

Vous pouvez créer des comptes de service personnalisés dans des projets Google Cloud à l'aide de Google Cloud Console, de l'API Identity and Access Management ou de l'outil de ligne de commande gcloud.

Si vous avez l'intention d'utiliser uniquement le compte de service avec des applications s'exécutant sur les services Google Cloud Computing, vous n'avez pas besoin de télécharger les clés privées, car vous pouvez utiliser des clés gérées par Google Cloud.

Les comptes de service IAM peuvent être traités comme des ressources ou des identités. Le compte de service dispose d'une identité, et vous lui accordez des autorisations en lui attribuant un rôle pour qu'il puisse accéder à une ressource, telle qu'un projet.

Lorsque vous consultez un compte de service en tant que ressource, vous pouvez autoriser un utilisateur à accéder à ce compte de service comme vous le feriez pour d'autres ressources Google Cloud. Vous pouvez attribuer à un utilisateur un rôle de propriétaire, éditeur, lecteur ou un rôle non défini serviceAccountUser pour lui permettre d'accéder au compte de service. Un utilisateur qui dispose du rôle serviceAccountUser pour un compte de service peut accéder à toutes les ressources avec les mêmes autorisations que le compte de service. Cette fonctionnalité est comparable à l'utilisation du rôle IAM décrite dans la section précédente.

Les clés de compte de service peuvent être des clés gérées par les utilisateurs que vous gérez ou des clés gérées Google Cloud qui sont gérées par Google Cloud.

Vous pouvez créer et gérer des clés gérées par les utilisateurs à l'aide de Cloud console, de l'API IAM ou de l'outil de ligne de commande gcloud. Vous êtes responsable de la sécurité et de la rotation des clés.

Les clés gérées par Google Cloud sont utilisées par des services tels qu'App Engine et Compute Engine. Vous ne pouvez pas créer ou télécharger explicitement une clé gérée par Google Cloud. Google gère les clés et assure leur rotation quotidienne.

Attribution d'autorisations

Google Cloud et AWS emploient tous deux les termes rôle et stratégie, mais leurs usages sont légèrement différents. Ces différences peuvent entraîner une confusion dans la comparaison entre AWS IAM et IAM. Un ensemble d'autorisations dans Google Cloud est appelé un rôle, mais avec AWS, il s'agit d'une stratégie.

Exemple d'autorisations AWS

Avec AWS, vous spécifiez les autorisations en tant qu'action, ressource et effet dans la définition de la stratégie. Par exemple, voici à quoi ressemble une stratégie AWS qui permet (l'effet) à un utilisateur de répertorier tous les buckets (l'action) dans un compte (la ressource) :

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

Les stratégies AWS IAM autonomes pouvant être associées à plusieurs utilisateurs, groupes et rôles sont appelées stratégies gérées. Celles-ci peuvent être créées et gérées par AWS, ou bien créées et gérées par le client (depuis votre compte AWS).

Exemple d'autorisations Google Cloud

Google Cloud utilise une approche prédéfinie basée sur le rôle. Ainsi, pour un cas d'utilisation courant tel que l'établissement de la liste de tous les buckets d'un projet, le rôle de lecteur suffit. Ce rôle doit ensuite être attribué à l'utilisateur ou au groupe, et le document qui en découle et qui associe les utilisateurs ou les groupes au rôle constitue une stratégie. Voici à quoi ressemble la définition d'une stratégie :

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

Stratégies AWS

AWS vous permet non seulement d'associer des stratégies à une identité, mais aussi d'associer une stratégie à une ressource. Pour cela, vous devez intégrer une identité ou un rôle capable d'accéder à la ressource au sein de la stratégie.

Dans la plupart des cas, AWS recommande l'utilisation de stratégies gérées. Consultez la documentation AWS pour obtenir des conseils relatifs au choix de la stratégie (gérée ou intégrée).

Stratégies Google Cloud

Examinons maintenant une stratégie Google Cloud déclarée dans un fichier JSON, appelé iam-gcs-access.json,, qui attribue le rôle viewer à un groupe d'utilisateurs et le rôle objectCreator à un compte de service. Une application peut ajouter des objets aux buckets d'un projet à l'aide du compte de service. L'exemple suivant vous montre comment créer plusieurs liaisons entre des membres et des rôles dans une stratégie unique.

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

Cette stratégie peut ensuite être liée à la ressource, ici, un projet, en utilisant Cloud Console, la commande set-iam-policy dans l'outil gcloud ou l'API pour attribuer la stratégie au projet. Dans cet exemple, la commande gcloud se présente comme suit :

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

[PROJECT_ID] représente votre ID de projet Google Cloud.

Cette démarche est comparable à l'intégration d'une identité ou d'un rôle capable d'accéder à la ressource au sein de la stratégie dans AWS.

Gérer des stratégies dans Google Cloud

Nous vous recommandons de traiter vos stratégies de la même manière que votre code : conservez-les dans un système de contrôle de version avec le reste des éléments qui vous permettent de définir votre environnement cloud. Lorsque vous mettez à jour vos stratégies, créez une nouvelle version.

Bien qu'AWS comporte les deux types de stratégies précédemment évoqués, Google Cloud ne dispose que d'un seul type de stratégie et vous permet de gérer vos stratégies de manière flexible à l'aide du système de contrôle de version que vous jugez approprié. Google Cloud fournit des dépôts Git privés, complets et hébergés sur Google Cloud : Cloud Source Repositories.

Si vous possédez déjà un dépôt sur GitHub ou Bitbucket, vous pouvez l'associer à Cloud Source Repositories. Les dépôts connectés et Cloud Source Repositories restent automatiquement synchronisés. Cloud Source Repositories propose également un éditeur source qui vous permet de parcourir, d'afficher, de modifier et de valider les changements apportés aux fichiers de votre dépôt depuis Cloud Console.

Si vous préférez utiliser vos solutions de contrôle de version actuelles, vous pouvez le faire sur Google Cloud.

Tester et vérifier les autorisations

Lorsque vous utilisez AWS, vous pouvez avoir recours au simulateur de stratégie IAM, qui permet de tester et de valider des stratégies nouvelles et existantes, et de connaître les stratégies définies pour un utilisateur, un groupe ou une ressource.

Avec Google Cloud, vous pouvez exécuter la commande gcloud get-iam-policy pour afficher la définition de la stratégie :

gcloud projects get-iam-policy [PROJECT_ID]

Vous pouvez vous appuyer sur la définition renvoyée pour vérifier les stratégies associées à la ressource. Vous pouvez également utiliser Cloud Console pour accéder à une ressource spécifique et vérifier les autorisations.

Pour vérifier les autorisations attribuées à une identité, vous pouvez sélectionner l'identité dans Cloud Console et afficher les rôles auxquels l'identité est associée. Vous pouvez également vous connecter avec cette identité ou avec une identité de test disposant des mêmes autorisations pour consulter les ressources accessibles par l'identité depuis Cloud Console.

Propagation des autorisations

Avec AWS, toutes les stratégies sont évaluées. L'ordre dans lequel elles sont définies n'a aucun impact perceptible, car le résultat final est "autorisé" ou "refusé". En utilisant un refus explicite, vous pouvez empêcher une stratégie étendue d'autoriser l'accès à un grand nombre de ressources. Cette procédure est décrite en détail dans la section Identification d'une demande autorisée ou refusée dans un compte.

Avec Google Cloud, 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. Comme les rôles sont concentriques, si vous accordez plusieurs rôles au même utilisateur, celui-ci obtient les autorisations du rôle le plus influent. Vous pouvez consulter quelques exemples de scénarios dans la section Utiliser la hiérarchie des ressources pour le contrôle des accès.

Audit IAM

Pour contrôler l'activité IAM, Amazon propose AWS CloudTrail, qui enregistre et consigne les appels à l'API AWS pour votre compte. CloudTrail envoie ces journaux à un compte Amazon S3 que vous spécifiez.

Google Cloud propose des journaux d'audit Cloud, qui enregistrent l'activité des administrateurs et l'accès aux données. Ces deux flux sont générés par les services Google Cloud pour vous aider à déterminer qui fait quoi, où et quand, au niveau de vos projets Google Cloud.

Les entrées individuelles des journaux d'audit sont conservées pendant une durée spécifiée dans la suite d'opérations Google Cloud. Vous pouvez ainsi consulter en un clin d'œil le tableau de bord des activités récentes. Ces entrées sont supprimées de la suite d'opérations Google Cloud après une période spécifiée. Les règles de quotas de Cloud Logging renseignent la durée pendant laquelle les entrées de journal sont conservées. Vous ne pouvez pas supprimer ou modifier les journaux d'audit.

La journalisation des rôles IAM vous permet de limiter l'accès aux ressources liées à la journalisation d'un projet ou d'une organisation.

Pour prolonger la période de conservation, vous pouvez exporter les entrées de journal d'audit vers un bucket Cloud Storage, un ensemble de données BigQuery, un sujet Pub/Sub ou une combinaison des trois.

Étapes suivantes

Consultez les autres articles Google Cloud pour les utilisateurs professionnels d'AWS :