Security Group : un firewall devant chaque instance Amazon EC2

Security Group : un firewall devant chaque instance Amazon EC2

Celui-ci assure le filtrage réseau des flux entrants au niveau des protocoles et ports réseaux. Ils sont par défaut fermés en entrée (ingress), et ce sont les clients qui choisissent les ports et protocoles à ouvrir ainsi que les sources (plages d’adresses IP ou groupes de machines).

VPC : un réseau privé

Amazon VPC (Virtual Private Cloud) permet de définir un réseau IP privé et spécifique aux besoins de l’entreprise. Bénéficiant d’un plan adressage IP privé non routable depuis Internet, et totalement personnalisable, il peut s’intégrer sans couture à un réseau d’entreprise existant. Il est découpé en subnets, chaque subnet pouvant être publique (accessible depuis Internet) ou privé. Les serveurs accessibles depuis Internet pourront disposer d’EIP (Elastic IP) – adresses IPv4 publiques – temporaires ou permanentes.

En complément il est possible de spécifier des NACL (Network Access Control List) entre les subnets. Ces règles de filtrage seront idéalement gérées par l’équipe réseau et pourront pallier d’éventuelles erreurs de Security Group d’un exploitant serveur. La séparation des règles de gestion de la sécurité est un gage de meilleur contrôle.

Accès par VPN

Amazon VPC propose nativement une passerelle VPN redondée reposant sur le protocole IPSec,  qui supporte les principaux équipements VPN du marché (Cisco, Juniper, …). La configuration est simple à mettre en œuvre, et la console AWS génère des fichiers de configurations prêts à l’emploi pour certains de ces équipements.

AWS Direct Connect : connexion privée par fibre dédiée

Terminons les solutions d’isolation réseau par l’offre AWS Direct Connect. Dans le cas où le client préfère ne pas transférer ses données par sa connexion Internet, AWS Direct Connect permet d’établir une connexion privée entre un datacenter client et AWS, par des fibres dédiées de 1 Gbps ou 10 Gbps. Pour la région Irlande, les points de connexion sont situés chez Telecity Group Londres Docklands et Eircom Dublin. Plusieurs opérateurs réseaux sont capables de fournir de telles connexions. On notera aussi l’existence d’intégrateurs réseaux qui se chargent de l’ensemble de la chaîne avec un contrat unique (par ex : la société InterCloud ).

AWS Direct Connect est souvent préféré dans les cas suivants :

•    Transfert régulier d’importantes quantités de données qui polluerait l’accès Internet de l’entreprise ;
•    Garantie de débit de bout en bout ;
•    Garantie de latence de bout en bout.

Afin de garantir une très haute disponibilité de la connexion réseau, on pourra configurer plusieurs liaisons fibres en redondance actif/actif, puis utiliser un VPN Internet en dernier secours.

Connexion privée via AWS Direct Connect

Données en transit (‘data in flight’)

La sécurisation des données en transit est très simple. Vu que VPC assure une isolation réseau complète, seul le transfert de données vers et hors du Cloud AWS sera considéré ici.

Transfert vers Amazon S3 par HTTPS

Amazon S3 supporte nativement les protocoles HTTP et HTTPS. Il est possible d’ajouter la « bucket policy » figure 3 pour interdire l’accès en HTTP.

Il existe de nombreux outils pour transférer des données vers Amazon S3, commerciaux ou open-source. Citons par exemple AWS CLI . Cet outil est facile à configurer via la commande aws cli –configure. Il est facile de synchroniser un répertoire local avec un bucket Amazon S3, par exemple :

aws s3 sync . s3://bucket-name/some/path/ –recursive

Import initial avec AWS Import/Export

Si l’import initial des données dépasse le To (Tera-octet), il peut être intéressant de considérer le service AWS Import/Export qui consiste à envoyer des disques durs physiques chez AWS en Irlande afin que les données soient transférées vers Amazon S3 via des réseaux très hauts débits. Dans ce cas on prendra quelques précautions pour sécuriser le transfert.

Il est fortement recommandé de chiffrer les données à la source avant d’expédier les disques durs.

Une bonne pratique consistera à importer les données brutes chiffrées dans un bucket Amazon S3 temporaire, puis via une instance Amazon EC2, déchiffrer les données et les stocker dans le bucket Amazon S3 cible.

Accès à DynamoDB via HTTPS

