Windows Azure: Gestione degli account di protezione in Windows Azure

Il cloud computing risolve alcuni problemi di protezione, ma gli utenti continuano a svolgere un ruolo attivo nella gestione degli accessi, nella protezione delle comunicazioni e dei dati.

Joshua Hoffman

Il cloud computing rappresenta il mutamento di paradigma più drastico mai sperimentato dal settore IT dall'introduzione di Internet. Larghezza di banda più rapida, spazi di archiviazione più economici e tecnologie di virtualizzazione più che affidabili hanno tramutato il concetto di Software as a Service in realtà. Il cloud offre sistemi scalabili, elastici e in base all'utilizzo, in grado di soddisfare le esigenze di una generazione che pretende il massimo della produttività con il minimo sforzo.

Sebbene il cloud computing risolva gran parte dei problemi relativi alla gestione dell'infrastruttura, la protezione rimane un tema scottante, in quanto richiede comunque lo stesso livello di attenzione di un data center fisico. Man mano che viene eseguita la migrazione di applicazioni e servizi a piattaforme di cloud computing quali Windows Azure, gli utenti continuano a ricoprire un ruolo attivo nella gestione degli accessi, nella protezione delle comunicazioni e dei dati aziendali più importanti.

Esistono diversi approcci consigliati per la gestione della protezione di applicazioni e servizi ospitati in Windows Azure. Sono inoltre disponibili procedure consigliate per la creazione e la gestione di account amministrativi, l'utilizzo di certificati per l'autenticazione e la gestione di transizioni all'inizio o al termine del periodo d'impiego.

Proprietà degli account

Nel portale per i clienti dei Microsoft Online Services è possibile gestire l'amministrazione e la fatturazione di tutti gli account Windows Azure, nonché iscriversi a servizi Windows Azure, aggiungere altri servizi quali SQL Azure e creare nuove istanze di servizi esistenti (abbonamenti).

Gli abbonamenti rappresentano effettivamente il "vincolo di fatturazione" per i servizi Windows Azure. È opportuno gestire per ogni applicazione (o raccolta di applicazioni) abbonamenti separati che richiedono una diversa struttura di fatturazione. È ad esempio possibile creare abbonamenti distinti con dettagli di fatturazione separati in presenza di vari reparti che ospitano applicazioni in Windows Azure, ma richiedono una fatturazione specifica.

Sarà necessario identificare un account di tipo "proprietario" e un account di tipo "amministratore" per ogni abbonamento. Ogni account è associato a un Windows Live ID. Il proprietario è responsabile della gestione dell'abbonamento e della fatturazione attraverso il portale per i clienti dei Microsoft Online Services. L'amministratore è responsabile della gestione degli aspetti tecnici dell'abbonamento, quali la creazione di servizi ospitati, tramite il portale di gestione della piattaforma Windows Azure.

È vivamente consigliato creare account univoci per ogni singolo ruolo. Questi account dovranno esistere indipendentemente dai singoli account. In altre parole, non utilizzare il Windows Live ID personale per il proprietario o l'amministratore del servizio nelle impostazioni basate sull'organizzazione o sul team. Creare piuttosto account univoci (utilizzando ad esempio uno schema di denominazione come AO[ID univoco]@live.com per i proprietari e AA[ID univoco]@live.com per gli amministratori), con password gestibili, e laddove necessario riconfigurabili, a livello centralizzato.

Dopo aver creato un abbonamento, gli amministratori potranno gestire servizi ospitati tramite il portale di gestione della piattaforma Windows Azure, accedendovi tramite le credenziali dell'account dell'amministratore del servizio. Una volta eseguito l'accesso, potranno iniziare a creare un nuovo servizio ospitato (vedere la Figura 1).

Figura 1 Creazione di un nuovo servizio ospitato in Windows Azure

In fase di creazione di un nuovo servizio ospitato, verrà richiesto di specificare un nome e fornire un prefisso URL e le opzioni di distribuzione. Sarà inoltre possibile scegliere un pacchetto preesistente (.cspkg) e un file di configurazione (.cscfg) da un ambiente di sviluppo, ad esempio Visual Studio (se si dispone già di pacchetti di applicazioni).

