File desktopCome sbarazzarsi del ruolo di amministratore

Wes Miller

Più di tre anni fa, ho iniziato il processo di conversione del mio account utente sul sistema Windows primario da amministratore locale ad utente locale. Lavoro alla Microsoft da più di sette anni, utilizzando sempre l'esecuzione come amministratore provvisto di tutti i privilegi. Certamente tale situazione era conveniente, ma quella terribile mancanza di sicurezza

evidenzia la fortuna sorprendente che ho avuto (insieme a molti altri utenti), dovuta al fatto che attualmente l'esecuzione costante come amministratore non è più pericolosa come un tempo.

Spesso mi sarebbe piaciuto raccogliere delle valide statistiche su questa situazione, ma il mio istinto e il mio impegno mi suggeriscono che troppe organizzazioni e troppi professionisti dell'IT utilizzano attualmente l'esecuzione come amministratori locali. Alla Winternals, quando ho iniziato ad utilizzare l'esecuzione come utente, la premessa era capire quanto ciò fosse difficile, in qualità di "prosumer" (ovvero di professional-consumer), e acquisire informazioni su come il nostro prodotto, Winternals Protection Manager, potesse fornire supporto in un'organizzazione di medie dimensioni. Dal momento che la maggior parte delle organizzazioni utilizzavano, e utilizzano ancora, una buona percentuale di utenti come amministratori, il nostro obiettivo era consentire agli amministratori di operare come utenti, rendendo la transizione (o almeno i punti salienti) più semplice possibile. Indipendentemente dalla tecnologia utilizzata, non è semplice convertire la propria organizzazione da un contesto in cui gli utenti sono amministratori ad un contesto in cui sono utenti, ma è l'unica maniera efficace ridurre la superficie di attacco all'interno dell'organizzazione stessa. Si pensi ad essa come ad un firewall interno al sistema, perché è questa la sua natura.

Come siamo giunti fin qui?

La mia sfida per voi: toccare con mano il problema

Se non avere ancora pensato alla conversione dei vostri amministratori in utenti, dovreste iniziare a farlo. E vi consiglio di iniziare da voi. Non su un computer secondario...così non vale! Provate a farlo sul vostro sistema primario, quello che utilizzate ogni giorno. Vi invito inoltre a provare senza utilizzare il Controllo dell'account utente (UAC) se disponete di Windows Vista®. Quando iniziate a diffondere la volontà di cambiamento all'interno della vostra organizzazione, è una buona idea esporsi in prima persona. Penso che vi renderete conto che l'utilizzo dell'esecuzione come non amministratore non è poi così difficile e che, grazie alla maggiore sicurezza garantita da tale cambiamento, riuscirete realmente a modificare la superficie di attacco della vostra organizzazione.

Nella storia di Windows® è dimostrato chiaramente che la maggior parte degli utenti operano come amministratori. Con le prime versioni di Windows, prima di Windows NT® 3.1, ogni utente interattivo disponeva degli stessi privilegi del successivo; a livello funzionale, non vi era alcuna sicurezza. In un ambiente familiare, questo scenario non era poi così terribile; significava soltanto che tutto il software veniva installato nello stesso modo. Il presupposto era che l'utente fosse il proprietario del computer e che tutto il software venisse installato per tutti gli utenti di tale computer.

Quando fece la sua comparsa Windows NT, non conquistò immediatamente il mercato aziendale (senza parlare del consumatore). E, in virtù della compatibilità Win32® tra Windows a 32 bit e Windows NT, la maggior parte dei fornitori di applicazioni non ha ricostruito le proprie applicazioni proprio per l'infrastruttura di sicurezza di Windows NT. In effetti, è stato soltanto con Windows 2000 che diversi fornitori di software indipendenti orientati al consumatore hanno iniziato a prestare attenzione a Windows NT. Ovviamente è stato proprio Windows XP che ha sollevato il problema, poiché è stato l'ultimo della famiglia 9x di Windows.

