L'architettura introdotta da FTK 2.0 è una vera rivoluzione. Nel precedente post si era scritto che FTK 2.0 adottava una archiettura client/server. Questo è vero in linea di massima ma sotto il cofano di FTK si nasconde una architettura studiata con chiaro scopo: la scalabilità. La CF non è più quella che era 10 anni fa quando gli unici tool erano per il DOS (prima ancora che arrivasse EnCase o FTK) e che la dimensione dei dati da analizzare si contava in qualche Giga di disco. Ormai chi lavora in questo settore conosce i problemi che emergono, vuoi per il corso della tecnologia (dischi da 750 Gb nei pc casalinghi ormai!), vuoi per la complessità delle reti e dei sistemi operativi. Capita quindi che una perizia debba prendere in esame un paio di PC desktop, il laptop dell'ufficio e magari uno o due dispositivi portatili come un blackberry o un PDA, senza contare i vari USB thumbdrive, i cdrom, dvd, ecc. FTK scompone lo strumento in tre distinte parti:
- L'interfaccia (user interface), che richiede poca memoria e poca potenza di calcolo.
- Il database che mantiene le informazioni del nostro caso o dei casi gestiti dall'examiner.
- Il worker, ovvero quella componente responsabile per l'indicizzazione, il recovery dei file e tutte le comuni operazioni che richiedono potenza computazionale e memoria
Nell versione attuale di FTK (la stand alone) permette di fondere queste tre componenti sullo stesso sistema oppure separare l¹interfaccia utente dalle altre due. Il vantaggio è che quindi possiamo tenere un PC, anche un laptop, per l¹analisi del nostro caso e lasciare fare il lavoro sporco ad un sistema multiprocessore e con memoria ram a volontà. Non sarebbe però una vera scalabilità si ci dovessimo fermare solo a questa scissione. Nelle versioni Professional e Lab Edition sarà possibile scindere anche il database dal worker o dai workers
Ed è qui che i vantaggi di una architettura trasparente e scalabile emergono. Facciamo un breve esempio considerando una architettura con una interfaccia utente (o magari anche due), il database e tre workers. Una volta che una immagine disco(o perché no, più immagini) viene aggiunta nel caso i workers si contendono i task da eseguire. Il primo worker potrebbe per esempio iniziare il data recovery, il secondo l'indicizzazione dell'immagine e l'ultimo iniziare il bruteforce di un file protetto da password e il tutto è trasparente all'utente. E' chiaro che se ci troviamo di fronte a un caso in cui vengono coinvolte numerose immagini disco con una serie di operazioni da eseguire su alcuni TeraByte di dati (e il trend ormai si attesta su queste dimensioni), una architettura del genere che dispone di macchine dedicate al lavoro duro non può che tornarci comoda. E le novità da parte di Accessdata non sono finite.
