Jeton de sécurité aws x amz

Publié le · aws, oauth, iam

Contrairement à Google Cloud et Azure, AWS n’utilise pas OAuth 2 et les jetons d’accès pour permettre aux clients de s’authentifier auprès de leur API. Au lieu de cela, AWS s’attend à ce que les clients calculent une signature pour chaque demande et transmettent la signature dans l’en-tête.

Pour calculer une signature, les clients créent d’abord une version canonisée de la demande, y compris ses paramètres, ses en-têtes et son corps. Ensuite, ils prennent cette demande, ajoutent quelques bits supplémentaires comme l’heure, et créent un code d’authentification de message (MAC) pour celle-ci à l’aide de la fonction HMAC-SHA256 en combinaison avec la clé d’accès secrète de l’utilisateur. Les détails sont un peu plus compliqués et décrits en détail dans la documentation AWS, mais c’est l’idée de base.

Par rapport à l’utilisation de jetons d’accès OAuth 2, la méthode AWS présente certains avantages :

• La signature de la demande prouve non seulement l’authenticité de la demande, mais aussi son intégrité . Si un attaquant intercepte et modifie une requête, la signature ne correspond plus à la requête et l’API rejette la requête.

  En revanche, les jetons d’accès prouvent l’authenticité des requêtes, mais pas leur intégrité . Si un attaquant intercepte et falsifie une demande, le jeton d’accès reste valide.

• Parce que la signature inclut l’heure, les requêtes ne peuvent pas être rejouées... ou du moins, il devient un peu plus difficile de les rejouer : pour tenir compte du décalage de l’horloge, les horodatages sont autorisés à être décalés de quelques minutes, et dans cette fenêtre de temps, il est possible de rejouer les requêtes. Néanmoins, la fenêtre de temps est plus courte que la validité habituelle des jetons d’accès.

Mais il y a aussi quelques inconvénients :

• Le calcul d’une signature n’est pas trivial. Nous n’avons pas seulement besoin d’une bibliothèque de crypto-monnaies qui prend en charge HMAC-SHA256, mais il y a aussi une bonne dose de logique impliquée pour canoniser une requête et générer la signature. En pratique, cela signifie généralement que nous devons utiliser l’une des bibliothèques AWS pour effectuer des requêtes d’API.

  L’ajout d’un en-tête à une requête HTTP est trivial en comparaison et cela nous permet de faire des requêtes ad-hoc à Azure et à l’API Google Cloud.

• Il n’y a pas de moyen simple de laisser un tiers effectuer une action en notre nom : lorsque nous utilisons des jetons d’accès OAuth, nous pouvons passer notre jeton d’accès au tiers, et le tiers peut utiliser le jeton pour effectuer des appels d’API en notre nom. Avec des demandes signées, ce n’est pas possible à moins de passer notre clé d’accès secrète à un tiers, ce qui serait une mauvaise idée.

• Seuls le client et AWS peuvent valider une demande, car seules ces deux parties connaissent la clé d’accès secrète. Par conséquent, il est également difficile d’utiliser les informations d’identification AWS pour prouver notre identité à un tiers : nous pouvons envoyer une demande signée au tiers, mais celui-ci ne peut pas valider la signature.

L’utilisation d’informations d’identification AWS pour prouver notre identité à un tiers est essentielle si nous voulons effectuer tout type d’échange d’informations d’identification, par exemple pour accéder aux API Vault ou Google Cloud.

Vault et Google Cloud nous permettent tous deux d’effectuer un échange d’informations d’identification, mais la façon dont ils le font est un peu un mauvais tour : ils nous demandent de les laisser être l’homme du milieu pour une demande GetCallerIdentity.

Pour la fédération d’identité de charge de travail, le processus est le suivant :

1. Le client crée un document JSON qui contient les informations qu’il aurait normalement inclure dans une demande adressée au point de terminaison AWS GetCallerIdentity, y compris une signature de demande valide. La fédération d’identités de charge de travail fait référence à ce document JSON sous le nom de jeton GetCallerIdentity .

2. Le client envoie le jeton GetCallerIdentity à la fédération d’identités de charge de travail.

3. La fédération d’identité de charge de travail utilise les informations du jeton GetCallerIdentity pour effectuer une requête GetCallerIdentity sur l’API AWS.

   Si la demande réussit, la fédération d’identité de charge de travail sait que la signature de la demande dans le jeton GetCallerIdentity doit avoir été valide, ce qui implique que nos informations d’identification AWS doivent également avoir été valides.

   À partir de la réponse, la fédération d’identité de charge de travail apprend également qui nous sommes, c’est-à-dire tout ce qu’elle a besoin de savoir pour effectuer un échange d’informations d’identification.

Super, mais comment créer une demande signée, sans l’envoyer réellement au point de terminaison AWS ? Ou plus précisément, comment générer les bons en-têtes pour une requête ? Après tout, ce n’est pas exactement ce pour quoi les bibliothèques clientes AWS sont conçues...

Créer une signature en Python

En Python, signer une requête sans l’exécuter est étonnamment facile grâce à la fonction, qui nous permet de signer un objet :

Le dictionnaire résultant contient les en-têtes que nous recherchons, à savoir et . Si nous avons utilisé des informations d’identification AWS temporaires, le dictionnaire contient également l’en-tête supplémentaire.

Création de signature en C#

En C#, les choses sont un peu plus difficiles : L’AWSSDK. Le package de base contient un ensemble complet de classes d’utilitaires liées à l’authentification, y compris la classe AWS4Signer (non documentée). Cette classe nous permet de signer une requête, mais nous devons passer un objet, ce qui est difficile à synthétiser.

Heureusement, n’est pas , donc nous peut dériver une classe qui offre un moyen plus pratique de créer des en-têtes signés tout en réutilisant la logique existante de :

Maintenant, tout ce que nous avons à faire est d’introduire le bon ensemble de paramètres pour obtenir l’ensemble des en-têtes signés en retour. Par exemple :

c’est un peu plus de code que ce dont nous avons besoin en Python, mais le résultat final est le même : contient les en-têtes de requête que nous recherchons, à savoir et . Si nous avons utilisé des informations d’identification AWS temporaires, le dictionnaire contient également l’en-tête supplémentaire.

Évaluez cette page– Merci pour vos commentaires !

Toutes les opinions exprimées sur ce blog sont celles de Johannes. Reportez-vous à la documentation du produit du fournisseur respectif pour obtenir des informations faisant autorité.

« Retour à l’accueil