Nella scheda Servizi ospitati al lato sinistro del portale selezionare Gestione utenti. Da questa posizione è possibile aggiungere altri coamministratori all'abbonamento (vedere la Figura 2) per poter usufruire di maggiore flessibilità grazie alla possibilità di fornire l'accesso all'amministrazione delle applicazioni ospitate.

Figura 2 Aggiunta di nuovi amministratori all'abbonamento

Gestione dei certificati

I certificati rappresentano un componente fondamentale nell'ambito della protezione di Windows Azure. Esistono due tipi di certificati che ricoprono un ruolo essenziale nella protezione di applicazioni o servizi: certificati di servizio e certificati di gestione.

I certificati di servizio sono normali certificati SSL utilizzati per proteggere le comunicazioni endpoint. Gli utenti che ad esempio hanno configurato la protezione SSL per un sito Web in IIS conosceranno sicuramente questo tipo di certificato. I certificati di servizio sono necessari per le distribuzioni di produzione emesse da un'autorità di certificazione radice attendibile. Sarà pertanto fondamentale acquistarli da terze parti, ad esempio VeriSign o DigiCert.

L'elenco di autorità di certificazione radice attendibili viene gestito qui (per Microsoft Windows) e qui (per Microsoft Windows Phone 7). Il nome del certificato SSL deve corrispondere al nome di dominio del sito Web. Sarà dunque necessaria una voce DNS CNAME per eseguire il mapping di yourapp.cloudapp.net (nome di dominio dell'applicazione fornito da Windows Azure) a www.yourcompany.com. Per motivi di sicurezza non è possibile acquistare un certificato con mapping a yourapp.cloudapp.net. Solo Microsoft può emettere certificati per cloudapp.net, ma è possibile creare un certificato autofirmato personalizzato ai fini di sviluppo.

I certificati autofirmati sono destinati esclusivamente ai fini di test, in quanto non verranno ritenuti attendibili dai Web browser degli utenti finali. Come risulterà evidente, in fase di test il browser rileverà il certificato non attendibile oppure le chiamate API effettuate mediante Windows Communications Foundation (WCF) avranno esito negativo. Ciò non significa che il certificato non viene utilizzato, ma semplicemente che non è ritenuto attendibile da un'autorità di certificazione radice. All'interno di un browser, si tratta di una situazione scomoda, seppur accettabile, in fase di test, ma è opportuno evitare questo tipo di esperienza agli utenti finali.

Per eseguire test con chiamate API, è necessario aggiungere codice per eludere la convalida del certificato oppure aggiungere il certificato CA radice del certificato di servizio autofirmato all'archivio certificati delle autorità di certificazione radice attendibili mediante Microsoft Management Console, comandi batch o codice. Ulteriori informazioni sull'argomento sono disponibili nel blog di David Hardin di Microsoft.

I certificati di servizio Windows Azure dovranno essere forniti nel formato Personal Information Exchange (.pfx). Per creare un certificato di servizio autofirmato personalizzato con "password" come segnaposto della password (in base alle esigenze è possibile modificare questa opzione nel comando finale), aprire un prompt dei comandi in Visual Studio ed eseguire il comando seguente:

makecert -r -pe -n "CN=yourapp.cloudapp.net" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sky exchange 
-sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv SSLDevCert.pvk SSLDevCert.cer

del SSLDevCert.pfx

pvk2pfx -pvk SSLDevCert.pvk -spc SSLDevCert.cer -pfx SSLDevCert.pfx -po password

Per caricare certificati di servizio SSL, nella scheda Servizi ospitati del portale di gestione della piattaforma Windows Azure fare clic su Aggiungi certificato e specificare la password (vedere la Figura 3).

Figura 3 Aggiunta di un certificato di servizio in Windows Azure

Anche i certificati di gestione vengono utilizzati da Windows Azure. Gli strumenti di Windows Azure per Microsoft Visual Studio utilizzano certificati di gestione per autenticare gli sviluppatori della distribuzione di Windows Azure. Anche lo strumento da riga di comando CSUpload utilizza i certificati di gestione per distribuire immagini di macchine virtuali, così come le richieste API REST della gestione servizi di Windows Azure.

