Security

Blocco di applicazioni con i criteri di restrizione software

Chris Corio and Durga Prasad Sayana

Panoramica:

• Funzionamento dei criteri di restrizione software
• Esecuzione dell'inventario delle applicazioni nell'ambiente in uso
• Creazione e applicazione di criteri

Quando i professionisti IT intendono ridurre il costo totale di proprietà (TCO) dei relativi computer desktop, vengono in genere prese in considerazione due strategie principali. La prima prevede la rimozione degli

account degli utenti desktop dal gruppo Administrators. La seconda consiste nel limitare le applicazioni che gli utenti possono eseguire. La risoluzione di questi problemi può rivelarsi un'impresa alquanto impegnativa in un ambiente aziendale, ma Windows Vista® offre alcune tecnologie che consentono di ottenere questo risultato.

Con Windows Vista e la relativa funzionalità Controllo dell'account utente (UAC) è stato fatto un enorme passo avanti verso la possibilità per i professionisti IT di consentire l'esecuzione dei relativi utenti aziendali come membri del gruppo Users (utenti standard). Con Controllo dell'account utente il contesto di sicurezza predefinito per tutte le applicazioni è stato modificato da amministratore a utente. Questa migrazione al gruppo Users resta un'attività straordinaria ma, man mano che il settore si adegua a questo nuovo paradigma, l'attività verrà ulteriormente semplificata.

Dopo l'analisi dei problemi correlati alla migrazione degli utenti al gruppo Users o, talvolta, durante questo processo, molti amministratori catalogano le applicazioni che i relativi utenti necessitano di eseguire e prendono in considerazione i passaggi necessari per consentire solo l'esecuzione di queste applicazioni. La funzionalità criteri di restrizione software è stata progettata per consentire ai professionisti IT di conseguire esattamente questo scopo.

Occorre semplicemente specificare le applicazioni consentite per l'esecuzione e distribuire il criterio mediante Criteri di gruppo. L'imposizione di un criterio di questo tipo in un'intera organizzazione determina una riduzione del costo totale di proprietà, in quanto questo blocco consente di limitare i problemi correlati alle applicazioni non supportate. È inoltre possibile utilizzare i criteri di restrizione software in alcuni contesti interessanti ed estremi, come illustrato nell'intestazione laterale "Criteri di restrizione software di base".

Funzionamento dei criteri di restrizione software

I criteri di restrizione software sono stati progettati per controllare esattamente il tipo di codice che può essere eseguito da un utente su un computer con Windows Vista. L'amministratore crea un criterio che stabilisce quali applicazioni è possibile o non è possibile eseguire nell'ambiente in uso. Questo criterio viene quindi valutato nel contesto in cui è consentita l'esecuzione del codice, ovvero durante la creazione del processo, in una chiamata a ShellExecute e durante l'esecuzione di uno script. Questo contesto verrà analizzato in maggiore dettaglio più avanti in questo articolo.

Se si stabilisce che un'applicazione può essere eseguita, l'applicazione verrà avviata. Se, tuttavia, si stabilisce che un'applicazione non può essere eseguita, l'applicazione verrà bloccata e l'utente riceverà una notifica. Se, ad esempio, si tentasse di eseguire Solitario dal menu Start, pur non essendo l'esecuzione di questa applicazione, verrebbe visualizzata una finestra di dialogo simile a quella riportata nella Figura 1.

Figura 1** Quando un'applicazione è bloccata viene visualizzata una finestra di dialogo **(Fare clic sull'immagine per ingrandirla)

L'interfaccia utente per la definizione di un criterio di restrizione software è esposta in Editor oggetti Criteri di gruppo, ovvero la posizione in cui viene creato il criterio di blocco. Sono disponibili diversi metodi per definire il tipo di codice che è possibile o non è possibile eseguire. Una volta completato e testato il criterio, è possibile distribuirlo.

Definizione dei criteri di restrizione software

La prima importante decisione da prendere, una decisione che influirà in modo significativo sulla modalità di funzionamento dei criteri di restrizione software nell'ambiente in uso, prevede la selezione di un tipo di regola predefinito. I criteri di restrizione software possono essere distribuiti utilizzando una delle due modalità seguenti: elenco delle applicazioni consentite o elenco delle applicazioni non consentite. In sostanza, queste due modalità consentono di specificare se si desidera creare un criterio che descriva ciascuna applicazione che è possibile eseguire nell'ambiente in uso o un criterio che stabilisca quale applicazione non può essere eseguita.

