Considerazioni sulla sicurezza per AppLocker

Si applica a

  • Windows 10
  • Windows Server

Questo argomento per il professionista IT descrive le considerazioni di sicurezza che è necessario affrontare durante l'implementazione di AppLocker.

Lo scopo di AppLocker è limitare l'accesso al software e quindi ai dati a cui si accede dal software, a un gruppo specifico di utenti o all'interno di un gruppo aziendale definito. Di seguito sono riportate le considerazioni sulla sicurezza per AppLocker:

AppLocker viene distribuito all'interno di un'organizzazione e gestito centralmente da coloro che hanno credenziali attendibili. In questo modo la creazione e la distribuzione dei criteri sono conformi ai processi di distribuzione e alle restrizioni di sicurezza simili.

I criteri di AppLocker vengono distribuiti tramite i processi noti e i mezzi noti all'interno del dominio tramite criteri di gruppo. Tuttavia, i criteri di AppLocker possono essere impostati anche sui singoli computer se la persona ha privilegi di amministratore e questi criteri potrebbero essere contrari ai criteri di sicurezza scritti dell'organizzazione. Le impostazioni di imposizione per i criteri locali vengono ignorate dagli stessi criteri di AppLocker in un oggetto Criteri di gruppo. Tuttavia, poiché le regole di AppLocker sono additive, un criterio locale che non si trova in un GPO verrà comunque valutato per tale computer.

Microsoft non offre un modo per sviluppare le estensioni di 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 informazioni sui cmdlet di Windows PowerShell per AppLocker, vedere i cmdlet di AppLocker in Windows PowerShell.

AppLocker viene eseguito nel contesto di Administrator o LocalSystem, che rappresenta il set di privilegi più elevato. Questo contesto di sicurezza ha il potenziale di un uso improprio. Se un utente con credenziali amministrative apporta modifiche a un criterio di AppLocker in un dispositivo locale Unito a un dominio, tali modifiche potrebbero essere sovrascritte o non consentite dall'oggetto Criteri di controllo che contiene la regola di AppLocker per lo stesso file (o percorso) modificato nella dispositivo locale. Tuttavia, poiché le regole di AppLocker sono additive, un criterio locale che non si trova in un GPO verrà comunque valutato per tale computer. Se il computer locale non è associato a un dominio e non viene gestito da criteri di gruppo, una persona con credenziali amministrative può modificare i criteri di AppLocker.

Quando si proteggono i file in una directory con una regola del tipo di condizione path, se si usa l'azione Consenti o nega sulla regola, è comunque necessario e buona prassi limitare l'accesso a tali file impostando gli elenchi di controllo di accesso (ACL) in base alla propria sicurezza. criteri.

AppLocker non protegge dall'eseguire binari DOS a 16 bit nella macchina virtuale DOS (NTVDM). Questa tecnologia consente l'uso di programmi Windows legacy e a 16 bit in computer che usano Intel 80386 o versione successiva quando esiste già un altro sistema operativo che esegue e controlla l'hardware. Il risultato è che i file binari a 16 bit possono ancora essere eseguiti in Windows Server2008R2 e Windows7 quando AppLocker è configurato per bloccare in altro modo binari e raccolte. Se si tratta di un requisito per impedire l'utilizzo delle applicazioni a 16 bit, è necessario configurare la regola Deny nella raccolta di regole eseguibili per NTVDM. exe.

Non è possibile usare AppLocker (o criteri di restrizione software) per evitare che il codice venga eseguito all'esterno del sottosistema Win32. In particolare, questo si applica al sottosistema (POSIX) in WindowsNT. Se si tratta di un requisito per impedire l'applicazione delle applicazioni nel sottosistema POSIX, è necessario disabilitare il sottosistema.

AppLocker può controllare solo i file di VBScript, JScript, bat, cmd e 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 è una forma di codice eseguibile 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 tramite AppLocker, il processo host deve chiamare AppLocker prima di eseguire il codice interpretato e quindi applicare la decisione restituita da AppLocker. Non tutti i processi host chiamano AppLocker e, di conseguenza, AppLocker non può controllare tutti i tipi di codice interpretato, ad esempio le macro di Microsoft Office.

Importante: è consigliabile configurare le impostazioni di sicurezza appropriate di questi processi host se è necessario consentirne l'esecuzione. Ad esempio, configurare le impostazioni di sicurezza in Microsoft Office per verificare 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 che sono state avviate. Le applicazioni possono contenere contrassegni passati a funzioni che segnalano a AppLocker di eludere le regole e consentire il caricamento di un altro exe o dll. In pratica, un'applicazione consentita da AppLocker può usare questi contrassegni per aggirare le regole di AppLocker e avviare processi figlio. È necessario esaminare accuratamente ogni applicazione prima di consentire l'esecuzione tramite le regole di AppLocker.

Nota: due contrassegni che illustrano questa condizione SANDBOX_INERTsono, a CreateRestrictedTokencui è possibile passare e LOAD_IGNORE_CODE_AUTHZ_LEVELa cui è possibile passare LoadLibraryEx. Entrambi i flag segnalano AppLocker per eludere le regole e consentire il caricamento di un elemento figlio. exe o dll.

Puoi bloccare il sottosistema Windows per Linux bloccando LxssManager. dll.

Argomenti correlati