Bonnes pratiques pour authentifier les applications dans Google Cloud en toute sécurité

Les documents Google Cloud peuvent vous aider dans votre travail. Vous souhaitez parfois apprendre un nouveau service ou voir une fonctionnalité en action. Lors d'une autre visite des documents, vous devrez peut-être développer une application pour une utilisation en production.

Nos documents sont souvent rédigés pour vous aider à configurer un service ou une fonctionnalité. Dans un environnement de production ou de développement, il peut être judicieux de mettre en place certaines bonnes pratiques concernant la sécurité pour votre organisation. Vous devrez peut-être authentifier vos applications différemment par rapport aux méthodes présentées dans les documents.

Pour choisir la méthode d'authentification adaptée à vos applications, utilisez l'arbre de décision ci-dessous. La suite de cet article explique chacune des méthodes sécurisées pour authentifier vos applications.

Schéma de l'arbre de décision, pour vous aider à choisir une méthode d'authentification de vos applications Chaque option est détaillée dans les sections de cet article.

Présentation des identifiants par défaut de l'application

La plupart du temps, vous souhaitez que votre code envoie des requêtes API : Vous pouvez utiliser une stratégie appelée Identifiants par défaut de l'application (Application Default Credentials, ADC) pour rechercher automatiquement les identifiants requis et authentifier votre application. Toutes les bibliothèques clientes Google Cloud sont compatibles avec l'ADC.

Avec l'ADC, vous pouvez développer localement à l'aide d'une méthode d'authentification, puis vous authentifier avec une méthode différente lors du déploiement à des fins de test ou de production. Aucun changement de code n'est nécessaire lorsque vous passez entre les différents environnements de déploiement et méthodes d'authentification compatibles.

Les bibliothèques clientes déterminent les méthodes d'authentification disponibles. L'ADC sélectionne ensuite la méthode d'authentification appropriée pour votre application pour envoyer des requêtes API, que vous développiez en local ou que vous exécutiez en production. Dans la mesure du possible, essayez d'utiliser la stratégie ADC pour vos applications.

Pour en savoir plus, consultez les pages Présentation des identifiants par défaut de l'application (ADC) et comment ADC trouve automatiquement les identifiants.

Développer et tester en local avec l'outil de ligne de commande gcloud

Dans ce scénario, l'outil de ligne de commande gcloud vous permet de modifier la configuration de votre projet à l'aide des API Cloud, ou d'écrire du code pour tester de nouvelles intégrations avec ces API. Ce type d'utilisation interactive est principalement destiné au développement et aux tests sur votre ordinateur local. Vous fournissez vos propres identifiants pour vous connecter à l'outil de ligne de commande gcloud. Cette approche vous permet de suivre l'identité à l'origine de la requête API et de gérer les quotas, ou de fournir une piste d'audit à des fins de sécurité.

Pour vous authentifier de manière interactive avec l'outil de ligne de commande gcloud afin d'émettre vos propres commandes et d'apporter des modifications de configuration, utilisez la commande gcloud auth login et spécifiez un projet de facturation appartenant à un utilisateur à l'aide de l'indicateur --billing-project. Les appels à certaines API Cloud, tels que l'API Cloud Translation ou l'API Cloud Vision, échouent si le projet de facturation n'appartient pas à un utilisateur.

Pour que votre code effectue des appels d'API Cloud depuis votre environnement de développement local, utilisez les bibliothèques clientes Google et ADC. Pour ce faire, utilisez la commande gcloud auth application-default login et spécifiez un projet de facturation appartenant à l'utilisateur avec l'indicateur --billing-project. Là encore, les appels à certaines API Cloud, tels que l'API Cloud Translation ou l'API Cloud Vision, échouent si le projet de facturation n'appartient pas à un utilisateur.

N'attribuez pas à votre compte un rôle qui accorde plus d'autorisations que nécessaire pour effectuer les requêtes API Cloud de votre application. L'outil de recommandation de la gestion de l'authentification et des accès (IAM) peut examiner les autorisations dont vous n'avez pas eu besoin au cours des 90 derniers jours afin que vous puissiez les supprimer.

Dans les environnements Google Cloud

Dans ce scénario, le code de votre application s'exécute dans Google Cloud et utilise des solutions sans serveur ou la famille de produits Compute, telle que les VM Compute Engine, Cloud Run, App Engine, Google Kubernetes Engine (GKE) ou Cloud. Fonctions. Étant donné que les applications s'exécutent dans l'environnement Google Cloud, utilisez les identifiants par défaut.

Avec les identifiants par défaut, votre application récupère le jeton d'identité associé à l'instance virtuelle qui exécute votre code. Le jeton d'identité est récupéré à partir d'un serveur de métadonnées qui s'exécute sur l'instance virtuelle. Ce jeton peut ensuite être utilisé pour authentifier et effectuer des requêtes d'API Cloud à l'aide de l'ADC.

Aucune action n'est requise de votre part pour utiliser les identifiants par défaut, car ils font partie des ADC. Vous n'avez pas besoin de modifier votre code, ni de créer et de gérer des comptes de service et une rotation des clés.

Centre de données sur site ou autre fournisseur cloud

Dans ce scénario, le code de votre application s'exécute sur votre propre infrastructure de centre de données ou sur un autre fournisseur de cloud tel qu'AWS ou Azure. S'il existe une compatibilité avec OpenID Connect (OIDC), utilisez la fédération d'identité pour les charges de travail externes et créez un pool d'identité pour les charges de travail de chaque environnement afin de fournir une authentification à vos applications.

Avec la fédération d'identité, vous pouvez utiliser la gestion de l'authentification et des accès (IAM) pour accorder des rôles IAM à des identités externes, et leur permettre d'emprunter l'identité de comptes de service. Cette approche vous permet d'accéder directement aux ressources à l'aide d'un jeton d'accès de courte durée.

