TLS per le comunicazioni interne in AWS: AWS Private CA vs CA Self-Managed

La prima volta che ho davvero preso coscienza dell'esistenza del protocollo TLS (all'epoca si chiamava ancora SSL) è stato al liceo. Un giorno abbiamo scoperto che la nostra scuola aveva installato una rete WiFi in tutto l'edificio e, essendo il ragazzo curioso che ero (e che ancora sono), ho deciso di "giocarci un po’". A quel tempo, persino i siti web più popolari stavano ancora effettuando la transizione da HTTP a HTTPS, quindi, dopo alcune ricerche su Google, ho scoperto che installando alcuni APK di dubbia provenienza sul mio Samsung Galaxy S2, avrei potuto intercettare i dati di altre persone collegate alla rete. Per ragioni legali sono obbligato a dire che non l'ho mai effettivamente fatto.

Fast forward fino all'università, ho finalmente studiato cos'era SSL/TLS e i suoi benefici. Come riportato all'inizio dell'RFC8446 (TLS 1.3), il canale creato dal protocollo TLS fornisce le seguenti proprietà:

• Autenticazione: il client è sicuro dell'identità del server. Questo impedisce, ad esempio, a un sito web malevolo di impersonare il sito web reale che stiamo cercando di visitare.
•  Riservatezza: tutte le informazioni inviate attraverso il canale sono visibili solo agli endpoint. Un attaccante che intercetta con successo il traffico non sarà in grado di leggerlo in chiaro. 
• Integrità: i dati inviati attraverso il canale non possono essere modificati senza che venga rilevato.

Un protocollo piuttosto utile insomma.

È passato un po’ di tempo da quando ero al liceo e ora è folle anche solo pensare di inviare credenziali di accesso o informazioni di pagamento su una connessione HTTP. Addirittura browser moderni ti avvertono con grossi banner rossi se anche solo visiti un sito in HTTP.

Perché TLS non è ovunque

Ormai gli utenti sono abituati a vedere il TLS abilitato su ogni pagina web e potrebbero essere ingannati pensando che ogni connessione che avviene nel mondo sia sicura. Tuttavia, chi lavora dall'altra parte del load balancer sa che TLS non viene neanche minimamente considerato per la maggior parte delle comunicazioni interne. Quindi, questo protocollo dovrebbe smettere di esistere al di là di un proxy/load balancer? Beh, nella maggior parte dei casi è accettabile per varie ragioni:

• Le comunicazioni interne sono generalmente considerate sicure: il rischio di intercettazione del traffico tra i componenti di un'infrastruttura cloud è considerato molto basso, non a causa dell'impatto (che può essere più o meno elevato), ma a causa della bassa probabilità che ciò accada.
• Overhead di gestione e costi: gestire un'infrastruttura a chiave pubblica (PKI) è un lavoro a tempo pieno. Gestire CA, scadenza dei certificati e, soprattutto, gestire in modo sicuro le chiavi private, richiede molto impegno, un impegno che in un'azienda si traduce direttamente in una spesa da giustificare.
• Prestazioni: sebbene l'ultima versione di TLS abbia un overhead prestazionale molto ridotto, potrebbe essere ancora troppo per carichi di lavoro specifici.

La prima motivazione è la più importante. Il rischio percepito e l'atteggiamento nei suoi confronti influenzano fortemente ogni altro aspetto della valutazione preliminare per l'adozione del TLS in una rete interna. Tuttavia, diverse organizzazioni possono assegnare diversi livelli di gravità a questo rischio durante l'analisi dell'impatto sul business. Nella maggior parte dei casi, il rischio è percepito come basso e quindi accettato. Per le organizzazioni che gestiscono dati altamente sensibili però - come banche, compagnie assicurative o organizzazioni sanitarie - l'impatto potrebbe causare la cessazione delle operazioni. In questi casi, l'utilizzo di TLS, anche per i servizi interni, è un requisito necessario.

Self-managed o AWS managed?

Ora il management ha deciso che ogni connessione deve essere protetta, ogni microservizio deve comunicare solo su HTTPS e chiunque utilizzi plain HTTP sarà licenziato seduta stante. Bene.

Come implementare tutto questo in un ambiente AWS?