Tuttavia, sono state create diverse applicazioni, presupponendo che ogni utente sul sistema disponesse dell'accesso di scrittura su Programmi (gli utenti non hanno tale accesso), HKEY_LOCALE_LA COMPUTER (HKLM) nel Registro di sistema (gli utenti non hanno tale accesso) e HKEY_LE CLASSI_LA RADICE (gli utenti non hanno tale accesso). Generalmente, i giochi sono i peggiori colpevoli quando si parla di accesso. A tal proposito, si rimanda all'articolo di Matt Clapham disponibile all'indirizzo technetmagazine.com/issues/2007/02/Gaming.

Questa situazione è problematica poiché la maggior parte delle applicazioni per più sistemi memorizzano i relativi file e impostazioni del Registro di sistema in tali percorsi e, per installarle, è necessario disporre dell'accesso in lettura e scrittura per tali percorsi. Sfortunatamente, alcune applicazioni richiedono la scrittura in tali chiavi dopo l'installazione. Ad esempio, mia figlia possiede un gioco basato su Flash. Ogni volta che viene eseguito, tale gioco tenta di installare un giocatore personalizzato, il che significa che quando mia figlia utilizza il ruolo di utente e non di amministratore, l'applicazione non viene avviata e restituisce un errore fatale. Sebbene questo sia un caso estremo e riguardi l'applicazione di un consumatore, la realtà è che molte delle applicazioni di non consumatori non possono essere utilizzate in modo adeguato nel mondo degli utenti non amministrativi. In effetti, se si prosegue nella mia sfida (consultare la barra laterale "La mia sfida per voi: toccare con mano il problema), si scoprirà quanto Windows stesso non sia tollerante nei confronti dell'esecuzione come utente.

Se si esamina la Figura 1, si noterà che l'esecuzione di IPConfig /release come utente è simile su Windows XP. Se si confronta tale scenario con quello della Figura 2, si noterà che lo stesso comando in Windows Vista non ottiene poi risultati migliori, ma almeno si capisce perché il comando non riesce. Tenere presente che gli strumenti di rete nell'insieme sono stati migliorati per consentire agli utenti di aggiornare i propri indirizzi IP. In modo analogo, se si tenta la Gestione computer (compmgmt.msc) come utente in qualsiasi versione, è possibile eseguire un numero limitato di attività, che generalmente terminano con frustranti vicoli ciechi, come mostrato nella Figura 3. Sebbene Windows Vista non consenta inizialmente molti degli strumenti di Gestione computer, non presenta messaggi più chiari di accesso negato.

Figura 1** Esecuzione come utente in Windows XP **(Fare clic sull'immagine per ingrandirla)

Figura 2** Esecuzione come utente in Windows Vista **(Fare clic sull'immagine per ingrandirla)

Figura 3** Messaggio fuorviante dopo l'esecuzione di compmgmt.msc come utente su Windows XP **(Fare clic sull'immagine per ingrandirla)

Motivi dell'importanza dell'esecuzione come utente

Perché la questione dovrebbe interessarci? Perché, in qualità di professionisti dell'IT, dovremmo iniziare a forzare le applicazioni per adattarle ad utenti con meno privilegi, anziché fare il contrario, ovvero lasciare che le applicazioni suppongano che l'utente interattivo sia il proprietario del sistema.

Sfortunatamente, gli stessi criteri che consentono degli amministratori di scrivere nelle chiavi del Registro di sistema concedono anche a qualunque malware eseguito nel relativo contesto utente l'accesso totale a tutti i contesti che non sono stati esplicitamente negati tramite gli elenchi di controllo degli accessi (ACL). Nel mondo di UNIX, gli utenti rispettano la regola che impone di non utilizzare l'esecuzione come utente root (l'equivalente funzionale dell'account Amministratore di Windows), soprattutto perché l'ecosistema di software che supera i limiti del modello di sicurezza è praticamente inesistente.

Tuttavia, la regola più saggia da seguire è fidarsi del buon senso e utilizzare l'esecuzione come amministratore soltanto quando è strettamente necessario, o ancora meglio, eseguire unicamente singole applicazioni come amministratore. In questo modo, si erige il firewall interno al sistema citato poc'anzi. E quindi, quando un malware o spyware tenta di accedere al sistema, non riesce a farlo, poiché non può scrivere nei percorsi del Registro di sistema o del file system necessari per infettare il sistema (ad esempio, installando un servizio o un driver o eseguendo un'installazione per tutti gli utenti). In più, in questo modo aumentano le probabilità che il software anti-malware riconosca il malware e gli impedisca di accedere all'intero sistema.

Tenere presente, tuttavia, che gli utenti non sono immuni dagli attacchi. Nonostante questa classe di malware non sia molto diffusa, esiste un elevato potenziale che infetti il contesto di un singolo utente individuale o distrugga i suoi dati. Ma il vettore di attacco rappresentato da tale software è limitato. Di conseguenza, lo stesso elemento che limita le istanze di malware su Linux o Macintosh (il numero più basso di vittime potenziali rendono tale sistema appetibile per gli autori di malware) può garantire attualmente la protezione generale dei vostri utenti finali e di voi stessi.

Eliminati anche i Power User?

Mentre sviluppavamo Protection Manager, uno dei commenti dei clienti era: "Attualmente eseguiamo Windows XP con tutti i nostri utenti come Power User, non come amministratori, quindi siamo al sicuro!" La realtà, tuttavia, è che i Power User non sono molto diversi dagli amministratori. Pochi sono i passi che consentono, con attività minime, ad un Power User in Windows XP di diventare un amministratore. Infatti, il gruppo Power User è stato eliminato in Windows Vista e Windows Server® 2008; soltanto un sistema aggiornato da una versione precedente di Windows disporrà di tale gruppo. Tutto sommato, è preferibile non utilizzare mai il gruppo Power User, neanche se si utilizza Windows XP.

Autorizzazioni pericolose

Nella mia rubrica di marzo sui thin client Windows (technetmagazine.com/issues/2008/03/DesktopFiles), ricorderete che ho mostrato parere contrario nei confronti della prospettiva di ridurre Windows XP per risparmiare spazio. Con lo stesso spirito, è una pratica diffusa consentire la conversione degli amministratori in utenti, ma è consigliabile eseguire questa procedura con cautela. Si tratta della modifica degli ACL sul Registro di sistema e sul file system per consentire gli utenti di scrivere in percorsi generalmente a loro vietati, abilitando così applicazioni problematiche.

Ovviamente, la soluzione migliore consiste nell'ottenere una versione aggiornata di un'applicazione che non richiede tale modifica, ma ciò non è sempre possibile. Se occorre modificare le autorizzazioni (eliminandole), procedere con estrema cautela. Tenere a mente che il firewall tra un utente e un amministratore è definito ampiamente dalle autorizzazioni di Registro di sistema e file system. La loro concessione riduce la vostra protezione e potenzialmente amplia la superficie di attacco rappresentata dal malware, quindi è bene essere molto prudenti.

E per quanto riguarda UAC?

Non si può parlare della transizione da amministratori ad utenti senza affrontare il Controllo dell'account utente (UAC) in Windows Vista. UAC, presente anche su Mac OS X, consente l'esecuzione come amministratore senza troppi rischi.

Come funziona tale controllo? Esaminiamo la Figura 4 e i dati mostrati da Process Explorer relativamente a cmd.exe. L'istanza di cmd.exe sulla destra è stata avviata senza elevazione: ho utilizzato l'esecuzione come amministratore. Di conseguenza, anche se l'utente sulla destra è identico all'utente sulla sinistra (in cui cmd.exe è stato avviato con elevazione), l'applicazione stessa non contiene i privilegi e i token necessari per consentire all'utente che esegue tale istanza di svolgere delle attività che richiedano diritti amministrativi. UAC riduce la superficie di attacco all'interno del contesto interattivo dell'utente. L'unico problema è costituito dal fatto che Windows non sa che questa attività richiede privilegi di amministratore e che l'utente può ricevere l'elevazione richiesta per completarla.

Figura 4** Due istanze di cmd.exe con privilegi diversi **(Fare clic sull'immagine per ingrandirla)

I piccoli scudi in Windows Vista mostrano le attività che richiedono elevazione (vedere la Figura 5). Tali attività richiedono elevazione ogni volta che vengono eseguite e questo è uno dei punti dolenti evidenziati dalla stampa relativamente a Windows Vista. L'alternativa, ovvero un rafforzamento delle credenziali, pone una potenziale minaccia alla sicurezza, che potrebbe essere utilizzata per sfruttare più facilmente il sistema.

Figura 5** Gli scudi in Windows Vista indicano che è richiesta un'elevazione **(Fare clic sull'immagine per ingrandirla)

Se UAC è attivato e i propri utenti scelgono un'esecuzione come utenti, verrà loro richiesta una serie di credenziali amministrative quando un'applicazione richiede privilegi di questo tipo. In questo caso, come nel caso dell'utilizzo di runas o psexec, l'applicazione viene eseguita letteralmente nel contesto dell'utente che l'ha avviata e non nel contesto dell'amministratore come avviene in UAC. L'attività viene quindi eseguita nel proprio contesto ma con privilegi elevati.

Esecuzione di Windows Vista come utente?

Personalmente, prediligo l'esecuzione di Windows Vista come utente, non come amministratore con UAC, poiché ritengo che questa sia l'idea migliore nell'azienda di medie dimensioni. Dopo tutto, gli utenti hanno controllo totale dei loro sistemi ed è possibile ridurre le opportunità di attacchi malware.

Inoltre, se si intende gestire i propri utenti con politiche di gruppo, anti-virus, anti-malware o un altro software e si desidera un controllo centrale sull'eventuale applicazione o completamento di tali attività, occorre senza dubbio garantire che i propri utenti finali non siano amministratori. Gli utenti amministratori possono arrestare i servizi, aggiungere o rimuovere driver e non solo. Ovviamente, un utente finale astuto può utilizzare Windows PE per eludere alcuni ostacoli della sicurezza. BitLocker® può rendere tale operazione più difficile ma, ancora una volta, è bene tenere presente che gli utenti finali con accesso fisico sono padroni assoluti del loro PC e possono disporne nel modo che preferiscono, fermo restando il tempo, l'esperienza e l'impegno in tal senso.

L'esecuzione di Windows Vista come utente non è poi così diversa dall'esecuzione di Windows XP come utente. Personalmente utilizzo gli stessi strumenti, ovvero PSExec, RunAs e ora anche UAC, per eseguire le attività come amministratore, laddove necessario. L'aspetto interessante è che le poche attività che in Windows XP richiedevano privilegi di amministratore ora non li richiedono più. Ad esempio, un utente di Windows Vista può installare una stampante locale. In Windows XP, gli utenti potevano installare le stampanti di rete ma non una stampante locale, attività per la quale erano richiesti privilegi di amministratore. In Windows Vista, se l'utente si trova fisicamente davanti al PC e il driver della stampante è presente nell'archivio driver, tale utente può installare una stampante e gestire i processi di stampa su tale periferica. Per ulteriori informazioni, consultare go.microsoft.com/fwlink/?LinkId=111534). Tenere presente che questa funzionalità è disabilitata in Windows Server 2008.

Ovviamente, gli utenti "si prendono gioco" della funzionalità dell'orologio (o della sua assenza) in Windows XP. Provate a fare doppio clic sull'orologio come utente (spesso si esegue tale azione per visualizzare la data, indipendentemente dal fatto che tale funzionalità non sia stata concepita per tale scopo) e riceverete l'errore mostrato nella Figura 6. Non molto simpatico... In Windows XP, è possibile modificare i criteri per consentire all'utente di svolgere tale operazione, mentre in Windows Vista questo non è necessario perché la suddetta funzione è stata concepita esattamente per l'uso che la maggior parte degli utenti ne fa. Quindi alla fine, l'esecuzione come utente, indipendentemente dal fatto che si utilizzi UAC o l'esecuzione come utente formale e l'elevazione come un altro utente, è generalmente più supportata in Windows Vista di quanto non lo fosse in Windows XP.

Figura 6** In Windows XP, gli utenti non amministratori non possono cambiare l'ora **(Fare clic sull'immagine per ingrandirla)

Consapevolezza dei limiti

Non dimenticare mai che l'esecuzione come utenti non amministratori non è una panacea. Gli utenti finali appassionati utilizzano fisicamente il proprio PC e lavorano diligentemente per sfruttare al meglio i propri sistemi, soprattutto se i privilegi di criteri o di utente creano degli inconvenienti o impediscono loro di completare un'attività.

Se i propri utenti utilizzano l'esecuzione come amministratori, non è difficile eludere i vari criteri di gruppo in uso. Senza dubbio, con un po' più di ingegno, gli utenti possono eseguire l'avvio in Windows PE e modificare le autorizzazioni per le quali normalmente non dispongono di privilegi sebbene, se si utilizza BitLocker o un'altra codifica di unità/volumi, è possibile impedire tale pratica o comunque renderla particolarmente complicata.

La soluzione migliore da adottare nel caso in cui la propria organizzazione non abbia ancora iniziato la transizione degli utenti finali verso l'esecuzione come utenti è acquisire familiarità con i motivi per cui è consigliabile dedicare tempo, denaro e impegno in tale attività, abbandonando l'esecuzione come amministratori.

Certamente, non tutte le applicazioni legacy consentono l'esecuzione come utenti, ma continuare ad utilizzare tali applicazioni equivale a sottoporre la propria organizzazione a minacce di violazione della sicurezza. È bene considerare la possibilità di una virtualizzazione dell'applicazione, spostandola letteralmente in una Virtual Machine in cui l'utente è un amministratore. In questo modo l'applicazione può essere utilizzata nei casi di necessità, senza compromettere la sicurezza del resto del sistema grazie alla conversione da amministratori ad utenti.

Si tenga presente che in questa rubrica non ho utilizzato il termine "blocco" né i relativi derivati. Molte persone considerano il passaggio da amministratori ad utenti parte di un'attività che viene spesso descritta utilizzando il suddetto termine. Sarà probabilmente a causa del mio background psicologico o del mio universo di marketing attuale, ma ritengo sia importante non utilizzare parole che diano agli utenti finali la sensazione che vengano loro tolti dei privilegi (anche se, a livello semantico, è così).

Preferisco sia più corretto sottolineare i vantaggi in termini di sicurezza per l'organizzazione e garantire la presenza di un valido piano per i casi limite in cui non è assolutamente consentita l'esecuzione come utente o in cui una specifica attività richiede privilegi di amministratore. Quando si utilizza un elemento manuale, come il mio script Run.vbs (disponibile in technetmagazine.com/issues/2007/03/DesktopFiles) o una soluzione commerciale per facilitare la transizione (in modo da nascondere i dettagli agli utenti finali e far funzionare semplicemente le cose), è importante concentrarsi da subito sull'attuazione della transizione da amministratore ad utente. Assiduo collaboratore di TechNet Magazine, Aaron Margosis è un sostenitore dell'esecuzione come non amministratore. Se non conoscete il suo blog, è un vero peccato! È la fonte più completa di informazioni sull'argomento (blogs.msdn.com/aaron_margosis). 

Wes Miller è attualmente un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.

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