 TechNet Magazine June 2007

TechNet Magazine June 2007

Protezione : Controllo dell'account utente di Windows Vista

Il controllo dell'account utente è una delle funzionalità meno apprezzate di Windows Vista. La funzione, che consente agli utenti di utilizzare diritti utente standard, è tuttavia in grado di risolvere molti dei problemi di protezione. Ecco una rassegna di alcuni dei problemi che il controllo dell'account utente consente di risolvere e una descrizione completa del funzionamento di questa nuova funzionalità.

Mark Russinovich Protezione: Suggerimenti per la protezione dei dati con Crittografia unità BitLocker

BitLocker si pone due scopi molto importanti: garantire sia la crittografia dei dati completa del volume che la convalida dell'integrità dei componenti che vengono avviati prima di Windows Vista. Questo articolo è una panoramica sul funzionamento di BitLocker e su come utilizzarlo per proteggere l'organizzazione.

Byron Hynes Protezione: Esplorazione di Windows Firewall

La mobilità ha modificato i rischi a cui sono esposti i computer e le tecniche che consentono di evitarli. Poiché i computer portatili vengono utilizzati internamente ed esternamente alla rete, sono necessari metodi di protezione dei sistemi più efficaci. Scopri come utilizzare Windows Firewall per proteggere i computer in Internet e nella tua rete interna.

Steve Riley Protezione: I nuovi ACL migliorano la protezione in Windows Vista

Gli ACL non sono stati rivoluzionati, ma sono state apportate alcune importanti modifiche che è necessario conoscere quando si gestiscono gli ACL in un ambiente Windows Vista. In questo articolo viene illustrato come siano stati modificati 30 ACL per migliorare la protezione, viene valutato l'impatto degli ACL rinnovati sull'organizzazione e viene suggerito come gestire queste modifiche nella propria infrastruttura.

Jesper Johansson Protezione: Gestione delle restrizioni hardware tramite Criteri di gruppo

L'utilizzo di chiavette USB per la memorizzazione dei dati e di altri dispositivi rimovibili semplifica la vita personale ma complica la vita professionale. Per una migliore protezione, è necessario tenere sotto controllo i dispositivi hardware che gli utenti installano sui sistemi in ufficio. Ora è possibile utilizzare i Criteri di gruppo per controllare quali dispositivi si possono utilizzare e quali no.

Jeremy Moskowitz Protezione: Quattro tecnologie di protezione che tutte le organizzazioni IT devono adottare

La maggior parte delle aziende condivide i medesimi problemi di protezione. Nel mondo connesso di oggi esistono quattro tipi generici di strumenti di protezione che tutte le organizzazioni devono assolutamente utilizzare. Nell'articolo si svela quali siano questi strumenti e si scopre come nel futuro le tecnologie coinvolte potranno collaborare per creare la soluzione di protezione perfetta.

Matt Clapham and Todd Thompson Protezione: Uno strumento nuovo e potente per la gestione dei certificati

I certificati sono un componente importante dell'infrastruttura. Quando ne scade uno, spesso la produttività subisce un arresto. Se ci si affida a un ambiente Microsoft PKI, la nuova soluzione ILM-CM (Identity Lifecycle Manager Certificate Management, gestione del ciclo di vita delle identità e gestione dei certificati) può essere d'aiuto per far sì che tutto funzioni correttamente. Nell'articolo si parla di come questo strumento possa essere utile per migliorare i processi di autenticazione e ridurre i costi di gestione dei certificati.

Kevin Dallmann Dal redattore: Problemi di protezione

Joshua Trupin Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen SQL: Domande&Risposte: Installazioni a 64 bit, allocazione della memoria cluster e altro ancora

Edited by Nancy Michell Utilità sotto i riflettori: PowerToy per l'elevazione dei privilegi degli script in Windows Vista

Controllo account utente rappresenta un importante miglioramento nella protezione, ma la possibilità di elevare le autorizzazioni è essenziale per eseguire determinate attività e funzioni amministrative. Ecco alcuni PowerToy che rendono le operazioni di elevazione più flessibili e potenti.

Michael Murgolo The Cable Guy: Il protocollo SSTP (Secure Socket Tunneling Protocol)

In Windows XP e Windows Server 2003 i protocolli VPN non funzionano per alcune configurazioni. In questo articolo vengono approfonditi alcuni problemi e sarà possibile notare come nella versione "Longhorn" di Windows Server e in Windows Vista con Service Pack 1 si ricorra al protocollo SSTP per risolverli.

Joseph Davies Windows PowerShell: Utilizzo di Active Directory

Windows PowerShell non dispone del cmdlet Get-ADSIObject, ma ciò non gli impedisce di offrire un solido supporto ADSI. In questo articolo viene fornita una presentazione degli adapter del tipo e viene spiegato come utilizzare Windows PowerShell per gli oggetti di directory.

Don Jones Hey, Scripting Guy!: Script per la sottolienatura rossa a zigzag

Esiste un modo più facile per aggiungere termini al dizionario di Microsoft Word che non farlo manualmente, una parola alla volta? E a chi non piacerebbe? Questo mese, gli Scripting Guy spiegano come creare dizionari personalizzati in Microsoft Word e come configurare Word a livello di programmazione in modo che utilizzi tali dizionari.

The Microsoft Scripting Guys Desktop file: Come evitare di perdere i dati

È sorprendente la frequenza con cui vengono persi i dati di un certo rilievo. In realtà, però, le informazioni vengono perse perché non vengono protette nel modo giusto. Scopri quali procedure seguire per proteggere i dati dell'organizzazione.

Wes Miller Taccuino: Parlare agli sviluppatori

Ottenere dagli sviluppatori la creazione di applicazioni più gestibili è più facile di quanto si creda. Dipende tutto dalla comunicazione. Gli sviluppatori vedono il software da una prospettiva diversa rispetto agli amministratori. Gli amministratori, tuttavia, parlando con gli sviluppatori possono spiegare ciò che è importante ai loro occhi e gli sviluppatori possono progettare di conseguenza del codice più aderente alle esigenze dell'organizzazione.

David Aiken Windows Confidential: Cosa vedono i nuovi utenti nel menu Start

Immagina di acquistare un computer nuovo, avviare Windows, selezionare il pulsante Start e visualizzare un menu vuoto. Esiste un motivo per cui il menu Start contiene delle applicazioni nello spazio destinato ai programmi utilizzati con maggiore frequenza anche se non ne è stato ancora utilizzato nessuno: fornire un uso immediato. Scopri come vengono scelte queste applicazioni.

Raymond Chen Lettere: Risposte alle domande degli utenti


 Protezione : Controllo dell'account utente di Windows Vista
Protezione Mark Russinovich

Controllo dell'account utente di Windows Vista
Panoramica:
  • Esecuzione con privilegi utente standard
  • Virtualizzazione del Registro di sistema e del file system
  • Elevazione dei privilegi dello stato dell'account

Il controllo dell'account utente è una delle funzionalità meno apprezzate di Windows Vista. Nella mia serie in tre parti sulle modifiche al kernel di Windows Vista, pubblicata su TechNet Magazine e disponibile in linea all'indirizzo technetmagazine.com, non ho esaminato il controllo dell'account utente perché ho ritenuto che questo argomento meritasse un articolo a parte.
In questo articolo verranno illustrati i problemi che il controllo dell'account utente è in grado di risolvere e verranno descritte l'architettura e l'implementazione delle tecnologie su cui questa funzionalità si basa. Queste tecnologie includono il refactoring delle operazioni che in precedenza richiedeva diritti amministrativi, la virtualizzazione leggera per consentire la corretta esecuzione dei programmi senza diritti amministrativi, la capacità dei programmi di richiedere in modo esplicito i diritti amministrativi e l'isolamento dei processi amministrativi dai processi non amministrativi in esecuzione sul desktop dello stesso utente.

Scopo del controllo dell'account utente
Il controllo dell'account utente ha lo scopo di consentire agli utenti di utilizzare diritti utente standard anziché diritti amministrativi. I diritti amministrativi consentono agli utenti di leggere e modificare qualsiasi parte del sistema operativo, compresi il codice e i dati di altri utenti, e persino lo stesso sistema Windows ®. Senza i diritti amministrativi gli utenti non possono accidentalmente (o deliberatamente) modificare le impostazioni di sistema né compromettere le informazioni riservate di altri utenti su computer condivisi e i malware non sono in grado di alterare le impostazioni di protezione del sistema o disattivare il software antivirus. L'esecuzione di applicazioni con i diritti utente standard può pertanto consentire di ridurre le chiamate urgenti al supporto tecnico negli ambienti aziendali, limitare l'impatto del malware, garantire un funzionamento costante dei computer domestici e proteggere i dati riservati sui computer condivisi.
Per rendere possibile l'esecuzione con un account utente standard, il controllo dell'account utente ha dovuto risolvere numerosi problemi. Innanzitutto, prima del rilascio di Windows Vista™, il modello di utilizzo di Windows è stato considerato uno dei presunti diritti amministrativi. Gli sviluppatori di software presupponevano che i relativi programmi potevano accedere e modificare qualsiasi impostazione relativa a file, chiavi del Registro di sistema o sistema operativo. Anche quando in Windows NT® sono stati introdotti meccanismi di protezione e impostazioni che consentivano di distinguere tra accessi concessi ad account utente standard e amministrativi, gli utenti venivano guidati attraverso un processo di installazione che li incoraggiava a utilizzare l'account amministrativo incorporato o un account membro del gruppo Administrators.
Il secondo problema che il controllo dell'account utente ha dovuto affrontare è rappresentato dal fatto che gli utenti necessitano talvolta di diritti amministrativi per eseguire operazioni comuni, come installazione di software, modifica dell'ora di sistema e apertura di porte nel firewall.
La soluzione del controllo dell'account utente a questi problemi consiste nella possibilità di eseguire la maggior parte delle applicazioni con diritti utente standard e di evitare l'uso di diritti amministrativi per qualsiasi tipo di operazione nonché nell'incoraggiare gli sviluppatori di software a creare applicazioni che possono essere eseguite con diritti utente standard. Il controllo dell'account utente consente di realizzare questi obiettivi fornendo la possibilità di richiedere con minore frequenza i diritti amministrativi, consentendo l'esecuzione delle applicazioni legacy con diritti utente standard, semplificando l'accesso degli utenti standard ai diritti amministrativi quando sono necessari e consentendo persino agli utenti con privilegi amministrativi di eseguire le applicazioni come utenti standard.

Esecuzione con privilegi utente standard
Un controllo completo di tutte le operazioni amministrative durante lo sviluppo di Windows Vista ha consentito di identificare molte delle attività che potrebbero essere consentite agli utenti standard senza compromettere la protezione del sistema. Ad esempio, anche le aziende che hanno adottato account utente standard per i relativi sistemi desktop Windows XP non possono rimuovere gli utenti che viaggiano di frequente dal gruppo Administrators unicamente perché Windows XP non prevede alcuna differenziazione tra la modifica del fuso orario e la modifica dell'ora di sistema. Gli utenti di computer portatili che desiderino configurare il fuso orario locale in modo che i relativi appuntamenti vengano visualizzati correttamente nel calendario durante un viaggio devono disporre del privilegio "Modifica dell'orario di sistema" (definito internamente SeSystemTimePrivilege) che, per impostazione predefinita, è concesso solo agli amministratori.
L'orario viene comunemente utilizzato nei protocolli di protezione, come Kerberos, ma il fuso orario influisce solo sulla modalità di visualizzazione dell'orario e, pertanto, Windows Vista prevede l'aggiunta di un nuovo privilegio, "Modifica del fuso orario" (SeTimeZonePrivilege), che viene assegnato al gruppo Users, come illustrato nella Figura 1. In tal modo, gli utenti di computer portatili in molte aziende hanno la possibilità di eseguire le applicazioni con account utente standard.
Figura 1 Privilegio “Modifica del fuso orario”
Figura 1 Privilegio “Modifica del fuso orario”
Windows Vista consente inoltre agli utenti standard di configurare le impostazioni WEP quando si connettono alle reti wireless, creare connessioni VPN, modificare le impostazioni di risparmio energia e installare gli aggiornamenti critici di Windows. Inoltre, questo sistema operativo fornisce le impostazioni dei Criteri di gruppo che consentono agli utenti standard di installare i driver della stampante e di altri dispositivi approvati dagli amministratori IT nonché installare i controlli ActiveX® dai siti approvati dagli amministratori.
E per quanto riguarda le applicazioni consumer e line of business (LOB) che non vengono eseguite correttamente con gli account utente standard? Sebbene alcune applicazioni software richiedano legittimamente diritti amministrativi, molti programmi memorizzano inutilmente i dati degli utenti in aree globali di sistema. Microsoft consiglia che i programmi di installazione di applicazioni globali che prevedono l'esecuzione con diritti amministrativi creino una directory all'interno della directory %Programmi% in cui memorizzare i file eseguibili e i dati ausiliari delle relative applicazioni e creino una chiave in HKEY_LOCAL_MACHINE\Software per le impostazioni delle relative applicazioni. È possibile che un'applicazione venga eseguita con account utente differenti e pertanto è consigliabile che memorizzi i dati specifici degli utenti nella directory %AppData% per utente e salvi le impostazioni per utente nel profilo del Registro di sistema dell'utente in HKEY_CURRENT_USER\ Software. Gli account utente standard non dispongono dell'accesso in scrittura alla directory %Programmi% o alla chiave HKEY_LOCAL_MACHINE\Software ma, poiché la maggior parte dei sistemi Windows viene eseguita in modalità utente singolo e la maggior parte degli utenti ha usufruito di privilegi di amministratore fino al rilascio di Windows Vista, le applicazioni che non salvano in modo corretto le impostazioni e i dati specifici degli utenti in tali posizioni continuano a funzionare comunque.
Windows Vista consente l'esecuzione di queste applicazioni legacy con account utente standard grazie alla virtualizzazione dello spazio dei nomi del file system e del Registro di sistema. Quando un'applicazione modifica un'area globale di sistema nel file system o nel Registro di sistema e questa operazione non riesce perché l'accesso viene negato, Windows reindirizza l'operazione a un'area per utente; quando l'applicazione esegue la lettura da un'area globale di sistema, Windows verifica prima la presenza di dati nell'area per utente e, se questi non sono presenti, consente di eseguire la lettura dall'area globale.
Ai fini della virtualizzazione, Windows Vista considera un processo come legacy se è un processo a 32 bit anziché a 64 bit, non viene eseguito con diritti amministrativi e non include un file manifesto che indica che è stato scritto per Windows Vista. In base a questa definizione, qualsiasi operazione che non ha origine da un processo classificato come legacy, compresi gli accessi alle condivisioni di file di rete, non è virtualizzata. Lo stato della virtualizzazione di un processo viene memorizzato come flag nel relativo token, che rappresenta la struttura di dati del kernel che tiene traccia del contesto di protezione di un processo, inclusi il relativo account utente, le appartenenze ai gruppi e i privilegi.
È possibile visualizzare lo stato della virtualizzazione di un processo aggiungendo la colonna Virtualizzazione alla pagina Processi di Gestione attività. Nella Figura 2 viene indicato che per la maggior parte dei componenti di Windows Vista, tra cui Gestione finestre desktop (Dwm.exe), Client Server Runtime Subsystem (Csrss.exe) ed Esplora risorse, la virtualizzazione è disattivata in quanto tali componenti contengono un file manifesto di Windows Vista o vengono eseguiti con diritti amministrativi e pertanto non consentono la virtualizzazione. Per Internet Explorer® (iexplore.exe) la virtualizzazione è attivata in quanto questa applicazione è in grado di ospitare più script e controlli ActiveX e deve presumere che questi elementi non sono stati scritti per funzionare in modo corretto con diritti utente standard.
Figura 2 Stato della virtualizzazione visualizzato in Gestione attività
Figura 2 Stato della virtualizzazione visualizzato in Gestione attività
Le posizioni del file system che vengono virtualizzate per i processi legacy sono %Programmi%, %ProgramData% e %SystemRoot%, escluse alcune sottodirectory specifiche. Tuttavia, tutti i file con estensioni di eseguibili, tra cui .exe, .bat, .scr, .vbs e altri, sono esclusi dalla virtualizzazione. Ne consegue che i programmi che si aggiornano automaticamente da un account utente standard non vengono eseguiti correttamente anziché creare versioni private dei relativi eseguibili non visibili a un amministratore che esegue un programma di aggiornamento globale. Per aggiungere ulteriori estensioni all'elenco delle eccezioni, inserirle nella seguente chiave del Registro di sistema ed eseguire il riavvio:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Utilizzare un tipo multistringa per delimitare più estensioni e non includere alcun punto prima del nome dell'estensione.
Le modifiche alle directory virtualizzate dai processi legacy vengono reindirizzate alla directory radice virtuale dell'utente, %LocalAppData%\VirtualStore. Se, ad esempio, un processo virtualizzato in esecuzione sul mio sistema crea C:\Windows\Application.ini, il file effettivamente creato è C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. Il componente locale del percorso evidenzia il fatto che i file virtualizzati non vengono spostati con il resto del profilo quando l'account prevede un profilo mobile.
Se in Esplora risorse si accede a una directory contenente file virtualizzati, sulla barra degli strumenti di Esplora risorse viene visualizzato il pulsante File compatibilità, come illustrato nella Figura 3. Questo pulsante consente di accedere alla sottodirectory VirtualStore corrispondente per visualizzare i file virtualizzati.
Figura 3 Il pulsante File compatibilità indica i file virtualizzati
Figura 3 Il pulsante File compatibilità indica i file virtualizzati
Nella Figura 4 viene illustrata l'implementazione della virtualizzazione del file system tramite Driver filtro virtualizzazione file LUA (%SystemRoot%\System32\Drivers\Luafv.sys). Essendo un driver di filtro del file system, questo driver è in grado di visualizzare tutte le operazioni del file system ma implementa solo le funzionalità per le operazioni dei processi legacy. È possibile osservare che questo driver modifica il percorso del file di destinazione per un processo legacy che crea un file in un'area globale di sistema ma non per un processo che esegue un'applicazione di Windows Vista con diritti utente standard. Dal punto di vista del processo legacy, l'operazione riesce quando il file viene creato in una posizione completamente accessibile dall'utente, ma le autorizzazioni predefinite per la directory \Windows negano l'accesso all'applicazione scritta per Windows Vista.
Figura 4 Virtualizzazione del file system
Figura 4 Virtualizzazione del file system
La virtualizzazione del Registro di sistema viene implementata in modo leggermente diverso rispetto alla virtualizzazione del file system. Le chiavi del Registro di sistema virtualizzate includono la maggior parte del ramo HKEY_LOCAL_MACHINE\Software, ma vi sono numerose eccezioni, tra cui:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Solo le chiavi che vengono comunemente modificate da applicazioni legacy, ma che non introducono problemi di compatibilità o interoperabilità, vengono virtualizzate. Windows reindirizza le modifiche delle chiavi virtualizzate da un'applicazione legacy alla chiave radice virtuale del Registro di sistema di un utente in HKEY_ CURRENT_USER\Software\Classes\VirtualStore. La chiave risiede nell'hive Classes dell'utente, %LocalAppData%\Microsoft\Windows\UsrClass.dat, di cui, analogamente a tutti gli altri dati dei file virtualizzati, non viene eseguito il roaming con un profilo utente mobile.
Anziché mantenere un elenco fisso di posizioni virtualizzate, come avviene in windows per il file system, lo stato della virtualizzazione di una chiave viene archiviato come flag, REG_ KEY_DONT_VIRTUALIZE, nella chiave stessa. L'utilità Reg.exe consente di visualizzare questo flag e gli altri due flag correlati alla virtualizzazione, REG_KEY_ DONT_SILENT_FAIL e REG_KEY_ RECURSE_FLAG, come illustrato nella Figura 5. Quando si imposta REG_KEY_DONT_SILENT_FAIL e la chiave non viene virtualizzata (è impostato il flag REG_KEY_DONT_VIRTUALIZE), a un'applicazione legacy, a cui verrebbe negato l'accesso all'esecuzione di un'operazione sulla chiave, viene invece concesso qualsiasi tipo di accesso di cui l'utente dispone alla chiave anziché l'accesso richiesto dall'applicazione. REG_KEY_RECURSE_FLAG indica se le nuove sottochiavi ereditano dai flag di virtualizzazione del padre anziché solo dai flag predefiniti.
Figura 5 Flag di virtualizzazione visualizzati nell'utilità Reg
Figura 5 Flag di virtualizzazione visualizzati nell'utilità Reg
Nella Figura 6 viene illustrata l'implementazione della virtualizzazione del Registro di sistema mediante Gestione configurazione, che gestisce il Registro di sistema nel kernel del sistema operativo, Ntoskrnl.exe. Come con la virtualizzazione del file system, un processo legacy che crea una sottochiave di una chiave virtualizzata viene reindirizzato alla chiave radice del Registro di sistema dell'utente, ma a un processo di Windows Vista viene negato l'accesso dalle autorizzazioni predefinite.
Oltre alla virtualizzazione del file system e del Registro di sistema, alcune applicazioni richiedono l'implementazione di ulteriori meccanismi in grado di garantirne la corretta esecuzione con diritti utente standard. Ad esempio, un'applicazione che verifica se l'account con cui viene eseguita appartiene al gruppo Administrators potrebbe in altri casi funzionare, ma non sarà possibile eseguirla se non appartiene a tale gruppo. Windows Vista definisce quindi una serie di correzioni rapide per la compatibilità tra le applicazioni in modo che tali applicazioni siano in grado di funzionare indipendentemente dall'appartenenza al gruppo in questione. Le correzioni rapide per la compatibilità applicate più comunemente alle applicazioni legacy per consentirne il corretto funzionamento con i diritti utente standard vengono illustrate nella Figura 7. I professionisti IT aziendali possono utilizzare strumenti come Application Compatibility Toolkit (ACT), disponibile all'indirizzo technet.microsoft.com/windowsvista/aa905066.aspx, e la relativa utilità Standard User Analyzer (SUA) o lo strumento LUA Buglight di Aaron Margosis per identificare i requisiti delle correzioni rapide per la compatibilità per le relative applicazioni LOB. Gli sviluppatori assegnano le correzioni rapide per la compatibilità a un'applicazione utilizzando lo strumento Compatibility Administrator, che fa parte di ACT, e distribuiscono il database di compatibilità risultante (file .sdb) sui relativi desktop tramite Criteri di gruppo. Tenere presente che, se necessario, la virtualizzazione può essere completamente disattivata per un sistema mediante un'impostazione dei criteri di protezione locali.
Figure 7 Correzioni rapide per la compatibilità per gli utenti comuni (Close Figure 7)

Correzione rapida per la compatibilità | Scopo
ElevateCreateProcess | Modifica CreateProcess per gestire gli errori di tipo ERROR_ELEVATION_REQUIRED chiamando il servizio Informazioni applicazioni per richiedere l'elevazione dei privilegi.
ForceAdminAccess | Esegue lo spoofing delle query di appartenenza al gruppo Administrators.
VirtualizeDeleteFile | Esegue lo spoofing dell'eliminazione riuscita di file e directory globali.
LocalMappedObject | Forza gli oggetti sezione globali nello spazio dei nomi dell'utente.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Reindirizza la registrazione globale di oggetti COM a un percorso distinto per ogni utente.
Effetti della virtualizzazione
È possibile modificare lo stato della virtualizzazione di un processo selezionando Virtualizzazione dal menu di scelta rapida che viene visualizzato quando si fa clic con il pulsante destro del mouse su di esso in Gestione attività. Nella Figura A viene illustrato il comportamento di un prompt dei comandi quando il relativo stato di virtualizzazione viene modificato. La virtualizzazione risulta inizialmente disattivata in quanto il prompt dei comandi include un manifesto di Windows Vista. Poiché viene eseguito con diritti utente standard, il prompt dei comandi non è in grado di creare un file nella directory \Windows, ma dopo essere stato virtualizzato con Gestione attività, riesce a creare il file in modo corretto. Quando la virtualizzazione ritorna allo stato disattivato, il prompt dei comandi non è in grado di trovare il file, che risiede in realtà nell'archivio virtuale dell'utente.
Figura A Modifica dello stato della virtualizzazione
Figura A Modifica dello stato della virtualizzazione

Modalità Approvazione amministratore
Anche se gli utenti eseguono solo programmi compatibili con i diritti utente standard, alcune operazioni richiedono tuttavia i diritti amministrativi. La maggior parte delle installazioni software richiede diritti amministrativi per la creazione di directory e chiavi del Registro di sistema in aree globali di sistema o per l'installazione di servizi o di driver di dispositivo. Anche la modifica delle impostazioni globali di sistema per Windows e le applicazioni richiede diritti amministrativi, così come la funzionalità controllo genitori di Windows Vista. Sarebbe possibile eseguire la maggior parte di queste operazioni passando a un account amministratore dedicato, ma lo svantaggio di questo approccio sta nella necessità per la maggior parte degli utenti di continuare a utilizzare l'account amministrativo per l'esecuzione delle relative attività quotidiane.
Windows Vista include pertanto la funzionalità avanzata "Esegui come" in modo da consentire agli utenti standard di avviare determinati processi con diritti amministrativi. Questa funzionalità ha richiesto l'implementazione nelle applicazioni di un metodo che consentisse di identificare le operazioni per cui il sistema può ottenere i diritti amministrativi per conto dell'applicazione, in base alle esigenze, argomento che illustrerò tra poco.
Inoltre, per consentire agli utenti che agiscono come amministratori di sistema di utilizzare diritti utente standard, ma senza dover inserire i nomi utente e le password ogni volta che desiderano accedere ai diritti amministrativi, Windows Vista fornisce la modalità Approvazione amministratore (AAM, Admin Approval Mode). Questa funzionalità crea due identità per l'utente all'accesso: una con diritti utente standard e un'altra con diritti amministrativi. Poiché ogni utente di un sistema Windows Vista è un utente standard o per la maggior parte dei casi dispone dei privilegi di esecuzione come utente standard in modalità Approvazione amministratore, gli sviluppatori devono presumere che tutti gli utenti di Windows siano utenti standard, il che determinerà una situazione in cui più applicazioni saranno in grado di funzionare con i diritti utente standard senza virtualizzazione o correzioni rapide per la compatibilità.
L'atto di conferire a un processo diritti amministrativi viene definito elevazione. Quando l'elevazione viene eseguita da un account utente standard, viene definita elevazione OTS (Over the Shoulder) in quanto richiede l'immissione di credenziali per un account membro del gruppo Administrators, un'operazione che in genere viene completata da un altro utente che digita le informazioni "sopra la spalla" dell'utente standard. Un'elevazione eseguita da un utente in modalità Approvazione amministratore viene denominata elevazione di consenso perché l'utente deve approvare semplicemente l'assegnazione dei relativi diritti amministrativi.
In Windows Vista un utente viene considerato amministratore se è membro di uno dei gruppi di amministratori elencati nella Figura 8. Molti dei gruppi elencati vengono utilizzati solo in sistemi appartenenti a un dominio e non assegnano direttamente agli utenti diritti amministrativi locali, ma consentono loro di modificare le impostazioni a livello di dominio. Se un utente è membro di uno di questi gruppi, ma non fa parte del gruppo Administrators effettivo, l'utente potrà accedere ai relativi diritti amministrativi tramite elevazioni OTS anziché elevazioni di consenso.
Figure 8 Gruppi amministrativi (Close Figure 8)

Amministratori predefiniti
Amministratori di certificati
Amministratori di dominio
Amministratori dell'organizzazione
Amministratori di criteri
Amministratori di schemi
Controller di dominio
Controller di dominio di sola lettura organizzazione
Controller di dominio di sola lettura
Operator di account
Operatori di backup
Operatori crittografici
Operatori della configurazione di rete
Operatori di stampa
Operatori di sistema
Server RAS
Utenti esperti
Accesso compatibile precedente a Windows 2000
Quando un utente appartenente a uno dei gruppi elencati esegue l'accesso, in Windows Vista viene creato un token che rappresenta la versione utente standard dell'identità amministrativa dell'utente. Il nuovo token viene privato di tutti i privilegi assegnati all'utente, eccetto quelli elencati nella Figura 9, che rappresentano i privilegi dell'utente standard predefiniti. Inoltre, tutti i gruppi di amministratori sono contrassegnati con il flag USE_FOR_DENY_ONLY nel nuovo token. Nella Figura 10 viene illustrata l'utilità Process Explorer di Sysinternals (uno strumento di gestione dei processi che è possibile scaricare da microsoft.com/technet/sysinternals) in cui vengono visualizzate le appartenenze ai gruppi e i privilegi di un processo eseguito con diritti amministrazioni nella parte sinistra e senza diritti amministrativi nella parte destra. Per impedirne l'utilizzo involontario, il modello di protezione di Windows richiede che un privilegio con il flag disattivato venga attivato prima di poter essere utilizzato.
Figure 9 Privilegi utente standard (Close Figure 9)

Nome descrittivo | Nome interno
Ignorare controllo incrociato | SeChangeNotifyPrivilege
Arresto del sistema | SeShutdownPrivilege
Rimozione del computer dall'alloggiamento | SeUndockPrivilege
Aumento di un working set di processo | SeIncreaseWorkingSetPrivilege
Modifica del fuso orario | SeTimeZonePrivilege
Figura 10 Token per l'utente standard e l'amministratore in modalità Approvazione amministratore
Figura 10 Token per l'utente standard e l'amministratore in modalità Approvazione amministratore
Un gruppo con il flag di sola negazione può essere utilizzato solo per negare l'accesso dell'utente a una risorsa, mai per consentire tale accesso, chiudendo un punto di vulnerabilità che potrebbe essere creato se il gruppo venisse rimosso completamente. Se, ad esempio, un file contenesse un elenco di controllo di accesso (ACL, Access Control List) che negasse al gruppo Administrators qualsiasi tipo di accesso, ma concedesse determinati tipi di accessi a un altro gruppo a cui l'utente appartiene, all'utente verrebbe concesso l'accesso se il gruppo Administrators fosse assente dal token, concedendo alla versione utente standard dell'identità dell'utente un numero di accessi maggiore rispetto alla relativa identità amministrativa.
I sistemi autonomi, che sono in genere rappresentati dai computer di casa, e i sistemi appartenenti a un dominio gestiscono l'accesso in modalità Approvazione amministratore da parte degli utenti remoti in modo differente in quanto i computer connessi a un dominio possono utilizzare gruppi amministrativi di dominio nelle relative autorizzazioni per le risorse. Quando un utente accede a una condivisione file di un computer autonomo, Windows richiede l'identità utente standard dell'utente remoto, mentre in sistemi appartenenti a un dominio Windows rispetta tutte le appartenenze ai gruppi di dominio dell'utente richiedendo l'identità amministrativa dell'utente.

