Sécurité de l'API amazon Web Services - dummies

Voici une question évidente concernant les proxys tiers: Si ces outils agissent en votre nom, comment Amazon Web Services (AWS) sait-il que la personne au nom de laquelle ils agissent est en fait vous? En d'autres termes, comment AWS peut-il authentifier votre identité pour s'assurer que les commandes qu'elle reçoit viennent de vous?

En fait, la même question est valide même si vous interagissez directement avec l'API AWS. Comment AWS peut-il valider votre identité pour s'assurer qu'elle n'exécute des commandes que pour vous?

Une façon, bien sûr, est d'inclure le nom d'utilisateur et le mot de passe de votre compte dans les appels d'API. Bien que certains fournisseurs de cloud prennent cette approche, Amazon ne le fait pas.

Plutôt que de s'appuyer sur un nom d'utilisateur et un mot de passe, il s'appuie sur deux autres identifiants pour authentifier ses appels de service API: la clé d'accès et la clé d'accès secrète. Il utilise ces clés dans les appels de service pour implémenter la sécurité d'une manière beaucoup plus sûre que d'utiliser uniquement votre nom d'utilisateur et votre mot de passe.

Alors, comment ça marche? Lorsque vous vous inscrivez pour un compte avec AWS, vous avez la possibilité de créer une clé d'accès et de vous envoyer une clé d'accès secrète. Chacun est une longue chaîne de caractères aléatoires, et la clé d'accès secrète est la plus longue des deux. Lorsque vous téléchargez la clé d'accès secrète, vous devez la stocker dans un endroit très sécurisé, car c'est la clé (désolé - mauvais jeu de mots) pour mettre en œuvre des appels de service sécurisés.

Après cela, Amazon et vous avez une copie de la clé d'accès et de la clé d'accès secrète. Conserver une copie de la clé d'accès secrète est crucial car il est utilisé pour crypter les informations échangées entre vous et AWS, et si vous n'avez pas la clé d'accès secrète, vous ne pouvez exécuter aucun appel de service sur AWS.

La façon dont les deux touches sont utilisées est simple d'un point de vue conceptuel, bien que quelque peu difficile dans le détail.

Essentiellement, pour chaque appel de service que vous souhaitez effectuer, vous (ou un outil agissant en votre nom) procédez comme suit:

Créez la charge utile d'appel de service.

Voici les données que vous devez envoyer à AWS. Il peut s'agir d'un objet que vous souhaitez stocker dans S3 ou de l'identifiant d'image d'une image que vous souhaitez lancer. (Vous allez également attacher d'autres informations à la charge utile, mais comme elles varient en fonction des spécificités de l'appel de service, elles ne sont pas listées ici.) Une donnée est l'heure actuelle.
Chiffrer la charge utile en utilisant la clé d'accès secrète.

Cela garantit que personne ne peut examiner la charge utile et découvrir ce qu'il contient.
Signer numériquement la charge chiffrée en ajoutant la clé d'accès secrète à la charge chiffrée et en effectuant un processus de signature numérique à l'aide de la clé d'accès secrète.

Les touches d'accès secret sont plus longues et plus aléatoires que les mots de passe des utilisateurs classiques. la clé d'accès secrète longue rend le chiffrement effectué avec elle plus sûr qu'il ne le serait s'il était exécuté avec un mot de passe d'utilisateur typique.
Envoyez la charge utile chiffrée totale, avec votre clé d'accès, à AWS via un appel de service.

Amazon utilise la clé d'accès pour rechercher votre clé d'accès secrète, qu'elle utilise pour déchiffrer la charge utile. Si la charge utile déchiffrée représente un texte lisible pouvant être exécuté, AWS exécute l'appel de service. Sinon, il conclut que quelque chose ne va pas avec l'appel de service (peut-être qu'il a été appelé par un acteur malveillant) et n'exécute pas l'appel de service.

Outre le chiffrement qui vient d'être décrit, AWS utilise deux autres méthodes pour garantir la légitimité de l'appel de service:

La première repose sur les informations de date incluses dans la charge utile d'appel de service, qu'elle utilise pour déterminer si le temps associé à la réalisation de l'appel de service est approprié; si la date de l'appel de service est très différente de ce qu'elle devrait être (beaucoup plus tôt ou plus tard que l'heure actuelle, en d'autres termes), AWS conclut qu'il ne s'agit pas d'un appel de service légitime et le rejette.
La deuxième mesure de sécurité supplémentaire implique une somme de contrôle que vous calculez pour la charge utile. (A somme de contrôle est un nombre qui représente le contenu d'un message.) AWS calcule une somme de contrôle pour la charge utile; si sa somme de contrôle n'est pas d'accord avec la vôtre, elle refuse l'appel de service et ne l'exécute pas.

Cette approche de contrôle vérifie que personne ne falsifie le contenu d'un message et empêche un acteur malveillant d'intercepter un appel de service légitime et de le modifier pour effectuer une action inacceptable. Si quelqu'un bloque le message, lorsque AWS calcule une somme de contrôle, cette somme de contrôle ne correspond plus à celle incluse dans le message et AWS refuse d'exécuter l'appel de service.

Si, comme la plupart des utilisateurs AWS, vous utilisez une méthode proxy pour interagir avec AWS - la console de gestion AWS, une bibliothèque de langues ou un outil tiers - vous devez fournir votre clé d'accès et votre clé d'accès secrète au proxy. Lorsque le proxy exécute les appels de service AWS en votre nom, il inclut la clé d'accès dans l'appel et utilise la clé d'accès secrète pour effectuer le chiffrement des données utiles.

En raison du rôle critique que remplissent ces clés dans AWS, vous devez les partager seulement avec les entités de confiance. Si vous souhaitez essayer un nouvel outil tiers et que vous ne connaissez pas grand-chose à la société, configurez un compte de test AWS pour l'essai au lieu d'utiliser les informations d'identification de votre compte AWS de production.

Ainsi, si vous décidez de ne pas aller de l'avant avec l'outil, vous pouvez le supprimer, mettre fin au compte AWS de test et aller de l'avant, sans vous préoccuper des failles de sécurité potentielles dans vos principaux comptes de production. Bien sûr, vous pouvez toujours créer de nouvelles clés d'accès et clés d'accès secrètes, mais l'utilisation de vos clés de production pour les tests et la modification des clés crée beaucoup de travail, car vous devez mettre à jour chaque emplacement.

Si vous êtes comme beaucoup d'autres utilisateurs d'AWS, vous utiliserez un certain nombre d'outils et de bibliothèques, et revenir vers eux pour mettre à jour vos clés est très pénible. Il vaut mieux utiliser des comptes de non-production pour tester de nouveaux outils.