Su AWS ci sono due modi principali per gestire i certificati privati.

(In realtà ne esistono molti di più, ma la maggior parte di essi è un po' "improvvisata" e quindi non adatta per un'organizzazione aziendale).

CA interna autogestita

Esistono molti progetti commerciali e open source che possono aiutare nella creazione e gestione di una CA privata. Questi tool sono particolarmente utili nella gestione del ciclo di vita dei certificati. Purtroppo però, il problema principale con la gestione dei certificati è mantenerli sicuri. Una CA interna dovrebbe essere più sicura persino di un domain controller. TLS perde completamente il suo valore se i certificati non vengono gestiti correttamente. È una cosa a volte trascurata; siamo abituati a creare una valanga di certificati pubblici tramite Let's Encrypt, che ci nasconde questa complessità, ma dover maneggiare dei certificati richiede molta attenzione.

Il pericolo principale è che, in caso di compromissione della CA, è possibile generare certificati validi per qualsiasi servizio dell’organizzazione, distruggendo l'intero modello di sicurezza. Ecco perché l'uso di CA intermedie (che possono essere revocate se compromesse) piuttosto che utilizzare direttamente la CA root è considerata una best practice.

 Dal punto di vista finanziario, anche se la generazione di certificati è completamente gratuita, il tempo e l’attenzione necessari per gestire una CA interna e i suoi certificati la rendono una scelta costosa. È bene ricordare sempre di includere il tempo necessario per la manutenzione durante un'analisi dei costi. Infine, non facciamo finta di niente, è anche una questione di responsabilità: dover gestire un componente infrastrutturale così critico è una bella responsabilità.

AWS Private CA

AWS Private CA è un servizio AWS che permette la creazione di un'intera gerarchia CA in pochi click. Il vero potere di questo servizio risiede non solo nella facilità di creare CA root e subordinate dalla Console AWS, ma anche nel fatto che sia profondamente integrato con altri servizi. Tutti i certificati vengono creati tramite ACM (AWS Certificate Manager), il che significa che qualsiasi servizio supportato da ACM supporterà automaticamente i certificati privati creati da AWS Private CA.

Naturalmente, poiché AWS Private CA emette certificati X.509, questi certificati possono essere utilizzati anche per altri scopi oltre al TLS. Ad esempio, li abbiamo recentemente utilizzati con IAM Roles Anywhere per l'autenticazione. Inoltre, utilizzando l'API o l'AWS CLI per generare i certificati o esportare un certificato privato da ACM, è possibile installare i certificati ovunque.

AWS Private CA risolve la maggior parte delle criticità intrinseche di un'infrastruttura PKI autogestita:

