De plus en plus d’entreprises décident de migrer vers une infrastructure cloud, et notamment Amazon Web Services pour profiter de nouvelles ressources et d’une puissance de stockage élastique. Mais elles doivent mettre en place une politique de sécurité adaptée sous peine d’être victimes de fuites de données personnelles ou confidentielles.
La base de données de Deep Root Analytics classait les 198 millions d'électeurs inscrits selon leurs tendances politiques dans 48 catégories. Outre leurs noms, elle contenait leur date de naissance, leur adresse personnelle, leurs numéros de téléphone… Créé au moment de l'élection présidentielle de 2012 aux États-Unis, cet énorme fichier (1,1 To) était stocké sur un cloud public d’Amazon Web Services par Deep Root Analytics.
Mais en juin 2017, l'équipe Cyber Risk d'UpGuard constate que ce fichier n’est pas du tout protégé : n'importe qui pouvait y accéder en entrant dans le sous-domaine Amazon "dra-dw".
Cette fuite de données personnelles était inévitable, AWS S3 étant mal configuré. Cet exemple, qui n'est pas unique, confirme que les organisations ne doivent pas avoir le sentiment que leurs données sont sécurisées lorsqu’elles sont dans le cloud. C’est à elles d’être plus vigilantes et de mettre en place une politique de sécurité adaptée.
Comprendre le modèle de la responsabilité partagée
Dans le cadre d'un modèle de responsabilité partagée, le fournisseur et le client sont tous deux responsables de la sécurisation du cloud. Le fournisseur, Amazon, est responsable de la sécurité "du cloud", c'est-à-dire de son infrastructure qui comprend les installations d'hébergement, le matériel et les logiciels. La responsabilité d'Amazon comprend la protection contre les intrusions et la détection des fraudes et des abus.
Le client, à son tour, est responsable de la sécurité "dans" le cloud, c'est-à-dire le contenu propre de l'organisation, les applications utilisant AWS et la gestion des accès d'identité ainsi que son infrastructure interne comme les pare-feu et le réseau.
Comment sécuriser vos données sur la plate-forme AWS ?
- Activez CloudTrail sur tous les AWS et activez la validation du journal CloudTrail. L'activation de CloudTrail permet de générer des logs.
L'historique des appels de l'API donne accès à des données telles que les modifications de ressources. Avec la validation des logs CloudTrail activée, il est possible d’identifier toute modification apportée aux fichiers logs.
Ces logs pourront être redirigés vers un Security Information Management System (SIEM) afin de détecter les comportements anormaux et obtenir des alertes sur des cyberattaques ou des comportements anormaux. - Activez la journalisation de l'accès aux bucket de CloudTrail S3. L'activation de l'enregistrement des accès permet de suivre les accès et d'identifier les tentatives potentielles d'accès non autorisé.
- Activez la journalisation des flux pour le cloud privé virtuel (VPC). Ces journaux permettent de surveiller le trafic réseau qui traverse le VPC et d'avertir en cas d'activité anormale.
- Appliquez une politique stricte pour les accès. La solution Identity and Access Management (IAM) d’AWS permet de gérer facilement les politiques utilisateurs, les mots de passe, les clés d’accès, l’authentification, les autorisations à mettre en place…
L’interface IAM d’AWS permet de faire de la délégation par rôle. Cela permet de réduire le risque d'accorder involontairement des permissions et des privilèges excessifs à un utilisateur et d’améliorer l'efficacité de la gestion des permissions. - Restreignez l'accès aux logs du seau CloudTrail et utilisez l'authentification multifactorielle pour la suppression du bucket. L'accès sans restriction, même pour les administrateurs, augmente le risque d'accès non autorisé en cas de vol d’identifiants après une attaque de phishing.
- Chiffrez les données ainsi que les logs. Dans le cas de la migration de données (données de l’entreprise vers AWS/entre services AWS/entre instances AWS) cette action doit être effectuée par un canal sécurisé afin d’assurer la confidentialité, l’intégrité et la non-répudiation.
- Ne perdez pas vos clés ! Plus sérieusement, cela signifie notamment qu’il ne faut pas utiliser les clés d'accès avec les comptes root. Créez plutôt des comptes basés sur les rôles et évitez d'utiliser des comptes utilisateur root. Enfin, n’oubliez pas de supprimer les clés inutilisées et de désactiver les comptes inactifs.
