Les 5 erreurs de configuration AWS les plus effrayantes

Écrit par

Shilpi Bhattacharjee

31 octobre 2022

0 minutes de lecture

En 2022, AWS (Amazon Web Services) reste l’une des principales plateformes cloud et continue d’être reconnu comme un leader des services d’infrastructure et de plateforme cloud.AWS représente 34 % des fournisseurs de services d’infrastructure cloud ; de nombreuses organisations hébergent donc aujourd’hui tout ou partie de leur infrastructure sur AWS.

La migration vers un fournisseur cloud, notamment AWS, présente des avantages considérables pour ses clients — économies potentielles, évolutivité, avantage concurrentiel, sécurité renforcée et possibilités de collaboration, entre autres — mais la configuration doit être effectuée correctement afin d’éviter les failles de sécurité.

Voici les cinq principales erreurs de configuration AWS à connaître pour éviter les failles de sécurité potentielles dans votre infrastructure :

Mauvaise configuration d’AWS CloudTrail

Flux de travail AWS CloudTrail illustrant l’enregistrement des activités, le stockage des événements, la surveillance, l’analyse et les usages pour l’audit, le suivi de la sécurité et le dépannage.

La première erreur de configuration à redouter est sans doute la plus importante. La mauvaise configuration d’AWS CloudTrail concerne le service de surveillance AWS, qui doit être activé dans votre organisation AWS et dans tous vos comptes AWS. Même s’il n’est pas activé dans vos comptes AWS, il doit l’être dans toutes les régions et les journaux doivent être stockés dans un compartiment S3 distinct. Ces mesures de sécurité sont essentielles : sans elles, un attaquant pourrait accéder à votre compte AWS.

En cas de faille de sécurité, vous n’auriez aucun moyen de savoir ce que l’attaquant a fait dans votre compte AWS — c’est précisément le rôle de CloudTrail. En identifiant les actions d’un utilisateur IAM AWS, CloudTrail vous permet de suivre les traces laissées par un utilisateur malveillant et de découvrir ce qui a été modifié pendant l’incident. L’activation d’AWS CloudTrail vous fournit les outils et les informations nécessaires pour garantir l’efficacité de votre plan de réponse aux incidents.

Mauvaise configuration d’AWS IAM

Schéma AWS Identity and Access Management montrant qui peut accéder aux ressources, les autorisations définies par les politiques IAM et les ressources organisationnelles AWS

La deuxième erreur de configuration AWS concerne AWS IAM (Identity and Access Management). Dans le cloud, l’identité est primordiale. Perdre l’accès à vos identifiants, les enregistrer en clair dans des secrets sur GitHub ou d’autres services de stockage, ou utiliser des utilisateurs IAM dans AWS sans MFA ou comme compte utilisateur root constitue une grave erreur de configuration.

C’est dangereux, car donner aux utilisateurs l’accès à votre compte root, ainsi qu’à votre utilisateur IAM avec MFA, signifie qu’un attaquant qui obtient ces identifiants codés en dur peut s’en servir pour se connecter et potentiellement faire tout ce qu’il veut dans le compte AWS auquel il a accès.

Mauvaise configuration d’un compartiment AWS S3

La prochaine erreur de configuration AWS à surveiller concerne les compartiments S3 : elle se produit lorsqu’un compartiment S3 reste accessible sans contrôles d’autorisation adéquats.

Souvenez-vous du compartiment CloudTrail mentionné plus haut. Si vous en autorisez l’accès à tout le monde dans votre organisation et qu’un attaquant parvient à accéder à des identifiants internes, il peut supprimer vos journaux CloudTrail et vous empêcher de découvrir ce qui s’est passé.

Mauvaise configuration d’AWS EC2

La quatrième erreur de configuration AWS concerne AWS EC2 (Elastic Compute Cloud). Une erreur de configuration fréquente d’AWS EC2 expose votre application hébergée sur EC2 à Internet. Si votre application est vulnérable, des utilisateurs malveillants peuvent potentiellement l’attaquer si sa règle de pare-feu, aussi appelée groupe de sécurité AWS, autorise le trafic depuis Internet. Utiliser un profil d’instance IAM ayant accès à l’ensemble de votre organisation représente également un risque pour la sécurité.

C’est particulièrement préoccupant, car cette situation peut servir de point de départ à une fuite de données. Dès qu’un utilisateur malveillant accède à une instance EC2, il peut potentiellement accéder à l’ensemble de son compte, selon la gravité de vos erreurs de configuration AWS.

Mauvaise configuration d’AWS RDS

Schéma illustrant la connexion d’Amazon RDS aux applications et présentant les fonctionnalités et avantages des bases de données gérées : sécurité, évolutivité, sauvegardes et réduction des coûts.

Même s’il s’agit d’un service géré par AWS, des erreurs de configuration restent possibles. Par exemple, vous pourriez laisser votre instance RDS accessible depuis Internet et configurer un groupe de sécurité ou une règle de pare-feu qui l’expose sur un port par défaut, permettant ainsi aux personnes malveillantes de savoir exactement quel port rechercher. Vous pourriez aussi rendre accessibles depuis Internet les instantanés de sauvegarde de vos machines virtuelles et instances RDS, permettant à des tiers de consulter vos données antérieures, sans que la base de données soit protégée par une authentification.

Cela présente un risque, car une base de données peut contenir des informations telles que vos données personnelles et celles de vos clients. Toutefois, vous pouvez prévenir les failles de sécurité et les attaques par déni de service potentielles en mettant en place les contrôles appropriés et en configurant correctement AWS pour votre application. Pour rester informé des vulnérabilités connues dans AWS et découvrir comment configurer vos comptes AWS afin d’optimiser leur sécurité, consultez les ressources ci-dessous.