Incrementare la sicurezza automatizzando la gestione dei sistemi: le strategie possibili

È ormai noto ai più che il quadro normativo europeo auspichi per la pubblica amministrazione un approccio Cloud-first e SaaS-first, incoraggiando una gestione dei servizi, e quindi delle risorse digitali, secondo il modello del cloud. Per un decennio la cosiddetta “digital transformation”, spinta anche dai vendor ha cercato di consentire la gestione di un numero di risorse sempre più elevato attraverso l’automazione che le astrazioni del cloud consentono.

Ecco che strumenti di gestione automatica di private cloud si sono diffusi negli anni, da Microsoft System Center a VMware vCloud Foundation, passando per Nutanix Acropolis solo per citarne alcuni. I colossi del cloud globale hanno poi cominciato a spingere per avere un “pezzettino” di public cloud eseguito presso il datacenter di un’organizzazione come Amazon AWS Outpost o Microsoft Azure Stack.

Anche il mondo “open” non è stato fermo e sono numerose le soluzioni basate su OpenStack per automatizzare la gestione delle risorse in accordo al modello di riferimento del cloud che è ormai condiviso da tutti, anche se con le dovute differenze.

Successivamente, a rendere più movimentato il panorama, sono arrivati i container e Kubernetes, strumenti per rendere ancora più dinamica l’allocazione delle risorse, e l’automazione ha permeato tutti gli aspetti della gestione del datacenter secondo un approccio Software-Defined applicato dapprima alle reti (SDN), poi allo storage (SDS) e infine all’intero datacenter (SDDC).

È naturale, quindi, chiedersi come mai la maggior parte dei vecchi datacenter sia privati che di pubbliche amministrazioni sono ancora scarsamente automatizzati con macchine virtuali create manualmente, rigorosamente una diversa dall’altra, e gestite largamente attraverso strumenti relativamente di basso livello che organizzano le risorse di un cluster.

Eppure, l’automazione svolge un ruolo essenziale per la gestione dei processi che sottendono agli aspetti di sicurezza, senza una struttura regolare è difficile, se non impossibile, aggiornare i sistemi e monitorare l’accesso alle risorse in modo da avere sistemi che espongano il minor numero possibile di falle e la cui politica di sicurezza possa essere realmente ispezionabile.

La sicurezza come conformità adattiva dei container cloud-native: il giusto approccio

La giungla dei sistemi di automazione

Siamo ormai tutti abituati che quando una particolare tecnologia diviene popolare affrontando un bisogno concreto, emergono numerose soluzioni che competono e tra cui spesso si sente di dover fare una scelta che condizionerà il futuro dell’IT dell’organizzazione.

Nel mondo dell’automazione, purtroppo, non vi sono strumenti software che competono per semplificare i processi, ma anche livelli differenti di gestione delle risorse che hanno reso necessario lo sviluppo dell’orchestratore.

Le risorse per semplificare i processi

A livello di infrastruttura esistono numerosi software per installare server automaticamente, spesso promossi dai vendor dell’hardware come parte dell’automazione della gestione, in particolare l’aggiornamento automatico dei firmware dei server.

A livello applicativo non si possono non menzionare strumenti come Ansible, Chef automate o Puppet che sono stati pionieri nel definire il funzionamento di sistemi che, data una descrizione del servizio, provvede al deployment in modo che sia ripetibile.

Più recentemente si è aggiunto anche Terraform, progetto più orientato alla gestione multi-cloud dei servizi ma che consente, con l’ausilio di progetti esterni, di “terraformare” un sistema bare-metal installando il sistema operativo.

I software cloud offrono una pletora di orchestratori, spesso con interfaccia grafica, da utilizzare per automatizzare compiti di gestione dell’infrastruttura.

Vi sono, infine, le shell del sistema operativo che da sempre consento l’automazione di gestione sia di singoli sistemi operativi che, attraverso meccanismi di autenticazione di rete e comunicazione sicura, più sistemi.

