AWS Multi-party Approval für Organizations

Multi-party approval ist eine Funktion von AWS Organizations, die eine vordefinierte Menge risikoreicher Operationen blockiert, bis ein Quorum namentlich benannter Menschen sie außerhalb des regulären Wegs freigibt. Ein einzelner Satz Anmeldedaten kann den Abzug nicht mehr allein betätigen, selbst wenn er gültig ist. Der Anforderer startet die Aktion, ein separates approval team (Freigabeteam) prüft sie in einem dedizierten Portal, und die Operation läuft erst, sobald der approval threshold (Freigabeschwelle) des Teams erreicht ist.

Das ist das Vier-Augen-Prinzip, durchgesetzt auf der API-Ebene statt in einem Runbook oder einer Slack-Nachricht. Es schließt die Lücke zwischen "wir haben eine Richtlinie, die besagt, dass zwei Personen abzeichnen müssen" und "die Plattform verweigert physisch jeden Schritt ohne zwei Freigaben".

Was es tatsächlich ist

Multi-party approval (MPA) sitzt innerhalb von AWS Organizations und stützt sich für die menschlichen Identitäten auf IAM Identity Center. Du definierst ein approval team, eine Gruppe von Freigebern aus deiner Identitätsquelle, und hängst einen approval threshold daran: die Mindestzahl dieser Personen, die zustimmen müssen, bevor eine protected operation laufen darf.

Anschließend markierst du bestimmte Operationen als protected. Ab diesem Punkt erhält niemand, der eine protected operation aufruft, ein unmittelbares Ergebnis. Stattdessen entsteht eine wartende Anfrage. MPA mailt jeden Freigeber des Teams an, jeder Freigeber öffnet das approval portal, prüft die Anfrage und gibt sie frei oder lehnt sie ab. Ist der threshold erreicht, darf die Operation des ursprünglichen Aufrufers fortfahren. Die Freigabe ist das Tor, nicht eine Benachrichtigung im Nachhinein.

Das Vokabular

Approval team: eine benannte Gruppe von Freigebern, hinterlegt mit IAM Identity Center Nutzern.
Approval threshold: wie viele Freigeber zustimmen müssen. Ein Team aus drei Personen mit einem threshold von zwei bedeutet, dass je zwei von ihnen die Aktion entsperren.
Protected operation: die konkrete Aktion, die du hinter das Tor gestellt hast.
Approval portal: die separate Oberfläche, auf der Freigeber prüfen und antworten. Sie ist bewusst von der Konsolensitzung getrennt, die die Anfrage gestellt hat.

Wie der Ablauf funktioniert

Der Prozess hat drei Schritte, und die Trennung zwischen ihnen ist der ganze Sinn der Sache.

Anfrage. Ein Nutzer (oder ein automatisierter Aufrufer) ruft eine protected operation auf. Statt sie auszuführen, erzeugt AWS eine Freigabesitzung und benachrichtigt das Team.
Freigabesitzung. Die Freigeber erhalten eine E-Mail mit einem Link, öffnen das Portal und sehen genau, was angefordert wird, von wem und gegen welche Ressource. Sie geben unabhängig voneinander frei oder lehnen ab.
Ausführung. Erreichen die Freigaben den threshold, läuft die Operation. Läuft die Sitzung ab oder wird der threshold nie erreicht, findet die Operation nie statt.

Der Anforderer kann seine eigene Anfrage nicht aus seiner eigenen Sitzung heraus freigeben. Die Freigabe geschieht auf einer anderen Oberfläche, gebunden an andere Identitäten. Genau das macht ein gestohlenes Session-Token oder eine kompromittierte CI-Rolle für sich allein unzureichend.

Warum es für die Sicherheit zählt

Der Wert liegt nicht in der E-Mail oder dem Portal. Er liegt darin, dass die Kontrolle unterhalb der Anwendung lebt, in der Plattform, wo ein einzelner kompromittierter Principal sie nicht umgehen kann.

Es beseitigt den einzelnen Kompromittierungspunkt

Die meisten katastrophalen Cloud-Vorfälle laufen auf eine Identität mit zu viel Reichweite hinaus: ein geleakter, langlebiger Schlüssel, ein gephishter Admin, eine zu breit gefasste Automatisierungsrolle. Für die Handvoll Operationen, die dir die Woche ruinieren können, verwandelt MPA "eine kompromittierte Anmeldeinformation" in "du musst zusätzlich N unabhängige Menschen gleichzeitig unterwandern". Das ist eine andere Angriffsklasse.

Es erzwingt Separation of Duties an der API

