Bonnes pratiques pour protéger les identifiants de développeur

Découvrez les bonnes pratiques pour sécuriser les postes de travail des développeurs et empêcher le vol et l' utilisation abusive d' Google Cloud identifiants, y compris les jetons porteurs OAuth deGoogle Cloud CLI tokens, les identifiants par défaut de l' application et les clés locales.

Ce document est destiné aux équipes de sécurité ou aux architectes cloud chargés de sécuriser leurs ressources cloud contre tout accès illégitime. Découvrez les contrôles disponibles permettant de réduire de manière proactive l'impact d'une compromission des identifiants de développeur, et de corriger votre environnement après qu'un point de terminaison a été compromis.

Risque de compromission des identifiants

Un pirate informatique peut compromettre des identifiants s'il a accès à un point de terminaison sur lequel un compte utilisateur légitime ou un compte de service s'est déjà authentifié avec Google Cloud ou gcloud CLI. Le pirate informatique peut ensuite copier ces jetons vers un autre point de terminaison, dont il a le contrôle, afin d'émettre des requêtes qui vont usurper l'identité légitime. Même si vous supprimez l'accès du pirate au point de terminaison compromis, il peut continuer à émettre des requêtes API authentifiées à l'aide des jetons copiés. Pour limiter ce risque, vous pouvez contrôler l'accès à vos systèmes à l'aide d'identifiants éphémères et offrant un accès contextuel.

Présentation des identifiants de développeur

Les identifiants Google Cloud suivants se trouvent généralement sur les postes de travail des développeurs :

Les sections suivantes décrivent comment chaque type d'identifiant est stocké et utilisé.

Jetons OAuth de gcloud CLI

gcloud CLI utilise des jetons d'accès OAuth 2.0 pour authentifier les requêtes des Google Cloud API. Le flux OAuth varie en fonction des types d'identifiants utilisés, mais le jeton d'accès et les autres identifiants sont généralement accessibles localement. Dans chaque cas, le jeton d'accès expire au bout de 60 minutes par défaut, mais peut durer jusqu'à 12 heures en cas de contraintes de durée de vie prolongée. Toutefois, d'autres types d'identifiants peuvent être persistants.

Lorsque vous définissez une autorisation de gcloud CLI basée sur un compte utilisateur, gcloud CLI lance un flux d'autorisation OAuth à trois acteurs pour accéder aux Google Cloud API au nom de l'utilisateur. Une fois que l'utilisateur a terminé le processus d'autorisation, gcloud CLI reçoit un jeton d'accès, ainsi qu'un jeton d'actualisation qui lui permet de demander de nouveaux jetons d'accès. Le jeton d'actualisation de longue durée est conservé jusqu'à ce que ses conditions d'expiration soient remplies.

Lorsque vous autorisez la gcloud CLI avec un compte de service, la gcloud CLI lance un flux d'authentification OAuth à deux acteurs pour accéder aux Google Cloud API avec l'identité du compte de service. Une fois que vous avez activé un compte de service à partir d'un fichier de clé privée, gcloud CLI utilise cette clé pour demander périodiquement un jeton d'accès. La clé privée de longue durée est stockée dans la configuration de gcloud CLI et reste valide jusqu'à ce que vous désactiviez ou supprimiez la clé de compte de service.

Lorsque vous exécutez gcloud CLI dans un Google Cloud environnement, tel que Compute Engine ou Cloud Shell, l'application peut automatiquement trouver les identifiants et s'authentifier en tant que compte de service. Par exemple, dans Compute Engine, une application telle que gcloud CLI peut interroger le serveur de métadonnées pour obtenir un jeton d'accès. Google gère et fait pivoter la clé de signature privée utilisée pour créer le jeton d'accès, et les identifiants de longue durée ne sont pas exposés à l'application.

Identifiants par défaut de l'application

Les identifiants par défaut de l'application sont utilisés par les applications pour s'authentifier auprès des Google Cloud API. Les développeurs peuvent générer des identifiants par défaut de l'application en exécutant gcloud auth application-default login. Cette commande écrit un fichier JSON en texte brut ($HOME/.config/gcloud/application_default_credentials.json ou %APPDATA%\gcloud\application_default_credentials.json), qui contient un jeton d'actualisation OAuth 2.0 et des identifiants client pour les bibliothèques clientes.

N'importe quelle bibliothèque cliente ou n'importe quel script personnalisé peut utiliser ces identifiants pour appeler Google Cloud des API.

