Dal 2004: Nessun compromesso

Gestione out-of-band su ogni macchina

Ogni server che gestiamo è un vero server enterprise con un vero controller lights-out: iDRAC Enterprise con licenza Datacenter su Dell, iLO Advanced su HPE, entrambi pilotati via Redfish, e ogni chassis blade attraverso il suo Onboard Administrator. Non una scheda madre white box la cui idea di gestione remota è un pulsante di accensione e nessuna console.

Sugli chassis blade l'Onboard Administrator raggiunge ogni controller dell'enclosure attraverso il backplane, ed è esso stesso una coppia ridondata con failover automatico.

In pratica. Quando un rack di chassis blade ha avuto bisogno della licenza iLO Advanced, e di un account di gestione creato su ogni blade, non abbiamo fatto login su un singolo blade. L'abbiamo spinto attraverso l'Onboard Administrator di ciascuno chassis e il rack era finito in pochi minuti, compresi i blade montati quella settimana che non avevano ancora credenziali proprie. È un runbook.

La rete di gestione non è la rete di produzione

Il controller ha la propria porta fisica e il proprio cavo verso il proprio switching. Non partizioniamo una scheda di rete di produzione lasciando che il controller ne prenda in prestito una fetta, che è la scorciatoia abituale e il motivo abituale per cui la gestione finisce a un errore dall'internet. La gestione vive sui propri switch, o su proprie VLAN su fabric che non trasportano nient'altro, in spazio di indirizzi privato che non è instradato da o verso alcuna rete di un cliente e non è mai annunciato a internet.

Lo chiamiamo air gap perché è così che si comporta. Una macchina virtuale di un cliente, anche completamente compromessa, che scansiona a velocità di linea per una settimana, non può vedere affatto un iLO o un iDRAC. Non rifiutato, non filtrato: assente. Non c'è nessun posto in cui i pacchetti possano andare. Vale anche nell'altra direzione, e conta altrettanto: nessun traffico di gestione viaggia su una VLAN di un cliente, così le nostre sessioni di console, il monitoraggio e i backup non entrano mai nel dominio di broadcast di un cliente né competono per la sua banda. L'isolamento è abbastanza reale da essere scomodo per noi, ed è questa la prova che è reale: un controller su una VLAN di gestione non può raggiungere con disinvoltura un web server interno per scaricare un'immagine firmware, perché nulla è permesso che non sia stato richiesto e messo per iscritto. L'ingegnere fa il passo in più.

I backup viaggiano allo stesso modo. Vengono presi sulla rete out-of-band, mai attraverso un segmento di produzione.

In pratica. Un'unica access list di gestione canonica è applicata su ogni piattaforma che gestiamo, sulle linee di login dei Cisco Nexus, per istanza di routing sui router, per interfaccia per SSH e HTTPS sui firewall, permettendo solo le subnet di gestione nominate, con il control plane policing che limita in hardware tutto ciò che resta.

Il piano di gestione in sé

Il piano di gestione è una rete a pieno titolo e l'abbiamo costruito come tale. Gira sulla nostra dorsale cifrata multi-sede: Cisco DMVPN, IPsec a AES-256, BGP trasportato sui tunnel, che unisce Atene, Amsterdam e Toronto alla nostra sede centrale a Cipro, che per scelta non si trova in nessuno degli edifici che gestisce. Gli hub sono ridondati, con percorsi equal-cost tra di essi e su circuiti diversi, e un rilevamento dei guasti che si accorge di un percorso morto in ben meno di un secondo.

Il personale lo raggiunge in un solo modo: attraverso gateway VPN e firewall che possediamo e gestiamo noi stessi, su OPNsense e Cisco Firepower, e poi attraverso jump host dentro il piano anziché direttamente dal laptop di un ingegnere. Livelli di fiducia diversi non condividono mai un oggetto del firewall, così allargare l'accesso di un gruppo non può allargare silenziosamente quello di un altro.

Verso i piani di backup e di disaster recovery la politica è deny by default e i dati scorrono in una sola direzione. La produzione non spinge mai verso il backup. È il lato backup a prelevare. Questo è imposto con regole di deny esplicite sulle appliance firewall, non con un firewall host che una macchina compromessa potrebbe modificare, e i segmenti di backup non hanno alcuna rotta verso internet. Solo l'intervallo di gestione li raggiunge. Se una macchina di produzione viene presa completamente, l'attaccante non ottiene alcuna conoscenza dell'infrastruttura di backup e nessun percorso verso di essa. Da dove si trova, non esiste.