In questa giungla di strumenti che spesso non si sovrappongono nelle funzioni e che sono spesso Turing-equivalenti (ovvero ci si possono scrivere interi software) è oggettivamente arduo orientarsi e quindi fare una scelta consapevole. Questo fa sì che spesso gli strumenti vengano selezionati per passione del tecnico di turno che, istintivamente, sente il bisogno di affermare la superiorità della sua scelta nel diminuire tutte le altre soluzioni; ma, se come troppo spesso accade, i tecnici a scegliere sono due è facile rapidamente trovarsi ad affrontare guerre di religione all’interno dello staff.

Volendo affrontare in modo più pragmatico la questione è naturale che si usino più di questi strumenti, anche perché l’automazione si basa sul coordinamento di risorse spesso sviluppate con tecnologie differenti e con la necessità di agenti che “adattino” un particolare software al sistema di automazione e che devono essere disponibili (e possibilmente affidabili e robusti) per consentirne il coordinamento.

Va detto che spesso gli “agenti” sono sviluppando usando script di shell di un particolare sistema operativo che seguono particolari convenzioni di codifica per poter essere invocati automaticamente.

PowerShell: una shell di coordinamento e open source

Adattare un software, magari legacy, ad uno dei vari sistemi di automazione richiede facilmente lo sviluppo di script di shell. La tradizione di composizionalità delle shell Unix ruota attorno alla nozione di processo: una shell Unix consente di lanciare processi e concatenarne i canali di input, output, ed errore per costruire comandi più complessi.

Questo paradigma è stato dominante per decadi facendo sistematicamente sentire inadeguati gli utenti dei sistemi Windows che avevano a disposizione prima il command.com e poi il cmd.exe due prompt dei comandi decisamente inadeguati rispetto alla controparte Unix.

Molti hanno sempre pensato che la colpa fosse di questi programmi (per carità la sintassi dei file batch di Windows è oggettivamente orribile), ma in realtà il problema risiede nel fatto che Windows adotta un modello di composizione non basato sul coordinamento di processi bensì sull’aggregazione di oggetti binari.

Nel 2007 Microsoft comincia a lavorare ad una shell per cercare di costruirsi una reputazione anche su un elemento ritenuto sempre più importante nella gestione dei sistemi: PowerShell. Il progetto viene realizzato costruendo sulla piattaforma .NET, piattaforma centrale per Microsoft sin dal 2001 e che si è evoluta nel corso di vent’anni fino a divenire interamente open source con la versione 5.0. La stessa sorte è toccata a PowerShell che è disponibile nella versione “core”, open source e multipiattaforma.

Gli aspetti caratterizzanti di PowerShell

L’approccio di PowerShell al coordinamento fonde l’approccio Unix con quello Windows: i comandi PowerShell (cmdlet) possono essere composti ma ciascuno restituisce un flusso di oggetti che possono essere acceduti per campi e analizzati. Qualora si esegua un processo allora si analizzeranno le linee di input/output del processo come se fossero oggetti della shell.

Un aspetto caratterizzante di questa piattaforma è quello di consentire l’accesso a tutte le librerie della piattaforma di programmazione .NET, rendendo virtualmente possibile programmare qualsiasi funzione in un ambiente più simile a quello di programmazione.

Questo approccio rende più semplice consumare web services e API Rest, rendendo la shell molto efficace nel coordinamento di micro-servizi. Allo stesso tempo se si devono coordinare applicazioni sviluppate in .NET (cosa molto comune in ambito industriale), è possibile gestire queste applicazioni in modo naturale poiché basate sullo stesso runtime, magari in una versione più vecchia.

Non posso dire di essere stato un fan della prima ora di PowerShell, fui consultato durante il design poiché avevo sviluppato nel 2000 una shell JavaScript per Windows chiamata ObjShell che presentai ai laboratori di Microsoft Research a Cambridge (UK). La sintassi sembrava un po’ scimmiottare quella delle shell Unix anche in ambiti dove non se ne sentiva il bisogno, inoltre la prima versione violava un principio cardine delle shell Unix: uno script PowerShell non era un Cmdlet mentre uno script di Shell Unix è un comando. Come spesso accade le limitazioni tecniche sono state superate col tempo, e mi sono trovato sempre più spesso ad usare questa shell interattiva per aggregare sistemi e trasformare dati.