Étant donné que les identifiants par défaut de l'application sont enregistrés en texte brut, tout processus ou script non approuvé s'exécutant dans le contexte de l'utilisateur peut accéder directement au fichier ou utiliser des commandes telles que gcloud auth application-default print-access-token pour récupérer les jetons d'accès actifs.

Les logiciels malveillants ciblent souvent le répertoire ~/.config/gcloud/ pour collecter application_default_credentials.json.

Pour en savoir plus, consultez Identifiants par défaut de l'application.

Clés de compte de service

Les clés de compte de service sont des fichiers de clé JSON privés qui sont téléchargés depuis la Google Cloud console. Ces clés sont utilisées par les applications pour s'authentifier auprès des Google Cloud API. Les clés de compte de service peuvent être stockées aux emplacements suivants :

  • Répertoire de configuration de gcloud CLI après l'exécution de gcloud auth activate-service-account
  • Système de fichiers local
  • Dépôt de code interne

Les clés de compte de service sur les points de terminaison des développeurs ne sont pas liées à la validation en deux étapes, n'ont pas de limites de session et n'expirent pas automatiquement.

Un pirate informatique qui vole une clé de compte de service peut créer des jetons d'accès au compte de service pour maintenir un accès persistant.

Pour plus d'informations, consultez la page Bonnes pratiques pour gérer les clés de compte de service.

Clés SSH

Les clés SSH sont utilisées pour s'authentifier auprès des instances Compute Engine. Les développeurs peuvent générer des clés SSH à l'aide de gcloud compute ssh. Cette commande génère des clés privées locales dans ~/.ssh/google_compute_engine. Les clés SSH sont de longue durée.

Un pirate informatique peut utiliser une clé SSH volée pour accéder à une VM, puis interroger le serveur de métadonnées afin d'extraire un jeton de compte de service associé. Cette attaque contourne les pare-feu de périmètre externes.

Au lieu d'utiliser des clés SSH, envisagez d'utiliser OS Login avec la validation en deux étapes. Pour en savoir plus, consultez Appliquer la validation en deux étapes pour accéder au serveur distant.

Cookies de navigateur

Les cookies de navigateur authentifient les requêtes HTTP Web auprès de la Google Cloud console et de Cloud Shell. Les cookies de navigateur sont créés automatiquement lorsqu'un utilisateur se connecte à la Google Cloud console.

Les cookies sont stockés dans le répertoire de profil du navigateur sur le poste de travail local. Par exemple, Google Chrome stocke les cookies dans ~/.config/google-chrome/ sous Linux ou %LOCALAPPDATA%\Google\Chrome\User Data sous Windows.

Les cookies de navigateur sont des identifiants de longue durée qui ne sont invalidés que lorsqu'un utilisateur se déconnecte, lorsqu'un délai avant expiration de la session survient ou lorsqu'un administrateur réinitialise la session utilisateur dans la console d'administration.

Un pirate informatique qui vole ces cookies peut les importer dans un autre navigateur pour pirater des sessions de console actives Google Cloud , en contournant l'authentification.

Pour réduire le risque de vol de cookies de session, définissez la durée de session pour Google Cloud les services.

Jetons d'accès de la fédération des identités des employés

Les développeurs peuvent utiliser la fédération des identités des employés pour s'authentifier via un fournisseur d'identité externe afin de pouvoir accéder aux Google Cloud ressources.

Pour se connecter avec une identité fédérée, les développeurs utilisent un fichier de configuration de connexion (créé avec la gcloud iam workforce-pools create-login-config commande) et se connectent à gcloud CLI. Après l'authentification auprès du fournisseur d'identité externe, le service de jetons de sécurité échange le code d'autorisation contre un jeton d'accès fédéré de courte durée et un jeton d'actualisation OAuth.

gcloud CLI stocke les métadonnées d'identifiants et les jetons d'actualisation dans une base de données d'identifiants locale, et met en cache les jetons d'accès actifs dans le répertoire de configuration de gcloud CLI. Les jetons d'accès fédérés sont des identifiants de courte durée qui expirent après un délai défini (60 minutes par défaut).

Un pirate informatique qui compromet un point de terminaison peut extraire des jetons d'accès fédérés actifs ou utiliser gcloud auth print-access-token pour emprunter l'identité du compte principal des employés. Si l'identité des employés dispose de droits d'emprunt d'identité, le pirate informatique peut également demander des jetons d'accès au compte de service pour augmenter ses privilèges.

