Controllo protezioneDistribuzione di EFS: Parte 1:

Al giorno d'oggi tutti hanno sentito parlare della perdita di dati personali o riservati a causa del furto di computer portatili o dell'abbandono di computer in luoghi sbagliati. I computer portatili vengono smarriti regolarmente. La totale protezione dei dati sui computer portatili è essenziale, in quest'epoca caratterizzata da furti di identità dove il rispetto delle normative è più che mai fondamentale.

L'uso di EFS (Encrypting File System), contenuto in Windows® fin dalla versione Windows 2000, potrebbe essere una soluzione in quanto fornisce una crittografia basata su disco, incorporata e a prestazioni elevate. EFS si integra perfettamente con Esplora risorse, tanto che gli utenti finali spesso non si rendono conto di utilizzare un file crittografato. Inoltre, EFS funziona altrettanto bene con le tecnologie di autenticazione e controllo di accesso originali di Windows, pertanto gli utenti non hanno bisogno di ricordare password diverse per accedere ai loro dati. Infine, EFS offre opzioni semplici da gestire per il recupero dei dati qualora un utente perdesse l'accesso alle sue chiavi di crittografia (ad esempio, in caso di cancellazione o danneggiamento del suo profilo utente o di perdita della smart card).

EFS utilizza la tecnologia di crittografia incorporata in Windows per generare, memorizzare e distribuire chiavi di crittografia complesse per la protezione dei dati. In Windows XP Service Pack 1 (SP1) e versioni successive, EFS utilizza l'algoritmo AES (Advanced Encryption Standard) con una chiave a 256 bit per la codifica dei dati sul disco. Queste chiavi simmetriche sono inoltre protette da una coppia asimmetrica di chiavi (RSA). EFS codifica ogni file con la sua chiave AES, quindi codifica questa chiave con la chiave RSA dell'utente e ne memorizza il risultato nel file. Per ulteriori informazioni sulla crittografia EFS, vedere "Risorse EFS" nella barra laterale. Per adesso non concentrerò l'attenzione sul lato strettamente tecnico di EFS, ma piuttosto su come distribuirlo e renderlo utilizzabile nell'ambiente degli utenti. Per questo motivo, il presente articolo presuppone una conoscenza precedente dei concetti di crittografia EFS.

Una nota sulla protezione di EFS

Alcune applicazioni sembrano essere in grado di decifrare o decodificare la crittografia EFS. Nessuna di queste applicazioni è capace di decrittografare effettivamente l'AES (o Data Encryption Standard, DES, o Expanded Data Encryption Standard, DESX), sono piuttosto in grado di accedere alla chiave privata EFS dell'utente forzandone la password in maniera brutale. La cosa importante da tenere a mente a proposito della crittografia EFS è che le chiavi private utilizzate per generare e proteggere i dati crittografati utilizzano Data Protection API (DPAPI). Per proteggere i dati, DPAPI utilizza i derivati delle credenziali di accesso di un utente; ne consegue che la protezione dei dati con EFS è efficace quanto la password dell'utente. Con Windows Vista™ è ora possibile memorizzare i certificati di crittografia EFS sulle smart card, cosa che modifica questo paradigma e aumenta considerevolmente la protezione relativa dei dati protetti da EFS.

Quanto deve essere lunga la password per resistere a questi attacchi? Considerate le funzionalità hardware e gli algoritmi moderni di attacco delle password, si consiglia una password (o più correttamente, passphrase) di 11 caratteri come minimo. Una passphrase di 11 caratteri o più lunga è estremamente resistente ai metodi odierni più avanzati, compresi gli attacchi hash precalcolati (come Rainbow Table, per ulteriori informazioni vedere la pubblicazione sul blog "Why you shouldn't be using passwords of any kind on your Windows networks" in "Risorse" nella barra laterale).

Utilizzare PKI o no?