Il divenire multipiattaforma e open ha reso la shell decisamente più attraente e oggi sempre più spesso mi trovo a coordinare i sistemi che sviluppo usando PowerShell su tutte le piattaforme su cui gira (incluso Raspberry PI).

Uno script esemplificativo dell’uso di PowerShell

A titolo di esempio ho sviluppato il seguente script per verificare la data di scadenza dei certificati TLS dei Web Server che manuteniamo: TLS Certificate test in powershell core, disponibile su GitHub.

Il semplice script sfrutta la possibilità di usare le librerie .NET per leggere le proprietà del certificato Web di un sito. Il codice definisce un nuovo cmdlet chiamato Test-WebServerCertificate (nome che segue la convenzione raccomandata da Powershell per consentire a chi la usa ad orientarsi tra migliaia di cmdlet diversi). Se ad esempio vogliamo verificare quali certificati di sicurezza sono in scadenza possiamo definire un array di nomi di siti:

Poiché un array è una sequenza di oggetti, li possiamo facilmente scorrere utilizzando l’operatore pipe (il simbolo ‘|’) per vedere le proprietà dei certificati per ciascun sito:

Infine, possiamo facilmente scoprire quelli che scadranno nei prossimi 10 mesi filtrando i campi usando il cmdlet where (alias per Where-Object):

Questa capacità di powershell di mantenere la struttura dei dati rende semplice l’accesso e la fruizione di OpenData. Ad esempio possiamo accedere al sito ustat del Ministero per l’Università e la ricerca e consultare i dati relativi al personale docente delle università Italiane scaricando i dati in formato CSV nel file temp.csv:

Una volta ottenuti i dati si possono facilmente leggere e visualizzare:

Possiamo quindi facilmente calcolare il numero di docenti con una semplice linea:

Infine, possiamo raggruppare il dato per area geografica:

Esistono numerosi moduli disponibili che consentono l’interazione con vari sistemi, tra questi sicuramente uno che usiamo spesso è il modulo SimplySql che consente di interrogare database e successivamente svolgere azioni sulla base dei risultati dell’interrogazione.

La natura duplice di PowerShell di ambiente di scripting, e ambiente di coordinamento di codice compilato con .NET, rende possibile scrivere efficacemente adattatori per molti software legacy che abitano le nostre infrastrutture, consentendo una più facile integrazione con i sistemi di automazione di propria scelta.

Automatizzare per rendere i sistemi più sicuri

L’automazione, oltre ad essere necessaria per poter sviluppare nuovi servizi riducendo lo sforzo per mantenere in esercizio i servizi esistenti, gioca un ruolo importantissimo nel panorama della sicurezza.

Configurare gli accessi alla rete piuttosto che ai file è un lavoro sempre più mastodontico, e automatizzare l’assegnazione dei permessi, magari usando i dati presenti in sistemi delle organizzazioni è un passo centrale per rendere più difficile la vita ad eventuali attaccanti. Inoltre, la rapida estensione di sistemi di automazione e monitoraggio è un aspetto chiave per produrre quella rappresentazione sempre più necessaria sullo stato dei sistemi alla ricerca di punti dove intervenire.

È il caso, ad esempio, dello script che verifica la scadenza dei certificati Web, sviluppato perché lo sforzo necessario a pianificare l’aggiornamento era divenuto sostanziale e scarsamente sostenibile.

Imparare a gestire i sistemi con la riga di comando porta nuovamente all’attenzione il tema delle competenze: soprattutto nella pubblica amministrazione la maggior parte dei sistemisti amministra i sistemi usando le interfacce grafiche, riducendo quindi l’abilità di automatizzare e aprendo il fianco a potenziali vulnerabilità introdotte da configurazioni ripetute manualmente con i tempi degli uomini, decisamente inadeguati nella scala temporale di macchine che attaccano altre macchine.