Introduzione
Periodicamente l’industria IT scopre delle parole chiave che diventano imprescindibili. Senza di esse nessuna trattativa è legittimata, nessun discorso è completo, nessuna conferenza è importante. A volte si tratta di temi che così come sono nati, muoiono. Altre volte, quando l’attenzione dei guru del marketing si sposta altrove, rimangono risultati tangibili che permettono un miglioramento di quella strana e fallace industria chiamata ICT. Da diversi mesi a questa parte la parola chiave è “governance”. Un sostantivo rubato ad altri contesti, lo si trova applicato alla direzione di uno stato o di un’azienda, spesso con implicazioni legate alla finanza. Basta fare una ricerca sui dizionari per trovare definizioni del tipo “Il complesso delle strutture, delle regole e delle strategie che presiedono alla guida di un’azienda, o anche di uno Stato” Hoepli, oppure “autorità di governo, effettivamente in grado di gestire la direzione politica e amministrativa di uno stato | l’insieme delle procedure e dei principi che consentono la gestione di un’azienda, di un’istituzione ecc.” Garzanti.
Declinare dunque governance per un sistema ICT significa definire, porre in essere e verificare in continuo tutte quelle norme che lo rendano:
- Supportabile da tutti i gruppi ICT aziendali tramite un insieme di politiche condivise
- Con costi predicibili
- Conforme alle normative vigenti
- Sicuro secondo le linee guida definite dalla sicurezza aziendale a qualsiasi livello, non necessariamente tecnico
Genesi
è evidente a tutti che qualche forma di norma scritta o almeno di consuetudine per la gestione del proprio sistema informatico è già oggi presente in tutti i sistemi informativi aziendali. Ciò che oggi manca, nella grande maggioranza dei casi, è la formalizzazione di queste politiche e, non meno importante, il controllo delle stesse. L’uso del termine governance non a caso richiama il rigore, la formalizzazione e la verificabilità (non insisterò mai abbastanza su questo) proprie di altri ambiti aziendali. Dalla consapevolezza della necessità di una governance strutturata e dalla presa di coscienza della mancanza della stessa, nasce la forte esigenza di governance per il proprio sistema ICT. Perché oggi questa consapevolezza è così diffusa, quali sono le cause di questo “nuovo bisogno”? Tre importanti cambiamenti hanno preso forza nell’ultimo lustro, la loro maturità odierna all’interno di qualsiasi sistema ICT li rende trainanti nell’adozione di una governance ICT:
- La cloud pubblica
- La sicurezza informatica, sempre più tallone di Achille di un mondo interconnesso
- L’allargamento del bacino di soggetti che sono interessati dalle varie legislazioni in merito alla protezione e gestione del dato, nonché alla necessità di continuità di servizio
Tutti questi aspetti meriterebbero considerazioni approfondite per studiare come contribuiscano alla necessità di governance e come sia possibile inserirli in una practice di governance ICT complessiva. In questo articolo mi soffermerò sul fattore cloud pubblica, forse il fattore a prima vista meno evidente.
La cloud pubblica
Perché sostengo che l’adozione delle cloud pubblica ha guidato l’esigenza di governance ICT? Le caratteristiche stesse della cloud: dinamicità, flessibilità, self service determinano questa esigenza. Lo spostamento dei dati e dei servizi sulla cloud pubblica, con le sue caratteristiche di dinamicità e rapidità di provisioning di nuove risorse e quindi con una predisposizione al cambiamento di diversi fattori più rapida rispetto al mondo on premises,, rende la definizione della governance ancora più importante che non in un ambiente privato. Non solo, la semplicità di delega e un modello di costi legato al consumo, espone l’azienda ad un rischio di perdita di controllo sugli stessi. Si tratta quindi non solo di un tema legato alla supportability dell’ambiente ICT realizzato, ma anche di una possibile esposizione finanziaria non prevedibile se non governata.
Come è possibile declinare la governance di un sistema ICT? Una buona base di partenza consiste nel prendere in esame e definire politiche per il governo di:
- processi e procedure che siano allineati agli obiettivi aziendali. Ad esempio come classificare i dati ed i servizi in base alla rilevanza aziendale, quali di essi, in base alla classificazione debbano essere implementati in alta disponibilità o per quali sia necessario un processo di disaster recovery.
- Uno standard di naming per tutti gli artifacts
- Integrazione degli standard di sicurezza aziendali e verifica continua della conformità agli stessi
- Come effettuare monitoring e alerting, come gestire gli incident
- Un modello comune per il controllo dei costi
- Un modello comune per la delega amministrativa
Il processo di definizione della governance è per forza di cose iterativo e progressivo, voler indirizzare immediatamente tutti i punti rischia di procrastinare troppo nel tempo l’adozione degli opportuni standard. È bene definire all’interno delle proprie politiche come indirizzare l’esistente non compliant, ad esempio può essere difficile ricondurre artifacts esistenti ad una differente naming convention. È bene dunque darsi degli step intermedi prioritizzando i temi da affrontare e considerando come gestire l’esistente.
Governance in Azure
Una volta definite le proprie linee guide di governance o se vogliamo le politiche per la governance del sistema ICT è necessario dotarsi degli strumenti che, come minimo, possano individuare gli scostamenti da queste policy. L’ottimo è dotarsi di strumenti che oltre alla verifica continua della compliance, possano anche forzare le politiche definite. Di fronte all’articolazione dell’argomento ci si potrebbe far prendere dallo scoramento, anche applicando il principio del divide et impera, potrebbe essere difficile iniziare con un foglio bianco.
Ogni provider di cloud pubblica ha il proprio approccio, in questo articolo affronteremo come Microsoft Azure affronta il tema governance, in un prossimo articolo approfondiremo come la stessa cosa sia indirizzata di Amazon AWS.
Azure ci aiuta sia con un set di policy (di seguito cosa sono) predefinite, sia tramite il servizio gratuito Azure Advisor che riporta consigli su come migliorare complessivamente le nostre implementazioni su Azure. Quindi niente paura, il viaggio non sarà breve, ma come cercheremo di illustrare di seguito, gli aiuti non mancheranno.
La base che permette, in Microsoft Azure, il controllo e l’enforcement delle politiche di governance si chiama, con poca fantasia, ma in modo molto chiaro, Azure Policy. Tramite le Policy posso specificare una naming convention o definire quali risorse possono essere create o ancora impostare livelli minimi di sicurezza che tutte le risorse target devono implementare. Le policy possono essere organizzate in gruppi chiamati Initiative e possono essere di solo audit oppure mandatory o bloccanti.
Il secondo concetto chiave è il target cui applicare le policy, Azure ha infatti una gerarchia di gestione che permette, se è necessario, una estrema granularità. Proviamo a mettere ordine in termini quali Tenant, Subscription, Resource Group e Management Group.
L’accesso a risorse Azure è possibile tramite identità contenute in un Azure Active Directory Tenant (Tenant). Azure AD regola le politiche di sicurezza sugli account e permette attivare funzioni avanzate quali meccanismi di multi factor authentication (MFA) e accesso condizionale.
Ogni risorsa Azure è contenuta in una Azure Subscription (subscription). La subscription ha le seguenti caratteristiche:
- È associata ad un tenant (e solo ad un tenant) che indica quali identità possono essere utilizzate per la delega amministrativa
- Definisce un primo contenitore gerarchico di delega amministrativa, tutte le risorse della subscription ereditano i permessi impostati a questo livello
- Definisce delle quote di risorse utilizzabili
- Funziona da segregazione logica delle risorse, a meno di configurazioni specifiche, le risorse di una subscription “non vedono” risorse in altre subscription
- È la prima unità di raggruppamento per il tracking dei costi Azure
Le risorse Azure facenti parte di una subscription sono contenute in Resource Group. I resource group sono contenitori di risorse a fini amministrativi con le seguenti caratteristiche:
- facilitano la delega amministrativa, le risorse contenute ereditano i permessi a livello di resource group
- facilitano la gestione dei tag, ovvero di quelle coppie chiave/valore che permettono di aggiungere metadati alle risorse Azure.
- Costituiscono un possibile raggruppamento per la rendicontazione dei costi
Laddove siano presenti più subscription o si voglia separare l’ambito operativo, da quello di governance è possibile introdurre i Management Groups.
Le policy possono essere applicate (assegnate) a livello di Subscription o Management Group e possono essere definite eccezioni per Resource Group. I management group permettono di applicare politiche e configurazioni alle risorse contenute in subscription diverse in modo centralizzato, purchè le stesse facciano parte del medesimo tenant. In presenza di più tenant, tutte le policy di interesse dovranno essere replicate manualmente per ogni tenant. I management group si prestano per essere organizzati a loro volta in gerarchie per facilitare l’applicazione di differenti set di policy e ai fini di delega amministrativa.
L’appartenenza ad un tenant è un elemento fortemente vincolante, infatti:
- il cambio di tenant di una subscription comporta l’azzeramento di tutti i permessi associati alle risorse
- Le risorse possono essere spostate liberamente tra resource group della stessa subscription e la maggior parte delle risorse possono essere spostate tra subscription del medesimo tenant. Le risorse però non possono essere spostate tra subscription di tenant diversi.
- I management group esistono all’interno di un tenant e non possono gestire subscription di tenant diversi
Ogni pratica di governance si basa anche su standardizzazione e conformità. Standardizzazione e conformità significa essere in grado di ripetere le medesime azioni nello stesso modo e verificare che questo sia effettivamente avvenuto in tutti i casi. Questa non è sicuramente una caratteristica in cui gli umani eccellono. Gli Azure ARM template sono lo strumento per rendere ripetibili e standardizzati i deployment e la configurazione degli artifacts su Azure. Si tratta di documenti in formato json che descrivono l’ambiente da realizzare, possono essere parametrizzati e ulteriormente completati tramite linguaggi di scripting disponibili su qualsiasi piattaforma. Tutti i deployment su Azure dovrebbero essere fatti tramite automazione e ARM template e non dal portale per garantire ripetibilità e standardizzazione.
In ultimo, per chi si trova a dover gestire ambienti particolarmente dinamici e con attività ripetitive o per chi debba gestire tenant multipli vengono in aiuto gli Azure Blueprint. Anche in questo caso il nome non lascia adito a dubbi, un blueprint è l’insieme degli artifacts, della loro configurazione, delle policy e della sicurezza che li governano tutto in un unico documento. Il blueprint può essere applicato a livello di Subscription e come tale può creare e configurare tutti (o quasi) gli artifacts che fanno parte di una subscription.
Un esempio
Ora che tutti i giocatori sono sul campo, la domanda è con quale schema farli giocare. Quali sono le best practices in merito? Come è possibile iniziare? Partendo dal presupposto che deve essere stato pensato un primo livello di formalizzazione delle policy, un possibile approccio per Azure può essere il seguente:
- Cercare di mantenere un unico tenant a meno di progetti speciali con elevata necessità di isolamento
- Creare una subscription per ogni progetto significativo in modo da facilitare la segregazione e il billing
- Creare due livelli di management groups, associando al management group root di default le policy irrinunciabili, ad esempio quelle di security. In assenza di requisiti di business specifici, dividere tramite management group e subscription gli ambienti di produzione da quelli “test and dev”.
- Organizzare le policy in “initiative” e assegnarle solo a livello di management group
In conclusione
Il lettore attento avrà notato che Policy, Management group, Blueprint e ARM template indirizzano solo parte degli strumenti per implementare una completa governance ICT. Non ho toccato il tema del monitor indirizzato da Azure Monitor, dell’enforcing di policy di sicurezza e di ritorno rispetto alla compliance alle normative gestito da Azure Security Center e così via. Ci sarà tempo e modo di affrontare anche questi aspetti, per il momento è importante iniziare a pensare alla governance del proprio sistema ICT e iniziare a familiarizzare con gli strumenti specifici per la gestione delle governance di Microsoft Azure.