Una delle convinzioni erronee più diffuse su EFS è che, per funzionare, richieda un'infrastruttura a chiave pubblica (PKI). Sebbene EFS possa integrarsi e sfruttare facilmente i vantaggi di una PKI, qualora l'organizzazione ne possieda già una, non si tratta di un requisito essenziale. Detto ciò, la decisione di utilizzare o meno una PKI durante la distribuzione dell'EFS avrà un impatto su molte decisioni di distribuzione future, pertanto deve essere vagliata con cura.

Il vantaggio principale dell'utilizzo di una PKI con EFS è la capacità di eseguire i processi di archiviazione e di ripristino della chiave. EFS consente agli amministratori di eseguire il ripristino dei dati, tuttavia il ripristino automatico è disponibile soltanto con una PKI e solo quando viene eseguito Windows Server® 2003 Enterprise Edition come Autorità di certificazione (CA). Il ripristino dei dati è il processo tramite cui l'utente che perde l'accesso alla sua chiave di crittografia può fornire i suoi dati crittografati a un amministratore designato noto come Data Recovery Agent (Agente di ripristino dei dati, DRA), il quale può quindi decrittografare i dati e riconsegnarli all'utente, oppure ricrittografarli per essere utilizzati con una nuova chiave privata. Il DRA è una figura importante nel processo di crittografia dell'utente, in quanto tutto ciò che l'utente codifica con la sua chiave viene codificato anche con una copia della chiave del DRA. Pertanto se l'utente perde la chiave, interviene il DRA il quale recupera i dati del testo crittografato, vi applica la sua chiave DRA per la decrittografia (o la ricrittografia), quindi riconsegna i dati all'utente. L'approccio del DRA è funzionale, tuttavia può essere difficile da gestire se l'utente ha crittografato grandi quantità di dati oppure non dispone di personale IT locale che funga da DRA.

Il ripristino della chiave, d'altra parte, richiede che l'autorità di certificazione esegua una copia della chiave di crittografia dell'utente durante il processo di creazione della chiave e ne memorizzi in maniera sicura la copia nel database della suddetta autorità di certificazione. In seguito, se l'utente perde l'accesso ai file codificati, l'amministratore della CA deve semplicemente consultare tale database e recuperare la chiave dell'utente. A questo punto l'utente avrà immediatamente accesso ai suoi dati senza richiedere l'intervento di un DRA. Grazie a questo processo, il ripristino della chiave può rivelarsi più veloce ed efficiente. Notare, tuttavia, che la procedura consigliata consiste nell'avere sempre a disposizione un DRA, anche nei casi di ripristino della chiave, per fornire un meccanismo di backup in caso di perdita delle chiavi. Inoltre questo consente alle grandi organizzazioni di disporre di un sistema di ripristino distribuito, dove gli amministratori IT locali possono recuperare i dati degli utenti senza essere costretti a coinvolgere il gruppo di amministratori della PKI.

Un altro potenziale vantaggio dell'utilizzo della PKI con EFS è che facilita una condivisione più agevole dei file codificati. Tenere presente che EFS non si limita esclusivamente ai computer portatili, infatti è uno strumento ugualmente prezioso nelle situazioni in cui non si possa garantire la protezione fisica di un computer. In queste situazioni, utenti multipli potrebbero avere bisogno di accedere agli stessi dati crittografati. Benché il supporto di Windows per la condivisione di file crittografati sia relativamente limitato, in quanto contempla soltanto la condivisione di file singoli e non delle directory, può tuttavia rivelarsi uno strumento utile. Per facilitare la condivisione dei file EFS, l'utente che condivide il file deve avere accesso alle chiavi pubbliche degli utenti con cui sta condividendo i file (cosa più facile se tali utenti dispongono di un valido certificato EFS pubblicato nel loro account in Active Directory®). Benché sia possibile eseguire manualmente tale pubblicazione, utilizzando l'autorità di certificazione (CA) di Windows installata in modalità Enterprise (integrata in Active Directory) il processo viene reso completamente automatico.

Gestione delle chiavi EFS