• Sicurezza: i certificati sono gestiti da AWS, non è più necessario preoccuparsi della sicurezza delle chiavi private. Questo risolve anche il problema di responsabilità discusso in precedenza.
• Tempo di setup: (esclusa la pianificazione dell'architettura) è una questione di pochi click sulla console o poche chiamate API.
• Tempo di manutenzione: i certificati ACM generati tramite AWS Private CA sono idonei al rinnovo gestito.

Sfortunatamente, tutte queste funzionalità hanno un costo. A seconda delle dimensioni dell'organizzazione, i prezzi di AWS Private CA possono essere scoraggianti o accettabili: $400 per CA privata al mese per la modalità general-purpose. A questo punto è necessario ricordare che una buona architettura include una CA root e più subordinate, quindi sarà necessario moltiplicare questo prezzo per ogni CA creata. Anche i certificati non sono gratuiti, il prezzo è di $0,75 per ogni certificato emesso al mese, scendendo a $0,35 dopo i primi 1000 e a $0,001 dopo 10000.

Non è sicuramente una scelta economica, ma per il valore che porta a un'azienda, è da valutare.

Ecco una tabella riassuntiva del confronto:

Implementazione

Indipendentemente dalla scelta, l'implementazione è molto simile per entrambe le opzioni. L'unica differenza è che i certificati creati da una CA autogestita devono essere caricati su ACM per essere utilizzati dalla maggior parte dei servizi AWS. Ciò richiede anche che i certificati vengano rinnovati manualmente una volta che si avvicinano alla scadenza.

Servizi integrati con ACM

Per i servizi integrati con ACM, la configurazione del certificato è banale. In genere, l'ARN del certificato passato come parametro durante la creazione o l'aggiornamento della risorsa è tutto ciò che serve per farla funzionare. L'elenco dei servizi supportati include la maggior parte dei servizi rivolti front-facing, come Amazon CloudFront, Amazon API Gateway, AWS Elastic Beanstalk ed Elastic Load Balancing, solo per citarne alcuni.

Altri servizi

Ora tratteremo brevemente i servizi di computing più comuni che potrebbero richiedere l'installazione di una CA privata per utilizzare i nostri endpoint HTTPS.

EC2

L'installazione di una CA privata in un'istanza EC2 dipende naturalmente dal sistema operativo. Ci sono molti tutorial sul web per ogni OS. Come esempio useremo Ubuntu, ma la procedura è simile per ogni sistema operativo:

sudo apt-get install -y ca-certificates
sudo cp private-ca.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

In sintesi, la procedura richiede di copiare il certificato trust store del sistema operativo. Piuttosto lineare.

Lambda

Con Lambda è richiesta un po’ più di creatività. Ci sono diversi modi per farlo:

• Installare la CA privata direttamente all’interno della runtime.
  Funziona allo stesso modo di EC2; il certificato CA viene aggiunto direttamente al trust store, quindi è riconosciuto a livello di sistema. Ecco un esempio (decisamente non ottimizzato, ma facile da leggere) di un Lambda Runtime personalizzata con il certificato installato:

FROM public.ecr.aws/lambda/python:3.12
RUN dnf install -y ca-certificates 
RUN update-ca-trust force-enable 
COPY certs/* /etc/pki/ca-trust/source/anchors/ 
RUN update-ca-trust extract 
...

• Includere il certificato con il codice.
  Un'altra opzione è includere la chiave pubblica direttamente nel tuo repository e personalizzare le richieste al servizio protetto per farvi riferimento. Ecco un esempio che utilizza la libreria requests di Python:

requests.post(url, data=data, verify='/path/to/public_key.pem')

• Scaricare il certificato durante l'esecuzione.
  Un'alternativa all'inclusione della chiave nel repository. È meno efficiente in termini di tempo di esecuzione, ma la memorizzazione nella cache del file tra le chiamate della funzione può renderla un'alternativa valida.

ECS

In questo caso le opzioni sono le stesse di Lambda, ma questa volta, inserire il certificato nel trust store è probabilmente più appropriato poiché lo sforzo per creare un "runtime personalizzato" è ora un requisito a causa della necessità di scrivere il Dockerfile.

Conclusioni

L'implementazione di TLS anche per le comunicazioni interne sta diventando sempre più necessaria, soprattutto per le organizzazioni che gestiscono dati sensibili. Mentre AWS Private CA offre una soluzione gestita con un'eccellente integrazione dei servizi, il suo costo deve essere valutato rispetto alle esigenze di sicurezza. Le CA self managed sono potenzialmente meno costose, ma richiedono competenza e manutenzione continua. Indipendentemente dalla strada presa, estendere la protezione TLS in tutta la tua infrastruttura aggiunge autenticazione, riservatezza e integrità alle comunicazioni interne. Lo sforzo e il costo necessari possono sembrare scoraggianti inizialmente, ma i benefici per la sicurezza la rendono una strada che vale la pena percorrere. Investire nella prevenzione oggi significa evitare conseguenze ben più gravi in futuro.

Bonus

"E se volessi avere HTTPS ovunque, ma non volessi dover gestire tutto questo?"

Disclaimer: questa soluzione non è per Enterprise, forse per piccole imprese o soluzioni temporanee.

È assolutamente possibile utilizzare certificati pubblici (ad esempio quelli rilasciati da Let's Encrypt) per servizi privati, è solo necessario  invocare il servizio con il nome di dominio corretto. Per fare ciò è sufficiente usare un DNS privato o semplicemente creare record pubblici contenenti l'indirizzo privato del servizio da raggiungere. È quello che faccio nel mio homelab ;)

About Proud2beCloud

Proud2beCloud è il blog di beSharp, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione più all'avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!