Voici quelques exemples de fournisseurs d'identité:

  • AWS
  • Azure Active Directory
  • Active Directory sur site
  • Okta
  • Clusters Kubernetes

Pour en savoir plus, découvrez comment utiliser la fédération d'identité pour les charges de travail externes et créer un pool d'identités de charge de travail.

Si vous ne disposez pas de l'assistance pour OIDC ou si vous ne souhaitez pas utiliser la fédération d'identité, vous pouvez créer des comptes de service gérés par l'utilisateur. Ces comptes de service sont abordés dans la section suivante. Veillez à stocker ces identifiants de manière sécurisée dans un coffre-fort numérique que votre fournisseur peut proposer, tel qu'AWS Secret Manager ou Azure Key Vault. N'écrivez pas ces identifiants sur le disque, sauf dans un format chiffré.

Comptes de service gérés par l'utilisateur

Dans ce scénario, votre code ne s'exécute pas dans Google Cloud ni dans un environnement compatible avec OpenID Connect et la fédération d'identité. Tant que l'environnement est considéré comme approuvé et qu'il n'y a pas de contraintes du service de règles d'administration pour empêcher son utilisation, vous pouvez utiliser des comptes de service pour authentifier vos applications. ADC fonctionne avec les comptes de service, de sorte que vos applications peuvent utiliser automatiquement différentes méthodes d'authentification dans différents environnements de déploiement.

Un compte de service est un type de compte spécial utilisé par une application, et non par une personne. Chaque compte de service est associé à des paires de clés RSA publiques/privées utilisées pour l'authentification. Assurez-vous que l'environnement a peu de chances d'être compromis et que les clés du compte de service sont exposées. Pour protéger toutes les clés que vous exportez et réduire les risques de sécurité potentiels, consultez les bonnes pratiques concernant les clés de compte de service.

Vous pouvez également utiliser un jeton autosigné JWT (JSON Web Token) ou un jeton OIDC avec votre compte de service pour éviter un aller-retour inutile pour obtenir des jetons. Pour en savoir plus, consultez la section expliquant comment envoyer une requête authentifiée à l'aide de jetons JWT à une API Cloud Endpoints.

Les comptes de service exécutent des actions pour vous, mais ils peuvent disposer d'autorisations excessives et ne sont généralement pas supprimés quand ils ne sont plus nécessaires. L'outil de recommandation de la gestion de l'authentification et des accès vous permet de vérifier les autorisations qui n'ont pas été nécessaires durant les 90 derniers jours, et d'identifier les comptes de service non utilisés à supprimer.

Environnements semi-approuvés ou restreints

Dans ce scénario, le code de votre application s'exécute dans un environnement semi-approuvé ou est soumis à des restrictions de règles qui limitent les actions pouvant être effectuées. N'utilisez pas de comptes de service dans ces environnements pour vous authentifier et effectuer des requêtes d'API Cloud.

Le service de règles d'administration peut être utilisé pour appliquer des contraintes à votre projet qui vous empêchent de communiquer avec des ressources exécutées dans d'autres projets, en particulier dans les déploiements de production.

Étant donné que chaque environnement est unique et que des exigences de sécurité différentes peuvent s'appliquer, consultez les instructions spécifiques à chaque service qui pourraient vous affecter. Collaborez avec vos équipes chargées des opérations et de la sécurité afin de concevoir la solution adaptée à vos besoins.

En règle générale, vous devez concevoir un système permettant d'obtenir de manière sécurisée un jeton d'accès de courte durée. Les considérations de conception suivantes s'appliquent:

  • Ce jeton doit durer suffisamment longtemps pour que votre application puisse s'exécuter, ou il doit pouvoir être actualisé.
  • Restreindre le jeton aux rôles requis.
  • N'écrivez pas le jeton sur le disque.

Par exemple, vous pouvez accéder à une gestion de clés numériques sur site, telle que Hashicorp Vault, ou limiter l'accès à Cloud Run, puis récupérer automatiquement les identifiants de Secret Manager ou des identifiants chiffrés de Cloud Key Management Service.

Vous pouvez également contacter Google Cloud Consulting pour obtenir de l'aide concernant la conception et la création d'une solution sécurisée.

Points à noter concernant la sécurité

Si vous utilisez des jetons JWT ou OIDC dans le cadre du processus d'authentification de votre application, ceux-ci sont valides pendant toute leur durée de vie. Pour réduire les risques d'exposition, configurez la durée de vie du jeton de sorte qu'elle soit légèrement plus longue que le temps nécessaire à l'exécution de votre tâche. Par exemple, si un jeton est nécessaire pendant 15 minutes pour l'exécution de votre tâche, configurez sa durée de vie sur 20 minutes.

Vous ne pouvez pas révoquer ces jetons sauf en supprimant le compte de service parent. Ici aussi, attribuez des règles de durée de vie de jeton pour réduire la durée pendant laquelle un jeton potentiellement compromis reste utilisable.

Les clés de compte de service peuvent être volées et utilisées pour générer des identifiants de manière quasiment indétectable indéfiniment ou jusqu'à la prochaine rotation des clés. Pour protéger les clés que vous exportez et minimiser les risques de sécurité potentiels, consultez les bonnes pratiques concernant les clés de compte de service, telles que la rotation des clés et l'audit.

Si nécessaire, vous pouvez supprimer les clés du compte de service afin qu'elles ne puissent plus être utilisées.

Étape suivante

Pour en savoir plus sur l'utilisation des identifiants dans les applications, consultez la page Bonnes pratiques de gestion des identifiants.