Nel 2021 Amazon S3 ha raggiunto i 15 anni di “onorato lavoro”. Durante questo periodo di tempo, più di 100 trilioni di oggetti sono statimemorizzati in S3 a livello globale.
Una buona parte di questi contiene dati sensibili e , nonostante il fortissimo impegno di AWS nell’applicare il principio di “security is job zero” , l'esposizione di tali informazioni è ancora un problema ampiamente diffuso.
In questo articolo mostreremo come abbiamo combinato due servizi AWS per condividere migliaia di fatture private in modo completamente sicuro, scalabile e automatizzato.
Il caso d’uso
Un noto e-commerce ha bisogno di condividere le fatture di acquisto dei propri clienti via e-mail. Attraverso il suo sistema di fatturazione, i file vengono generati e memorizzati automaticamente su S3 e devono essere disponibili per il download per almeno dieci anni.
Un modo molto comune ed errato di soddisfare questo requisito è quello di rendere gli oggetti contenuti nei bucket S3 accessibili pubblicamente. In questo caso, purtroppo, tutte le fatture private potrebbero essere facilmente fruibili da chiunque abbia una connessione Internet e una buona conoscenza informatica.
Un approccio più corretto, invece, è quello di sfruttare una particolare funzionalità di S3 chiamata presigned URL. Questa funzione consente di scaricare file privati incorporando le credenziali di accesso all’oggetto nell'URL di download. Visitando il link, l’oggetto viene scaricato senza alcuna necessità di inserire credenziali o fare login.
Questo approccio, però, ha un limite: la durata massima delle credenziali Signature Version 4 incorporate nei presigned URL di S3 è di 7 giorni . Questo problema rende impossibile utilizzarli in questo caso d'uso. Infatti, come detto prima, gli URL di download delle fatture devono essere validi per un periodo temporale ben maggiore dei 7 giorni consentiti.
Fortunatamente, AWS ci viene in soccorso con un'altra soluzione sicura e altrettanto performante.
I Signed URL di Cloudfront
Per raggiungere l’obiettivo, questa soluzione prevede che si aggiunga un ulteriore servizio AWS: Amazon Cloudfront. Oltre al miglioramento delle prestazioni fornito dalle edge location di Cloudfront, esso consente opzioni di sicurezza avanzate che il servizio di object storage, da solo, non permette nativamente.
L'integrazione tra i due servizi dà vita a funzionalità di sicurezza come l’Origin Access Control (OAC), o il più legacy Origin Access Identity (OAI), e i Signed URL di Cloudfront.
Configurato correttamente, il primo assicura che gli oggetti non vengano mai scaricati direttamente da S3. Infatti, per non incorrere in bollette AWS elevate, è meglio non consentire l'invio di un numero imprevedibile di richieste direttamente a questo servizio. Il secondo,invece, è la chiave di volta dell'intera infrastruttura. Come vedremo, i meccanismi di firma dei Signed URL di Cloudfront sono molto diversi da quelli utilizzati nei presigned URL di S3.
Da quanto detto prima, i presigned URL di S3, per garantire l’accesso a oggetti privati, contengono credenziali temporanee con una validità massima di una settimana. I Signed URL di Cloudfront, invece, consentono una scadenza quasi infinita permessa dal particolare valore contenuto nella signature.
È importante sapere che, per generare un Signed URL di Cloudfront, è necessario creare una coppia di chiavi (chiamata Key Group) e caricare la chiave pubblica sulla console di Cloudfront.
Il valore della signature viene calcolato crittografando, con la chiave privata appena generata, una IAM Policy . Al momento del download di un file da parte di un utente, questa policy IAM viene decrittografata da Cloudfront per verificare che il chiamante abbia i permessi di scaricare quel determinato oggetto. In questo modo, come per i presigned URL di S3, non è necessario effettuare alcuna login per accedere alla propria fattura, ma avviene tutto in maniera automatica.
Per rendere tutto più chiaro, ecco un esempio di come potrebbe apparire la policy IAM prima di essere crittografata:
È possibile controllare ulteriormente le autorizzazioni incluse nella firma utilizzando una policy custom.
L'architettura completa
Per riassumere quanto detto, abbiamo bisogno di costruire un'infrastruttura che, su richiesta del sistema di fatturazione, generi un URL di download sicuro e con una lunga scadenza.
Come si può vedere dallo schema, una funzione lambda (Sign URL function) e un secret di Secrets Manager sono apparsi nel disegno infrastrutturale. Il compito della lambda consiste nel generare i Signed URL di Cloudfront utilizzando la chiave privata memorizzata nel segreto.
Quando il sistema di fatturazione memorizza una nuova fattura nel Bucket S3, esso richiama anche la lambda per generare il Signed URL da inviare al cliente via e-mail e permettergli la visione del file.
Per lo sviluppo della funzione lambda, abbiamo deciso di utilizzare Python per il suo basso cold start e la comoda classe CloudFrontSigner integrata nel Software Development Kit(SDK) di AWS Boto3.
Seguendo questo link si può trovare una versione semplificata del codice Python che abbiamo sviluppato per questa soluzione. Come si può notare, il codice è completamente configurabile grazie a delle variabili d’ambiente che possono soddisfare diverse esigenze infrastrutturali.
| CF_BASE_URL | Il base url della distribuzione Cloudfront (ad esempio invoices.myecommerce.net) |
| CF_PRIVATE_KEY | Il nome del segreto contenente la chiave privata |
| CF_KEY_ID | L'ID della chiave pubblica caricata su Cloudfront (ad esempio K734GLTZE4PRT) |
| YEARS_VALID | Il numero di anni per i quali gli URL firmati saranno validi. Utilizzato per calcolare la data specificata nella condizione della policy IAM "DateLessThan" |
Osservazioni
Come si nota, tutti i servizi utilizzati nell'architettura sono gestiti da Amazon Web Services. Per questo motivo, non è necessario prendersi carico della gestione della scalabilità e di altre problematiche.
In particolare, l'adozione di servizi totalmente serverless, consente idealmente una scalabilità infinita dell'intero sistema. Allo stesso tempo poi, il modello di pagamento modulato sulla base dell’utilizzo delle risorse permette di mantenere i costi infrastrutturali di sistemi come questo molto bassi.
Vuoi saperne di più? Contattaci!
Fonte: https://doordash.engineering/2021/12/14/building-authenticated-access-to-s3