Se si dispone, e si può utilizzare, una PKI basata su Windows Server 2003, generare certificati EFS per gli utenti è un processo semplice. Una CA di Windows Server 2003 viene fornita con una serie predefinita di modelli di certificati, compreso il modello EFS di base. Tuttavia questo modello fa parte della versione 1 e non supporta l'archiviazione delle chiavi. Pertanto, prima di renderlo disponibile nella propria CA, è necessario duplicare il modello per crearne uno nuovo nella versione 2 (ad esempio, lo si potrebbe chiamare EFS con archiviazione delle chiavi, come indicato nella Figura 1). In questo nuovo modello, accedere alla scheda Gestione richiesta e selezionare l'opzione di archiviazione della chiave di crittografia dell'utente. Si noti che prima di attivare quest'opzione è necessario configurare correttamente l'archiviazione della chiave sulla CA. La sezione risorse contiene un'eccellente descrizione del processo. È necessario inoltre impostare questo modello affinché sostituisca il modello EFS di base per assicurarsi che i client utilizzino la nuova versione (vedere la Figura 2).

Figura 1** EFS con archiviazione delle chiavi **(Fare clic sull'immagine per ingrandirla)

Figura 2** Sostituzione del modello EFS di base **(Fare clic sull'immagine per ingrandirla)

Per consentire l'accesso all'iscrizione al corretto gruppo di utenti, occorre impostare le corrette autorizzazioni sul modello. Poiché il componente EFS in Windows richiederà automaticamente un certificato al primo utilizzo di EFS, generalmente non è necessario consentire agli utenti di autoiscriversi nel modello EFS. Infatti, si sconsiglia di attivare l'autoiscrizione per i certificati EFS a meno di essere certi che tutti gli utenti autoiscritti utilizzeranno EFS. La Figura 3 indica le impostazioni di iscrizione di EFS. L'emissione di certificati a utenti che potrebbero non utilizzare mai EFS, aumenta inutilmente la dimensione del database della CA. Benché la dimensione del database della CA non sia limitata, può diventare più difficile da gestire (in particolare con Microsoft Management Console o MMC) man mano che il numero di certificati emessi aumenta.

Figura 3** Impostazione delle autorizzazioni utente EFS **(Fare clic sull'immagine per ingrandirla)

Infine, se è necessario supportare la condivisione dei file crittografati, può essere utile far pubblicare automaticamente dalla CA il certificato dell'utente in Active Directory.

Una volta configurato correttamente il modello nella propria CA, la prima volta che un utente esegue la crittografia di un file con EFS otterrà il suo certificato da tale CA e questa archivierà automaticamente la sua chiave privata.

Gestione delle chiavi DRA

Il passo successivo da considerare, se si dispone di una PKI, è se utilizzare o meno i certificati DRA generati dalla CA. Perché non si dovrebbero utilizzare i certificati DRA dalla propria PKI? Si consideri uno scenario in cui l'autorità di certificazione emette un certificato con un periodo di validità relativamente breve (due anni o meno). Tale CA non sarà in grado di emettere alcun certificato con una durata di validità superiore alla propria, vale a dire che i certificati DRA avranno una validità di due anni al massimo. Ciò può risultare in operazioni di ripristino dei dati considerevolmente più complicate. Quest'esempio ipotetico è illustrato nello scenario seguente.

1. Un utente codifica un file nel gennaio del 2006; i certificati DRA emessi nel suo computer per mezzo di Criteri di gruppo hanno una validità di due anni (scadono a gennaio 2008).
2. L'utente continua a lavorare con EFS, crittografando nuovi file.
3. Nel gennaio del 2008 i certificati DRA scadono e tramite Criteri di gruppo l'amministratore emette nuovi certificati.
4. Da questo momento in poi, tutte le operazioni di crittografia utilizzano i nuovi certificati DRA (compresi tutti i file aperti dall'utente e codificati con vecchi DRA; una volta salvati, questi utilizzeranno i nuovi DRA); tuttavia tutti i successivi file che l'utente non tocca risulteranno protetti solo con i vecchi DRA.
5. L'utente danneggia accidentalmente il suo profilo e richiede il ripristino dei dati.
6. L'amministratore IT deve disporre di due serie di certificati DRA: quelli nuovi per tutti i file toccati a partire dal Passaggio 3 e quello vecchio per tutti i file che non sono stati toccati da allora.

Benché l'amministratore IT possa eseguire uno script dopo il Passaggio 3 per aggiornare tutti i file col nuovo DRA (utilizzando cipher.exe /u), potrebbe essere un processo lungo. Inoltre, e per maggiore chiarezza, le coppie di chiavi DRA possono essere utilizzate anche dopo la loro data di scadenza, anche se il componente EFS non consentirà alcuna nuova operazione di crittografia, a condizione che un certificato DRA scaduto sia incluso nei suoi criteri di ripristino. I vecchi file crittografati con la coppia di chiavi DRA scadute, possono ovviamente essere recuperati. Pertanto le coppie di chiavi DRA non devono mai essere eliminate, nemmeno al termine del periodo di validità. Non è possibile sapere quando se ne avrà bisogno di nuovo.

Per queste ragioni, si consiglia che gli ambienti aventi CA con certificati di validità brevi impieghino certificati DRA autofirmati che abbiano una durata di validità superiore. L'utilità di crittografia contiene un'opzione (cipher.exe /r) che crea automaticamente le coppie di chiavi dell'agente di ripristino EFS con una validità di 100 anni (vedere la Figura 4). Il certificato di questa coppia di chiavi può essere allegato quindi agli oggetti Criteri di gruppo (GPO, Group Policy Object) ed utilizzato come DRA in tutta l'organizzazione. Poiché il componente EFS non controlla la catena di certificati DRA, i certificati autofirmati saranno validi senza dover apportare alcuna modifica all'elenco di Autorità di certificazione principale attendibili presente nei sistemi. A prescindere dalla durata di validità della CA di un'organizzazione, si consiglia sempre di creare almeno un certificato DRA a lunga scadenza e di allegarlo a un oggetto Criteri di gruppo che copra l'intero dominio. Questa è l'opzione di fallback per il ripristino dei dati, da utilizzare qualora tutte le altre opzioni siano vane. Ciò è particolarmente importante se si utilizzano chiavi DRA generate da CA in mancanza di un archivio di chiavi della CA. Nell'eventualità che un certificato DRA venga compromesso, è possibile aggiornare l'oggetto Criteri di gruppo con un nuovo certificato e utilizzare cipher.exe/u per aggiornare i file, come indicato precedentemente.

Figura 4** Esecuzione di Ciquer /R **(Fare clic sull'immagine per ingrandirla)

Risorsa EFS

Per ottenere ulteriori informazioni sui dettagli e le procedure consigliate per EFS, visitare i seguenti siti.

• Perché si sconsiglia di utilizzare password di qualsiasi tipo sulle reti Windows
• Implementazione dei passaggi per l'archiviazione delle chiavi
• Encrypting File System in Windows XP and Windows Server 2003

Distribuzione di KRA e DRA

L'archiviazione delle chiavi consente agli amministratori CA la capacità di recuperare chiavi crittografate garantite per conto dell'utente. Ovviamente, si tratta di una funzionalità estremamente riservata e importante, in quanto può consentire a un amministratore della CA di decrittografare tutti i dati presenti nell'organizzazione che utilizza una chiave firmata dalla CA. Pertanto l'archiviazione e il ripristino delle chiavi dovrebbero essere gestiti con la massima cura e solo un numero esiguo di fidati addetti alla sicurezza dovrebbe possederne l'autorizzazione. A ragione della natura riservata del ripristino delle chiavi, se si desidera farne affidamento come meccanismo principale per recuperare l'accesso a dati crittografati EFS, è importante richiedere che un processo di escalation, chiaramente definito per le richieste di ripristino, sia inviato al proprio team di amministrazione della CA. Il processo di ripristino dovrebbe essere avviato solo dopo aver vagliato attentamente la richiesta. Quindi, una volta che la chiave è stata effettivamente recuperata, dovrebbe essere fornita all'utente tramite un metodo protetto (in altre parole non tramite posta elettronica) in quanto la chiave recuperata fornisce l'accesso a tutti i dati protetti da EFS.

Le chiavi dell'agente di recupero chiavi, o semplicemente chiavi KRA, vengono generate e gestite dagli amministratori della CA e non vengono manifestate tramite Criteri di gruppo. Infatti EFS non può determinare da solo se una chiave utilizzata sia stata archiviata o meno, ma esegue semplicemente le operazioni di crittografia, come sempre. Inoltre, le chiavi KRA create sulla CA non sono affatto specifiche a EFS. Una CA che adotta l'archiviazione delle chiavi disporrà di n numero di chiavi KRA ad essa associate a livello della CA, che saranno utilizzate per proteggere tutte le chiavi archiviate dalla CA. Queste chiavi possono contenere quelle utilizzate con EFS, messaggi di posta elettronica sicuri o qualsiasi altra attività relativa a certificati che preveda la crittografia. Le chiavi KRA devono essere memorizzate in maniera sicura dai singoli agenti di recupero chiavi e devono esistere almeno due KRA in grado di fornire un fallback qualora una delle chiavi venisse perduta.

La prima volta che un amministratore accede al controller di dominio in un dominio appena creato, si genera un criterio di ripristino predefinito a livello di dominio che utilizza un certificato autofirmato e la coppia di chiavi memorizzata nel profilo dell'amministratore sul DC. Questo certificato DRA avrà una validità di tre anni. Si consiglia di rimuovere tale certificato predefinito e di sostituirlo con certificati autofirmati con validità superiore o con certificati emessi dalla propria PKI. Se questo certificato auto firmato predefinito non viene rimosso, tre anni dopo la sua creazione EFS bloccherà la crittografia di nuovi file in tutto il dominio. Ciò avviene perché il certificato sarà allora scaduto e EFS eviterà la crittografia di qualsiasi altro dato se nei suoi criteri di ripristino è presente un certificato DRA scaduto. Benché sia possibile eseguire Windows XP e sistemi più recenti senza disporre di alcun criterio di ripristino, si consiglia vivamente di non effettuare questa operazione. Infatti, qualora un utente, per un motivo qualsiasi, perdesse l'accesso alla sua chiave di crittografia e non fosse possibile eseguirne il ripristino, tutti i suoi dati andrebbero irrevocabilmente perduti.

Come già indicato, le chiavi DRA possono essere autofirmate oppure emesse da una CA. Nella maggior parte dei casi, l'opzione migliore è un approccio ibrido, con almeno due DRA autofirmati e a lunga validità utilizzati come agente di ripristino da tutta l'organizzazione come ultima risorsa. Poiché i certificati DRA vengono distribuiti tramite gli oggetti Criteri di gruppo, dispongono delle stesse funzionalità di ereditarietà di altri oggetti Criteri di gruppo (GPO). In altre parole, l'algoritmo standard di applicazione e accumulo di oggetti Criteri di gruppo delle unità organizzative, locali, di sito e di dominio, che controlla l'applicazione di altre impostazioni dei GPO, si applica anche ai DRA. Pertanto, un'organizzazione può facilmente implementare un approccio a più livelli con i DRA, dove il gruppo IT centrale dispone dell'accesso ai DRA dell'intera azienda, ma dove anche i gruppi IT locali continuano a gestire specifiche aree di responsabilità. Questa è una risorsa preziosa, in particolare per grosse organizzazioni distribuite su una vasta area geografica, in quanto riduce la necessità di trasferire grandi quantità di dati crittografati attraverso collegamenti WAN per facilitare il ripristino dei dati. La Figura 5 mostra una tipica distribuzione di DRA a più livelli.

Figura 5** Distribuzione di DRA multilivello **

In questo caso, un utente nell'unità organizzativa Baton Rouge dispone di sei DRA per ogni file codificato: due dai suoi amministratori locali, due dal gruppo IT dell'America del Nord e due dal livello di dominio. Pertanto, se l'utente perde l'accesso ai suoi dati crittografati, li può recuperare da un DRA locale in Baton Rouge o dal gruppo IT dell'America del Nord. Come risorsa finale, se questi quattro DRA non fossero disponibili o fossero stati perduti, per recuperare i dati potrebbero intervenire i DRA a livello di dominio. Il processo è essenzialmente lo stesso a prescindere da quale DRA abbia eseguito il ripristino. Per prima cosa l'utente deve rendere i dati disponibili al DRA. È importante che il DRA adotti le misure necessarie per assicurare che la richiesta sia legittima e provenga dal vero proprietario dei dati. Fatto ciò, il DRA carica il certificato DRA, decrittografa i dati (e preferibilmente li ricodifica) e quindi li rinvia all'utente finale. Alcune organizzazioni optano inoltre per il ripristino locale: il DRA visita fisicamente l'utente in questione, carica la sua coppia di chiavi DRA nel profilo, decrittografa i dati e rimuove la coppia di chiavi. L'utente può così accedere ai suoi dati in formato testo normale e può ricodificarli con una nuova chiave. Si noti che questo approccio è molto meno sicuro in quanto la coppia di chiavi DRA viene copiata (anche se temporaneamente) nel computer locale, tuttavia ciò consente di risparmiare tempo, in particolare quando si devono recuperare grandi quantità di dati.

Si noti che se il ripristino dovesse essere fornito all'utente attraverso l'archiviazione e il recupero della chiave, la richiesta di ripristino sarebbe gestita in maniera completamente separata da questo processo. Invece di utilizzare un DRA, la richiesta di recupero chiavi dell'utente verrebbe rivolta agli amministratori dell'autorità di certificazione, i quali vagliano la richiesta e accedono all'archivio per recuperare la chiave privata dell'utente. Gli amministratori delle autorità di certificazione rendono disponibile all'utente questa chiave privata in maniera protetta, ad esempio collocandola in un sito Web protetto per il download. (Se l'utente utilizzava una smart card per memorizzare la sua chiave EFS, disponibile con Windows Vista, è necessario che anche tale chiave venga emessa nuovamente). Quando l'utente carica questa chiave nel suo profilo ottiene accesso immediato a tutti i suoi dati crittografati.

Poiché le coppie di chiavi DRA e KRA possono essere utilizzate per decrittografare dati riservati, è importante che siano adeguatamente protette. Le coppie di chiavi DRA e KRA non devono essere memorizzate nei normali profili desktop degli amministratori (i profili in cui eseguono le loro normali attività quotidiane). Ma devono essere memorizzate in maniera protetta e non in linea sulle unità floppy, ottiche o flash conservate in un luogo fisicamente protetto. Quando si dovrà effettuare nuovamente il ripristino, l'agente di recupero dati potrà caricare la coppia di chiavi su una workstation di ripristino da tali supporti, eseguire l'operazione di ripristino e rimuovere la coppia di chiavi. Alcune organizzazioni particolarmente impegnate nella protezione designano workstation dedicate per il ripristino, allo scopo di massimizzare la protezione di tali coppie di chiavi; tuttavia, non è un requisito obbligatorio per tutte le organizzazioni.

Nella prossima puntata

Una volta esaminati gli aspetti relativi alla pianificazione EFS su gestione delle chiavi, ripristino dei dati e Active Directory, il mese prossimo, nella Parte 2 di questo argomento, verranno prese in considerazione le richieste di distribuzione lato cliente. L'attenzione sarà posta su diversi argomenti: controllo dell'uso di EFS attraverso Criteri di gruppo, scelta di cosa crittografare, crittografia automatica dei dati attraverso script di accesso e miglioramenti lato client che consentiranno a Esplora risorse di utilizzare i dati protetti da EFS ancora più facilmente.

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.