Cinq règles d’or pour la sécurité dans le cloud AWS (Amazon Web Services)

La création d’un nouveau compte AWS se fait avec un login / mot de passe initial. Ce mot de passe donne accès au compte dit « racine » qui a tous les droits sur le compte, y compris celui de le clore définitivement. L’utilisation du compte racine doit donc rester exceptionnelle afin d’éviter les manipulations hasardeuses qui peuvent impacter tous les accès liés à ce compte.

Pour créer des accès utilisateurs nominatifs pour l’ensemble de vos administrateurs, il est donc fortement conseillé d’utiliser AWS IAM (Identity and Access Management). Ce service permet de délivrer à chaque administrateur ses propres identifiants, mots de passe et clefs d’accès aux API AWS, et donc de pouvoir conditionner les différents accès.

IAM propose un langage riche pour autoriser certaines actions sur certaines ressources particulières. Pour faciliter la prise en main, il existe des rôles prêts à l'emploi comme « Administrateur » ou « Power User ».

Il est aussi essentiel de mettre en place un processus de gestion des clefs en interne et de s’assurer qu’elles sont bien gardées en lieu sûr. Il est enfin conseillé d’utiliser des clefs différentes en fonction des applications, de les changer régulièrement et de supprimer les clefs qui ne sont plus utilisées.

Une fois les comptes AWS IAM créés, il est fortement conseillé d’activer le mode MFA (MultiFactor Authentication) sur le compte racine. Il s’agit d’ajouter une étape dans l’authentification. En effet, pour s’y connecter, elle nécessitera, en plus du login/mot de passe, un second mot de passe à usage unique (OTP) - celui-ci est généré soit par un token physique Gemalto, soit par une application sur Smartphone. Ainsi, seul le possesseur du token ou du smartphone pourra se connecter au compte racine.

Cette opération est très simple :

1. Se connecter au compte AWS avec le compte racine ;
2. Choisir le service AWS IAM ;
3. Cliquer sur « Manage MFA Device » ;
4. Choisir « Virtual MFA Device » ;
5. Scanner le QR code avec votre smartphone, puis saisir deux codes successifs délivrés par l'application ;
6. Option : vous pouvez également imprimer le QR code et garder la page au coffre. Elle permettra de régénérer l’application smartphone en cas d’effacement accidentel de l’application du smartphone ;
7. Désormais la connexion au compte racine nécessitera un second mot de passe OTP.

AWS CloudTrail est un service gratuit qui dépose dans votre réceptacle Amazon S3 (bucket) les journaux d’accès aux API AWS – ces accès aux API proviennent de la console AWS ou d’appels directs aux API. Ces journaux sont au format JSON et sont délivrés environ toutes les cinq minutes.

En effet, en cas d’opération douteuse sur votre compte AWS, il est important de pouvoir consulter les journaux d’accès. Il est donc essentiel d’activer au préalable ces journaux via le service AWS CloudTrail. Ce dernier est activé indépendamment pour chaque région AWS (AWS CloudTrail est aujourd’hui disponible dans huit régions).

L’activation se fait simplement via la console en sélectionnant le service.

Protégez durablement vos données : Amazon S3 est conçu pour une durabilité de 99,999999999%. Cela signifie que si vous stockez 10.000 objets dans Amazon S3, vous pourriez perdre en moyenne 1 objet toutes les 10 millions d’années. Cette durabilité est assurée par un fort niveau de redondance des données dans des bâtiments séparés. À côté de cette durabilité technique, le plus grand risque de perte de données est désormais l’erreur humaine : l’effacement accidentel d’une donnée par un utilisateur ou un administrateur.

Heureusement, ce risque est prévu par Amazon S3 avec le service de versioning. Cette fonctionnalité peut être activée indépendamment pour chaque bucket Amazon S3. Une fois activée, Amazon S3 conservera tout l’historique des objets stockés, qu’ils aient été modifiés ou supprimés. Cela permet de revenir facilement en arrière en cas d’erreur.

Le seul impact du versioning est que la facturation inclura le stockage de l’ensemble des versions antérieures des objets, y compris les objets supprimés. Pour modérer cet impact, il est possible de combiner le versioning avec le Lifecycle Management. Ainsi pour chaque bucket Amazon S3 vous pouvez décider d’archiver et/ou de supprimer automatiquement les anciennes versions des objets au bout d’un certain nombre de jours.

Exemple de paramétrage :

• Versioning activé sur le bucket Amazon S3 ;
• les versions courantes des objets sont stockées au coût Amazon S3 (soit $0,03/Go/mois en Europe) ;

• les versions précédentes des objets et les objets supprimés :

  • sont stockés au coût Amazon S3 pendant 10 jours,
  • puis sont archivés dans Amazon Glacier (réduction de 60% des coûts de stockage),
  • enfin sont supprimés au bout de 120 jours.

De nombreux développeurs aiment partager sur Internet les scripts qu’ils ont développés – par exemple sur Github. Dans certains cas, ces développeurs publient accidentellement leurs clefs d’API AWS et donnent un accès involontaire à leur compte AWS. AWS scrute en permanence ces sites de partage de code afin de prévenir ces développeurs de leur publication accidentelle et leur donner les procédures à suivre.

Afin de réduire ce risque, il est important de ne jamais mettre des clefs d’accès AWS « en dur » dans des scripts ou des applications. Pour les scripts et applications s’exécutant dans Amazon EC2, il existe un moyen simple de générer automatiquement des clefs d’accès aux API AWS sans jamais mettre de clefs « en dur » dans les scripts : il s’agit des « rôles EC2 ».

Le service AWS IAM permet de définir une notion de « rôle » c’est-à-dire de droits d’accès aux API AWS pour une application. Au lancement d’une instance Amazon EC2, on peut choisir quel rôle associer à cette instance. Ainsi AWS IAM va générer automatiquement des clefs ayant les droits correspondant à ce rôle, ces clefs étant différentes pour chaque instance Amazon EC2. Ces clefs ont une durée de vie limitée et leur rotation a lieu plusieurs fois par jour. Les SDK fournis par AWS utilisent automatiquement et de manière transparente ces clefs temporaires.

Exemples d’utilisation :

• autoriser l’application à lire/écrire dans Amazon DynamoDB – base de données NoSQL opérée par AWS ;
• autoriser l’application à lire un bucket Amazon S3 pour récupérer les dernières mises à jour ;
• autoriser l’application à faire des snapshots de ces volumes disque EBS – c’est particulièrement utile pour les bases de données afin de réaliser les snapshots quand les disques sont dans un état cohérent ;
• autoriser l’application à publier des métriques applicatives dans AWS CloudWatch.

Par extension, il est recommandé de penser à créer des rôles IAM et des accès temporaires si :

• vous disposez d'une application ou des scripts CLI sur Amazon EC2 ;
• vous devez accorder l'accès intercomptes ;
• vous avez une application mobile ;
• vous souhaitez faire une fédération d'identité avec un annuaire d'entreprise comme Microsoft Active Directory via le protocole SAML v2 ;
• votre organisation dispose d'un système d’authentification sur site.