AWS Multi-party Approval pour Organizations

Le Multi-party approval est une capacité d'AWS Organizations qui bloque un ensemble prédéfini d'opérations à haut risque tant qu'un quorum d'humains nommés ne les a pas approuvées hors bande. Un seul jeu d'identifiants, même valide, ne peut plus appuyer sur la gâchette à lui seul. Le demandeur déclenche l'action, une approval team distincte la passe en revue dans un portail dédié, et l'opération ne s'exécute qu'une fois l'approval threshold de l'équipe atteint.

C'est le principe des "quatre yeux" appliqué au niveau de l'API plutôt que dans un runbook ou un message Slack. Cela comble l'écart entre "nous avons une politique qui dit que deux personnes doivent valider" et "la plateforme refuse physiquement de continuer sans deux validations".

Ce que c'est réellement

Le Multi-party approval (MPA) se situe au sein d'AWS Organizations et dépend d'IAM Identity Center pour les identités humaines. Vous définissez une approval team, un ensemble d'approbateurs issus de votre source d'identité, et vous y attachez un approval threshold : le nombre minimal de ces personnes qui doivent dire oui avant qu'une protected operation puisse s'exécuter.

Vous marquez ensuite certaines opérations comme protected. À partir de là, quiconque invoque une protected operation n'obtient pas de résultat immédiat. Il obtient une demande en attente. MPA envoie un e-mail à chaque approbateur de l'équipe, chacun ouvre l'approval portal, examine la demande, puis l'approuve ou la refuse. Une fois le threshold atteint, l'opération de l'appelant initial est autorisée à se poursuivre. L'approbation est la barrière, pas une notification a posteriori.

Le vocabulaire

Approval team : un groupe nommé d'approbateurs, adossé à des utilisateurs IAM Identity Center.
Approval threshold : combien d'approbateurs doivent approuver. Une équipe de trois avec un threshold de deux signifie que deux d'entre eux, quels qu'ils soient, débloquent l'action.
Protected operation : l'action précise que vous avez placée derrière la barrière.
Approval portal : la surface hors bande où les approbateurs examinent et répondent. Elle est délibérément séparée de la session console qui a émis la demande.

Comment fonctionne le flux

Le processus comporte trois étapes, et la séparation entre elles est tout l'enjeu.

Demande. Un utilisateur (ou un appelant automatisé) invoque une protected operation. Au lieu de s'exécuter, AWS crée une session d'approbation et notifie l'équipe.
Session d'approbation. Les approbateurs reçoivent un e-mail avec un lien, ouvrent le portail, et voient exactement ce qui est demandé, par qui et sur quelle ressource. Ils approuvent ou refusent de manière indépendante.
Exécution. Lorsque les approbations atteignent le threshold, l'opération s'exécute. Si la session expire ou que le threshold n'est jamais atteint, l'opération n'a jamais lieu.

Le demandeur ne peut pas approuver sa propre demande depuis sa propre session. L'approbation se fait sur une surface différente, liée à des identités différentes. C'est ce qui rend insuffisant, à lui seul, un jeton de session volé ou un rôle CI compromis.

Pourquoi c'est important pour la sécurité

La valeur n'est pas l'e-mail ni le portail. C'est que le contrôle vit en dessous de l'application, dans la plateforme, là où un seul principal compromis ne peut pas le contourner.

Cela supprime le point unique de compromission

La plupart des incidents cloud catastrophiques se résument à une identité dotée d'une portée trop grande : une clé à longue durée de vie divulguée, un admin hameçonné, un rôle d'automatisation surdimensionné. Pour la poignée d'opérations capables de ruiner votre semaine, MPA transforme "un identifiant compromis" en "vous devez aussi subvertir N humains indépendants en même temps". C'est une autre catégorie d'attaque.

Cela impose la séparation des tâches au niveau de l'API

La séparation des tâches vit en général dans un document de conformité et meurt dans la pratique, parce que rien n'empêche un ingénieur pressé d'effectuer les deux moitiés d'un changement sensible. MPA déplace la règle dans le control plane. C'est la plateforme, et non la bonne volonté, qui impose la seconde signature.

C'est un frein contre les rançongiciels et les saboteurs internes

Le scénario destructeur classique consiste à supprimer d'abord les sauvegardes, puis les données. Si les opérations qui suppriment ou modifient vos points de récupération protégés sont placées derrière un quorum, un attaquant qui détient une identité ne peut pas détruire en silence votre dernière ligne de récupération. Le même frein s'applique à un employé mécontent disposant d'un accès légitime.

Cela produit une piste d'audit défendable

Chaque protected operation porte désormais la trace de qui l'a demandée, de qui l'a approuvée et quand. Pour SOC 2, ISO 27001, PCI DSS ou une revue interne post-incident, "montrez-moi les approbations pour cette action" devient une requête plutôt qu'un travail d'archéologie.

Où cela trouve sa place, et où non

Utilisez le Multi-party approval quand	Passez votre chemin quand
L'opération est rare, à fort rayon d'impact et irréversible	L'opération est fréquente et nécessite une exécution immédiate
Vous exploitez AWS Organizations avec IAM Identity Center	Vous exploitez des comptes autonomes sans Organizations ni Identity Center
Vous avez besoin d'une validation distribuée pour la conformité ou le Zero Trust	Le risque ne justifie pas la charge de gestion des équipes et des workflows
Vous voulez protéger la suppression ou l'altération de sauvegardes de dernier recours	Vous avez besoin d'une automatisation qui s'exécute sans surveillance, sans humain dans la boucle

MPA est un scalpel, pas une couverture. Placez-le sur les opérations où un faux pas est irrécupérable : destruction de coffres de sauvegarde logiquement air-gapped, démantèlement de garde-fous au niveau de l'org, suppression de points de récupération. Ne le placez pas sur des opérations que votre équipe exécute quarante fois par jour, sinon vous entraînerez tout le monde à approuver machinalement, ce qui est pire qu'aucun contrôle.

Modes de défaillance à anticiper

Disponibilité des approbateurs. Si votre threshold est de deux et que seules deux personnes composent l'équipe, un simple congé peut bloquer une urgence légitime. Dimensionnez l'équipe plus large que le threshold et tenez la liste à jour.
Tension du break-glass. Un incident réel peut nécessiter la protected operation rapidement. Décidez à l'avance comment joindre les approbateurs en dehors des heures ouvrées, et répétez-le, avant la nuit où cela comptera.
Lassitude d'approbation. Protégez trop, et les approbateurs cessent de lire. Le contrôle dégénère en clic réflexe. Gardez la liste protégée courte et réellement à enjeux élevés.
Dépendance à la source d'identité. MPA s'appuie sur IAM Identity Center. S'il est mal configuré ou indisponible, votre chemin d'approbation l'est aussi. Cela fait partie de votre planification de résilience, pas en dehors.

À retenir

Le Multi-party approval est l'un des rares contrôles AWS qui change le calcul pour un attaquant au lieu de simplement lever une alerte. Pour le petit ensemble d'opérations où une seule erreur ou un seul identifiant volé est catastrophique, une barrière à quorum fait la différence entre un incident et une catastrophe. Appliquez-le étroitement, dotez correctement les approval teams en personnel, et répétez le chemin de break-glass.