L’accès à DynamoDB se fait systématiquement par HTTPS et ne nécessitera pas de précaution supplémentaire. Il est fortement conseillé d’utiliser les SDK fournis par AWS qui prennent en charge toute la mécanique d’authentification, la gestion des erreurs et la gestion des réémissions de requêtes.

Accès aux instances Amazon EC2 via SSH

L’accès aux machines virtuelles se fait systématiquement via SSH. Par défaut les accès Telnet et les authentifications par mots de passe sont désactivées. L’authentification SSH requiert systématiquement l’usage d’une clef privée. Il n’y a pas de précaution supplémentaire à prendre autre que d’utiliser les mécanismes standards de SSH.

À noter que si, de plus, le client a choisi d’utiliser VPC via un VPN, les données sont sur-chiffrées par le VPN.

Données au repos (‘data at rest’)

Terminons ce tour d’horizon sécurité par le chiffrement des données au repos.

« Server Side Encryption » natif

Un certain nombre de services AWS proposent nativement des fonctions (gratuites) de chiffrement côté serveur. Elles sont toutes basées sur un chiffrement AES-256 bits, avec rotation des clefs régulière. C’est le cas pour les services suivants :

•    Amazon S3 : cette option est gratuite et optionnelle, elle permet de choisir objet par objet ceux qui seront chiffrés côté serveur. Ce chiffrement est automatique lorsque les données sont migrées vers Amazon Glacier – option de stockage froid à $0,011/Go/mois en Irlande – cette option de migration vers Glacier se gère dans les options de cycle de vie des buckets S3.
•    Amazon Redshift : toutes les données stockées au sein de RedShift peuvent être chiffrées en AES-256 bits (option gratuite).
•    Amazon EBS (Elastic Block Store) : fournit des volumes de stockage permanent au niveau bloc à utiliser avec les instances Amazon EC2 et propose nativement une option de chiffrement AES-256 avec des clefs distinctes par volume

Dans certains cas, les clients peuvent vouloir gérer eux-mêmes les clefs de chiffrement. Il est toujours possible de chiffrer les données à la source, par exemple avec aescrypt. Attention cependant, le traitement des données nécessitera des développements spécifiques sur Hadoop pour déchiffrer les données à la volée au moment des traitements. Hadoop ne propose pas pour l’instant de solution prête à l’emploi mais les mécanismes d’extension sont disponibles, par exemple sous forme de SerDe (Serializer-Deserializer) sous Hive.

Chiffrement des données dans Amazon EC2

La première option est d’utiliser les volumes EBS chiffrés. Cette option est transparente pour l’OS et la gestion des clefs est assurée par AWS.

Pour les clients qui souhaitent gérer eux-mêmes leurs clefs de chiffrement, voici les différents mécanismes utilisables dans Amazon EC2 :

•    Chiffrement natif des volumes par l’OS : dm-crypt sous Linux ou BitLocker sous Windows (à noter que BitLocker ne sera pas utilisable pour le volume de boot car il nécessite l’accès à une puce TPM – non disponible dans Amazon EC2)
•    Chiffrement fichier par fichier au niveau du file-system : de multiples solutions existent, par exemple EFS (extension de NTFS) sous Windows
•    Chiffrement fichier par fichier ad-hoc : là encore de nombreuses solutions existent comme GPG  ou aescrypt.

Les solutions ci-dessus requièrent que les clefs soient elles-mêmes stockées sur les instances ou dans Amazon S3. Il existe enfin des solutions partenaires, par exemple TrendMicro SecureCloud  ou SafeNet ProtectV , qui permettent de chiffrer la totalité des volumes Amazon EC2 en stockant les clefs hors du cloud ou dans des HSM (Hardware Security Module) privés sur site ou hébergés au sein d’AWS. Le service AWS CloudHSM propose des boîtiers SafeNet Luna SA 5 à la demande. Ces solutions sont plus coûteuses et complexes à mettre en œuvre, et à réserver à des projets très particuliers.

Conclusion

Le cloud computing permet aujourd’hui de lancer de manière simple et rapide des projets de Big Data, il est cependant essentiel de garder à l’esprit l’importance de la sécurité avant et pendant ces projets. Une bonne évaluation de son fournisseur de cloud, une bonne compréhension des responsabilités, une gestion stricte des accès, la mise en place des bons outils et une analyse précise de la sensibilité des données permettent de lancer des projets de Big Data sécurisés dans le cloud et de pouvoir tirer profits de la flexibilité du cloud en toute sérénité.