Gestire la 2FA di un account AWS condiviso

Nessuno dovrebbe accedere ad AWS con un identificativo condiviso. L’accesso quotidiano spetta a identità per persona tramite IAM Identity Center, e l’automazione spetta a ruoli piuttosto che a qualsiasi cosa un umano digiti.

Resta l’utente root, che è davvero un identificativo unico per account. Ciò che è utile sapere è che non dovete condividere nemmeno il suo secondo fattore: AWS permette di registrare più dispositivi MFA sull’utente root, quindi due o tre amministratori possono iscrivere ciascuno il proprio. Copiare un segreto TOTP è un ripiego per i casi in cui questo non è possibile, non la scelta predefinita.

Tre identificativi diversi

«Il nostro account AWS» di solito significa una di queste tre cose, e hanno risposte diverse.

L’utente root. Uno per account, identificato da un indirizzo email, capace di fare tutto, compreso chiudere l’account e cambiare la fatturazione. Non fatto per il lavoro quotidiano.

Le identità per persona. Utenti di IAM Identity Center, o utenti IAM nelle configurazioni più vecchie. È lì che il lavoro si fa davvero, ed è lì che ognuno ha il proprio secondo fattore.

Le chiavi di accesso. Credenziali a lunga durata per l’accesso programmatico. Non è un accesso interattivo, non è protetto dalla MFA come la gente suppone, ed è ciò che si ritrova più spesso in un vecchio repository.

La maggior parte delle domande sulla «2FA AWS condivisa» riguarda in realtà il primo, e nasce perché gli altri due non sono mai stati messi in piedi.

Lavoro quotidiano: identità per persona

IAM Identity Center dà a ciascuno il proprio accesso, la propria MFA, e credenziali a durata limitata sugli account e i ruoli a cui ha diritto. L’accesso è concesso per assegnazione invece che consegnando qualcosa, e togliere qualcuno è un’azione in un solo posto, qualunque sia il numero di account AWS che gestite.

Se siete ancora su utenti IAM, il minimo è un utente per persona, ciascuno con il proprio dispositivo MFA, e nessun utente condiviso per la squadra. Un utente IAM condiviso ha tutti i problemi di un utente root condiviso senza nessuna delle sue ragioni d’essere.

Per un’agenzia che lavora nell’account di un cliente, l’equivalente di «invitatemi» è un ruolo tra account: il cliente mantiene la proprietà e può revocarlo in un solo posto, e nessuno manda credenziali via email.

Automazione: ruoli, non accessi

Tutto ciò che gira senza sorveglianza dovrebbe assumere un ruolo invece di accedere. Su AWS stesso, questo significa profili di istanza, ruoli di task o una federazione OIDC dal vostro fornitore di CI. Sono credenziali a durata limitata, senza segreto da conservare e senza nulla che un umano debba digitare.

Se uno script chiede a qualcuno un codice a sei cifre, sta usando l’identità di un umano, e si romperà il giorno in cui quell’umano se ne andrà.

Le chiavi di accesso a lunga durata sono l’altra metà del tema. Sono revocabili e rinnovabili singolarmente, il che è un vero vantaggio rispetto a un segreto TOTP, ma sono anche le credenziali che finiscono nei commit. Tenetene poche e ruotatele secondo un calendario che rispettate davvero.

L’utente root: il vero account condiviso

La root esiste, più persone devono poterla raggiungere, e non deve dipendere dal telefono di una sola persona.

Registrate più di un dispositivo MFA

È la risposta propria di AWS, ed elimina interamente la questione della condivisione. Iscrivete l’app o la chiave hardware di ogni amministratore che deve poter agire da root. Ogni dispositivo detiene il proprio segreto, e nessun segreto viene mai copiato. Un’uscita è la rimozione della registrazione di un dispositivo, non la reimpostazione della 2FA dell’account e la reiscrizione di tutti.

Dove una chiave hardware è praticabile, è qui che vale il suo prezzo: il secondo fattore non può essere né fotografato, né trasferito, né sincronizzato.

Puntate l’email root a una casella che due persone possono leggere

