Jetons sans serveur dans le cloud : Exploitation et détection

Synthèse

Cet article présente les mécanismes et les implications en matière de sécurité de l’authentification serverless sur les principales plateformes cloud. Les attaquants ciblent les fonctions sans serveur dans l’espoir d’exploiter des vulnérabilités résultant de pratiques de codage non sécurisé de la part des développeurs ou d’une mauvaise configuration des fonctions cloud. L’exploitation réussie de ces vulnérabilités permet aux attaquants d’obtenir des matériels d’authentification qu’ils peuvent ensuite utiliser à mauvais escient.

Les fonctions informatiques sans serveur sont souvent associées à des identités cloud utilisant des jetons d’authentification pour obtenir un accès temporaire et limité aux services et ressources cloud. L’exfiltration de ces jetons peut exposer les environnements cloud à des risques de sécurité.

Amazon Web Services (AWS) Lambda, Azure Functions et Google Cloud Run Functions sont des exemples de plateformes et fonctions sans serveur qui reposent sur l’utilisation des matériels d’authentification. Ces informations comprennent la gestion des identités et des accès (IAM) dans AWS, les identités managées dans Azure et les jetons de compte de service dans Google Cloud Platform (GCP).

Comprendre le fonctionnement de ces services nous permet de mettre en œuvre des stratégies efficaces pour éviter l’exposition des jetons et détecter leur utilisation abusive, pouvant conduire à la compromission d’environnements cloud. Ces compromissions impliquent une élévation de privilèges, une persistance malveillante dans l’environnement ou l’exfiltration d’informations sensibles dont l’accès est réservé aux identités légitimes.

Les clients de Palo Alto Networks bénéficient d’une meilleure protection contre les menaces évoquées dans cet article grâce à notre gamme de produits Cortex. Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse aux incidents.

Introduction

Le serverless est un modèle cloud où des fournisseurs comme AWS (Lambda), Azure (Functions) et Google Cloud (Functions) gèrent l’infrastructure, la mise à l’échelle et la maintenance. Ce modèle permet aux organisations et à leurs développeurs de se concentrer uniquement sur le code, tandis que le fournisseur de services cloud s’occupe des tâches en arrière-plan.

Fonctionnant sur une base événementielle, les fonctions serverless s’exécutent en réponse à des déclencheurs tels que des requêtes HTTP, des modifications de bases de données ou des événements programmés. La mise à l’échelle automatisée du service fonctionnel permet d’ajuster les ressources à la demande, ce qui garantit un bon rapport coût-efficacité, le fournisseur de services cloud facturant uniquement le temps d’exécution et les ressources utilisées.

Bien que le serverless simplifie le développement et le déploiement, il est important de comprendre les risques potentiels associés à ces services. Certains de ces risques découlent du fait que les développeurs peuvent attribuer des identités aux fonctions serverless, et que ces identités se manifestent sous la forme d’ensembles de matériels d’authentification accessibles au code s’exécutant dans la fonction. Ces matériels d’authentification sont utilisés pour authentifier et autoriser l’exécution d’opérations dans le cloud.

Ces matériels d’authentification sont appliqués avec un ensemble d’autorisations qui dictent leur utilisation. En fonction des autorisations associées à l’identité attachée à la fonction, ces matériels d’authentification peuvent permettre l’accès à des ressources cloud et à des données sensibles.

Les fonctions serverless sont des cibles attractives pour les attaquants pour plusieurs raisons :

• Les fonctions serverless peuvent être vulnérables aux attaques par exécution de code à distance (RCE) ou falsification de requête côté serveur (SSRF) en raison de pratiques de développement non sécurisées
• Elles sont souvent exposées publiquement (par conception ou en raison d’une mauvaise configuration) ou traitent des entrées provenant de sources externes
• Les attaquants peuvent exploiter les jetons serverless pour obtenir un accès non autorisé en lecture/écriture, ce qui peut mettre en danger les infrastructures critiques et les données sensibles

Lorsqu’on utilise des fonctions serverless, il est important de prendre en compte les risques encourus lorsque les développeurs d’applications déploient du code non sécurisé dans les fonctions cloud, et de bien comprendre les menaces qui ciblent ces fonctions.

Comment fonctionne l’authentification serverless sur les principales plateformes Cloud

Avec l’approche serverless, les applications sont déployées en exécutant des fonctions à la demande. Le principal avantage de cette approche est que les applications ou les composants spécifiques peuvent être exécutés en fonction des besoins, ce qui élimine la nécessité d’un environnement d’exécution continu.

