6 grandes vulnérabilités AWS IAM – et comment les éviter

Qu’est-ce qu’une vulnérabilité dans le cloud ? En termes simples, il s’agit d’une faiblesse exploitable dans un environnement cloud. Les vulnérabilités sont souvent causées par des erreurs de configuration des ressources cloud et peuvent entraîner des fuites de données et des failles de sécurité, en particulier lorsqu’elles concernent la gestion des identités et des accès (IAM).

IAM est notoirement complexe, et les conséquences d’une mauvaise configuration peuvent être graves. Selon notre  rapport State of Cloud Security 2021, IAM est l’erreur de configuration cloud la plus fréquemment citée (par 41 % des répondants). De plus, le rapport 2021 de Verizon sur les enquêtes relatives aux fuites de données indique que des identifiants étaient impliqués dans 61 % des fuites analysées.

Dans cet article, nous présentons plusieurs vulnérabilités liées à AWS IAM, ainsi que des conseils pour les prévenir.

Vulnérabilités liées aux identifiants AWS

Ne pas renouveler les clés d’accès

La vulnérabilité : Des clés d’accès IAM qui ne sont pas renouvelées

Pourquoi est-ce dangereux ?  Les clés d’accès sont des identifiants à long terme que les utilisateurs IAM utilisent pour accéder par programmation à l’interface CLI ou à l’API. Elles sont composées d’un ID de clé d’accès et d’une clé d’accès secrète. Plus les clés restent actives longtemps, plus un acteur malveillant a de chances de les compromettre. Des clés d’accès compromises sont tout aussi dangereuses qu’un nom d’utilisateur et un mot de passe compromis.

Comment y remédier : CIS AWS Foundations Benchmark v1.4.0 recommande de renouveler les clés d’accès tous les 90 jours ou moins. Vous pouvez le faire depuis AWS Management Console, la CLI ou l’API. Voici les étapes générales :

1. Créer une nouvelle clé d’accès

2. Mettre à jour les applications pour qu’elles utilisent la nouvelle clé

3. Désactiver l’ancienne clé

4. Après avoir vérifié que les applications fonctionnent, supprimer l’ancienne clé

Consultez les étapes de correction ici.

Réutiliser des mots de passe

La vulnérabilité : Réutiliser un mot de passe déjà utilisé

Pourquoi est-ce dangereux ? Comme pour les clés d’accès, plus un mot de passe reste actif longtemps, plus il risque d’être compromis. Le réutiliser ne fait qu’aggraver le problème. Il existe également un risque d’attaques par bourrage d’identifiants, lors desquelles un attaquant tente d’accéder à un compte en essayant de nombreuses combinaisons de noms d’utilisateur et de mots de passe volés.

Comment y remédier : CIS AWS Foundations Benchmark v1.4.0 recommande de définir une politique de mots de passe dans laquelle l’option « Empêcher la réutilisation des mots de passe » est activée et le « Nombre de mots de passe à mémoriser » est fixé à 24.  Consultez les étapes de correction ici.

Ne pas utiliser l’authentification multifacteur

La vulnérabilité : Ne pas utiliser l’authentification multifacteur

Pourquoi est-ce dangereux ?  L’authentification multifacteur (MFA) ajoute une couche de protection pour les utilisateurs IAM. Sans elle, un nom d’utilisateur et un mot de passe suffisent pour se connecter à AWS. Un attaquant disposant d’identifiants compromis a donc les clés du royaume. Lorsque l’authentification multifacteur est activée pour un compte, l’utilisateur doit fournir une information supplémentaire pour se connecter, par exemple un code à usage unique généré par un dispositif MFA virtuel ou matériel. Sans cette information, la connexion échoue et l’attaquant est bloqué.

Comment y remédier : CIS AWS Foundations Benchmark v1.4.0 recommande d’activer l’authentification multifacteur pour tous les utilisateurs IAM ayant accès à la console.  Consultez les étapes de correction ici.

Vulnérabilités liées aux politiques IAM

Autoriser des actions de listage trop larges sur les compartiments S3

La vulnérabilité : Les politiques des rôles IAM autorisent des actions de listage trop larges sur les compartiments S3