Separation of Duties lebt üblicherweise in einem Compliance-Dokument und stirbt in der Praxis, weil nichts einen gehetzten Ingenieur daran hindert, beide Hälften einer sensiblen Änderung selbst auszuführen. MPA verschiebt die Regel in die Steuerungsebene. Die Plattform, nicht der gute Wille, erzwingt die zweite Unterschrift.

Es ist eine Bremse gegen Ransomware und destruktive Insider

Das klassische destruktive Vorgehen ist, zuerst die Backups zu löschen, dann die Daten. Sitzen die Operationen, die deine geschützten Wiederherstellungspunkte löschen oder verändern, hinter einem Quorum, kann ein Angreifer, dem eine Identität gehört, deine letzte Wiederherstellungslinie nicht still zerstören. Dieselbe Bremse greift bei einem verärgerten Insider mit legitimem Zugang.

Es erzeugt einen Audit-Trail, den du verteidigen kannst

Jede protected operation trägt nun einen Nachweis darüber, wer sie angefordert hat, wer sie freigegeben hat und wann. Für SOC 2, ISO 27001, PCI DSS oder eine interne Post-Incident-Auswertung wird "zeig mir die Freigaben für diese Aktion" zu einer Abfrage statt zu einem archäologischen Projekt.

Wo es passt und wo nicht

Multi-party approval einsetzen, wenn	Verzichten, wenn
Die Operation selten ist, einen großen Wirkungsradius hat und irreversibel ist	Die Operation häufig ist und sofortige Ausführung braucht
Du AWS Organizations mit IAM Identity Center betreibst	Du eigenständige Konten ohne Organizations oder Identity Center betreibst
Du verteilte Freigaben für Compliance oder Zero Trust brauchst	Das Risiko den Aufwand für das Verwalten von Teams und Workflows nicht rechtfertigt
Du das Löschen oder Verändern von Last-Resort-Backups schützen willst	Du Automatisierung brauchst, die unbeaufsichtigt ohne Menschen im Ablauf läuft

MPA ist ein Skalpell, kein Tuch über alles. Setz es auf die Operationen, bei denen ein falscher Schritt nicht wiederherstellbar ist: das Zerstören logisch air-gapped Backup-Vaults, das Abbauen von Guardrails auf Organisationsebene, das Löschen von Wiederherstellungspunkten. Setz es nicht auf Operationen, die dein Team vierzig Mal am Tag ausführt, sonst trainierst du alle darauf, Freigaben abzunicken, was schlimmer ist als gar keine Kontrolle.

Failure modes, die du einplanen solltest

Verfügbarkeit der Freigeber. Liegt dein threshold bei zwei und sind nur zwei Personen im Team, kann ein einziger Urlaub einen legitimen Notfall blockieren. Mach das Team größer als den threshold und halte die Besetzung aktuell.
Break-glass-Spannung. Ein echter Vorfall kann die protected operation schnell brauchen. Entscheide vorab, wie du Freigeber außerhalb der Geschäftszeiten erreichst, und übe es, bevor die Nacht kommt, in der es zählt.
Freigabemüdigkeit. Schützt du zu viel, hören die Freigeber auf zu lesen. Die Kontrolle verkommt zum Reflexklick. Halte die geschützte Liste kurz und tatsächlich folgenschwer.
Abhängigkeit von der Identitätsquelle. MPA stützt sich auf IAM Identity Center. Ist das fehlkonfiguriert oder nicht verfügbar, ist es auch dein Freigabepfad. Es gehört in deine Resilienzplanung, nicht außerhalb davon.

Das Fazit

Multi-party approval ist eine der wenigen AWS-Kontrollen, die die Rechnung für einen Angreifer verändern, statt nur eine Flagge zu hissen. Für die kleine Menge an Operationen, bei denen ein einzelner Fehler oder eine einzelne gestohlene Anmeldeinformation katastrophal ist, ist ein Quorum-Tor der Unterschied zwischen einem Vorfall und einer Katastrophe. Wende es eng an, besetze die approval teams ordentlich und übe den break-glass-Pfad.

Read this next

AWS S3 New Feature: Re-encryption without Movement, dazu, wie AWS mehr Sicherheitskontrollen in die Plattformebene drückt.
When the Cloud Sneezes, the World Catches a Cold, über Wirkungsradius und warum es die Reibung wert ist, die irreversiblen Operationen zu schützen.

Baust du agentische Systeme, die AWS-Anmeldedaten halten? Dasselbe Quorum-Denken gilt für autonome Aktionen, siehe die Feldnotizen auf ercan.ai. Für Beratung zu AWS, Cloud-Sicherheit und Plattform-Governance, beginne bei ercanermis.com.