Nella progettazione di infrastrutture cloud-based riveste un ruolo di fondamentale importanza la sicurezza dei dati e dell’accesso alle macchine virtuali che elaborano ed ospitano i servizi attraverso cui questi dati vengono resi disponibili all’esterno.

I clienti che si rivolgono a un consulente o a un fornitore esterno per l’implementazione di un’architettura cloud si aspettano infatti che il livello di sicurezza garantito sia pari o superiore rispetto a soluzioni on premises e, se da un lato è molto difficile acquisire la fiducia di un cliente nel momento in cui deve giungere alla scelta di esternalizzare la gestione dei dati a una soluzione cloud, dall’altro è molto facile perdere la fiducia faticosamente guadagnata nel tempo qualora dovesse insorgere un problema di sicurezza nell’accesso ai dati.

La procedura descritta in questo articolo è verticalizzata su AWS e istanze EC2, però i concetti introdotti hanno valenza generale e le operazioni descritte possono essere facilmente replicate su altri ambienti di virtualizzazione.

Il concetto di strong authentication

Nell’ambito del Digital Identity Management, l’autenticazione è il meccanismo di verifica che associa una o più identità digitali a un’entità del mondo reale. Al fine di attribuire l’identità all’ente che asserisce di esserne titolare e garantire così il corretto accesso ai sistemi digitali, l’autenticazione si basa su una serie di elementi in grado di caratterizzare il soggetto.

I fattori che permettono di stabilire in maniera univoca l’identità di un individuo sono di diversa natura, ma vengono tradizionalmente ricondotti a tre categorie fondamentali:

  • conoscenze (ciò che si sa), ad esempio una password, una pass-phrase o un PIN riservati;
  • attributi accidentali (ciò che si ha), ovvero la disponibilità di un oggetto fisico come i token utilizzati comunemente per l’accesso a servizi di home banking;
  • attributi essenziali (ciò che si è), ad esempio i dati biometrici inalterabili.

Un meccanismo che combina due o più tra i fattori sopraelencati è definito autenticazione multifattore (MFA, acronimo di multifactor authentication) o strong authentication. Ad esempio, l’accesso ad un sistema che prevede l’inserimento di una coppia di credenziali note all’utente — ciò che si sa — cui fa seguito l’inserimento di un codice inviato al dispositivo mobile personale — ciò che si ha — è un meccanismo di autenticazione multifattore. In generale, quando un meccanismo coinvolge n elementi si parla di “autenticazione a n fattori”, per cui il meccanismo illustrato è un esempio di autenticazione a due fattori (two-factor authentication o TFA).

In questo specifico esempio, il codice utilizzato come secondo fattore di autenticazione comporta due vantaggi: in primo luogo viene reso disponibile su un dispositivo di cui solo il soggetto è in possesso — lo smartphone personale — e in secondo luogo ha una validità limitata nel tempo, riducendo in modo drastico la vulnerabilità cui sarebbe esposto il sistema qualora il codice entrasse in possesso di soggetti terzi. L’utilizzo di password temporanee usa-e-getta, meglio note come OTP (one-time password) è molto frequente come fattore di autenticazione aggiuntivo.

Autenticazione e istanze EC2

Nel caso delle istanze di macchine virtuali EC2, l’accesso degli utenti avviene tipicamente attraverso una connessione sicura basata sul protocollo SSH, che comporta l’inserimento di una coppia di credenziali (nome utente e password) o un meccanismo a chiave asimmetrica per cui l’autenticità dell’utente è data dal nome utente e da una chiave privata, la cui validità viene verificata con la chiave pubblica presente sulla macchina.

I dati relativi alla coppia di chiavi (che comprendono la chiave privata) sono resi disponibili tramite un certificato digitale in formato PEM generato nel corso della procedura di creazione della macchina virtuale, che può essere scaricato in locale.

Entrambi gli approcci descritti, tuttavia, non sono esenti da potenziali falle di sicurezza. Da una parte, l’utilizzo di nome utente e password può essere vulnerabile ad attacchi di tipo brute force, cui invece il meccanismo basato sulla chiave privata sarebbe immune. In quest’ultimo caso, però, la conservazione del certificato entro i termini di riservatezza è interamente responsabilità dell’utente finale e potrebbe essere condivisa accidentalmente con terzi o ceduta contro la volontà del soggetto.

Essendo inoltre tali meccanismi di autenticazione basati su un solo fattore, una volta superata la prima challenge un potenziale attaccante è in grado di accedere al sistema senza ulteriori ostacoli.

Per questi motivi è auspicabile introdurre un meccanismo di autenticazione a due fattori in cui oltre a nome utente e certificato, o nome utente e password, l’accesso all’istanza EC2 è subordinato anche all’utilizzo di una OTP come elemento aggiuntivo, legato a un dispositivo esterno in possesso dell’utente.

MFA su Amazon Web Services

Esistono diversi sistemi per integrare l’autenticazione multifattore nel meccanismo di accesso alle istanze EC2, utilizzando strumenti software di terze parti, alcuni open source non commerciali (ad es. Google Authenticator) altri a pagamento (ad es. Duo Security o LoginTC).

Un esempio pratico: Google Authenticator

Google Authenticator consente di ottenere una TFA per uno o più utenti e, nello specifico, implica l’utilizzo di una password temporanea basata sulla variabile tempo (time-based one-time password, o TOTP) secondo quanto specificato nello standard informale RFC6238. In quanto TOTP, la rotazione della password è assicurata dal fatto che l’algoritmo condiviso tra client e server per la generazione delle credenziali temporanee prevede l’utilizzo di un timestamp.