I cmdlet della gestione servizi di Windows Azure utilizzano i certificati di gestione per Windows PowerShell. È possibile utilizzare i cmdlet PowerShell di Windows Azure per eseguire e automatizzare senza problemi le attività di distribuzione, configurazione e gestione di sistemi basati su Windows Azure.

I certificati di gestione Windows Azure devono essere forniti nel formato X.509 (.cer). Per creare certificati di servizio autofirmati personalizzati, aprire un prompt dei comandi in Visual Studio ed eseguire il comando seguente:

makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss my -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 ManagementApiCert.cer

Caricare i certificati di gestione mediante la piattaforma di gestione di Windows Azure selezionando Certificati di gestione nel riquadro sinistro e quindi facendo clic su Aggiungi certificato (vedere la Figura 4). Per ulteriori informazioni sulla creazione di certificati personalizzati per Windows Azure, consultare l'articolo "Come creare un certificato per un ruolo" in MSDN Library.

Figura 4 Aggiunta di un certificato di gestione in Windows Azure

Transizioni di dipendenti

Uno dei principali vantaggi relativi a una soluzione di cloud computing è costituito dal fatto che è ospitata fuori sede da terzi e fornisce pertanto un livello di ridondanza fisica dalla sede. Se tuttavia un dipendente abbandona un'organizzazione in modo volontario o meno, sarà più difficile limitare l'accesso alle risorse.

È pertanto essenziale seguire alcuni passaggi obbligatori ogni volta che un cambiamento influisce sull'accesso approvato alle risorse di cloud computing. Il primo passaggio consiste nel reimportare le password per qualsiasi account amministratore di servizio a cui il dipendente poteva accedere. Se sono stati creati ID di amministratore di servizio e proprietario di account indipendenti, univoci e gestibili a livello centrale, il processo risulterà più semplice.

Se non è possibile reimpostare la password per l'account dell'amministratore del servizio, è possibile accedere al portale per i clienti dei Microsoft Online Services come proprietario dell'account. Aggiornare l'account elencato come amministratore del servizio. È inoltre opportuno rimuovere qualsiasi account elencato come coamministratore tramite il portale di gestione della piattaforma Windows Azure,

Il secondo passaggio consiste nel riemettere i certificati di gestione pertinenti. Questi certificati rappresentano un metodo di autenticazione per il servizio ospitato tramite le API di Visual Studio e Windows Azure. Pertanto, nel momento in cui un dipendente abbandona l'organizzazione, non sarà più possibile ritenere attendibili questi certificati. Anche se il computer del dipendente rimane all'interno dell'azienda, potrebbe aver eseguito una copia del certificato in altri modi.

Per riemettere certificati di gestione, è sufficiente eseguire nuovamente il comando specificato in alto e rimuovere i certificati di gestione precedenti dal portale di gestione della piattaforma Windows Azure. Caricare i nuovi certificati di gestione e distribuirli a tutti i dipendenti autorizzati. È necessario seguire questa procedura solo per i certificati di gestione, in quanto i certificati di servizio forniscono solo crittografia e non autenticazione.

Sebbene le applicazioni siano ospitate nel cloud, è necessario intervenire in modo proattivo nell'architettura di protezione. Per ulteriori risorse sull'argomento, consultare la pagina Risorse di protezione per Windows Azure in MSDN Library. Seguire queste procedure consigliate per la gestione degli account e dei certificati. In questo modo l'organizzazione potrà sfruttare al meglio i vantaggi del cloud computing, senza compromettere la protezione delle informazioni aziendali più importanti.

Un ringraziamento a David Hardin di Microsoft IT e Daniel Odievich di Microsoft Developer and Platform Evangelism Team, insieme alla partnership di Security Talk Series per l'assistenza fornita nell'ambito della redazione di questo articolo.

Joshua Hoffman* è l'ex caporedattore di TechNet Magazine. Oggi è un autore e consulente indipendente che offre i suoi servizi ai clienti in merito a tecnologie e marketing rivolto a destinatari specifici. Hoffman è inoltre caporedattore di ResearchAccess.com, un sito dedicato alla crescita e all'arricchimento della community coinvolta nella ricerca di mercato. Vive a New York City.*

Contenuto correlato

• Chiarimenti sul cloud computing
• Microsoft, NSF propone Azure per i ricercatori
• Proteggere il cloud computing o farne tranquillamente a meno?