Comment éviter les 11 principales erreurs de configuration d’AWS

Lorsque vous configurez une nouvelle infrastructure cloud AWS, ou que vous modifiez des paramètres pour accorder des autorisations ou en retirer, vous devez tenir compte d’un certain nombre de points concernant la sécurité.

En vertu du modèle de responsabilité partagée d’AWS, vous êtes responsable de la sécurité « dans » le cloud, tandis qu’AWS est responsable de la sécurité « du » cloud. En d’autres termes, vous êtes responsable des modifications que vous apportez, lesquelles peuvent entraîner l’exposition publique de vos données.

Dans cet article, nous passons en revue les erreurs de configuration les plus fréquentes des services les plus utilisés et vous expliquons comment modifier l’infrastructure en toute sécurité et éviter les compromissions.

Les quatre principales erreurs de configuration de S3

1. Compartiments publics et objets publics contenus dans des compartiments

Si vous devez utiliser S3 pour stocker un site web ou héberger un site statique, il est probable que vous devrez rendre publique une partie de vos compartiments, voire la totalité. Ce processus est facile, mais s’il n’est pas réalisé correctement, vos données risquent d’être compromises. Or, nous le savons, les compromissions de données ont eu des conséquences extrêmement dommageables ces dernières années. Si vous créez un nouveau compartiment et que vous souhaitez le rendre public, vous avez le choix entre différentes options.

Comme le montre la capture d’écran ci-dessous, vous pouvez choisir d’autoriser l’accès public aux compartiments et aux objets via de nouvelles listes de contrôle d’accès, n’importe quelle liste de contrôle d’accès, de nouvelles stratégies de point d’accès ou n’importe quelle stratégie de point d’accès :

Veillez à bien choisir l’option la plus appropriée pour votre application. Faites également attention aux objets que vous ajoutez à votre compartiment, car celui-ci restera public jusqu’à ce que vous modifiiez ce paramètre, ce qui peut exposer des données sensibles.

2. Ne pas utiliser la journalisation des accès

Dans S3, la journalisation des accès est un paramètre facile à activer, accessible via l’onglet Properties (Propriétés) d’un compartiment :

Ce paramètre est désactivé par défaut, mais vous pouvez l’activer en cliquant sur le bouton Edit (Modifier) et en sélectionnant un compartiment cible pour le stockage des journaux.

Ce paramètre a pour fonction de journaliser toute demande d’accès au compartiment. L’utilisation de ces journaux n’entraîne aucuns frais supplémentaires. En outre, ces journaux peuvent être très utiles dans certaines situations et peuvent même vous aider à expliquer une facture S3 à un client. Cependant, gardez à l’esprit que leur stockage dans le compartiment cible vous sera facturé au tarif S3 habituel. De plus, comme ces journaux ont tendance à vite s’accumuler, il peut s’avérer judicieux de configurer un mécanisme de suppression automatique.

Par ailleurs, évitez d’activer la journalisation des accès pour votre compartiment cible, sans quoi vous créerez une boucle sans fin et risquez de vous retrouver avec une facture salée à payer.

3. Ne pas utiliser la gestion des versions et le cycle de vie S3

L’activation de la gestion des versions pour un compartiment vous permet de stocker plusieurs instances d’un objet dans le même compartiment. Le principal avantage de cette fonction est qu’en cas de dysfonctionnement d’une application ou d’action inappropriée de la part d’un utilisateur, vous pourrez restaurer l’objet concerné.

Pour activer cette fonction, accédez à la console S3, puis à l’onglet Properties (Propriétés) :

Ce paramètre étant facile à activer, il est conseillé d’associer une authentification multifacteur (MFA) aux opérations de suppression. Vous éviterez ainsi toute suppression involontaire d’instances antérieures des objets.

La gestion des versions présente toutefois un inconvénient : pour chaque version d’un objet, la totalité de l’objet est stockée, et pas uniquement les différences entre cet objet et ses versions antérieures. Pour résoudre ce problème, vous pouvez utiliser des règles de configuration du cycle de vie S3, par exemple pour que les anciens objets soient automatiquement supprimés au bout d’un certain temps. Vous pouvez également transférer ces objets vers des services de stockage plus abordables, tels que S3 Glacier Flexible Retrieval, et les supprimer dès lors qu’ils ont été remplacés par leur version la plus récente.

4. Ne pas chiffrer les informations critiques

Si vous stockez des données sensibles, veillez à toujours les chiffrer, soit côté serveur via S3, soit côté client par vous-même. Si vous choisissez de chiffrer les données côté serveur, la procédure est beaucoup plus simple, car Amazon se charge du chiffrement, du stockage et du déchiffrement lors du téléchargement ou de la copie d’un objet. Vous pouvez activer cette fonction depuis l’onglet Properties (Propriétés) en cliquant sur le bouton Edit (Modifier) dans la section Default encryption (Chiffrement par défaut) :

Vous pourrez alors choisir les clés que vous souhaitez utiliser pour le chiffrement. Les clés SSE-S3 sont gérées par S3, de sorte que vous n’avez rien à faire. Les clés SSE-KMS sont gérées par le biais de KMS et nécessitent un peu plus de configuration.

Si vos données sont très sensibles, vous pouvez envisager de les chiffrer vous-même avant de les stocker. C’est possible, mais un peu risqué, car si vous perdez vos clés, vous ne pourrez plus récupérer ou déchiffrer vos objets. En outre, comme ce processus est complexe et nécessite un gros travail de configuration, il vous est conseillé de consulter la documentation AWS pour voir comment procéder.

Les trois principales erreurs de configuration d’EC2

1. Instantanés publics ou instantanés partagés non chiffrés

