Controllo della protezioneDistribuzione di EFS: Parte 2

John Morello

Qualunque distribuzione di EFS (Encrypting File System) è composta essenzialmente di due parti: una parte che prevede la progettazione back-end che si concentra sugli agenti di gestione e recupero dei certificati e una parte che si concentra sull'implementazione di EFS rivolta all'utente. Il mese scorso ci siamo occupati della parte back-end, delle opzioni per il recupero di chiavi e dati

e del provisioning di certificati per i client. In questa sede, ci concentreremo sugli aspetti della distribuzione visti dall'utente finale, come i miglioramenti a Windows® Explorer, la scelta del percorso di file system da crittografare e la modalità di gestione delle opzioni di crittografia con Criteri di gruppo.

Stato di utilizzo di EFS

Una volta deciso di distribuire EFS, la prima fase consiste nel determinarne lo stato attuale d'utilizzo nell'organizzazione. EFS può essere utilizzato in modalità autonoma, in cui l'utente finale è l'unico responsabile della creazione e del backup delle chiavi di crittografia. Alcuni utenti avanzati dell'organizzazione potrebbero avere già utilizzato EFS in questa modalità, per cui è importante determinare chi siano per assicurare una transizione senza problemi a una distribuzione più gestita.

La prima volta che EFS viene utilizzato da un utente su un computer, Windows crea la seguente voce del registro di sistema seguente in HKEY_CURRENT_USER:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash 

È possibile utilizzare Microsoft ® Systems Management Server (SMS), gli script di accesso di Active Directory o altri strumenti per verificare la presenza di questa voce sulle macchine dell'organizzazione. Se questa voce del registro di sistema è presente, significa che l'utente ha già utilizzato EFS. Ciò non indica necessariamente che qualcuno stia utilizzando attualmente EFS né che vi siano dati crittografati. Se sul computer viene rilevata questa chiave di registro di sistema, esaminarlo attentamente per determinare la presenza di file crittografati.

Utilizzare cipher.exe e le opzioni /U e /N per creare un report sullo stato di crittografia di file e directory del computer. Ad esempio, per determinare se i dati del sistema sono crittografati, eseguire questo comando:

cipher /U /N

Il controllo del Registro di sistema e il report di crittografia potrebbero essere combinati in un unico script per verificare la presenza del valore del Registro di sistema e, in tal caso, generare un report dei file crittografati presenti sul computer. Una volta creati i report, sarà chiaro quali sono gli utenti a possedere file crittografati e sarà possibile migrarli verso la gestione centrale.

Per controllare l'applicazione di Criteri di gruppo durante l'implementazione, è utile creare due gruppi di protezione nel dominio per separare i computer in cui è in uso EFS da quelli in cui non lo è. I gruppi potrebbero essere ad esempio "SG-ComputersUsingEFS" per gli account computer delle macchine che già utilizzano EFS e "SG-ComputersNotUsingEFS" per quelle che non utilizzano EFS.

Controllo dell'utilizzo di EFS mediante Criteri di gruppo

Una volta chiaro chi utilizza o meno EFS, la fase successiva della distribuzione client consiste nel disattivare l'utilizzo autonomo di EFS per chi non lo sta attualmente impiegando. Questo è un passaggio importante nel processo di implementazione perché attivare e configurare EFS correttamente la prima volta è più semplice che eseguire la migrazione degli utenti che utilizzano certificati autofirmati. Completare questo passaggio solo dopo avere determinato quali utenti utilizzano già EFS, perché disattivando EFS tramite Criteri di gruppo gli utenti non saranno in grado di accedere ai file attualmente crittografati. Questi criteri sono disponibili in Editor oggetti criteri di gruppo in Configurazione computer\Impostazioni di Windows\Impostazioni di protezione\Criteri chiave pubblica\Crittografia File System.

Come illustrato in precedenza, questo valore dovrebbe essere abilitato soltanto sui computer dove EFS non è attualmente in uso, per non interrompere l'attività di chi già utilizza EFS. Nell'esempio citato quindi l'elenco di controllo di accesso (ACL) nell'Oggetto Criteri di gruppo che disattiva EFS consente soltanto al gruppo "SG-ComputersNotUsingEFS" di applicare Criteri di gruppo.

Crittografare o non crittografare

