La sicurezza in Windows Azure

La piattaforma Windows Azure e la sua infrastruttura di rete è stata progettata per garantire i più elevati livelli di sicurezza, mitigando i possibili e permettendo un potenziale incremento dei livelli di protezione rispetto ad una infrastruttura on premises.
Le uniche porte aperte ed indirizzabili su una macchina virtuale di Windows Azure sono quelle definite esplicitamente dal file di configurazione del servizio, uploadato con il package dell’applicazione. Inoltre, ogni macchina ha il traffico filtrato dal suo switch, che blocca il traffico non autorizzato, ed è protetta dal Windows Firewall, abilitato per default. Questa configurazione permette di mitigare fortemente la possibilità di ottenere informazioni attraverso port scan e bloccare i tentativi di enumerazione dei servizi.
Eventuali attacchi Denial of Service sono mitigati dai load balancers di Windows Azure. Il continuo monitoraggio permette l’identificazione un eventuale attacco DoS originato dall’interno e l’immediata rimozione dalla rete della macchina virtuale incriminata. Inoltre il Root Host OS, che gestisce le macchine virtuali, non è indirizzabile dall’esterno ne da nessun altro tenant sulla rete di Azure.
Le VLAN utilizzate per partizionare la rete interna sono segmentate in modo da impedire che nodi compromessi possano impersonare altri sistemi o sistemi vitali come il Fabric Controller. L’unico traffico broadcast e multicast permesso sulle VLAN è quello relativo ai meccanismi di funzionamento del DHCP. Le comunicazioni tra il Root Host OS e i Fabric Controller sono particolarmente critiche (vengono trasferite le configurazioni e i certificati) e sono efficacemente protette utilizzando una connessione HTTPS crittografata e utilizzante un meccanismo di mutua autenticazione.
Lo switch virtuale dell’Hypervisor impedisce che una macchina virtuale possa sniffare il traffico relativo ad un’altra macchina sullo stesso host fisico e gli switch dei rack sono utilizzati per limitare gli IP ed i MAC Address utilizzabili, impedendo di fatto lo spoofing. L’unico modo per ascoltare il traffico diretto alle macchine virtuali gestite da un hypervisor è quello di ottenere un accesso amministrativo su una VM, trovare una falla di sicurezza sull’hypervisor tale da permettere un accesso al Root OS e ottenere un account di sistema sulla macchina fisica. Se non impossibile, quantomeno molto improbabile.
Per la mitigazione degli attacchi side channel non si è badato a spese: ogni macchina virtuale ha generalmente una CPU dedicata. Non essendo presenti più CPU logiche su una CPU fisica i pattern di accesso alle cache non sono esposti dai context switch. Le migrazioni di macchine virtuali tra CPU differenti sono ancora possibili, ma talmente rare da non fornire nessuna informazione.
I nodi attualmente hanno coppie di CPU con quattro core indipendenti. Ogni core ha una cache privata e la cache è condivisa al terzo livello. Ciò significa che le cache sono condivise con altre tre CPU. Il bus di memoria, poi, è condiviso con altre sette CPU. Questo livello di condivisione è tale da produrre un livello di rumore sufficiente a rendere impossibile la ricostruzione delle attività attuate dai meccanismi di crittografia.

Questa voce è stata pubblicata in Cloud computing e contrassegnata con , , , , , , , , . Contrassegna il permalink.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...