Installando Google Authenticator su una macchina EC2 viene generata una chiave segreta da condividere con un dispositivo dell’utente, come lo smartphone personale. Una volta in possesso della chiave segreta condivisa (il modo più veloce è la scansione di un QR code), il dispositivo sarà in grado di generare periodicamente a intervalli di 30 secondi codici temporanei ripetibili e verificabili lato server.

Trattandosi di uno standard aperto, per la generazione di TOTP è possibile utilizzare l’applicazione mobile di Google Authenticator o una qualsiasi altra app compatibile con la specifica RFC6238.

La procedura descritta nella sezione successiva fa riferimento a una macchina EC2 su cui è installata una distribuzione Ubuntu Server “Trusty Tahr” (14.04.3 LTS).

Installazione

Per prima cosa è necessario installare il modulo PAM di autenticazione specifico per Google Authenticator con il comando:

$ sudo apt-get install libpam-google-authenticator

a questo punto è sufficiente invocare il comando:

$ google-authenticator
Do you want authentication tokens to be time-based (y/n) y

confermare nel prompt (come illustrato) quando viene richiesto se le password temporanee debbano essere basate su tempo, limitando così la validità delle password temporanee (o token) a slot temporali di 30s. È inoltre necessario rispondere ad una serie di ulteriori domande che permettono di configurare opzioni di sicurezza aggiuntive, ad esempio:

  • limitare nel tempo il numero di accesso con lo stesso token (es. 1 solo login ogni 30s);
  • incrementare la durata di validità del token agli slot temporali adiacenti (precedente e successivo) per tollerare eventuali discrepanze di sincronizzazione tra server e client;
  • limitare il numero di accessi consentiti in un dato arco di tempo (es. max 3 accessi ogni 30s).

La procedura genererà un QR code che viene reso disponibile a un determinato URL, ad esempio:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/ubuntu@ip-172-31-38-216%3Fsecret%1234567890QWERTYUI

che dovrà essere utilizzato dall’applicazione mobile (client) per acquisire la chiave segreta e avviare la generazione dei token TOTP.

Attivazione del modulo PAM

Il passo successivo lato server è l’integrazione di Google Authenticator in PAM, il sistema di autenticazione modulare utilizzato di default nelle macchine Linux per i login e gli accessi via SSH all’istanza EC2, intervenendo sui file di configurazione di sistema.

Per prima cosa, è necessario modificare /etc/pam.d/sshd aggiungendo la riga:

auth required pam_google_authenticator.so

e modificare /etc/ssh/sshd_config facendo in modo che la riga relativa alla ChallengeResponseAuthentication contenga:

ChallengeResponseAuthentication yes

Infine, occorre riavviare il demone SSH in modo da applicare la nuova configurazione con il comando:

$ sudo service ssh restart

A partire da questo momento, all’accesso da parte degli utenti non sarà più richiesta la sola password ma anche il codice di verifica temporaneo visibile dal dispositivo mobile.

NB: La procedura descritta sopra permette di applicare la MFA solo agli utenti che accedono con username e password, ma non si applica invece agli utenti che utilizzano il certificato PEM. Tale sistema di autenticazione è comunque sconsigliato perché presuppone la distribuzione di un certificato digitale e di una chiave privata, che è maggiormente a rischio di essere resa pubblica, alterata o rubata.

Setup del dispositivo mobile

Una volta installata l’applicazione Google Authenticator su Android o iOS è sufficiente selezionare l’opzione per l’aggiunta di una nuova chiave e scansionare il QR code disponibile all’URL fornito dal server in fase di installazione.

Conclusioni

L’introduzione della MFA nelle politiche di accesso alle istanze EC2 permette ai progettisti di infrastrutture cloud di incrementare il livello di sicurezza delle proprie architetture, superando i limiti di un approccio tradizionale basato su una password statica o su un certificato in possesso dell’utente.

L’autenticazione multifattore inoltre, come si è visto, non sostituisce le consuete politiche di sicurezza ma può essere utilizzata come un livello aggiuntivo integrandosi con le strategie esistenti. Nell’ambito delle architetture AWS, ad esempio, in cui la prassi prevede la creazione di sottoreti in cui solo il Bastion Host espone pubblicamente la porta 22 e le restanti macchine virtuali sono accessibili solo dal Bastion Host, la MFA può essere utilizzata per controllare l’accesso al Bastion Host dall’esterno e incrementare così la sicurezza generale dell’architettura.

Come curiosità storica, le radici dell’idea di valutare l’autenticità dell’identità di un individuo sulla base di un fattore aggiuntivo esterno al soggetto stesso, come il possesso di qualcosa, risalgono all’antica Grecia.

A seguito di un accordo tra famiglie o città era infatti usanza spezzare in due un anello o una tessera di terracotta lasciando in custodia a ciascuna delle parti una delle due metà. Per evitare le frodi e garantire l’identità degli emissari della controparte era quindi sufficiente verificare che il simbolo in possesso del soggetto combaciasse con la propria metà, portando così a termine il “processo di autenticazione”. L’usanza è stata portata avanti dai Romani con le tesserae hospitales e una traccia di tale pratica sopravvive ancor oggi proprio nella parola “simbolo”, dal greco symbolon (σύμβολον), la cui etimologia rimanda al verbo symballo (συμβάλλω) che letteralmente significa appunto “rimettere insieme”.

 

Leave a Comment