Una volta determinati i sistemi che utilizzano attualmente EFS e disattivato EFS su tutti gli altri fino alla distribuzione gestita, la fase successiva consiste nel determinare cosa crittografare in tale distribuzione gestita. In base alla modalità con cui vengono gestiti i sistemi client, il processo potrebbe variare da semplice a complesso.

La prima cosa da considerare quando si pensa a quali file crittografare è se gli utenti sono amministratori del sistema. Se gli utenti sono amministratori locali, è possibile soltanto istruirli e incoraggiarli a crittografare i dati riservati, ma non sarà possibile controllare la crittografia in modo gestito. Il motivo è semplice: un amministratore locale può creare file e directory ovunque nel file system. Così, se da una parte è possibile crittografare i percorsi comuni come Documenti, se l'utente crea una nuova directory in un altro percorso e vi salva delle informazioni riservate, è abbastanza difficile assicurarne la protezione. Oltre ai vantaggi per la sicurezza che si ottengono quando gli utenti finali non sono amministratori locali, questa opzione rende EFS più gestibile e protetto.

Un'altra informazione da tenere a mente su EFS è che si tratta di una crittografia per utente. In altre parole, tutto ciò che viene crittografato da un determinato utente può essere decrittografato solo da quello stesso utente, compreso l'account SYSTEM (fatta eccezione per Agente recupero dati o DRA). Ciò significa che se un file eseguibile o DLL viene crittografato con una chiave dell'utente e un'altra entità sul sistema tenta di accedervi, l'entità riceverà un errore di accesso negato. Pertanto, si sconsiglia di crittografare file o directory che contengono codice eseguibile a cui potrebbero richiedere l'accesso più entità su un sistema. Windows eviterà la crittografia di file in %SystemRoot% o file con attributo SYSTEM, ma non è insolito per i fornitori di software installare file binari in %Programmi% per servizi che potrebbero essere eseguiti dall'account SYSTEM. Ad esempio, tale approccio è comune tra i fornitori di portatili da utilizzare durante l'installazione di software di gestione di alimentazione e periferiche eseguite come servizi.

Tenendo conto di queste informazioni, quali sono le procedure consigliate per la crittografia EFS? La risposta dipende dalla configurazione dei sistemi dell'utente. In un ambiente ben gestito con un'immagine del sistema operativo standardizzata, è possibile automatizzare il processo di crittografia per utenti in base a percorsi di archiviazione dati predeterminati dall'immagine. Ad esempio, se gli utenti possono salvare i dati solo in %profilo utente%\Documenti, potrebbe essere necessario crittografare solo quella directory. (Nota: fare attenzione alla crittografia di Documenti se si utilizza il reindirizzamento della cartella). Se Documenti viene reindirizzato a un server, sarà necessario che tale server sia trusted per delega e che abbia accesso al profilo dell'utente. In casi di questo tipo è generalmente più facile crittografare la cache File non in linea (trattata più avanti).

In un ambiente meno gestito (dove gli utenti possono scrivere in più percorsi del file system), potrebbe essere interessante automatizzare la crittografia di alcuni percorsi di archiviazione comuni e istruire gli utenti su come crittografare gli altri percorsi in autonomia. Indipendentemente dall'ambiente è necessario eseguire la crittografia sempre a livello di directory piuttosto che di file per assicurare che tutti i file creati nella directory, compresi quelli temporanei, siano crittografati.

Percorsi di crittografia consigliati

Come regola generale, i percorsi da crittografare sono: %profilo utente%\Documenti, %profilo utente%\Dati applicazioni\Microsoft\Outlook (presupponendo che si utilizzi Microsoft Office Outlook® come client di messaggistica) e %profilo utente%\Desktop. La crittografia di Documenti consente di proteggere il percorso predefinito dei file salvati in Windows XP. La protezione della directory di Outlook assicura la crittografia dei messaggi di posta elettronica memorizzati localmente; fondamentale per gli utenti che eseguono Outlook 2003 in modalità cache predefinita. Infine, il desktop è spesso utilizzato come directory temporanea in cui gli utenti possono collocare i documenti a cui stanno lavorando o presentazioni che utilizzano spesso. È possibile che nell'organizzazione i percorsi predefiniti di queste directory siano stati modificati, pertanto le scelte di crittografia di EFS devono riflettere i percorsi utilizzati di solito nell'organizzazione.

