Questa è la prima parte della mia panoramica di IaC basata su un esperimento personale: la creazione di una Cyber range utilizzando il paradigma di IaC. Ecco la seconda e la terza parte.

Durante le mie sessioni su Twitch, sono solito offrire un laboratorio pratico ai partecipanti. I miei laboratori vengono creati automaticamente su AWS, utilizzando Terraform e Ansible.

Scenario

Il mio scenario è piuttosto semplice: devo creare un insieme di VM all’interno di AWS e configurarle con alcuni software e servizi aggiuntivi. Queste VM espongono alcuni servizi vulnerabili che possono essere sfruttati e difesi dai partecipanti.

Prima di iniziare la sessione su Twitch, ho avviato manualmente Terraform e Ansible per creare e configurare le VM. Per essere specifici, uso:

• Terraform, per creare le VM su AWS;
• Terraform, per creare il gateway VPN da client a sito;
• OpenVPN per connettersi al lato interno del laboratorio;
• Ansible, tramite OpenVPN, per configurare le VM.

Il processo di creazione richiede meno di 10 minuti.

Piano e standardizzazione

IaC è 80% pianificazione e standardizzazione. Significa che dobbiamo identificare i requisiti, gli scenari e i casi limite. Poi dobbiamo identificare come definiamo la nostra infrastruttura (mi riferisco a questa fase come “modellazione”), e infine dovremmo scrivere dei prototipi per verificare la nostra idea e approccio.

Nel mio caso, devo creare scenari di Cyber range che possono includere più VM:

• con vari sistemi operativi e applicazioni;
• collegati a reti diverse;
• eventualmente protetti da apparecchiature aggiuntive (firewall).

Tutte le VM devono essere accessibili da un host specifico per configurarle.

Ultimo requisito: tutti gli scenari dovrebbero essere completamente creati da zero e distrutti dopo la sessione. Non sono previsti dati permanenti.

Nel mio caso ho deciso di:

• scrivere un modulo Terraform personalizzato per creare l’infrastruttura di base (accesso a Internet, reti di base, gateway VPN da client a sito o host bastion);
• definire manualmente i componenti aggiuntivi (VM aggiuntive, reti e come sono collegate);
• configurare ciascuna VM utilizzando dei ruoli (è possibile configurare più ruoli all’interno della stessa VM).

Creazione dell’infrastruttura

Lo scenario più basilare richiede la creazione di un host bastion e almeno una VM Linux Ubuntu. La documentazione di Terraform è piuttosto esplicativa e non ci sono problemi al riguardo.

Il mio unico suggerimento è: pianificare attentamente ciò di cui hai bisogno ora e a breve termine, e essere pronti ad adattarsi.

Nel mio caso, ho deciso di utilizzare i tag per tracciare il sistema operativo, le applicazioni installate, lo scopo e gli utenti amministrativi… Questi tag saranno utili in Ansible.

Configurazione dell’infrastruttura

Qui arrivano i problemi: Terraform e Ansible sono due universi diversi e devo farli comunicare. Utilizzando AWS e pianificando attentamente la mia infrastruttura, ho trovato l’inventario AWS EC2 di Ansible piuttosto buono, anche se ha alcune limitazioni.

In breve:

• Terraform crea l’infrastruttura applicando i tag;
• L’inventario AWS EC2 di Ansible recupera le istanze AWS EC2 e prepara un inventario compatibile con Ansible, mantenendo i tag;
• Dopo aver stabilito la connessione OpenVPN, Ansible può configurare le VM interne.

L’inventario AWS EC2 di Ansible risolve tutte le VM interne con l’indirizzo IP privato:

plugin: aws_ec2
regions:
  - eu-central-1
filters:
  instance-state-name: running
keyed_groups:
  - key: tags
    prefix: tag
hostnames:
  - tag:Name
compose:
  ansible_host: private_ip_address

A questo punto, abbiamo un ottimo modo per costruire e configurare l’infrastruttura, indipendentemente dal fatto che le VM siano raggiungibili da Internet o meno. L’unico effetto collaterale è che le connessioni VPN da client a sito impattano molto sul mio account AWS.

Altro (certificati)

L’approccio sopra richiede la creazione e la gestione di una CA (Certification Authority):

• Il concentratore da client a sito di AWS richiede un certificato del server;
• I client VPN hanno bisogno del certificato pubblico CA per convalidare il certificato del concentratore;
• I client VPN hanno bisogno di un certificato valido per essere accettati dal concentratore VPN;
• Il concentratore da client a sito di AWS ha bisogno del certificato pubblico CA per convalidare i certificati client;
• I server aggiuntivi (ad esempio i server web) potrebbero avere bisogno di certificati validi.

Anche se le documentazioni di AWS e Terraform sono molto buone, questa attività mi ha costato ore per trovare l’approccio giusto.

Conclusioni

Come ho scritto prima, IaC è 80% pianificazione e standardizzazione. Parlando delle imprese, non c’è un “approccio standard”, tutto dovrebbe essere progettato attorno a un contesto specifico, con particolari esigenze. In uno scenario del mondo reale, sono coinvolte molte squadre: operazioni (ovviamente), consumatori (ad esempio, sviluppatori), audit e conformità, e sicurezza… IaC richiede un “approccio olistico”, le squadre non possono adottare un approccio IaC senza coinvolgere le parti interessate. Andare da soli significa fallire: limitazioni, costi elevati e moltissime eccezioni non pianificate…