Nella modalità elenco delle applicazioni consentite la regola predefinita all'interno del criterio è impostata su Con restrizioni e determina il blocco di tutte le applicazioni la cui esecuzione non è consentita. Nella modalità elenco delle applicazioni non consentite, la regola predefinita è impostata su Senza restrizioni e limita solo le applicazioni elencate in modo esplicito.

La modalità elenco delle applicazioni non consentite, come è possibile intuire, rappresenta un approccio poco realistico se si desidera ottenere una riduzione elevata del costo totale di proprietà e conseguire i vantaggi in termini di sicurezza derivanti dal blocco delle applicazioni. La creazione e la gestione di un elenco esteso che blocchi tutti i malware e altre applicazioni problematiche è praticamente impossibile; pertanto, è consigliabile che il criterio di restrizione software venga implementato nella modalità elenco delle applicazioni consentite, che prevede l'utilizzo della regola predefinita Con restrizioni.

Esecuzione dell'inventario delle applicazioni nell'ambiente in uso

Se si prevede di progettare un criterio che specifichi le applicazioni che possono essere eseguite, è necessario determinare esattamente quali applicazioni sono richieste dagli utenti. I criteri di restrizione software offrono una funzionalità di registrazione avanzata con un criterio molto semplice che consente di determinare esattamente quali applicazioni vengono eseguite nell'ambiente in uso.

Su un insieme di computer di esempio all'interno del proprio ambiente distribuire un criterio di restrizione software con la regola predefinita impostata su Senza restrizioni e assicurarsi di rimuovere tutte le altre regole aggiuntive. L'obiettivo è abilitare il criterio di restrizione software ma non utilizzare tale criterio per limitare l'esecuzione delle applicazioni; al contrario, il criterio viene utilizzato semplicemente per monitorare le applicazioni eseguite.

Successivamente, creare il seguente valore del Registro di sistema per attivare la funzionalità di registrazione avanzata e impostare il percorso in cui deve essere scritto il file di registro:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

A questo punto, quando un'applicazione viene eseguita e il criterio di restrizione software viene valutato (questo criterio viene valutato anche se è consentita l'esecuzione di tutte le applicazioni disponibili), viene scritta una voce nel file di registro.

Ciascuna voce del registro include il chiamante del criterio di restrizione software e l'ID processo (PID) del processo chiamante, la destinazione valutata, il tipo di regola del criterio di restrizione software selezionata e un identificatore per la regola. Di seguito viene riportata una voce di esempio scritta quando un utente fa doppio clic su notepad.exe:

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

Questo file di registro rappresenta ciascun frammento di codice eseguibile che verrà controllato dal criterio di restrizione software dopo che è stato abilitato e impostato per il blocco delle applicazioni. Ne consegue che per ciascuna voce del file di registro è necessario decidere se deve essere inclusa nell'elenco delle applicazioni consentite. Tenere presente che verranno controllati diversi file binari che fanno parte di Windows® e sono necessari per il corretto funzionamento del sistema.

La tecnica di registrazione descritta in questo articolo offre un metodo chiaro per comprendere esattamente quali applicazioni nell'ambiente in uso verranno rilevate dai criteri di restrizione software. Tuttavia, tale tecnica non rappresenta l'unico metodo per eseguire questa attività.

Lo strumento Inventory Collector, integrato in Microsoft® Application Compatibility Toolkit 5.0, consente di eseguire l'inventario delle applicazioni utilizzate nel proprio ambiente. Questo strumento offre diversi metodi per determinare quali applicazioni sono installate nel proprio ambiente e consente di consolidare i risultati in un database centrale.

Creazione di regole aggiuntive

Dopo aver creato l'elenco delle applicazioni di cui è necessario consentire l'esecuzione nell'ambiente in uso, è possibile creare le regole che consentiranno l'esecuzione effettiva di tali applicazioni. La funzionalità criteri di restrizione software prevede l'utilizzo di due metodi per identificare i criteri: un metodo è basato sulle proprietà di crittografia di un'applicazione, come il relativo hash, mentre l'altro definisce una cartella o un percorso attendibile in cui devono risiedere le applicazioni considerate attendibili.

