Multi-party approval di AWS per Organizations

Multi-party approval è una funzionalità di AWS Organizations che blocca un insieme predefinito di operazioni ad alto rischio finché un quorum di persone designate non le approva fuori banda. Un singolo set di credenziali, anche se valido, non può più premere il grilletto da solo. Il richiedente avvia l'azione, un approval team separato la esamina in un portale dedicato e l'operazione viene eseguita soltanto quando l'approval threshold del team è raggiunto.

È il principio dei "quattro occhi" applicato a livello di API invece che in un runbook o in un messaggio Slack. Chiude il divario tra "abbiamo una policy che dice che due persone devono firmare" e "la piattaforma rifiuta fisicamente di procedere senza due firme".

Che cos'è davvero

Multi-party approval (MPA) risiede dentro AWS Organizations e dipende da IAM Identity Center per le identità umane. Definisci un approval team, un insieme di approvatori presi dalla tua identity source, e gli associ un approval threshold: il numero minimo di quelle persone che devono dire sì prima che una protected operation possa essere eseguita.

Poi marchi operazioni specifiche come protected. Da quel momento in poi, chiunque invochi una protected operation non ottiene un risultato immediato. Ottiene una richiesta in sospeso. MPA invia un'email a ogni approvatore del team, ognuno apre l'approval portal, esamina la richiesta e la approva o la nega. Una volta raggiunta la threshold, l'operazione del chiamante originale può procedere. L'approvazione è il cancello, non una notifica a cose fatte.

Il vocabolario

Approval team: un gruppo nominato di approvatori, basato su utenti di IAM Identity Center.
Approval threshold: quanti approvatori devono approvare. Un team di tre con una threshold di due significa che due qualsiasi di loro sbloccano l'azione.
Protected operation: l'azione specifica che hai messo dietro al cancello.
Approval portal: la superficie fuori banda dove gli approvatori esaminano e rispondono. È deliberatamente separata dalla sessione console che ha fatto la richiesta.

Come funziona il flusso

Il processo è in tre passi, e la separazione tra di essi è il punto centrale.

Richiesta. Un utente (o un chiamante automatizzato) invoca una protected operation. Invece di eseguirla, AWS crea una sessione di approvazione e avvisa il team.
Sessione di approvazione. Gli approvatori ricevono un'email con un link, aprono il portale e vedono esattamente cosa viene richiesto, da chi e contro quale risorsa. Approvano o negano in modo indipendente.
Esecuzione. Quando le approvazioni raggiungono la threshold, l'operazione viene eseguita. Se la sessione scade o la threshold non viene mai raggiunta, l'operazione non avviene.

Il richiedente non può approvare la propria richiesta dall'interno della propria sessione. L'approvazione avviene su una superficie diversa, legata a identità diverse. È questo che rende un token di sessione rubato o un ruolo CI compromesso insufficienti da soli.

Perché conta per la sicurezza

Il valore non è l'email o il portale. È che il controllo vive sotto l'applicazione, nella piattaforma, dove un singolo principal compromesso non può aggirarlo.

Rimuove il singolo punto di compromissione

La maggior parte degli incidenti cloud catastrofici si riduce a un'identità con troppa portata: una chiave a vita lunga trapelata, un admin vittima di phishing, un ruolo di automazione con scope eccessivo. Per la manciata di operazioni che possono rovinarti la settimana, MPA trasforma "una credenziale compromessa" in "devi anche sovvertire N esseri umani indipendenti allo stesso tempo". È una classe di attacco diversa.

Applica la separation of duties a livello di API

La separation of duties di solito vive in un documento di conformità e muore nella pratica, perché niente impedisce a un ingegnere di fretta di fare entrambe le metà di una modifica sensibile. MPA sposta la regola nel control plane. È la piattaforma, non la buona volontà, a imporre la seconda firma.

È un freno contro ransomware e insider distruttivi

Il classico copione distruttivo è cancellare prima i backup, poi i dati. Se le operazioni che cancellano o alterano i tuoi recovery point protetti stanno dietro a un quorum, un attaccante che possiede un'identità non può distruggere in silenzio la tua ultima linea di recupero. Lo stesso freno vale per un insider scontento con accesso legittimo.

Produce un audit trail difendibile

Ogni protected operation porta ora con sé un record di chi l'ha richiesta, chi l'ha approvata e quando. Per SOC 2, ISO 27001, PCI DSS o una revisione interna post-incidente, "mostrami le approvazioni per questa azione" diventa una query invece di un lavoro di archeologia.

Dove si inserisce, e dove no

Usa Multi-party approval quando	Evitala quando
L'operazione è rara, ad alto raggio d'impatto e irreversibile	L'operazione è frequente e richiede esecuzione immediata
Usi AWS Organizations con IAM Identity Center	Usi account standalone senza Organizations o Identity Center
Hai bisogno di firme distribuite per conformità o Zero Trust	Il rischio non giustifica l'onere di gestire team e workflow
Vuoi proteggere la cancellazione o l'alterazione dei backup di ultima istanza	Ti serve automazione che gira senza presidio, senza umani nel ciclo

MPA è un bisturi, non una coperta. Mettila sulle operazioni in cui una mossa sbagliata è irrecuperabile: distruggere backup vault logicamente isolati, smantellare i guardrail a livello di org, cancellare recovery point. Non metterla sulle operazioni che il tuo team esegue quaranta volte al giorno, o addestrerai tutti ad approvare a timbro automatico, il che è peggio di nessun controllo.

Modalità di fallimento da pianificare

Disponibilità degli approvatori. Se la tua threshold è due e nel team ci sono solo due persone, una singola vacanza può bloccare un'emergenza legittima. Dimensiona il team più grande della threshold e tieni l'elenco aggiornato.
Tensione del break-glass. Un incidente reale può aver bisogno della protected operation in fretta. Decidi in anticipo come raggiungere gli approvatori fuori orario, e provalo, prima della notte in cui conta.
Fatica da approvazione. Proteggi troppo e gli approvatori smettono di leggere. Il controllo degenera in un click riflesso. Tieni la lista delle operazioni protette corta e davvero ad alta posta in gioco.
Dipendenza dalla identity source. MPA si appoggia a IAM Identity Center. Se è mal configurato o non disponibile, lo è anche il tuo percorso di approvazione. Appartiene alla tua pianificazione di resilienza, non al di fuori di essa.

In sintesi

Multi-party approval è uno dei pochi controlli AWS che cambia i conti per un attaccante invece di limitarsi ad alzare una bandiera. Per il piccolo insieme di operazioni in cui un singolo errore o una singola credenziale rubata è catastrofico, un cancello a quorum è la differenza tra un incidente e un disastro. Applicala in modo mirato, dota gli approval team del personale giusto e prova il percorso di break-glass.

Leggi questo dopo

AWS S3 New Feature: Re-encryption without Movement, per come AWS sta spingendo più controlli di sicurezza giù nel livello della piattaforma.
When the Cloud Sneezes, the World Catches a Cold, sul raggio d'impatto e sul perché proteggere le operazioni irreversibili vale l'attrito.

Stai costruendo sistemi agentici che detengono credenziali AWS? Lo stesso ragionamento sul quorum vale per le azioni autonome, vedi le note sul campo su ercan.ai. Per consulenza su AWS, sicurezza cloud e governance della piattaforma, parti da ercanermis.com.