Oltre a queste procedure consigliate generali, è necessario determinare l'eventuale presenza di applicazioni che potrebbero salvare informazioni riservate in percorsi alternativi. Ad esempio, alcune applicazioni salvano le informazioni utente in %Programmi%\Nomeappl piuttosto che nel profilo dell'utente. È importante determinare se tali applicazioni sono presenti sui sistemi client in modo da proteggere correttamente i dati in uso. In una situazione ottimale, è possibile configurare l'applicazione in modo da salvare le modifiche in un percorso specifico del profilo utente (come Documenti), in cui non sono necessarie ulteriori modifiche di EFS. Nella peggiore delle ipotesi, se l'applicazione richiede che i dati siano memorizzati nella directory Programmi, è possibile utilizzare EFS per crittografare soltanto la sottodirectory specifica di Programmi.

Infine, un'attenzione particolare merita la crittografia della directory temporanea (%TMP % e %TEMP%). Molti programmi di installazione di applicazioni utilizzano questa directory per l'espansione dei contenuti del pacchetto di installazione ed eseguono poi le operazioni di spostamento di file sui file espansi per collocarli nell'adeguato percorso in %Programmi%. Poiché un file spostato nello stesso volume conserva gli attributi originali, il file continuerà a essere crittografato anche dopo essere stato posizionato in %Programmi%. Se un utente diverso da quello che esegue il programma di installazione tenta di utilizzare questo file, gli sarà negato l'accesso. Spesso, tali problemi non si manifestano in messaggi di errore chiari che indicano la causa principale. Per questo motivo si consiglia di crittografare %TMP% soltanto negli ambienti ben gestiti, dove gli utenti finali non installano applicazioni autonomamente.

Protezione di file non in linea

File non in linea è una funzionalità disponibile a partire da Windows 2000 che consente agli utenti di eseguire una copia locale dei dati memorizzati su un file server. File non in linea consente agli utenti di lavorare su questi dati rimanendo disconnessi dal server e di sincronizzare le modifiche nel server alla connessione successiva. File non in linea non è soltanto una directory che contiene le copie di file del server. Si tratta di un database condiviso a livello di sistema eseguito nel contesto dell'account SYSTEM. In Windows XP, tale database può essere protetto con EFS. Alla luce di quanto detto prima e considerando la specificità per utente di EFS sorge una domanda. Come è possibile crittografare un database utilizzato da entità di protezione multiple tramite la tecnologia EFS?