Il recupero della root passa da quell’indirizzo. La casella personale di un fondatore rende l’account irrecuperabile il giorno in cui non c’è più: usate una lista di distribuzione o una casella condivisa, e assicuratevi che chi la può leggere siano persone a cui affidereste il recupero dell’account, perché funzionalmente è ciò che quell’indirizzo concede.

Cancellate le chiavi di accesso root

Non dovrebbero essercene. Se esistono, sono credenziali condivise senza alcuna MFA davanti, il che è peggio di tutto il resto di questo articolo.

Sorvegliate gli accessi root

CloudTrail li registra, e un allarme sull’uso della root è pratica corrente. Su un account sano, gli accessi root sono rari e spiegabili, il che li rende economici da sorvegliare e preziosi da vedere.

Quando un segreto TOTP condiviso resta la risposta

I dispositivi MFA multipli coprono la maggior parte dei casi. Alcuni resistono:

• L’account di un cliente che non amministrate, dove vi consegnano credenziali senza che possiate ristrutturare nulla.
• Console vecchie o di terze parti attorno ad AWS (un portale di fatturazione, un pannello da rivenditore, un fornitore di monitoraggio) che accettano esattamente un’iscrizione TOTP.
• Un identificativo di emergenza che la vostra procedura esige che più persone possano usare in fretta, dove i dispositivi individuali non sono praticabili.

Per quelli, i requisiti sono quelli di qualsiasi account condiviso: una custodia unica del segreto, un accesso ai codici concesso per persona, un registro di chi ha letto un codice, e codici di recupero conservati fuori dall’account che recuperano. Il ragionamento è in come condividere codici 2FA in squadra in sicurezza, e il confronto dei meccanismi nei modi migliori per gestire la 2FA di un account condiviso. Lo stesso ragionamento applicato a un fornitore di pagamenti è in gestire la 2FA di un account Stripe condiviso.

Una procedura di emergenza che merita di essere scritta

Per la root, e per tutto ciò che serve solo in caso di emergenza:

1. Chi può usarla, per nome, e che cosa la innesca.
2. Dove vivono l’identificativo e il suo secondo fattore, e quante persone possono raggiungere ciascuno.
3. Dove sono i codici di recupero, fuori dall’account che recuperano.
4. Che cosa fa scattare un avviso all’uso, cioè l’allarme CloudTrail di cui sopra.
5. Che cosa succede dopo: chi viene avvisato, che cosa viene rivisto, che cosa viene eventualmente rinnovato.
6. Quando è stata provata l’ultima volta. Una procedura mai provata sarà scoperta la sera in cui qualcuno ne ha bisogno.

Quando qualcuno lascia un account AWS

1. Togliete le sue assegnazioni Identity Center o cancellate il suo utente IAM.
2. Disattivate e cancellate le sue chiavi di accesso, comprese quelle usate dai suoi strumenti.
3. Rimuovete la registrazione del suo dispositivo MFA root, se ne aveva uno.
4. Se ha mai detenuto un segreto TOTP condiviso, reimpostate quella 2FA e cambiate la password associata. Il segreto non lascia il suo telefono da solo.
5. Verificate se può ancora leggere l’indirizzo email root.
6. Rileggete CloudTrail attorno alla sua uscita, in cerca dell’inatteso.

Il passaggio 5 è quello che si dimentica. Accedere alla casella root è accedere all’account root, qualunque cosa abbiate revocato altrove.

Dove si colloca Share Auth

In modo stretto, e deliberato. Per gli account della sezione qui sopra, cioè la console di un cliente, un pannello di terze parti che accetta una sola iscrizione, o un identificativo di emergenza: il segreto è inserito una volta e cifrato a riposo, le persone che hanno bisogno dei codici vedono il codice e il suo conto alla rovescia invece del segreto, i permessi sono per membro, e ogni consultazione è registrata.

Per un utente root AWS che amministrate voi, registrare un secondo dispositivo MFA vale più di qualunque cosa una cassaforte possa fare, la nostra compresa. Fate prima quello.