Pour réduire les risques, configurez la durée de la session sur votre pool d'identités des employés sur la durée minimale nécessaire et alignez-la sur les règles de réauthentification et de délai avant expiration de la session de votre fournisseur d'identité externe. Pour en savoir plus sur le stockage et la gestion des identifiants, consultez la page Bonnes pratiques pour utiliser la fédération d'identité de charge de travail.

Impact de la compromission des identifiants

Si un pirate informatique parvient à compromettre un point de terminaison, les identifiants tels que les jetons OAuth vont constituer des cibles de choix, car ils permettent aux pirates informatiques de conserver ou d'augmenter leur accès.

Un développeur peut devoir légitimement afficher ses propres identifiants lors de l'écriture et du débogage de code. Par exemple, un développeur peut avoir besoin d' authentifier des requêtes REST auprès des Google Cloud services lorsqu'il travaille avec une bibliothèque cliente non compatible. Le développeur dispose de différentes méthodes pour afficher ses identifiants :

Toutefois, un pirate informatique peut utiliser ces mêmes techniques après avoir compromis un point de terminaison.

Si un pirate informatique compromet un point de terminaison, la menace principale est qu'il va pouvoir exécuter des commandes gcloud CLI ou d'autres portions de code en se servant des identifiants légitimes de l'identité authentifiée. En outre, le pirate informatique peut copier les identifiants sur un autre point de terminaison qu'il contrôle, afin de conserver son accès. Il existe aussi une menace secondaire associée à ce vol d'identifiants : le pirate informatique peut toujours utiliser les identifiants de longue durée pour obtenir un accès persistant, même après que vous avez supprimé l'accès au point de terminaison compromis.