Quando un utente che esegue Windows XP sceglie l'opzione per la crittografia dei file non in linea di Esplora risorse, la routine di crittografia utilizzata è diversa da quella impiegata per le altre operazioni di crittografia avviate dall'utente. Piuttosto che utilizzare la coppia di chiavi EFS personale dell'utente per il processo (che impedirebbe a SYSTEM di accedere ai file), l'account SYSTEM genera una coppia di chiavi da utilizzare con EFS e la utilizza per crittografare la memoria lato client. Si tratta di implicazioni critiche sulla protezione in quanto se un utente è in grado di eseguire il codice come SYSTEM, può decrittografare i dati della cache. Se un portatile viene rubato un utente malintenzionato è in grado di reimpostare con facilità la password amministratore e accedere come amministratore. Con i privilegi di amministratore attivi può eseguire il codice come SYSTEM e accedere alla cache. (Questo comportamento è cambiato in Windows Vista™ dove si utilizza adesso la chiave del singolo utente per crittografare File non in linea specifici dell'utente).

Per proteggersi da questo tipo di attacco, è possibile configurare il portatile per memorizzare la chiave di crittografia per il database Gestione account di protezione (SAM) non linea, come password da immettere all'avvio (modalità 2) o su dischetto durante il processo di avvio (modalità 3). Entrambi gli approcci possono essere complessi poiché richiedono l'interazione non automatica col computer all'avvio, creando problemi potenziali con la gestione automatica dei sistemi. Tuttavia, se EFS deve essere utilizzato su un computer con File non in linea è importante che sia utilizzata una di queste opzioni per proteggere i dati della cache. In genere è preferibile utilizzare la password all'avvio (vedere la Figura 1) perché un utente a cui viene sottratto il laptop terrà probabilmente il dischetto nel computer o nella borsa.

Figura 1** Automatizzare le operazioni di EFS **

Attivazione di EFS

Una volta determinato cosa crittografare nel client, la fase successiva è eseguire l'operazione di crittografia. A tal fine utilizzare uno script di accesso o un altro processo che esegua uno script sul client per richiamare cipher.exe ed eseguire l'operazione di crittografia. Se nell'ambiente sono presenti utenti di EFS autonomi, come indicato nell'esempio precedente, si consiglia di iniziare la migrazione da questi.

Per eseguire la migrazione degli utenti autonomi, la prima fase è il provisioning dei sistemi client con certificati gestiti, come discusso nell'articolo di febbraio 2007 (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Una volta iscritti tutti i sistemi a questi certificati gestiti, eseguire la crittografia con l'opzione /U per aggiornare tutti i file esistenti con le nuove chiavi di agente di recupero e di crittografia. A questo punto, tutti i sistemi nel gruppo SG-ComputersUsingEFS dovrebbero utilizzare EFS in modo gestito, anche per le chiavi emesse (e potenzialmente archiviate) centralmente nonché per gli agenti di recupero gestiti centralmente.

Per distribuire EFS per gli utenti che non lo utilizzano attualmente occorre rimuovere i Criteri di gruppo che ne impediscono l'uso. Una volta eseguita l'operazione e dopo che gli utenti si sono iscritti ai certificati gestiti, è possibile eseguire uno script di accesso per crittografare i percorsi principali citati sopra. Ecco un esempio di script semplificato:

cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"

Dopo avere attivato EFS sulle directory desiderate, considerare due opzioni aggiuntive per aumentare la protezione della distribuzione di EFS, entrambe correlate ai dati paginati dalla memoria su disco. Per ciascuno di questi scenari la quantità di dati che potrebbe essere potenzialmente recuperata da un utente malintenzionato si limita a quanto caricato nella memoria o su disco durante l'uso legittimo. Ossia, i dati riservati protetti mediante EFS sul computer che non sono stati visualizzati (e non sono stati quindi caricati nella memoria) non sono a rischio di attacco.

Il file di paging viene utilizzato da Windows come memoria virtuale (spesso chiamato spazio di swapping in altri sistemi operativi) e contiene dati in memoria scritti come testo normale nel disco rigido. Ciò potrebbe mettere a rischio i dati riservati presenti su un sistema protetto da EFS perché un utente malintenzionato che riesce a recuperare il file di paging potrebbe utilizzare potenzialmente degli strumenti forensi per estrarre dati utilizzabili. Poiché il file di paging non può essere crittografato in Windows XP (ma può esserlo in Windows Vista) l'opzione migliore è forzare Windows a cancellarlo all'arresto del sistema. Questa operazione può essere eseguita tramite Criteri di gruppo, come illustrato nella Figura 2.

Figura 2** Impostazione di Criteri di gruppo **(Fare clic sull'immagine per ingrandirla)

Il lato negativo dell'impostazione consiste nel significativo aumento del tempo necessario ad arrestare il computer, soprattutto se dispone di una memoria di grandi dimensioni. Per impostazione predefinita, la dimensione del file di paging è direttamente proporzionale alla memoria fisica del computer. Questo perché per cancellare il file di paging Windows deve scrivere fisicamente in ogni pagina sul disco prima dell'arresto del sistema.

Il file di sospensione in Windows contiene un'immagine della memoria fisica del computer quando la modalità di risparmio energia è impostata per attivare la sospensione. Quando si verifica la sospensione, Windows scrive il contenuto completo della memoria fisica sul disco nel file di sospensione, consentendo il ripristino del computer esattamente sul medesimo stato quando l'utente è pronto a procedere. Come il file di paging, il file di sospensione non può essere crittografato in Windows XP. Ma a differenza del file di paging, la sospensione non può essere disattivata direttamente da un oggetto Criteri di gruppo. Occorre invece utilizzare uno script per richiamare powercfg.exe con l'opzione /HIBERNATE per disattivare (o riattivare) la sospensione.

Una volta completate le attività di crittografia e configurazione iniziali, si consiglia di cancellare lo "slack space" dai dischi della distribuzione. Questo processo può essere molto lungo e problematico, ma presenta un vantaggio di protezione in ambienti a protezione elevata. Lo "slack space" è l'area del disco che non conserva i dati attivi nel sistema, ma che, a causa della modalità di funzionamento del disco fisso, può contenere informazioni riservate provenienti di file utilizzati in precedenza. In altre parole, poiché un'operazione di cancellazione di file non sovrascrive effettivamente tutti i settori occupati da un file su un disco (rimuove soltanto l'indicatore dalla tabella di file), i dati che sono stati cancellati continuano a esistere sul disco. In questi casi, i dati possono essere recuperati da strumenti forensi in grado di leggere questo slack space e riassemblare i file. Per cancellare questi dati residui in modo sicuro, eseguire la crittografia con l'opzione /W. L'operazione forza la crittografia a sovrascrivere ripetutamente tutti i settori contrassegnati come disponibili sul disco. Finché tutte le operazioni di file future sui dati riservati si verificano nelle directory protette da EFS, non sarà necessario eseguire questo comando regolarmente.

Ottimizzazione di Esplora risorse per EFS

Per impostazione predefinita, le opzioni di crittografia e decrittografia di file e directory si trovano nei menu di proprietà avanzate di Esplora risorse. Per migliorare l'esperienza dell'utente finale con EFS, è possibile inserire "Crittografa" e "Decrittografa" nel menu di scelta rapida di Esplora risorse (visualizzato facendo clic con il pulsante destro del mouse). Inoltre, è possibile configurare Esplora risorse in modo che visualizzi file e directory protetti da EFS in un colore diverso (verde) rispetto agli altri file. Ciò consente agli utenti di sapere se un file o una directory è crittografato senza dover scorrere il menu delle proprietà avanzate. Se lo si desidera, è possibile aggiungere un'opzione per definire quali utenti hanno accesso al file o alla directory. Per abilitare tale opzione, eseguire le

following changes in the registry via a script calling reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]  
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS in Windows Vista

EFS ha subito numerosi miglioramenti in Windows Vista che semplificano la distribuzione, la gestione e l'aumento della sicurezza. Primo fra questi è il supporto completo per la memorizzazione delle chiavi EFS su smart card. Si tratta di una funzionalità particolarmente utile per le organizzazioni che già utilizzano l'accesso della smart card, in quanto la stessa scheda può essere utilizzata anche per memorizzare le chiavi EFS degli utenti. Il supporto per le smart card viene esteso anche ai certificati dell'agente di recupero, per cui anche i certificati DRA riservati possono essere memorizzati nelle schede.

Windows Vista supporta anche la crittografia di elementi precedentemente impossibili o complessi da crittografare in Windows XP. Windows Vista esegue la crittografia del file di paging, eliminando la necessità di impostare l'opzione che consente di cancellare il file di paging della memoria virtuale. L'intero sistema dei File non in linea è stato rielaborato in Windows Vista. Oltre a prestazione e stabilità migliori (e a un'interfaccia più intuitiva), il caching lato client avviene adesso per utente, consentendo di crittografare la cache in modo protetto senza ricorrere alle modalità SYSKEY 2 o 3. Questi due miglioramenti eliminano i principali ostacoli alla distribuzione degli attuali ambienti basati su Windows XP.

Infine, Windows Vista consente agli amministratori di configurare la crittografia della cartella Documenti direttamente da Criteri di gruppo, senza dover utilizzare uno script separato. Nella Figura 3 sono illustrate le nuove proprietà EFS disponibili tramite Oggetto Criteri di gruppo in Windows Vista.

Figura 3** Proprietà EFS di Windows Vista **(Fare clic sull'immagine per ingrandirla)

Conclusione

EFS fornisce agli amministratori Windows un'opzione altamente protetta per proteggere i dati mobili. EFS è scalabile, facile da gestire e offre meccanismi di ripristino dei dati flessibili. In Windows Vista EFS è stato potenziato con funzionalità per la gestione e la distribuzione semplificate, come il supporto dell'archiviazione di chiavi basato su smart card. Per le organizzazioni che desiderano proteggere i dati, anche nel caso di un computer fisicamente perso, EFS fornisce una soluzione che fa già parte della piattaforma Windows esistente.

Ulteriori informazioni

Per ulteriori informazioni sugli argomenti trattati in questa sede, consultare le risorse seguenti:

• Articolo Controllo protezione di febbraio 2007
• Encrypting File System in Windows XP and Windows Server 2003 (in inglese)
• Come utilizzare l'utilità SysKey per proteggere il database Gestione account di protezione di Windows

John Morello si è laureato con lode presso la LSU e lavora in Microsoft da sei anni coprendo diversi ruoli. Come consulente senior, ha progettato soluzioni di protezione per le aziende Fortune 100 nonché per i clienti della difesa e civili americani. Attualmente è Program Manager presso il gruppo Windows Server e si dedica alle tecnologie di protezione e accesso remoto.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.