Torniamo sul concetto della protezione interna di un Web server e di un DBMS. Nel corso della guida ci siamo occupati di definire criteri ed accortezze volti ad "oscurare" ogni risorsa di tipo filesystem correlata al servizio in questione per ogni utente non autorizzato (che disponga di login sul sul server), ivi compresi gli utenti "virtuali" associati ai vari servizi in esecuzione.
La principale motivazione è rappresentata dalla possibilità che un cracker, ottenuto l'accesso al sistema in qualità dell'utente con cui gira un ipotetico servizio_A da egli bucato, possa manomettere altri servizi (ed avere accesso ai loro dati). Se proteggiamo a dovere il server Apache/MySQL dall'interno, anche in presenza di accesso alla shell di comando, il danno rimane circoscritto a servizio_A. O poco più.
Tutto corretto, ma.. non ci siamo occupati del contrario: dobbiamo proteggere i servizi rimanenti nel caso il buco "appaia" proprio sulla nostra installazione di Apache/MySQL, cioè se proprio uno dei due divenga il "trampolino di lancio" per l'intero sistema (e rete).
Generalmente si utilizza la tecnica del chrooting, ovvero si rinchiude il servizio in una "gabbia": il servizio vede il suo albero di directory come l'intero filesystem del server. Tuttavia presenterò ora una tecnica diversa, che tanto ha a che fare con l'utilizzo di più server, ciascuno su cui gira un unico servizio (paradigma di sicurezza "vera"), ma che ci premette nel contempo di evitare lo "spreco" di hardware differenti.
Sto parlando di virtualizzazione dei server, ciò che attua, per i nostri scopi, una più rigida separazione delle porzioni di filesystem usate dai diversi servizi. Lo vedremo nelle prossime lezioni.
