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

Stephan Hadinger

Cet article a été rédigé par Stephan Hadinger, Sr Manager Solutions Architecture Amazon Web Services.

Vous pouvez réagir par rapport à cet article sur le forum : Commentez ♪

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

- Auteur : Stephan Hadinger

- Parution : 20 décembre 2014

- Licence : Copyright ® 2014 Stephan Hadinger. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Cinq règles d’or pour la sécurité dans le cloud AWS

- I-A. Utilisez des comptes IAM adaptés

- I-B. Activez le MFA sur le compte racine

- I-C. Activez le service AWS CloudTrail

- I-D. Activez le Versioning sur Amazon S3

- I-E. Utilisez des rôles Amazon EC2 IAM adaptés

- II. Conclusion

I - Cinq règles d’or pour la sécurité dans le cloud AWS

La perspective d’une migration de l’infrastructure informatique vers le cloud est de plus en plus séduisante pour de nombreuses entreprises, encore faut-il pouvoir le faire en toute sécurité. Il est donc essentiel de connaitre et mettre en place les bonnes pratiques de la sécurité afin de réussir sa migration dans le cloud.

Le cloud d’AWS apporte aujourd’hui de nombreux bénéfices comme une flexibilité à la minute, une capacité sans limites, des services hautement disponibles, des coûts toujours plus bas, et un niveau de sécurité très élevé intégrant des certifications majeures comme ISO-27001, SOC-1/2/3 ou encore PCI DSS niveau 1.

Le modèle de sécurité d’Amazon Web Services est un modèle de responsabilité partagée, c’est-à-dire qu’AWS assure la sécurisation des couches basses (bâtiments, hyperviseurs, filtrage réseau…) et les clients assurent la sécurité de leurs applications, données et OS. Les clients ont les droits administrateurs sur leurs machines virtuelles ainsi qu’un contrôle total et permanent des configurations de leurs ressources AWS : mots de passe utilisateurs et administrateurs, droits d’accès associés, règles de filtrage réseau – pour n’en citer que quelques-uns…

Les clients ont pour ainsi dire « les clefs de leur datacenters virtuels ». Il est donc important de confier la gestion de ces clefs à des administrateurs de confiance, tout en auditant régulièrement leur utilisation. C’est pour cela que le modèle généralement retenu par les clients AWS est celui du « droit minimal » et de la « séparation des tâches ». En clair : les administrateurs ont seulement les droits dont ils ont besoin et les opérations sensibles nécessitent des droits répartis entre plusieurs personnes.

Pour aller plus loin dans la sécurisation des données, nous vous présentons aujourd’hui cinq règles d’or, simples et applicables en moins de cinq minutes chacune, pour la sécurité de votre compte AWS.

I-A - Utilisez des comptes IAM adaptés

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.

I-B - Activez le MFA sur le compte racine

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.

Les tokens physiques Gemalto peuvent être commandés en ligne.

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.

Le mode MFA pourra également être activé sur chaque accès de vos administrateurs.

I-C - Activez le service AWS CloudTrail

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.

I-D - Activez le Versioning sur Amazon S3

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.

I-E - Utilisez des rôles Amazon EC2 IAM adaptés

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.

Les clefs associées au rôle EC2 sont obtenues via le serveur de métadonnées de l’instance (http://169.254.169.254), il est important de ne pas associer de rôle sur des serveurs partagés par plusieurs utilisateurs, car chaque utilisateur aura potentiellement accès à ces clefs.

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.

II - Conclusion

La sécurité est une priorité de tous les instants, les règles vues ci-dessus sont utiles et faciles à mettre en œuvre. Il existe de nombreuses autres bonnes pratiques à mettre en place – certaines sont propres au cloud mais la plupart sont communes avec l’informatique sur site. Dans tous les cas, n’hésitez pas à contacter les équipes AWS pour plus d’informations ou des conseils personnalisés.

Vous pouvez réagir par rapport à cet article sur le forum : Commentez