Accesso semplificato ai diritti amministrativi
Esistono diversi metodi con cui il sistema e le applicazioni identificano la necessità di diritti amministrativi. Un metodo che viene visualizzato nell'interfaccia utente di Esplora risorse è rappresentato dall'opzione di scelta rapida e dalla voce del menu di scelta rapida "Esegui come amministratore". Questi elementi contengono l'icona di uno scudo colorato che deve essere posizionata su qualsiasi pulsante o voce di menu che determini un'elevazione di diritti qualora venga selezionata. Se si seleziona "Esegui come amministratore", in Esplora risorse, verrà chiamata l'API ShellExecute con il verb "runas".
Poiché la maggior parte dei programmi di installazione richiede diritti amministrativi, il caricatore di immagini, responsabile dell'avvio iniziale di un eseguibile, include il codice di rilevamento del programma di installazione per identificare gli eventuali programmi di installazione legacy. Alcuni dei sistemi euristici che utilizza sono piuttosto semplici, in quanto vengono impiegati semplicemente per verificare se l'immagine contiene le parole impostazione, installazione o aggiornamento nel relativo nome di file o nelle informazioni interne sulla versione; altri sono più sofisticati in quanto prevedono l'analisi delle sequenze di byte nell'eseguibile che sono comuni alle utilità wrapper di installazione di terze parti.
Il caricatore di immagini chiama inoltre la libreria di compatibilità tra applicazioni (appcompat) per verificare se l'eseguibile di destinazione richiede diritti amministrativi. La libreria controlla il database di compatibilità tra applicazioni per verificare se all'eseguibile è associato il flag di compatibilità RequireAdministrator o RunAsInvoker.
Il metodo più comune con cui un eseguibile può richiedere diritti amministrativi è includere un tag requestedElevationLevel nel relativo file manifesto dell'applicazione. I manifesti sono file XML che contengono informazioni aggiuntive su un'immagine. Questi file sono stati introdotti in Windows XP per identificare eventuali dipendenze dagli assembly DLL in modalità affiancata o dagli assembly di Microsoft .NET Framework. La presenza dell'elemento trustInfo in un manifesto (che è possibile notare nel dump di stringa estratto da Firewallsettings.exe e riportato di seguito) denota un eseguibile scritto per Windows Vista in cui è nidificato l'elemento requestedElevationLevel. L'attributo relativo al livello dell'elemento può avere uno dei tre valori seguenti: asInvoker, highestAvailable e requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Gli eseguibili che non richiedono diritti amministrativi, come Notepad.exe, specificano il valore asInvoker. Alcuni eseguibili partono dal presupposto che gli amministratori desiderino sempre il massimo livello di accesso e pertanto utilizzano il valore highestAvailable. A un utente che esegue un eseguibile con tale valore verrà richiesta l'elevazione dei privilegi solo se l'utente utilizza la modalità Approvazione amministratore o se viene considerato un amministratore in base alle regole definite in precedenza e pertanto deve assumere privilegi più elevati per accedere ai relativi diritti amministrativi. Regedit.exe, Mmc.exe ed Eventvwr.exe sono esempi di applicazioni che utilizzano il valore highestAvailable. Infine, requireAdministrator determina sempre una richiesta di elevazione e viene utilizzato da qualsiasi eseguibile che non è in grado di funzionare senza diritti amministrativi.
Le applicazioni di accessibilità specificano "true" per l'attributo uiAccess in modo da pilotare l'input della finestra dei processi con privilegi elevati e, per ottenere questo diritto, è necessario inoltre che tali applicazioni siano firmate e risiedano in una delle diverse posizioni protette, tra cui %SystemRoot% e %Programmi%.
Un metodo semplice per determinare i valori specificati da un eseguibile consiste nel visualizzare il relativo manifesto con l'utilità Sigcheck di Sysinternals, come illustrato di seguito:
sigcheck –m <executable>
L'esecuzione di un'immagine che richiede diritti amministrativi determina l'avvio di Consent.exe (%SystemRoot%\System32\Consent.exe) nel servizio Applicazioni informazioni (AIS, Application Information Service), contenuto in %SystemRoot%\System32\Appinfo.dll, che viene eseguito all'interno di un processo Host servizio (%SystemRoot%\System32\Svchost.exe). Consent acquisisce un'immagine bitmap dello schermo, vi applica un effetto di dissolvenza, passa a un desktop accessibile solo all'account di sistema locale, imposta l'immagine bitmap come sfondo e visualizza una finestra di dialogo per l'elevazione dei privilegi che contiene informazioni sull'eseguibile. La visualizzazione di un desktop separato impedisce a qualsiasi malware presente nell'account dell'utente di modificare l'aspetto della finestra di dialogo.
Figura 11 Finestre di dialogo per l'elevazione OTS
Figura 11 Finestre di dialogo per l'elevazione OTS
Se un'immagine è un componente di Windows che ha la firma digitale di Microsoft e l'immagine risiede nella directory di sistema di Windows, nella parte superiore della finestra di dialogo verrà visualizzata una striscia blu, come illustrato nella parte superiore della Figura 11. La striscia grigia (finestra di dialogo centrale) è relativa alle immagini che hanno la firma digitale di società diverse da Microsoft e la striscia arancione (finestra di dialogo inferiore) è relativa alle immagini prive di firma. Nella finestra di dialogo per l'elevazione dei privilegi vengono visualizzati l'icona, la descrizione e l'autore per le immagini con firma digitale, ma solo un'icona generica, il nome file e il messaggio "Autore non identificato" per le immagini prive di firma. Questo rende più difficoltoso per il malware imitare l'aspetto del software autorizzato. Il pulsante Dettagli nella parte inferiore della finestra di dialogo si espande per mostrare la riga di comando che verrà passata all'eseguibile nel caso in cui venga avviato. La finestra di dialogo relativa all'elevazione di consenso in modalità Approvazione amministrazione, illustrata nella Figura 12, è simile, ma anziché richiedere l'immissione di credenziali amministrative include i pulsanti Continua e Annulla.
Figura 12 Finestra di dialogo per l'elevazione in modalità Approvazione amministratore
Figura 12 Finestra di dialogo per l'elevazione in modalità Approvazione amministratore
Se un utente rifiuta un'elevazione di privilegi, in Windows verrà restituito un errore di accesso negato al processo che ha eseguito l'avvio. Quando un utente accetta un'elevazione di privilegi immettendo le credenziali di amministratore o facendo clic sul pulsante Continua, AIS chiama CreateProcessAsUser per avviare il processo con l'identità amministrativa appropriata. Sebbene AIS sia, dal punto di vista tecnico, il padre del processo con privilegi elevati, questo servizio utilizza la nuova funzionalità dell'API CreateProcessAsUser che consente di impostare l'ID processo padre del processo su quello del processo da cui è stato originariamente avviato (vedere la Figura 13). Per questo motivo, i processi con privilegi elevati non vengono visualizzati come elementi figlio del processo Host servizio di AIS in strumenti come Process Explorer, in cui vengono visualizzati gli alberi dei processi.
Figura 13 Flusso del processo di elevazione dei privilegi
Figura 13 Flusso del processo di elevazione dei privilegi
Anche se le finestre di dialogo per l'elevazione dei privilegi vengono visualizzate su un desktop protetto separato, per impostazione predefinita, gli utenti non dispongono di alcun metodo per verificare che la finestra di dialogo visualizzata sia legittima e non presentata dal malware. Questo non rappresenta un problema per la modalità Approvazione amministratore in quanto il malware non può ottenere diritti amministrativi con una finestra di dialogo di consenso non legittima. Tuttavia, il malware potrebbe attendere una richiesta di elevazione OTS di un utente standard, intercettarla e utilizzare una finestra di dialogo trojan horse per acquisire le credenziali di amministratore. Con tali credenziali i malware possono ottenere l'accesso all'account dell'amministratore e infettarlo.
Per questa ragione, non è consigliabile utilizzare le elevazioni OTS negli ambienti aziendali. Per disattivare le elevazioni OTS (e ridurre le chiamate al supporto tecnico), eseguire l'editor dei criteri di protezione locali (Secpol.msc) e configurare "Controllo account utente: comportamento della richiesta di elevazione dei privilegi per utenti standard" su "Nega automaticamente richieste di esecuzione con privilegi elevati".
Gli utenti privati che sono consapevoli dei problemi relativi alla protezione devono configurare le elevazioni OTS per richiedere una Secure Attention Sequence (SAS) che il malware non è in grado di intercettare o simulare. Per configurare SAS, eseguire l'Editor criteri di gruppo (Gpedit.msc), accedere a Configurazione computer | Modelli amministrativi | Componenti di Windows | Interfaccia utente delle credenziali e attivare "Richiedi percorso trusted per immissione credenziali". Una volta eseguite queste operazioni, verrà chiesto di premere la combinazione di tasti Ctrl + Alt + Canc per accedere alla finestra dialogo per l'elevazione dei privilegi.

Isolamento dei Processi con privilegi elevati
Windows Vista colloca una barriera intorno ai processi con privilegi elevati per proteggerli da programmi malware eseguiti sullo stesso desktop con diritti utente standard. Senza una barriera di protezione, il malware potrebbe gestire un'applicazione amministrativa inviando a tale applicazione input sintetizzati di mouse e finestra tramite messaggi finestra. Sebbene il modello di protezione di Windows standard impedisca al malware in esecuzione in un processo con diritti utente standard di compromettere un processo con diritti elevati eseguito come utente differente, non impedisce tuttavia al malware eseguito come versione diritti standard di un utente amministrativo di aprire i processi con privilegi elevati dell'utente, inserire del codice in questi processi e avviare i thread dei processi per eseguire il codice inserito.
Il meccanismo di protezione di Windows Vista per i messaggi finestra è definito User Interface Privilege Isolation (UIPI). Questa funzionalità è basata sul nuovo meccanismo di integrità di Windows che Windows Vista utilizza come la barriera di protezione per i processi con privilegi elevati. In questo nuovo modello di protezione, tutti i processi e gli oggetti hanno livelli di integrità e il criterio di integrità di un oggetto può limitare gli accessi che sarebbero altrimenti concessi a un processo dal modello di protezione DAC (Discretionary Access Control, controllo di accesso discrezionale) di Windows.
I livelli di integrità (IL) vengono rappresentati dagli identificatori di protezione (SID), che rappresentano anche gli utenti e i gruppi, dove il livello viene codificato nell'identificatore relativo (RID) del SID. Nella Figura 14 vengono illustrati il nome visualizzato, il SID e la versione esadecimale del RID del SID per i quattro livelli di integrità principali. I numeri esadecimali mostrano una distanza di 0x1000 tra ciascun livello che consente l'utilizzo dei livelli intermedi da parte delle applicazioni di accessibilità dell'interfaccia utente oltre che un'espansione futura.
Figure 14 Livelli di integrità principali (Close Figure 14)

Nome | SID | RID
Livello obbligatorio basso | S-1-16-4096 | 0x1000
Livello obbligatorio medio | S-1-16-8192 | 0x2000
Livello obbligatorio alto | S-1-16-12288 | 0x3000
Livello obbligatorio di sistema | S-1-16-16384 | 0x4000
Nella Figura 15 vengono illustrati i criteri dei livelli di integrità degli oggetti e i tipi di accesso su cui tali criteri impongono limitazioni, che corrispondono agli accessi generici definiti per un oggetto. Ad esempio, No-Write-Up impedisce a un processo con livello di integrità inferiore di ottenere gli accessi rappresentati dagli accessi di tipo GENERIC_WRITE. Il criterio predefinito per la maggior parte degli oggetti, inclusi file e chiavi del Registro di sistema, è No-Write-Up, che impedisce a un processo di ottenere l'accesso in scrittura a oggetti con un livello di integrità superiore, anche se l'elenco di controllo di accesso discrezionale (DACL) dell'oggetto concede all'utente questo tipo di accesso. Gli unici oggetti con un criterio differente sono gli oggetti processo e thread. I relativi criteri, No-Write-Up e No-Read-Up, impediscono a un processo eseguito con un livello di integrità inferiore di inserire codice ed eseguire la lettura di dati, ad esempio le password, da un processo con un livello di integrità più alto.
Figure 15 Criteri dei livelli di integrità (Close Figure 15)

Criterio | Effetto
No-Write-Up | Un processo con livello di integrità inferiore non può modificare un oggetto con livello di integrità più alto
No-Read-Up | Un processo con livello di integrità inferiore non può eseguire la lettura da un oggetto con livello di integrità più alto
No-Execute-Up | Un processo con livello di integrità inferiore non può eseguire un oggetto con livello di integrità più alto
Windows assegna a ogni processo un livello di integrità che colloca nel token del processo insieme ai SID dei gruppi a cui l'utente che esegue il processo appartiene. Nella Figura 16 vengono elencati esempi di processi assegnati a livelli di integrità differenti. I processi ereditano in genere il livello di integrità del relativo padre, ma un processo può anche avviare un altro processo con un livello di integrità differente, come avviene in AIS quando avvia un processo con privilegi elevati. È possibile visualizzare i livelli di integrità del processo con l'utilità Whoami incorporata specificando l'opzione /all oppure con l'utilità Process Explorer o AccessChk di Sysinternals. Process Explorer consente di visualizzare i livelli di integrità dei processi con l'aggiunta della colonna relativa al livello di integrità.
Figure 16 Assegnazione di livelli di integrità a processi di esempio (Close Figure 16)

Livello di integrità | Processi di esempio
Livello obbligatorio basso | Modalità protetta di Internet Explorer e processi avviati dalla modalità protetta di Internet Explorer
Livello obbligatorio medio | Processi utente standard e processi in modalità Approvazione amministratore con privilegi non elevati
Livello obbligatorio alto | Processi eseguiti con diritti amministrativi
Livello obbligatorio di sistema | Processi Sistema locale, Servizio locale e Servizio di rete
Ogni oggetto a protezione diretta ha un livello di integrità esplicito o implicito. Agli oggetti processo, thread e token è sempre assegnato un livello di integrità esplicito che in genere è identico al livello di integrità memorizzato nel token del processo corrispondente. Alla maggior parte degli oggetti è assegnato un livello di integrità esplicito e pertanto gli oggetti vengono impostati automaticamente su un livello di integrità medio. Gli unici oggetti creati con un livello di integrità diverso da quello medio sono gli oggetti creati da un processo eseguito al livello di integrità basso e a cui è pertanto assegnato un livello di integrità basso. È possibile utilizzare lo strumento iCacls incorporato (%SystemRoot%\System32\iCacls.exe) per visualizzare i livelli di integrità dei file e l'utilità AccessChk di Sysinternals per visualizzare i livelli di integrità di file, chiavi del Registro di sistema, servizi e processi. Nella Figura 17 viene mostrato che una directory a cui è necessario accedere dalla modalità protetta di Internet Explorer ha un livello di integrità basso.
Figura 17 Utilità AccessChk in cui viene visualizzato il livello di integrità della directory Preferiti di un utente
Figura 17 Utilità AccessChk in cui viene visualizzato il livello di integrità della directory Preferiti di un utente
Se un oggetto ha un livello di integrità esplicito, viene memorizzato in una voce di controllo di accesso (ACE) di un nuovo tipo di Windows Vista, Label ACE, nell'elenco di controllo di accesso di sistema (SACL) del descrittore di protezione dell'oggetto (vedere la Figura 18). Il SID nella voce ACE corrisponde al livello di integrità dell'oggetto e i flag della voce ACE codificano i criteri di integrità dell'oggetto. Prima di Windows Vista, negli elenchi di controllo di accesso di sistema venivano memorizzati solo le voci di controllo di accesso di controllo che richiedono il privilegio "Gestione file registro di controllo e di protezione" (SeSecurityPrivilege), ma la lettura di un tipo Label ACE richiede solo l'accesso Autorizzazioni di lettura (READ_CONTROL). Perché un processo possa modificare il livello di integrità di un oggetto è necessario che disponga dell'accesso Modifica proprietario in (WRITE_OWNER) all'oggetto e un livello di integrità uguale o più alto di quello dell'oggetto; il processo inoltre può impostare solo un livello di integrità uguale o inferiore a quello ad esso assegnato. Il nuovo privilegio"Modifica delle etichette di oggetti" (SeRelabelPrivilege) consente a un processo di modificare il livello di integrità di qualsiasi oggetto a cui il processo ha accesso e anche di impostare il livello di integrità su un valore superiore al livello di integrità ad esso assegnato; tuttavia, per impostazione predefinta, questo privilegio non è assegnato a tutti gli account.
Figura 18 Tipo Label ACE di un oggetto
Figura 18 Tipo Label ACE di un oggetto
Quando un processo tenta di aprire un oggetto, il controllo di integrità viene eseguito prima del controllo del DACL di Windows standard nella funzione SeAccessCheck del kernel. In base ai criteri di integrità predefiniti, un processo può aprire un oggetto per l'accesso in scrittura solo se il relativo livello di integrità è uguale o più alto del livello di integrità dell'oggetto e il DACL concede al processo il tipo di accesso desiderato. Ad esempio, un processo con livello di integrità basso non può aprire un processo con livello di integrità medio per l'accesso in scrittura, anche se il DACL concede al processo l'accesso in scrittura.
In base ai criteri di integrità predefiniti, i processi possono aprire qualsiasi oggetto, ad eccezione degli oggetti processo e thread, per l'accesso in lettura, purché il DACL dell'oggetto concede ai processi l'accesso in lettura. Ne consegue che un processo eseguito a un livello di integrità basso può aprire qualsiasi file accessibile all'account utente con cui viene eseguito. La modalità protetta di Internet Explorer utilizza i livelli di integrità per impedire al malware di modificare le impostazioni dell'account utente, ma non impedisce al malware di leggere i documenti dell'utente.
Gli oggetti processo e thread rappresentano delle eccezioni in quanto il relativo criterio di integrità include anche No-Read-Up. Ne consegue che il livello di integrità di un processo deve essere uguale o più alto del livello di integrità del processo o del thread che desidera aprire e perché l'operazione di apertura riesca, è necessario che il DACL conceda al processo il tipo di accesso desiderato. Si supponga che i DACL consentano l'accesso desiderato; nella Figura 19 vengono illustrati i tipi di accessi che i processi eseguiti con i livelli di integrità medio e basso hanno agli altri processi e oggetti.
Figura 19 Accessi a oggetti e processi
Figura 19 Accessi a oggetti e processi
Anche il sottosistema di messaggistica di Windows rispetta i livelli di integrità per implementare la funzionalità UIPI consentendo a un processo di inviare solo un numero limitato di messaggi di finestre informative alle finestre di proprietà di un processo con un livello di integrità più alto. Questo impedisce ai processi utente standard di pilotare l'input alle finestre di processi con privilegi elevati o di compromettere un processo con privilegi elevati inviando a tale processo messaggi in formato non corretto che determinano sovraccarichi del buffer interno. I processi possono scegliere di consentire a ulteriori messaggi di eludere le misure di protezione chiamando l'API ChangeWindowMessageFilter. UIPI impedisce inoltre agli hook delle finestre di influire sulle finestre dei processi con livello di integrità più alto in modo che un processo utente standard non sia in grado ad esempio di registrare i tasti premuti dall'utente in un'applicazione amministrativa.

Elevazioni e limiti di protezione
È importante tenere presente che le elevazioni di privilegi del controllo dell'account utente sono una convenienza e non un limite di protezione. Un limite di protezione richiede che i criteri di protezione stabiliscano chi o cosa può oltrepassare tale limite. Gli account utente sono un esempio di limite di protezione in Windows perché un utente non può accedere ai dati appartenenti a un altro utente senza disporre dell'autorizzazione di tale utente.
Perché le elevazioni non rappresentano limiti di protezione, non esiste alcuna garanzia che il malware eseguito su un sistema con diritti utente standard non possa compromettere un processo con privilegi elevati per ottenere diritti amministrativi. Ad esempio, le finestre di dialogo per l'elevazione dei privilegi identificano solo l'eseguibile a cui verranno concessi privilegi elevati, senza indicare le operazioni che l'eseguibile effettuerà durante l'esecuzione. L'eseguibile elaborerà gli argomenti della riga di comando, caricherà le DLL, aprirà i file di dati e comunicherà con altri processi. Ciascuna di queste operazioni potrebbe consentire a eventuali malware di compromettere il processo con diritti elevati e ottenere pertanto diritti amministrativi.
Esecuzione in una sandbox con livello di integrità basso
La modalità protetta di Internet Explorer viene eseguita con un livello di integrità basso per innalzare una barriera protettiva contro gli eventuali malware che potrebbero infettare il relativo processo. Questo impedisce al malware di modificare le impostazioni di account dell'utente e installarsi in una posizione di avvio automatico. È possibile utilizzare l'utilità PsExec di Sysinternals insieme all'opzione -l per avviare processi arbitrari con un livello di integrità basso in modo da esplorare la sandbox. Come illustrato nella Figura B, un prompt dei comandi eseguito con un livello di integrità basso non è in grado di creare un file nella directory temporanea dell'utente a cui è associato un livello di integrità medio, ma è in grado di eseguire tale operazione nella directory temporanea di Internet Explorer a cui è associato un livello di integrità basso.
Figura BIl prompt dei comandi è in grado di creare solo file con un livello di integrità simile

I processi in modalità Approvazione amministratore con privilegi elevati sono particolarmente soggetti ad attacchi di malware in quanto vengono eseguiti nello stesso account utente dei processi con diritti standard dell'utente in modalità Approvazione amministratore e condividono il profilo dell'utente. Molte applicazioni leggono le impostazioni e caricano le estensioni registrate nel profilo di un utente, offrendo al malware l'opportunità di assumere privilegi elevati. Ad esempio, le comuni finestre di dialogo di controllo caricano le estensioni Shell configurate nella chiave del Registro di sistema di un utente (in HKEY_CURRENT_USER), fornendo pertanto al malware la possibilità di aggiungersi come estensione in modo da essere caricato in qualsiasi processo con privilegi elevati che utilizza queste finestre di dialogo.
Anche i processi elevati da account utente standard possono essere compromessi a causa dello stato di condivisione. Tutti i processi eseguiti in una sessione di accesso condividono lo spazio dei nomi interno in cui Windows memorizza oggetti come eventi, mutex, semafori e memoria condivisa. Se il malware sa che un processo con privilegi elevati tenterà di aprire e leggere uno specifico oggetto memoria condivisa all'avvio del processo, potrebbe creare l'oggetto con contenuti che determinano un sovraccarico del buffer in modo da inserire del codice nel processo con privilegi elevati. Questo tipo di attacco è relativamente sofisticato, ma impedisce che le elevazioni OTS rappresentino un limite di protezione.
La conclusione è che le elevazioni sono state introdotte per convenienza in modo da incoraggiare gli utenti che desiderano accedere ai diritti amministrativi a utilizzare, per impostazione predefinita, i diritti utente standard. Gli utenti che desiderano le garanzie di un limite di protezione possono rinunciare alla comodità utilizzando un account utente standard per le attività quotidiane e la funzionalità Cambio rapido utente (FUS, Fast User Switching) per passare a un account amministratore dedicato per eseguire le attività amministrative. D'altra parte, gli utenti che desiderano rinunciare alla protezione a favore della comodità possono disattivare il controllo dell'account utente su un sistema nella finestra di dialogo Account Utente del Pannello di controllo, tenendo presente tuttavia che questa operazione determina la disattivazione della modalità protetta di Internet Explorer.

Conclusioni
L'esecuzione con privilegi utente standard offre numerosi vantaggi, tra cui la garanzia della protezione dei sistemi da danni accidentali o volontari e la protezione dei dati e dell'integrità degli utenti che condividono un sistema da accessi non autorizzati. Le diverse modifiche e tecnologie alla base del controllo dell'account utente avranno come risultato l'introduzione di un cambiamento sostanziale nel modello di utilizzo di Windows. Con Windows Vista, gli utenti di Windows sono per la prima volta in grado di eseguire gran parte delle attività quotidiane e la maggior parte delle applicazioni software con diritti utente standard e molte aziende hanno ora la possibilità di distribuire account utente standard.

Mark Russinovichè un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) e spesso partecipa come oratore a conferenze su IT e sviluppo. È entrato in Microsoft dopo la recente acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato le utilità Process Explorer, Filemon e Regmon.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Protezione: Suggerimenti per la protezione dei dati con Crittografia unit&#224; BitLocker
Protezione Byron Hynes

Suggerimenti per la protezione dei dati con Crittografia unità BitLocker
Panoramica:
  • Crittografia completa dei volumi
  • Chiavi di BitLocker
  • Configurazione di BitLocker

Crittografia unità BitLocker di Windows è senza dubbio una delle funzionalità più discusse di Windows Vista. Tuttavia, la maggior parte degli utenti non ha ancora avuto l'opportunità di testare BitLocker per esplorarne di prima mano
le potenzialità e la modalità di funzionamento, in particolare su un computer con un TPM (Trusted Platform Module). In questo articolo viene presentata un'introduzione ai concetti fondamentali alla base di BitLocker™ in modo da consentire la valutazione delle relative potenzialità e includerlo nel proprio piano di aggiornamento. Verranno prima fornite alcune informazioni generali e concettuali, successivamente verranno analizzati la modalità di attivazione di BitLocker, il ripristino dei dati e l'amministrazione e infine verrà illustrato come BitLocker può rivelarsi un valido aiuto alla fine del ciclo di vita di un computer. Per comprendere meglio la terminologia utilizzata in questo articolo, è opportuno dare un'occhiata al riquadro "Dischi e volumi".
Dischi e volumi
La terminologia relativa a dischi e volumi può generare in molti casi confusione. Di seguito viene riportato un glossario abbreviato da utilizzare come riferimento.
Partizione: una partizione è una sezione di unità disco rigido fisica. È una struttura logica definita in una tabella di partizione memorizzata sul disco.
Volume: un volume è una struttura logica in Windows costituita da una o più partizioni e definita da un componente di Windows denominato gestore dei volumi. Ad eccezione del gestore dei volumi e dei componenti di avvio, il resto del sistema operativo e le applicazioni utilizzano i volumi, non le partizioni. Nel caso dei sistemi operativi client di Windows, compreso Windows Vista, tra le partizioni e i volumi esiste in genere una relazione uno-a-uno. Nei server, un volume è in genere costituito da più partizioni, ad esempio in una configurazione RAID tipica.
Partizione attiva: è possibile contrassegnare come partizione attiva una sola partizione per volta. La partizione attiva è la partizione che contiene il settore di avvio utilizzato per avviare il sistema operativo. La partizione attiva viene talvolta denominata partizione di sistema o volume di sistema; prestare tuttavia attenzione a non confondere questi termini con il volume del sistema operativo Windows.
Volume del sistema operativo Windows: questo volume contiene l'installazione di Windows, comprese le cartelle System e System32. Prima del rilascio di Windows Vista, veniva utilizzato il termine partizione di avvio (tutt'ora utilizzato in molti casi). Il termine volume del sistema operativo Windows è più chiaro, consentendo di eliminare la confusione senza fine tra i termini partizione di avvio e partizione di sistema. In passato, gli istruttori erano soliti ricordare agli studenti che "l'avvio viene eseguito dalla partizione di sistema e i file di sistema si trovano nella partizione di avvio".
Prima di Windows Vista, non vi era alcuna differenza tra il volume del sistema operativo Windows (noto anche come partizione di avvio) e la partizione attiva (nota anche come partizione di sistema), in quanto i dischi rigidi in molti computer client erano configurati come una singola partizione di grandi dimensioni. Nella Figura A vengono illustrate le funzioni assegnate a ciascuna partizione o volume nella console Gestione disco di Windows Vista.
Figura A Funzioni delle partizioni
Figura A Funzioni delle partizioni

BitLocker svolge due funzioni che sono complementari ma distinte. Primo, BitLocker offre la crittografia completa dei volumi per il volume del sistema operativo Windows®. Secondo, sui computer con un TPM compatibile, BitLocker fornisce un metodo per verificare l'integrità dei componenti che intervengono nelle fasi iniziali dell'avvio prima di consentire l'avvio di Windows Vista.
Per utilizzare tutte le funzionalità di BitLocker, è necessario che il computer sia dotato di un microchip TPM e un BIOS compatibili. Con il termine "compatibile" si intende un TPM versione 1.2 e un BIOS che supporta il TPM e il meccanismo SRTM (Static Root of Trust Measurement) come definito dal Trusted Computing Group (TCG). Tuttavia, anche i computer senza un TPM e un BIOS compatibili possono utilizzare la crittografia BitLocker.

Crittografia completa dei volumi
BitLocker offre la crittografia completa dei volumi per assicurare che tutti i dati scritti nel volume del sistema operativo Windows vengano crittografati. La crittografia è fondamentale per proteggere le informazioni riservate archiviate nei computer dell'organizzazione, in particolare nei computer portatili.
I computer portatili vengono persi o rubati ogni giorno. Grazie alla maggiore capacità di archiviazione dei computer portatili e a una forza lavoro sempre più mobile, un singolo utente è in grado di portare con sé centinaia di gigabyte di segreti industriali dell'organizzazione, di documenti riservati o di informazioni personali dei clienti. Utilizzando un qualsiasi servizio per la ricerca di notizie si potrà rilevare che ogni giorno viene persa una quantità eccessiva di dati. Il Privacy Rights Clearinghouse afferma che a partire dal 2005 sono stati persi o rilasciati oltre 104 milioni di record contenenti informazioni personali.
La maggior parte delle organizzazioni è già impegnata, in ottemperanza a mandati legali e aziendali, nella tutela della riservatezza di diversi tipi di informazioni private; tuttavia, pur in assenza di un obbligo legale, è probabile che molte aziende intraprendano un'iniziativa di questo tipo sulla spinta di un importante interesse commerciale.

Perché crittografare l'intero volume?
Un amministratore di Windows esperto avrà probabilmente già familiarità con le opzioni di crittografia basate su Windows come Crittografia file system (EFS) e la crittografia e la protezione fornite da Rights Management Services (RMS). La differenza principale con BitLocker risiede nel fatto che questo tipo di crittografia, una volta attivato, è automatico, trasparente e coinvolge l'intero volume.
Ad esempio, con EFS, è necessario indicare specificamente quali file e cartelle dovranno essere protetti. In Windows Vista sono disponibili alcune nuove opzioni che rendono EFS più flessibile; inoltre, sia EFS che RMS soddisfano i requisiti di alcuni scenari che BitLocker non è in grado di gestire. Tuttavia, sia EFS che RMS richiedono significative attività di configurazione da parte dell'amministratore e queste funzionalità non sono progettate per proteggere tutti i dati archiviati nel volume.
Al contrario, BitLocker consente di crittografare tutti gli elementi scritti in un volume protetto da BitLocker, compresi il sistema operativo, il Registro di sistema, i file di sospensione e di paging, le applicazioni e i dati utilizzati dalle applicazioni.
Tre elementi non sono crittografati: il settore di avvio, qualsiasi settore danneggiato già contrassegnato come illeggibile e i metadati del volume. I metadati del volume sono costituiti da tre copie ridondanti di dati utilizzati per gestire BitLocker, comprese le informazioni statistiche sul volume e le copie protette di alcune chiavi di decrittografia. Questi elementi non richiedono la crittografia perché non sono univoci e non rappresentano informazioni preziose o che consentono l'identificazione personale dell'utente.
La crittografia completa dei volumi garantisce la protezione dagli attacchi non in linea, ovvero tipi di attacchi realizzati con l'intento di eludere le funzionalità di protezione del sistema operativo. Ad esempio, un comune attacco non in linea prevede il furto di un computer, la rimozione dell'unità disco rigido e l'installazione di questa unità come seconda unità in un altro computer (eseguendo una copia differente di Windows o un diverso sistema operativo) per evitare le autorizzazioni NTFS e le password degli utenti. Non è possibile leggere un volume protetto da BitLocker utilizzando questo tipo di attacco.

Modalità di crittografia dei dati con BitLocker
BitLocker utilizza l'algoritmo AES (Advanced Encryption Standard) con chiavi a 128 bit. Per garantire un più elevato livello di protezione, è possibile sostituire le chiavi con chiavi a 256 bit utilizzando Criteri di gruppo o il provider Strumentazione gestione Windows (WMI) di BitLocker.
Ogni settore del volume viene crittografato singolarmente e una parte della chiave di crittografia viene derivata dallo stesso numero di settore. Ne consegue che due settori contenenti dati non crittografati identici determinano la scrittura sul disco di byte crittografati differenti, rendendo molto più difficoltosa l'individuazione di chiavi mediante la creazione e la crittografia di informazioni note.
Prima che i dati vengano crittografati mediante AES, BitLocker utilizza anche un algoritmo denominato diffusore. Senza addentrarci nei meccanismi della crittografia, un diffusore può essere descritto come un algoritmo che assicura che anche modifiche minime al testo normale determinino la modifica dell'intero settore nel testo crittografato. Anche questo meccanismo rende molto più difficoltosa l'individuazione di chiavi o dati da parte di un utente malintenzionato.
Se si desidera esplorare nei dettagli l'algoritmo di crittografia di BitLocker, è possibile leggere l'articolo di Neil Ferguson dedicato a questo argomento all'indirizzo "Diffusore AES-CBC + Elephant: un algoritmo di crittografia del disco per Windows Vista".

Chiavi di BitLocker
Ogni volta che viene trattato il tema della crittografia entrano in gioco le chiavi e BitLocker non fa eccezione. BitLocker utilizza un'architettura di chiavi elegante, ma piuttosto complessa.
I settori vengono crittografati mediante una chiave chiamata chiave di crittografia completa dei volumi (FVEK, Full-Volume Encryption Key). La chiave FVEK, tuttavia, non viene utilizzata né è accessibile dagli utenti. La chiave FVEK viene a sua volta crittografata con una chiave denominata chiave master del volume (VMK). Questo livello di astrazione offre alcuni importanti vantaggi, ma può rendere un po' più difficoltosa la comprensione del processo. La chiave FVEK viene conservata come un segreto gelosamente custodito in quanto, nel caso venisse compromessa, sarebbe necessario crittografare nuovamente tutti i settori, operazione che è opportuno evitare in quanto piuttosto onerosa in termini di tempo. Il sistema funziona correttamente con la chiave VMK.
La chiave FVEK (crittografata con VMK) viene memorizzata sul disco, come parte dei metadati del volume. Sebbene la chiave FVEK venga memorizzata localmente, non viene mai scritta su disco in formato non crittografato.
Anche la chiave VMK viene crittografata o "protetta", ma da una o più protezioni con chiave. La protezione con chiave predefinita è rappresentata dal TPM. L'utilizzo di un TPM verrà trattato nella sezione riportata di seguito sul controllo di integrità. Per i casi di emergenza, viene creata come protezione con chiave anche una password di ripristino. Anche il ripristino verrà trattato più avanti in questo articolo.
Per garantire una maggiore protezione, è possibile combinare il TPM con un codice PIN numerico o con una chiave parziale memorizzata su un unità USB. Ciascuno di questi elementi è una forma di autenticazione a due fattori. Se il computer in uso non è dotato di un chip TPM e BIOS compatibili, è possibile configurare BitLocker in modo che una protezione con chiave venga completamente memorizzata su un'unità USB. Questo tipo di chiave viene definito chiave di avvio.
È possibile disattivare BitLocker senza eseguire la decrittografia dei dati; in questo caso, la chiave VMK viene protetta solo da una nuova protezione con chiave che viene memorizzata in formato non crittografato. Notare che questa chiave di cancellazione consente al sistema di accedere all'unità come se non fosse protetta.
All'avvio, il sistema cerca una protezione con chiave appropriata eseguendo una query sul TPM, controllando le porte USB o, se necessario, facendo richiesta all'utente della suddetta protezione (ripristino). L'individuazione di una protezione con chiave consente a Windows di decrittografare la chiave VMK, che esegue la decrittografia della chiave FVEK che, a sua volta, esegue la decrittografia dei dati memorizzati su disco. Il processo è illustrato nella Figura 1.
Figura 1 Processo di avvio predefinito di BitLocker
Figura 1 Processo di avvio predefinito di BitLocker

Controllo di integrità
Poiché i componenti nella fase iniziale del processo di avvio devono essere disponibili in formato non crittografato in modo da consentire l'avvio del computer, un utente malintenzionato potrebbe modificare il codice in questi componenti (si pensi al rootkit) e successivamente ottenere l'accesso al computer, anche se i dati sul disco sono stati crittografati.
Utilizzando questo tipo di attacco, un intruso potrebbe ottenere l'accesso a informazioni riservate, ad esempio le chiavi di BitLocker o le password degli utenti, e utilizzare tali informazioni per aggirare altri meccanismi di protezione.
Impedire questo tipo di attacco è stato uno dei primi obiettivi del programma e del team che ha creato BitLocker. Sotto alcuni aspetti, la crittografia è stata soprattutto un mezzo per raggiungere un fine. La crittografia completa dei volumi consente a BitLocker di proteggere l'integrità del sistema e impedire l'avvio di Windows se i componenti delle fasi iniziali dell'avvio sono stati modificati.
Sui computer dotati di un TPM compatibile, a ogni avvio del computer, ciascuno dei componenti delle fasi iniziali dell'avvio, come il BIOS, il record di avvio principale (MBR, Master Boot Record), il settore di avvio e il codice ed il codice di Boot Manager, esamina il codice da eseguire, calcola un valore hash e memorizza il valore in specifici registri del TPM chiamati registri di configurazione di piattaforma (PCR). Una volta memorizzato un valore in un PCR, il valore non può essere sostituito o cancellato a meno che il sistema non venga riavviato. BitLocker utilizza il TPM e i valori memorizzati nei PCR per proteggere la chiave VMK.
Un TPM può creare una chiave associata a specifici valori dei PCR. Quando questo tipo di chiave viene creato, il TPM esegue la crittografia della chiave che può essere decrittografata solo dallo stesso TPM. Inoltre, il TPM esegue la decrittografia della chiave solo se i valori dei PCR correnti corrispondono ai valori specificati durante la creazione della chiave. Questo processo viene detto sealing della chiave nel TPM.
Per impostazione predefinita, BitLocker esegue il sealing delle chiavi in base alle misurazioni del CRTM (Core Root of Trust Measurement), al BIOS e alle estensioni della piattaforma, al codice ROM facoltativa, al codice MBR, al settore di avvio NTFS e a Boot Manager. Se si apportano modifiche non previste a uno di questi elementi, BitLocker bloccherà l'unità e ne impedirà l'accesso o la decrittografia.
Per impostazione predefinita, BitLocker è configurato per la ricerca e l'utilizzo di un TPM. È possibile utilizzare Criteri di gruppo o un'impostazione dei criteri locali per consentire a BitLocker di funzionare senza un TPM e memorizzare le chiavi in un'unità flash USB esterna; tuttavia, senza un TPM, BitLocker non sarà in grado di verificare l'integrità del sistema.