Nella Figura 2 viene illustrato dove aggiungere le regole per consentire l'esecuzione delle applicazioni nel nodo Criteri restrizione software dell'Editor oggetti Criteri di gruppo (gpedit.msc). Il metodo più semplice per definire le applicazioni nel proprio ambiente consiste nel creare una regola hash per ogni singolo file binario rilevato durante la fase di registrazione.

Figura 2** Utilizzo di gpedit.msc per creare i criteri di restrizione software **(Fare clic sull'immagine per ingrandirla)

Poiché l'hash è un valore univoco restituito per uno specifico insieme di bit, a ciascun file binario nel criterio sarà associato un hash differente. Questo approccio è particolarmente sicuro e consentirà solo l'esecuzione degli specifici file binari presenti nel criterio definito.

Ovviamente, questo approccio presenta delle limitazioni. È possibile, ad esempio, che nell'ambiente in uso siano presenti diverse migliaia di file binari. La creazione di tutte queste regole nell'interfaccia utente dei criteri di restrizione software può rivelarsi piuttosto difficoltosa e, se il numero di regole diventa particolarmente elevato, le prestazioni possono risentirne. Inoltre, l'aggiornamento di ciascuna applicazione nel proprio ambiente richiederà la distribuzione nell'ambiente di una o più nuove regole hash. L'aggiornamento di un criterio così vasto man mano che le applicazioni vengono aggiornate può rappresentare un onere non indifferente.

Per fortuna, per ovviare a questo problema, è possibile utilizzare altri due metodi di identificazione delle regole che consentono di semplificare l'utilizzo dei criteri di restrizione software nell'ambiente in uso. Esplorando ulteriormente il meccanismo di sicurezza crittografica, è possibile creare una regola che consentirà l'esecuzione di qualsiasi file binario firmato da uno specifico certificato.

L'esecuzione di questa attività consente di semplificare la gestione dell'elenco dei criteri in quanto, quando un'applicazione viene aggiornata, i nuovi file binari vengono in genere firmati dallo stesso certificato di quelli precedenti. Tuttavia, se non si desidera che una versione precedente del file binario venga eseguita nel proprio ambiente, è necessario aggiungere la regola hash Con restrizioni in modo da impedire che venga consentita l'esecuzione del file.

Per impostazione predefinita, la valutazione delle regole certificati è disattivata per i criteri di restrizione software. Due sono le ragioni alla base dell'esecuzione di questa operazione.

Primo, le regole certificati nei criteri di restrizione software vengono definite in base agli elementi presenti nell'archivio Autori attendibili del sistema. Poiché l'archivio Autori attendibili viene utilizzato per scopi diversi da quelli delle regole dei criteri di restrizione software, è necessario dedicare maggiore tempo e attenzione quando questo archivio viene utilizzato per la funzionalità criteri di restrizione software.

La seconda ragione è che, per determinare se la firma di un file è valida, è necessario eseguire l'hash del file e confrontarlo con le informazioni sulla firma. L'esecuzione dell'hash di un file è un'operazione molto dispendiosa: per calcolare l'hash è necessario leggere l'intero file dal disco ed elaborarlo.

Per attivare le regole certificati, accedere al nodo Criteri restrizione software e selezionare l'oggetto di imposizione nel riquadro dei risultati. Fare doppio clic per aprire la finestra di dialogo delle proprietà e selezionare l'opzione Imponi regole certificati.

L'altro metodo comune per identificare il codice consiste nell'utilizzare il percorso del codice sul computer locale. Questa è una tecnica efficace ed efficiente, ma presenta una limitazione: è necessario assicurare che le impostazioni di sicurezza siano impostate in modo appropriato nella cartella.

Se si aggiunge una specifica regola percorso e agli utenti è consentito scrivere in tale percorso, ad esempio sul desktop, gli utenti saranno in grado di eseguire tutte le applicazioni desiderate inserendo l'eseguibile nella cartella in questione. Tuttavia, se gli utenti non fanno parte del gruppo Administrators, non saranno in grado di apportare modifiche nella directory Programmi o Windows. Questo implica che, se tutte le applicazioni risiedono nella directory Programmi e gli utenti non fanno parte del gruppo Administrators, sarà necessario ricorrere alle regole percorsi per poter disporre di un criterio semplice ed efficiente.

Le regole percorsi offrono alcune altre funzionalità che le rendono particolarmente appropriate per determinati ambienti. Questa tecnica fornisce il supporto per i caratteri jolly e consente di utilizzare le variabili di ambiente per semplificare la definizione delle regole portabili nel proprio ambiente; dopo tutto, %systemdrive% potrebbe non corrispondere a c:\ per tutti gli utenti.

Quanto alle prestazioni e alla gestione, questo metodo rappresenta probabilmente la soluzione più semplice per identificare il codice. Le regole percorsi sono certamente una soluzione da prendere in considerazione, ma occorre tenere presenti alcune considerazioni di sicurezza aggiuntive.

Regole area rete

I criteri di restrizione software includono un tipo di regola denominato Regola area rete, che ora tuttavia, è diventato obsoleto. L'intento originale di queste regole era basato sull'idea che l'origine di uno specifico codice eseguibile può essere identificata e considerata attendibile e, pertanto, consentirne l'esecuzione. Purtroppo, questo obiettivo è particolarmente difficoltoso da raggiungere e, di conseguenza, questo metodo non ha mai funzionato in modo ottimale. Attualmente, questo tipo di regola non viene applicato nella maggior parte delle posizioni dei punti di ingresso dei criteri di restrizione software.

Nei casi in cui la maggior parte delle applicazioni viene installata nella directory %Programmi% ma altri file eseguibili vengono installati in posizioni differenti e firmati da uno specifico certificato, potrebbe essere opportuno utilizzare tipi di regole differenti. Utilizzando alcune regole hash e un paio di regole percorsi si sarà in grado di ottenere il criterio appropriato.

Tenere presente semplicemente che le regole vengono elaborate secondo uno specifico ordine, come illustrato nella Figura 3. Le regole certificati sono le regole più specifiche, seguono quindi le regole hash, le regole percorsi e infine le regole percorsi contenenti caratteri jolly. Pertanto, se un frammento di codice viene identificato da una regola hash e da una regola percorso, il livello di sicurezza della regola hash avrà la priorità.

Figura 3** Ordine di elaborazione delle regole **(Fare clic sull'immagine per ingrandirla)

Imposizione dei criteri

I criteri di restrizione software forniscono un'ampia gamma di copertura sul sistema da proteggere. L'idea è che qualsiasi posizione da cui il codice può essere eseguito deve essere integrata con il criterio di restrizione software e, a sua volta, deve controllare il criterio per verificare se è consentita l'esecuzione del codice eseguibile.

Anche se sono presenti numerose posizioni che controllano i criteri di restrizione software, il punto di ingresso più semplice è CreateProcess. Durante CreateProcess, il criterio viene controllato per determinare se è consentita o meno l'esecuzione del file binario che rappresenta l'applicazione. La verifica dei criteri viene eseguita dall'API SaferIdentifyLevel, che è documentata pubblicamente. Il processo generale è illustrato nella Figura 4. L'API SaferIdentifyLevel verrà trattata in maggiore dettaglio più avanti.

Figura 4** Utilizzo di SaferIdentifyLevel di determinare se un file binario può essere eseguito **(Fare clic sull'immagine per ingrandirla)

Dopo CreateProcess, l'API più comunemente utilizzata in cui viene imposto il criterio di restrizione software è ShellExecute. Questa API viene chiamata quando l'utente fa clic su un'applicazione nel menu Start o fa doppio clic su un elemento sul desktop.

È possibile chiamare ShellExecute in un'ampia gamma di formati di file. Nel caso di un file .txt, la chiamata di ShellExecute nel file non comporta l'esecuzione del file; dal punto di vista tecnico, il file viene ovviamente aperto. Per questa ragione, i criteri di restrizione software contengono un elenco di tipi di file eseguibili in modo che possano determinare quali tipi di file vengono controllati quando ShellExecute viene chiamata. È possibile personalizzare questo elenco di tipi di file eseguibili nell'interfaccia utente dei criteri di restrizione software.

Oltre a CreateProcess e ShellExecute, sono disponibili altri due punti di integrazione principali: LoadLibrary e host di script. LoadLibrary è ovviamente una posizione importante da cui controllare il codice eseguibile, ma presenta alcuni vincoli speciali.

La maggior parte delle applicazioni include un eseguibile e diverse DLL che vengono caricate. Sul sistema vengono in genere eseguite molte applicazioni. Questo significa che LoadLibrary richiede un numero elevato di controlli dei criteri. A seconda del criterio utilizzato per l'identificazione del codice, l'imposizione di questo punto di ingresso può rivelarsi un'operazione piuttosto dispendiosa. Per avere un'idea, si immagini un contesto che prevede il controllo dell'hash di ogni DLL caricata nel sistema, il che implica l'esecuzione dell'hash del file binario e il confronto di tale file con un elenco costituito probabilmente da migliaia di hash.

Questa funzionalità è disattivata per impostazione predefinita, ma può essere abilitata manualmente A tal fine, accedere al nodo Criteri restrizione software in gpedit.msc e fare doppio clic su Imposizione. Selezionare quindi il pulsante di opzione Tutti i file nel software.

Come affermato, i criteri di restrizione software sono integrati con la maggior parte degli host di script nel sistema, tra cui cmd, VBScript, Cscript e JScript®. Questi punti di ingresso, analogamente agli altri, utilizzano l'API di imposizione dei criteri di restrizione software principale: SaferIdentifyLevel.

L'API SaferIdentifyLevel determina se deve essere consentita l'esecuzione di uno specifico eseguibile in base alle informazioni di identificazione presenti nei criteri di restrizione software pertinenti. Questa API è documentata pubblicamente. Gli host di script di terze parti e gli ambienti eseguibili possono e devono utilizzarla per l'integrazione con i criteri di restrizione software in modo che i criteri possano determinare se consentire l'esecuzione di un frammento di codice eseguibile.

Esecuzione con l'account Utente standard

Una funzionalità non molto nota dei criteri di restrizione software è la capacità di filtrare i privilegi di determinate applicazioni in fase di avvio. Questa funzionalità è stata introdotta in Windows XP, ma non è stata esposta nell'interfaccia utente dei criteri di restrizione software fino al rilascio di Windows Vista.

In tal modo, questa funzionalità può essere considerata un'anticipazione di Controllo dell'account utente di Windows Vista, in quanto può essere utilizzata per eseguire un'applicazione con l'account Utente standard anche quando l'utente è membro del gruppo Administrators. Questa situazione si verifica quando si crea una regola e si imposta il livello di sicurezza sulla modalità di esecuzione come utente normale nell'interfaccia utente di Regole aggiuntive.

Sia la funzionalità di filtraggio dei token di Controllo dell'account utente che le regole di esecuzione come utente normale dei criteri di restrizione software sfruttano i vantaggi di un'API sottostante che implementa lo stesso comportamento dell'API CreateRestrictedToken. Tuttavia, tra le due tecnologie esistono differenze architetturali globali molto significative. In particolare, Controllo dell'account utente si differenzia dai criteri di restrizione software per due aspetti principali.

Primo, in Windows Vista con la funzionalità Controllo dell'account utente attivata, ogni applicazione viene avviata per impostazione predefinita con un token di sicurezza simile a un membro del gruppo Users, anche quando l'utente è un amministratore. Questo risultato può essere ottenuto con i criteri di restrizione software, ma non esiste alcun metodo per avviare un'applicazione con il token di amministratore effettivo dell'utente, ad esempio quando l'utente deve installare un'applicazione. La modifica nel contesto di sicurezza predefinito e la semplicità di accesso al token di amministratore completo di un utente sono i vantaggi principali di Controllo dell'account utente.

La seconda differenza è che, nel caso di eseguibili, lo stesso codice stabilisce il livello di privilegio necessario per il relativo funzionamento. Questa è una distinzione importante in quanto i fornitori di software indipendenti (ISV) e gli sviluppatori sono in grado di comprendere le esigenze del relativo codice. Ad esempio, se un'applicazione del Pannello di controllo deve apportare una modifica che richiede privilegi di amministratore, può specificare tale requisito nel relativo file manifesto. Pertanto, l'ISV può descrivere i privilegi richiesti da un'applicazione piuttosto che imporre un determinato livello di privilegio su di essa senza alcuna possibilità di modificare questo livello.

Per ora, è opportuno evitare di utilizzare le regole di esecuzione come utente normale a meno che non si sia in grado di comprenderne il funzionamento. Controllo dell'account utente rappresenta un metodo eccellente per rimuovere gli utenti desktop dal gruppo Administrators ed è opportuno considerare seriamente l'idea di lasciare abilitata la funzionalità Controllo dell'account utente nell'ambiente aziendale.

Criteri di restrizione software attualmente in uso

Occorre prendere in considerazione diversi fattori quando si utilizzano i criteri di restrizione software. Tuttavia, accade talvolta che i criteri di restrizione software vengano utilizzati senza averne la consapevolezza. Se, ad esempio, si esegue Controllo genitori su un sistema Windows Vista, per controllare l'esecuzione delle applicazioni vengono utilizzati i criteri di restrizione software.

I criteri di restrizione software hanno rappresentato un importante sviluppo tecnologico quando sono stati introdotti per la prima volta in Windows XP. Tuttavia, il blocco delle applicazioni solo ora sta iniziando effettivamente ad attirare l'attenzione dei professionisti IT.

La funzionalità criteri di restrizione software in Windows Vista presenta aspetti che devono essere ancora perfezionati, ma è chiaro che gli amministratori desiderano disporre di un maggiore controllo sulle applicazioni in esecuzione nei relativi ambienti. Per fortuna, questa tecnologia continuerà a evolversi, agevolando per i professionisti IT la gestione dei relativi sistemi e la riduzione dei costi correlati all'esecuzione di un ambiente Microsoft Windows.

Criteri di restrizione software di base

Un'applicazione dei criteri di restrizione software prevede la creazione di un criterio che determina il blocco di Windows in modalità tutto schermo. Per creare questa modalità, Microsoft produce un toolkit, denominato SteadyState™. Tuttavia, se si è interessati solo al blocco delle applicazioni che possono essere eseguite, questo risultato può essere ottenuto con maggiore facilità.

Per consentire l'insieme minimo di applicazioni necessarie per accedere a Windows Vista, creare un criterio che consenta di eseguire logonui.exe e userinit.exe da %windir%\system32. La maggior parte degli utenti richiederà probabilmente che venga consentita l'esecuzione anche delle seguenti applicazioni:

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

Se si desidera utilizzare la shell di Windows predefinita, è opportuno aggiungere anche %windir%\explorer.exe.

In alternativa, è possibile scegliere di eseguire l'avvio direttamente da un'applicazione, come Internet Explorer®. In tal caso, sarà necessario elencare iexplore.exe anziché explorer.exe.

Un altro aspetto di questi criteri di base è che gli utenti non devono essere membri del gruppo Administrators. Questo requisito è importante in quanto impedisce che il criterio venga ignorato dagli utenti. Tuttavia, poiché possono eseguire solo un insieme di applicazioni di base e non dispongono di privilegi di amministratore, gli utenti non disporranno neppure dei privilegi necessari per installare le applicazioni o gestire il sistema.

Pertanto, per eseguire queste attività per i computer in questione, sarà necessario disporre di metodi specifici. Se si intende aggiornare e gestire questi computer eseguendo l'accesso localmente con un account di amministratore, è consigliabile selezionare il pulsante di opzione che prevede l'applicazione dei criteri di restrizione software a tutti gli utenti eccetto gli amministratori locali. I criteri devono includere anche consent.exe e cmd.exe. Questo consentirà all'amministratore di avviare qualsiasi opzione di amministrazione da un prompt cmd con privilegi di amministratore.

Notare che la funzionalità Controllo dell'account utente, per impostazione predefinita, limita i privilegi del token di sicurezza dell'utente in modo da dare l'impressione che il token non sia membro del gruppo Administrators. Anche se si configura l'impostazione sopra riportata in modo che il criterio non venga applicato agli amministratori, tale criterio verrà comunque applicato agli utenti. Solo quando si utilizza la funzionalità di elevazione dei privilegi di Controllo dell'account utente, l'amministratore potrà disporre di privilegi di amministratore completi e il criterio di restrizione software non verrà applicato.

Chris CorioChris Corio è stato membro del team Windows Security in Microsoft per oltre cinque anni. I suoi interessi si rivolgono principalmente al campo delle tecnologie di sicurezza delle applicazioni e delle tecnologie di gestione per la sicurezza di Windows. È possibile contattare Chris all'indirizzo winsecurity@chriscorio.com.

Durga Prasad SayanaDurga Prasad Sayana è Software Design Engineer responsabile dei test nel team Windows Core Security. I suoi interessi si rivolgono principalmente al campo delle tecnologie di sicurezza e dei test del software. È possibile contattare Durga all'indirizzo durgas@microsoft.com.

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