Chacun des principaux fournisseurs de cloud partage des concepts similaires pour les fonctions serverless, par exemple :

• La prise en charge de plusieurs langages de programmation
• L’absence d’accès SSH en raison de leur architecture entièrement managée
• L’utilisation de rôles, de comptes de service ou d’identités managées pour contrôler de manière sécurisée l’accès aux ressources

AWS Lambda

Le service IAM d’AWS permet de créer et de gérer des utilisateurs, des autorisations, des groupes et des rôles. Ce service est responsable de la gestion des identités et de leur niveau d’accès aux comptes et services AWS, ainsi que du contrôle de diverses fonctionnalités au sein d’un compte AWS.

Les fonctions serverless utilisent des rôles Lambda, qui n’ont pas d’autorisations par défaut ; des politiques IAM doivent être utilisées pour gérer les autorisations et sécuriser l’accès à d’autres services AWS.

Pour simplifier la gestion des autorisations, AWS propose des politiques gérées (comme AWSLambdaBasicExecutionRole) que les développeurs associent souvent à ces rôles pour activer rapidement des fonctionnalités de base.

Lorsqu’un rôle IAM est associé à une fonction Lambda, le service AWS Security Token Service (STS) génère automatiquement des identifiants de sécurité temporaires pour ce rôle.

Il s’agit d’un moyen sûr d’accéder aux matériels d’authentification au moment de l’exécution, sans les risques associés aux matériels d’authentification codés en dur à long terme.

Ces matériels d’authentification sont limités aux autorisations définies dans la politique d’accès associée au rôle. Il s’agit d’un identifiant de clé d’accès, d’une clé d’accès secrète et d’un jeton de session.

Au moment de l’exécution, le service d’exécution Lambda charge les matériels d’authentification du rôle dans l’environnement d’exécution de la fonction et les stocke en tant que variables d’environnement, telles que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_SESSION_TOKEN. Ces variables sont accessibles au code de la fonction pendant l’exécution, ce qui permet à la fonction d’interagir en toute sécurité avec d’autres services AWS.

Google Cloud Functions

Google Cloud Functions utilise des jetons de compte de service pour authentifier et autoriser l’accès à d’autres services Google Cloud. Un compte de service est un compte Google spécialisé lié à un projet et représente une identité non humaine, plutôt qu’un utilisateur individuel.

Lors du déploiement d’une fonction cloud, les développeurs peuvent l’associer à un compte de service personnalisé ou au compte de service par défaut. Lorsqu’ils utilisent un compte de service personnalisé, les développeurs peuvent attribuer des rôles IAM spécifiques afin de définir les autorisations exactes dont la fonction a besoin pour accomplir ses tâches.

Les comptes de service par défaut sont des comptes gérés par l’utilisateur que Google Cloud crée automatiquement lorsque les utilisateurs activent des services spécifiques. Par défaut, Google Cloud Functions utilise différents comptes de service en fonction de la génération :

• Les fonctions Cloud Run de première génération utilisent le compte de service par défaut d’App Engine (<project_id>@appspot.gserviceaccount.com ).
• Les fonctions Cloud Run de deuxième génération utilisent le compte de service Compute par défaut (<numéro_de_projet>-compute@developer.gserviceaccount.com).

Ces comptes de service par défaut disposent souvent d’autorisations d’éditeur lorsque les développeurs utilisent GCP sans rattachement organisationnel, ce qui leur permet de créer, de modifier et de supprimer des ressources au sein du projet. Toutefois, dans les projets relevant d’une organisation GCP, les comptes de service par défaut sont créés sans aucune autorisation. Dans ce cas, ils ne peuvent effectuer que les actions explicitement autorisées par les rôles qui leur sont attribués.

Bien qu’une fonction GCP fonctionne dans un environnement serverless, lorsqu’il s’agit d’accéder aux matériels d’authentification associés à la fonction, elle se comporte de la même manière qu’un serveur traditionnel, tel qu’une instance de machine virtuelle (VM), en récupérant ses jetons de compte de service à partir du serveur de métadonnées d’instance (IMDS) au moment de l’exécution. L’IMDS à l’adresse hxxp://metadata.google[.]internal/ fournit des jetons d’accès de courte durée pour le compte de service associé à la fonction. Ces jetons permettent à la fonction de s’authentifier auprès des services GCP.

Azure Functions