Pourquoi est-ce dangereux ? Si un rôle IAM dispose d’une politique autorisant des actions de listage trop larges sur les compartiments S3 et qu’un acteur malveillant accède à ce rôle, il peut répertorier tous vos compartiments pour découvrir où vous stockez vos données. Comme s3 sync nécessite également des autorisations de listage, l’acteur malveillant peut alors potentiellement voler des données sensibles dans vos compartiments. Évitez d’inclure les actions s3:ListAllMyBuckets, s3:List* et s3:* dans les politiques IAM, sauf si elles sont absolument nécessaires. Cette vulnérabilité pourrait avoir contribué à la fuite de données de Capital One en 2019. Pour en savoir plus, consultez Analyse technique de l’incident de fuite de données de Capital One causé par une erreur de configuration du cloud.

Comment y remédier : Supprimez de la politique IAM les autorisations de listage trop larges. Consultez les étapes de correction ici.

Autoriser tous les principaux à assumer un rôle

La vulnérabilité : Les politiques d’approbation des rôles IAM autorisent tous les principaux à assumer le rôle

Pourquoi est-ce dangereux ? Autoriser n’importe quel utilisateur IAM de n’importe quel compte AWS à assumer un rôle dans votre compte revient à lui accorder toutes les autorisations associées à ce rôle IAM. Les conséquences peuvent être catastrophiques : élévation des privilèges, exfiltration de données, etc. Vérifiez que les politiques d’approbation des rôles ne contiennent pas tous les éléments suivants :

• Effect: « Allow »

• Principal: « * »

• Action: « sts:AssumeRole »

Comment y remédier : Remplacez le caractère générique par un principal spécifique. Consultez les étapes de correction ici.

Accorder des privilèges d’administration complets

La vulnérabilité : Les politiques IAM accordent des privilèges d’administration complets "*:*"

Pourquoi est-ce dangereux ? Une politique IAM qui autorise toutes les autorisations possibles pour tous les services possibles enfreint directement le principe de sécurité du  moindre privilège. Si un acteur malveillant accède à un utilisateur ou à un rôle associé à une telle politique, il dispose d’un accès illimité à l’ensemble de votre compte AWS : la partie est terminée. Il est préférable d’attribuer uniquement les autorisations nécessaires, et rien de plus.

Comment y remédier : Supprimez les caractères génériques des politiques Allow dans lesquelles Action et Resource sont tous deux définis sur *.  Consultez les étapes de correction ici.

Conseils et bonnes pratiques IAM

Voici quelques bonnes pratiques à suivre avec IAM :

• Appliquez le principe de sécurité du moindre privilège. N’accordez que les autorisations nécessaires à l’exécution d’une tâche. Mieux vaut commencer avec un rôle doté d’un minimum d’autorisations et en ajouter au besoin que de commencer par un accès administratif et de retirer des autorisations.

• Adoptez de bonnes pratiques en matière de mots de passe. Vous pouvez créer une politique de mots de passe pour les utilisateurs afin de leur imposer des critères lors de la création d’un mot de passe, comme une longueur minimale (CIS recommande au moins 14 caractères), une combinaison de lettres, de chiffres et de symboles, ainsi que l’interdiction de réutiliser un ancien mot de passe. Vous pouvez également définir une date d’expiration pour obliger les utilisateurs à renouveler leur mot de passe périodiquement, par exemple tous les 90 jours.

• Stockez les identifiants de manière responsable. N’enregistrez pas de clés d’accès ou de mots de passe dans des dépôts de code, même privés : c’est ainsi qu’ Uber s’est fait pirater en 2016. Ne partagez pas non plus les identifiants entre utilisateurs.

• Surveillez votre configuration IAM pour être averti de tout changement de politique ou de toute activation ou désactivation d’une clé d’accès. Vous devriez également rédiger des règles personnalisées pour répondre aux besoins spécifiques de votre entreprise. Votre organisation exige-t-elle que les utilisateurs changent leur mot de passe AWS tous les 45 jours ? Mettez en place une solution qui vérifie, dans chaque compte AWS, la présence d’une politique de mots de passe imposant cette exigence.

Envie d’en apprendre davantage ? Découvrez notre série sur les 5 erreurs de configuration AWS les plus courantes.