L’identità è il nuovo perimetro

La lezione precedente ha tracciato una linea tra ciò che un provider cloud protegge e ciò che deve proteggere il cliente. Dal lato del cliente, un elemento fa più lavoro di ogni altro: l’identità — chi è autorizzato ad accedere, e cosa può fare una volta dentro. Una rete d’ufficio tradizionale aveva un muro e una porta chiusa a chiave; un account cloud ha un modulo di accesso, raggiungibile da qualsiasi parte del mondo, a qualsiasi ora. Proteggere quell’accesso è in pratica la maggior parte di cosa significa “sicurezza nel cloud”.

Come vengono davvero rubati gli account

La compromissione di un account raramente comporta che un aggressore violi i sistemi di un provider cloud. Segue tipicamente lo schema del furto di credenziali visto nel corso sulla modellazione delle minacce di questa università: una password riutilizzata da un servizio violato e non correlato, o una pagina di phishing convincente che chiede semplicemente l’accesso direttamente. Una volta che un aggressore ha credenziali valide, la maggior parte dei servizi cloud non ha modo di distinguerle da quelle del vero proprietario dell’account — ed è esattamente per questo che il singolo controllo che CISA evidenzia sopra ogni altro è l’autenticazione a più fattori (MFA).

L’MFA, e perché non tutte le forme sono uguali

CISA afferma chiaramente che “gli utenti che attivano l’MFA hanno molte meno probabilità di essere violati”, perché una password rubata da sola smette di essere sufficiente. Ma CISA classifica anche le forme disponibili di MFA in base alla loro resistenza al phishing, e questa classifica conta: “l’unica autenticazione ampiamente disponibile resistente al phishing è l’autenticazione FIDO/WebAuthn” — lo standard alla base delle passkey e delle chiavi di sicurezza hardware, trattato nel corso di crittografia. Un codice via SMS è, nelle parole di CISA, comunque molto meglio di nessun secondo fattore, ma può essere intercettato o inoltrato da un aggressore sufficientemente motivato; le notifiche push basate su app con corrispondenza numerica si collocano nel mezzo. Per un account cloud che contiene qualcosa di sensibile, attivare l’opzione MFA più forte offerta da quell’account è il singolo passo dal valore più alto in questa lezione.

OAuth: i permessi che concedi ad altre app

Ogni volta che fai clic su “continua con Google” o colleghi uno strumento di pianificazione al tuo calendario, stai usando OAuth, descritto dalla documentazione stessa dello standard come “il protocollo standard del settore per l’autorizzazione”. La sua proprietà utile è che l’app di terze parti non vede mai la tua password — accedi direttamente con il tuo provider, poi approvi un insieme specifico e limitato di permessi, chiamati scope, per quell’app. Il suo rischio è esattamente quella concessione di permessi: un’app di pianificazione che ha bisogno solo di leggere gli orari liberi/occupati del tuo calendario può chiedere, e ottenere di routine, il permesso di leggere e inviare email a tuo nome. Ogni app collegata è una concessione permanente di accesso che persiste finché qualcuno non la revoca, ed è per questo che l’ultima lezione di questo corso tratta la revisione di quell’elenco, non solo la sua configurazione corretta una volta sola.

Chiavi trapelate: la cugina meno visibile di OAuth

Strumenti automatizzati e integrazioni spesso si autenticano con una chiave API anziché con un accesso umano — una lunga stringa che funziona come una password ma non viene digitata da una persona e spesso non è protetta dall’MFA. Queste chiavi finiscono esposte più spesso di quanto la maggior parte delle persone si aspetti: incollate in un ticket di supporto, inviate per errore a un repository di codice, lasciate in un file di configurazione condiviso più ampiamente del previsto. Trattare una chiave API con la stessa cautela di una password — non condividerla mai in chiaro, ruotarla se potrebbe essere stata esposta, e limitare cosa può fare — chiude una lacuna che l’MFA, pensata per gli accessi umani, non copre.