Les identités gérées par Azure permettent aux ressources Azure de s’authentifier et d’interagir avec d’autres services Azure de manière sécurisée et transparente, sans qu’il soit nécessaire de coder des matériels d’authentification en dur. À l’instar des services fonctionnels d’AWS et de GCP, ces identités éliminent les risques liés à la gestion des matériels d’authentification dans le code.

Les identités managées attribuées par le système sont liées à une ressource unique et sont automatiquement supprimées lors de la suppression de la ressource. D’autre part, les identités managées attribuées par l’utilisateur sont des ressources indépendantes qui peuvent être attribuées à plusieurs services, ce qui offre une plus grande souplesse pour les scénarios d’authentification partagée.

Une fonction Azure à laquelle est associée une identité managée doit utiliser son jeton d’identité managée pour s’authentifier auprès d’une ressource Azure. Ci-dessous la procédure d’authentification détaillée:

• La fonction interroge ses variables d’environnement pour récupérer les valeurs de IDENTITY_ENDPOINT et IDENTITY_HEADER.
  • IDENTITY_ENDPOINT : Une variable d’environnement qui contient l’adresse du terminal local de l’identité managée fourni par Azure. Il s’agit d’une URL locale à partir de laquelle une application peut demander des jetons.
  • IDENTITY_HEADER : Paramètre obligatoire lors de l’interrogation du terminal local de l’identité managée. Cet en-tête est utilisé pour atténuer les attaques SSRF.
• La fonction envoie une requête HTTP GET au terminal local de l’identité managée avec l’en-tête IDENTITY_HEADER inclus dans l’en-tête HTTP. (Pour plus de détails sur la structure de la demande, voir la documentation d’Azure sur l’acquisition de jetons pour les App Services)
• Microsoft Entra ID (anciennement Azure Active Directory) vérifie l’identité de la fonction et émet un jeton OAuth 2.0 temporaire qui est limité spécifiquement à la ressource cible.
• La fonction inclut le jeton émis dans sa demande à la ressource Azure (par exemple, Azure Key Vault, compte de stockage).
• La ressource Azure valide le jeton et vérifie les autorisations de la fonction à l’aide du contrôle d’accès basé sur les rôles ou des politiques d’accès spécifiques aux ressources.

Si elle est autorisée, la ressource accorde l’accès pour effectuer l’opération demandée. Cela garantit une authentification sûre et transparente sans qu’il soit nécessaire d’utiliser des secrets codés en dur dans le code.

Vecteurs d’attaque pour l’exfiltration de jetons

Cette section aborde les risques et les menaces liés à l’utilisation de fonctions serverless. Lorsqu’ils développent et configurent des fonctions, les développeurs d’applications doivent veiller à sécuriser ces fonctions contre des attaques telles que SSRF et RCE. En l’absence d’une telle sécurité, les attaquants pourraient manipuler les fonctions serverless qui sont vulnérables au SSRF, ce qui amènerait les fonctions à envoyer des requêtes non autorisées aux services internes. Cela peut conduire à un accès involontaire ou à l’exposition d’informations sensibles au sein du système, telles que les jetons d’accès, le contenu de la base de données interne ou les configurations de service. Il est important de souligner que ces risques surviennent principalement lorsque les fonctions sont publiques ou qu’elles traitent des données provenant d’utilisateurs externes et d’autres sources.

Dans les attaques SSRF, un attaquant trompe un serveur (comme une fonction serverless) en effectuant des requêtes HTTP vers des ressources internes ou externes auxquelles l’attaquant ne devrait pas avoir accès. Comme c’est le serveur lui-même qui fait la demande, il peut accéder à des services internes qui ne sont pas exposés à Internet. Une fonction serverlessr vulnérable prend une URL en entrée et récupère les données à partir de celle-ci.

Dans GCP, SSRF peut être utilisé pour accéder à l’IMDS à l’adresse hxxp://metadata.google[.]internal/, en extrayant des jetons temporaires de compte de service. Un attaquant peut alors utiliser ces jetons pour se faire passer pour la fonction et effectuer des actions non autorisées dans le cadre des autorisations de son rôle IAM. Les vulnérabilités liées à l’exécution de code à distance permettent aux attaquants d’exécuter du code arbitraire dans l’environnement d’une fonction.

Pour AWS Lambda, les attaques RCE pourraient exposer des matériels d’authentification temporaires stockées dans des variables d’environnement, telles que AWS_ACCESS_KEY_ID et AWS_SESSION_TOKEN.

