Dans le cadre du modèle de responsabilité partagée d'AWS, tandis qu'AWS gère la « sécurité DU cloud » (centres de données physiques, matériel hôte, hyperviseurs), le client assume l'entière responsabilité de la « sécurité DANS le cloud » — en particulier la gouvernance des identités, l'hygiène des clés secrètes et le contrôle des accès. La compromission d'un compte Root AWS sans restriction ou d'un utilisateur IAM privilégié permet à des cyberattaquants de déployer des milliers de dollars d'instances de minage crypto, d'exfiltrer des bases de données S3 entières ou de procéder à des suppressions destructrices de sauvegardes.
MFA obligatoire pour tous les utilisateurs avec accès console et non négociable pour le compte Root.
AWS autorise jusqu'à 8 clés FIDO2 et jetons virtuels distincts par compte, éliminant tout SPOF matériel.
Politique IAM de refus conditionnel global bloquant les appels d'API tant que la MFA n'est pas active.
Référentiels de conformité Cloud : CIS Benchmark & Normes Réglementaires
Que votre organisation prépare une attestation SOC 2 Type II, une certification ISO 27001, un audit PCI DSS 4.0 ou applique le pilier Sécurité du framework AWS Well-Architected, l'application de la MFA à l'ensemble des identités IAM constitue un prérequis incontournable :
| Cadre Réglementaire | Spécification du Contrôle | Niveau d'Exigence | Mécanisme d'Audit |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Niveau 1 (Obligatoire) | Évaluation automatique AWS Security Hub / Prowler |
| PCI DSS 4.0 | Exigence 8.4.2 | Obligatoire | Audit des consoles et API de l'environnement de données bancaires (CDE) |
| SOC 2 Type II (Critères de confiance) | CC6.1 / CC6.2 | Contrôle Clé | Inspection indépendante des rapports d'identifiants IAM (Credential Reports) |
| Obligation Plateforme AWS 2024–2026 | Politique Globale AWS | Blocage Plateforme | Interdiction de connexion Root sans enregistrement MFA préalable |
L'impératif absolu de sécurisation du compte Root AWS
Au sein d'un compte AWS, l'utilisateur Root représente l'identité toute-puissante créée à l'ouverture. Contrairement aux rôles et utilisateurs IAM, les actions du compte Root ne peuvent pas être restreintes par des politiques IAM basées sur l'identité ni par des SCP au sein d'un compte autonome.
Rayon d'impact destructeur en cas de compromission du compte Root :
- Clôture irréversible du compte : Les attaquants peuvent cliquer sur « Clôturer le compte », planifiant la destruction définitive de l'infrastructure ;
- Piratage financier et facturation : Remplacer les cartes bancaires enregistrées, modifier les coordonnées de facturation et instancier des centaines de machines GPU pour miner des cryptomonnaies à vos frais ;
- Éclatement de l'arborescence AWS Organizations : Détacher les comptes membres de l'organisation pour désactiver la surveillance de sécurité centralisée ;
- Modification des contacts de sécurité officiels : Changer l'adresse e-mail et le téléphone de contact coupe définitivement toute assistance par le support AWS officiel.
- Zéro Clé d'Accès Root (Access Keys) : Vérifiez dans le Credential Report qu'aucune clé d'accès programmatique n'existe pour le compte Root. Si une clé est présente, supprimez-la sur-le-champ ;
- Chiffrement et partage sous double garde : Générez un mot de passe aléatoire de plus de 32 caractères, séparez-le en deux fragments confiés à deux dirigeants distincts (ex. RSSI et Directeur Juridique) et scellez-les dans des coffres-forts physiques distincts ;
- Redondance multi-terminaux (jusqu'à 8 équipements) : Enregistrez au moins deux clés matérielles FIDO2 physiques (YubiKeys) ainsi qu'un équipement de secours TOTP virtuel hors ligne conservé au coffre.
Matrice de sélection MFA : TOTP virtuel vs FIDO2 matériel (YubiKey)
AWS prend en charge trois grandes familles d'équipements MFA. Les architectes cloud doivent choisir le facteur approprié selon le niveau de criticité des accès :
Applications TOTP Virtuelles
Codes standard RFC 6238 (Google Authenticator, Aegis, 2FAS, 2FA-Tool). Déploiement instantané, aucun coût matériel. Idéal pour les développeurs standards.
Gamme YubiKey 5
Résistant au Phishing. La validation cryptographique liée au nom de domaine bloque les proxys inverses d'hameçonnage. Obligatoire pour le Root et les Administrateurs.
Cartes Gemalto / Thales
Boîtier autonome avec écran LCD sans aucune connectivité. Indispensable pour les salles sécurisées ou zones confidentielles (SCIF) où les smartphones et clés USB sont interdits.
Certification FIPS 140-2 Niveau 3 et Gouvernance sous Double Garde :
Pour les grandes entreprises et les sous-traitants de la défense, la protection du compte Root impose des boîtiers physiques certifiés FIPS 140-2 Niveau 3. Dépourvus d'interface sans fil ou Bluetooth, ils sont immunisés contre les logiciels espions mobiles.
Protocole de Double Garde Physique : Lors des manœuvres de secours d'urgence (Break-Glass), la connexion Root requiert deux collaborateurs : l'un détenant les identifiants d'accès maîtres, l'autre détenant la clé physique du coffre ignifugé abritant le jeton matériel.
Imposition de la MFA via les politiques IAM (Implémentation JSON)
La conformité d'entreprise ne peut dépendre du bon vouloir des collaborateurs. L'imposition doit être programmatique : tout utilisateur non authentifié avec la MFA doit être systématiquement interdit de toute action dans la console ou via les API, à l'exception unique d'enregistrer son propre périphérique MFA.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
La déclaration n°4 évalue la clé de condition globale "aws:MultiFactorAuthPresent": "false" avec un Deny explicite. Comme un refus explicite l'emporte toujours sur toutes les autorisations Allow, tout appel d'API sans MFA valide est immédiatement rejeté, forçant l'utilisateur à enregistrer son jeton d'authentification pour débloquer ses accès.
Authentification AWS CLI & SDK : Jetons de session temporaires STS
Lorsque la MFA est imposée par politique IAM, les développeurs lançant des commandes comme aws s3 ls ou exécutant des déploiements Terraform recevront des erreurs AccessDenied. Les clés d'accès statiques permanentes ne peuvent pas demander de code 2FA de manière interactive.
Les ingénieurs doivent utiliser AWS STS (Security Token Service) pour échanger leurs clés permanentes et un code TOTP contre des identifiants temporaires :
Script d'automatisation (aws-mfa-session.sh) :
Placez ce script utilitaire dans votre environnement local (~/.aws/aws-mfa-session.sh) pour automatiser l'obtention de jetons de session :
# Échange des clés AWS permanentes + Code MFA contre un jeton STS temporaire
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Saisissez votre code TOTP 2FA à 6 chiffres : "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Authentification réussie ! Session temporaire exportée (Valide 12 heures)."
else
echo "❌ Échec d'authentification. Vérifiez le code ou la dérive d'horloge de l'appareil."
fi
Délégation de rôles entre comptes (AssumeRole) avec contrainte MFA
Dans les architectures multi-comptes d'entreprise, les ingénieurs s'authentifient sur un compte central Identity, puis basculent sur les comptes cibles (Production, Préproduction) via sts:AssumeRole. Pour empêcher tout usage frauduleux d'identifiants dérobés, la relation de confiance (Trust Policy) du rôle de production doit exiger explicitement la validation MFA :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Cette architecture garantit que même si les clés d'un développeur sont interceptées dans le compte central, l'attaquant ne pourra jamais assumer le rôle privilégié de production sans fournir un jeton MFA valide.
Audit CloudTrail & Alertes en temps réel avec EventBridge
La surveillance de sécurité proactive impose de détecter instantanément toute connexion à la console de gestion AWS effectuée sans double facteur. En capturant les événements CloudTrail et en les acheminant via Amazon EventBridge, les équipes SecOps disposent d'un système d'alerte immédiat :
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Dès réception de l'événement, EventBridge déclenche une notification Amazon SNS vers le canal d'astreinte du centre opérationnel de sécurité (SOC) ou exécute une fonction AWS Lambda révoquant sur-le-champ la session utilisateur suspecte.
Gouvernance multi-comptes : AWS Organizations & IAM Identity Center
Dans les entreprises gérant des dizaines ou des centaines de comptes AWS dans des Landing Zones, créer des utilisateurs IAM individuels dans chaque compte est un contre-modèle obsolète.
Fédération d'identité centralisée :
Déployez AWS IAM Identity Center (anciennement AWS SSO) dans votre compte de gestion dédié (Management Account). Fédérez vos identités avec votre fournisseur d'identité d'entreprise (Okta, Microsoft Entra ID, PingFederate). Imposez la MFA directement au niveau de l'IdP, tout en attachant des politiques de contrôle de service (SCP) au niveau de la racine de l'organisation pour bloquer toute action Root non autorisée dans les comptes membres :
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
SCP de production : Imposer la contrainte MFA sur tous les comptes membres
En attachant une Service Control Policy (SCP) au niveau de la racine de l'organisation ou d'une unité organisationnelle (OU), l'équipe d'architecture cloud établit un garde-fou inviolable : les opérations destructrices d'API sont refusées inconditionnellement sans session MFA active :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Chaînage de rôles & Durée de vie des jetons STS :
Lorsque des identités IAM assument un rôle intermédiaire qui assume ensuite un rôle secondaire (« role chaining »), AWS STS retire le contexte originel aws:MultiFactorAuthPresent du jeton en aval ! Pour maintenir une conformité continue, concevez vos flux de délégation directement depuis la session authentifiée d'IAM Identity Center sans empiler de rôles intermédiaires.
Plan de reprise d'activité : Procédure en cas de perte du MFA Root
Que se passe-t-il si toutes les clés matérielles FIDO2 et jetons virtuels du compte Root sont détruits ou inaccessibles ?
Séquence officielle de déblocage hors bande :
- Connexion Root initiale : Saisissez l'adresse e-mail Root et le mot de passe maître sur la console AWS ;
- Résolution de problème MFA : Sur l'invite MFA, cliquez sur « Résoudre un problème lié à l'authentification multifacteur » (Troubleshoot MFA) ;
- Vérification de l'adresse e-mail principale : AWS transmet un lien de confirmation à durée limitée sur la messagerie Root principale. Cliquez sur le lien pour valider le défi ;
- Appel téléphonique automatisé : Cliquez sur « M'appeler maintenant ». Le système vocal automatisé d'AWS appelle le numéro de téléphone officiel du compte et énonce un code PIN de confirmation à 6 chiffres.
Si le numéro de téléphone a changé ou si le collaborateur référent a quitté l'entreprise sans mise à jour des paramètres du compte AWS, la récupération automatique échoue. Le recours manuel nécessite alors de fournir les actes légaux notariés d'enregistrement de votre entreprise auprès des équipes AWS Trust & Safety, entraînant un délai d'examen de 3 à 7 jours ouvrés.
FAQ de l'Architecte Cloud Entreprise
Les jetons MFA du compte Root peuvent-ils être partagés au sein d'une équipe DevOps ? ▼
C'est formellement interdit. Le partage d'identifiants Root fait échouer tous les audits de conformité (SOC 2, ISO 27001). L'administration courante doit s'effectuer exclusivement via des rôles IAM Identity Center avec traçabilité nominative. Les identifiants Root doivent demeurer scellés dans des coffres sous double garde pour les urgences absolues uniquement.
En quoi la clé de condition aws:MultiFactorAuthAge renforce-t-elle la sécurité ? ▼
Cette clé vérifie la fraîcheur de la session. En configurant "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}, vous exigez que le jeton MFA ait été validé dans les 3 600 secondes précédentes (1 heure). Les opérations à haut risque (ex. suppression de clusters RDS) seront bloquées si la session est plus ancienne, vous protégeant contre le vol de sessions persistantes.
Puis-je utiliser le générateur 2FA-Tool pour enregistrer un périphérique virtuel AWS MFA ? ▼
Oui. Le MFA virtuel d'AWS respecte rigoureusement les spécifications RFC 6238 TOTP (HMAC-SHA1, pas temporel de 30 secondes, 6 chiffres). Vous pouvez saisir la clé secrète Base32 dans 2FA-Tool.com pour calculer les deux codes d'authentification consécutifs exigés lors de l'enregistrement, 100 % localement dans votre navigateur.
Testez vos jetons TOTP d'entreprise en toute sécurité
Générez instantanément des codes de vérification TOTP RFC 6238 avec l'API Web Crypto du W3C. Aucun appel serveur, exécution strictement isolée en mémoire, zéro fuite de données.