Nei miei ultimi due articoli (se te li sei persi, qui trovi la 1° parte e qui la 2° parte), ho illustrato utilizzi di IP Fabric molto specifici. Oggi procederò al contrario, partendo da due problemi molto comuni, oserei dire dilaganti:
- Compliance nella configurazione;
- Controllo e standardizzazione della versione del sistema operativo;
La prima volta in cui ho visto un controllo della versione del sistema operativo è stata ai primi del 2000, con il cosiddetto bug y2k. Passavo giorni interi a connettermi ai router, usando il comando “show vers” per individuare la versione del sistema operativo e la memoria installata. Fatto questo, di solito, dovevo installare la memoria prima di aggiornare la versione 11.x di IOS. Se non altro sapevo cosa stava per rompersi quando disabilitavo il router. Ero all’inizio della mia carriera, spesso entusiasta dei nuovi metodi di lavoro, ma non sempre consapevole delle conseguenze delle mie azioni. Più o meno nello stesso periodo, armeggiando come consulente sulla rete di una grande banca, ho notato la presenza di traffico Netbios che non avrebbe dovuto esserci, allora ho aggiornato la configurazione su diversi router e firewall (mi rivolgo a chi è abbastanza anziano da sapere che Microsoft aveva bisogno di quel protocollo per comunicare). Inavvertitamente ho creato danni alla banca, perché non seguendo gli standard ignoravo diverse informazioni.
Oggi sono meno spregiudicato, meno “tecnico” e abbastanza maturato da riconoscere i problemi che mi sfuggivano allora. Una configurazione incoerente delle reti, unita alla mancanza di regole di conformità standardizzate, è la via più breve per il disastro: forse non oggi, nemmeno domani, ma un problema prima o poi si presenterà. Pertanto, come affrontiamo questa sfida?
Siccome il problema si articola in più fasi interconnesse, a volte finiamo per pensare troppo e bloccarci. In parte perché ci mancano gli strumenti, in parte perché fare le cose manualmente può essere oltremodo complesso se non impossibile, soprattutto se si lavora in un grande ambiente.
La sfida non è costruire un singolo framework o uno standard, che nella maggior parte dei casi esiste già o si può creare facilmente. La sfida è interfacciare quel framework (composto da più produttori e dispositivi) all’interno di organizzazioni complesse, che spesso hanno varie aree tecnologiche legate a diversi gruppi organizzativi (pensate per esempio alla sicurezza, al networking, agli sviluppatori, a Scada/PCD). Molti programmatori hanno cercato di risolvere questo problema in maniera miope, perché invece di inquadrarlo nella sua globalità, lo hanno affrontato come fosse limitato al loro brand: una difficoltà di Cisco, di PaloAlto, di Juniper ecc. Occorre invece una soluzione applicabile a tutte le reti e infrastrutture di sicurezza, indipendentemente dal tipo di dispositivo o dalla sfera di controllo.
Alcune aziende hanno cercato di risolvere questo problema creando strumenti per gestire la configurazione e gli standard a livello di dispositivo. Questo può aiutare ma, anche se appiana problemi di conformità, non risolve quello generale. Ad esempio, posso creare configurazioni perfette di firewall conformi a CIS/PCI/GDPR ecc., ma se un altro dispositivo è configurato per bypassare il firewall o è compromesso perché non soddisfa lo stesso standard, avere una configurazione perfetta è inutile. Occorre uno strumento che esplori tutta la rete in modo rapido, semplice ed efficiente, che catturi le configurazioni, le standardizzi e visualizzi i dati. Che ci permetta anche di stabilire gli intenti per la rete e fare verifiche di assurance. L’output di queste validazioni deve inoltre poter lanciare degli allarmi. Se il nostro standard, ad esempio, è solo il SNMPv3, per evitare rischi di sicurezza inerenti alle stringhe di comunità SNMPv2, il logging deve essere abilitato e Telnet disabilitato. Occorre controllare questo aspetto ogni volta che facciamo uno snapshot della rete, (almeno una volta al giorno) non su un solo dispositivo ma ovunque.
Questa stessa piattaforma di Network Assurance può risolvere anche l’altro problema di cui parlavo: la standardizzazione delle versioni del sistema operativo. In presenza di una rete tentacolare distribuita nel corso degli anni, come facciamo a far rispettare gli standard del sistema operativo di rete? Anche se siamo stati molto disciplinati e abbiamo un programma di strumenti di automazione già in atto, cosa succede quando ci sono Common Vulnerabilities and Exposures? È facile ripararle, ma quanto è grande il rischio operativo? Non sarebbe meglio se uno strumento potesse mostrarvi rapidamente dove sono i dispositivi colpiti? O quante versioni di codice avete sullo stesso dispositivo? E se oltre a mostrare dove sono per sito, permettesse di vedere le dipendenze a livello di rete (layer 1,2,3) e capire il rischio associato a una potenziale interruzione? Tutto questo non risolve il problema, ma permette di:
1) diminuire il tempo necessario per capire dove risiede il rischio;
2) darvi un’idea più chiara di quale sia il reale rischio legato all’aggiornamento del codice;
3) darvi un modo semplice per vedere la conformità dell’OS in tutto il vostro ambiente.
Infine, un semplice percorso post-modifica o uno snapshot della rete vi darà più tranquillità.
In questa serie di articoli ho toccato solo alcuni casi pratici, ma l’applicazione di questi strumenti è quasi infinita. Quando si valutano soluzioni di rete e assurance, il trucco si riassume in alcuni elementi: facilità di installazione e impostazione, facilità d’uso e di modifica per nuovi casi d’uso, API semplice e aperta, capacità webhook per consentire l’integrazione con altri strumenti di terze parti e, infine, agilità.
Alla prossima! E che le vostre reti siano sempre sicure e stabili!
