Author: Davide Maccarrone
Gli Storage Account sono l’offerta Azure PaaS di storage multipurpose per l’archiviazione di dati. Per loro natura sono esposti pubblicamente tramite FQDN e raggiungibili da internet. Utilizzando recenti funzionalità come i VNet Service Endpoint è possibile applicare regole di firewalling agli Storage Account per consentire l’accesso solamente a specifici range di indirizzi IP (pubblici e privati), ma la natura dell’endpoint resta un FQDN.
Negli scenari in cui le politiche aziendali impediscano che un applicativo comunichi con un BLOB Storage Account risolvendo il nome pubblico o passando per internet, è possibile fornire un accesso con IP privato con una specifica soluzione architetturale:
La soluzione prevede l’utilizzo di un Application Gateway e di una (o più) Virtual Machine configurata come Reverse Proxy per ruotare le richieste verso lo Storage Account. Il Reverse Proxy viene configurato utilizzando il ruolo IIS e i componenti aggiuntivi di URL Rewrite e Application Request Routing.
https://www.microsoft.com/en-us/download/details.aspx?id=47333
https://www.microsoft.com/en-us/download/details.aspx?id=47337
Ad alto livello, le richieste client arrivano contro l’ip privato dell’Application Gateway, che le ruota contro il Reverse Proxy, che a sua volta le ruota contro lo Storage Account. Il Reverse Proxy fa da middleware e consente di utilizzare esclusivamente blob\container con access level “Private”.
La configurazione del Reverse Proxy è come segue:
In particolare, è necessario utilizzare una regex per intercettare le chiamate corrette, ad esempio:
^(?!.*health_awrfsx)(.*)
Questa regex ignora tutte le richieste che contengono “health_awrfsx” e quindi non ne fa URL rewrite. Ciò è necessario per non intercettare anche le Probe requests che andremo a configurare nell’Application Gateway.
“health_awrfsx” sarà anche una cartella sotto la root di IIS che conterrà un file da monitorare:
Il file health.txt può essere vuoto o contenere qualsiasi stringa, ne verrà fatta una semplice HTTP GET da parte della custom probe dell’App GW.
Il nome della cartella è ovviamente a piacere, il suffisso “_awrfsx” è randomico e serve a limitare la possibilità che venga confusa con una chiamata da reindirizzare.
L’Application Gateway è configurato come segue:
- Listener agganciato a Frontend IP privato
- Backend Pool composto dalla VM che ospita il Reverse Proxy
- Custom Probe che fa HTTP GET del file health.txt nel path creato sulla VM Reverse Proxy
- Regola che associa i componenti di cui sopra
NB: l’esempio è in http, ovviamente il Listener potrebbe essere in HTTPS con opportuno certificato
Lo stato del Backend è monitorabile dalla blade “Backend Health” dell’Application Gateway:
Il risultato è che i BLOB sono accessibili con un IP privato:
Esempio con BLOB contenuto in un Container con Access Policy “public”
Esempio con BLOB contenuto in un Container con Access Policy “private” e SAS Token emesso sul singolo BLOB
In ambienti di Produzione è ovviamente opportuno ridondare il Reverse Proxy Windows utilizzando un Load Balancer ed un Availability Set, oltre a configurare la catena di SSL per non esporre nulla in chiaro.
In particolare il primo punto comporta dei costi aggiuntivi sotto forma di due o più Virtual Machines.
Una soluzione meno costosa ma meno stringente dal punto di vista della sicurezza consiste nel non utilizzare i Reverse Proxies ma di configurare uno specifico Container\BLOB nello Storage Account con ACL “public” di modo da fare il probing direttamente su un BLOB creato ad-hoc, per poi chiudere il vero traffico pubblico con un VNet Service Endpoint. In alternativa, si può utilizzare un Container\BLOB con ACL “private”, generare una SAS Policy specifica e utilizzare per il probing del Reverse Proxy il token SAS hardcoded nel path.