Imposer le MFA sur les comptes AWS : les politiques qui le forcent vraiment

On n’impose pas le MFA sur AWS en le demandant — on l’impose avec une politique de refus qui bloque tout sauf la configuration du MFA tant qu’aucun appareil n’est enregistré, ou mieux, en déplaçant les humains vers IAM Identity Center où le MFA est un réglage d’annuaire plutôt qu’un tour de politique. La politique d’application classique est un Deny avec "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} plus une exclusion NotAction pour les actions MFA en libre-service. Trompez-vous d’opérateur de condition et la politique barre les utilisateurs hors de l’inscription — ou n’impose silencieusement rien du tout.

Ce qui se passe

Chaque requête AWS authentifiée porte des clés de contexte, et aws:MultiFactorAuthPresent est celle qui dit si la session a prouvé un deuxième facteur. La subtilité qui casse la plupart des politiques maison : la clé n’est présente que sur les identifiants temporaires (sessions console, sessions AssumeRole, résultats de GetSessionToken). Les requêtes signées avec de simples clés d’accès à long terme ne portent pas la clé du tout — elle n’est pas « false », elle est absente. C’est pourquoi l’opérateur compte : "Bool": {"aws:MultiFactorAuthPresent": "false"} ne correspond pas quand la clé manque, alors un utilisateur avec des clés d’accès passe à côté de la politique sans être touché. BoolIfExists traite « absente » comme une correspondance, ce qui est ce que vous voulez — les appels CLI avec clés nues sont refusés en même temps que les sessions console sans MFA. Ce comportement est voulu, mais il bloque aussi les scripts de service qui roulent sous des utilisateurs IAM, une raison de plus pour que ceux-ci soient des rôles; les rôles assumés par des services AWS ne sont pas touchés parce que la politique est attachée aux utilisateurs humains, pas aux rôles de charges de travail.

L’application a donc trois couches. Utilisateurs IAM : la politique deny-sauf-MFA sur un groupe contenant chaque humain. L’utilisateur racine : aucune politique ne peut le contraindre — le MFA racine est une étape manuelle non négociable, et AWS exige progressivement le MFA pour les utilisateurs racine des comptes de gestion et autonomes depuis 2024. Utilisateurs Identity Center : IAM Identity Center > Settings > Authentication, réglez l’invite MFA à « Every time they sign in (always-on) » ou contextuelle, et l’enregistrement à obligatoire à la connexion — aucun JSON impliqué. Les détails sur la clé de contexte vivent dans la documentation IAM.

Quoi vérifier en premier

Qui s’authentifie encore comme utilisateur IAM. La politique ne compte que pour cette population; les utilisateurs Identity Center sont gouvernés par les réglages d’annuaire.
La colonne mfa_active du rapport d’identifiants — votre écart d’application actuel, utilisateur par utilisateur.
Le statut du MFA racine sur chaque compte, incluant les comptes bac-à-sable oubliés, visible par compte sous IAM > Dashboard > Security recommendations.
Si de l’automatisation roule sous des utilisateurs IAM du groupe humain — elle va casser le jour où le deny atterrit; migrez-la vers des rôles d’abord.

Comment vérifier

# Quels utilisateurs n'ont pas d'appareil MFA?
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d \
  | awk -F, '$8=="false" {print $1}'   # colonne 8 = mfa_active

# Lister les appareils MFA d'un utilisateur
aws iam list-mfa-devices --user-name jsmith

# Sommaire du compte incluant le MFA racine
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

Pour tester l’application après le déploiement de la politique : connectez-vous comme utilisateur de test sans MFA et confirmez que la console montre Access Denied partout sauf sur le chemin IAM > Users > (self) > Security credentials; ensuite enregistrez un appareil, déconnectez-vous, reconnectez-vous, et confirmez le retour de l’accès normal.

Le runbook

Déployez la politique deny-sauf-MFA sur un groupe contenant tous les utilisateurs IAM humains. La forme qui fonctionne — réduite à ses deux énoncés décisifs :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOwnMfaSetup",
      "Effect": "Allow",
      "Action": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                 "iam:ResyncMFADevice", "iam:ListMFADevices",
                 "iam:GetUser", "iam:ChangePassword"],
      "Resource": ["arn:aws:iam::*:mfa/*", "arn:aws:iam::*:user/${aws:username}"]
    },
    {
      "Sid": "DenyAllExceptSetupWithoutMFA",
      "Effect": "Deny",
      "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                    "iam:ResyncMFADevice", "iam:ListMFADevices",
                    "iam:GetUser", "iam:ChangePassword", "sts:GetSessionToken"],
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }
  ]
}

Annoncez une échéance avant de l’attacher. Les utilisateurs en pleine tâche perdent tout sauf le chemin d’inscription au moment où la politique atterrit; un préavis d’une semaine transforme une tempête de billets de soutien en non-événement.
Configurez le MFA racine sur chaque compte à la main. Clés matérielles ou FIDO2 pour le compte de gestion; entreposez l’information de récupération sous un vrai contrôle d’accès. Plusieurs appareils MFA par utilisateur racine sont supportés — enregistrez-en deux.
Basculez Identity Center en MFA permanent si les humains passent par le SSO : Settings > Authentication > MFA, invite à chaque connexion, enregistrement obligatoire à la première connexion.
Doublez avec de la détection. Une alarme basée sur CloudTrail sur les connexions console où additionalEventData.MFAUsed vaut « No » attrape ce que la couche politique manque — le câblage est dans notre base CloudTrail et GuardDuty.

Quand ce n’est pas la bonne approche

Perfectionner le MFA des utilisateurs IAM est le mauvais investissement si le vrai correctif — déplacer les humains vers Identity Center — est disponible; la politique ci-dessus est un échafaudage pour la période héritée, pas la destination (notre guide Identity Center couvre le passage). Évitez aussi d’attacher le deny aux rôles de charges de travail : aws:MultiFactorAuthPresent n’existe jamais pour les rôles assumés par des services, donc BoolIfExists refuserait vos propres applications.

Erreurs fréquentes

Utiliser Bool au lieu de BoolIfExists, ce qui exempte exactement les utilisateurs à clés d’accès que vous devez attraper.
Oublier l’exclusion libre-service, barrant les utilisateurs non inscrits hors de l’inscription — la politique verrouille son propre remède.
Imposer le MFA pour la console en laissant de vieilles clés d’accès comme porte de côté sans politique.
Considérer le MFA racine du compte principal comme réglé pendant que les comptes bac-à-sable et hérités restent sans protection.

Prévention

Alertez chaque semaine sur toute ligne mfa_active=false du rapport d’identifiants; la liste devrait être vide et le rester.
Intégrez l’attachement de la politique MFA dans l’automatisation de création d’utilisateurs pour qu’aucun humain n’existe hors du groupe encadré.
Préférez les clés de sécurité FIDO2 ou les passkeys au TOTP virtuel quand l’équipe peut les supporter; les deux battent l’absence de deuxième facteur.
Revérifiez le MFA racine après chaque acquisition de compte ou restructuration d’organisation — les comptes hérités sont là où vivent les trous.

L’application du MFA, c’est une politique, une page de réglages et un rituel racine manuel — la partie difficile est seulement de décider que « recommandé » veut dire « obligatoire ». Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.