Considerazioni sulla sicurezza per AppLocker
Questo argomento, destinato ai professionisti IT, descrive le considerazioni sulla sicurezza che dovrai prendere in considerazione per l'implementazione di AppLocker.
AppLocker ha lo scopo di limitare l'accesso al software e, di conseguenza, ai dati a cui tale software ha accesso, a un gruppo specifico di utenti oppure all'interno di un gruppo aziendale definito. Ecco alcune considerazioni sulla sicurezza per AppLocker:
AppLocker è distribuito all'interno di un'organizzazione e viene amministrato a livello centralizzato da personale IT con credenziali attendibili. In questo modo la creazione e la distribuzione dei criteri sono conformi a processi di distribuzione dei criteri e restrizioni di sicurezza simili.
I criteri di AppLocker vengono distribuiti tramite processi e strumenti noti all'interno del dominio tramite i Criteri di gruppo. Tuttavia, i criteri di AppLocker possono essere impostati anche nei singoli computer se l'utente dispone dei privilegi di amministratore, anche se tali criteri potrebbero essere in conflitto con i criteri di sicurezza scritti dell'organizzazione. Le impostazioni di imposizione per i criteri locali vengono sovrascritte dagli stessi criteri di AppLocker in un oggetto Criteri di gruppo. Tuttavia, dato che le regole di AppLocker sono additive, i criteri locali non inclusi in un oggetto Criteri di gruppo vengono comunque valutati per il computer.
Microsoft non fornisce uno strumento per sviluppare estensioni per AppLocker. Le interfacce non sono pubbliche. Un utente con credenziali di amministratore può automatizzare alcuni processi di AppLocker usando i cmdlet di Windows PowerShell. Per info sui cmdlet di Windows PowerShell per AppLocker, vedi l'articolo relativo ai cmdlet di AppLocker in Windows PowerShell.
AppLocker viene eseguito nel contesto di Administrator o LocalSystem, ovvero il set di privilegi più elevato. Questo contesto di protezione può potenzialmente venire usato in modo improprio. Se un utente con credenziali amministrative apporta modifiche ai criteri di AppLocker in un dispositivo locale aggiunto a un dominio, queste modifiche potrebbero essere sovrascritte o non consentite dall'oggetto Criteri di gruppo contenente la regola di AppLocker per lo stesso file (o percorso) modificato nel dispositivo locale. Tuttavia, dato che le regole di AppLocker sono additive, i criteri locali non inclusi in un oggetto Criteri di gruppo vengono comunque valutati per il computer. Se il computer locale non viene aggiunto a un dominio e non è gestito tramite Criteri di gruppo, un utente con credenziali amministrative può modificare i criteri di AppLocker.
Quando i file in una directory vengono protetti con una regola della condizione Percorso, indipendente dall'uso dell'azione di autorizzazione o di negazione nella regola, è comunque necessario e consigliabile limitare l'accesso a tali file mediante l'impostazione degli elenchi di controllo di accesso (ACL) in base ai criteri di sicurezza definiti.
AppLocker non applica alcuna protezione per l'esecuzione di file binari DOS a 16 bit in una macchina DOS virtuale (NTVDM). Questa tecnologia consente di eseguire programmi DOS legacy e programmi Windows a 16 bit in computer che usano un processore Intel 80386 o superiore quando è già presente un altro sistema operativo in esecuzione per il controllo dell'hardware. Il risultato è che i file binari a 16 bit possono comunque essere eseguiti in Windows Server 2008 R2 e Windows 7 anche quando AppLocker è configurato per bloccare file binari e librerie. Se impedire l'esecuzione delle applicazioni a 16 bit rappresenta un requisito, devi configurare la regola di negazione nella raccolta regole eseguibili per NTVDM.exe.
Non puoi usare AppLocker (o i criteri di restrizione software) per impedire l'esecuzione del codice esternamente al sottosistema Win32. In particolare, ciò è valido per il sottosistema (POSIX) in Windows NT. Se impedire l'esecuzione delle applicazioni nel sottosistema POSIX rappresenta un requisito, devi disabilitare il sottosistema.
AppLocker può controllare solo file VBScript, JScript, BAT e CMD, nonché script di Windows PowerShell. Non controlla tutto il codice interpretato eseguito all'interno di un processo host, ad esempio script Perl e macro. Il codice interpretato è un tipo di codice eseguibile che viene eseguito all'interno di un processo host. Ad esempio, i file batch di Windows (*.bat) vengono eseguiti nel contesto dell'host dei comandi di Windows (cmd.exe). Per controllare il codice interpretato mediante AppLocker, il processo host deve chiamare AppLocker prima dell'esecuzione del codice interpretato e quindi applicare la decisione restituita da AppLocker. Non tutti i processi host chiamano AppLocker e, di conseguenza, AppLocker non può controllare qualsiasi tipo di codice interpretato, ad esempio le macro di Microsoft Office.
Importante
Se devi consentirne l'esecuzione, devi configurare le impostazioni di sicurezza appropriate di questi processi host. Ad esempio, puoi configurare le impostazioni di sicurezza di Microsoft Office per garantire che vengano caricate solo le macro firmate e attendibili.
Le regole di AppLocker consentono o impediscono l'avvio di un'applicazione. AppLocker non controlla il comportamento delle applicazioni dopo il loro avvio. Le applicazioni possono contenere flag passati a funzioni che segnalano ad AppLocker di ignorare le regole e consentire il caricamento di un altro file EXE o DLL. In pratica, un'applicazione consentita da AppLocker può usare questi flag per ignorare le regole di AppLocker e avviare processi figlio. Devi esaminare attentamente ogni applicazione prima di consentirne l'esecuzione mediante le regole di AppLocker.
Nota
I due flag che illustrano questa condizione sono SANDBOX_INERT, che può essere passato a CreateRestrictedToken, e LOAD_IGNORE_CODE_AUTHZ_LEVEL, che può essere passato a LoadLibraryEx. Entrambi questi flag segnalano ad AppLocker di evitare le regole e consentire il caricamento di un file EXE o DLL figlio.