Si le pirate informatique parvient à compromettre les identifiants de développeur, il peut effectuer les actions suivantes :

  • Emprunter l'identité de l'utilisateur ou du compte de service compromis. Le trafic d'API qui utilise les jetons compromis est consigné comme s'il provenait de l'utilisateur ou du compte de service compromis, d'où une distinction complexe dans les journaux entre activité normale et activité malveillante.
  • Demander des jetons d'accès indéfiniment à l'aide d'un jeton d'actualisation OAuth persistant (à partir de gcloud CLI ou des identifiants par défaut de l'application) ou d'une clé privée associée à un compte de service.
  • Contourner l'authentification demandant le mot de passe de l'utilisateur ou la validation en deux étapes, car les jetons sont accordés après le flux de connexion.
  • Utiliser des clés SSH volées pour accéder aux instances Compute Engine et interroger le serveur de métadonnées afin de voler les jetons de compte de service associés.
  • Utiliser des cookies de navigateur volés pour pirater des sessions de console actives Google Cloud sans avoir besoin du mot de passe de l'utilisateur ni de la validation en deux étapes.
  • Utiliser des jetons d'accès fédérés volés pour accéder aux ressources accordées aux pools d'identités des employés ou augmenter les privilèges en empruntant l'identité de comptes de service.

Bonnes pratiques pour limiter les risques

Mettez en œuvre les contrôles décrits dans les sections suivantes pour réduire le risque de compromission des identifiants de développeur. Si vous suivez les bonnes pratiques de sécurité décrites dans le plan de base de l'entreprise ou dans la conception de la zone de destination dans Google Cloud, vous disposez peut-être déjà de ces contrôles.

Définir la durée de session pour les Google Cloud services

Pour réduire la durée d'exploitation d'un jeton compromis, définissez la durée de session pour Google Cloud les services. Pour les nouveaux clients, une durée de session par défaut de 16 heures est automatiquement appliquée. Les clients qui ont créé leur Google Cloud organisation avant 2023 peuvent avoir un paramètre par défaut qui ne nécessite jamais de réauthentification. Vérifiez ce paramètre pour vous assurer que vous disposez d'une règle de réauthentification avec une durée de session comprise entre 1 et 24 heures. La règle de réauthentification oblige l'utilisateur à se réauthentifier régulièrement sur gcloud CLI avec son mot de passe ou sa clé de sécurité.

La durée de session pour les Google Cloud services est un paramètre distinct de la durée de session pour les services Google, qui contrôle les sessions Web pour la connexion aux services Google Workspace, mais ne contrôle pas la réauthentification pour Google Cloud. Si vous utilisez les services Google Workspace, définissez également la durée de session pour ceux-ci.

Configurer VPC Service Controls

Configurez VPC Service Controls dans votre environnement pour garantir que seul Google Cloud le trafic d'API provenant du périmètre que vous avez défini peut accéder aux ressources compatibles. Le périmètre de service limite l'utilité des identifiants compromis, car il bloque les requêtes adressées à des services restreints provenant de points de terminaison contrôlés par le pirate informatique et extérieurs à votre environnement.

Configurer Chrome Enterprise Premium

Configurez des règles Chrome Enterprise Premium pour aider à sécuriser la Google Cloud console et Google Cloud les API. Configurez un niveau d'accès Chrome Enterprise Premium et une liaison visant à autoriser de manière sélective les attributs évalués lors de chaque requête API, y compris l'accès basé sur les adresses IP ou l'accès basé sur les certificats pour l'authentification TLS mutuelle. Les requêtes qui utilisent des identifiants d'autorisation compromis, mais qui ne répondent pas aux conditions définies dans votre règle Chrome Enterprise Premium, seront rejetées.

Chrome Enterprise Premium est un contrôle centré sur l'utilisateur qui rejette le trafic utilisateur des API qui ne répond pas aux conditions définies. VPC Service Controls est un contrôle centré sur les ressources qui définit les périmètres au sein desquels les ressources peuvent communiquer. VPC Service Controls s'applique à toutes les identités d'utilisateur et identités de compte de service ; en revanche, Chrome Enterprise Premium ne s'applique qu'aux identités d'utilisateur de votre organisation. Lorsqu'ils sont utilisés conjointement, Chrome Enterprise Premium et VPC Service Controls réduisent l'efficacité des identifiants compromis sur une machine contrôlée par un pirate informatique en dehors de votre environnement.

Appliquer la validation en deux étapes pour accéder au serveur distant

Si vous autorisez les développeurs à accéder aux ressources Compute Engine via SSH, configurez OS Login avec la validation en deux étapes. Cela consiste à définir un point de contrôle supplémentaire, selon lequel l'utilisateur doit s'authentifier de nouveau avec son mot de passe ou sa clé de sécurité. Un pirate informatique disposant de jetons OAuth compromis, mais d'aucun mot de passe ni clé de sécurité, va se retrouver bloqué par cette fonctionnalité.

L'accès RDP (Remote Desktop Protocol) aux instances Windows sur Compute Engine n'est pas compatible avec le service OS Login. Par conséquent, la validation en deux étapes ne peut pas être appliquée de manière précise pour les sessions RDP. Lorsque vous utilisez Identity-Aware Proxy (IAP) Desktop ou des plug-ins RDP pour Google Chrome, procédez comme suit :

Restreindre l'utilisation des clés de compte de service

Lorsque vous utilisez une clé de compte de service pour l'authentification, la valeur de la clé est stockée dans les fichiers de configuration de gcloud CLI, séparément du fichier de clé téléchargé. Un pirate informatique ayant accès à votre environnement peut copier la clé à partir de la configuration de gcloud CLI, ou copier le fichier de clé à partir de votre système de fichiers local ou de votre dépôt de code interne. Par conséquent, en plus de votre plan d'atténuation des jetons d'accès compromis, vous devez étudier la façon dont vous gérez les fichiers de clé de compte de service téléchargés.

Passez en revue des alternatives plus sécurisées pour l'authentification afin de réduire ou d'éliminer les cas d'utilisation qui dépendent d'une clé de compte de service. Appliquez également les constraints/iam.disableServiceAccountKeyCreation et constraints/iam.disableServiceAccountKeyUpload contraintes de règle d'administration pour désactiver la création de clés de compte de service.

Appliquer le principe du moindre privilège

Lorsque vous concevez des stratégies de Identity and Access Management (IAM), gardez en tête le principe du moindre privilège. N'accordez aux utilisateurs que les rôles dont ils ont besoin pour accomplir une tâche, en cherchant à limiter le plus possible leur champ d'action. Étudiez les recommandations concernant les rôles et mettez-les en application, pour éviter de définir dans votre environnement des stratégies IAM mêlant des rôles inutilisés, et des rôles offrant trop de possibilités.

Protéger vos points de terminaison

Déterminez comment un pirate informatique peut obtenir un accès physique ou distant à vos points de terminaison, tels que des postes de travail de développeur ou des instances Compute Engine. Bien qu'il soit important de définir un plan pour répondre à la menace de compromission des identifiants, réfléchissez également au risque de compromission de vos points de terminaison de confiance par un pirate informatique. Si celui-ci parvient à accéder à vos points de terminaison de confiance, il pourra exécuter des commandes gcloud CLI ou d'autres portions de code directement sur les points de terminaison.

Bien que la protection complète des postes de travail de développeur dépasse le cadre de ce document, évaluez la manière dont vos outils et opérations de sécurité peuvent vous aider à protéger et à surveiller vos points de terminaison. Posez-vous les questions suivantes :

  • Comment la sécurité physique des postes de travail de développeur est-elle assurée ?
  • Comment identifier et résoudre les violations de réseau ?
  • Comment les utilisateurs obtiennent-ils un accès à distance aux sessions SSH ou RDP ?
  • Comment des identifiants persistants, tels que les clés SSH ou les clés de compte de service, peuvent-ils être compromis ?
  • Certains workflows utilisent-ils des identifiants persistants et pourraient-ils être remplacés par des identifiants éphémères ?
  • Existe-t-il des appareils partagés sur lesquels un utilisateur pourrait consulter les identifiants gcloud CLI d'un autre utilisateur, mis en cache ?
  • Un utilisateur peut-il s'authentifier sur gcloud CLI à partir d'un appareil non vérifié ?
  • Comment le trafic approuvé se connecte-t-il aux ressources au sein de votre périmètre VPC Service Controls ?

Assurez-vous que vos opérations de sécurité apportent une réponse à chacune de ces questions.

Aligner vos équipes de réponse

Assurez-vous à l'avance que les équipes de sécurité responsables de la réponse aux incidents disposent d'un accès approprié sur la Google Cloud console et la console d'administration. Si des équipes distinctes gèrent la Google Cloud console et la console d'administration, vous risquez d'obtenir une réponse retardée lors d'un incident.

Pour évaluer une compromission et y répondre, consultez Répondre à une compromission d' Google Cloud identifiants.

Surveiller le piratage des identifiants

Tenez compte des points suivants pour surveiller les cas potentiels de piratage :

  • Recherchez les secrets dans vos dépôts de code à l'aide d'outils tels que la détection d'anomalies ou l'analyse des secrets.

  • Dans Cloud Audit Logs, configurez des alertes pour les éléments suivants :

    • Méthodes iamcredentials.googleapis.com (telles que GenerateAccessToken, GenerateIdToken, SignJwt) pour auditer la génération de jetons de compte de service

      Ces journaux nécessitent que vous activiez les journaux d'accès aux données.

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail pour auditer les emprunts d'identité d'utilisateur et de compte de service

    • Requêtes d'échange sts.googleapis.com pour les assertions d'identité anormales

  • Dans Security Command Center, surveillez les résultats de détection des menaces suivants à partir d'Event Threat Detection :

    • Persistance : Nouvelle géographie
    • Persistance : Nouvel agent utilisateur
    • Persistance : Nouvelle méthode d'API
    • Fuite : accès depuis le proxy d'anonymisation
    • Augmentation des privilèges : emprunt d'identité de compte de service anormal pour les activités d'administration
    • Augmentation des privilèges : emprunt d'identité anormal d'un compte de service pour les activités d'administration
    • Accès initial : une clé de compte de service divulguée a été utilisée
    • Persistance : une clé de compte de service a été créée
    • Accès initial : connexion suspecte bloquée
    • Accès initial : piratage - compte désactivé

    Pour chaque menace, étapes d'investigation recommandées sont fournies pour vous aider à répondre.

  • Surveillez les connexions des utilisateurs à Google Workspace et Cloud Identity. Pour mieux suivre les problèmes, envisagez d'exporter les journaux vers Cloud Logging.

  • Surveillez les journaux de Chrome Enterprise Premium et de VPC Service Controls pour détecter les tentatives d'accès hors périmètre avec des jetons volés.

  • Surveillez les anomalies dans l'utilisation des clés de compte de service à l'aide de Cloud Monitoring.

Assurez-vous que votre centre d'opérations de sécurité (SOC) est informé sans délai et dispose des playbooks, des outils et des accès nécessaires pour réagir rapidement en cas de suspicion de piratage d'identifiants. Vous pouvez également intégrer Security Command Center à votre solution SIEM existante ou importer des journaux dans Google Security Operations pour une analyse plus approfondie.

Étape suivante