Le modifiche alla dorsale sono verificate dal vivo sul sistema in esecuzione, una metà di una coppia ridondata alla volta, ed è per questo che possiamo lavorare sulla dorsale nel mezzo di una giornata lavorativa.

In pratica. Abbiamo spostato l'intero parco VPN site-to-site di un cliente da un paese a un altro in una sola sessione, prima di una scadenza fissa. L'hub è stato clonato, trasferito e acceso in parallelo con l'originale, così entrambi erano attivi nello stesso momento e c'era sempre un posto in cui i tunnel potessero stare. I router delle filiali sono stati spostati uno alla volta, ciascuno verificato attivo prima di toccare il successivo, ciascuno con un failover pulito lungo il percorso. Nessuno ha viaggiato verso una filiale.

La baseline di hardening su ogni host

Ogni macchina che costruiamo parte dalla stessa baseline, e la baseline non è negoziabile. SELinux è in enforcing, e non lo spegniamo per far collaborare un'applicazione, scriviamo invece la policy. I filesystem sono XFS.

Le patch non dipendono da nessun altro. Gestiamo il nostro mirror di pacchetti nel nostro datacenter, con i repository da cui installa la nostra flotta, firme upstream intatte, raggiungibile solo dai nostri intervalli di indirizzi. Un mirror pubblico che ha una brutta giornata non è un evento qui, e un server deliberatamente incapace di parlare con internet è ancora un server che possiamo aggiornare completamente.

In pratica. Quando è stata pubblicata una vulnerabilità critica in un runtime molto diffuso, i pacchetti corretti erano in produzione su ogni server interessato lo stesso giorno, prima della fine della stessa notte. Non a mano e non di fretta: il rollout fa un backup, aggiorna un host alla volta, campiona siti reali su quell'host per una risposta sana prima e dopo, e interrompe automaticamente l'intera operazione se uno non torna correttamente. Veloce e accurato non sono opposti se costruite la cosa che lo fa per voi.

I log delle macchine entrano, e nulla può tacere

Le severità serie vanno direttamente nella chat operativa dove l'ingegnere reperibile si trova già, raggiungendo una persona in pochi secondi, e sappiamo che sono secondi perché li abbiamo cronometrati con un allarme reale. All'edge, sensori dedicati leggono il traffico in mirror dai router di confine e osservano continuamente i pattern volumetrici e di denial of service.

Un dispositivo può sembrare perfettamente sano dalla sua riga di comando mentre in silenzio non manda nulla al collector, quindi «il logging è configurato» qui non è una prova. Confermiamo che il log arrivi, all'altro capo, nello stream a cui appartiene, dopo ogni modifica che avrebbe potuto disturbarlo. I sistemi di monitoraggio hanno i propri watchdog su macchine separate, così «la cosa che stava osservando ha smesso di osservare» è a sua volta un allarme. Il silenzio non è mai una buona notizia.

In pratica. Il nostro controllo di salute di routine verifica anche due cose che la maggior parte dei controlli salta: se ogni dispositivo sta ancora davvero spedendo i suoi log, e se la sua configurazione viene ancora davvero salvata. Quei due sono i guasti che nascondono gli altri.

Analisi in tempo reale sulle nostre NVIDIA A100

La maggior parte dei provider raccoglie i log in un contenitore e lo interroga dopo che qualcosa si è già rotto. Noi mettiamo lo stream al lavoro. Regole di base eliminano prima il rumore conosciuto, poi tutto ciò che resta, da router, switch, firewall, array di storage e server, viene analizzato all'arrivo da modelli AI che girano su un array di nostre GPU NVIDIA A100, dentro il nostro datacenter.

I modelli leggono attraverso i dispositivi, non una riga di log alla volta: un errore di percorso dello storage, un'interfaccia che oscilla e una temperatura in aumento sullo stesso rack diventano una sola storia invece di tre messaggi scollegati. Colgono i pattern che una regola statica non coglierà mai, la deriva lenta e la combinazione insolita che precede un guasto, e ogni allarme raggiunge l'ingegnere con un secondo parere già allegato. I dati delle macchine smettono di essere una pila di testo da scorrere con grep e diventano un preavviso.

Nulla di tutto questo lascia la nostra rete. I modelli, le GPU e i dati sono tutti nostri, e nessuna riga di log viene mai inviata a un servizio AI esterno.

Un CTO che ci valuta è il benvenuto a chiedere l'access list, il runbook e l'instradamento degli allarmi. Vi mostreremo tutti e tre.