Par défaut, les instantanés que vous créez à partir de vos instances sont en mode privé. Il pourrait toutefois en être autrement dans deux cas de figure.

Dans le premier cas de figure, un utilisateur disposant d’autorisations suffisantes (ou un service tel qu’AWS Lambda) pourrait activer le mode public. Un état antérieur de vos données pourrait alors être disponible publiquement, ce qui peut avoir des conséquences désastreuses. Dans le deuxième cas de figure, vous pourriez avoir besoin de partager un instantané non chiffré. Dans ce cas, le destinataire pourra créer des volumes à partir de cet instantané, ce qui revient à démarrer une instance contenant toutes vos données.

Dans les deux cas, vous devez chiffrer vos instantanés, ce qui implique de chiffrer vos instances au moment de leur création ou de créer un instantané chiffré, puis un nouveau volume racine à partir de cet instantané.

2. Présence d’instances backend dans des sous-réseaux publics

Si certaines de vos instances ne nécessitent pas de connexion Internet (bases de données ou API simples, par exemple), pensez à les conserver dans des sous-réseaux privés. Les connexions Internet représentent une menace omniprésente, qui peut frapper à tout instant, car vous ne savez jamais qui a accès à l’adresse IP de votre instance.

Pour permettre à une instance d’être active dans un sous-réseau privé, il suffit d’interdire l’attribution automatique d’adresses IPv4 et IPv6. Pour ce faire, accédez à l’onglet Subnet (Sous-réseau) de la console VPC, choisissez le sous-réseau de votre instance et désactivez ce paramètre :

3. AMI publiques/non chiffrées

Si vous devez créer une AMI (Amazon Machine Image), vous aurez peut-être aussi besoin de la partager avec un autre compte. Dans ce cas, faites preuve de vigilance et prenez un certain nombre de mesures pour empêcher les compromissions de sécurité.

Tout d’abord, veillez à chiffrer vos volumes. Ainsi, les AMI susceptibles de contenir un volume seront chiffrées par défaut et ne révéleront aucune donnée. Ensuite, soyez prudent lorsque vous accordez des autorisations à EC2, car vous devrez peut-être définir la disponibilité de l’AMI en mode public. Cela peut s’avérer problématique si votre entreprise compte un utilisateur interne malveillant parmi son effectif ou si des services tels qu’AWS Lambda sont compromis.

Enfin, partagez toujours vos AMI par le biais de la console pour éviter tout risque d’exposition publique :

Les quatre principales erreurs de configuration de l’IAM

1. Absence de MFA ou de rotation des clés

L’authentification multifacteur (MFA) est cruciale et devrait être obligatoire pour toute entité ajoutée à votre solution de gestion des identités et des accès (IAM), en particulier les utilisateurs. De cette façon, vous pourrez limiter les vols de clés et réduire considérablement la surface d’attaque. Pour activer la MFA, accédez à l’onglet Security Credentials (Identifiants de sécurité) de l’utilisateur auquel vous souhaitez l’appliquer et sélectionnez l’option souhaitée :

Veillez également à appliquer la rotation des clés d’accès à l’intégralité du compte. Si AWS ne permet pas de le faire automatiquement et suggère de le faire manuellement, il existe en revanche des outils open source qui peuvent automatiser et simplifier le processus pour vous. Cela ne concerne que les utilisateurs IAM, pas les rôles, étant donné que les clés attribuées aux rôles expirent automatiquement au bout d’un certain temps.

2. Ne pas utiliser de rôles

Grâce à la gestion des identités et des accès ou IAM (Identity Access Management), vous pouvez choisir d’accorder des autorisations aux utilisateurs en leur associant directement des règles. Une telle pratique n’est toutefois pas recommandée dans les infrastructures critiques et de grande taille, car vous risquez d’octroyer les mauvaises autorisations aux mauvaises personnes. En outre, si vous oubliez de retirer ces autorisations, elles resteront actives à tout jamais.

En utilisant des rôles comme principale méthode d’octroi des autorisations, vous pouvez tirer parti de l’expiration automatique des clés, ce qui vous permettra de gérer les autorisations excessives ou les vols de clés beaucoup plus facilement. Si bon nombre de vos utilisateurs partagent des privilèges communs, vous pouvez aussi choisir d’utiliser des groupes. En revanche, évitez d’associer directement des règles à ces utilisateurs.

3. Attribuer trop de privilèges

Lorsque vous accordez des autorisations, appliquez le principe du moindre privilège. Si un utilisateur ou un rôle doit accéder à un service, identifiez les actions spécifiques qu’il doit entreprendre pour effectuer son travail, et attribuez ces privilèges à l’entité IAM — au lieu de choisir la voie de la facilité, qui consiste à attribuer l’accès à l’intégralité du service. Comme nous l’avons vu, il existe de nombreuses autorisations simples mais puissantes qui, une fois accordées, peuvent avoir des conséquences désastreuses.

4. Conserver des identifiants inutilisés

Assurez en permanence le suivi de vos clés, ainsi que des utilisateurs et des rôles actifs au sein de votre infrastructure. Si un utilisateur devient inactif pour quelque raison que ce soit (vacances, licenciement, etc.), vous pourrez désactiver les clés correspondantes pendant la durée nécessaire, puis les supprimer au bout d’un certain temps.

Ainsi, aucun jeu de clés associé à des autorisations ne se retrouvera dans la nature et vous éviterez de créer une faille dans votre environnement. Il est toujours préférable de récréer un utilisateur que d’exposer votre environnement à des attaques internes potentielles.

See Crowdstrike Falcon In Action

Téléchargez ce nouveau rapport pour découvrir les principales menaces pour la sécurité du cloud à surveiller en 2022 et comment les neutraliser.

Télécharger