Amazon sécurité des services Web de l'API

Voici une question évidente lorsqu'ils traitent avec les procurations tiers: Si ces outils agissent en votre nom, Comment Amazon Web Services (AWS) savent que la personne au nom de laquelle ils agissent est en fait tu? En d'autres termes, comment peut-AWS authentifier votre identité pour garantir que les commandes qu'il reçoit sont de vous?

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

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

Plutôt que de compter sur un nom d'utilisateur et mot de passe, il repose sur deux autres identifiants pour authentifier ses appels de service de l'API: la clé d'accès et la clé d'accès secret. Il utilise ces touches dans les appels de service à mettre en œuvre la sécurité d'une manière qui est beaucoup plus sûr que d'utiliser uniquement votre nom d'utilisateur et 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 d'avoir une clé d'accès secret envoyé à vous. Chacun d'eux est une longue chaîne de caractères aléatoires, et la clé d'accès secret est le plus long des deux. Lorsque vous téléchargez la clé d'accès secret, vous devriez stocker quelque part très sécurisé car il est la clé (désolé - mauvais jeu de mots) à la mise en œuvre des appels de service sécurisées.

Après vous faites cela, vous et Amazon avez une copie de la clé d'accès et la clé d'accès secret. Conserver une copie de la clé d'accès secret est crucial car il est utilisé pour chiffrer les informations envoyées avant et en arrière entre vous et AWS, et si vous ne disposez pas de la clé d'accès secrète, vous ne pouvez pas exécuter des appels de service sur AWS.

La façon dont les deux clés sont utilisées est conceptuellement simple, bien que quelque peu difficile en détail.

Essentiellement, pour chaque appel de service que vous souhaitez effectuer, vous (ou un outil fonctionnant sur votre nom) faire ce qui suit:

1. 
   
   
   
   

   Créer l'appel de service la charge utile.

   Ce sont les données que vous devez envoyer à AWS. Il peut être un objet que vous souhaitez stocker dans S3 ou l'identifiant d'image d'une image que vous voulez lancer. (Vous aurez également connecter d'autres éléments d'information à la charge utile, mais parce qu'ils varient selon les spécificités de l'appel de service, ils ne sont pas énumérés ici. Un morceau de données est l'heure actuelle.)

2. Chiffrer la charge utile en utilisant la clé d'accès secret.

   Cela assure que personne ne peut examiner la charge utile et de découvrir ce qu'il ya dedans.

3. Signer numériquement la charge utile chiffrée en ajoutant la clé d'accès secret à la charge utile chiffrée et exécuter un processus de signature numérique en utilisant la clé d'accès secret.

   Touches d'accès secrets sont plus longs et plus aléatoire que l'utilisateur typique passwords- la clé secrète longue d'accès rend le chiffrement exécuté avec elle plus sûre que ce serait si elle était réalisée avec un mot de passe de l'utilisateur typique.

4. Envoyer la charge utile totale crypté, avec votre clé d'accès, à AWS via un appel de service.

   Amazon utilise la clé d'accès pour consulter votre clé d'accès secrète, qui l'utilise pour décrypter la charge utile. Si la charge utile déchiffré représente texte lisible qui peut ê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 ne pas exécuter l'appel de service.

En plus du cryptage vient d'être décrit, AWS dispose de deux autres méthodes utilisées pour assurer la légitimité de l'appel de service:

• Le premier est basé sur les informations de date inclus dans la charge utile d'appel de service, qui l'utilise pour déterminer si le temps associé à la décision de l'appel de service est appropriate- 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 n'y a pas un appel de service légitime et la défausse.

• La seconde mesure de sécurité supplémentaire implique une somme de contrôle pour calculer la charge utile. (UN checksum est un nombre qui représente le contenu d'un message.) AWS calcule une somme de contrôle pour la payload- si son contrôle ne sont pas d'accord avec le vôtre, il rejette l'appel de service et ne l'exécute pas.

  Cette approche de contrôle veille à ce que personne ne falsifie le contenu d'un message et empêche un acteur malveillante d'intercepter un appel de service légitime et changer pour effectuer une action inacceptable. Si quelqu'un altère le message, lorsque AWS calcule une somme de contrôle, ce checksum ne correspond plus à celui inclus dans le message, et AWS refuse d'exécuter l'appel de service.

Si, comme la plupart des utilisateurs d'AWS, vous utilisez une méthode de remplacement pour interagir avec AWS - la console de gestion AWS, une bibliothèque de langue, ou d'un outil tiers - vous devez fournir votre clé d'accès et la clé d'accès secret à la procuration. Lorsque le proxy exécute les appels de service AWS en votre nom, il comprend la clé d'accès à l'appel et utilisez la touche d'accès secret à effectuer le chiffrement de la charge utile.

En raison du rôle essentiel que ces touches remplissent en AWS, vous devriez les partager seulement avec les entités qui vous avez confiance. Si vous voulez essayer un nouvel outil tiers et vous ne savez pas beaucoup sur la société, mettre en place un compte de test AWS pour le procès au lieu d'utiliser vos identifiants de compte AWS production.

De cette façon, si vous décidez de ne pas aller de l'avant avec l'outil, vous pouvez laisser tomber, terminer le test compte AWS, et aller de l'avant, sans se soucier 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 touches d'accès secrets, mais en utilisant vos touches de production pour les tests et ensuite changer les touches crée beaucoup de travail, car vous avez besoin de mettre à jour tous les lieux qui fait référence à vos clés existantes.

Si vous êtes comme beaucoup d'autres utilisateurs d'AWS, vous allez utiliser un certain nombre d'outils et de bibliothèques, et de revenir à eux de mettre à jour vos clés est une douleur. Vous feriez mieux d'utiliser des comptes non productifs de tester de nouveaux outils.