Prima attivazione di BitLocker
BitLocker è disponibile in Windows Vista Enterprise e Windows Vista Ultimate. BitLocker verrà inoltre fornito come componente facoltativo con la prossima versione di Windows Server®, nome in codice "Longhorn".
La sezione riportata di seguito presume che si disponga di un computer con un TPM compatibile disponibile per il test. Se si desidera attivare BitLocker su un computer non dotato di un TPM, seguire la procedura nell'intestazione laterale "Utilizzo di BitLocker senza un TPM".
Utilizzo di BitLocker senza un TPM
BitLocker è configurato per impostazione predefinita per l'utilizzo di un TPM e, se non si dispone di un TPM, Windows non consentirà di attivare BitLocker. Tuttavia, la procedura riportata di seguito, che è stata tratta dalla Guida dettagliata a Crittografia unità BitLocker di Windows, consentirà di utilizzare BitLocker senza un TPM.
Per eseguire questi passaggi, è necessario eseguire l'accesso come amministratore. Anche senza un TPM, è necessario che il computer in uso supporti la lettura da un'unità flash USB durante il processo di avvio. Inoltre, è necessario che sia disponibile un'unità flash USB durante l'attivazione di BitLocker e ogni volta che il computer viene riavviato.
Per attivare Crittografia unità BitLocker su un computer senza un TPM compatibile, attenersi alla seguente procedura:
  1. Fare clic sul pulsante Start, digitare gpedit.msc nella casella Inizia ricerca e premere INVIO.
  2. Se viene visualizzata la finestra di dialogo Controllo account utente, verificare che quella proposta sia l'azione desiderata e scegliere Continua.
  3. Nell'albero della console Editor oggetti Criteri di gruppo, fare clic su Criteri del computer locale, su Modelli Amministrativi, quindi su Componenti di Windows e infine fare doppio clic su Crittografia unità BitLocker.
  4. Fare doppio clic su Impostazione del Pannello di controllo: attivazione opzioni di avvio avanzate. Verrà visualizzata la finestra di dialogo Impostazione del Pannello di controllo: attivazione opzioni di avvio avanzate.
  5. Selezionare l'opzione Abilitato e la casella di controllo Consenti BitLocker senza un TPM compatibile, quindi scegliere OK. A questo punto, è stata modificata l'impostazione dei criteri ed è pertanto possibile utilizzare una chiave di avvio anziché un TPM.
  6. Chiudere Editor oggetti Criteri di gruppo.
  7. Per forzare l'applicazione immediata di Criteri di gruppo, è possibile fare clic sul pulsante Start, digitare gpupdate.exe /force nella casella Inizia ricerca e premere INVIO. Attendere il completamento del processo.