Il est essentiel de noter que ces vecteurs d’attaque ne sont pas des failles inhérentes aux plateformes cloud elles-mêmes, mais découlent plutôt d’un développement non sécurisé rédigé par les développeurs d’applications qui pourrait introduire des vulnérabilités, telles que SSRF ou RCE. Les développeurs d’applications peuvent atténuer ces risques en mettant en œuvre des pratiques de développement sécurisé telles que la validation des entrées.

Simulations de vecteurs d’attaque

Les simulations suivantes montrent comment les attaquants pourraient extraire les jetons serverless et les utiliser pour des activités malveillantes dans différents fournisseurs de services cloud (CSP). Ces attaques pourraient tirer parti d’un code de fonction non sécurisé déployé par les développeurs d’applications.

Simulation 1 : Accès direct à l’IMDS à partir d’une fonction BPC

Pour réaliser cette simulation, nous avons déployé deux fonctions Google Cloud Run qui accèdent au service de métadonnées des fonctions et extraient les jetons des deux différents comptes de service associés à partir du chemin suivant :

• hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token

Le premier exemple illustre l’extraction d’un compte de service par défaut. Le deuxième exemple illustre l’extraction d’un compte de service personnalisé. Ces exemples montrent comment le code peut accéder directement au service de métadonnées, tout comme une application vulnérable à une attaque SSRF pourrait également y accéder.

Exemple 1 : Extraction d’un compte de service par défaut dans GCP

Comme le montre la figure 1, le compte de service associé à la fonction était le compte de service serverless par défaut. La figure 2 montre que le jeton d’accès renvoyé appartient au même compte de service.

Exemple 2 : Extraction d’un compte de service personnalisé dans GCP

La figure 3 montre le compte de service personnalisé que nous avons associé à la fonction. La figure 4 montre le jeton d’accès renvoyé appartenant au compte de service personnalisé. Nous avons ensuite utilisé le jeton renvoyé pour effectuer des opérations dans l’environnement.

La figure 5 ci-dessous montre un exemple de commande permettant de lister les buckets.

Si des attaquants peuvent répertorier et lire le contenu des buckets dans GCP, ils peuvent accéder à des fichiers sensibles tels que des matériels d’authentification, des sauvegardes ou des configurations internes. Cela leur permet de voler des données, de compromettre le système ou de se déplacer latéralement au sein de l’environnement.

Une fois que les attaquants obtiennent un jeton d’accès pour un compte de service avec des autorisations d’éditeur dans GCP (comme le compte de service Compute Engine par défaut), ils peuvent modifier, supprimer ou créer des ressources dans la plupart des services. Il peut s’agir d’accéder à des données sensibles, de déployer des workloads malveillants, d’escalader des privilèges ou de perturber des services. L’accès de l’éditeur permet un contrôle quasi total du projet.

Simulation 2 : Utilisation de RCE pour récupérer les jetons stockés dans les variables d’environnement de la fonction AWS Lambda

Dans cette simulation, nous avons accédé aux variables d’environnement de la fonction Lambda et en avons extrait l’AWS_ACCESS_KEY_ID, l’AWS_SECRET_ACCESS_KEY et l’AWS_SESSION_TOKEN.

La figure 6 montre la sortie du code de la fonction Lambda.

La figure 7 montre la configuration des identifiants AWS temporaires obtenus à l’étape précédente (les variables d’environnement Lambda).

Nous avons ensuite utilisé la commande suivante pour dresser la liste de tous les buckets S3 auxquels la session authentifiée peut accéder.

Simulation 3 : Utilisation de RCE pour récupérer des jetons à partir d’un terminal d’identité local d’une fonction Azure

Dans cette simulation, nous avons accédé aux variables d’environnement de la fonction Azure et extrait l’IDENTITY_ENDPOINT et l’IDENTITY_HEADER en exécutant des commandes à distance. Nous avons ensuite extrait le jeton d’identité managée via le terminal d’identité local, en fournissant les paramètres indiqués ci-dessous dans la figure 8 :

• Ressource
• version de l’API
• X-IDENTITY-HEADER

Détection et prévention de l’exfiltration de jetons

Détection de l’exfiltration de jetons dans les environnements sans serveur

Des mécanismes de détection efficaces sont essentiels pour identifier l’exfiltration de jetons dans les environnements sans serveur. Ces mécanismes se concentrent sur les anomalies de comportement pour signaler les activités non autorisées. Voici quelques-unes des principales stratégies de détection mises en œuvre sur les principales plateformes cloud.

