{"id":7810,"date":"2025-05-07T14:52:20","date_gmt":"2025-05-07T12:52:20","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7810"},"modified":"2025-05-20T18:06:18","modified_gmt":"2025-05-20T16:06:18","slug":"tls-per-le-comunicazioni-interne-in-aws-aws-private-ca-vs-ca-self-managed","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/tls-per-le-comunicazioni-interne-in-aws-aws-private-ca-vs-ca-self-managed\/","title":{"rendered":"TLS per le comunicazioni interne in AWS: AWS Private CA vs CA Self-Managed"},"content":{"rendered":"\n
La prima volta che ho davvero preso coscienza dell’esistenza del protocollo TLS (all’epoca si chiamava ancora SSL) \u00e8 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\u2019”. A quel tempo, persino i siti web pi\u00f9 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.<\/p>\n\n\n\n
Fast forward fino all’universit\u00e0, 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\u00e0:<\/p>\n\n\n\n
\n
Autenticazione<\/strong>: il client \u00e8 sicuro dell’identit\u00e0 del server. Questo impedisce, ad esempio, a un sito web malevolo di impersonare il sito web reale che stiamo cercando di visitare.<\/li>\n\n\n\n
Riservatezza<\/strong>: tutte le informazioni inviate attraverso il canale sono visibili solo agli endpoint. Un attaccante che intercetta con successo il traffico non sar\u00e0 in grado di leggerlo in chiaro. <\/li>\n\n\n\n
Integrit\u00e0<\/strong>: i dati inviati attraverso il canale non possono essere modificati senza che venga rilevato.<\/li>\n<\/ul>\n\n\n\n
Un protocollo piuttosto utile insomma.<\/p>\n\n\n\n
\u00c8 passato un po\u2019 di tempo da quando ero al liceo e ora \u00e8 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Perch\u00e9 TLS non \u00e8 ovunque<\/h2>\n\n\n\n
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\u00e0 di un proxy\/load balancer? Beh, nella maggior parte dei casi \u00e8 accettabile per varie ragioni:<\/p>\n\n\n\n
\n
Le comunicazioni interne sono generalmente considerate sicure<\/strong>: il rischio di intercettazione del traffico tra i componenti di un’infrastruttura cloud \u00e8 considerato molto basso, non a causa dell’impatto (che pu\u00f2 essere pi\u00f9 o meno elevato), ma a causa della bassa probabilit\u00e0 che ci\u00f2 accada.<\/li>\n\n\n\n
Overhead di gestione e costi<\/strong>: gestire un’infrastruttura a chiave pubblica (PKI) \u00e8 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.<\/li>\n\n\n\n
Prestazioni<\/strong>: sebbene l’ultima versione di TLS abbia un overhead prestazionale molto ridotto, potrebbe essere ancora troppo per carichi di lavoro specifici.<\/li>\n<\/ul>\n\n\n\n
La prima motivazione \u00e8 la pi\u00f9 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\u00e0 a questo rischio durante l’analisi dell’impatto sul business. Nella maggior parte dei casi, il rischio \u00e8 percepito come basso e quindi accettato<\/em>. Per le organizzazioni che gestiscono dati altamente sensibili per\u00f2 – 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, \u00e8 un requisito necessario.<\/p>\n\n\n\n
Self-managed o AWS managed?<\/h2>\n\n\n\n
Ora il management ha deciso che ogni connessione deve essere protetta, ogni microservizio deve comunicare solo su HTTPS e chiunque utilizzi plain HTTP sar\u00e0 licenziato seduta stante. Bene. <\/p>\n\n\n\n
Come implementare tutto questo in un ambiente AWS?<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Su AWS ci sono due modi principali per gestire i certificati privati. <\/p>\n\n\n\n
(In realt\u00e0 ne esistono molti di pi\u00f9, ma la maggior parte di essi \u00e8 un po’ “improvvisata” e quindi non adatta per un’organizzazione aziendale).<\/p>\n\n\n\n
CA interna autogestita<\/h2>\n\n\n\n
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\u00f2, il problema principale con la gestione dei certificati \u00e8 mantenerli sicuri. Una CA interna dovrebbe essere pi\u00f9 sicura persino di un domain controller. TLS perde completamente il suo valore se i certificati non vengono gestiti correttamente. \u00c8 una cosa a volte trascurata; siamo abituati a creare una valanga di certificati pubblici tramite Let’s Encrypt, che ci nasconde questa complessit\u00e0, ma dover maneggiare dei certificati richiede molta attenzione.<\/p>\n\n\n\n
Il pericolo principale \u00e8 che, in caso di compromissione della CA, \u00e8 possibile generare certificati validi per qualsiasi servizio dell\u2019organizzazione, distruggendo l’intero modello di sicurezza. Ecco perch\u00e9 l’uso di CA intermedie (che possono essere revocate se compromesse) piuttosto che utilizzare direttamente la CA root \u00e8 considerata una best practice.<\/p>\n\n\n\n
Dal punto di vista finanziario, anche se la generazione di certificati \u00e8 completamente gratuita, il tempo e l\u2019attenzione necessari per gestire una CA interna e i suoi certificati la rendono una scelta costosa. \u00c8 bene ricordare sempre di includere il tempo necessario per la manutenzione durante un’analisi dei costi. Infine, non facciamo finta di niente, \u00e8 anche una questione di responsabilit\u00e0: dover gestire un componente infrastrutturale cos\u00ec critico \u00e8 una bella responsabilit\u00e0.<\/p>\n\n\n\n
AWS Private CA<\/h2>\n\n\n\n
AWS Private CA \u00e8 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\u00e0 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\u00e0 automaticamente i certificati privati creati da AWS Private CA.<\/p>\n\n\n\n
Naturalmente, poich\u00e9 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, \u00e8 possibile installare i certificati ovunque.<\/p>\n\n\n\n
AWS Private CA risolve la maggior parte delle criticit\u00e0 intrinseche di un’infrastruttura PKI autogestita:<\/p>\n\n\n\n
\n
Sicurezza<\/strong>: i certificati sono gestiti da AWS, non \u00e8 pi\u00f9 necessario preoccuparsi della sicurezza delle chiavi private. Questo risolve anche il problema di responsabilit\u00e0 discusso in precedenza.<\/li>\n\n\n\n
Tempo di setup<\/strong>: (esclusa la pianificazione dell’architettura) \u00e8 una questione di pochi click sulla console o poche chiamate API.<\/li>\n\n\n\n
Tempo di manutenzione<\/strong>: i certificati ACM generati tramite AWS Private CA sono idonei al rinnovo gestito.<\/li>\n<\/ul>\n\n\n\n
Sfortunatamente, tutte queste funzionalit\u00e0 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\u00e0 general-purpose. A questo punto \u00e8 necessario ricordare che una buona architettura include una CA root e pi\u00f9 subordinate, quindi sar\u00e0 necessario moltiplicare questo prezzo per ogni CA creata. Anche i certificati non sono gratuiti, il prezzo \u00e8 di $0,75 per ogni certificato emesso al mese, scendendo a $0,35 dopo i primi 1000 e a $0,001 dopo 10000.<\/p>\n\n\n\n
Non \u00e8 sicuramente una scelta economica, ma per il valore che porta a un’azienda, \u00e8 da valutare.<\/p>\n\n\n\n
Ecco una tabella riassuntiva del confronto:<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Implementazione<\/h2>\n\n\n\n
Indipendentemente dalla scelta, l’implementazione \u00e8 molto simile per entrambe le opzioni. L’unica differenza \u00e8 che i certificati creati da una CA autogestita devono essere caricati su ACM per essere utilizzati dalla maggior parte dei servizi AWS. Ci\u00f2 richiede anche che i certificati vengano rinnovati manualmente una volta che si avvicinano alla scadenza.<\/p>\n\n\n\n
Servizi integrati con ACM<\/h4>\n\n\n\n
Per i servizi integrati con ACM, la configurazione del certificato \u00e8 banale. In genere, l’ARN del certificato passato come parametro durante la creazione o l’aggiornamento della risorsa \u00e8 tutto ci\u00f2 che serve per farla funzionare. L’elenco dei servizi supportati include la maggior parte dei servizi rivolti front-facing<\/em>, come Amazon CloudFront, Amazon API Gateway, AWS Elastic Beanstalk ed Elastic Load Balancing, solo per citarne alcuni.<\/p>\n\n\n\n
Altri servizi<\/h4>\n\n\n\n
Ora tratteremo brevemente i servizi di computing pi\u00f9 comuni che potrebbero richiedere l’installazione di una CA privata per utilizzare i nostri endpoint HTTPS.<\/p>\n\n\n\n
EC2<\/h5>\n\n\n\n
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 \u00e8 simile per ogni sistema operativo:<\/p>\n\n\n\n
In sintesi, la procedura richiede di copiare il certificato trust store del sistema operativo. Piuttosto lineare.<\/p>\n\n\n\n
Lambda<\/h5>\n\n\n\n
Con Lambda \u00e8 richiesta un po\u2019 pi\u00f9 di creativit\u00e0. Ci sono diversi modi per farlo:<\/p>\n\n\n\n
\n
Installare la CA privata direttamente all\u2019interno della runtime<\/strong>. Funziona allo stesso modo di EC2; il certificato CA viene aggiunto direttamente al trust store, quindi \u00e8 riconosciuto a livello di sistema. Ecco un esempio (decisamente non ottimizzato, ma facile da leggere) di un Lambda Runtime personalizzata con il certificato installato:<\/li>\n<\/ul>\n\n\n\n
Includere il certificato con il codice<\/strong>. Un’altra opzione \u00e8 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<\/em> di Python:<\/li>\n<\/ul>\n\n\n\n
Scaricare il certificato durante l’esecuzione<\/strong>. Un’alternativa all’inclusione della chiave nel repository. \u00c8 meno efficiente in termini di tempo di esecuzione, ma la memorizzazione nella cache del file tra le chiamate della funzione pu\u00f2 renderla un’alternativa valida.<\/li>\n<\/ul>\n\n\n\n
ECS<\/h5>\n\n\n\n
In questo caso le opzioni sono le stesse di Lambda, ma questa volta, inserire il certificato nel trust store \u00e8 probabilmente pi\u00f9 appropriato poich\u00e9 lo sforzo per creare un “runtime personalizzato” \u00e8 ora un requisito a causa della necessit\u00e0 di scrivere il Dockerfile.<\/p>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n
L’implementazione di TLS anche per le comunicazioni interne sta diventando sempre pi\u00f9 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\u00e0 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\u00f9 gravi in futuro.<\/p>\n\n\n\n
Bonus<\/h2>\n\n\n\n
“E se volessi avere HTTPS ovunque, ma non volessi dover gestire tutto questo?<\/em>“<\/p>\n\n\n\n
Disclaimer<\/strong>: questa soluzione non \u00e8 per Enterprise, forse per piccole imprese o soluzioni temporanee.<\/p>\n\n\n\n
\u00c8 assolutamente possibile utilizzare certificati pubblici (ad esempio quelli rilasciati da Let’s Encrypt) per servizi privati, \u00e8 solo necessario invocare il servizio con il nome di dominio corretto. Per fare ci\u00f2 \u00e8 sufficiente usare un DNS privato o semplicemente creare record pubblici contenenti l’indirizzo privato del servizio da raggiungere. \u00c8 quello che faccio nel mio homelab \ud83d\ude09<\/p>\n\n\n\n
![\"La](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/05\/image2.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/05\/image1.jpg\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/05\/Screenshot-2025-05-07-at-10.58.46.png\")
<\/figure><\/div>\n\n\n