Una fase importante del processo di attivazione di BitLocker è assicurare che i volumi vengano configurati in modo corretto. BitLocker richiede che la partizione attiva sia decrittografata in modo da consentire la lettura del settore di avvio, di Boot Manager e del programma di caricamento di Windows (questi componenti vengono protetti eseguendo la procedura per l'integrità del sistema descritta in precedenza). Poiché gli altri componenti di Windows possono richiedere l'uso temporaneo della partizione attiva, Microsoft consiglia che la partizione attiva sia almeno di 1,5 GB. È consigliabile inoltre configurare le autorizzazioni NTFS in modo che gli utenti non siano in grado di scrivere accidentalmente i dati in questo volume.
Lo stesso sistema Windows verrà installato in un altro volume di maggiori dimensioni, che può essere crittografato. Se si installa Windows in un nuovo sistema, è possibile configurare manualmente i volumi seguendo le istruzioni disponibili nella Guida dettagliata a Crittografia unità BitLocker di Windows.
È possibile utilizzare lo strumento BitLocker Drive Preparation Tool per configurare il sistema per BitLocker. Questo strumento consente di semplificare la procedura di configurazione delle unità ed è disponibile come funzionalità aggiuntiva di Windows Vista Ultimate o ai clienti che distribuiscono Windows Vista Enterprise. Per istruzioni dettagliate su BitLocker Drive Preparation Tool, visitare il sito Web all'indirizzo support.microsoft.com/kb/930063.
BitLocker Drive Preparation Tool consente di ridurre automaticamente il volume (se si dispone di un solo volume), creare la seconda partizione, renderla attiva, apportare tutte le modifiche di configurazione necessarie e spostare i file di avvio nella posizione appropriata.
Una volta configurati i volumi, l'attivazione di BitLocker si rivelerà estremamente semplice. Nella sezione Protezione del Pannello di controllo, fare clic sull'icona Crittografia unità BitLocker. Dopo aver seguito le istruzioni della richiesta di consenso del controllo dell'account utente, viene visualizzata una schermata simile a quella riportata nella Figura 2.
Figura 2 Attivazione di BitLocker
Figura 2 Attivazione di BitLocker
La sequenza esatta dei passaggi successivi varia a seconda dello stato del chip TPM nel computer. Se il chip TPM non è inizializzato, verrà eseguita l'Inizializzazione guidata TPM. Seguire le istruzioni per inizializzare il TPM, che prevedono il riavvio del computer.
Dopo aver inizializzato il TPM, verrà visualizzata la pagina Salva la password di ripristino, come illustrato nella Figura 3. Per essere in grado di ripristinare i dati in caso di errore del TPM o di problemi di altro tipo, è necessaria una password di ripristino. Questa pagina consente di salvare una password di ripristino in un'unità flash USB o in un'unità disco locale o di rete oppure di stamparla per conservarla in un luogo sicuro. È necessario selezionare almeno una di queste opzioni ed è possibile scegliere di salvare più copie. Una volta salvata la password di ripristino, si attiverà il pulsante Avanti. Fare clic su questo pulsante.
Figura 3 Salvataggio della password di ripristino
Figura 3 Salvataggio della password di ripristino
Verrà visualizzata la pagina Crittografare il volume selezionato e sarà possibile scegliere se eseguire o meno un controllo del sistema prima dell'avvio della crittografia. Il controllo del sistema richiede il riavvio del computer, ma rappresenta il metodo migliore per assicurare che il TPM, il BIOS e le porte USB funzionino in modo corretto con BitLocker. Dopo il riavvio, qualora venissero rilevati eventuali problemi, viene visualizzato un messaggio di errore. In caso contrario, viene visualizzata la barra di stato Crittografia in corso.
Niente altro. La crittografia verrà completata in background e sarà possibile continuare a utilizzare il computer. Una volta completata la crittografia iniziale, verrà visualizzato un messaggio di conferma. È inoltre possibile monitorare in tempo reale lo stato di completamento della crittografia del volume del disco posizionando il cursore del mouse sull'icona Crittografia unità BitLocker nella barra degli strumenti, nella parte inferiore dello schermo. Per ulteriori dettagli, fare riferimento alla Guida dettagliata citata in precedenza.
Alcuni utenti sono rimasti sorpresi nello scoprire che BitLocker non visualizza alcuna richiesta all'utente e garantisce l'assenza di qualsiasi tipo di interruzione quando il computer viene avviato. La ragione risiede nella configurazione predefinita di BitLocker che prevede la verifica dell'integrità del sistema tramite il TPM prima di sbloccare il volume. Questa operazione avviene in modo automatico e trasparente per l'utente.
È possibile configurare BitLocker in modo che richieda l'immissione di un codice PIN o la presenza di una chiave memorizzata su un'unità flash USB all'avvio. Questa configurazione garantisce un più elevato livello di protezione ed è consigliata per le situazioni in cui la maggiore protezione fa passare in secondo piano gli inconvenienti derivanti dall'immissione del codice PIN, ovvero sempre, a mio avviso. In altre parole il desktop richiede un PIN e il computer portatile richiede una chiave USB.

Ripristino di BitLocker
Quando si utilizza la crittografia, in particolare in un ambiente aziendale, è essenziale disporre di un metodo che consenta a un utente autorizzato di ripristinare i relativi dati, anche se non sono disponibili le chiavi o i normali metodi di accesso. In BitLocker questa capacità viene definita ripristino.
Se vengono apportate modifiche non previste ai componenti delle fasi iniziali dell'avvio, una chiave di avvio USB viene persa o un utente dimentica il proprio codice PIN, BitLocker non sarà in grado di completare il normale processo di avvio. BitLocker lascerà bloccato il volume e Windows non sarà in grado di avviarsi. Il codice di BitLocker in Boot Manager presenterà una schermata di testo. Se una password di ripristino è stata salvata su un'unità flash USB (talvolta chiamata chiave di ripristino), verrà visualizzata una schermata simile a quella illustrata nella Figura 4.
Figura 4 Ricerca di una chiave di ripristino
Figura 4 Ricerca di una chiave di ripristino
Perché BitLocker sia in grado di leggere un'unità flash USB, è necessario che in fase di avvio sia connesso. Pertanto, se si dispone di un'unità flash USB con una password di ripristino, inserirla e premere ESC. In caso contrario, premere INVIO per visualizzare la schermata illustrata nella Figura 5. Questa schermata verrà visualizzata anche nel caso in cui non si sia salvato una chiave di ripristino su un'unità USB.
Figura 5 Immissione di una password BitLocker
Figura 5 Immissione di una password BitLocker
BitLocker, a questo punto, esegue la ricerca di una password numerica composta da 48 cifre in grado di sbloccare l'unità. Questo numero viene visualizzato nella pagina se si sceglie di stampare la password di ripristino; inoltre verrà memorizzato in un file se la password di ripristino è stata salvata in una cartella.
Il metodo più semplice per gestire le password di ripristino in un ambiente aziendale consiste nel memorizzarle automaticamente in Active Directory®. Informazioni dettagliate su come eseguire questa operazione sono disponibili sul sito Web all'indirizzo go.microsoft.com/fwlink/?LinkId=87067.
In un articolo successivo prenderò in esame la gestibilità di BitLocker, ma come parte di questa panoramica, è importante sapere che BitLocker viene fornito con un provider WMI completo che consente la gestione di BitLocker (e del TPM) tramite l'uso di qualsiasi sistema WBEM (Web-Based Enterprise Management) compatibile con WMI. Ne consegue che è possibile scrivere script per BitLocker utilizzando qualsiasi linguaggio di script in grado di accedere a oggetti WMI, come VBScript o Windows PowerShell™.
BitLocker viene inoltre fornito con uno strumento da riga di comando, denominato manage-bde.wsf, che utilizza il provider WMI per consentire la gestione di BitLocker su computer locali o remoti. Per ulteriori informazioni, avviare un prompt dei comandi con privilegi elevati e digitare manage-bde.wsf /?.

Rimozione sicura delle autorizzazioni
Può accadere che si verifichino situazioni in cui si renda necessaria la rimozione delle autorizzazioni per un computer. Le aziende investono in genere significativi capitali e un notevole impegno per assicurare che le unità disco siano completamente pulite prima di essere rilasciate. Molti dei processi che rimuovono dati riservati dalle unità disco sono dispendiosi in termini di tempo e di denaro o determinano l'eliminazione permanente dell'hardware. BitLocker fornisce altre opzioni più vantaggiose.
Anziché preoccuparsi di rimuovere i dati dopo un'eventuale infezione, BitLocker assicura innanzitutto che vengano evitati tutti i rischi associati alla memorizzazione dei dati riservati su disco. Poiché tutti i dati scritti nel disco sono crittografati, è possibile renderli completamente inaccessibili in modo permanente distruggendo tutte le copie delle chiavi di crittografia. Il disco rigido stesso rimane completamente intatto e può essere riutilizzato.
È possibile scegliere tra diversi approcci per la rimozione delle autorizzazioni dei volumi protetti da BitLocker. È possibile scegliere di eliminare tutte le copie delle chiavi dai metadati del volume, ma di archiviarle in un sito centrale protetto. In tal modo, i sistemi potranno essere trasportati senza rischi o sarà possibile rimuoverne temporaneamente le autorizzazioni se vengono lasciati incustoditi per lunghi periodi di tempo. Questo approccio assicura inoltre che i dati siano accessibili solo agli utenti autorizzati, impedendo l'accesso a tutti gli utenti non autorizzati, ad esempio i nuovi proprietari dell'apparecchiatura.
È inoltre possibile scegliere di eliminare tutte le copie di chiavi dai metadati del volume e da tutti gli archivi, come Active Directory (creando eventualmente nuove chiavi che non vengono memorizzate). In tal caso, poiché non esistono chiavi di decrittografia, nessun utente sarà in grado di recuperare i dati.
In entrambi questi casi, la rimozione e la distruzione delle chiavi contenute nei metadati del volume sono quasi immediate e possono essere eseguite su più sistemi da un amministratore. Questo metodo richiede un investimento minimo di tempo e di impegno ma garantisce un livello piuttosto elevato di protezione permanente. L'utilità di formattazione in Windows Vista è stata aggiornata in modo che sia possibile utilizzare un comando di formattazione per eliminare i metadati del volume e sovrascrivere tali settori per eliminare in sicurezza tutte le chiavi di BitLocker.

Alcune considerazioni finali
BitLocker è uno strumento potente progettato per garantire la protezione da rischi specifici, consentendo di ottenere risultati ottimali. Tuttavia, sarebbe un errore aspettarsi che BitLocker sia in grado di assicurare la protezione da tutti i tipi di rischi. È assolutamente fondamentale continuare a utilizzare meccanismi di difesa e controllo appropriati, come le password complesse.
Tenere presente che BitLocker è progettato per far fronte agli attacchi non in linea. Ne consegue che se Windows è in esecuzione, BitLocker ha sbloccato il volume. In altre parole, BitLocker non garantisce la protezione di un sistema in esecuzione. Tecnologie come EFS e RMS integrano BitLocker garantendo la protezione delle informazioni mentre il sistema operativo è in esecuzione.
Per ulteriori informazioni su BitLocker, visitare il sito Web Microsoft all'indirizzo technet.microsoft.com/windowsvista/aa905065.aspx. Per ulteriori informazioni sulle specifiche TPM e su TCG, consultare la sezione delle specifiche TPM del sito Web TCG all'indirizzo go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes fa parte del team Windows Server User Assistance di Microsoft. In passato ha lavorato come consulente e istruttore. È possibile contattarlo all'indirizzo bhynes@microsoft.com.


 Protezione: Esplorazione di Windows Firewall
Protezione Steve Riley

Esplorazione di Windows Firewall
Panoramica:
  • Protezione in entrata e in uscita
  • Windows Filtering Platform
  • Interfaccia di protezione avanzata
  • Profili di rete

Agli albori dell'era informatica, nessuno aveva mai pensato di installare firewall su singoli computer. Chi ne aveva bisogno? Pochissimi avevano sentito parlare di Internet, TCP/IP era ancora lontano e i protocolli LAN non venivano inoltrati al di là del proprio edificio o campus. I dati di un certo rilievo venivano conservati nel
mainframe o in file server. Le informazioni che gli utenti conservavano nei propri computer desktop erano raramente di importanza critica, pertanto si riusciva a mantenere un livello di protezione adeguato. Se era disponibile una connessione Internet, probabilmente erano disponibili alcuni convertitori di protocolli e un router di filtraggio dei pacchetti (ossia il "firewall"), configurati con molta probabilità con troppe regole ed eccezioni.
Gli ambienti informatici moderni sono molto diversi da quelli del passato. Oggi tutto è connesso a Internet (si parla di TCP/IP) e i dispositivi portatili rappresentano la norma. È molto probabile che il tuo datore di lavoro ti fornisca un computer portatile, non perché si preoccupi di te ma perché spera così di ottenere il massimo, dandoti la possibilità di lavorare ovunque sia disponibile una connessione Wi-Fi. I computer portatili hanno un costo maggiore rispetto ai desktop, ma tale investimento viene sicuramente ripagato dalla produttività. È proprio la mobilità che li rende così allettanti per te e per i tuoi avversari.
Prova a pensare: del tempo totale in cui il tuo computer portatile è acceso e connesso a una rete, in che percentuale è connesso alla rete aziendale? Se sei come me, forse il 20 percento massimo. Ciò significa che il computer portatile è al sicuro solo per il 20 percento del tempo quando si trova nei confini della rete aziendale Microsoft, protetto da attacchi esterni dalle difese perimetrali della rete. Ma cosa accade nell'80 percento del tempo durante il quale il mio computer portatile è, per scopi pratici, connesso direttamente a Internet? Molto spesso sono connesso alla rete più pericolosa del mondo: la LAN dell'hotel durante una conferenza sulla protezione dei computer. Nelle ore in cui sono connesso alla rete aziendale, quali sono i rischi rappresentati da altri computer all'interno dello stesso ambiente?
I controlli di protezione si evolvono, a volte troppo a rilento, per stare al passo con i rischi. I virus erano un problema che riguardava i client perché gli utenti utilizzavano dischetti per le loro transazioni commerciali, pertanto i primi programmi antivirus erano destinati ai client. In seguito, man mano che i messaggi di posta elettronica sono diventati di uso comune e il malware si è evoluto in worm (che agiscono direttamente sui messaggi di posta elettronica), i programmi anti-malware si sono evoluti e sono stati applicati ai gateway di posta elettronica. Con la comparsa del Web, il malware si è trasformato in trojan horse e i software anti-malware hanno seguito i server proxy di accesso a Internet. Si tratta di un percorso evolutivo noto su cui nessuno si è mai soffermato.
Applichiamo ora la stessa logica ai firewall. In passato i firewall rappresentavano una protezione sufficiente contro i pericoli della rete. Attualmente non è più così, in quanto i rischi sono diversi, più sofisticati e più diffusi. Senza considerare che sono cambiati notevolmente anche i dispositivi e gli stili di lavoro. Molti computer contengono informazioni riservate memorizzate localmente e vengono utilizzati spesso al di fuori della rete aziendale. Pertanto, è necessario che il firewall si evolva in un meccanismo di protezione client singolo. Non fare errori: i firewall client non sono più facoltativi. Per proteggere i computer dalla rete corpnet e da Internet, sono necessari i firewall client.

Firewall client e misure apparenti di protezione
Molte persone non sapevano che la versione iniziale di Windows® XP conteneva un firewall client. La cosa non sorprende molto poiché il firewall era disattivato per impostazione predefinita ed erano necessari troppi clic del mouse per accedervi. Il firewall appariva furtivamente senza alcuna indicazione reale relativa al suo scopo o senza una guida su come utilizzarlo. Ma funzionava. Se avessi attivato quel firewall, ti avrebbe protetto da Nimda, Slammer, Blaster, Sasser, Zotob e da qualsiasi altro tentativo di traffico indesiderato alla porta di rete. Vista l'importanza della protezione client, in Windows XP Service Pack 2 (SP2) il firewall è attivato per impostazione predefinita, esistono due profili (Internet e Corpnet) ed è consentita l'abilitazione di Criteri di gruppo.
Sfortunatamente, due ostacoli hanno rallentato l'adozione del firewall di Windows XP SP2: problemi relativi all'applicazione e misure apparenti di protezione. Molte persone erano preoccupate che il firewall avrebbe potuto impedire il corretto funzionamento delle applicazioni, sebbene ciò accadesse raramente visto come era concepito il firewall. Il firewall consentiva tutto il traffico in uscita dal computer, ma bloccava tutto il traffico in entrata che non era in risposta a una precedente richiesta in uscita. L'unica occasione in cui questo tipo di concezione avrebbe bloccato un'applicazione su un client sarebbe stato nel caso in cui l'applicazione avesse creato un socket di ascolto e prevedesse di ricevere richieste in entrata. Il firewall di Windows XP consentiva la configurazione semplice di eccezioni per programmi o porte (ma, sfortunatamente, non tramite Criteri di gruppo).
Il maggiore deterrente era rappresentato da misure apparenti di protezione eseguite dai produttori di altri firewall client. Alcuni credevano che il modo in cui il firewall di Windows XP era concepito, dal momento che consentiva tutto il traffico in uscita, non fosse sufficiente per un firewall client. L'obiezione si basava sul fatto che un buon firewall client dovrebbe bloccare tutto il traffico, in entrata e in uscita, a meno che l'utente non disponga dell'autorizzazione specifica.
Soffermiamoci per un momento su questo punto. Emergono due scenari.
  • Se si accede come amministratore locale e si viene infettati da malware, il malware disattiverà semplicemente il firewall. Tu sei 0wn3d.
  • Se non si accede come amministratore locale e si viene infettati da malware, il malware provocherà l'apertura di una finestra di dialogo da parte di un firewall di terze parti contenente una lingua straniera, porte e indirizzi IP e una domanda molto seria: "Si desidera consentire questa operazione?" L'unica risposta, naturalmente, è "Sì, stupido computer, smetti di tormentarmi!". E una volta disattivata la finestra di dialogo, viene disattivata anche la protezione. O, più comunemente, il malware controllerà semplicemente una sessione esistente di un programma già autorizzato e la finestra di dialogo non verrà neanche visualizzata. Ancora una volta sei 0wn3d.
C'è un assioma importante di protezione di cui è necessario essere a conoscenza: la protezione appartiene all'elemento che si desidera proteggere, non alla cosa da cui si sta tentando di proteggersi. L'approccio corretto consiste nell'eseguire l'agile ma efficace Windows Firewall su ogni computer all'interno della propria organizzazione, per proteggerli da qualsiasi altro computer nel mondo. Se si tenta di bloccare le connessioni in uscita da un computer già compromesso, come è possibile essere certi che il computer esegua effettivamente l'operazione richiesta? Ovviamente non è possibile. La protezione in uscita è una misura apparente di protezione, un espediente che dà soltanto l'impressione di migliorare la protezione senza migliorarla effettivamente. Questo è il motivo per cui la protezione in uscita non esisteva nel firewall di Windows XP e non esiste nel firewall di Windows Vista™. Parlerò del controllo in uscita in Windows Vista più avanti.

Quali sono le novità in Windows Vista?
Windows Filtering Platform, parte del nuovo stack di rete, è l'elemento base per il firewall di Windows Vista. Come Windows XP, Windows Vista blocca il traffico in entrata per impostazione predefinita. A seconda del profilo del computer che si sta utilizzando, potrebbero esservi delle eccezioni predefinite per i servizi di rete (tratterò dei profili più avanti). È possibile, se si desidera, scrivere delle regole per consentire connessioni in entrata. Anche Windows Vista, come Windows XP, consente per impostazione predefinita tutto il traffico in uscita dai processi interattivi, ma limita il traffico in uscita dai servizi che partecipano alla restrizione del servizio. E, ancora una volta, è possibile scrivere delle regole per bloccare ulteriori connessioni in uscita.
La grande differenza tra Windows XP e Windows Vista è rappresentata dalla nuova interfaccia di protezione avanzata e dal supporto completo di Criteri di gruppo per la configurazione e per le regole (vedere la Figura 1). La vecchia UI del Pannello di controllo rimane sempre a disposizione e pressoché inalterata tranne per quanto concerne le impostazioni di registrazione e le impostazioni di Internet Control Message Protocol (ICMP), che si trovano ora nella nuova UI. Questa nuova UI, lo snap-in MMC con protezione avanzata, offre tutte le nuove funzionalità, senza tralasciare la flessibilità. È anche disponibile un contesto nuovo nel comando netsh, netsh advfirewall, attraverso cui è possibile eseguire lo script di aggiunta o eliminazione della regola, impostare e illustrare criteri globali e per profilo, nonché visualizzare lo stato attivo del firewall. Inoltre, per gli sviluppatori, FirewallAPI.dll e Netfw.h forniscono il controllo programmatico su tutte le impostazioni del firewall.
Figura 1 Windows Firewall con protezione avanzata
Figura 1 Windows Firewall con protezione avanzata
MMC con protezione avanzata è basato su procedure guidate. Durante la creazione di una regola, è possibile scegliere tra quattro tipi: programma, porta, predefinito o personalizzato. La descrizione dei tipi è riportata in dettaglio nella Figura 2.
Figure 2 Quattro tipi di regole (Close Figure 2)

Tipo | Scopo
Programma | Utilizzato per consentire o bloccare il traffico per un programma particolare.
Porta | Utilizzato per consentire o bloccare il traffico su porte TCP o UDP particolari.
Predefined (Predefinito) | Utilizza un gruppo di regole preesistente per attivare la funzionalità di Windows sulla rete (come la condivisione di file e stampanti o l'assistenza remota).
Personalizzato | Illustra tutte le manopole, i pulsanti e le opzioni in modo da configurare come specifica una regola nel modo desiderato.
Esistono molti elementi a cui poter fare riferimento durante la scrittura delle regole, tutti disponibili per le regole locali e le regole applicate attraverso Criteri di gruppo tra cui: account e gruppi di utenti e computer di Active Directory®, indirizzi IP di origine e di destinazione, porte TCP e UDP di origine e di destinazione, numeri di protocollo IP, programmi e servizi, tipi di interfacce (cablate, wireless o accesso remoto) e tipi e codici ICMP.
Una volta configurato, il firewall elabora le regole nell'ordine seguente:
Restrizioni di servizio Alcuni dei servizi di Windows Vista limiteranno la probabilità di un altro attacco tipo Blaster. Una delle restrizioni è un elenco di porte richieste dal servizio. Il firewall impone tale restrizione e impedisce che il servizio utilizzi (o gli venga indicato di utilizzare) qualunque altra porta.
Regole per la protezione delle connessioni MMC con protezione avanzata incorpora IPsec e il firewall. Tutte le regole che contengono i criteri IPsec vengono elaborate successivamente.
Bypass autenticato I computer autenticati specificati possono ignorare altre regole.
Regole di blocco Queste regole bloccano esplicitamente il traffico specifico in entrata o in uscita.
Regole di autorizzazione Queste regole autorizzano esplicitamente il traffico specificato in entrata o in uscita.
Le regole del firewall vengono memorizzate nel Registro di sistema, ma non andrò a specificare esattamente dove. Va bene, le potrai trovare in queste posizioni:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Non modificare le regole direttamente nel Registro di sistema. Se lo fai, lo scopriremo e dovrai vedertela con noi! Scherzo, ma l'unico modo per modificare le regole è utilizzare MMC con protezione avanzata.

Profili di rete
Windows Vista definisce tre profili di rete: dominio, privato e pubblico. Se il computer è associato al dominio ed è stato registrato correttamente all'interno di questo, viene applicato automaticamente il profilo di dominio. Non eseguire mai questa operazione di tua iniziativa. Quando il computer è connesso a una rete interna senza un dominio (come una rete domestica o una piccola rete aziendale), è compito tuo (o di un amministratore) applicare il profilo privato. Infine, quando il computer è connesso direttamente a Internet, sei tu che devi applicare il profilo pubblico.
In che modo Windows Vista decide dove collocare il computer? Ogni volta che si verifica una modifica di rete (nel caso in cui si riceva un nuovo indirizzo IP, venga visualizzato un nuovo gateway predefinito o si ottenga una nuova interfaccia), un servizio denominato NLA (Network Location Awareness) rileva tale modifica. Questo servizio crea un profilo di rete, che contiene informazioni su interfacce esistenti, se il computer è stato autenticato in un controller di dominio, l'indirizzo MAC del gateway e così via, infine assegna a tale profilo un GUID. NLA notifica poi il firewall che a sua volta applica i criteri corrispondenti (esiste un criterio definito per ciascuno dei tre profili).
Se si tratta di una nuova interfaccia che il computer non ha mai incontrato prima e se NLA non ha scelto il profilo di dominio, verrà visualizzata una finestra di dialogo in cui indicare il tipo di rete a cui si è connessi. Sono disponibili tre possibilità: domestica, aziendale e pubblica. Si potrebbe pensare che aziendale indichi il profilo di dominio, ma ciò non corrisponde a realtà. È necessario ricordare che non viene mai visualizzato il profilo di dominio perché NLA lo sceglie automaticamente quando il computer effettua il collegamento a un dominio. In realtà, sia domestica che aziendale corrispondono al profilo privato. Dal punto di vista funzionale sono equivalenti, solo le icone sono diverse. Nota: è necessario essere un amministratore locale o essere in grado di assumere i privilegi di amministratore locale, per scegliere il profilo privato. Come previsto, la rete pubblica corrisponde al profilo pubblico.
In Windows Vista, un profilo di rete si applica a tutte le interfacce nel computer. Di seguito è riportato un resoconto della struttura decisionale di NLA:
  1. Esaminare tutte le reti connesse.
  2. L'interfaccia è connessa a una rete classificata come pubblica? Se sì, impostare il profilo del computer su Pubblico e uscire.
  3. L'interfaccia è connessa a una rete classificata come privata? Se sì, impostare il profilo del computer su Privato e uscire.
  4. Tutte le interfacce visualizzano un controller di dominio e il computer ha effettuato correttamente l'accesso? Se sì, impostare il profilo del computer su Dominio e uscire.
  5. Inoltre, impostare il profilo del computer su Pubblico.
L'obiettivo consiste nel selezionare il profilo più restrittivo possibile. Esistono, tuttavia, due effetti indesiderati. Innanzitutto, se la porta Ethernet del proprio computer è connessa alla rete Corpnet e il NIC wireless è connesso a Starbucks al piano inferiore, il computer sceglierà il profilo pubblico, non quello di dominio. In seguito, se il computer è direttamente connesso a Internet (nel profilo pubblico) o alla LAN domestica (nel profilo privato) e si effettua una connessione VPN alla rete corpnet, il computer rimarrà nel profilo pubblico o privato.
Che cosa significa tutto questo? I criteri del firewall per il profilo di dominio contengono delle regole per l'assistenza remota, l'amministrazione remota, la condivisione di file e stampanti e così via. Se ci si basa su queste regole per ottenere un client in modalità remota, ciò non sarà possibile se il client ha scelto un altro profilo. Ma non disperare, puoi scrivere regole di firewall per consentire tutte le connessioni in entrata necessarie e applicarle soltanto alle connessioni VPN. A questo punto è possibile ancora amministrare i client tramite la connessione VPN anche quando non si trovano nel profilo di dominio.

Controllo delle connessioni in uscita
In precedenza è stato specificato che la forma tipica di protezione in uscita nei firewall del client è rappresentata dalle misure apparenti di protezione. Tuttavia, una forma di controllo in uscita è molto utile: il controllo amministrativo di determinati tipi di traffico che non si desidera consentire. Il firewall di Windows Vista consente già questo controllo per le restrizioni del servizio. Il firewall consente a un servizio di comunicare soltanto tramite le porte di cui necessita e di bloccare tutti i tentativi di servizio. È possibile scrivere ulteriori regole che consentono o bloccano il traffico specifico in modo da soddisfare i criteri di protezione dell'organizzazione (vedere la Figura 3).
Figura 3 Creazione guidata nuova regola connessioni in entrata
Figura 3 Creazione guidata nuova regola connessioni in entrata
Ad esempio, è possibile che si desideri impedire agli utenti di eseguire un client di messaggistica immediata particolare. È possibile creare una regola (in Criteri di gruppo, ovviamente) per bloccare le connessioni ai server di accesso per quel client.
Esistono comunque alcune limitazioni pratiche a questo approccio. Ad esempio, Windows Live™ Messenger (noto come MSN® Messenger) dispone di diversi server da utilizzare per l'accesso e l'elenco di tali server non è mai definitivo. Inoltre, se la porta predefinita 1863/tcp è bloccata, si tornerà alla porta 80/tcp. Una regola per bloccare Windows Live Messenger dalla connessione ai server di accesso potrebbe risultare troppo complessa e soggetta a cambiamenti. Il controllo amministrativo in uscita può essere utile, ma non rappresenta un sostituto per i criteri di restrizione software se si ha la necessità di mantenere uno stretto controllo sugli utenti del software che hanno l'autorizzazione a installare ed eseguire.

Proteggi il tuo computer
Non esiste più alcun limite perimetrale. Ogni computer deve disporre di una protezione adeguata. Proprio come i software anti-malware sono passati dal client al confine della rete, i firewall devono passare dal confine della rete al client. È possibile agire immediatamente attivando il firewall già installato.
Se sui sistemi è in esecuzione Windows XP o si sta già passando a Windows Vista, Windows Firewall è disponibile per tutti i client e fornirà la protezione necessaria per migliorare la protezione all'interno della propria organizzazione, anche quando i lavoratori mobili sono lontani migliaia di chilometri dall'ufficio.

Ulteriori informazioni disponibili
  • Windows Vista TechCenter: introduzione a Windows firewall con protezione avanzata
  • Windows Vista TechCenter: Windows Firewall con protezione avanzata - Diagnostica e risoluzione dei problemi
  • Presentazione europea del TechEd di Steve Riley: firewall di Windows Vista e miglioramenti IPSec
  • The Cable Guy: il nuovo Windows Firewall in Windows Vista e Windows Server "Longhorn"
  • Laboratorio virtuale del firewall di Windows Vista

Steve Riley è Senior Security Strategist presso Microsoft Security Technology Unit e collabora con TechNet Magazine come redattore. Tiene conferenze in tutto il mondo ed è costantemente impegnato con i clienti per garantire loro maggiore protezione. Il suo ultimo libro è Protect Your Windows Network (Addison-Wesley, 2005). È possibile contattarlo all'indirizzo steve.riley@microsoft.com.


 Protezione: I nuovi ACL migliorano la protezione in Windows Vista
Protezione Jesper Johansson

I nuovi ACL migliorano la protezione in Windows Vista
Panoramica:
  • Novità negli ACL
  • Controlli più rigidi sull'amministratore
  • Autorizzazioni per il programma di installazione trusted
  • Utenti e gruppi modificati

Sebbene la struttura di base degli elenchi di controllo di accesso (ACL) per Windows Vista non sia stata modificata in modo radicale, sono state tuttavia apportate alcune piccole ma importanti modifiche che è necessario conoscere. Alcune modifiche
sono state ritenute necessarie in quanto in Windows® XP gli ACL sono stati responsabili di diversi problemi. Innanzitutto, la maggior parte degli utenti di Windows XP dispone di privilegi di esecuzione come amministratore, ovvero utilizza un account membro del gruppo Administrators predefinito. Per gli utenti privati, questo rappresenta una certezza virtuale in quanto tutti gli account aggiunti durante l'installazione diventano amministratori. Pertanto, tutti i programmi utilizzati da questi utenti verranno eseguiti con privilegi amministrativi, con conseguente possibilità di accesso illimitato al sistema operativo. Ovviamente, questa situazione si rivela particolarmente problematica in caso di programmi di dubbia provenienza.
Il secondo problema da risolvere era rappresentato dal fatto che gli ACL predefiniti nelle versioni precedenti di Windows erano spesso motivo di irritazione per gli utenti in quanto includevano voci di controllo di accesso (ACE) per gruppi come Everyone, Power Users e simili. Ad esempio, l'ACL predefinito nella directory radice del volume di avvio (in genere C:\) in Windows XP concedeva l'accesso in lettura al gruppo Everyone e l'autorizzazione per la creazione di cartelle ai membri del gruppo Users. Infine, Windows XP prevedeva alcune limitazioni sui tipi di operazioni eseguibili con gli ACL. In Windows XP non era ad esempio possibile assegnare autorizzazioni al proprietario corrente di un oggetto. Questo sistema operativo prevedeva l'assegnazione delle autorizzazioni di proprietario, ma non il trasferimento di tali autorizzazioni in caso di modifica del proprietario. Analogamente, i proprietari disponevano sempre di diritti impliciti per un oggetto, indipendentemente dalle autorizzazioni ad essi assegnate per l'oggetto in questione.
Con Windows Vista™, Microsoft si è assunta l'impegno di risolvere la maggior parte di questi problemi e di attivare il supporto per altre funzionalità, come il controllo dell'account utente. Questo articolo è incentrato sulle modifiche più significative correlate al controllo dell'accesso in Windows Vista. La trattazione di questo argomento proseguirà nell'articolo del prossimo mese, in cui verranno esaminati gli strumenti che è possibile utilizzare per la gestione del controllo dell'accesso.

Utenti e gruppi nuovi e modificati
Alcuni utenti e gruppi in Windows Vista sono nuovi, mentre altri, già esistenti in Windows XP, sono stati rimossi. Inoltre, è stato modificato il comportamento di alcuni utenti e gruppi. Ciascuna delle modifiche apportate ha un certo impatto sulla modalità di gestione del controllo dell'accesso.
Amministratore: disattivato per impostazione predefinita L'account amministratore predefinito, a cui è associato l'identificatore relativo (RID) 500, è ora disattivato per impostazione predefinita nella maggior parte dei casi. L'account amministratore è stato creato per i casi di emergenza, ovvero per essere utilizzato per il recupero del computer come ultima opzione quando tutte le altre falliscono. Nella maggior parte dei casi viene tuttavia utilizzato come account amministrativo standard, violando pertanto diversi principi di protezione. La violazione del più significativo di questi principi, l'accountability, ovvero la capacità di identificare le azioni e il comportamento di un utente all'interno di un sistema, implica l'incapacità di tenere traccia dell'autore di eventuali modifiche al sistema. Pertanto, l'account è stato dichiarato parzialmente obsoleto. È possibile che in futuro l'account venga dichiarato da Microsoft completamente obsoleto, ma per ora è disattivato per impostazione predefinita. Se non sono presenti altri account locali nel gruppo Administrators, sarà possibile continuare a utilizzare RID 500 nella Console di ripristino di emergenza e in modalità provvisoria; in caso contrario, non potrà e non dovrà essere utilizzato.
Tenere presente che esiste una differenza tra l'account amministratore predefinito e gli altri account nel gruppo Administrators. In genere, le iniziali del termine "Administrator" sono in maiuscolo quando si fa riferimento all'account con il RID 500 per distinguerlo da un account "amministratore" che rappresenta qualsiasi altro account membro del gruppo Administrators predefinito. Anche le iniziali dei nomi dei gruppi sono in maiuscolo.
In Windows XP, l'account amministratore predefinito disponeva di alcuni diritti e privilegi speciali non concessi a nessun altro amministratore. Molti di questi privilegi sono stati rimossi in Windows Vista, con due importanti eccezioni: Primo, un account amministratore disattivato può essere utilizzato nella Console di ripristino di emergenza se non sono presenti altri amministratori locali. Secondo, l'account amministratore non è soggetto al controllo dell'account utente e dispone sempre di un token amministrativo completo. Lo stesso vale per l'amministratore di dominio (RID 500 in un dominio).
Rimozione delle autorizzazioni del gruppo Power Users Il gruppo Power Users precedente è stato, per motivi pratici, disattivato. Il gruppo è ancora presente, ma molte delle autorizzazioni ad esso assegnate sono state rimosse. Non è affatto un segreto che un utente che era membro del gruppo Power Users era in sostanza un amministratore a tutti gli effetti che tuttavia non aveva assunto formalmente i privilegi di amministratore. Una volta mi è capitato di sostituire un computer su cui veniva eseguito Windows XP Service Pack 2 (SP2) e a cui sono state applicate tutte le patch in meno di 45 minuti, ottenendo privilegi amministrativi. Tali privilegi includevano il riconoscimento, la scrittura di un programma di piccole dimensioni in C++, la disconnessione e la riconnessione per completare la sostituzione, operazioni tutte consentite perché ero membro del gruppo Power Users.
Poiché molte organizzazioni hanno concesso autorizzazioni sofisticate al gruppo Power Users e si basano sull'appartenenza dei relativi utenti a tale gruppo, non è stato possibile rimuovere il gruppo in Windows Vista. Tuttavia, è probabile che Microsoft rimuova completamente il gruppo Power Users in una versione futura di Windows. È pertanto consigliabile iniziare a pianificare la migrazione dal gruppo Power Users.
Programma di installazione trusted Il programma di installazione trusted è un servizio, non un utente, anche se dispone di autorizzazioni in tutto il file system. La protezione avanzata consente di considerare ogni servizio come entità di protezione completa a cui è possibile assegnare le stesse autorizzazioni concesse a qualsiasi altro utente. Per una panoramica di questa funzionalità, vedere il numero di gennaio 2007 di TechNet Magazine. Nel libro Windows Vista Security (Grimes e Johansson, Wiley Press, 2007) la protezione avanzata viene esaminata in dettaglio, illustrando, tra l'altro, il modo in cui viene utilizzata da altre funzionalità, come il firewall e IPsec.
I SID dei servizi non vengono rilasciati dalle autorità descritte in precedenza, come NT AUTHORITY o un dominio. Il nome completo per l'account virtuale TrustedInstaller è NT SERVICE\TrustedInstaller e il relativo SID è il seguente:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
È possibile visualizzare il SID per qualsiasi servizio, anche per quelli non esistenti, eseguendo il comando sc showsid, come illustrato nella Figura 1.
Figura 1 sc showsid mostra il SID per qualsiasi servizio, inclusi quelli non ancora esistenti
Figura 1 sc showsid mostra il SID per qualsiasi servizio, inclusi quelli non ancora esistenti
Questo SID inizia con S-1-5-80. Osservare che la prima sottoautorità è 80, che corrisponde a SECURITY_SERVICE_ID_BASE_RID, il che indica che questo SID viene rilasciato dalla sottoautorità NT SERVICE a un servizio. Lo stesso vale per qualsiasi servizio. Le sottoautorità e i RID rimanenti sono basati sul nome del servizio stesso. Questo consente a uno sviluppatore di concedere le autorizzazioni al relativo servizio senza dover prima creare e installare il servizio, in quanto il nome è deterministico e non cambia da computer a computer.
Qualora non si sia in grado di individuare il servizio TrustedInstaller nel gestore dei servizi, il relativo nome visualizzato è "Programma di installazione dei moduli di Windows".
Rimozione degli account Guida e supporto tecnico Gli account Support_xxxxxx e HelpAssistant sono stati entrambi rimossi dalle installazioni pulite di Windows Vista, anche se vengono mantenuti durante l'aggiornamento da una versione precedente di Windows. L'account Support_xxxxxx veniva utilizzato per eseguire gli script del supporto tecnico. È possibile che alcuni OEM che fornivano contenuto della Guida personalizzato fornissero anche account di supporto creati da loro stessi. Non è chiaro cosa accadrà agli account degli OEM, ma è molto probabile che gli OEM smetteranno semplicemente di crearli. In verità, questi account non sono più necessari. Infatti, dal punto di vista della protezione, non è stata un'idea brillante consentire agli utenti di eseguire gli script del supporto tecnico così come di un qualsiasi altro utente e, pertanto, sarebbe meglio se questi account non venissero più utilizzati. Per eseguire questa attività, Windows Vista fornisce un nuovo meccanismo.
L'account HelpAssistant veniva utilizzato durante l'assistenza remota. Analogamente al supporto tecnico, la funzionalità di assistenza remota è stata riprogettata per evitare l'utilizzo dell'account HelpAssistant che, pertanto, è stato rimosso.
Nuovi SID basati sui percorsi di rete Nei sistemi operativi basati su Windows NT® sono stati sempre presenti alcuni SID basati sui percorsi di rete, come NETWORK e INTERACTIVE, che indicano gli utenti che eseguono l'accesso dalla rete e in modo interattivo. Esiste inoltre un SID REMOTE INTERACTIVE LOGON che viene assegnato agli utenti che eseguono l'accesso tramite Servizi terminal. Tenere presente che gli utenti di Servizi terminal avranno nei relativi token sia il SID REMOTE INTERACTIVE LOGON che il SID INTERACTIVE LOGON. In Windows Vista sono stati aggiunti altri due SID: REMOTO e INTERNET. L'esatta motivazione logica alla base dell'aggiunta di un account che indica un accesso tramite connessione remota non è molto chiara, soprattutto considerando che un numero sempre crescente di utenti non stabilirà alcuna connessione a Internet se l'unica rete disponibile è una linea telefonica. Il SID INTERNET è stato ovviamente progettato per indicare qualsiasi utente che esegua l'accesso superando i confini della rete LAN. Il SID NETWORK, tuttavia, indica qualsiasi utente che esegua l'accesso dalla rete, incluso Internet.
DIRITTI PROPRIETARIO e diritti di proprietario Ora è disponibile un SID per DIRITTI PROPRIETARIO, che si applica a qualsiasi utente che diventi proprietario di un file al momento dell'accesso. Questo SID viene utilizzato principalmente per limitare le operazioni che il proprietario può eseguire con il file. Sono state apportate due modifiche significative alla modalità d funzionamento dei diritti di proprietario rispetto a Windows XP. Primo, se un utente è proprietario dell'oggetto, ma nell'oggetto è presente una voce di controllo di accesso applicabile allo stesso utente, i diritti nella voce ACE avranno la priorità sui diritti di proprietario dell'utente. Poiché al proprietario sono sempre stati associati diritti impliciti, questa importante modifica avrà un significativo impatto su alcuni aspetti dell'amministrazione del sistema. Secondo, il SID DIRITTI PROPRIETARIO può essere utilizzato per limitare ulteriormente le operazioni che il proprietario può eseguire con un oggetto.
Si supponga di disporre di una cartella di proprietà dell'utente Jesper, che contiene un ACL, come illustrato nella Figura 2. L'utente, Jesper, dispone solo dell'autorizzazione di lettura per la cartella, anche se è il proprietario. Se tenta di copiare un file in tale cartella, la copia non riuscirà in quanto Jesper non dispone dell'autorizzazione di scrittura nella cartella. Questo non è tuttavia completamente evidente nei messaggi di errore. Se si tenta di copiare un file in una cartella di cui si è proprietario ma non si dispone dell'autorizzazioni di scrittura per l'utilizzo di Esplora risorse®, si verifica la seguente situazione: innanzitutto, un messaggio in Esplora risorse indica e richiede la necessità di elevare le autorizzazioni per copiare il file, ma la copia del file non riesce perché non si dispone dei diritti di copia in questa cartella. Vengono visualizzati il messaggio di errore "Per eseguire l'operazione è necessaria l'autorizzazione" e i pulsanti "Riprova" (sostanzialmente inutile) e "Annulla". Questa situazione si verifica anche se si è proprietario della cartella.
Figura 2 Solo l'account di sistema locale e un altro utente hanno accesso a questa cartella.
Figura 2 Solo l'account di sistema locale e un altro utente hanno accesso a questa cartella.
Se Jesper tenta di modificare l'ACL nel file, gli verrà chiesto di elevare il relativo token prima di eseguire questa operazione. Poiché è il proprietario del file, ha la possibilità di effettuare questa operazione. Il proprietario dispone di diritti impliciti per la lettura e la modifica dell'ACL (READ_CONTROL e WRITE_DAC) a meno che non sia presente una voce ACE per DIRITTI PROPRIETARIO che specifichi diversamente.
Per comprendere l'effetto del SID DIRITTI PROPRIETARIO, aggiungiamo questo SID all'ACL sopra citato. A questo punto, si dispone delle autorizzazioni illustrate nella Figura 3.
Figura 3 L'aggiunta delle autorizzazioni DIRITTI PROPRIETARIO alla cartella consente di modificare le autorizzazioni di Jesper
Figura 3 L'aggiunta delle autorizzazioni DIRITTI PROPRIETARIO alla cartella consente di modificare le autorizzazioni di Jesper
Con queste autorizzazioni, se l'account Jesper tenta di eseguire una copia nella cartella, questa operazione riuscirà in quanto Jesper è il proprietario e dispone dei diritti appropriati. Tuttavia, se Jesper tenta di modificare l'ACL nell'oggetto, questa operazione non riuscirà. La voce ACE per DIRITTI PROPRIETARIO specifica che il proprietario deve disporre solo del privilegio di modifica, ma non gli è consentito modificare l'elenco di controllo di accesso discrezionale (DACL). Pertanto, l'autorizzazione DIRITTI PROPRIETARIO viene utilizzata principalmente per rimuovere WRITE_DAC, ovvero la capacità di modificare il descrittore di protezione, dal proprietario.
Se un amministratore modifica il proprietario dell'oggetto, le autorizzazioni DIRITTI PROPRIETARIO non verranno automaticamente trasferite al nuovo proprietario. In questo caso, la voce ACE per DIRITTI PROPRIETARIO viene disattivata e viene contrassegnata come Solo eredità ma non viene applicata a contenitori o oggetti; in altre parole non viene applicata a nulla. Questa operazione viene eseguita per assicurare che gli amministratori non vengano completamente esclusi dall'utilizzo dell'oggetto. Per applicare di nuovo la voce ACE per DIRITTI PROPRIETARIO, l'amministratore deve accedere alla voce ACE e riattivarla manualmente. A tal fine, occorre contrassegnarla come applicabile alla cartella corrente, alle sottocartelle e ai file desiderati.
Il SID DIRITTI PROPRIETARIO può rivelarsi molto utile in numerosi scenari interessanti, ad esempio quando l'amministratore desidera che gli utenti siano in grado di creare file e cartelle su un file server, ma non desidera che siano in grado di modificare gli ACL in tali cartelle. Un'altra probabile situazione è rappresentata da uno scenario in cui alcuni utenti sono stati membri per un determinato periodo di un gruppo e hanno creato alcuni oggetti ma, successivamente, probabilmente per motivi aziendali, sono stati rimossi da questo gruppo. A questo punto, tali utenti non dovrebbero essere in grado di modificare le impostazioni sugli oggetti creati.
Il SID DIRITTI PROPRIETARIO viene ampiamente utilizzato nella protezione avanzata. Quando un servizio crea un oggetto transitorio in fase di esecuzione, il creatore dell'oggetto rappresenta il SID principale del processo di servizio, in genere LocalSystem, NetworkService o LocalService, e non il SID per il servizio stesso. Ne consegue che qualsiasi altro servizio in esecuzione nello stesso contesto del processo può modificare l'oggetto, uno scenario quasi mai auspicabile. Se si imposta un SID DIRITTI PROPRIETARIO per tali oggetti, il sistema operativo sarà in grado di impedire ad altri servizi di accedere agli oggetti.

ACL predefiniti
Gli ACL predefiniti in Windows XP garantivano un discreto livello di protezione. A parte alcuni problemi di ridotta entità, come consentire agli utenti di inserire i file nella directory principale del volume di avvio, erano in linea di massima una "soluzione assennata". Tuttavia, alcuni OEM hanno avuto la presunzione di avere un'idea più precisa di cosa costituisse una discreta protezione. Nella schermata nella Figura 4 viene illustrata un'immagine dell'ACL contenuto nella directory di Windows su un computer che esegue Windows XP Media Center Edition di un importante OEM. L'OEM ha disattivato essenzialmente la protezione del file system.
Figura 4 ACL configurato da un OEM
Figura 4 ACL configurato da un OEM
Microsoft ha apportato alcune modifiche agli ACL in Windows Vista. Innanzitutto, chiunque abbia familiarità con Windows XP saprà senz'altro che tutti i file del sistema operativo sono di proprietà del gruppo Administrators e che gli amministratori dispongono del controllo completo su tali file. Ogni membro del gruppo Administrators disponeva pertanto di un accesso illimitato a questi file. Questo non avviene in Windows Vista.
Programma di installazione trusted In Windows Vista, la maggior parte dei file del sistema operativo è di proprietà del SID TrustedInstaller e solo tale SID dispone del controllo completo su questi file. Questa modifica è parte integrante dei meccanismi di integrità che sono stati introdotti in Windows Vista e ha lo scopo specifico di impedire a un processo eseguito come amministratore o sistema locale di sostituire automaticamente i file. Per eliminare un file del sistema operativo, è necessario pertanto assumere la proprietà del file e aggiungervi una voce ACE che consenta di eliminarlo. Questo fornisce un livello minimo di protezione contro un processo eseguito come LocalSystem e che dispone dell'etichetta di integrità Sistema; si suppone che un processo con livello di integrità basso non sia in grado di elevare i relativi privilegi per modificare la proprietà. Alcuni servizi, ad esempio, possono essere eseguiti con livello di integrità medio anche se vengono eseguiti con un account di sistema locale. Tali servizi non possono sostituire i file di sistema e, pertanto, un potenziale exploit che assume il controllo di questi servizi non sarà in grado di sostituire i file del sistema operativo, rendendo un po' più difficoltosa l'installazione di un rootkit o altro malware nel sistema. Inoltre, diventa ancora più difficile per gli amministratori di sistema che non gradiscono la presenza di un file binario di sistema rimuovere tale file.
Voci ACE di negazione Numerosi oggetti nel file system contengono voci ACE di negazione associate al gruppo Everyone, il che è stato motivo di grande costernazione per la maggior parte degli amministratori. Se si attiva l'opzione "Visualizza cartelle e file nascosti", verrà visualizzata la nota directory Documents and Settings. Se, tuttavia, si fa clic su tale directory, verrà visualizzato il messaggio di errore Accesso negato. Per capire cosa avviene nella directory Documents and Settings, esaminare l'elenco delle directory nella Figura 5.
Figura 5 Documents and Settings è un punto di giunzione, non una directory
Figura 5 Documents and Settings è un punto di giunzione, non una directory
Documents and Settings, in realtà, non è una directory ma un punto di giunzione. Tenere presente che i punti di giunzione sono simili ai collegamenti simbolici che reindirizzano semplicemente l'accesso a una destinazione differente. In questo caso, la giunzione reindirizza a una directory definita C:\Users. Microsoft ha apportato modifiche significative allo spazio dei nomi del file system in Windows Vista e i dati degli utenti sono stati spostati in C:\Users. Anche altri elementi sotto il precedente spazio dei nomi "C:\Documents and Settings\<Nomeutente>" sono stati spostati. Ad esempio, "C:\Documents and Settings\<Nomeutente>\Dati applicazioni" è stato spostato in C:\Users\<nomeutente>\appdata\roaming. È possibile avere un'idea più chiara delle modifiche apportate se si accede a una riga di comando e si utilizza il comando dir /a, come illustrato nella Figura 5. La ragione per cui lo spazio dei nomi è stato modificato in modo così radicale risiede nella necessità di renderlo più intuitivo per gli utenti e di ottenere una separazione più netta tra documenti e dati. Anziché memorizzare tutti i file di dati sotto la cartella documenti, gli sviluppatori possono ora creare cartelle personalizzate sotto il profilo dell'utente e l'utente sarà in grado di visualizzarle da tale posizione. I dati delle applicazioni per tutti gli utenti ora risiedono in una cartella nascosta denominata %systemroot%\ProgramData anziché in Documents and Settings\All Users\Dati applicazioni.
Microsoft non ha rimosso lo spazio dei nomi "C:\Documents and Settings" in quanto le applicazioni precedenti potrebbero essere configurate a livello di codice per l'utilizzo di tale nome anziché delle variabili di ambiente desiderate, come %USERPROFILE%. Tali applicazioni smetterebbero di funzionare nel caso in cui lo spazio dei nomi "C:\Documents and Settings" venisse rimosso. Pertanto, questi percorsi sono ora rappresentati come punti di giunzione o collegamenti simbolici per garantire la compatibilità con le versioni precedenti. Tuttavia, è possibile che le applicazioni in cui tali percorsi sono specificati a livello di codice smettano comunque di funzionare, a seconda della modalità con cui accedono ai dati presenti nei percorsi in questione; nelle versioni di Windows in lingue diverse dalla lingua inglese, tali applicazioni non sono più funzionanti. Questo aspetto è fondamentale. Quando un aggiornamento a Windows, ad esempio Windows XP SP2 o Windows Vista, compromette il funzionamento di programmi di terze parti, la ragione risiede quasi sempre nella formulazione di ipotesi non valide o nell'utilizzo improprio di Windows da parte degli sviluppatori di questi programmi.
Se si tenta di aprire un file, ad esempio digitando "C:\Documents and Settings\<Nomeutente>\Documenti\foo.txt", l'operazione riuscirà, purché si disponga di un file in tale percorso denominato foo.txt. Tuttavia, se si tenta di accedere a "C:\Documents and Settings\<Nomeutente>\Documenti", verrà visualizzato il messaggio di errore "Accesso negato". Per capire cosa succede, dare un'occhiata all'ACL nella Figura 6.
Figura 6 In Documents and Settings è presente una voce ACE di negazione
Figura 6 In Documents and Settings è presente una voce ACE di negazione
Esaminare la prima voce ACE nell'elenco. Si tratta di una voce ACE di negazione per il gruppo Everyone per la visualizzazione del contenuto delle cartelle. I programmi possono attraversare i punti di giunzione e aprire i documenti con percorsi assoluti perché il gruppo Everyone dispone del privilegio Ignorare controllo incrociato (noto anche come SeChangeNotifyPrivilege). I tentativi di un utente o un processo di enumerare le directory che rappresentano non riusciranno a causa della presenza della voce ACE di negazione. Per questo motivo non è possibile visualizzare il contento all'interno di C:\Documents and Settings né eliminare la "directory". La ragione principale dell'inserimento della voce ACE di negazione in questo percorso consiste nell'impedire agli utenti di eliminare la giunzione e compromettere il funzionamento delle applicazioni precedenti. Ha lo scopo inoltre di ricordare agli sviluppatori di non scrivere applicazioni che prevedono l'utilizzo dello spazio dei nomi precedente ma che possano essere avviate tramite l'uso di variabili di ambiente o stringe del Registro di sistema in modo da isolare le applicazioni da eventuali modifiche future e differenze di lingua.
Tenere presente che tutti i punti di giunzione sono nascosti per impostazione predefinita e pertanto la maggior parte degli utenti non è in grado di visualizzarli. Per impedire che vengano eliminati, Microsoft ha inserito una voce ACE di negazione per l'autorizzazione "Visualizzazione contenuto cartella".
Ignorare controllo incrociato La ragione per cui gli utenti possono accedere ai file per i quali dispongono dei diritti appropriati all'interno di cartelle (o punti di giunzione) per le quali non dispongono di diritti risiede nel fatto che il gruppo Everyone dispone del privilegio Ignorare controllo incrociato. Ignorare controllo incrociato o SeChangeNotifyPrivilege rappresenta il privilegio di base in Windows e viene concesso a un processo per il quale tutti gli altri privilegi sono stati rimossi, a meno che il processo non richieda esplicitamente che gli venga rimosso anche tale privilegio. Questo è quello che accade quando si avvia un processo utilizzando la riga runas /trustlevel:0x10000 < in Windows Vista. Il programma specificato in <comando> verrà eseguito con un token con restrizioni e tutti i privilegi, eccetto SeChangeNotifyPrivilege, verranno rimossi dal token del processo.
Il punto più interessante è che trustlevel 0x20000 fornisce un token con il set di SID standard ma con privilegi rimossi. 0x40000 fornisce un token completamente normale.

Autorizzazioni predefinite
Le autorizzazioni predefinite nel file system di Windows Vista presentano lievi differenze rispetto a Windows XP. Se si esamina l'ACL in %systemdrive% (in genere l'unità C: o volume di avvio), in Windows XP o Windows Server® 2003, è possibile osservare quanto riportato di seguito (o qualcosa di molto simile nelle versioni precedenti di Windows XP):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Di seguito viene illustrato lo stesso ACL all'interno della stessa directory in Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
È possibile rilevare numerose differenze degne di nota. Innanzitutto, ora sono presenti due voci ACE per BA (BUILTIN\Administrators) anziché una, ma il risultato finale è lo stesso. In Windows Vista, una voce ACE non viene ereditata e concede l'accesso completo alla directory radice, mentre l'altra voce ACE è una voce ACE IO (Solo eredità), ereditata da contenitori e oggetti, e concede il controllo completo o GA (Generico completo). Lo stesso vale per la sostituzione della voce ACE per SY (LocalSystem) con due voci ACE in Windows Vista. In Windows XP, l'unica voce ACE disponibile concedeva l'accesso completo ed era ereditata da oggetti e contenitori. Ancora una volta non si nota una modifica sostanziale. La ragione principale per la modifica dell'ACL è il tentativo di chiarire e ridurre i privilegi in modo da semplificare la gestione e, potenzialmente, il ripristino dell'ACL.
L'aspetto più interessante è che la voce ACE per CO (Creator/Owner) è stata rimossa. Ne consegue che se un utente crea un oggetto nella directory radice del file system, non vengono più concesse autorizzazioni speciali al creatore dell'oggetto.
È inoltre possibile osservare che la voce ACE per WD (Everyone) è stata rimossa. La maggior parte degli utenti interessati alla protezione, sebbene sia possibile che non abbiano compreso completamente le implicazioni delle loro azioni, ha espresso forti perplessità su questa voce ACE. Microsoft ha tentato invano per anni di spiegare che Everyone era dal punto di vista funzionale identico al gruppo Users predefinito, ma alla fine ha optato per la rimozione di tale voce. Poiché è presente una voce ACE identica per BU (BUILTIN\Users), anch'essa ereditata da contenitori e oggetti, il risultato finale è che nulla è cambiato.
Inoltre, due delle voci ACE per BU, ovvero il gruppo Users predefinito, sono state sostituite con le voci ACE per AU (Authenticated Users). La ragione risiede nel fatto che l'account Guest è membro del gruppo Users predefinito (in virtù del fatto che INTERACTIVE è membro del gruppo Users predefinito), ma Guest non è membro di Authenticated Users. Per consentire all'account Guest di leggere ed eseguire file, la voce ACE 0x1200a9 (Lettura/esecuzione) continua a essere concessa al gruppo BU. Tuttavia, le voci ACE che concedono le autorizzazioni per la creazione di file e cartelle sono invece concesse al gruppo Authenticated Users. Questo è un elemento di grande differenza rispetto a Windows XP. In Windows XP, un account Guest era in grado di creare file nella directory radice. In Windows Vista, un account Guest non è in grado di creare tali file. Tenere presente, tuttavia, che questa considerazione non è valida per i casi in cui l'account Guest è attivato e i membri del gruppo Guests sono in grado di accedere alla directory radice del volume di avvio. Per impostazione predefinita, l'account Guest è disattivato.
Infine, nei due elenchi sopra riportati sono presenti un paio di voci ACE molto interessanti e apparentemente complicate. In Windows XP, è presente una voce ACE ereditata da contenitori, che specifica 0x100004 per il gruppo Users predefinito. Questa voce ACE concede al gruppo Users il diritto di creare sottocartelle in quanto è ereditata dai contenitori. È presente anche una voce ACE Solo eredità, ereditata dalle sottocartelle per 0x100002. Questa voce concede agli utenti il diritto di creare file e sottocartelle nelle cartelle da essi create sotto la directory radice. In altre parole, queste due voci ACE consentono agli utenti, compresi i membri del gruppo Guests, di creare file e cartelle sotto la directory radice, come indicato in precedenza.
In Windows Vista, le voci ACE corrispondenti sono una voce ACE Solo eredità, ereditata da contenitori e file, che concede le autorizzazioni GR (Lettura generica), GX (Esecuzione generica) e GW (Scrittura generica) insieme a SD (Descrittore di protezione), e una voce ACE applicabile solo alla directory radice che concede il privilegio LC. LC è un acronimo che appartiene alle voci ACE in Active Directory®. In Active Directory, questo acronimo indica che un utente è in grado di visualizzare oggetti figlio. Tuttavia, il valore esadecimale di LC è 0x4. Per una directory, 0x4 corrisponde a FILE_ ADD_SUBDIRECTORY, che diventa equivalente, dal punto di vista funzionale, a 0x100004, in quanto è già disponibile il valore 0x100000 (capacità di utilizzare l'oggetto per la sincronizzazione) che viene fornito dalla voce ACE 0x1200a9. In altre parole, si ottiene lo stesso risultato ottenuto in Windows XP: gli utenti hanno la capacità di creare sottodirectory all'interno della directory principale.
Da dove provengono i valori esadecimali? E soprattutto cosa sono i valori esadecimali? Come si è potuto osservare, il controllo dell'accesso è costituito da numeri esadecimali (base16), come 0x1200a9. Questi numeri sono in effetti rappresentazioni dei bit delle maschere di bit all'interno di una maschera di accesso che sono attivati, il che indica che vengono utilizzati nella specifica voce ACE. Quando si utilizza uno strumento, come icacls, sc o secedit per elencare un ACL, le maschere di bit vengono rappresentate da stringhe di testo molto più semplici se esiste una corrispondenza 1:1.
Pertanto, per determinare il significato di LC, è sufficiente accedere al sito Web MSDN®, individuare la stringa LC e cercare nella colonna relativa ai valori dei diritti di accesso ADS_RIGHT_ACTRL_DS_LIST. Se si apre il file di intestazione Iads.h e si cerca questa stringa, si scoprirà che corrisponde a 0x4. Per le stringhe non Active Directory (quelle che non sono precedute dal prefisso "ADS_RIGHT"), il valore esadecimale si trova generalmente in AccCtrl.h. Una volta individuato il valore esadecimale, è piuttosto semplice cercarlo nella maschera di accesso in WinNt.h o AccCtrl.h per determinarne il significato.
Per ulteriori informazioni in merito, è opportuno consultare il libro Protect Your Windows Network (di Jesper Johansson e Steve Riley, Addison-Wesley, 2005). Il capitolo 17 tratta in maniera dettagliata la modalità di analisi delle stringhe SDDL (Security Description Definition Language) e delle voci ACE.
Le autorizzazioni concesse a tali sottodirectory sono gestite esclusivamente dalla voce ACE (A;OICIIO;SDGXGWGR;;;AU) in Windows Vista, il che rappresenta la differenza più significativa tra Windows Vista e Windows XP. Anziché concedere il controllo completo al creatore delle sottodirectory, come in Windows XP, Windows Vista concede privilegi di modifica agli utenti membri del gruppo Authenticated Users.
Il risultato finale di questo nuovo ACL è che il creatore di un oggetto non può più disporre di diritti special. Probabilmente, la maggiore differenza rispetto a Windows XP è che il gruppo Authenticated Users dispone dei privilegi di modifica anche per le sottocartelle create dagli amministratori. In Windows XP, i gruppi Users e Authenticated Users non dispongono di diritti per gli oggetti creati dagli amministratori nella directory radice. Nel complesso, tuttavia, sebbene queste voci ACE possano sembrare complesse, il risultato finale non è molto differente da quello ottenuto in Windows XP.
In sintesi, in Windows Vista tutti, compreso l'utente Guest, sono in grado di leggere ed eseguire file nella directory radice. Solo agli utenti membri del gruppo Authenticated Users è consentito creare nuovi file e cartelle e, dopo che li hanno creati, vengono loro concesse le autorizzazioni di modifica per i file e le cartelle in questione. In altre parole, le autorizzazioni sono leggermente più limitate in Windows Vista rispetto a Windows XP, anche se è importante notare che l'account Guest è disattivato per impostazione predefinita.

Modifiche ai token
Quando un utente membro del gruppo Administrators in Windows XP esegue l'accesso, il relativo token contiene il SID del gruppo Administrators e l'utente può seguire tutte le operazioni consentite al gruppo Administrators. In Windows Vista, invece, questo non avviene a causa del controllo dell'account utente. Il SID del gruppo Administrators è ancora presente nel token, ma è contrassegnato come di sola negazione, come illustrato nella schermata di Process Explorer nella Figura 7.
Figura 7 Con il controllo dell'account utente, il SID del gruppo Administrators viene utilizzato solo per la negazione dell'accesso a meno che non si esegua l'elevazione dei privilegi
Figura 7 Con il controllo dell'account utente, il SID del gruppo Administrators viene utilizzato solo per la negazione dell'accesso a meno che non si esegua l'elevazione dei privilegi
Quando si esegue il controllo dell'accesso, una voce di questo tipo nel token viene utilizzata solo per negare l'accesso, ovvero per soddisfare le voci ACE di negazione. Tutte le voci ACE di consenso per tale SID vengono ignorate. Ne consegue che un utente, anche se esegue l'accesso al sistema come amministratore, in realtà non dispone sempre dei privilegi di amministratore.

Livelli di integrità
Windows ora supporta l'etichettatura di processi e oggetti con livelli di integrità. I livelli di integrità sono rappresentati anche come voci ACE, ma non fanno parte dell'elenco di controllo di accesso discrezionale (DACL). Fanno invece parte dell'elenco di controllo di accesso di sistema (SACL), con alcuni flag speciali. Ad esempio, il flag NW viene utilizzato per indicare un processo con livello di integrità inferiore a cui viene impedito di scrivere in un oggetto con un livello di integrità superiore (SDDL_NO_WRITE_UP). Questo argomento viene trattato in maniera dettagliata da Mark Russinovich nel suo articolo "Controllo dell'account utente di Windows Vista" in questo numero di TechNet Magazine.

Conclusione
Sebbene non siano state introdotte modifiche rivoluzionarie nel controllo dell'accesso in Windows Vista, come è avvenuto in Windows 2000, è possibile osservare numerose piccole modifiche. Tali modifiche, prese singolarmente, non incidono in modo significativo, ma nell'insieme hanno un notevole impatto sulla modalità di gestione del sistema Inoltre, queste modifiche supportano numerose altre iniziative, in particolare il controllo dell'account utente e la protezione avanzata. È possibile che alcuni amministratori restino delusi quando iniziano a utilizzare Windows Vista. Ho assistito più volte a commenti sui "sistemi operativi tirannici" che impongono restrizioni sulla possibilità di eliminazione di parti del sistema operativo che, per ragioni diverse, non sono gradite. Tuttavia, vi sono valide motivazioni alla base delle modifiche introdotte nel nuovo sistema operativo e, molto probabilmente, se si dedica un po' di tempo all'analisi di ciò che è stato fatto, se ne comprenderà il perché.

Jesper Johansson è Security Architect per una grossa azienda di e-commerce, responsabile per la strategia di protezione nell'ambito della gamma delle proprietà e dei servizi delle applicazioni. Ha lavorato nel settore della protezione per 20 anni ed è autore di numerosi articoli e di due libri dedicati alla protezione. Quando non si dedica alla protezione delle informazioni, insegna immersioni subacquee.


 Protezione: Gestione delle restrizioni hardware tramite Criteri di gruppo
Protezione Jeremy Moskowitz

Gestione delle restrizioni hardware tramite Criteri di gruppo
Panoramica:
  • Limitazione delle installazioni di hardware
  • Restrizioni per dispositivi specifici
  • Restrizioni per classi di dispositivi

Tutti sanno che è vero: le chiavette USB per la memorizzazione dei dati e di altri dispositivi rimovibili semplifica la vita personale ma complica la vita professionale. È necessario trovare il modo di controllare quali
dispositivi hardware possono essere installati e quali no. Per fortuna, con Criteri di gruppo in Windows Vista™ e nella prossima versione di Windows® Server con nome in codice "Longhorn", è possibile autorizzare i mouse USB ma impedire le chiavette USB, autorizzare l'uso dei lettori di CD-ROM, ma non dei masterizzatori di DVD oppure consentire l'uso di dispositivi Bluetooth ma non PCMCIA.
Esistono due sezioni di Criteri di gruppo che aiutano a proteggere l'hardware: Configurazione computer | Modelli amministrativi | Sistema | Accesso agli archivi rimovibili (vedere la Figura 1) e Configurazione computer | Modelli amministrativi | Sistema | Installazione dispositivi | Restrizioni installazione dispositivi (vedere la Figura 2).
Figura 1 Restrizioni hardware predefinite in Criteri di gruppo
Figura 1 Restrizioni hardware predefinite in Criteri di gruppo
Figura 2 Personalizzazione dei tipi di hardware a cui applicare le restrizioni
Figura 2 Personalizzazione dei tipi di hardware a cui applicare le restrizioni
Il nome del primo set (Accesso agli archivi rimovibili) ne spiega già la funzione: se si attiva un'impostazione del criterio per un tipo di dispositivo di archiviazione rimovibile (CD/DVD, disco floppy e così via), sarà quindi possibile limitare la lettura e/o scrittura su tale tipo di dispositivo, se necessario. Le opzioni disponibili però non sono così sofisticate come in Restrizioni per l'installazione di dispositivi.
In Accesso agli archivi rimovibili esistono gruppi di impostazioni del criterio denominati Classi personalizzate: nega accesso in lettura e Classi personalizzate: nega accesso in scrittura. Dal nome si direbbero opzioni interessanti, ma il criterio Accesso agli archivi rimovibili non impedisce l'installazione dei driver. Quando viene rilevato l'hardware, il driver per la classe è già stato installato. Il criterio non fa altro che evitare che si legga o si scriva sul dispositivo. Nella sezione successiva, in cui si descrivono le impostazioni del criterio Restrizioni per l'installazione di dispositivi, sono riportate le istruzioni per bloccare del tutto l'uso del driver.

Gestione di classi e ID
È prima di tutto necessario stabilire con chiarezza quali dispositivi limitare. Si può pensare in grande o in piccolo. Vale a dire, è possibile limitare una determinata "classe" di dispositivi oppure scendere ancora di più nello specifico e limitare un singolo tipo di hardware. È ovviamente possibile ragionare all'inverso e consentire solo specifiche classi di dispositivi, come i mouse USB. Il trucco, in tutti i casi, è tutto qui: per definire dei criteri efficaci, è necessario stabilire in anticipo l'hardware che si desidera limitare.
Se, quindi, si desidera bloccare tutti i driver di joystick e consentire solo l'installazione dei mouse USB, è necessario disporre di un joystick e di un mouse USB. In alternativa è possibile utilizzare Internet per individuare ID hardware, ID compatibile o Classe dispositivo. Tuttavia, se si dispone dei dispositivi fisici, l'operazione risulterà molto più semplice. In questo caso, infatti, è possibile collegare il dispositivo al computer e individuare direttamente ID hardware, ID compatibile o Classe dispositivo. Una volta acquisite queste informazioni, sarà possibile bloccare o l'utilizzo del dispositivo.
Nell'esempio seguente, viene impedito l'utilizzo di una famiglia di scheda audio specifica: una Creative AutoPCI ES1371/ES1373. Per escludere altri dispositivi (dispositivi USB specifici, porte USB e così via), continuare con l'operazione sostituendo di volta in volta il dispositivo desiderato.
Accedere a Gestione dispositivi su un computer su cui siano già installati i dispositivi hardware. Quando si individua il dispositivo, fare clic con il pulsante destro del mouse e scegliere Proprietà, quindi la scheda Dettagli. Per impostazione predefinita viene visualizzata una "Descrizione del dispositivo". Sono informazioni molto interessanti, ma in questo momento poco utili. Scegliere la casella a discesa Proprietà e selezionare "ID hardware", come nella Figura 3.
Figura 3 La scheda Dettagli del dispositivo
Figura 3 La scheda Dettagli del dispositivo
Nella pagina ID hardware vengono visualizzati dall'alto in basso gli ID di dispositivo dal più specifico al meno specifico. Se si esamina con attenzione la prima voce in alto nell'elenco ID hardware, si noterà che questa scheda audio è specificatamente una Rev 2 della scheda audio ES1371. Un'informazione molto dettagliata. Se si scorre l'elenco, la descrizione diventa meno specifica fino a comprendere intere famiglie.
Inoltre, è possibile modificare le Proprietà per ID compatibili. Questi descrivono anche l'hardware e sono considerati meno specifici rispetto agli ID hardware. È possibile decidere di utilizzare le informazioni in ID compatibili per tentare di inserire altro hardware simile nell'elenco dei dispositivi da non utilizzare, perché è meno specifico e consente di raggiungere maggiori risultati. In questo caso si corre però il rischio di limitare dispositivi di cui, invece, si intende consentire l'utilizzo.
Alla categoria meno specifica si accede selezionando Classe dispositivo dalla casella a discesa Proprietà. Nell'esempio, la scheda audio viene indicata semplicemente come Media. I dispositivi di questo tipo sono moltissimi, quindi anche in questo caso meno è dettagliata l'informazione, maggiore deve essere la prudenza.
Una volta deciso il valore da utilizzare, fare clic con il pulsante destro del mouse, scegliere Copia, incollarlo nel Blocco note e memorizzarlo. Eseguire una copia esatta del valore è importante, perché nei passaggi successivi il valore dovrà essere inserito in modo preciso, in particolare dovranno corrispondere tutti i caratteri minuscoli e maiuscoli del valore.
Se per acquisire ID hardware o Classe dispositivo si preferisce utilizzare la riga di comando invece di Gestione dispositivi, leggere le informazioni sull'utilità da riga di comando Devcon all'indirizzo support.microsoft.com/kb/311272. Microsoft consente di utilizzare alcuni ID per le classi più comuni quando non è possibile accedere fisicamente ai dispositivi; consultare le informazioni all'indirizzo go.microsoft.com/fwlink/?LinkId=52665.

Controllo dell'accesso all'hardware con i Criteri di gruppo
Nell'articolo vengono descritte tutte le impostazioni che si trovano in Configurazione computer | Modelli amministrativi | Sistema | Installazione dispositivi | Restrizioni installazione dispositivi (illustrato nella Figura 2), per portare a termine l'operazione dell'esempio è sufficiente una sola di tali impostazioni.
Creare prima di tutto un oggetto Criteri di gruppo (GPO) e collegarlo a un OU (o dominio e così via) che contiene i computer che utilizzano Windows Vista da controllare. Modificare quindi il GPO e passare a Configurazione computer | Modelli amministrativi | Sistema | Installazione dispositivi | Restrizioni installazione dispositivi | Impedisci l'installazione dei dispositivi che corrispondono a uno di questi ID. Scegliere Attivato nell'impostazione del criterio, fare clic su Mostra (anche nell'impostazione del criterio) e scegliere Aggiungi nella finestra di dialogo "Mostra contenuti". Quindi nella finestra di dialogo "Aggiungi elemento", incollare le informazioni sul dispositivo salvate in precedenza, come illustrato nella Figura 4.
Figura 4 Incollare l'ID del dispositivo per ottenere una descrizione esatta
Figura 4 Incollare l'ID del dispositivo per ottenere una descrizione esatta
Questo è il punto cruciale della procedura: se è già stato installato su un computer, il dispositivo non verrà magicamente disinstallato né ne verrà limitato l'accesso. Di conseguenza, se si intende limitare l'accesso all'hardware, sarà necessario eseguire l'operazione prima della distribuzione di Windows Vista. È tuttavia utile sottolineare che in Windows Vista viene rieseguito il controllo a ogni rimozione e reinstallazione del dispositivo. Dispositivi come le unità USB (che vengono spesse rimosse e reinstallate) sono esempi evidenti di applicazione di questo processo. Poiché Windows Vista esegue il controllo solo quando il dispositivo viene ricollegato, il dispositivo viene limitato in tale momento (anche se il driver del dispositivo viene caricato inizialmente sul computer). Il problema più complesso riguarda i dispositivi che vengono forniti con il computer e non vengono rimossi e reinstallati. Per questo tipo di dispositivi, esiste una soluzione non immediatamente evidente.
Quando si accende un computer a cui non è ancora mai stato collegato il dispositivo hardware, Windows tenterà di installare il driver, fornendo le informazioni sullo stato e sul relativo avanzamento. Se si è impostato un criteri per limitare tale dispositivo, si vedrà un risultato come nella Figura 5.
Figura 5 L'installazione di un dispositivo impedita
Figura 5 L'installazione di un dispositivo impedita

Ulteriori restrizioni per l'hardware
Nell'esempio precedente è stato impedito l'accesso a un solo dispositivo. Se necessario, è possibile seguire la procedura opposta, limitando tutto l'hardware e consentendo per impostazione predefinita solo alcuni dispositivi. Anche in questo caso è possibile visualizzare un elenco di impostazioni dei criteri nella Figura 2, che mostra la sezione Configurazione computer | Modelli amministrativi | Sistema | Installazione dispositivi | Restrizioni installazione dispositivi di Criteri di gruppo. È possibile scegliere tra diverse impostazioni disponibili.
La prima è "Consenti agli amministratori di ignorare criteri di Restrizioni installazione dispositivi". Per impostazione predefinita, gli amministratori locali di Windows Vista devono rispettare le restrizioni definite. Se si attiva questa impostazione, gli amministratori locali potranno ignorare la restrizione e installare qualsiasi dispositivo hardware.
La seconda impostazione è "Consenti l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi". Quando si immettono le descrizioni dei dispositivi in questa impostazione di criterio, si consente espressamente l'installazione sul sistema dei dispositivi hardware corrispondenti. Questa impostazione di criterio rispetta solo le classi di installazione, non gli ID di dispositivo (utilizzati nell'esempio).
Per ottenere l'effetto opposto, è possibile impostare "Impedisci l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi".
Le due impostazioni "Visualizza un messaggio personalizzato quando un criterio impedisce l'installazione (titolo fumetto) / (testo fumetto)" consentono di personalizzare il messaggio, come nella Figura 5.
Come già anticipato, la modalità meno specifica per descrivere l'hardware è la classe dell'hardware. È opportuno notare che l'impostazione "Consenti l'installazione dei dispositivi che corrispondono a uno di questi ID" non rispetta le descrizioni di ID classe. Per utilizzare le descrizioni di ID classe, utilizzare "Consenti l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi" oppure "Impedisci l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi". È preferibile utilizzare il secondo criterio con l'impostazione "Impedisci l'installazione di dispositivi non descritti da altre impostazioni dei criteri". Quando si impedisce (per impostazione predefinita) l'accesso a tutto l'hardware e si utilizza quindi questa impostazione, si specifica in modo preciso i dispositivi di cui si desidera consentire l'utilizzo.
Nell'esempio si è utilizzato il criterio "Impedisci l'installazione dei dispositivi che corrispondono a uno di questi ID" per limitare un tipo specifico di hardware in base agli ID dispositivo. Per implementare delle restrizioni utilizzando una Classe dispositivo, è necessario sfruttare altre impostazioni specifiche dei criteri, come "Consenti l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi" oppure "Impedisci l'installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi".
L'opzione "Impedisci l'installazione dei dispositivi rimovibili" rappresenta un modo rapido e generico per limitare qualsiasi dispositivo hardware che descriva se stesso come rimovibile, compresi i dispositivi USB. Questa impostazione resta comunque piuttosto generica, dunque è preferibile non utilizzarla troppo spesso. Utilizzare, invece, le tecniche descritte in precedenza per ottenere ID dispositivo moderatamente restrittivi e bloccarli in modo specifico.
Infine, "Impedisci l'installazione di dispositivi non descritti da altre impostazioni dei criteri" è l'impostazione di criterio che consente di limitare tutto l'hardware di cui non sia stata autorizzata in modo specifico l'installazione. Questi criteri, insieme ai vari criteri di autorizzazione (come "Consenti l'installazione dei dispositivi che corrispondono a uno di questi ID"), rappresentano uno strumento molto valido per autorizzare solo l'hardware che si desidera venga utilizzato nel proprio ambiente.

Conclusioni
I Criteri di gruppo in Windows Vista consentono di eseguire molte nuove operazioni, estremamente utili per autorizzare solo l'hardware che si desidera venga utilizzato nel proprio ambiente. È sufficiente implementare le impostazioni dei criteri prima possibile durante la distribuzione, in modo che risulti da subito impossibile connettere l'hardware che non si desidera venga utilizzato sulla rete.
Intervista con Michael Dennis, il Lead Program Manager per Criteri di gruppo in Microsoft
Ho avuto di recente l'opportunità di intervistare Michael Dennis, che ha diretto il team di Criteri di gruppo in Microsoft fin dalla sua fondazione. Michael sta lasciando il team Criteri di gruppo per inseguire nuove opportunità all'interno di Microsoft. Ho trascorso un po' di tempo in compagnia di Michael a riflettere sugli ultimi nove anni di Criteri di gruppo, sugli obiettivi raggiunti e sulla strada ancora da fare.

Jeremy Moskowitz Michael, credo che molte persone vorrebbero sapere qual è l'obiettivo più importante raggiunto dal team Criteri di gruppo durante la tua conduzione in Microsoft.

Michael Dennis I successi più significativi risalgono a qualche tempo fa, quando ci siamo concentrati sullo sviluppo di ciò che poi sarebbe diventato Criteri di gruppo. In Windows NT® 4.0 esisteva già Criteri di sistema, dunque siamo partiti da quella base e dalla valutazione dei problemi noti all'epoca. Tutto ciò accadeva nello stesso periodo in cui veniva sviluppato Active Directory®, quindi ci siamo dedicati al miglioramento della gestibilità di client e server.
L'idea di origine prevedeva che Criteri di gruppo venisse creato in una gerarchia e il fatto che questa idea fosse del tutto nuova rappresentava molto per noi. Ci siamo di conseguenza concentrati su infrastruttura principale, processi dei client e integrazione con Active Directory.
Il sottoprodotto del nostro miglior risultato si è rivelato il peggior problema. Il motivo erano i problemi della GUI utilizzata in Windows 2000. Per utilizzare le nuove funzionalità in modo efficace, gli utenti avrebbero dovuto laurearsi in Criteri di gruppo, dal momento che nemmeno gli amministratori sapevano bene come funzionasse. Avremmo dovuto creare il Console Gestione Criteri di gruppo (GPMC) e Gruppo di criteri risultante (RSoP) prima di riconsegnare il prodotto (come previsto dalle specifiche).

JM Quali elementi nuovi avresti voluto inserire in Criteri di gruppo?

MD Gli elementi che ho sempre voluto, fin dalla release in Windows 2000, ora sono tutti compresi in Windows Vista: elementi come RSoP, GPMC, impostazioni potenziate e così via. Mi sarebbe piaciuto giungere prima a questo risultato.
Ora vorrei che l'infrastruttura di Criteri di gruppo potesse essere estesa più facilmente dai partner. Il nostro modello di estensione lato server/lato client richiede molto lavoro di sviluppo. È anche vero che la nostra struttura di modelli ADM/ADMX costituisce un framework di facile estensione. Sarebbe tuttavia meglio se quella parte del sistema consentisse ai partner di estendere più tipi di impostazioni.
Un altro desiderio consiste nel rendere il reporting di GPMC più estendibile per strumenti di partner e sviluppatori di terze parti. È un'area su cui siamo stati abbastanza sollecitati dai produttori terzi di strumenti.

JM Quali sono le caratteristiche del team Criteri di gruppo poco note al pubblico?

MD A volte non è chiara a tutti la collocazione del team Criteri di gruppo nel quadro globale. L'idea di fondo prevede che il team crei l'infrastruttura, il trasporto e le parti relative a lato server e lato client. Solo per Windows Vista, tuttavia, abbiamo collaborato con 120 diversi team di Microsoft per integrare le nuove impostazioni di questa versione.
I lettori devono comprendere che Criteri di gruppo non è colpevole degli eventuali problemi di rallentamento del sistema all'avvio o all'accesso. Se il sistema è lento, è piuttosto colpa del payload di Criteri di gruppo. Se si chiede a Criteri di gruppo di eseguire operazioni molto onerose, i rallentamenti diventano una conseguenza ovvia. Se si richiede, ad esempio, un'installazione personalizzata di Microsoft Office per ciascun computer, non c'è problema. L'importante è essere consci del peso dell'operazione richiesta; prima di ottenere un prompt di accesso sarà necessario attendere il completamento dell'installazione di Office. Questo è un rallentamento? Certo che lo è, ma è esattamente ciò che l'amministratore ha richiesto al sistema.

JM Quali sono le funzionalità di Criteri di gruppo che preferisci?

MD In questo periodo sono molto soddisfatto di alcune delle nuove impostazioni integrate in Windows Vista. Le impostazioni dei dispositivi rimovibili (le restrizioni applicate alle chiavette USB e così via) erano funzionalità molto richieste dal pubblico. Sono disponibili circa 2.400 impostazioni in Windows Vista, che offrono agli amministratori un livello di controllo significativo. Mi diverto a chiedere ai clienti cosa vorrebbero tenere sotto controllo e a dimostrare quindi come fare per riuscirci.

JM Perché si è passati dai file ADM agli ADMX?

MD Dal punto di vista tecnico, non è stato necessario tutto questo per ottenere la nuova funzione di archivio centrale di Windows Vista. Il passaggio ad ADMX è stato motivato soprattutto dalla necessità di supportare in modo corretto più lingue contemporaneamente.
In precedenza, negli ambienti multilingue capitava spesso che il contenuto dei file ADM in un GPO venisse inavvertitamente scritto da un'altra lingua. Storicamente, il formato ADM deriva da Windows NT 4.0, che l'ha preso a prestito da Windows 98, che l'ha ereditato da Windows 95. Se all'epoca fosse già stato disponibile, XML sarebbe stato il candidato ideale per il formato dei nostri file.
Ora che è disponibile il formato XML, è diventato più facile supportare più lingue ed esistono ottime opportunità in futuro di apportare miglioramenti a Registro di sistema e impostazioni grazie alla nuova schematizzazione.

JM Quale è stata la sfida più difficile da vincere durante il lavoro nel team Criteri di gruppo?

MD Il problema più rilevante affrontato dal team è la necessità di ottenere gli altri componenti di Windows per attivare i criteri per le rispettive funzionalità.
Il team X può rispondere: &quot;Abbiamo appena creato questa utilissima funzionalità. Perché mai qualcuno dovrebbe disattivarla&?quot; È facile capire le loro ragioni. Abbiamo dovuto risolvere molti di questi problemi.
Le sfide sono anche di carattere tecnico e riguardano l'attivazione di alcuni elementi tramite i criteri, ad esempio, Windows Firewall con protezione avanzata (WFAS). WFAS è stato molto difficile da gestire, poiché la sua corretta attivazione tramite criteri non è affatto così diretta come potrebbe sembrare. L'interfaccia creata dal team WFAS per Windows Vista è eccellente, ma l'integrazione è stata complessa.
Nelle versioni di Windows prima di Vista, i team responsabili dei prodotti non tenevano conto della possibilità di attivare i diversi componenti del pacchetto tramite i criteri. Durante lo sviluppo di Windows Vista, invece, una buona parte dei team ci ha chiesto come fare per consentirne l'attivazione. Un ottimo risultato!
JM Cosa hai in programma per il futuro?

MD Sto passando al team &quot;Mobile Information Worker&quot;, che si occupa di smartphone, Pocket PC e così via. Il mio compito consisterà nell'estendere alcune delle tecnologie di gestione presenti in Windows Server System ai dispositivi Windows Mobile®.
Tenterò di infondere la mia visione e la mia passione per la facilità di gestione e di applicarle a questo nuovo ambito. Lascio comunque il team Criteri di gruppo in una posizione di vantaggio che gli consentirà di procedere anche senza il mio apporto.

JM Vuoi dire altro ai nostri lettori?

MD Il momento più importante dell'intero processo di sviluppo di Criteri di gruppo è stato il contatto con i clienti per comprendere realmente le esigenze sul campo. Se i clienti hanno un'opinione ben strutturata sugli scenari in cui desiderano inserire Criteri di gruppo e delle esigenze aziendali già formate, possono comunicarli con fiducia a Microsoft.
Disponiamo di un meccanismo di commenti e suggerimenti molto buono che tutti possono utilizzare accedendo all'indirizzo WindowsServerFeedback.com. Basta cercare il pulsante di Criteri di gruppo (Group Policy).
Se gli utenti si esprimono nei seguenti termini: &quot;Ecco il problema, ecco le nostre esigenze aziendali, vorremmo conoscere il sistema per ottenere questo risultato e per questo motivo&quot; le informazioni raccolte acquisiscono un valore inestimabile per noi. I responsabili di Criteri di gruppo prendono le proprie decisioni proprio leggendo le informazioni che giungono tramite questo canale.
Dunque, chi desidera avere un impatto sui futuri sviluppi di Criteri di gruppo, deve comunicarci le proprie esigenze. Purché non ci si limiti a scrivere: &quot;Ci serve il criterio di gruppo per fare X&quot; senza alcuna informazione sui motivi e gli obiettivi. Il lavoro del team è esattamente immaginare o scoprire il &quot;come&quot. L'informazione che invece deve fornire il cliente è il &quot;perché&quot;.
JM Grazie per averci raccontato le tue esperienze nel team Criteri di gruppo in Microsoft e in bocca al lupo per la tua nuova attività!
MD Grazie a te, Jeremy.

Jeremy Moskowitz, MCSE e MVP per Criteri di gruppo, gestisce GPanswers.com, il forum della comunità su Criteri di gruppo. Tiene una serie di workshop di formazione intensiva su Criteri di gruppo. Il suo ultimo libro è Group Policy: Management, Troubleshooting and Security (Sybex, 2007). È possibile contattare Jeremy all'indirizzo www.GPanswers.com.


 Protezione: Quattro tecnologie di protezione che tutte le organizzazioni IT devono adottare
Protezione Matt Clapham and Todd Thompson

Quattro tecnologie di protezione che tutte le organizzazioni IT devono adottare
Panoramica:
  • Pannello personale di gestione del rischio
  • Antimalware
  • Rilevamento di anomalie in rete

Nell'ambito della protezione IT, la maggior parte delle organizzazioni affronta ogni giorno gli stessi problemi. Microsoft non fa eccezione. Abbiamo lavorato due anni con il team Risk Management and Compliance di
Microsoft® Managed Solutions (MMS) (vedere "Microsoft ricarica la divisione IT di Energizer" per ulteriori informazioni su MMS).
Al team Risk Management and Compliance è affidato l'incarico di definire, monitorare e correggere l'attitudine al rischio di tutti gli ambienti di MMS (sia per i servizi forniti ai clienti che per il coordinamento dell'infrastruttura). Il responsabile del team, Arjuna Shunn, ha intuito tempestivamente che era necessaria una soluzione tecnologica che garantisse i controlli e il monitoraggio desiderati in modo centralizzato e coerente. Le tecnologie che verranno illustrate nell'articolo sono un risultato diretto delle prime intuizioni del team, associate a due anni di esperienza nell'utilizzo di vari prodotti Microsoft e di terze parti.
Prima di tutto, erano necessarie tecnologie di protezione in grado di garantire i tre principali tipi di controllo: prevenzione, rilevamento e correzione, oltre a funzioni di verifica e reporting. Abbiamo esaminato questa raccolta di strumenti suddividendoli in quattro categorie: pannello personale di gestione del rischio, antimalware, rilevamento di anomalie in rete e gestione della configurazione desiderata. Si è tentato di inserire almeno un rappresentante di ciascuna categoria nelle operazioni di gestione del rischio. La scoperta è stata che sfruttando le tecnologie di ciascuna delle quattro aree, il team di protezione IT può raggiungere un equilibrio ragionevole tra costi ed efficacia.
Le due operazioni principali di gestione del rischio, ovvero gestione delle risposte ai problemi di protezione e gestione della conformità, si sono avvantaggiate di questo approccio, ma la strada da percorrere per ottenere il coordinamento desiderato tra gli strumenti è ancora lunga. Un gruppo coerente di tecnologie può offrire molto di più in termini di efficienza operativa, ma purtroppo sul mercato ancora non esiste un sistema integrato del genere.
Per i team di protezione IT, tuttavia, non tutto è perduto; è solo una questione di tempo prima che i quattro sistemi inizino a operare e interagire insieme con un'efficacia ottimale. Quando questi sistemi opereranno in sintonia, non solo consentiranno il controllo attivo dell'attitudine alla protezione del sistema, ma torneranno anche utili durante i controlli o altre operazioni IT di routine. In questo articolo si descrive la funzione ideale di ciascun sistema, con alcuni utili esempi.

Pannello personale di gestione del rischio
Un pannello personale di gestione di rischio (RMD) è assolutamente necessario. È la singola tecnologia più importante per un team di protezione IT. I rischi correlati a riservatezza, integrità, disponibilità e responsabilità (CIA2) in un'organizzazione sono spesso monitorati da più sistemi e processi diversi, senza un'unica interfaccia che consenta di aggregare i dati, correlare e risolvere le situazioni di rischio. Inoltre, i requisiti normativi specificano livelli di trasparenza dei dati aziendali sempre più difficili da garantire e non esiste alcun sistema semplificato per definire facilmente i criteri, dalla creazione all'esecuzione in azienda. Questa situazione è comprovata dalle difficoltà delle organizzazioni comuni nell'acquisire, correlare, valutare, monitorare/aggiornare e garantire la conformità dei dati. Anche se non rappresenta la soluzione RMD completa qui delineata, System Center Operations Manager 2007, come illustrato nella Figura 1, offre una singola interfaccia per il monitoraggio di più risorse e la raccolta dei relativi avvisi.
Figura 1 System Center Operations Manager 2007 offre una singola interfaccia per la visualizzazione degli avvisi e la gestione delle risorse dell'intera rete
Figura 1 System Center Operations Manager 2007 offre una singola interfaccia per la visualizzazione degli avvisi e la gestione delle risorse dell'intera rete
L'acquisizione dei dati è resa più complessa dall'impossibilità di aggregare e normalizzare i dati provenienti da origini diverse. L'aggregazione di dati è complessa di per se, poiché richiede l'adozione dell'approccio non centralizzato fin troppo comune nella raccolta e nel reporting dei dati. Anche quando si riesce ad aggregare i dati, la normalizzazione continua a porre problemi ancora maggiori perché è estremamente difficile stabilire il quadro operativo comune necessario per supportare la normalizzazione dei dati. Senza la normalizzazione, è impossibile confrontare in modo significativo gli eventi relativi a protezione e integrità che provengono da sistemi diversi.
Per garantire l'automazione necessaria, il pannello personale di gestione del rischio deve avere accesso ai dati provenienti da origini diverse dalle tecnologie di protezione descritte qui. Molti dati non relativi alla protezione possono essere utilizzati per determinare l'attitudine complessiva al rischio. Informazioni come i registri dei router, il controllo dei cespiti, lo stato delle patch, gli utenti attualmente connessi, i report sulle prestazioni e i dati di gestione delle modifiche possono tutte fornire indicazioni pertinenti a chi investiga sui motivi di un problema. Quindi l'intero sistema dee poter accedere a tutti questi dati. È normale che anche la più Microsoft-centrica delle infrastrutture aziendali comprenda delle tecnologie non Microsoft, dunque un RMD deve poter accettare dati provenienti da tecnologie non Microsoft tramite una qualche interfaccia comune.
Quando è possibile acquisire e normalizzare i dati, il passaggio successivo consiste nel metterli in correlazione. L'obiettivo finale consiste nel mettere in correlazione una serie di eventi, come un evento di anomalie in rete, un evento prodotto da un antivirus e un evento di variazione della configurazione, in un blocco di dati relativo al rischio interpretabile e immediatamente utilizzabile. La creazione di una logica di correlazione che consenta di produrre una serie di avvisi significativi relativi al rischio richiede una grande quantità di lavoro manuale. Con le tecnologie attualmente disponibili, tale logica di correlazione è, nel migliore dei casi, difficile da conseguire.
Anche la valutazione dei dati richiede molto lavoro manuale. Nei casi in cui si riesce a correlare i dati, l'analista deve comunque esaminare i dati messi in correlazione per determinarne l'efficacia. L'efficacia dei dati messi in correlazione è direttamente proporzionale all'efficacia delle regole su cui è basata la correlazione. Per valutare il rischio per l'ambiente IT, è quindi necessaria un'ulteriore analisi umana dei dati messi in correlazione. Un quadro complessivo di gestione del rischio chiaro e codificato potrebbe aiutare a ridurre l'entità dell'intervento manuale necessario per ottenere una valutazione prima di un'azione efficace. Senza questo quadro operativo, lo sviluppo di una serie pratica di regole di correlazione in una determinata implementazione è molto complesso.
Ammesso che un sistema riesca a raggiungere il punto di valutazione del rischio, il passaggio successivo è il monitoraggio e aggiornamento automatizzato. Oggi, questa operazione è realmente disponibile soltanto all'interno dell'organizzazione e solo per una serie limitata di tecnologie, come la gestione di patch o antivirus. Il monitoraggio e aggiornamento automatizzato condotto dal sistema RMD garantisce all'amministratore IT un'eccezionale opportunità di mantenere il sistema IT su un livello di rischio accettabile. Quando vengono individuati più rischi simultaneamente, la logica di correlazione deve consentire di definire le priorità per le risposte agli eventi in base ai dati di classificazione dei cespiti.
Infine, garantire la conformità ai vari requisiti normativi costituisce una sfida enorme per i reparti IT e, come già anticipato, il sistema deve supportare tale funzionalità. Un sistema centralizzato di gestione del rischio correlato ai criteri potrebbe rappresentare un grande vantaggio per la produzione di report e prove di conformità. Ma i criteri devono essere necessariamente più significativi di qualche "dove" o "perché". Per facilitare il monitoraggio e aggiornamento automatizzato, i criteri devono essere tradotti in una serie di standard che il pannello personale può monitorare, applicare e verificare.
Il pannello personale di gestione del rischio ideale può dunque essere definito come un modo per fornire un'interfaccia centralizzata per la valutazione dell'integrità dell'organizzazione, della conformità a criteri e normative e dei processi di gestione del rischio. È possibile conseguire questo risultato combinando le informazioni da più prodotti e fonti di protezione in un'unica visualizzazione coerente relativa al rischio. Una buona soluzione RMD deve consentire di:
  • Aggregare, normalizzare e mettere in correlazione i dati da origini diverse
  • Fornire raccolta di informazioni e valutazione del rischio automatizzate
  • Mappare i requisiti normativi in base ai criteri e supportarne il controllo e il reporting
  • Costituire un quadro unificato che può essere modificato in modo da rispondere alle esigenze dell'organizzazione.
Il pannello personale deve inoltre consentire di organizzare e visualizzare i dati in modo significativo, evidenziando, ad esempio, i problemi più frequenti in base al tipo o al sistema di origine, i problemi ancora in sospeso, i problemi risolti e così via. Deve infine consentire di visualizzare maggiori dettagli su ciascuna riga di report. Quando si esamina un evento, deve essere facile accedere a tutti i dati correlati. In tal modo è possibile migliorare la qualità e la rapidità del processo decisionale.
Un RMD risulta utile anche agli amministratori dei team che non si occupano di protezione. Poiché il pannello personale presuppone un punto di vista olistico sull'ambiente, un RMD può funzionare da osservatorio centralizzato sullo stato corrente per tutto lo staff. Il pannello personale può, ad esempio, avvisare il team di messaggistica su un attacco di tipo Denial of Service in corso sul gateway SMTP. Se agli occhi del team di gestione del rischio questo appare come un problema di protezione, il team di messaggistica sarà più propenso a trattarlo come un problema di disponibilità. Sebbene non può essere responsabile della circoscrizione e risoluzione di tale problema, è probabile che il team di messaggistica consideri preziose informazioni come queste che riguardano gli oggetti dell'attività di gestione del team.

Tecnologie antimalware
Un sistema antimalware completo è importante per la protezione dell'infrastruttura da minacce impreviste che si nascondono dietro pezzi di codice e azioni degli utenti. Sono attualmente disponibili due diversi tipi di strumenti per la protezione contro il malware: antivirus e antispyware. Windows® Defender, ad esempio, illustrato nella Figura 2, fa parte della seconda categoria. I prodotti di entrambe le categorie prevengono, rilevano e correggono efficacemente i diversi tipi di infezione. Tuttavia, è solo questione di tempo prima che questi due tipi di protezione vengano sintetizzati in una soluzione unica, con l'utilizzo di un solo stack antimalware su ciascun sistema.
Figura 2 Windows Defender protegge il client dallo spyware
Figura 2 Windows Defender protegge il client dallo spyware
Una soluzione antimalware completa deve monitorare il sistema in tempo reale ed eseguire analisi periodiche. Deve inoltre fornire report sul malware conosciuto (compresi virus, spyware e rootkit) e sconosciuto, in base ai tipici comportamenti a rischio. Una robusta tecnologia antimalware sorveglia tutti i punti di ingresso classici (compresi file system, Registro di sistema, shell, browser, e-mail e applicazioni connesse) con una stretta integrazione con sistema operativo e applicazioni.
Inoltre, una soluzione antimalware deve gestire molto più della semplice protezione degli host. È infatti necessario che agisca sui servizi di messaggistica e collaborazione comuni, spesso utilizzati per il passaggio di file infetti, come SharePoint® e la messaggistica istantanea. Una soluzione di questo tipo deve inoltre garantire una prevenzione automatizzata bloccando le operazioni in corso (conosciute e sospette), oltre all'accurata analisi dei dati utente per la rimozione di elementi quali i virus delle macro che si nascondono nei documenti utente e che non hanno ancora infettato il sistema.
È ovvio che una soluzione antimalware senza aggiornamenti è inutile. Sul sistema devono essere sempre presenti le firme e i sistemi di rimozione aggiornati, per tenere testa anche alle minacce più recenti. Se viene rilevata una nuova minaccia, il produttore deve adottare ulteriori protezioni prima della successiva ora zero. Una soluzione antimalware di facile utilizzo è anche configurabile e aggiornabile in modo centralizzato.
È ovvio che una protezione di questo livello non deve essere ottenuta a scapito delle prestazioni. Se le prestazioni peggiorano, diminuisce anche la produttività. Gli utenti potrebbero anche tentare di disattivare la soluzione antimalware, creando scenari di protezione del tutto assente.
Non deve, infine, essere trascurata l'importanza delle tecnologie ausiliarie che facilitano il compito del sistema antimalware. I firewall, la limitazione dei privilegi utente e altre strategie consentono di migliorare anche la protezione da codice dannoso e azioni degli utenti.

Rilevamento di anomalie in rete
Mentre l'antimalware sorveglia i sistemi, il rilevamento delle anomalie in rete (NAD) monitora i percorsi comuni, valutando alcuni indicatori ben noti di comportamenti sospetti e riportando tali informazioni al RMD per il monitoraggio e l'aggiornamento. Un firewall, ad esempio, come illustrato nella Figura 3, va inserito in questa categoria. I comportamenti sospetti potrebbero essere del traffico tipico di alcuni attacchi (come worm o Denial of Service) o dei dati che corrispondono a un determinato modello (come dei codici fiscali) e che vengono inviati tramite messaggi di e-mail.
Figura 3 Un firewall è una parte importante di una soluzione di rilevamento di anomalie in rete
Figura 3 Un firewall è una parte importante di una soluzione di rilevamento di anomalie in rete
Malgrado gli sforzi profusi nella gestione IT, in tutte le grandi reti aziendali verrà inevitabilmente rilevato un episodio occasionale di malware. Il NAD costituisce un sistema di avviso tempestivo che può aiutare ad accelerare la risoluzione del problema. Inoltre, le funzionalità di monitoraggio dei dati del NAD e la possibilità di individuare e bloccare la divulgazione di informazioni riservate sono strumenti utili per proteggere le informazioni in ambienti in cui sia fondamentale evitare la perdita di dati e garantire la conformità alle normative.
Come con le tecnologie antimalware, per non comprometterne l'efficacia, il NAD deve essere costantemente adattato alla serie più recente di minacce e ai tipi di dati sensibili. Inoltre, un buon sistema NAD deve essere in grado di riconoscere le anomalie reali, in modo da minimizzare il numero di falsi positivi. In caso contrario, gli amministratori inizieranno a ignorare i report che provengono dal NAD, presupponendo che si tratti solo di altri falsi allarmi.
Dopo un periodo di regolazione e addestramento, il sistema NAD sarà in grado di riconoscere e monitorare i modelli tipici di utilizzo del traffico. Questo è importante, poiché i nuovi tipi di malware e di altri attacchi spesso rivelano la propria presenza con un cambiamento nei modelli di utilizzo. I dispositivi impiegati per il collegamento in rete assumono un ruolo significativo nel sistema NAD, giacché la soluzione deve elaborare i dati provenienti da router, switch e firewall. Gli allarmi del NAD possono quindi essere elaborati dal motore di correlazione del RMD.
È interessante la possibilità di integrare i rilevatori di anomalie in rete nel software antimalware o nel firewall dell'host, creando un diaframma di protezione che tutti i computer interessati aiutano a mantenere integro, bloccando gli attacchi prima che si diffondano.

Gestione della configurazione desiderata
Una delle sfide più pressanti che i reparti IT affrontano quotidianamente nelle grandi organizzazioni consiste nel conservare le configurazioni appropriate dei sistemi. I buoni motivi per conservare le configurazioni di sistema sono molti: facilità di gestione, semplificazione della scalabilità, garanzia di conformità, chiusura contro varie forme di intrusione e aumento della produttività, solo per nominarne alcuni. Molti di questi si ripercuotono sul livello complessivo di protezione.
La gestione della configurazione desiderata è un'area largamente ignorata nella maggior parte delle aziende, a causa della complessità che implica e dei costi di avvio. Gli studi tuttavia confermano che, nel lungo termine, la manutenzione dei sistemi consente di ridurre i costi e migliorare l'affidabilità. Una soluzione di monitoraggio della configurazione desiderata (DCM) può aiutare.
Un buon sistema DCM deve eseguire automaticamente l'analisi della rete, per verificare che i nuovi sistemi vengano distribuiti come desiderato e che i sistemi già esistenti restino conformi ai criteri definiti. Sia che verifichi che venga distribuita la patch più recente o che riduca al minimo il numero di utenti che hanno privilegi di dominio, una soluzione DCM completa deve configurare i sistemi, analizzarli e fornire informazioni su quanto ciascuna configurazione sia prossima all'ideale. Le correzioni possono essere semplici (come applicare una patch ai nuovi sistemi in rete al momento dell'installazione) o forzosa (come imporre delle impostazioni per i client e-mail degli utenti). La chiave consiste nel definirle sulla base dei criteri e delle esigenze di conformità dell'organizzazione. Un DCM può collaborare anche all'identificazione e rimozione di infezioni da malware, poiché i tipi più semplici vengono facilmente rilevati nei risultati dell'analisi.
Il DCM è uno dei principali fornitori di dati al motore di correlazione del RMD e offre dettagli importanti sullo scostamento dell'host in questione rispetto alla configurazione normale. La tempestività dei dati può fare la differenza tra uno o cinque eventi di allarme, quindi un cespite deve essere analizzato con una frequenza proporzionale al proprio valore; ad esempio, un cespite poco importante può essere analizzato anche solo mensilmente, mentre un cespite di rilevanza media deve essere analizzato ogni settimana e uno di importanza critica ogni giorno.
L'installazione di un DCM è inoltre parte fondamentale di un buon meccanismo di protezione degli accessi alla rete (NAP), poiché consente al sistema di verificare che tutti i sistemi connessi siano configurati in modo corretto e di bloccare i sistemi nuovi o sconosciuti fino alla convalida. Inoltre, un DCM deve ricercare vulnerabilità di configurazione (come elenchi di controllo degli accessi deboli su una condivisione) in modo che gli amministratori possano intraprendere le azioni più appropriate.
Non è corretto pensare che un DCM possa essere applicato solo a host come client o server. Anche i dispositivi di connessione in rete e la directory principale possono essere inclusi in un DCM. Se è disponibile una struttura di rete ben conosciuta, dovrebbe essere semplice per il sistema DCM ideale applicare gli standard per i dispositivi associati. Le potenzialità sarebbero davvero enormi. Invece di modificare manualmente le configurazioni dei router, l'implementazione può essere gestita da un DCM oppure è possibile associare una serie di impostazioni di Criteri di gruppo standard a una serie particolare di server o client. Il DCM può monitorarli ed emettere un avviso quando le impostazioni del dominio vengono modificate.
I dati raccolti dal DCM devono essere abbastanza affidabili da essere utilizzati in un controllo IT. Una buona soluzione DCM deve poter accedere alla gestione delle modifiche e ai controlli di conformità alle normative, in modo che i problemi di controllo possano essere risolti in modo tempestivo e continuo. Una delle routine di controllo in Microsoft, ad esempio, consiste nel verificare che non venga modificata l'appartenenza dell'amministratore locale sui server MMS. L'applicazione di questa regola è un esempio perfetto di utilizzo del DCM.
Anche se il reparto IT non è pronto ad adottare un sistema DCM a correzione automatica, una variazione nota come controllo della configurazione desiderata può essere comunque distribuita e offrire notevoli vantaggi. Anche questa variazione produce report e avvisi sui problemi di configurazione, ma non si ottengono le stesse economie di scala poiché le fasi di monitoraggio e aggiornamento sono in gran parte manuali. È importante sottolineare, tuttavia, che notifiche e dati necessari per un RMD saranno disponibili per la correlazione.
Attenzione, però: l'ambito di un DCM, in una qualsiasi delle forme appena descritte, deve essere definito sui soli elementi meno importanti della configurazione associati ai dati standard raccolti sui cespiti. In caso contrario si potrebbe influire negativamente sulla flessibilità necessaria al team IT. Se le guide di configurazione DCM diventano obsolete, il DCM diventerà rapidamente un costo operativo piuttosto che uno strumento utile. È dunque fondamentale tenere sempre aggiornata la configurazione ottimale dei cespiti. Inoltre, è consigliabile che il sistema DCM comprenda gli aggiornamenti regolari dei criteri di configurazione, in base alle procedure consigliate per il cespite o l'applicazione in questione.

Conclusioni
Che lo si crei ex-novo all'interno dell'organizzazione oppure lo si acquisti da un produttore affidabile, il pannello personale è essenziale ed è destinato a costituire lo strumento primario del team per la risoluzione dei problemi. Anche le applicazioni antimalware sono essenziali, poiché aiutano a proteggere il sistema dai rischi che si moltiplicano ogni giorno che passa. Il rilevamento delle anomalie in rete è sul punto di passare dal semplice rilevamento delle firme di malware e di intrusioni negli host a funzioni più complesse di rilevamento delle divulgazioni di dati, che possono aiutare a evitare le prossime violazioni della rete. La gestione della configurazione desiderata, sebbene sia uno strumento nuovo, diventerà presto un pilastro del monitoraggio e della manutenzione delle configurazioni. Indipendentemente dal fornitore, è necessario procurarsi almeno uno strumento di ciascuna di queste quattro categorie.
Da quanto si è visto fino ad ora, nessun singolo produttore (Microsoft compreso) offre una soluzione unica e completa che assolva a ciascuna delle quattro funzioni. La selezione di prodotti che soddisfano le proprie esigenze specifiche dipende dal singolo utente. Lo scopo dell'articolo è semplicemente diffondere la consapevolezza di ciò che è necessario, degli obiettivi da perseguire e delle soluzioni ideali.

Matt Clapham è Security Engineer nel gruppo Infrastructure and Security della divisione IT di Microsoft. In precedenza ha lavorato per due anni nel team Microsoft Managed Solutions Risk Management and Compliance.
Todd Thompson è Security Engineer nel gruppo Infrastructure and Security della divisione IT di Microsoft. In precedenza ha lavorato per due anni nel team Microsoft Managed Solutions Risk Management and Compliance.


 Protezione: Uno strumento nuovo e potente per la gestione dei certificati
Protezione Kevin Dallmann

Uno strumento nuovo e potente per la gestione dei certificati
Panoramica:
  • Architettura di ILM-CM
  • Amministrazione e modelli
  • Creazione di un flusso di lavoro

Al lavoro è una giornata tranquilla, quando arriva una chiamata dal team del supporto tecnico: è scaduto il certificato di uno dei sistemi di produzione. Ora il sistema non è disponibile e l'azienda sta perdendo produttività e denaro finché non lo si rinnova.
I responsabili della gestione di un ambiente PKI (Public Key Infrastructure, infrastruttura a chiave pubblica) saranno senz'altro sorpresi di sapere che un certificato è scaduto inaspettatamente. E comunque ora addio giornata tranquilla.
Quando Microsoft ha aggiunto i servizi PKI a Windows® 2000 e Windows Server® 2003, implementare un proprio ambiente PKI interno per le aziende era semplice e poco costoso. Purtroppo però i servizi PKI Microsoft® non consentivano di gestire il ciclo di vita dei certificati che venivano generati. Recentemente, tuttavia, Microsoft ha acquisito un prodotto per la gestione dei certificati e ha rilasciato Identity Lifecycle Manager (ILM) che combina la gestione dei certificati con il provisioning di identità e le funzionalità di controllo di Microsoft® Identity Integration Server (MIIS). In quest'articolo verrà illustrato come utilizzare ILM per la gestione dei certificati e delle smart card dell'organizzazione.

Architettura di ILM-CM
Il nucleo dell'architettura di ILM Certificate Management (gestione certificati ILM) è costituito dal server ILM-CM e dai componenti correlati (vedere la Figura 1). Il server ILM-CM può essere installato in una configurazione server singola in modo da interfacciarsi con una o più autorità di certificazione (CA). Per ILM-CM è necessario SQL Server™, in cui sono memorizzate le informazioni sui certificati, i criteri e altri dati correlati, utilizzati per gestire i certificati nell'ambiente. Per gestire gli utenti e le autorizzazioni di protezione, per il server ILM-CM è inoltre necessario Active Directory®. Per le versioni e i componenti necessari vedere la Figura 2.
Figure 2 Supporto dell'infrastruttura ILM-CM (Close Figure 2)

Componenti | Versioni
Active Directory | Windows Server 2003
Server di database | SQL Server 2000 SP3 o successivi oppure SQL Server 2005
Autorità di certificazione | Windows Server 2003 Enterprise Edition o Data Center Edition
SMTP | Server SMTP
Figura 1 Architettura di ILM-CM
Figura 1 Architettura di ILM-CM
Una volta che l'ambiente ILM-CM sarà stato completamente installato, tutte le richieste di certificati verranno comunicate al server ILM-CM. Il server ILM-CM ha la funzione di archiviare le informazioni relative ai certificati nel database SQL Server, il quale può essere ulteriormente utilizzato per generare report e avvisi, nonché per gestire un ambiente di flusso di lavoro.
L'architettura software di ILM-CM è costituita essenzialmente da tre parti di alto livello: server ILM-CM, plug-in per le autorità di certificazione e componenti del lato client. È possibile installare ed eseguire il software server su una CA o su un server utilizzato principalmente per ILM-CM, il quale comunica con le CA, il database SQL Server e Active Directory. Fornisce inoltre un portale Web utilizzabile dai gestori dei certificati per configurare i criteri e i flussi di lavoro dei certificati e dai sottoscrittori per richiedere e rinnovare certificati software.
Perché la CA comunichi con il server ILM-CM, i moduli uscita e criteri ILM-CM devono essere installati e configurati su tutte le CA che si desidera gestire. Questi due moduli vengono utilizzati per registrare le informazioni dei certificati nel database. Quando una CA emette un certificato, le informazioni vengono inviate al server ILM-CM tramite il modulo uscita e il server, a sua volta, registra le informazioni del certificato nel database.
Se si prevede di gestire smart card nell'ambiente, è necessario installare il software client per le smart card di ILM-CM. Questo software è necessario in tutti i computer client che devono interagire con il server ILM-CM.

Installazione di ILM-CM
L'installazione del server ILM-CM è in effetti piuttosto semplice: è disponibile una procedura guidata che agevola il processo. Prima di eseguire la procedura guidata, è necessario svolgere alcune funzioni di preinstallazione.
In primo luogo per ILM-CM sono necessari Active Directory e un'estensione dello schema ILM-CM. Tramite l'estensione dello schema vengono aggiunti gli attributi di protezione di Microsoft .NET Framework richiesti da ILM-CM per implementare i modelli di profilo.
È inoltre necessario installare .NET Framework 2.0 e devono essere presenti i componenti citati in precedenza: SQL Server, le CA e il server SMTP. Se ILM-CM deve essere installato in un server distinto dalla CA, è necessario installare i moduli ILM-CM nelle CA eseguendo su di esse la procedura guidata di installazione di ILM-CM. Una volta completata l'installazione, puntando il browser su http://nomehost/CLM dovrebbe essere possibile connettersi al portale ILM-CM.
Per attivare la notifica della scadenza/rinnovo dei certificati è necessario configurare il servizio ILM-CM sul server ILM-CM. Iniziare creando un account adatto in Active Directory. Passare ai servizi ILM-CM e aggiungere questo account come account di accesso. Aggiungere quindi l'utente al gruppo degli amministratori locali e IIS_WPG sul server ILM-CM e impostare i privilegi "Agisci come parte del sistema operativo, Generazione controlli di protezione e Sostituzione di token a livello di processo" utilizzando i criteri di gruppo. Una volta impostato il servizio ILM-CM, il server ILM-CM potrà analizzare il database SQL Server alla ricerca di certificati scaduti e inviare una notifica tramite posta elettronica ai proprietari o ai gestori dei certificati.

Amministrazione di ILM-CM
ILM-CM viene gestito tramite un'interfaccia Web, divisa in aree funzionali relative alle attività di gestione degli utenti, dei certificati e delle smart card. Quando si è connessi al portale ILM-CM con privilegi amministrativi adeguati, vengono visualizzate varie attività di amministrazione che consentono di gestire l'ambiente ILM-CM (vedere la Figura 3). Nella sezione relativa alle attività comuni sono presenti opzioni che includono la registrazione di utenti per una nuova serie di certificati o una smart card. È altresì possibile gestire e approvare richieste.
Figura 3 Attività del portale di gestione ILM-CM
Figura 3 Attività del portale di gestione ILM-CM
Per identificare utenti e certificati si utilizza l'area relativa alla gestione degli utenti e dei certificati. Le attività disponibili in quest'area consentono di trovare, ripristinare, revocare o rinnovare certificati. È inoltre possibile visualizzare un elenco delle revoche.
Se l'organizzazione utilizza le smart card, è utile la sezione relativa alla gestione delle smart card degli utenti. Se, ad esempio, la smart card di un utente è bloccata, da qui è possibile sbloccarla. È inoltre possibile visualizzare le smart card inserite nel lettore locale ed eseguirvi ricerche.
L'area relativa alla richieste dell'interfaccia consente ai gestori dei certificati di riesaminare e approvare le richieste di certificati degli utenti. È ad esempio possibile visualizzare i certificati contenuti in una richiesta con stato in sospeso. L'area relativa all'amministrazione consente di creare e gestire modelli di profilo. Infine, l'area relativa ai report viene utilizzata, come prevedibile, per sviluppare e creare report relativi a utenti e certificati.
Quando l'utente viene autenticato presso il portale ILM-CM, se l'account non dispone di privilegi amministrativi, viene visualizzata una pagina di sottoscrizione dotata di funzionalità di gestione self-service per gli utenti dei certificati (vedere la Figura 4). Dal portale, gli utenti possono visualizzare e gestire i propri certificati e smart card in base alla configurazione di criteri specifici. Sono esempi di attività comuni la richiesta di certificati o smart card, la verifica di certificati esistenti e la modifica del codice PIN delle smart card.
Figura 4 Pagina di sottoscrizione del portale per gli utenti con funzionalità di amministrazione self-service
Figura 4 Pagina di sottoscrizione del portale per gli utenti con funzionalità di amministrazione self-service
Fornire un processo di flusso di lavoro delegato di alta qualità per emettere, rinnovare, revocare e sostituire i certificati o le smart card costituisce una sfida in qualunque organizzazione. Con ILM-CM è possibile delegare queste attività con maggiore tranquillità. Supponiamo che un utente abbia dimenticato il codice PIN di una smart card. Utilizzando il modello di flusso di lavoro delegato, l'utente può rivolgersi al supporto tecnico e rispondere a qualche domanda di verifica. Se le risposte alle domande sono corrette, il personale del supporto sblocca la smart card dell'utente. Un altro esempio di flusso di lavoro delegato potrebbe essere costituito dal recupero del certificato EFS (Encrypted File System, file system crittografato) di un utente in caso di eliminazione accidentale o smarrimento di un computer portatile.

Modelli di profilo
Il modello di profilo è il componente fondamentale che attiva un processo di gestione del flusso di lavoro completo per ILM-CM. Un modello di profilo è considerato un unico oggetto amministrativo contenente uno o più modelli di certificato. I modelli di profilo vengono creati e configurati per gestire il funzionamento del processo di flusso nell'ambiente dei certificati. L'aspetto principale di un modello di profilo è la capacità di contenere più modelli di certificato gestibili come un unico elemento, vale a dire che è possibile gestire gli utenti da un modello che tiene traccia del processo del certificato per tutto il ciclo di vita.
I modelli di profilo possono essere configurati in modo da memorizzare i certificati in un computer (tramite software) o in una smart card (tramite hardware). È possibile creare questi modelli duplicando un esempio dal portale di amministrazione ILM-CM. Nel modello di profilo, è possibile definire diversi componenti dei criteri di gestione (vedere la Figura 5).
Figura 5 Un modello di profilo
Figura 5 Un modello di profilo
Molti dei componenti dei criteri sono applicabili sia ai profili software sia ai profili smart card (vedere la Figura 6). Alcuni di questi meritano un ulteriore commento. Durante il processo di registrazione del certificato, è possibile utilizzare il componente di registrazione criteri per definire alcuni criteri riguardanti le modalità desiderate per il flusso del processo di registrazione. È ad esempio possibile impostare una raccolta di dati, vale a dire che l'utente deve inserire informazioni quali i codici di reparto, l'indirizzo di posta elettronica e i dati del gestore. È altresì possibile creare definizioni per stampare automaticamente un documento ufficiale una volta che l'utente ha registrato il certificato.
Figure 6 Criteri di profilo software (Close Figure 6)

Componente | Descrizione
Dettagli del profilo | Fornisce i dettagli generali del modello di profilo. Qui è possibile aggiungere uno o più modelli di certificato al modello di profilo.
Criterio di duplicazione | Definisce le entità del flusso di lavoro di un certificato esistente.
Criterio di registrazione | Definisce il flusso di lavoro del processo di registrazione.
Criterio di aggiornamento in linea | È simile al criterio di rinnovo, ad eccezione del fatto che consente di aggiornare i certificati in scadenza, il contenuto di certificati, modelli e applet di smart card.
Criterio Recupero per conto altrui | Consente di recuperare la chiave privata o i certificati di un utente.
Criterio di rinnovo | Consente di definire il flusso di lavoro di rinnovo quando un certificato scade.
Criterio di reintegro | Consente di definire il processo per reintegrare un certificato.
Criterio di ripristino | Consente di definire il flusso di lavoro per ripristinare un certificato utente memorizzato su un computer che viene eliminato, ricreato o rubato.
Criterio di revoca | Consente di definire il flusso di lavoro per revocare tutti i certificati di un profilo.
I criteri di aggiornamento in linea possono essere molto utili per l'organizzazione. Sono simili ai criteri di rinnovo, a eccezione del fatto che con questo metodo è possibile aggiornare il contenuto dei certificati, i modelli di certificato, gli applet contenuti nelle smart card, nonché il certificato in sé quando sta per scadere. Per utilizzare appieno questi criteri, è necessario attivare il servizio ILM-CM e il file web.config per consentire l'accesso a un attributo con più valori in Active Directory. Sarà inoltre necessario installare il servizio di aggiornamento in linea nel computer client.
Il criterio Recupero per conto altrui può essere utile se l'azienda utilizza la crittografia EFS. Supponiamo che qualcuno elimini accidentalmente il certificato di crittografia. È possibile utilizzare questo componente dei criteri per impostare un flusso di lavoro in cui il team del supporto tecnico che si occupa della protezione richiede la chiave privata dell'utente. L'utente potrebbe così recuperarla ricevendo un messaggio di posta elettronica contenente una password segreta generata dal server ILM-CM e accedere a un collegamento Web privato sul server ILM-CM per recuperare il certificato con le chiavi private associate. Il criterio Recupero per conto altrui è particolarmente utile anche nel caso un dipendente abbia lasciato l'organizzazione, ma sia necessario recuperarne i dati a fini normativi, di archiviazione o altro.
Per proteggere maggiormente il processo di rinnovo, il relativo criterio consente di impostare e inviare per posta elettronica la chiave privata, necessaria per il rinnovo dei certificati, che gli utenti utilizzeranno come password una sola volta. Se si revoca un certificato e in seguito si desidera reintegrarlo e rimuoverlo dall'elenco di revoche di certificati (CRL), è possibile definire tale processo di flusso di lavoro tramite il criterio di reintegrazione.
Due componenti univoci, associati esclusivamente ai criteri di certificati software e non alle smart card, costituiscono i criteri di ripristino e revoca. Se un certificato utente memorizzato in un computer viene eliminato, il computer viene rubato o ne viene modificata la configurazione hardware, il processo per ripristinare il certificato o le chiavi, se archiviate sulla CA, potrebbe essere definito tramite il criterio di ripristino. Il criterio di revoca consente all'amministratore di impostare una motivazione statica per la revoca o alla persona che esegue la richiesta di indicarne la motivazione al momento della revoca.
Sono presenti cinque criteri di gestione aggiuntivi specifici per i modelli di profilo delle smart card, come illustrato nella Figura 7.
Figure 7 Criteri di profilo smart card (Close Figure 7)

Componente | Descrizione
Criterio di sostituzione | Consente di definire il profilo nel caso la smart card di un utente venga smarrita o rubata.
Criterio di disattivazione | Consente di definire il processo di disattivazione di certificati contenuti in una smart card prima della loro scadenza.
Criterio di ritiro | Consente di definire il processo per revocare tutti i certificati su una smart card.
Criterio di sblocco | Consente di definire chi può sbloccare il codice PIN dell'utente di una smart card.
Criterio per smart card temporanee | Consente di definire una smart card sostitutiva per un breve periodo. L'utente riceve nuovi certificati di firma ma sarebbe in grado di decrittografarne i dati ottenendo i certificati di crittografia del profilo esistenti.
È possibile definire varie operazioni diverse per il criterio di ritiro, come cancellare i dati dell'utente dalla smart card, bloccare l'utente e i codici PIN di amministrazione e ripristinare il PIN amministrativo. Il criterio di sblocco viene in genere utilizzato se un utente ha dimenticato il PIN o ha ricevuto una nuova smart card con un PIN assegnato da ILM-CM. In questi casi l'utente richiede lo sblocco della smart card.
Come in qualunque prodotto amministrativo, i report sono uno strumento molto utile. La possibilità di acquisire un'istantanea dell'ambiente dei certificati o delle smart card è molto importante per qualsiasi organizzazione. In ILM-CM sono incorporati diversi report standard, fra cui inventari delle smart card, riepiloghi delle richieste, utilizzo e scadenze dei certificati e altro ancora. Come avviene con altri sistemi, se sono necessari report aggiuntivi, è possibile scrivere query personalizzate poiché tutti i dati sono memorizzati in un database SQL Server.

Sviluppo di un flusso di lavoro
Vediamo ora come ILM-CM può essere utile per definire un processo di flusso di lavoro produttivo. Supponiamo che vi siano vari amministratori di sistema, responsabili della gestione e della manutenzione dei certificati SSL per i propri sistemi. La prima domanda è: quali sono gli aspetti principali del processo?
A seconda del tipo di sistema, il processo può richiedere metodi diversi per la creazione del file di richiesta del certificato. La prima operazione consiste nello sviluppare una pagina intranet con istruzioni dettagliate su come creare la richiesta del certificato per tutti i sistemi.
Dopo avere creato il file di richiesta, l'amministratore potrà inoltrarlo al portale ILM-CM degli utenti per l'approvazione del certificato. Utilizzando il processo di flusso di lavoro di ILM-CM, l'amministratore può definire vari approvatori che dovranno verificare e approvare le richieste di certificati. Dopo l'approvazione di un certificato, l'utente potrà recuperarlo da ILM-CM. Poiché le informazioni dei certificati vengono inserite in un database SQL Server, gli amministratori possono recuperare le informazioni cronologiche.
Un anno dopo, quando il certificato si avvicinerà alla scadenza, il richiedente riceverà una notifica tramite posta elettronica da ILM-CM per informarlo che il certificato sta per scadere e deve essere rinnovato. La messa in atto di questo processo di flusso di lavoro contribuirà a scongiurare la scadenza imprevista di certificati evitando così di rovinare la giornata agli amministratori.

Riepilogo
Se l'azienda utilizza un ambiente Microsoft PKI, ILM-CM può essere utile per gestirlo. ILM-CM consente alle organizzazioni di migliorare i processi di autenticazione per la protezione e di ridurre i costi e le complessità derivanti dalla gestione di smart card e certificati digitali. ILM-CM sarà inoltre l'elemento di base su cui sviluppare i processi di flusso di lavoro per certificati e smart card di cui oggi molte aziende sentono la mancanza.
Microsoft ha inoltre implementato il supporto di un'API esterna per ILM-CM. Se l'organizzazione utilizza applicazioni personalizzate, potrebbe essere possibile interfacciare queste applicazioni per trarre vantaggio dal supporto di API ILM-CM.
Per ulteriori informazioni su ILM-CM, vedere microsoft.com/technet/clm. Una guida introduttiva è disponibile anche all'indirizzo (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann è consulente come Senior Systems Engineer presso Accenture ed è responsabile in primo luogo del supporto di ambienti Active Directory e PKI per grandi imprese. Kevin ha conseguito le certificazioni MCSE e MCT ed è docente di corsi Microsoft.


 Dal redattore: Problemi di protezione
Dal redattore
Problemi di protezione
Joshua Trupin

Ultimamente i rischi per la protezione sembrano essere diventati un po' più gestibili. Saremmo senz'altro lieti se il merito fosse tutto da attribuire a TechNet Magazine, ma vi sono alcuni altri fattori che entrano in gioco. Il due principali sono la consapevolezza e la solidità.
La consapevolezza consiste semplicemente nel restare all'erta per quanto riguarda potenziali minacce e tecniche di ingegneria sociale, oltre che nell'installare regolarmente patch e aggiornamenti per proteggere il software già presente. La solidità costituisce l'altra faccia della medaglia, ovvero il concetto che sia possibile creare software più sicuro e in modo da ridurre al minimo gli attacchi superficiali disattivando per impostazione predefinita le funzioni esposte.
E in più c'è un altro fattore: leggere TechNet Magazine con regolarità. È impossibile dimenticarsene! Questo è il nostro già quasi famoso numero sulla protezione, nel quale sono contenuti ben sette articoli che saranno senz'altro di aiuto agli analisti/professionisti del settore per essere sempre in guardia per la propria azienda. Nell'articolo di apertura di Mark Russinovich si parla del controllo degli account utente (UAC), mentre Steve Riley approfondisce l'argomento Windows Firewall e Jesper Johansson esplora le modifiche apportate agli elenchi di controllo dell'accesso (ACL) in Windows Vista. Jeremy Moskowitz inoltre prende in considerazione Criteri di gruppo e illustra i blocchi hardware, mentre Michael Murgolo offre il suo contributo con i PowerToys abilitati agli script e altro ancora. Il numero oggi disponibile potrebbe essere il più importante mai pubblicato.
Pur restando sempre sulla difensiva è utile conoscere le nuove offerte Microsoft per la protezione. Microsoft Forefront rappresenta il fattore "solidità", si tratta di prodotti line-of-business che offrono protezione in tre settori: sistemi operativi client, applicazioni server e margini della rete. Contiene strumenti di protezione per Exchange Server e SharePoint e include ISA Server e Intelligent Application Gateway per il traffico di rete. Intelligent Application Gateway rappresenta la parte della &quot;consapevolezza&quot; in quanto consente di acquisire la conoscenza dei sistemi, di semplificare le operazioni e la gestione, di generare report e di migliorare l'erogazione dei servizi. Include tecnologie di configurazione e di monitoraggio delle operazioni della prossima generazione, fra gli altri strumenti.
Per ulteriori informazioni su Forefront e System Center, visitare il sito Microsoft relativo all'infrastruttura all'indirizzo Microsoft.com/infrastructure. Per ottenere le soluzioni migliori per i problemi di protezione, nonché acquisire consapevolezza e solidità, c'è TechNet Magazine.
—Joshua Trupin

Si ringraziano i seguenti esperti tecnici di Microsoft: Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher e Buck Woody.


 Casella degli strumenti: Nuovi prodotti per professionisti IT
Casella degli strumenti Nuovi prodotti per professionisti IT and Greg Steen
All'interfaccia di myLittleAdmin è possibile applicare una skin
L'interfaccia utente basata sul Web supporta la maggior parte delle operazioni di database, compresa la creazione di nuovi database, consente di gestire i database esistenti e i relativi contenuti, nonché di utilizzare snapshot e schemi. Modificare le proprietà degli oggetti di database esistenti è semplice e in myLittleAdmin è disponibile un'utile griglia di dati ridefinibile per modificare singole righe delle tabelle. L'interfaccia della visualizzazione struttura è simile a quella di SQL Server Management Studio, per cui già nota. Il solo ostacolo è costituito dal fatto che facendo clic con il pulsante destro del mouse a volte non viene visualizzato il menu di scelta rapida che ci si aspetterebbe.
È possibile utilizzare myLittleAdmin anche per modificare gli accessi, i ruoli del server e le credenziali dell'istanza di SQL. Consente perfino di creare e modificare le periferiche di backup e i server collegati, attività che è utile poter eseguire da una posizione remota.
Con myLittleAdmin è possibile svolgere attività quali l'esecuzione di query ad hoc, il collegamento o lo scollegamento di database, l'esecuzione di backup e ripristino, l'importazione di dati CSV e la compattazione di database. È inoltre possibile passare al log degli errori e al monitor attività per risolvere i problemi.
Prezzo: si parte da 590 dollari per una singola licenza server. Con il set di strumenti per host Web si parte da 990 dollari per una singola licenza server.


 SQL: Domande&amp;Risposte: Installazioni a 64 bit, allocazione della memoria cluster e altro ancora
SQL: Domande&Risposte Installazioni a 64 bit, allocazione della memoria cluster e altro ancora and A cura di Nancy Michell
Figura 1La documentazione in linea di SQL Server effettua una ricerca tramite Windows Live
Supponiamo che SQL Server abbia tutta la RAM su un server e che venga avviata una nuova istanza di SQL Server. Cosa succede alla memoria dell'istanza di SQL Server originale? È consigliabile partire dallo scenario peggiore in cui è operativo un solo nodo e tutte le istanze di SQL Server si appoggiano su quel nodo?
R È opinione diffusa che l'opzione migliore sia quella di impostare un valore massimo per la memoria del server leggermente inferiore alla memoria totale disponibile sul sistema. Tuttavia, non è certo che la scelta di un terzo del valore della memoria totale sia la scelta migliore per la situazione in oggetto.
Il pericolo potenziale rappresentato dal blocco contemporaneo di tre server su quattro all'interno del cluster e che allo stesso tempo le tre istanze di SQL Server si trovino a dipendere dal quarto nodo, rimane una possibilità remota.
Nella maggior parte dei casi, è consigliabile configurare ciascuna istanza in modo che utilizzi la maggior parte della memoria disponibile per ciascun nodo. Supponiamo che ciascun nodo disponga di 32 GB di RAM. È ragionevole che l'impostazione di memoria massima per il server sia intorno ai 28 GB per ciascuna istanza.
Nel caso di un errore all'interno del nodo, l'istanza ad esso associata eseguirà il failover nei confronti del nodo passivo e potrebbe quindi sfruttare potenzialmente i 28 GB di memoria. Le altre due istanze rimarrebbero inalterate e dipenderebbero dagli altri due nodi del cluster.
Nell'esempio viene citato un cluster di failover a quattro nodi con cinque istanze di SQL Server e una di Analysis Services. Se si utilizza SQL Server 2000 con la funzionalità AWE (Address Windowing Extensions), sarà necessario impostare dei limiti di memoria precisi per le istanze del motore relazionale poiché queste ultime non cedono la memoria acquisita. La situazione è ben diversa se si parla della flessibilità offerta da SQL Server 2005 e dalle relative istanze a 64 bit che possono disporre di un ampio spazio degli indirizzi con o senza funzionalità AWE (anche nel caso dell'utilizzo delle funzionalità AWE in questa situazione, il sistema risulta dinamico e può fornire memoria su richiesta). Quello che accade all'istanza originale di SQL Server e alla memoria che ha acquisito in una situazione di failover in cui viene avviata una nuova istanza, quindi, dipende dal tipo di sistema utilizzato (SQL Server 2000 o SQL Server 2005) e dallo stato delle funzionalità AWE.
La pianificazione dello scenario peggiore, quindi, è teoricamente giusta anche se in termini pratici, a meno che il sistema non sia stato ampiamente modificato, è improbabile che possa sussistere una situazione in cui tre nodi su quattro si blocchino all'interno di un cluster che esegue cinque istanze del motore relazionale di SQL Server e una di Analysis Services. Il nodo rimanente non avrà sufficienti risorse di CPU per provvedere alle istanze originali ad un livello di prestazioni soddisfacente. Poiché questo è quello che si verifica in genere, è consigliabile programmare una soluzione che mantenga prestazioni ottimali con la perdita di un unico nodo e che lasci spazio alla possibilità di piccoli interventi manuali con la perdita di uno o più nodi. Questo metodo dovrebbe consentire una combinazione ottimale del supporto dell'alta disponibilità (HA) favorendo l'utilizzo migliore delle risorse più costose.
Grazie a SQL Server 2005, infine, l'utente finale può espandere il cluster a otto nodi. In SQL Server 2000 un cluster poteva disporre di un numero massimo di quattro nodi.

Limiti di mirroring
D Leggendo alcune informazioni sulle opzioni di mirroring del database di SQL Server 2005, si scopre che questa funzionalità è limitata a un massimo di 10 database per istanza del server. Nel caso descritto di seguito sono necessarie due istanze separate di SQL Server con relativa capacità di archiviazione, failover automatico tra le due e ridondanza dei dati.
Partendo dall'utilizzo della funzionalità peer-to-peer (P2P) di replica delle transazioni di SQL Server 2005 e da Microsoft® Cluster Server (MSCS), l'IP di un cluster viene legato a uno dei due nodi, in modo tale che tutto il traffico di inserimento, aggiornamento, cancellazione e lettura venga indirizzato a un singolo nodo all'interno del cluster, mentre il nodo secondario viene considerato passivo anche se le transazioni vi vengono replicate. In caso di errore, MSCS eseguirebbe il failover dell'IP nei confronti dell'altro nodo e poiché è configurato con le funzionalità P2P e bidirezionali, non dovrebbe essere necessario alcun processo manuale per la pubblicazione delle transazioni verso l'altro nodo (una volta ripristinato). Verrebbe quindi utilizzata la configurazione MNS (Majority Node Set) all'interno di MSCS per ridurre la necessità di una risorsa disco condivisa per il raggiungimento del quorum.
L'opzione di mirroring sussiste. Il numero di database viene successivamente ridotto da 1.000 a 100 per il cluster di SQL Server. In questo caso è comunque necessario far gravare sui sistemi questo tipo di carico di risorse?
R Per informazioni e aiuto sulle funzionalità di mirroring di SQL Server, visitare il centro di assistenza tecnica BOL o SQL Server all'indirizzo microsoft.com/technet/prodtechnol/sql e msdn2.microsoft.com/sql.
La domanda ha generato numerose discussioni. Di seguito vengono riportate quelle che risultano più appropriate:
La prima risposta afferma che non esiste un limite al numero di database per i quali può essere eseguita la funzione di mirroring all'interno di una data istanza. Partendo dal presupposto che ci si riferisca ad un articolo che consiglia l'esecuzione della funzione di mirroring per un massimo di 10 database per istanza, è necessario ricordare che questa è una semplice approssimazione e non sussistono particolari limiti se non quelli dettati dalle risorse disponibili per il sistema in oggetto.
Il mirroring può rappresentare un'opzione, anche se 1.000 database necessariamente graveranno su di esso a meno che non si disponga di un server molto potente. Se non si vuole utilizzare la funzionalità di archiviazione condivisa e sfruttare le tecnologie integrate di SQL Server, è possibile optare per il mirroring, la distribuzione dei log o la replica. I pro e i contro variano a seconda della scelta.
Qualora si disponga di un grosso numero di database, non si utilizzi l'archiviazione condivisa e si abbia la necessità di sfruttare una soluzione per il ripristino di emergenza fornita da Microsoft, la seconda risposta consiglia l'opzione di distribuzione dei log tramite un insieme di programmi di guida personalizzati di piccole dimensioni per facilitare l'overhead di amministrazione. Un programma può eseguire il backup e il ripristino di ciascun database evitando l'esecuzione di agenti multipli per la distribuzione dei log. Quest'ultima operazione può comportare la perdita di dati. Non esiste alcuna soluzione integrata che possa prescindere dalle funzionalità di archiviazione condivisa o una soluzione DBMS che eviti la possibile perdita di dati.
Rimane sicuramente il problema del rilevamento e dell'esecuzione del failover da parte di MSCS. Le configurazioni MNS in un cluster di solito non cancellano totalmente la necessità dell'archiviazione condivisa, ma solo quella di un LUN condiviso e dedicato per il raggiungimento del quorum. La sola possibilità di evitare l'archiviazione condivisa consisterebbe nella configurazione del cluster in modo tale che gestisca solamente gli IP e i nomi di rete. SQL Server non può essere suddiviso in cluster senza archiviazione condivisa, pertanto questo tipo di operazione non può essere effettuata sul servizio SQL. Il cluster, di conseguenza, risulta impossibilitato a rivelare e monitorare i servizi SQL Server in una configurazione tipica.
La suddivisione in cluster del servizio SQL Server può essere effettuata impostandolo come servizio generico da monitorare, ma il problema si verifica poi in fase di failover: poichè il servizio viene suddiviso in cluster, infatti, MSCS tenterebbe di portarlo in linea sul nodo passivo in fase di failover, dove un altro servizio SQL sarebbe già in esecuzione. È comunque possibile utilizzarlo per eseguire la suddivisione in cluster di IP e nomi di rete e quindi eseguire il failover manuale ove necessario. La stessa operazione può essere effettuata, come in altri casi, tramite NLB (Network Load Balancing). Per ulteriori informazioni consultare il documento all'indirizzo microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx.
Dato il numero di database da gestire, una soluzione di distribuzione dei log potrebbe rivelarsi la più appropriata al caso. Sarà comunque necessario eseguire l'automazione del processo tramite un pacchetto DTS/SSIS (Data Transformation Services/SQL Server Integration Services), per evitare tempi di backup manuale, di spostamento e applicazione dei log troppo lunghi in caso di errore.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren e in particolar modo Buck Woody.


 Utilit&#224; sotto i riflettori: PowerToy per l'elevazione dei privilegi degli script in Windows Vista
Utilità sotto i riflettori PowerToy per l'elevazione dei privilegi degli script in Windows Vista and Michael Murgolo
Scarica il codice per questo articolo: Utility2007_06.exe (159KB)
Controllo account utente rappresenta un importante miglioramento nella protezione, ma la possibilità di elevare le autorizzazioni è essenziale per eseguire determinate attività e funzioni amministrative. Ecco alcuni PowerToy che rendono le operazioni di elevazione più flessibili e potenti.
Fra le numerose funzionalità di Windows Vista introdotte per risolvere i problemi di protezione, Controllo account utente (UAC) è una delle più significative. Con Controllo account utente, anche gli utenti che sono amministratori eseguono la maggior parte delle applicazioni con privilegi standard, ma senza rinunciare a una "potenziale elevazione" per attività amministrative e
funzioni applicative specifiche. Dopo aver utilizzato Windows Vista™ per molti mesi, l'elevazione di un'attività o applicazione in base alle necessità è diventata un'abitudine. Tuttavia, non sono mancati gli inconvenienti, con conseguenti delusioni, nell'elevazione di alcuni tipi di attività in Windows Vista.
Nello spirito dei vecchi PowerToy di Windows®, ho pensato di creare alcuni PowerToy di elevazione degli script per superare queste limitazioni. È possibile trovare tutti i PowerToy illustrati nell'articolo all'interno del download all'indirizzo technetmagazine .com/code07.aspx. Alcune informazioni sul funzionamento di UAC sono riportate nell'articolo del novembre 2006 "Con UAC (User Account Control) si realizza il sogno degli account senza privilegi di amministratore" di Alex Heaton (vedere il riquadro "Ulteriori riferimenti").

PowerToy Elevate Command
La prima limitazione era rappresentata dall'assenza di un metodo per elevare un'applicazione dalla riga di comando o dalla finestra di dialogo Esegui. Dopo aver chiesto ad altri colleghi in Microsoft, ho trovato uno script di esempio di John Stephens (un Software Design Engineer di Microsoft), che mi ha fornito le informazioni di cui avevo bisogno. Ho scoperto che se si passa il verb "runas" all'API ShellExecute o al suo equivalente COM, il metodo ShellExecute di Shell.Application, l'applicazione avviata richiederà di eseguire l'elevazione (vedere il riquadro per i dettagli). Questo mi ha consentito di creare il primo PowerToy di elevazione, il PowerToy Elevate Command.
Questo strumento (costituito dai file ElevateCommand.inf, elevate.cmd e elevate.vbs) aggiunge un comando di elevazione al sistema. Con il comando è possibile avviare le applicazioni che richiedono di eseguire l'elevazione dalla riga di comando, uno script o la finestra di dialogo Esegui. Il comando seguente, ad esempio, apre Win.ini con Blocco note (dopo aver richiesto l'elevazione):
elevate notepad c:\Windows\Win.ini
Quando si utilizza il comando di elevazione con Windows Script Host (WSH), Windows PowerShell™ o altri script, è necessario specificare l'eseguibile dell'host di script (come wscript, cscript o powershell) come applicazione. Per eseguire un vbs, ad esempio, utilizzare il codice seguente:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Figura 2Prompt con privilegi elevati

Installazione e implementazione
Per installare questi PowerToy, fare clic con il pulsante destro del mouse su un file INF, scegliere Install e approvare l'elevazione. Per disinstallare, utilizzare la selezione Programmi e funzionalità del Pannello di controllo.
Se interessa approfondire la conoscenza dei file INF e ci si chiede come mai tre PowerToy installano elevate.cmd ed elevate.vbs nelle diverse posizioni, ecco la spiegazione. La maggior parte dei PowerToy vengono implementati aggiungendo una sottochiave runas alla chiave HKEY_CLASSES_ROOT\objecttype\Shell per il tipo di oggetto nel Registro di sistema.
Tuttavia, ho ritenuto opportuno che alcuni PowerToy rendessero disponibili per alcuni tipi di oggetto due voci di menu di scelta rapida di elevazione ("CMD Prompt Here as Administrator" e "PowerShell Prompt Here as Administrator" per i tipi di oggetto Drive e Directory; "Run as Administrator" e "Run as Administrator with Command Prompt" per tutti i tipi di oggetto WSH). Poiché può esistere una sola chiave runas per ciascun tipo di oggetto, ho dovuto implementare la seconda azione chiamando il comando elevate. D'altro canto desideravo che ciascun INF potesse essere installato e disinstallato in modo indipendente, quindi ho dovuto inserire le copie associate elevate.cmd ed elevate.vb in posizioni diverse. È possibile incrementare i contatori di utilizzo dei file da un file INF non elaborato. MSI rappresenta di certo una soluzione migliore, ma desideravo che i programmi di installazione potessero essere creati e modificati con un editor di testo. Un effetto collaterale di queste scelte è la visualizzazione di un contrassegno solo per le voci del menu di scelta rapida implementate utilizzando la chiave runas.

Riepilogo
Spero che questi strumenti risultino utili e rendano più proficuo l'impiego di UAC. Forse ispireranno altri utenti a creare PowerToy personalizzati (chi utilizza altri linguaggi di script come Perl o Python su Windows Vista, troverà facile creare un PowerToy di elevazione degli script anche nel proprio linguaggio preferito). Come tutti i PowerToy, questi strumenti non sono supportati e vengono utilizzati a proprio rischio. In ogni caso, buona elevazione a tutti!
Ulteriori riferimenti
  • Con UAC (User Account Control) si realizza il sogno degli account senza privilegi di amministratore
  • Panoramica su Controllo account utente
  • Elevazione con ShellExecute
  • Metodo ShellExecute
  • Verb e associazioni di file
  • Un vecchio PowerToy torna alla ribalta


 The Cable Guy: Il protocollo SSTP (Secure Socket Tunneling Protocol)
The Cable Guy Il protocollo SSTP (Secure Socket Tunneling Protocol) and Joseph Davies
Questo articolo si riferisce a una versione preliminare di Windows Server, il cui nome in codice è "Longhorn". Le informazioni riportate sono soggette a modifiche.
In Windows XP e Windows Server 2003 i protocolli VPN non funzionano per alcune configurazioni. In questo articolo vengono approfonditi alcuni problemi e sarà possibile notare come nella versione "Longhorn" di Windows Server e in Windows Vista con Service Pack 1 si ricorra al protocollo SSTP per risolverli.
Il supporto per la rete privata virtuale (VPN, Virtual Private Network) in Windows XP e in Windows Server 2003 consente di connettersi alla rete intranet privata via Internet, come se il computer fosse collegato a una porta Ethernet locale. In Windows XP e Windows Server 2003, tuttavia, i protocolli VPN non funzionano per alcune configurazioni del firewall
e per alcune configurazioni indirette, ad esempio quando il computer utilizza un server proxy NAT (Network Address Translator) o Web, in cui il traffico delle connessioni VPN viene bloccato. Per risolvere questi problemi, nella successiva versione di Windows Server®, il cui nome in codice è "Longhorn", e in Windows Vista™ con Service Pack 1 (entrambi in fase di test beta) viene incluso il supporto per il nuovo protocollo SSTP (Secure Socket Tunneling Protocol).

Problemi di accesso di VPN
In Windows® XP e Windows Server 2003 i protocolli VPN che attivano le connessioni di accesso remoto a una rete intranet via Internet sono PPTP (Point-to-point Tunneling Protocol) e L2TP/IPsec (Layer Two Tunneling Protocol with Internet Protocol security). Questi protocolli provvedono a incapsulare i pacchetti trasmessi tra un client di accesso remoto e la rete intranet alla quale il client è connesso.
Il traffico VPN basato su PPTP consiste in una connessione TCP alla porta TCP 1723 del server VPN per la manutenzione del tunnel e in pacchetti incapsulati con GRE (Generic Routing Encapsulation) per i dati VPN. Il traffico PPTP, tuttavia, può presentare problemi con firewall, NAT e proxy Web. Per evitare difficoltà, è necessario che i firewall vengano configurati per consentire tanto la connessione TCP quanto i dati incapsulati con GRE. Sebbene GRE sia un metodo standard di incapsulamento di pacchetti IP, molti provider di servizi Internet (gli ISP) ignorano questi pacchetti, con conseguente perdita di dati. Le connessioni disponibili negli alberghi e nei locali pubblici, inoltre, sono solitamente configurate per il traffico Web e della posta elettronica normale e potrebbero quindi non consentire il traffico PPTP. Se inoltre il computer utilizza un NAT, è necessario che questo sia in grado di convertire il traffico GRE. In caso contrario sarà possibile stabilire la connessione TCP ma non trasmettere o ricevere dati incapsulati con GRE. Il traffico PPTP, infine, non può passare da un proxy Web.
Nell'altro protocollo VPN disponibile in Windows XP e Windows Server 2003, L2TP/IPsec, si utilizza il protocollo IKE (Internet Key Exchange) per negoziare la protezione ESP (Encapsulating Security Payload) IPsec del traffico VPN e anche in questo caso possono verificarsi problemi con firewall, NAT e proxy Web.
In questa situazione è necessario che i firewall siano configurati per consentire sia il traffico IKE che i dati incapsulati con ESP. Se il computer client VPN utilizza un NAT, tanto il client VPN quanto il server VPN devono supportare NAT-T (NAT-Traversal) IPsec. Si noti, tuttavia, che il server VPN non può utilizzare un NAT e che di conseguenza il traffico L2TP/IPsec non può passare da un proxy Web.

La nuova soluzione VPN
Come risulta evidente, il funzionamento del protocollo VPN in Windows XP e Windows Server 2003 presenta varie difficoltà. La novità positiva riguarda il protocollo SSTP che in Windows Vista con Service Pack 1 e nella versione "Longhorn" di Windows Server è in grado di risolvere questi problemi di connettività VPN utilizzando HTTP su SSL (Secure Sockets Layer). SSL è anche noto come TLS (Transport Layer Security). HTTP su SSL sulla porta TCP 443 è il protocollo utilizzato per qualche tempo sul Web per l'acquisizione dei numeri di carta di credito e altri dati privati. Ogni volta che ci si connette a un indirizzo Web che inizia con https:, si utilizza HTTP su SSL.
L'utilizzo di HTTP su SSL consente di risolvere molti problemi di connettività del protocollo VPN: firewall, NAT e proxy Web solitamente non ostacolano questo tipo di traffico poiché è molto diffuso.
Nel protocollo SSTP viene utilizzata una sessione HTTP su SSL tra client e server VPN per scambiare pacchetti IPv4 o IPv6 incapsulati. Si osservi che esiste una differenza tra una connessione VPN di accesso remoto basata su HTTP su SSL e la connessione eseguita da un'applicazione in cui si utilizza HTTP su SSL. Outlook® Web Access (OWA), ad esempio, consente di accedere alla posta elettronica di Microsoft Exchange presso la propria azienda via Internet. In OWA viene utilizzata una sessione HTTP su SSL crittografata che tuttavia non equivale a una connessione di accesso remoto. Nonostante in OWA sia possibile leggere la propria posta elettronica, non è possibile passare all'URL di una rete intranet incorporato in un messaggio di posta elettronica di Exchange.
SSTP non supporta configurazioni proxy Web autenticate, in cui il proxy richiede un certo tipo di autenticazione durante la richiesta di connessione HTTP.
L'implementazione di HTTP su SSL in Windows può ridurre notevolmente i costi di manutenzione della soluzione di accesso remoto adottata. HTTP su SSL, ad esempio, riduce il numero di richieste di assistenza all'help desk ed elimina i problemi legati ai server VPN per i quali vengono utilizzati NAT. Poiché SSTP funziona praticamente ovunque, inoltre, si nota una maggiore soddisfazione e una maggiore produttività degli utenti.
Dal momento che SSTP è incorporato in Windows, non è necessario preoccuparsi di software client VPN di terze parti da installare e gestire in computer client né di altro software da installare nel server VPN. SSTP, inoltre, è in grado di bilanciare meglio il carico delle connessioni VPN mediante i servizi di bilanciamento del carico SSL disponibili.
Nuove funzioni SSTP
  • Nel protocollo SSTP è integrato il supporto per Protezione accesso alla rete, che consente di proteggere meglio le risorse di rete implementando la conformità ai requisiti di integrità del sistema. Per ulteriori informazioni su Protezione accesso alla rete, vedere microsoft.com/nap.
  • SSTP, inoltre, supporta il traffico IPv6 nativo inviato nel tunnel SSTP e le connessioni SSTP basate su IPv6 attraverso Internet IPv6.
  • SSTP, infine, stabilisce una singola sessione HTTP su SSL dal client SSTP al server SSTP. Altre soluzioni VPN di terze parti basate su SSL utilizzano due sessioni HTTP su SSL. Il ricorso a una sola sessione HTTP su SSL consente di utilizzare meno la rete e di bilanciare meglio il carico.
  • SSTP è infine completamente integrato nei componenti client VPN di Windows Vista con Service Pack 1 e Windows Server &quot;Longhorn&quot; e Routing e Accesso remoto in SSTP di Windows Server &quot;Longhorn.&quot; è un altro protocollo VPN in grado di ricorrere agli stessi protocolli di autenticazione e agli stessi metodi di configurazione, quali la cartella Connessioni di rete e Connection Manager, utilizzati per le connessioni PPTP o basate su L2TP/IPsec.
Diversamente dai protocolli PPTP e L2TP/IPsec di Windows XP e Windows Server 2003, SSTP non supporta le connessioni VPN da sito a sito.

SSTP in Windows
Un computer che esegue la versione "Longhorn" di Windows Server e Routing e Accesso remoto è un server VPN basato su SSTP. Non è necessario installare IIS dal momento che Routing e Accesso remoto attende connessioni in ingresso nello specifico URI (Uniform Resource Identifier) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/. Routing e Accesso remoto e IIS, tuttavia, possono coesistere nello stesso server.
Un computer che esegue Windows Vista (con i miglioramenti previsti nell'imminente Service Pack 1, il cui rilascio è al momento annunciato per la fine dell'anno) o la versione "Longhorn" di Windows Server è un client VPN basato su SSTP, in grado di avviare connessioni SSTP verso un server VPN basato su SSTP. È necessario che nel server SSTP sia installato un certificato del computer con la proprietà Autenticazione server o EKU (Enhanced Key Usage) universale. Questo certificato del computer viene utilizzato nel client SSTP per autenticare il server SSTP quando viene stabilita la sessione SSL. Il certificato del computer del server SSTP viene convalidato. Per rendere attendibile il certificato del computer, è necessario che nel client SSTP sia installata l'autorità di certificazione principale (CA) della CA di emissione del certificato del computer del server SSTP.
Nella Figura 1 vengono confrontati gli attributi dei diversi protocolli VPN nella versione "Longhorn" di Windows Server e in Windows Vista con Service Pack 1. Le funzioni di SSTP sono descritte nella sezione "Nuove funzioni SSTP".
Figure 1 Confronto tra i diversi protocolli VPN (Close Figure 1)

Attributi | PPTP | L2TP/IPsec | SSTP
Incapsulamento | GRE | L2TP su UDP | SSTP su TCP
Crittografia | MPPE (Microsoft Point-to-Point Data Encryption) con RC4 | ESP IPsec con lo standard Triple DES (Data Encryption Standard) o lo standard AES (Advanced Encryption Standard) | SSL con RC4 o AES
Protocollo di manutenzione del tunnel | PPTP | L2TP | SSTP
Esecuzione dell'autenticazione da parte dell'utente | Prima dell'inizio della crittografia | Dopo che la sessione IPsec è stata stabilita | Dopo che la sessione SSL è stata stabilita
Certificati necessari per stabilire il tunnel VPN | Nessuno | Certificati del computer sia nel client sia nel server VPN | Certificato del computer nel server VPN e certificato dell'autorità di certificazione principale nel client VPN

Funzionamento di SSTP
Quando in un computer che esegue la versione "Longhorn" di Windows Server o Windows Vista con Service Pack 1 viene avviata una connessione VPN basata su SSTP, si verifica quanto segue:
  1. Nel client SSTP viene stabilita una connessione TCP con il server SSTP tra una porta TCP allocata dinamicamente sul client e la porta TCP 443 del server.
  2. Il client SSTP invia un messaggio Hello del client SSL a indicare che il client intende creare una sessione SSL con il server SSTP.
  3. Il server SSTP invia il proprio certificato del computer al client SSTP.
  4. Il client SSTP convalida il certificato del computer, determina il metodo di crittografia per la sessione SSL, genera una chiave per la sessione SSL e la crittografa con la chiave pubblica del certificato del server SSTP.
  5. Il client SSTP invia la forma crittografata della chiave di sessione SSL al server SSTP.
  6. Il server SSTP esegue la decrittografia della chiave di sessione SSL con la chiave privata del proprio certificato del computer. Tutte le comunicazioni future tra il client SSTP e il server SSTP vengono crittografate con il metodo di crittografia e la chiave di sessione SSL negoziati.
  7. Il client SSTP invia un messaggio di richiesta HTTP su SSL al server SSTP.
  8. Il client SSTP negozia un tunnel SSTP con il server SSTP.
  9. Il client SSTP negozia una connessione PPP con il server SSTP. Questa negoziazione comprende l'autenticazione delle credenziali dell'utente con un metodo di autenticazione PPP e la configurazione delle impostazioni per il traffico IPv4 o IPv6.
  10. Il client SSTP inizia a trasmettere traffico IPv4 o IPv6 attraverso il collegamento PPP.
Nella Figura 2 viene illustrata la struttura dei pacchetti IPv4 o IPv6 trasmessi su una connessione VPN basata su SSTP.
Figura 2Struttura dei pacchetti SSTP
Un pacchetto IPv4 o IPv6 viene innanzitutto incapsulato con un'intestazione PPP e un'intestazione SSTP. La combinazione del pacchetto IPv4 o IPv6, dell'intestazione PPP e dell'intestazione SSTP viene crittografata nella sessione SSL. Per completare il pacchetto, vengono aggiunti un'intestazione TCP e un'intestazione IPv4 (per connessioni SSTP via Internet IPv4) o IPv6 (per connessioni SSTP via Internet IPv6).
Per ulteriori informazioni su SSTP, vedere il blog relativo a Routing e Accesso remoto all'indirizzo blogs.technet.com/rrasblog.


 Windows PowerShell: Utilizzo di Active Directory
Windows PowerShell Utilizzo di Active Directory and Don Jones Windows PowerShell non dispone del cmdlet Get-ADSIObject, ma ciò non gli impedisce di offrire un solido supporto ADSI. In questo articolo viene fornita una presentazione degli adapter del tipo e viene spiegato come utilizzare Windows PowerShell per gli oggetti di directory.
Chi ha provato a utilizzare Windows PowerShell, molto probabilmente si è imbattuto nel cmdlet Get-WMIObject, noto anche con il semplice alias, gwmi. Come descritto nell'articolo del mese scorso, questo cmdlet evidenzia quale grande miglioramento rispetto ai precedenti linguaggi di script e alle shell della riga di comando sia PowerShell
(vedere technetmagazine.com/issues/2007/05/PowerShell). Gwmi consente di accedere rapidamente e con facilità a WMI (Strumentazione gestione Windows®) per svolgere un numero incredibile di operazioni senza dover scrivere script complessi.
Get-WMIObject costituisce un ottimo esempio delle potenzialità di Windows PowerShell™ tanto che, quando ne parlo durante un corso, puntualmente i partecipanti ne estrapolano le funzionalità ad altre aree dell'amministrazione di Windows. Una delle prime domande che mi vengono poste è: "Esiste un cmdlet Get-ADSIObject?"

Supporto ADSI in Windows PowerShell
ADSI è l'acronimo di Active Directory® Services Interface. Malgrado il nome, ADSI non è specifico di Active Directory. Più correttamente, il nome dovrebbe essere letto come segue: "Active (pausa) Directory Services Interface", ovvero interfaccia per i servizi di directory, in quanto ADSI è in grado di connettersi a molti servizi di directory, comprese directory di tipo Windows NT® e non solo domini Windows NT, ma, si badi bene, anche a Gestione account di protezione (SAM) locale in computer membri o autonomi. Con questa flessibilità, un cmdlet Get-ADSIObject sarebbe estremamente utile. Purtroppo il team di Windows PowerShell non è riuscito a includerlo nella prima versione.
Ciò non equivale a dire però che Windows PowerShell manca del supporto ADSI, anzi... Il supporto ADSI in Windows PowerShell infatti è talmente ben fatto da non far rimpiangere la mancanza del cmdlet Get-ADSIObject.
Tutto parte dall'adapter del tipo [ADSI]. E qui è necessario ricorrere a una piccola spiegazione sugli adapter del tipo. Si tenga presente che Windows PowerShell è basato su Microsoft® .NET Framework (2.0 o versioni successive, per la precisione), di conseguenza, al suo interno, quasi tutto, dagli oggetti WMI a file e cartelle, è rappresentato come oggetto .NET Framework. Il team di Windows PowerShell non era tuttavia soddisfatto di esporre semplicemente oggetti .NET Framework non elaborati agli amministratori di Windows. Molti oggetti di .NET Framework, ad esempio, funzionano in modo incoerente e la coerenza era uno dei principali obiettivi progettuali di Windows PowerShell. Un'altra ragione è che alcuni oggetti di .NET Framework sono eccessivamente complessi per l'amministrazione di Windows e, anche in questo caso, in fase di progetto la semplicità è stata tenuta in grande considerazione, di conseguenza sono nati gli adapter del tipo.
Come lascia presagire il nome, gli adapter "adattano" il tipo di un oggetto .NET Framework a un formato più coerente e per alcuni aspetti più semplice. Supponiamo ad esempio di creare una nuova variabile di stringa simile alla seguente:
[string]$var = “Hello”
È stata utilizzata un'istanza del tipo System.String, gestita dall'adapter .NET. L'adapter del tipo [ADSI] è connesso alle classi DirectoryServices di .NET Framework, che includono il tipo DirectoryEntry.

Recupero di oggetti dalla directory
La connessione agli oggetti directory è piuttosto semplice. Ad esempio, per la connessione a un utente di nome Don, che fa parte dell'unità organizzativa (OU) IT, del dominio Contoso.com, si utilizzerebbe codice simile al seguente:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Per chi ha già utilizzato ADSI in VBScript o in un altro linguaggio, questo codice dovrebbe avere un aspetto familiare. Si tratta di una stringa di query LDAP (Lightweight Directory Access Protocol), ovvero il mezzo nativo per accedere ad Active Directory. Non è necessario specificare un nome di controller di dominio o altri dettagli, le informazioni contenute nel nome di dominio completo (Fully Qualified Domain Name, FQDN) sono sufficienti per identificare un controller di dominio (DC) e recuperare l'oggetto, ovviamente presupponendo che l'utente disponga delle autorizzazioni necessarie per svolgere questa operazione.
Per l'utilizzo degli account di protezione locali viene adottato un processo pressoché identico, a eccezione del fatto che viene utilizzato il provider WinNT anziché il provider LDAP:
$user = [ADSI]”WinNT://don-pc/don”
Si noti che sia il moniker LDAP sia il moniker WinNT distinguono fra maiuscole e minuscole. Mentre in Windows PowerShell la distinzione fra maiuscole e minuscole non sussiste, queste risorse ADSI la prevedono, per cui è importante fare attenzione quando si digita.
Nella Figura 1 è illustrato ciò che accade passando la variabile $user a Get-Member: si ottiene un elenco delle proprietà dell'oggetto. Purtroppo però l'elenco non è completo di tutte le proprietà dell'utente e non contiene i metodi dell'oggetto utente. A questo proposito, la classe .NET Framework System.DirectoryServices.DirectoryEntry funziona in modo alquanto strano e in Windows PowerShell ne viene visualizzato soltanto il risultato.
Figura 1Recupero di un elenco di proprietà dell'oggetto
Per recuperare oggetti è necessario in primo luogo essere in grado di creare una stringa di query. Utilizzare il provider WinNT è abbastanza facile, basta specificare un computer o un nome di dominio, seguito da una barra e quindi dal nome di un oggetto. Questa tecnica funziona bene con i domini Active Directory che, dopotutto, sono compatibili con i domini delle versioni precedenti di Windows NT. Di fatto, per recuperare gli oggetti da Active Directory a volte può essere più semplice utilizzare il provider WinNT poiché offre una visualizzazione semplice del dominio, vale a dire che non è necessario sapere in quale OU si trova un oggetto, perché il provider WinNT prescinde dalle unità organizzative.
Per recuperare oggetti LDAP è necessaria una precisione maggiore. Si inizia con informazioni il più possibile specifiche, come il nome canonico di un oggetto o il nome di un'unità organizzativa, quindi si fornisce il percorso completo dell'oggetto, a iniziare dal contenitore padre e procedendo verso il dominio stesso. Ad esempio, l'utente Don, che fa parte dell'unità organizzativa Sales (vendite), contenuta nell'unità organizzativa West del dominio Contoso.com, si presenta come segue:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Per questo formato è necessaria un po' di pratica, oltre a sapere dove si trova l'oggetto. Nella Figura 2 sono riepilogati i vari componenti del nome di dominio completo.
Figure 2 Componenti FQDN (Close Figure 2)

Componente | Scopo | Esempio
cn | Nome canonico di un oggetto. Utilizzato anche per contenitori che non consistono in un'unità organizzativa, come utenti e computer. | cn=Don
ou | Unità organizzativa. | ou=Sales
dc | Componente nome di dominio. Ogni componente del nome di un dominio DNS ottiene il proprio componente "dc=". | dc=domain, dc=com

Un piccolo aiuto
Per creare ed eliminare oggetti è necessario in primo luogo connettersi al contenitore dell'oggetto, ad esempio l'unità organizzativa, e quindi inviare al contenitore la richiesta di creare o eliminare l'oggetto. Dimentico sempre la sintassi corretta, ma fortunatamente gli Scripting Guy di Microsoft mi danno una mano con ADSI Scriptomatic.
Nonostante sia stato in origine creato per VBScript, ADSI Scriptomatic è una guida utile anche per Windows PowerShell dato che la sintassi ADSI reale è la stessa. Ad esempio, dopo avere scaricato lo strumento, scelgo l'opzione per creare un nuovo utente. Ignoro tutto il codice di script generato dallo strumento fino al codice di fine connessione al contenitore, simile a quanto segue:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
È facile convertire la sintassi per Windows PowerShell. Primo, mi connetto al contenitore in cui creare l'utente. Per essere coerente con il codice di Scriptomatic, per rappresentare l'unità organizzativa utilizzo la variabile $objContainer. Creo inoltre la variabile $strName che conterrà il nome del nuovo utente:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
Copio quindi il mio codice sovrascrivendo quello di Scriptomatic, elimino tutte le tracce di istruzioni Set di VBScript e aggiungo il simbolo $ ai nomi delle variabili:
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Questo è tutto ciò che serve: è stato creato un nuovo utente nell'unità organizzativa Test del dominio Contoso.com.

Modifica di oggetti directory
Una volta eseguita la connessione a un oggetto quale un utente o un gruppo, è possibile modificarlo. Utilizzando il provider WinNT è possibile modificare direttamente molte proprietà come quelle illustrate nella Figura 1. Per visualizzare e quindi modificare, ad esempio, la proprietà Description di un utente, è necessario procedere come segue:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
In questo caso, il fattore importante da ricordare è che, quando si modifica una proprietà, le modifiche vengono apportate nella cache delle proprietà locale, che è un'area di archiviazione temporanea gestita da ADSI nel computer. Chiamando il metodo SetInfo, il contenuto della cache viene riscritto nel dominio o nel computer dal quale è stato recuperato l'oggetto, essenzialmente salvando nuovamente nella directory le modifiche apportate.
Gli oggetti Active Directory non dispongono di proprietà dirette per la maggior parte degli attributi degli oggetti. In sostituzione, si utilizzano i metodi Get e Put:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Gli oggetti WinNT tendono a essere alquanto semplicistici, poiché nei servizi di directory di Windows NT non vengono memorizzate molte informazioni su oggetti quali utenti e gruppi. D'altra parte in Active Directory viene memorizzata una quantità enorme di informazioni e individuare i nomi degli attributi corretti può essere arduo. Per modificare, ad esempio, il cognome di un utente è necessario modificare la proprietà Sn. Perché Sn? Perché si riferisce al cognome ("surname" in inglese).
Fortunatamente Microsoft fornisce un ottimo riferimento incrociato, disponibile in linea all'indirizzo msdn2.microsoft.com/ms677286.aspx. In questo riferimento sono illustrati i nomi degli attributi di ogni area principale della console Utenti e computer di Active Directory, così, se è noto cosa modificare nella console, è possibile presagire il nome dell'attributo sottostante. Si noti che nel libro ADSI Scripting: TFM di Cade Fassett (SAPIEN Press, 2007) è disponibile un riferimento incrociato console-attributo più completo.

Cosa non è possibile fare
Purtroppo il supporto ADSI in Windows PowerShell non è solido come il supporto per altre tecnologie quali WMI. È, ad esempio, abbastanza difficile enumerare i membri dei gruppi del computer locale. Quando si ha a che fare con Active Directory si presentano una serie di difficoltà. In base alla mia esperienza, attività di base quali il recupero, la creazione e l'eliminazione di oggetti funzionano bene. Anche la modifica delle proprietà degli oggetti funziona abbastanza bene, sebbene alcune proprietà siano inaccessibili. Ho incontrato le maggiori difficoltà utilizzando oggetti e gruppi locali tramite il provider WinNT.
Ciò non significa che non sia possibile fare nulla: semplicemente alcune operazioni sono un po' più difficili o, per così dire, meno intuitive. Si prenda in considerazione l'esempio seguente:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
L'utente denominato User1 viene aggiunto al gruppo Techs. L'inizio è abbastanza semplice. Il gruppo viene recuperato utilizzando il nome di dominio completo, quindi viene utilizzata la raccolta Member (in particolare il metodo Add della raccolta) per aggiungere il nome di dominio completo dell'utente desiderato. L'ultimo passaggio, tuttavia, non è affatto intuitivo. Per salvare le modifiche viene chiamato il metodo CommitChanges della classe PSBase.
PSBase è una classe speciale che rappresenta direttamente l'oggetto .NET Framework di base. In questo caso CommitChanges non viene esposto direttamente in Windows PowerShell (effettivamente l'adapter ADSI non espone alcun metodo), per cui è necessario risalire alla classe sottostante. Non è impossibile, ma certamente non è intuitivo e dimostra che le funzionalità dei servizi di directory non sono ancora state completamente adattate a Windows PowerShell.
Per questo vi sono varie ragioni: primo, il team di Windows PowerShell ha aggiunto il supporto ADSI attuale alla shell relativamente tardi nel ciclo di sviluppo. Come dice spesso Jeffrey Snover, responsabile dell'architettura della shell: "rendere disponibile un prodotto per il rilascio significa scegliere". Il team ha dovuto fare i conti con un periodo di tempo predeterminato per sviluppare e rendere disponibile la shell per il rilascio, quindi ha dovuto prendere decisioni relativamente a cosa tenere in serbo per la prossima versione, altrimenti avrebbero continuato a lavorare per anni per aggiungere funzionalità senza mai rilasciare un prodotto supportato.
Un'altra ragione è tuttavia costituita dagli elementi .NET Framework sottostanti. La classe DirectoryServices di .NET Framework è piuttosto complessa e per adattare questa complessità a Windows PowerShell era necessario molto tempo e un'attenta pianificazione. Secondo me le classi .NET Framework sono un po' sbilanciate verso Active Directory e non forniscono un supporto eccellente per il provider WinNT. Windows PowerShell erediterebbe quindi tali limitazioni da .NET Framework.
Mi sarei aspettato che in Windows PowerShell il supporto dei servizi di directory fosse stato enormemente ampliato, supporto che potrebbe addirittura non passare per il livello di ADSI, ma essere introdotto sotto forma di miglioramenti di base in .NET Framework. Nel frattempo, il supporto ADSI disponibile in Windows PowerShell consente di eseguire la maggior parte delle attività amministrative, quali la creazione di utenti, la modifica di proprietà utente comuni e così via.
Si ricordi inoltre che molte attività dei servizi di directory possono essere eseguite attraverso WMI. Vedere gli script disponibili all'indirizzo microsoft.com/technet/scriptcenter/scripts con alcuni ottimi esempi dell'utilizzo di WMI per fornire maggiori informazioni su un gruppo locale di quante non ne vengano fornite da ADSI.


 Hey, Scripting Guy!: Script per la sottolienatura rossa a zigzag
Hey, Scripting Guy! Script per la sottolienatura rossa a zigzag and Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2007_06.exe (151KB)
Esiste un modo più facile per aggiungere termini al dizionario di Microsoft Word che non farlo manualmente, una parola alla volta? E a chi non piacerebbe? Questo mese, gli Scripting Guy spiegano come creare dizionari personalizzati in Microsoft Word e come configurare Word a livello di programmazione in modo che utilizzi tali dizionari.
Figura 1Documento di Word con errori di ortografia
Notato niente di particolare? Esatto: Word ha sottolineato con una linea a zigzag i termini di scripting quali Msgbox. Perché? Perché Word non riconosce questi termini. Non riconosce questi termini? Forza, Word! Dopo tutto, negli ultimi anni gli Scripting Guy hanno digitato il termine Msgbox milioni di volte. E milioni di volte hanno eseguito il controllo ortografico e indicato che Msgbox è stato digitato correttamente. E ancora segnali Msgbox, StrReverse e LTrim come termini errati? Cosa c'è che non va?
Prima che qualcuno si scagli in difesa di Microsoft Word, sì, siamo consci della possibilità di aggiungere manualmente questi termini al dizionario ma siamo Scripting Guy e, per dirla tutta, non ne vogliamo proprio sapere delle procedure manuali. Oltretutto aggiungere manualmente funzioni VBSCRIPT, nomi di classi WMI (Windows® Management Instrumentation, Strumentazione gestione Windows®) e attributi di oggetti ADSI (Active Directory® Security Interfaces, interfacce di protezione di Active Directory®) può essere alquanto noioso, per non dire di peggio. E se desiderassimo farlo per tutti i computer? Inoltre, se desiderassimo condividere queste grafie corrette con tutti i nostri devoti lettori? Scenario What If, per rendere l'idea...
Il punto è questo: di certo deve esistere un modo più semplice per aggiungere i termini di script (o qualunque termine, tanto non ha importanza) al dizionario senza doverlo fare a mano, una parola alla volta.
E qui si scopre che non è vero. Ma dovete aspettare il mese prossimo!
Fermatevi, stiamo solo scherzando. Ovviamente esiste un modo più semplice per aggiungere i termini al dizionario. Fra qualche minuto inizieremo a illustrarlo. Ma prima parliamo un attimo dei dizionari.
A questo proposito, ecco una curiosità. Perché gli americani scrivono "color" anziché "colour" e "center" anziché "centre"? La risposta la conosciamo: perché a Noah Webster, che ha redatto il primo dizionario dell'inglese americano, non piacevano le regole ortografiche inglesi e quindi ha modificato arbitrariamente l'ortografia di molte parole.
Fantastico, anche se non molto illuminante. Ma non è mica facile trovare aneddoti interessanti sui dizionari!
Oltre al dizionario standard incorporato nell'applicazione, Microsoft Word consente di creare tutti i dizionari personalizzati che si desidera. Per impostazione predefinita, in Word è presente un dizionario personalizzato denominato Custom.dic, incluso nella cartella Dati applicazioni\Microsoft\Proof contenuta nella cartella del profilo utente ovvero, in Windows XP, \Documents and Settings\nome utente per impostazione predefinita. Facendo clic con il pulsante destro del mouse su una parola segnalata come errata e scegliendo Aggiungi al dizionario, la parola verrà aggiunta a Custom.dic.
Custom.dic non è altro che un normale file di solo testo. Aprendolo nel Blocco note verrà visualizzato un elenco di parole simile a quanto riportato di seguito:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
Illustreremo ora come aggiungere termini di script al dizionario di Microsoft Word a livello di programmazione. Basta creare un file di testo contenente i termini desiderati e configurare Word in modo da utilizzare quel file come dizionario personalizzato. Cosa c'è di difficile? Considerando che gli Scripting Guy sono disposti a farlo autonomamente, proprio niente.
Un attimo però: prima dobbiamo occuparci di una faccenda collaterale. Nel modello a oggetti di Microsoft Word, le informazioni sui dizionari personalizzati sono memorizzate nella raccolta CustomDictionaries. È possibile accedere a livello di programmazione a questa raccolta facendo riferimento all'oggetto Word.Application e alla proprietà CustomDictionaries. Ad esempio, nella Figura 2 viene illustrato uno script che restituisce informazioni su tutti i dizionari personalizzati associati alla copia di Microsoft Word utilizzata.
Figure 2 Script che recupera le informazioni del dizionario personalizzato (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Eseguendo lo script illustrato nella Figura 2 verranno restituite informazioni simili a quelle riportate di seguito:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
È andato tutto liscio, no?
Ovviamente recuperare informazioni sui dizionari esistenti non è come creare un nuovo dizionario personalizzato, c'è la stessa differenza che passa fra aver letto che qualcuno ha un milione di dollari e avere un milione di dollari. Vediamo quindi se riusciamo a scoprire come creare un nuovo dizionario personalizzato in Word.
Iniziamo aggiungendo tutte le funzioni VBScript a un nuovo dizionario denominato Scripting.dic. Partiamo dalle funzioni VBScript perché qui c'è qualcosa da fare, dopodiché spiegheremo come aggiungere al dizionario classi WMI, attributi ADSI e cmdlet di Windows PowerShell™ senza fare praticamente nulla. Inutile dire che, quando si tratta di lavorare poco, gli Scripting Guy sanno il fatto loro.
Tanto per cominciare, per creare un dizionario personalizzato in Microsoft Word bastano pochi semplici passaggi:
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Come si può osservare, si inizia creando un'istanza dell'oggetto Word.Application. Si osservi che la proprietà Visible non è mai stata impostata su True per visualizzare Word sullo schermo. Perché? Ebbene, semplicemente perché per eseguire questo script occorre più o meno un secondo e quindi sarebbe inutile far lampeggiare brevemente la schermata di Word per poi vederla scomparire subito. Se a qualcuno però piacciono le istanze lampeggianti di Word, se non altro per sapere che lo script è in esecuzione, aggiunga quanto riportato di seguito alla seconda riga di codice dello script:
objWord.Visible = True
Dopo avere creato l'oggetto Word.Application, utilizzeremo questa riga di codice per creare un riferimento oggetto alla raccolta CustomDictionaries:
Set colDictionaries = _
  objWord.CustomDictionaries
Chiamiamo quindi il metodo Add per aggiungere il dizionario personalizzato. Attenzione che il file non deve necessariamente esistere, se non viene trovato un file denominato Scripting.dic, in Word verrà creato un nuovo file vuoto con questo nome. Di seguito viene riportato il codice per aggiungere il dizionario personalizzato:
colDictionaries.Add “Scripting.dic”
I lettori più attenti avranno notato anche che non è stato specificato un percorso quando è stato aggiunto il nuovo dizionario, semplicemente abbiamo passato il nome del file (Scripting.dic) al metodo Add. Va bene. In questo caso, Scripting.dic verrà creato nella cartella predefinita per i dizionari e gli altri strumenti di correzione ortografica (ad esempio, C:\Documents and Settings\kenmyer\Dati applicazioni\Microsoft\Proof).
E per fare in modo che il dizionario personalizzato si trvoi in un altro percorso? Nessun problema. Utilizzando il seguente comando, il file Scripting.dic verrà creato nella cartella C:\Scripts:
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
E se in seguito decidessimo di sbarazzarci del dizionario personalizzato? Ancora una volta non ci sono problemi. In tal caso potremmo semplicemente creare un'associazione al dizionario in questione e utilizzare il metodo Delete per sbarazzarcene:
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Figura 3Documento di Word dopo l'aggiunta del dizionario personalizzato
È molto comodo per quanto ci riguarda, soprattutto alla luce del fatto che è possibile condividere Scripting.dic e lo script di creazione del dizionario personalizzato con chi si desidera. È necessario pochissimo tempo per farlo in tutte le versioni di Word e vedere che anche qui Msgbox viene considerata una parola corretta. A dire il vero, se noi Scripting Guy fossimo pigri, potremmo concludere qui l'articolo di questo mese e comunque avremmo fornito qualcosa di utile. Ma questo ancora non è nulla.
Nota: effettivamente siamo pigri, ma visto che nell'articolo è rimasto spazio vuoto, omaggiamo il pubblico ancora di un paio di script.
Come forse si saprà, VBScript e Windows Script Host sono timidi e non amano mettersi in mostra. Ciò tuttavia non vale per WMI, ADSI e Windows PowerShell. Basta chiedere e queste tecnologie paleseranno le proprie classi, proprietà e metodi, con la possibilità di sapere pressoché tutto ciò che si desidera.
Prendiamo come esempio ADSI. Nella Figura 4 viene illustrato uno script associato allo schema di Active Directory che recupera tutti gli attributi dell'oggetto account utente e quindi scrive gli attributi nel file C:\Scripts\Scripting.dic.
Figure 4 Aggiunta dei nomi degli attributi ADSI a un dizionario personalizzato (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
Visto che bello? Con solo poche righe di codice abbiamo creato un dizionario contenente tutti gli attributi dell'oggetto utente Active Directory. Condividendo questo codice con altri autori di script, nessuno dovrà più preoccuparsi del fatto che i nomi degli attributi, come streetAddress o givenName, vengano segnalati come parole errate e ovviamente con la possibilità di espandere il discorso all'infinito. Se si desidera aggiungere le proprietà della classe computer basta inserire questa riga di codice:
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
E le classi WMI? Nella Figura 5 viene illustrato uno script che recupera un elenco di tutte le classi WMI presenti nello spazio dei nomi root\cimV2 e scrive queste informazioni in C:\Scripts\Scripting.dic.
Figure 5 Aggiunta dei nomi delle classi WMI a un dizionario personalizzato (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Stiamo dimenticando gli utenti di Windows PowerShell? Gli Scripting Guy non farebbero mai una cosa simile! Caspita, per la verità li avevamo proprio dimenticati, ma per fortuna ci siamo ricordati di questo script di una riga, che restituisce tutti i nomi dei cmdlet e quindi li scrive in C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
La conclusione positiva che possiamo trarre dall'articolo di questo mese è che tutti abbiamo imparato qualcosa. I lettori hanno imparato a creare dizionari personalizzati in Microsoft Word e a configurare Word a livello di programmazione in modo che utilizzi questi dizionari personalizzati e gli Scripting Guy hanno imparato che quando si deve fare qualcosa è sempre meglio tentare di farlo fare a qualcun altro, ma se qualcosa va storto si è sempre in tempo a farlo da sé.


 Desktop file: Come evitare di perdere i dati
Desktop file Come evitare di perdere i dati and Wes Miller È sorprendente la frequenza con cui vengono persi i dati di un certo rilievo. In realtà, però, le informazioni vengono perse perché non vengono protette nel modo giusto. Scopri quali procedure seguire per proteggere i dati dell'organizzazione.
Il flusso di informazioni non può essere arrestato. Indipendentemente dalle persone a cui si affida questo compito e dalle modalità di protezione dei contenuti, esisterà sempre una possibilità di accesso. Ogni giorno vengono riportate notizie su perdite di dati, importanti o meno. È ridicolo che vengano persi dati importanti
Figura 2Evitare di scegliere password facilmente identificabili, come il nome della propria madre
Sebbene l'integrità della password e l'autenticazione locale siano importanti, nel sistema locale non dovrebbero tuttavia essere presenti dati fondamentali, a meno che non siano fisicamente protetti o crittografati. Le password da sole non bastano. La password di un utente è uno strumento che consente di evitare che utenti malintenzionati compromettano l'accesso interattivo diretto al sistema e apportino modifiche indesiderate.

Protezione fisica
I dati importanti non si dovrebbero trovare in un sistema che possa essere fisicamente compromesso o rimosso dall'ufficio. Se si dispone di sistemi che si teme possano essere compromessi all'avvio di Windows PE e durante il recupero dei dati, significa che ci sono altri problemi, Windows PE non è il colpevole. Invece, almeno una delle seguenti affermazioni è vera. I sistemi non sono protetti fisicamente in modo appropriato. Sono protetti, ma non ci si fida degli utenti che vi hanno accesso, i dati si trovano in un sistema che non è (o non può essere) protetto fisicamente oppure in sistemi non possono essere protetti fisicamente e non sono stati utilizzati strumenti di crittografia del volume, come la funzionalità BitLocker™ in Windows Vista, per impedire il danneggiamento fisico. (Per ulteriori informazioni su BitLocker, vedere l'articolo di Byron Hynes in questo numero di TechNet Magazine.)
Quale sistema potrebbe essere a rischio? È possibile proteggerli fisicamente? Perché non posizionarli in un datacenter o in altre aree con accesso limitato? Se ciò non è possibile o se si tratta di un sistema portatile, viene utilizzato il software di crittografia del volume? Se non è possibile effettuare almeno una di queste operazioni, spostare i dati in un sistema che possa essere protetto oppure crittografarli. Nel caso del computer portatile rubato, menzionato in precedenza, se il volume fosse stato crittografato con uno strumento di crittografia del volume sicuro, i dati sarebbero stati quasi completamente al sicuro.
Il solo fatto che un sistema si trovi in un datacenter non significa che sia protetto. Se si dispone di un gruppo di T1 su Internet, si corrono ancora dei rischi. L'accesso a Internet consente agli utenti malintenzionati di avvicinarsi all'accesso fisico, quindi considera attentamente le potenziali minacce a cui è sottoposto il sistema. Prendere in considerazione la possibilità di spostare i dati su un segmento separato della rete in cui si dispone di almeno un livello aggiuntivo di protezione della rete tra Internet e i sistemi analizzati.

Riduzione del rischio per i dati
Un'altra misura di protezione disponibile è costituita dal fornire agli utenti l'accesso tramite le applicazioni o gli strumenti thin-client che isolano i dati in un server fisicamente protetto. Questo può significare fornire l'accesso tramite VPN, affinché gli utenti che si trovano in un altro luogo possano avere l'accesso. Non si dovrebbe mai consentire che i vincoli fisici di un utente dettino legge su come dovrebbero essere trattati i dati. Solo perché un utente necessita dell'accesso e si trova in un luogo in cui non è disponibile la banda larga o qualsiasi altro accesso ad alta velocità, non significa che si dovrebbero spostare i dati su un'istanza locale del computer dell'utente. Se non è assolutamente possibile spostare il sistema e questo si dovesse trovare in un luogo non sicuro, proteggere i dati utilizzando la crittografia del volume.

Protezione interna al sistema
Esiste la possibilità che, nonostante l'impegno, qualcuno riesca a entrare nel sistema rimuovendo il disco rigido e posizionandolo in un altro sistema Windows, dove è possibile reimpostare gli ACL NTFS.
Per non trovarsi impreparati, utilizzare la crittografia del volume fornita con Windows Vista. Per la maggior parte delle altre versioni di Windows, sono disponibili molti strumenti di terze parti. Variano per la complessità di utilizzo, come pure per la capacità di eseguire la crittografia del volume completo e/o la crittografia di singoli file o directory come le autorizzazioni Crittografia file system (EFS). Se il volume è crittografato, i dati saranno protetti contro quasi tutti i furti più avanzati.

Protezione archiviazione
Anche i dati di backup devono essere protetti. La maggior parte delle persone fornisce due motivazioni per non effettuare un backup del sistema in modo sicuro: la crittografia durante il backup impiega troppo tempo e/o il software di backup non la supporta.
Se si sta eseguendo il backup dei sistemi e, in particolar modo, se si sta seguendo la procedura migliore, ossia tenere i backup in altro luogo, è necessario proteggere i dati che si trovano nei backup. Crittografare i dati utilizzando EFS, se disponibile, o un altro software di crittografia del volume (come la funzionalità BitLocker di Windows Vista o altro software di terze parti) o acquistare un software di backup che comprenda funzionalità di crittografia e che venga eseguito a un livello accettabile. Il fatto che i dati si trovino in un nastro di backup o spezzettati in una soluzione di backup basata su disco non significa che sono completamente protetti. Considerare che il meccanismo di trasporto stesso sarà compromesso.

Protezione della trasmissione
È necessario proteggere tutti i dati trasportati via cavo. Utilizzare solo protocolli protetti per accedere al sistema remoto. Utilizzare versioni crittografate di protocolli e considerare sempre la probabilità di un attacco di tipo man-in-the-middle (MITM). Non utilizzare protocolli poco crittografati o non crittografati e, se si utilizza la crittografia, non utilizzare una lunghezza di crittografia debole o un algoritmo. È necessario che qualcuno all'interno dell'organizzazione capisca tutti i protocolli di comunicazione e gli algoritmi di crittografia utilizzati all'interno del sistema nell'infrastruttura.

Eliminazione protetta
Alcune volte è successo che su dischi rigidi o altri dispositivi di archiviazione comprati da eBay o dal mercato delle pulci locale sono stati rilevati software forensi o utilità non eliminate che rivelavano segreti, dati che avrebbero dovuto essere eliminati completamente prima di vendere i dispositivi.
Se si dispone di UFD nell'organizzazione, prendere in considerazione le utilità di crittografia obbligatorie. I dischi che contengono dati ad alto rischio dovrebbero essere crittografati. Contrariamente a quanto si pensa, io non concordo con l'idea che la semplice crittografia dei volumi prima di disfarsene sia una modalità sicura. Ricordate la metafora sui rifiuti medici che ho menzionato in precedenza? Considerare i dati che si trovano su questi sistemi come rifiuti pericolosi e proteggere le utilità di eliminazione dati come il trattamento. Utilizzare uno strumento di eliminazione dati che implementi la specifica DoD 5220.22-M, come SDelete di Mark Russinovich, prima di rivendere i dischi e i sistemi o anche prima di spostarli all'interno dell'organizzazione. Diversamente l'utente successivo verrà a conoscenza di tutti i dati dell'utente precedente.

Controllo
Ultimo, ma non meno importante, un altro componente chiave della protezione dei dati è costituito dal controllo e anche dal modello di minacce (Threat Modeling), del ciclo di vita dei dati all'interno dell'organizzazione. Comprendere i punti deboli in cui può verificarsi la perdita dei dati e fare particolare attenzione a questi punti. Windows fornisce diversi strumenti di controllo integrati. Con il controllo, tuttavia, è possibile incorrere facilmente nell'overflow dei dati. Verificare di effettuare il controllo nelle aree giuste e di non produrre una quantità eccessiva di dati. Controllare i punti deboli e correggerli con adeguate attività di prevenzione. Evitare che queste piccole falle indeboliscano l'intera struttura di protezione dei dati. Accertarsi inoltre che gli utenti sappiano come trattare i dati. Questi sono i collegamenti importanti a molti livelli dell'organizzazione. Sarà possibile trovare ulteriori indicazioni nella barra laterale "Ulteriori riferimenti". Non dimenticare di seguire tutti i suggerimenti qui delineati; in questo modo si potranno dormire sonni tranquilli.
Ulteriori riferimenti
Nella guida relativa alle risorse per i responsabili dell'implementazione per l'ottimizzazione dell'infrastruttura centrale, dal livello base a standardizzato, verrà illustrato come spostare l'infrastruttura IT da un livello base reattivo e molto manuale a un livello standardizzato con una maggiore automazione, standard di configurazione imposti e operazioni ottimizzate. Scaricare la guida all'indirizzo go.microsoft.com/?linkid=5795711. È possibile trovare ulteriori guide alle risorse per i responsabili dell'implementazione per l'ottimizzazione dell'infrastruttura all'indirizzo microsoft.com/io. Vedere anche l'articolo "Le 10 leggi immutabili della protezione" per ulteriori suggerimenti sulla protezione.


 Taccuino: Parlare agli sviluppatori
Taccuino Parlare agli sviluppatori and David Aiken Ottenere dagli sviluppatori la creazione di applicazioni più gestibili è più facile di quanto si creda. Dipende tutto dalla comunicazione. Gli sviluppatori vedono il software da una prospettiva diversa rispetto agli amministratori. Gli amministratori, tuttavia, parlando con gli sviluppatori possono spiegare ciò che è importante ai loro occhi e gli sviluppatori possono progettare di conseguenza del codice più aderente alle esigenze dell'organizzazione.
Sembrerà strano, ma gli sviluppatori hanno sul software un punto di vista diverso dagli amministratori. Gli sviluppatori lavorano con il codice, le tracce, i file di configurazione XML, i GUID e gli assembly. Gli amministratori lavorano con script e snap-in di Microsoft® Management Console (MMC) (almeno, così vorrebbero).
È opportuno fare un passo indietro. A volte l'intero processo di sviluppo del software sembra senza senso. Si investono tantissime risorse cercando di intuire ciò che serve all'utente finale. Si creano prototipi, si eseguono studi sull'utilizzabilità, interviste e ogni tipo di speculazione, eppure quando si tratta di esercitare una capacità di gestione semplice e coerente, tutto sembra svanire. Tanto basta a complicare qualsiasi tipo di progetto.
Ho sempre pensato che Xcopy, Regedit e il Blocco Note rappresentassero i modi migliori per installare il software. Ora so che invece Microsoft Installer (MSI) non ha rivali e può essere personalizzato, installato e disinstallato. Mi rendo conto che chiedere a un amministratore di configurare un servizio Web utilizzando il Blocco note per modificare del codice XML è probabilmente una pessima idea e che uno snap-in MMC (o uno script di Windows PowerShell™) rappresenta, di gran lunga, un'alternativa migliore. So bene che una traccia dello stack non suggerisce a un utente o amministratore la causa principale e le possibili soluzioni di un problema e che resta da preferire un evento ben scritto nei registri delle applicazioni. So anche che per creare software che possa essere gestito e utilizzato dagli amministratori, è necessario trattare questi ultimi come fossero utenti.
Se si considera l'amministratore come un utente, è possibile definire casi di utilizzo, creare prototipi, eseguire studi utilizzabilità e così via. In questo modo si riesce a garantire i massimi livelli di utilizzabilità per gli amministratori. In altre parole si aiutano gli amministratori a installare, configurare, monitorare, risolvere i problemi e correggere il software fornito, senza che chiamino il supporto. Se si utilizzano le funzionalità di gestione integrate nel sistema operativo che gli amministratori conoscono bene, si riesce a ridurre in modo considerevole il costo di esecuzione dell'applicazione (con meno riassegnazioni dei problemi), si aumenta la soddisfazione del cliente (i problemi dell'applicazione sono meno frequenti e i clienti possono risolverli rapidamente) e si aumentano le probabilità di vendere altre copie del software a scapito di un prodotto concorrente (e come risultato finale, una bella barca tra le isole del Mediterraneo).
D'accordo, la barca è un sogno. Invece ottenere che gli sviluppatori producano applicazioni più gestibili non è solo un sogno, è un traguardo raggiungibile. Chiunque può collaborare. La prossima volta che qualcosa va storta, meglio non limitarsi a inoltrare il messaggio di e-mail e chiamare l'autore del software con un sussurro. È certamente meglio suggerire che venga scritto un evento nel registro dell'applicazione o sia previsto un misuratore delle prestazioni o una qualche altra indicazione del problema. Ancora meglio, si può suggerire una possibile causa e una risoluzione del problema. È possibile anche chiedere allo sviluppatore di creare uno script di Windows PowerShell o uno snap-in della console MMC per configurare l'applicazione. Il vero problema è che gli sviluppatori non sono sempre consci dell'esistenza dei sistemisti, senza parlare delle loro esigenze. A volte basta ricordarlo.


 Windows Confidential: Cosa vedono i nuovi utenti nel menu Start
Windows Confidential Cosa vedono i nuovi utenti nel menu Start and Raymond Chen Immagina di acquistare un computer nuovo, avviare Windows, selezionare il pulsante Start e visualizzare un menu vuoto. Esiste un motivo per cui il menu Start contiene delle applicazioni nello spazio destinato ai programmi utilizzati con maggiore frequenza anche se non ne è stato ancora utilizzato nessuno: fornire un uso immediato. Scopri come vengono scelte queste applicazioni.
Abbiamo pensato di riempire questo menu Start inizialmente vuoto con parti di testo. Ad esempio, qualcosa del tipo "Attenzione, questo spazio vuoto visualizzerà presto tutti i programmi che eseguirai, credimi". In questo modo lo spazio vuoto non è più solo assurdo, ma anche brutto.
Dopo numerosi tentativi abbiamo deciso, infine, cosa verrà visualizzato in Windows XP. Il mese scorso l'elenco dei programmi utilizzati con maggiore frequenza era basato su un sistema a punti, i programmi con più punti vengono visualizzati in questo elenco dinamico. Per i nuovi utenti, abbiamo assegnato alcuni punti fittizi per i diversi programmi. Di conseguenza, il menu Start iniziale presenta un campionamento di programmi divertenti che danno un'idea di cosa è possibile fare.
Il numero dei punti fittizi è stato scelto attentamente in modo che siano presenti punti sufficienti affinché i programmi desiderati vengano posizionati nell'elenco di programmi utilizzati con maggiore frequenza, ma non tanti da sommergere quelli reali guadagnati dai programmi man mano che gli utenti avviano le applicazioni.
Tuttavia, questi punti fittizi non vengono assegnati se l'utente ha effettuato l'aggiornamento da Windows 2000. In tal caso, i punti utilizzati dal menu Start di Windows 2000 per Intellimenus sono stati utilizzati per generare il sistema a punti di Windows XP. In questo modo, il menu Start per un'installazione aggiornata di Windows XP rifletteva i programmi che l'utente aveva eseguito più spesso in Windows 2000 proprio all'inizio.
Nella versione iniziale di Windows XP, i punti fittizi sono stati assegnati in modo che i primi tre dei sei spazi nell'elenco dei programmi utilizzati con maggiore frequenza fossero scelti da Windows, mentre gli ultimi tre dal produttore del computer. Se hai acquistato una copia di Windows XP al dettaglio, piuttosto che una preinstallata, Windows compila due di quei tre spazi, mentre lascia l'ultimo vuoto. In questo modo, il primo programma eseguito viene visualizzato immediatamente nel menu Start.
Questi sei spazi hanno subito variazioni in Windows XP Service Pack 1. Due spazi sono stati scelti da Windows, uno dal Ministero della Giustizia degli Stati Uniti e l'ultimo dal produttore del computer. Come prima, se hai acquistato una copia di Windows XP presso un rivenditore al dettaglio, due degli spazi del produttore del computer sono stati assegnati da Windows, mentre l'ultimo è stato lasciato vuoto.
Il menu Start è una delle parti più visibili dell'interfaccia utente di Windows e, come si può vedere, molto del lavoro consiste nel tentare di renderlo naturale e intuitivo.


 Lettere: Risposte alle domande degli utenti
Lettere Risposte alle domande degli utenti
Introduzione a Windows PE
Dopo avere letto l'articolo di Wes Miller "Introduzione a Windows PE" nel numero di settembre 2006 di TechNet Magazine, ho creato un menu con la procedura guidata basata su HTA (HTML for Applications). Avrei qualche domanda su come farlo funzionare in Windows® PE 2.0.
—Andy

Di seguito sono riportate le domande degli utenti unitamente alle relative risposte di Wes:

Com' è possibile sapere se i componenti software facoltativi HTA e Windows Script Host (WSH) sono in esecuzione dal file ISO?
Se i componenti facoltativi sono stati installati nel file ISO seguendo le istruzioni fornite nella documentazione, dovrebbero funzionare correttamente, ma ho sentito parlare di due situazioni comuni in cui questo non accade: se non è stato eseguito peimg/prep per preparare l'immagine oppure se non è stato utilizzato il parametro /commit con ImageX per eseguire il commit delle modifiche nell'immagine di Windows PE quando la si smonta.

È necessario installare Strumentazione gestione Windows (WMI)? Con i file della procedura guidata disponibili tramite l'articolo viene generato un errore in Internet Explorer®.
I file della procedura guidata dovrebbero funzionare se sono installati i componenti HTA, dato che sono molto rudimentali. WMI non è necessario per questi componenti, poiché li ho scritti prima che fosse possibile aggiungere WMI a Windows PE.

Che procedura dovrei seguire per includere OC.bat nel file startnet.cmd?
Non è necessario utilizzare il file OC.bat se si utilizza Windows PE 2.0. Serve solo con le versioni 1.x. Utilizzando Windows PE 2.0 è possibile aggiungere componenti senza utilizzare lo shim eseguito da OC.bat.

Posso utilizzare parte del codice di Wes nel menu una volta che sarò riuscito a farlo funzionare?
Certo, gli esempi di codice sono a disposizione degli utenti che possono riutilizzarli come desiderano. Non è invece possibile rivenderli o ridistribuirli unitamente al pacchetto del codice di esempio. Per ulteriori informazioni vedere il contratto di licenza sul sito Web di TechNet Magazine.

Dove si trova Windows PE?
Dove posso trovare gli strumenti di generazione di Windows PE? È possibile scaricarli o è necessario acquistarli?
—Franklin
Gli strumenti di generazione di Windows PE per Windows Vista™ fanno parte di Windows Automated Installation Kit (WAIK). Il download è disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=85377.
Il kit WAIK può essere utilizzato soltanto con la famiglia di sistemi operativi Windows Vista. Per la distribuzione di Windows XP, sono disponibili molti strumenti simili in Business Desktop Deployment Solution Accelerator. Con Windows Vista, tuttavia, le modalità di gestione delle licenze per Windows PE sono cambiate. In precedenza (per Windows XP), Windows PE era disponibile soltanto con licenze Software Assurance (per ulteriori informazioni, visitare il sito microsoft.com/licensing/sa/benefits/winpe.mspx).

Gestione risorse file server
Il pacchetto Gestione risorse file server verrà messo a disposizione del pubblico per il download in modo da poterlo utilizzare con la versione originale di Windows Server® 2003 o è compatibile soltanto con versione R2?
—Dan
Gestione risorse file server è una funzionalità di Windows Server 2003 R2. A causa delle dipendenze presenti in tale versione, attualmente non si prevede di renderlo disponibile per le versioni precedenti.

All'interno del kernel
Ho letto l'articolo di Mark Russinovich su "Il kernel di Windows Vista: parte 3" e avrei un paio di domande. Primo, vedo che in Process Explorer vengono visualizzati i percorsi casuali dei file exe o dll durante ogni sessione di avvio. È possibile che il malware utilizzi lo stesso meccanismo per determinare la posizione di codice da sfruttare? Secondo, se sono presenti 256 posizioni da cui può partire la sequenza casuale (se interpreto correttamente il contenuto dell'articolo), com'è possibile evitare che il malware esegua "brutalmente" il probe se il codice oggetto dell'attacco rimane statico per tutta la sessione?
—Joe

Mark ha risposto a tutte le domande:

Per quanto riguarda Process Explorer si tratta dell'uovo di Colombo: il malware non può scoprire dove si trovano le DLL perché non è in grado di individuare la posizione dell'API che restituisce queste informazioni. L'esecuzione "brutale" del probe non è praticabile come metodo di introduzione in quanto, se il malware non fosse riuscito a individuare correttamente queste informazioni, l'applicazione che tenta di infettare con tutta probabilità si arresterebbe in modo anomalo o, come minimo, la sequenza casuale rallenterebbe la diffusione del virus. Nel peggiore dei casi verrebbe impedito al malware di infettare il sistema.

Contattaci
Desideri esprimere un commento? Non esitare! Il tuo parere è importante per noi. Inviaci un messaggio di posta elettronica all'indirizzo tnmag@microsoft.com.