La détection se fait en deux étapes :

• Valider que l’identité est associée à une fonction serverless.
• Identifier les comportements anormaux des identités sans serveur. Ces comportements peuvent inclure :
  • Les adresses IP source qui ne correspondent pas au contexte dans lequel la fonction est exécutée, telles que les adresses provenant de numéros de systèmes autonomes (ASN) qui ne sont pas associés à un fournisseur de services cloud.
  • Les identités serverless effectuant des requêtes avec des user-agents suspects.

Étape 1 : Identifier les identités serverless

Pour identifier les comptes de service associés aux fonctions sans serveur dans GCP, nous analysons la section serviceAccountDelegationInfo dans les journaux. Ces informations fournissent des indications cruciales sur la chaîne de délégation des comptes de service. Plus précisément, lorsqu’un compte de service est associé à une fonction, il délègue son autorité à un compte de service sans serveur par défaut :

• Google Cloud Run Service Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com)
• gcf-admin-robot.iam.gserviceaccount[.]com (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com)

Ces comptes de service exécutent des tâches au nom de la fonction.

Par exemple, dans l’entrée de journal de la figure 9, nous voyons le compte de service personnalisé associé à une fonction (sa-test@<project-id>.iam.gserviceaccount[.]com) déléguer son autorité à l’agent de service Cloud Run.

Dans la figure 9 ci-dessus, le champ principalEmail sous authenticationInfo spécifie le compte de service utilisé (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com).

Le serviceAccountDelegationInfo indique le principal de première partie (dans ce cas : service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com), ce qui indique que le compte de service fonctionne dans un environnement sans serveur comme Cloud Functions ou Cloud Run.

Une approche efficace pour découvrir les identités serverless consiste à établir le profil des comptes de service qui ont précédemment délégué leur autorité à des comptes de service sans serveur par défaut. Cela garantit que même si des comptes de service autres que ceux par défaut sont associés à des fonctions, ils sont identifiés.

Dans AWS, les fonctions Lambda s’appuient sur les rôles IAM pour sécuriser l’accès aux services AWS. Ces rôles génèrent des matériels d’authentification temporaires. Nous pouvons identifier l’identité Lambda par son nom de rôle.

Dans Azure, les identités managées associées aux Azure Function Apps sont utilisées pour l’authentification.

Étape 2 : Identifier les comportements inhabituels pour les identités serverless

Dans un environnement cloud sécurisé, les fonctions serverless sont généralement destinées à exécuter des tâches automatisées et circonscrites, telles que la réponse à des requêtes API ou le traitement d’événements. Ces fonctions ne doivent pas être utilisées de manière interactive. Cependant, si des attaquants obtiennent l’accès à l’environnement d’une fonction sans serveur ou à son identité, ils peuvent l’utiliser à mauvais escient pour exécuter des commandes d’interface de ligne de commande (CLI) (par exemple, gcloud CLI ou curl) afin d’interagir directement avec les ressources du cloud.

Une méthode de détection consiste à examiner le user-agent des appels API. Si l’agent utilisateur correspond à des outils CLI connus (par exemple, gcloud CLI) ou à des cadres de test d’intrusion, il est signalé comme suspect, car les CLI ne devraient généralement pas être utilisées par les identités serverless. Cela indique une exploitation potentielle de l’environnement ou des jetons de compte de service.

À noter que cette méthode d’identification de l’utilisation à distance des jetons sans serveur en fonction de l’agent utilisateur ne peut pas être réalisée dans Azure, car les informations relatives au user-agent n’apparaissent pas dans les journaux Azure.

Une autre approche pour détecter l’utilisation à distance d’un jeton d’identité sans serveur consiste à corréler l’emplacement de l’utilisation d’un jeton avec des plages ASN d’adresses IP de fournisseurs de cloud connus. Si une demande provient d’une adresse IP externe non associée au CSP, une alerte est déclenchée, mettant en évidence une éventuelle utilisation non autorisée du jeton en dehors de l’environnement cloud.

Stratégies de prévention

La sécurisation des jetons serverless nécessite une combinaison de mesures proactives, de gestion de la posture et de pratiques de sécurité de surveillance de l’exécution pour minimiser le risque d’exploitation. Tout d’abord, mettez en œuvre le principe du moindre privilège en attribuant des rôles avec les autorisations minimales requises pour les fonctions sans serveur. Cela réduit l’impact potentiel d’une mauvaise utilisation des jetons.

