Impact des identifiants de compte AWS

Question

J'utilise les outils d'Amazon pour créer une application Web. Je suis très heureux avec eux, mais j'ai un problème de sécurité.

À l'heure actuelle, j'utilise plusieurs instances EC2, S3, SimpleDB et SQS. Afin d'authentifier les demandes auprès des différents services, vous devez inclure votre Access Identifiers (connexion requise).

Par exemple, pour télécharger un fichier à partir d'une instance S3 EC2, votre instance EC2 a besoin d'avoir votre accès ID de clé et votre accès secrète.

Cela signifie essentiellement que votre nom d'utilisateur et mot de passe doivent être dans vos instances.

Si l'une de mes instances devait être compromise, tous mes actifs Amazon seraient compromis. Les clés peuvent être utilisées pour télécharger/remplacer des données S3 et SimpleDB, démarrer et arrêter des instances EC2, etc.

Comment puis-je minimiser les dommages d'un seul hôte compromis? Ma première pensée est d'obtenir plusieurs identifiants par compte afin que je puisse suivre les modifications apportées et révoquer rapidement le compte «piraté». Amazon ne prend pas en charge plus d'un ensemble d'informations d'identification par compte. Mon second réflexe était de créer plusieurs comptes et d'utiliser des ACL pour contrôler l'accès. Malheureusement, tous les services ne permettent pas d'accorder l'accès à vos données à d'autres comptes. Plus la bande passante est moins chère, plus vous l'utilisez, donc tout passer par un compte est idéal.

Est-ce que quelqu'un a traité ou a au moins pensé à ce problème?

Answer 1

Ce que vous pouvez faire est d'avoir un seul 'serveur d'authentification' verrouillé. La clé secrète n'existe que sur ce serveur, et tous les autres serveurs devront demander l'autorisation. Vous pouvez attribuer vos propres clés aux différents serveurs et les verrouiller par adresse IP. De cette façon, si un serveur est compromis, vous révoquez simplement sa clé du 'serveur d'authentification'.

Ceci est possible en raison du mode de fonctionnement de l'authentification AWS. Supposons que votre serveur Web doive télécharger un fichier vers S3. D'abord, il va générer la requête AWS et envoyer cette requête avec votre clé de serveur personnalisée au 'serveur d'authentification'. Le serveur d'authentification va authentifier la requête, faire la magie de chiffrement et renvoyer la chaîne authentifiée au serveur web. Le serveur web peut alors l'utiliser pour envoyer la demande avec le fichier à télécharger sur S3.

Answer 2

AWS offre la "Consolidated Billing" qui répond à vos préoccupations à la réflexion.

https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=consolidated-billing

« facturation consolidée vous permet de consolider le paiement des services Web multiples Amazon (AWS) comptes au sein de votre entreprise en désignant un seul compte payant. Vous pouvez voir une vue combinée des coûts AWS encourus par tous les comptes, La facturation consolidée peut également réduire vos coûts globaux puisque l'utilisation cumulée de tous vos comptes peut vous aider à atteindre plus rapidement les niveaux de volume à bas prix. "

Answer 3

AWS vous permet de créer plusieurs utilisateurs avec Identity and Access Management. Cela vous permettra de mettre en œuvre l'un ou l'autre de vos scénarios.Je suggère de définir un utilisateur IAM par instance EC2, cela vous permet de révoquer l'accès à un utilisateur spécifique (ou simplement à ses clés d'accès) si l'instance EC2 correspondante est compromise et utilise également des permissions précises pour restreindre les API l'utilisateur peut appeler et les ressources auxquelles il peut accéder (par exemple, autoriser uniquement l'utilisateur à télécharger vers un compartiment spécifique).

Answer 4

En outre, les rôles AWS IAM vous permettent d'attribuer des autorisations à une instance EC2 plutôt que d'avoir à placer des clés sur l'instance. Voir l'article de blog au http://aws.typepad.com/aws/2012/06/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2.html La plupart des SDK utilisent les clés temporaires créées par les rôles.