En outre, pour protéger les environnements d’exécution sans serveur dans GCP et Azure, restreignez l’accès à l’IMDS en configurant des contrôles au niveau du réseau et en appliquant des mécanismes de validation des demandes. Assurer une validation robuste des entrées pour empêcher les attaquants d’utiliser des techniques d’exploitation comme le SSRF pour accéder aux métadonnées sensibles, aux jetons et à d’autres ressources cloud comme les API et les bases de données.

Conclusion

L’informatique serverless est le choix privilégié pour le développement d’applications modernes, car elle offre des avantages significatifs en termes d’évolutivité, de rentabilité et de gestion simplifiée de l’infrastructure.

Les matériels d'authentification permettant à ces fonctions d’interagir avec les services cloud constituent un élément de sécurité essentiel et une cible de choix pour les attaquants. La compromission de ces matériels d’authentification peut avoir de graves conséquences, notamment l’accès non autorisé à des ressources cloud et l’exfiltration de données.

La mise en œuvre d’une gestion proactive de la posture et de protections de surveillance de l’exécution est une stratégie cruciale pour la protection des environnements cloud.

Les organisations peuvent mieux protéger leurs environnements sans serveur en :

• Comprenant les mécanismes des références serverless et les meilleures pratiques pour les provisionner et les gérer dans AWS, Azure et GCP
• Reconnaissant les vecteurs d’attaque courants tels que l’exfiltration de jetons via l’exploitation de l’IMDS ou l’accès aux variables d’environnement

Protection et mitigation des risques par Palo Alto Networks

Les clients de Palo Alto Networks sont mieux protégés contre les menaces mentionnées ci-dessus grâce aux produits suivants :

Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse aux incidents ou composez l’un des numéros suivants :

• Amérique du Nord Par téléphone : 866.486.4842 (866.4.UNIT42)
• EMEA : +31 20 299 3130
• APAC : +65 6983 8730
• Japon : +81 50 1790 0200

Palo Alto Networks a partagé ces conclusions avec les autres membres de la Cyber Threat Alliance (CTA). Les membres de la CTA s’appuient sur ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et perturber de manière coordonnée les activités des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.

Pour aller plus loin

• Utilisation des variables d’environnement Lambda - Guide du développeur AWS Lambda
• Sécurisation de variables d’environnement Lambda - Guide du développeur AWS Lambda
• Gestion des autorisations dans AWS Lambda - Guide du développeur AWS Lambda
• Identité de fonction - Google Cloud
• Que sont les identités managées pour les ressources Azure ? - Microsoft Learn
• Sécurisation d’Azure Functions - Microsoft Learn
• Qu’est-ce que c’est, AWS Secrets Manager ? - Guide de l’utilisateur AWS Secret Manager
• Concepts de base d’Azure Key Vault - Microsoft Learn
• Présentation de Secret Manager - Documentation de Google Cloud Secret Manager
• Qu’est-ce que la gestion des identités et des accès (IAM) ? - Microsoft Security
• Que sont les identités managées pour les ressources Azure ? - Microsoft Learn
• Contrôle des identités et des accès - Introduction à la sécurité AWS - Livre blanc AWS
• Identifiants du compte de service - Documentation Google Cloud IAM
• Identifiants de sécurité temporaires dans IAM - Guide de l’utilisateur de AWS Identity et Access Management
• Référence API du service de jetons de sécurité AWS - Documentation du service de jetons de sécurité AWS
• Instances Compute Engine - Documentation Google Cloud
• Projets Google Cloud - Documentation Google Cloud
• Comptes de service gérés par l’utilisateur - Documentation Google Cloud
• Comparer les fonctions Cloud Run - Documentation Google Cloud Run
• Comptes de service par défaut - Documentation Google Cloud
• Référence du terminal REST - Identités managées pour App Service et Azure Functions
• Variables d’environnement et paramètres d’application dans Azure App Service - Microsoft Learn
• Guide pratique de l’utilisation d’identités managées pour ressources Azure sur une machine virtuelle Azure afin d’acquérir un jeton d’accès - Microsoft Learn
• Qu’est-ce que l’identifiant Microsoft Entra ? - Microsoft Learn
• À propos d’Azure Key Vault - Microsoft Learn
• Autoriser l’accès aux objets blobs à l’aide de l’identifiant Microsoft Entra - Microsoft Learn
• Présentation du compte de stockage - Microsoft Learn
• Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (RBAC Azure) ? - Microsoft Learn
• Politiques d’accès spécifiques aux ressources - Microsoft Learn