• Cloud, Guide, Microsoft 365, Sicurezza
• 5 Maggio 2026

Quando si introduce WinGet in un modello di application lifecycle management, il vantaggio si vede subito: meno attività manuali nella gestione delle versioni, meno repackaging ripetitivo e una maggiore flessibilità nella distribuzione e nell’aggiornamento delle applicazioni. Questo approccio diventa particolarmente utile quando si lavora con Microsoft Intune e si vogliono costruire app Win32 evergreen, cioè pacchetti in grado di installare o aggiornare il software facendo riferimento a una logica più dinamica rispetto al classico installer statico.

Fin qui tutto bene. Il tema arriva subito dopo, quando la stessa CLI che utilizziamo per i deployment gestiti resta disponibile anche all’utente finale. Se winget.exe è utilizzabile da prompt, un utente può cercare, installare o aggiornare applicazioni presenti nelle sorgenti disponibili sul client. In un ambiente aziendale questo aspetto non può essere lasciato al caso, perché rischia di trasformare uno strumento utile per l’IT in un canale non governato per introdurre software fuori standard.

Nel mio scenario di partenza il requisito era molto preciso: mantenere attiva la policy Enable Windows Package Manager command line interfaces, perché il modello evergreen basato su WinGet deve continuare a funzionare, ma impedire allo stesso tempo che l’utente standard possa usare la CLI manualmente per installare ciò che vuole. Questa policy, gestita tramite il CSP DesktopAppInstaller, lavora a livello device: se viene disabilitata, l’uso della CLI WinGet e dei cmdlet PowerShell del Windows Package Manager viene bloccato; se resta abilitata o non configurata, la CLI rimane disponibile, a condizione che non sia stato disabilitato anche App Installer. Per uno scenario enterprise basato su WinGet, quindi, questa leva da sola non basta. Potete trovare i riferimenti di queste impostazioni alle seguenti pagine ICT Power:

• WinGet: distribuzione e governance con Microsoft Intune
• WinGet: creare app Win32 evergreen con Microsoft Intune

In questo articolo vedremo quindi come affrontare il problema dal punto di vista operativo, usando AppLocker. Faremo solo un breve confronto con App Control for Business, perché è una tecnologia che viene spesso associata a questi scenari, ma che in questo caso non offre la granularità necessaria per distinguere tra utente interattivo e contesto System. L’obiettivo è bloccare l’uso manuale di Microsoft.DesktopAppInstaller agli utenti standard, lasciando invece funzionare i deployment Win32 eseguiti da Intune in contesto System. Vedremo anche cosa aspettarci lato utente, quali log controllare e quali errori evitare, perché con le policy di application control basta poco per bloccare più del previsto.

Disclaimer

Prima di procedere con la configurazione, proviamo a chiarire il perimetro tecnico di questa guida. Quando usiamo WinGet con Intune non stiamo controllando una normale applicazione Win32 installata in un percorso classico come C:\Program Files. WinGet è incluso in App Installer, cioè nel pacchetto Microsoft.DesktopAppInstaller, e rientra quindi nel mondo delle packaged apps. Questo cambia il modo in cui dobbiamo impostare il controllo. Se proviamo a gestirlo come un semplice .exe, rischiamo di costruire una regola poco efficace o, peggio, troppo ampia, con effetti collaterali su componenti che non volevamo toccare.

C’è poi un secondo aspetto da tenere presente, ovvero il contesto di esecuzione delle app Win32 distribuite da Intune. Un’app può essere installata in contesto User oppure System. Nel nostro scenario il contesto System è fondamentale, perché consente al deployment gestito di restare separato dall’utente interattivo. L’installazione viene eseguita dal servizio e non dipende dalla sessione dell’utente, anche se il comportamento finale resta sempre legato a come è stato progettato l’installer.

Questa distinzione è alla base di tutta la configurazione: WinGet deve continuare a funzionare per i deployment gestiti da Intune in contesto System, ma non deve essere utilizzabile liberamente dall’utente standard da prompt o PowerShell. Da qui nasce la necessità di controllare Microsoft.DesktopAppInstaller nel modo corretto, senza bloccare l’intero meccanismo applicativo del client.

Importante: bloccare Microsoft.DesktopAppInstaller con AppLocker non significa bloccare automaticamente gli aggiornamenti delle app Microsoft Store. La regola che creeremo nella demo di questo articolo impedisce agli utenti standard di usare App Installer e WinGet in modo interattivo, ma lascia consentite le altre packaged app firmate grazie alla default allow rule della collection, che vedremo più avanti. Gli aggiornamenti gestiti dal Microsoft Store continueranno a funzionare, mentre non sarà più possibile per l’utente standard aggiornare applicazioni tramite comandi WinGet (come winget upgrade).

Differenze tra AppLocker e App Control for Business

Nell’introduzione abbiamo citato sia AppLocker sia App Control for Business, ed è utile chiarire che non sono due modi equivalenti per fare la stessa configurazione.

Entrambe rientrano nel perimetro dell’application control su Windows, ma lavorano con logiche diverse. App Control for Business è pensato per controllare il codice che può essere eseguito sul dispositivo nel suo insieme. È la scelta più adatta quando l’obiettivo è costruire un perimetro di trusted code valido per tutta la macchina, con scenari più avanzati come kernel mode, Managed Installer, Intelligent Security Graph e policy multiple. Le policy App Control si applicano al computer nel suo complesso e coinvolgono tutti gli utenti del device.

AppLocker, invece, resta molto utile quando dobbiamo differenziare il comportamento in base all’utente o al gruppo. Può controllare eseguibili, Windows Installer, script, DLL se abilitate, packaged app e packaged app installer. La caratteristica che in questo scenario ci interessa di più è la possibilità di applicare regole a utenti o gruppi specifici. Qui non vogliamo bloccare WinGet a livello device: vogliamo impedirne l’uso interattivo agli utenti standard, lasciando funzionare i deployment gestiti in contesto System

Tabella 1: Tabella comparativa AppLocker vs App Control for Business

La differenza più importante, per il nostro caso, è la gestione del target. Se creo una deny rule con App Control for Business, quella regola vale per il device. Non distingue tra utente interattivo, processo eseguito da Intune o contesto System. Questo è il motivo per cui una deny sull’app finale, ad esempio Google Chrome, può bloccare anche il deployment Intune della stessa applicazione se il package evergreen usa WinGet per installarla.

Con AppLocker, invece, possiamo lavorare su Microsoft.DesktopAppInstaller e applicare la deny solo agli utenti standard. In questo modo il componente che include App Installer e WinGet viene bloccato per l’uso interattivo dell’utente, mentre i deployment Win32 configurati in Intune con Install behavior = System continuano a usare il proprio flusso gestito. Ed è esattamente la separazione che ci serve in questo articolo: non vogliamo dire “questa applicazione non deve mai girare su questo dispositivo“, ma “l’utente standard non deve usare WinGet come canale libero di installazione“.

Prerequisiti per AppLocker

Prima di creare la regola su Microsoft.DesktopAppInstaller, chiariamo bene i prerequisiti. AppLocker è una tecnologia molto efficace per questo scenario ma va configurata con attenzione, poiché se si interviene sulla collection sbagliata o si passa subito in enforcement senza una base di regole corretta, il rischio è bloccare più applicazioni del previsto. Per questa guida utilizzeremo AppLocker solo per controllare App Installer (WinGet) tramite la collection Packaged app Rules. Non toccheremo quindi le Executable Rules, le Windows Installer Rules o le Script Rules, a meno che non siano già presenti nel vostro ambiente e debbano essere gestite separatamente.

Sistema operativo supportato

AppLocker è supportato su Windows 10, Windows 11 e sulle versioni Windows Server supportate:

• Windows 10 versione 2004 e successive, con gli aggiornamenti richiesti
• Windows 11, le policy AppLocker sono supportate su tutte le edizioni per lo scenario indicato dalla documentazione ufficiale.

Sulle versioni precedenti di Windows il supporto dipende maggiormente da edizione e metodo di distribuzione; quindi, in ambienti legacy conviene verificare sempre la matrice di supporto prima del rollout, che trovate alla pagina ufficiale Microsoft Operating system requirements – AppLocker. Nel contesto di questo articolo il riferimento è un device Windows 11, gestito con Microsoft Intune, su cui vogliamo impedire l’uso interattivo di WinGet agli utenti standard senza bloccare i deployment Win32 eseguiti in contesto System.

Microsoft Intune e AppLocker CSP

Per distribuire la configurazione tramite Intune useremo un profilo custom basato su AppLocker CSP. Il CSP espone collection separate per EXE, MSI, Script, DLL e StoreApps. Nel nostro caso la collection corretta è StoreApps, perché Microsoft.DesktopAppInstaller è una packaged app. Non dobbiamo creare una regola EXE su winget.exe. WinGet è distribuito come parte di App Installer (Microsoft.DesktopAppInstaller), quindi il controllo va fatto nella collection delle packaged apps. Se si prova a gestirlo come una normale applicazione Win32, si rischia di costruire una regola poco affidabile o non allineata al comportamento reale del client.

Servizio Application Identity

AppLocker richiede il servizio Application Identity (AppIDSvc). Questo servizio determina e verifica l’identità delle applicazioni; se viene arrestato, le policy AppLocker non vengono applicate. In un deployment gestito, il servizio deve quindi essere configurato correttamente prima di aspettarsi qualsiasi enforcement.

Su un client di test potete abilitarlo da prompt elevato con:

Attenzione: sulle versioni moderne di Windows il servizio Application Identity è protetto; quindi, non sempre è possibile gestirne il tipo di avvio dalla console grafica dei servizi. Il metodo più affidabile resta la configurazione tramite comando, GPO, security template o altro meccanismo di gestione supportato.

Win32 app Intune in contesto System

Il requisito di partenza è lasciare funzionare le app Win32 evergreen basate su WinGet. Per questo motivo le app distribuite da Intune devono essere configurate con Install behavior = System. Se il package viene eseguito in contesto utente, la regola AppLocker pensata per bloccare l’utente interattivo rischia di bloccare anche il deployment. Per il modello descritto in questo articolo, la separazione è questa: l’utente standard non deve poter usare WinGet manualmente, mentre Intune deve poter continuare a eseguire il proprio wrapper in contesto System. Questo prerequisito va verificato prima di iniziare la configurazione, perché è la base su cui si regge l’intero disegno.

Target della deny rule

La deny rule non va applicata a Everyone. Se usiamo Everyone, rischiamo di coinvolgere anche contesti che non vogliamo bloccare. In un ambiente ibrido o domain joined, la scelta più pulita può essere un gruppo AD dedicato, ad esempio GG_Block_Winget_Interactive, nel quale inserire solo gli utenti standard a cui vogliamo impedire l’uso interattivo di App Installer e WinGet. Nel mio scenario, però, il dispositivo è cloud-only. Per questo motivo nella demo userò il gruppo locale built-in Users, che corrisponde al SID well-known S-1-5-32-545. Questa scelta è comoda perché il SID è consistente sui client Windows e può essere usato nel payload XML di AppLocker. Va però compresa bene, ricordiamoci che stiamo bloccando l’uso interattivo di Microsoft.DesktopAppInstaller agli utenti standard del dispositivo. Il deployment Intune, invece, deve restare in contesto System, proprio per non rientrare nello stesso perimetro.

Default rules nella collection Packaged app Rules

Prima di creare la deny su Microsoft.DesktopAppInstaller, dobbiamo creare le default rules nella collection Packaged app Rules. Questo passaggio evita un errore molto comune: bloccare involontariamente altre packaged apps, come Microsoft Teams, AAD BrokerPlugin o componenti Microsoft usati dal sistema operativo.

La sequenza corretta è quindi:

• aprire la collection Packaged app Rules
• creare le default rules
• aggiungere la deny mirata su Microsoft.DesktopAppInstaller
• testare in Audit only
• passare in enforcement solo dopo aver verificato gli eventi

Senza questa base di allow, la collection può diventare più restrittiva del previsto, soprattutto se nel device o nella policy esistono già altre collection AppLocker configurate.

Audit only prima dell’enforcement

Per la prima fase, la collection Packaged app Rules deve essere impostata in Audit only. In questo modo la regola viene valutata, ma non blocca ancora l’esecuzione. Questo consente di verificare nei log se il match è corretto prima di applicare il blocco. È una precauzione che in laboratorio può sembrare eccessiva, ma in produzione evita problemi. Con AppLocker, una regola troppo larga o una collection configurata male può bloccare componenti che non c’entrano nulla con WinGet.

Punti di attenzione

Per questo scenario non serve abilitare enforcement sulle collection Executable Rules, Windows Installer Rules, Script Rules o DLL Rules. L’obiettivo non è costruire una allowlist completa del client, ma bloccare l’uso interattivo della packaged app Microsoft.DesktopAppInstaller. Tuttavia, se nel vostro ambiente esistono già regole AppLocker su EXE, MSI o Script, vanno considerate nel test, perché ogni collection ha un proprio comportamento di enforcement. In particolare, se si interviene sulle Executable Rules senza default rules adeguate, si può arrivare facilmente a un blocco generalizzato degli .exe. Per questa guida, quindi, la configurazione deve restare concentrata sulla collection Packaged app Rules.

Come implementare AppLocker con Intune passo dopo passo

In questa guida parto da uno scenario cloud-only, quindi con dispositivi Microsoft Entra joined e gestiti da Microsoft Intune. Questo dettaglio è fondamentale, perché cambia il modo in cui conviene costruire il target della regola AppLocker. In un ambiente ibrido potremmo usare un gruppo AD dedicato, ma in uno scenario cloud-only non voglio basare la regola su gruppi AD non presenti o su gruppi locali custom creati manualmente sui singoli device. Un gruppo locale creato manualmente su un client avrebbe infatti un SID specifico di quel dispositivo e non sarebbe portabile in modo affidabile sugli altri endpoint, per questo motivo, nella demo userò il gruppo locale built-in Users, identificato dal SID well-known S-1-5-32-545.

Questa scelta consente di avere una regola consistente sui dispositivi target. La deny verrà quindi applicata agli utenti standard che rientrano nel gruppo locale Users, mentre il contesto System, usato dai deployment Win32 di Intune configurati correttamente, non rientra in quel gruppo.

Attenzione anche ad un altro aspetto: la regola è pensata per bloccare l’uso interattivo di App Installer e WinGet agli utenti standard. Se avete account amministrativi che rientrano comunque nel gruppo locale Users, anche loro potrebbero essere intercettati nell’uso interattivo di winget. Per questo motivo il rollout va gestito con gradualità, partendo da un gruppo pilota di device e verificando bene il comportamento prima di allargare la distribuzione. La logica della configurazione sarà quindi questa:

• tutte le packaged app firmate restano consentite tramite la regola predefinita della collection Packaged app Rules
• Microsoft.DesktopAppInstaller viene negato agli utenti standard
• i deployment Win32 eseguiti da Intune in contesto System, invece, continuano a funzionare perché non vengono eseguiti nel contesto utente che stiamo bloccando

Per la creazione dell’app Win32 evergreen basata su WinGet vi rimando all’articolo WinGet: creare app Win32 evergreen con Microsoft Intune, dove il package viene configurato per essere eseguito in contesto System.

Figura 1: Install behavior System per l’app Win32 evergreen

Cosa vogliamo ottenere

L’obiettivo, come detto, non è bloccare tutte le packaged app né creare una allowlist completa del client. Vogliamo intervenire solo sul componente che permette all’utente di usare WinGet in modo interattivo. La configurazione finale sarà quindi questa:

Tabella 2: Configurazione desiderata AppLocker

Questo approccio usa AppLocker per il caso in cui serve differenziare il comportamento tra utenti o gruppi. AppLocker può infatti applicare regole a utenti e gruppi, mentre il CSP AppLocker espone collection distinte, tra cui StoreApps, che è quella corretta per le packaged app come Microsoft.DesktopAppInstaller.

Abilitare Servizio Application Identity

Come anticipato nel capitolo dei prerequisiti, AppLocker richiede il servizio Application Identity. Se il servizio non è in esecuzione, le regole AppLocker non vengono applicate e il comportamento del client può risultare diverso da quello atteso. Sul client di test possiamo verificarne lo stato aprendo la console dei servizi. Premiamo Win + R, digitiamo services.msc e premiamo Invio. All’interno della console cerchiamo il servizio Application Identity, che nei sistemi in italiano viene visualizzato come Identità applicazione, e controlliamo la sua configurazione.

Figura 2: Servizio Application Identity

In produzione questa impostazione può essere distribuita tramite policy, script o altro meccanismo di gestione centralizzata. Nella fase di laboratorio, invece, può essere utile configurarla manualmente per validare subito il comportamento della regola. Il servizio Application Identity ha il compito di determinare e verificare l’identità delle applicazioni, informazione che AppLocker utilizza per applicare correttamente le proprie regole. Per questo motivo, prima di procedere con i test, è importante assicurarsi che il servizio sia configurato e avviato correttamente.

Creare la policy AppLocker su un client pilota

Per evitare errori nella scrittura manuale dell’XML da distribuire con Microsoft Intune, conviene generare inizialmente la policy da un client pilota. In questo modo possiamo usare la console grafica di AppLocker, creare le regole nel formato corretto e poi esportare il risultato in XML. Sul client di test apriamo la console dei Criteri di sicurezza locali con privilegi amministrativi. Possiamo farlo premendo Win + R, digitando secpol.msc e premendo Invio. In alternativa, possiamo cercare secpol.msc dal menu Start ed eseguirlo come amministratore.

Figura 3: Creazione policy AppLocker – Parte 1

Una volta aperta la console, andiamo in Impostazioni di sicurezza > Criteri di controllo delle applicazioni > AppLocker > Regole app in pacchetto. Questa è la collection corretta per il nostro scenario, perché Microsoft.DesktopAppInstaller è una packaged app. Non dobbiamo quindi partire dalle regole per gli eseguibili classici, perché il nostro obiettivo non è bloccare un file .exe, ma controllare l’esecuzione di App Installer e WinGet tramite la collection delle app in pacchetto. A questo punto facciamo clic destro su Regole app in pacchetto e selezioniamo Crea regole predefinite.

Attenzione: questo passaggio è fondamentale e non va saltato. La regola predefinita consente agli utenti di eseguire le packaged app firmate e crea la base di allow necessaria prima di aggiungere la deny mirata su Microsoft.DesktopAppInstaller. Senza questa base, AppLocker può diventare molto più restrittivo del previsto. È il caso tipico in cui, dopo aver creato una regola di blocco apparentemente mirata, ci si ritrova con messaggi di blocco anche su componenti come Microsoft Teams, AAD BrokerPlugin o altre app pacchettizzate di sistema. La sequenza corretta, quindi, è sempre questa: prima le regole predefinite della collection Regole app in pacchetto, poi la deny specifica su Microsoft.DesktopAppInstaller.

Figura 4: Creazione policy AppLocker – Parte 2

Verrà creata automaticamente una regola predefinita che consente a Everyone di eseguire le packaged app firmate. Questa regola è la base di allow della collection e serve a evitare che AppLocker blocchi anche applicazioni pacchettizzate che devono continuare a funzionare regolarmente.

Figura 5: Creazione policy AppLocker – Parte 3

A questo punto, sempre nella collection Regole app in pacchetto, creiamo la regola di blocco per Microsoft.DesktopAppInstaller. Facciamo clic destro su Regole app in pacchetto e selezioniamo Crea nuova regola.

Figura 6: Creazione policy AppLocker – Parte 4

Nella procedura guidata che si apre, nella schermata Prima di iniziare, selezioniamo Avanti.

Figura 7: Creazione policy AppLocker – Parte 5

Nella sezione Autorizzazioni selezioniamo l’azione Nega. Subito sotto, nel campo Utente o gruppo, la procedura propone di default Everyone. In questo scenario non è quello che vogliamo usare. Se neghiamo App Installer a Everyone, rischiamo di intercettare anche contesti che non vogliamo bloccare. Nel nostro caso l’obiettivo è impedire l’uso interattivo di WinGet agli utenti standard, lasciando invece funzionare i deployment gestiti da Intune in contesto System. Per questo motivo selezioniamo Seleziona e impostiamo come target il gruppo locale built-in Users che, nei sistemi in italiano, viene visualizzato come Utenti. Dopo aver selezionato il gruppo, confermiamo con OK e proseguiamo con Avanti.

Figura 8: Creazione policy AppLocker – Parte 6

A questo punto, dopo aver verificato che l’azione sia impostata su Nega e che il gruppo target sia BUILTIN\Users, proseguiamo selezionando Avanti.

Figura 9: Creazione policy AppLocker – Parte 7

Nella sezione Autore facciamo clic su Seleziona. Si aprirà la finestra Selezione applicazioni, dalla quale possiamo scegliere una packaged app installata sul client da usare come riferimento per la regola. Nel campo di ricerca digitiamo Microsoft.DesktopAppInstaller. Verrà filtrata l’applicazione App Installer. Selezioniamola e confermiamo con OK.

Attenzione: sul client potrebbero essere presenti più versioni dello stesso pacchetto. Il wizard consente di selezionarne una sola, ma nel nostro scenario la versione scelta non è il punto importante. La regola che andremo a creare dovrà infatti essere basata sul nome del pacchetto, non sulla singola versione. In questo modo continuerà a essere valida anche dopo gli aggiornamenti di App Installer.

Figura 10: Creazione policy AppLocker – Parte 8

A questo punto, nella sezione Autore, verranno mostrate le informazioni dell’applicazione selezionata. Non dobbiamo allargare la regola a tutto il publisher Microsoft, perché in quel caso rischieremmo di bloccare altre packaged app firmate dallo stesso publisher. La deny deve essere mirata su Microsoft.DesktopAppInstaller. Allo stesso tempo, non vogliamo nemmeno limitare la regola a una specifica versione del pacchetto. Per ottenere il comportamento desiderato, spostiamo quindi il selettore fino a Nome pacchetto. In questo modo la regola sarà riferita al package name Microsoft.DesktopAppInstaller, indipendentemente dalla versione installata. Una volta configurato il livello corretto della regola, selezioniamo Avanti.

Figura 11: Creazione policy AppLocker – Parte 9

Nella sezione Eccezioni, per questo scenario, non dobbiamo aggiungere alcuna esclusione. Proseguiamo selezionando Avanti.

Figura 12: Creazione policy AppLocker – Parte 10

La sezione Nome è l’ultimo passaggio della configurazione. Qui assegniamo un nome alla regola, ad esempio “Deny rule per Microsoft.DesktopAppInstaller” e, se volete, possiamo aggiungere anche una descrizione. Una volta completati i campi, selezioniamo Crea per generare la regola.

Figura 13: Creazione policy AppLocker – Parte 11

Dopo la creazione, nella collection Regole app in pacchetto dovremo avere almeno due regole:

• la default allow per le packaged app firmate
  
• la deny rule appena creata su Microsoft.DesktopAppInstaller
  

Questa è la configurazione minima corretta per il nostro scenario: prima una base di allow per evitare blocchi indesiderati sulle packaged app, poi una deny mirata solo su Microsoft.DesktopAppInstaller.

Figura 14: Creazione policy AppLocker – Parte 12

Impostare la collection in Audit only

Dopo aver creato la regola predefinita e la deny rule su Microsoft.DesktopAppInstaller, conviene impostare la collection in Audit only prima di applicare il blocco. Questo passaggio serve a validare la configurazione senza interrompere subito l’esperienza utente. In questa fase AppLocker valuta le regole e genera gli eventi nei log, ma non impedisce ancora l’esecuzione dell’applicazione. È il modo più sicuro per verificare che la deny stia colpendo solo App Installer (WinGet) e non altre packaged app che devono continuare a funzionare.

Per configurare l’audit, torniamo nella console Criteri di sicurezza locali e andiamo in Impostazioni di sicurezza > Criteri di controllo delle applicazioni, facciamo clic con il tasto destro su AppLocker e selezioniamo Proprietà.

Figura 15: Impostazioni Audit only per AppLocker – Parte 1

Nella finestra delle proprietà di AppLocker, nella sezione Regole app in pacchetto, selezioniamo Configurate e poi impostiamo l’enforcement su Controlla soltanto (Audit only). Con questa configurazione l’utente continuerà a poter eseguire App Installer e winget, ma nei log AppLocker vedremo gli eventi che indicano se la regola avrebbe prodotto un blocco. Se i log mostrano solo riferimenti a Microsoft.DesktopAppInstaller, possiamo proseguire con maggiore sicurezza. Se invece compaiono eventi su altre packaged app, come Teams o componenti di sistema, è meglio fermarsi e rivedere la collection prima di passare in enforcement. Una volta applicata la modifica, confermiamo con OK.

Attenzione: se nella finestra sono presenti altre collection già configurate, ad esempio Regole eseguibili, Regole di Windows Installer o Regole script, non modificatele in questa fase. L’obiettivo della guida è lavorare solo sulla collection Regole app in pacchetto. Cambiare l’enforcement di altre collection senza aver predisposto le relative regole predefinite può causare blocchi indesiderati e, nei casi peggiori, impedire l’avvio di applicazioni necessarie al corretto funzionamento del sistema.

Figura 16: Impostazioni Audit only per AppLocker – Parte 2

Esportare la policy AppLocker

Dopo aver creato le regole e impostato la collection in Audit only, possiamo esportare la policy in formato XML. Questo file ci servirà come base per creare il profilo custom in Microsoft Intune. Torniamo quindi in Impostazioni di sicurezza > Criteri di controllo delle applicazioni, facciamo clic con il tasto destro su AppLocker e selezioniamo Esporta criterio.

Figura 17: Esportazione policy AppLocker – Parte 1

Nella finestra che si apre scegliamo il percorso in cui salvare il file XML. Nel mio caso utilizzerò la cartella C:\Temp, assegnando alla policy un nome, ad esempio “DenyRule_AppInstaller_Users.xml” (non è fondamentale il nome). Confermiamo quindi con Salva.

Figura 18: Esportazione policy AppLocker – Parte 2

Al termine dell’operazione verrà mostrato un messaggio con l’esito dell’esportazione e il numero di regole incluse nel file. Chiudiamo l’avviso selezionando OK.

Figura 19: Esportazione policy AppLocker – Parte 3

A questo punto abbiamo ottenuto l’XML da usare come base per il profilo Intune. Se state lavorando sullo stesso client pilota su cui poi testerete la policy distribuita da Intune, conviene rimuovere la configurazione locale appena creata. In questo modo evitiamo di confondere gli effetti della policy locale con quelli della policy MDM. Per farlo, torniamo in Impostazioni di sicurezza > Criteri di controllo delle applicazioni > AppLocker > Regole app in pacchetto ed eliminiamo le regole create per il test locale, quindi sia la regola predefinita di allow sia la deny rule su Microsoft.DesktopAppInstaller.

Figura 20: Eliminazione policy AppLocker

Dopo aver rimosso le regole, dobbiamo anche togliere la configurazione di enforcement locale sulla collection. Torniamo quindi in Impostazioni di sicurezza > Criteri di controllo delle applicazioni, facciamo clic con il tasto destro su AppLocker e selezioniamo Proprietà. Nella sezione Regole app in pacchetto, rimuoviamo il flag da Configurate. In questo modo la collection non resterà configurata localmente e sarà Intune, tramite il profilo che creeremo nei prossimi passaggi, ad applicare la policy al client. Confermiamo selezionando Applica e poi OK.

Questa pulizia non è obbligatoria se state solo generando l’XML su una macchina di laboratorio separata, ma è consigliata quando usate lo stesso device anche per validare il deployment da Intune, come nel mio caso. In caso contrario potreste trovarvi con una policy locale e una policy MDM applicate contemporaneamente, rendendo più difficile capire quale configurazione stia realmente producendo il comportamento osservato.

Figura 21: Eliminazione regola Audit only

Deep dive in AppLocker XML

Prima abbiamo esportato la policy AppLocker in formato XML nella cartella C:\Temp. Prima di creare il profilo custom in Microsoft Intune, bisogna aprire il file e capire quali parti ci servono davvero. Aprendo l’XML esportato, noterete che il file non contiene solo la collection che abbiamo configurato per questa guida. L’export completo di AppLocker può includere anche altre collection eventualmente presenti sul client, ad esempio regole per eseguibili, script, Windows Installer o DLL. Per il nostro scenario, però, ci interessa esclusivamente la collection dedicata alle packaged apps.

Figura 22: AppLockerPolicy XML

La sezione da individuare è la RuleCollection di tipo Appx, che nel nostro caso è stata impostata in AuditOnly:

All’interno di questa collection troviamo la regola predefinita che consente a Everyone di eseguire le packaged app firmate. Questa regola è importante perché mantiene consentite le packaged app firmate e riduce il rischio di blocchi indesiderati su componenti come Teams, AAD BrokerPlugin o altre app pacchettizzate di sistema:

Subito dopo troviamo la regola di deny che abbiamo creato per Microsoft.DesktopAppInstaller:

Tutto il resto del file non ci serve, pertanto il file XML completo che dobbiamo configurare sarà il seguente:

Figura 23: AppLockerPolicy XML modificato

Creare il profilo Custom in Microsoft Intune

A questo punto siamo pronti per portare la configurazione in Microsoft Intune. L’XML è stato preparato, abbiamo isolato la RuleCollection corretta e possiamo distribuirla ai dispositivi tramite AppLocker CSP. Apriamo il Microsoft Intune Admin Center e navighiamo in Devices > Configuration. Da qui creiamo una nuova policy scegliendo Windows 10 and later come piattaforma e Templates come tipo di profilo. Nel sottomenu dei template, selezionate Custom e procediamo facendo click su Create.

Figura 24: Creazione Custom Template in Microsoft Intune – Parte 1

Nella scheda Basics assegniamo un nome alla policy, ad esempio “AppLocker – Block WinGet interactive usage“, aggiungiamo una descrizione se la riteniamo utile e proseguiamo con Next.

Figura 25: Creazione Custom Template in Microsoft Intune – Parte 2

Nella sezione Configuration settings aggiungiamo una nuova riga tramite il pulsante Add, nel wizard OMA-URI Settings che si apre sulla destra inserire i seguenti parametri:

• Name = AppLocker StoreApps Policy
• Description (Opzionale) = Policy AppLocker per bloccare Microsoft.DesktopAppInstaller agli utenti standard
• OMA-URI = ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/BlockWinGet/StoreApps/Policy
• Data type = String
• Value = Incolliamo il contenuto XML della RuleCollection Appx
  

Attenzione: la struttura ‘OMA-URI utilizzata è ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/{group}/StoreApps/Policy. Il valore BlockWinGet che ho utilizzato nella demo è il grouping scelto per questa policy. Può essere un nome descrittivo, ma deve restare stabile e non entrare in conflitto con altri grouping eventualmente usati per AppLocker. Il CSP AppLocker prevede grouping dinamici proprio per separare le diverse configurazioni. Se state facendo più test o avete già creato policy precedenti, può essere utile usare un nome nuovo o un valore univoco, ad esempio BlockWinGetV2, per evitare residui di configurazioni precedenti.

Una volta compilati tutti i campi, selezioniamo Save.

Figura 26: Creazione Custom Template in Microsoft Intune – Parte 3

Dopo aver aggiunto la riga OMA-URI, verifichiamo che sia presente nella sezione Configuration settings e proseguiamo con Next.

Figura 27: Creazione Custom Template in Microsoft Intune – Parte 4

Nella sezione Assignments assegniamo la policy al gruppo desiderato. In questo scenario consiglio di partire da un gruppo pilota di device, perché il CSP AppLocker viene applicato al dispositivo. La regola interna, invece, continuerà a colpire gli utenti standard tramite il SID configurato nell’XML, nel nostro caso S-1-5-32-545, cioè BUILTIN\Users. Per assegnare la policy, selezioniamo Add groups, cerchiamo il gruppo pilota, selezioniamolo tramite la relativa checkbox e confermiamo con Select.

Figura 28: Creazione Custom Template in Microsoft Intune – Parte 5

Sempre nella sezione Assignments, verifichiamo che il gruppo sia stato aggiunto correttamente in Included groups. Se necessario possiamo aggiungere altri gruppi o usare filtri di assegnazione, ma in fase di test è meglio mantenere il perimetro il più ristretto possibile.

Figura 29: Creazione Custom Template in Microsoft Intune – Parte 6

Nella sezione Applicability Rules possiamo definire condizioni aggiuntive per limitare l’applicazione della policy, ad esempio a specifiche versioni o edizioni di Windows. Per questa demo non è necessario configurare regole di applicabilità, ma in ambienti più ampi possono essere utili per evitare risultati Not applicable su dispositivi che non devono ricevere questa configurazione. Proseguiamo quindi con Next.

Figura 30: Creazione Custom Template in Microsoft Intune – Parte 7

Infine, nella pagina Review + create controlliamo attentamente tutti i parametri configurati: nome della policy, OMA-URI, tipo dato, contenuto XML e assegnazioni. Questa verifica è importante, perché un errore nel payload XML o nel nodo OMA-URI può impedire l’applicazione della policy sul client. Se tutto è configurato correttamente, selezioniamo Create.

Figura 31: Creazione Custom Template in Microsoft Intune – Parte 8

Dopo pochi istanti la policy sarà disponibile in Intune e pronta per la distribuzione secondo le assegnazioni configurate.

Figura 32: Creazione Custom Template in Microsoft Intune – Parte 9

A questo punto possiamo passare alla verifica lato client. Nella prima fase la policy è ancora in AuditOnly, quindi non bloccherà realmente l’esecuzione di App Installer o WinGet, ma ci permetterà di controllare nei log se la regola viene valutata correttamente.

Esperienza utente

Dopo aver configurato la policy, è importante verificare il comportamento dal punto di vista dell’utente. Non basta controllare che il profilo risulti distribuito da Intune, dobbiamo anche vedere cosa succede realmente quando un utente standard apre un prompt dei comandi o una sessione PowerShell e prova a usare WinGet. Per rendere il test più leggibile, conviene dividerlo in tre momenti:

• prima dell’applicazione della policy
• con la policy in Audit only
• con la policy in Enforce

Questa distinzione è utile perché ci permette di separare due aspetti diversi: nella fase di audit la regola viene valutata e genera eventi nei log, ma non blocca l’esecuzione; nella fase di enforcement, invece, AppLocker applica realmente la deny rule e impedisce l’uso di Microsoft.DesktopAppInstaller agli utenti interessati dalla regola.

Prima dell’applicazione della policy

Prima di applicare la policy AppLocker, l’utente standard può aprire un prompt dei comandi o una sessione PowerShell ed eseguire normalmente WinGet. In questa fase la CLI risponde senza restrizioni, interroga le sorgenti configurate sul client e consente all’utente di cercare o avviare l’installazione dei pacchetti disponibili nel catalogo. È proprio questo il comportamento che vogliamo governare: WinGet è presente sul dispositivo e funziona, ma può essere usato anche al di fuori di un flusso gestito dall’IT.

Figura 33: Esperienza utente prima di AppLocker – Parte 1

Figura 34: Esperienza utente prima di AppLocker – Parte 2

Questo primo test ci serve come baseline. Prima di introdurre AppLocker, dobbiamo verificare che WinGet funzioni correttamente sul client e che l’eventuale blocco osservato nei passaggi successivi sia effettivamente causato dalla policy e non da problemi preesistenti, come sorgenti non disponibili, App Installer non aggiornato o errori di rete.

Comportamento con policy in Audit only

Vediamo ora cosa succede quando il client riceve la policy creata in Microsoft Intune. Nella prima fase la policy AppLocker è configurata in Audit only. Questo significa che la regola viene valutata, ma non viene ancora applicato alcun blocco. L’utente standard può quindi continuare a eseguire winget da prompt dei comandi o da PowerShell e, dal suo punto di vista, l’esperienza resta invariata.

La differenza, in questa fase, si vede lato amministratore. AppLocker registra nei log gli eventi che indicano che Microsoft.DesktopAppInstaller sarebbe stato bloccato se la collection fosse stata configurata in enforcement. È esattamente il motivo per cui conviene partire da Audit only: possiamo verificare che la regola intercetti il package corretto senza interrompere subito l’operatività del client.

I log da controllare si trovano in Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker. Per le packaged app, l’evento più importante in questa fase è l’Event ID 8021, che indica che una packaged app è stata valutata in audit. Nel nostro caso l’evento deve fare riferimento a Microsoft.DesktopAppInstaller. Se invece compaiono eventi relativi ad altre packaged app, come Teams o componenti di sistema, conviene fermarsi e rivedere la configurazione prima di passare in enforcement.

Con questa verifica confermiamo che la policy è arrivata sul device e che la deny rule viene valutata correttamente. Solo dopo questa validazione ha senso modificare la RuleCollection da AuditOnly a Enabled, così da applicare il blocco.

Figura 35: Event Viewer ID 8021 – AppLocker Audit Only

Policy in Enforce

Dopo aver verificato i log in modalità Audit only, possiamo passare la collection Packaged app Rules in modalità Enforce. In questo modo AppLocker non si limiterà più a registrare l’evento, ma applicherà realmente la deny rule su Microsoft.DesktopAppInstaller. Per modificare la policy riapriamo il Microsoft Intune Admin Center e navighiamo in Devices > Configuration. Apriamo la policy creata in precedenza, nel nostro caso AppLocker – Block WinGet interactive usage e, nella schermata della policy, scorriamo fino alla sezione Configuration settings e selezioniamo Edit.

Figura 36: AppLocker policy in Enforce mode – Parte 1

Nella schermata successiva individuiamo la riga OMA-URI configurata in precedenza, selezioniamo i tre puntini accanto alla riga e scegliamo Edit. Nel pannello laterale, all’interno del campo Value, modifichiamo il valore della RuleCollection sostituendo EnforcementMode=”AuditOnly” con EnforcementMode=”Enabled”, in questo modo la collection passerà dalla sola registrazione degli eventi al blocco effettivo. Dopo la modifica selezioniamo Save.

Figura 37: AppLocker policy in Enforce mode – Parte 2

Proseguiamo con Review + save

Figura 38: AppLocker policy in Enforce mode – Parte 3

Infine, concludiamo la modifica alla policy facendo click nuovamente su Save.

Figura 39: AppLocker policy in Enforce mode – Parte 4

A questo punto, dopo la sincronizzazione del device, il comportamento lato utente cambia. La policy non è più in modalità audit, quindi l’utente standard che rientra nel target della regola, nel nostro caso BUILTIN\Users, non potrà più eseguire Microsoft.DesktopAppInstaller. Se l’utente prova a utilizzare winget da prompt dei comandi o da PowerShell, l’esecuzione viene bloccata da AppLocker e viene mostrato un errore. Questo è esattamente il comportamento atteso, non stiamo bloccando la singola applicazione finale che potrebbe essere installata da WinGet, ma il componente che consente all’utente di usare WinGet in modo interattivo.

Figura 40: Esperienza utente AppLocker in Enforce – Parte 1

Figura 41: Esperienza utente AppLocker in Enforce – Parte 2

Anche nei log cambia il tipo di evento generato. In modalità Audit only avevamo un evento informativo o di warning che indicava che l’app sarebbe stata bloccata. In modalità Enforce, invece, troviamo un errore che indica il blocco effettivo di Microsoft.DesktopAppInstaller. Il log da controllare resta Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker. Nel nostro caso l’evento di riferimento è l’Event ID 8022, che indica che una packaged app è stata bloccata dalla policy AppLocker.

Figura 42: Event Viewer ID 8022 – AppLocker Enforce

Esperienza System

Abbiamo visto che, una volta portata la policy AppLocker in modalità Enforce, l’utente standard non riesce più a eseguire WinGet in modo interattivo. La regola di deny è infatti applicata al gruppo BUILTIN\Users, quindi l’esecuzione di Microsoft.DesktopAppInstaller viene bloccata quando il comando viene avviato dalla sessione utente. A questo punto la domanda più importante è un’altra: cosa succede se la stessa logica viene usata da una Win32 app distribuita da Intune in contesto System?

Per la creazione di un’app Win32 evergreen basata su WinGet vi rimando all’articolo WinGet: creare app Win32 evergreen con Microsoft Intune pubblicato su ICT Power. In questo esempio ho preparato un’applicazione Win32 evergreen (7-Zip), configurata con Install behavior = System. In questo scenario AppLocker non blocca l’esecuzione, perché la deny rule che abbiamo creato non è applicata al contesto System, ma al gruppo BUILTIN\Users. Il risultato è quello che volevamo ottenere: l’utente non può usare WinGet manualmente, mentre Intune può continuare a usare WinGet all’interno del flusso gestito.

Dal Company Portal seleziono quindi l’applicazione 7-Zip.

Figura 43: Installazione app Win32 evergreen con WinGet – Parte 1

Proseguo selezionando Installa.

Figura 44: Installazione app Win32 evergreen con WinGet – Parte 2

Dopo qualche istante, l’installazione viene completata correttamente.

Figura 45: Installazione app Win32 evergreen con WinGet – Parte 3

La conferma più importante arriva dai log dell’applicazione. Nei log di detection e installazione si vede che WinGet viene eseguito nel contesto previsto e non viene bloccato dalla policy AppLocker, né durante la fase di rilevamento né durante la fase di installazione.

Figura 46: Detection log app Win32 evergreen con WinGet

Figura 47: Install log app Win32 evergreen con WinGet – Parte 1

Figura 48: Install log app Win32 evergreen con WinGet – Parte 2

Questa verifica chiude il cerchio della configurazione. La CLI di WinGet resta inutilizzabile per l’utente standard, ma continua a funzionare per i deployment Win32 gestiti da Intune in contesto System. È esattamente la separazione che cercavamo: bloccare l’uso interattivo non governato, senza interrompere il modello evergreen usato per la gestione applicativa.

Troubleshooting

Nel corso dei test ci sono due errori che conviene conoscere bene, perché sono quelli che più facilmente portano a risultati inattesi o, nei casi peggiori, a un client quasi inutilizzabile. Il primo è creare solo la regola di deny su Microsoft.DesktopAppInstaller, senza prima aggiungere la regola predefinita di allow per le packaged app firmate. Il secondo è passare direttamente in Enforce, senza fare prima una fase di Audit only. Presi singolarmente sono già due errori da evitare. Se però si combinano insieme, il risultato può diventare molto pesante.

Deny rule senza regola predefinita di allow

Come abbiamo visto nei capitoli precedenti, nella collection Regole app in pacchetto non basta creare una deny rule e considerare chiuso il lavoro. AppLocker, infatti, ragiona per collection, e una collection configurata male può diventare molto più restrittiva di quanto sembri a prima vista.

Nel nostro scenario la regola corretta deve sempre partire da due elementi:

• una regola predefinita di allow per le packaged app firmate
• una regola di deny mirata su Microsoft.DesktopAppInstaller

Se ci dimentichiamo la regola predefinita di allow e lasciamo solo la deny, il rischio è che AppLocker inizi a impattare anche altre packaged app che non volevamo toccare, ed è esattamente quello che si vede già nella fase di test. Nell’esempio seguente, nella collection Regole app in pacchetto, è presente soltanto la deny rule su Microsoft.DesktopAppInstaller, senza la regola predefinita di allow.

Figura 49: Collection Regole app in pacchetto con sola deny rule

In una situazione di questo tipo, AppLocker non si limita più a colpire solo App Installer nel modo previsto, ma può iniziare a coinvolgere anche altri componenti pacchettizzati del sistema.

Cosa si vede in Audit only

Se per fortuna abbiamo lasciato la collection in Audit only, il client continua a funzionare e l’utente non viene ancora bloccato. In compenso, però, i log mostrano chiaramente che la configurazione è sbagliata. In Event Viewer, sotto Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker > Esecuzione app in pacchetto iniziano a comparire eventi 8021 relativi ad applicazioni che non c’entrano nulla con WinGet. Nell’esempio seguente, ad esempio, vediamo che l’esecuzione di MICROSOFT.AAD.BROKERPLUGIN sarebbe stata impedita in caso di enforcement.

Figura 50: Event ID 8021 in Audit only su packaged app non desiderate

Questo è già un segnale molto chiaro, perché la policy non sta colpendo solo Microsoft.DesktopAppInstaller, ma sta diventando troppo aggressiva. Se in questa fase nei log vedete componenti come AAD BrokerPlugin, Teams o altre packaged app Microsoft, conviene fermarsi subito e correggere la collection prima di procedere oltre.

Cosa succede se dimentichiamo anche l’Audit only

Il problema peggiora se, oltre ad aver creato solo la deny rule, ci dimentichiamo anche di lasciare la collection in Audit only e passiamo direttamente in Enforce. In questo caso AppLocker non si limita più a registrare gli eventi, ma inizia a bloccare realmente le packaged app intercettate dalla collection. E qui il comportamento del pc può deteriorarsi molto rapidamente. In Event Viewer compaiono infatti gli eventi 8022, che indicano il blocco effettivo dell’applicazione.

Figura 51: Event ID 8022 in Enforce su packaged app non desiderate

Nel mio test, ad esempio, il blocco non ha coinvolto solo App Installer, ma anche MICROSOFT.AAD.BROKERPLUGIN. Questo tipo di comportamento è un chiaro indicatore del fatto che la collection è stata costruita in modo errato. Se si arriva a questo punto, il dispositivo può iniziare a comportarsi in modo anomalo: alcune packaged app possono non avviarsi più, alcune funzionalità di Windows possono smettere di rispondere correttamente e perfino componenti aziendali come il Company Portal possono essere bloccati.

Nell’esempio seguente, infatti, il Portale Aziendale non riesce più ad aprirsi e mostra un messaggio di blocco da parte dell’amministratore.

Figura 52: Company Portal bloccato da una collection Packaged app configurata in modo errato – 1

Figura 53: Company Portal bloccato da una collection Packaged app configurata in modo errato – 2

Correggere gli errori

Se vi accorgete dell’errore quando siete ancora in Audit only, la correzione è semplice: basta aggiungere la regola predefinita di allow nella collection Regole app in pacchetto, riesportare l’XML e aggiornare il profilo Intune. Se invece la policy è già in Enforce e il client ha iniziato a bloccare altre app, conviene intervenire subito sul profilo Intune:

• riportare la policy in Audit only (oppure rimuoverla temporaneamente)
• correggere la RuleCollection inserendo la regola predefinita di allow
• ridistribuire il profilo corretto
• sincronizzare il client e verificare di nuovo i log

In laboratorio è un errore utile da vedere almeno una volta, perché fa capire molto bene come lavora AppLocker. In produzione, invece, è uno di quei casi che conviene evitare del tutto.

Checklist di costruzione delle regole AppLocker

Per evitare errori critici come quelli visti nel capitolo precedente, vi lascio una checklist minima da seguire prima di distribuire una policy AppLocker ai client. AppLocker è molto utile quando dobbiamo applicare regole diverse in base all’utente o al gruppo, ma proprio per questo va trattato con attenzione: una collection configurata male può bloccare molto più di quanto previsto.

La checklist che segue è quella che utilizzerei prima di portare una configurazione da laboratorio a Intune:

• creare le default rules nella collection interessata
• aggiungere la deny o allow rule necessaria
• impostare la collection in Audit only
• esportare la policy
• distribuire la policy a un gruppo pilota
• controllare Event Viewer
• verificare il comportamento lato utente
• verificare il comportamento dei deployment gestiti
• passare in Enforce solo dopo un’attenta validazione

Nel nostro scenario, la regola più importante è la prima: default allow prima, deny mirata dopo. Se saltate questo passaggio e andate direttamente in enforcement, AppLocker può iniziare a bloccare packaged app che non hanno nulla a che fare con WinGet.

Conclusioni

Quando si introduce WinGet in un modello di gestione applicativa enterprise, la parte tecnica legata all’installazione è solo una parte del lavoro. Il passaggio successivo, spesso più delicato, è capire come evitare che lo stesso strumento venga usato fuori dal perimetro previsto dall’IT. Nel nostro scenario il requisito era mantenere attiva la CLI di WinGet perché necessaria alle app Win32 evergreen distribuite con Intune, ma impedire agli utenti standard di usarla manualmente da prompt o PowerShell per installare software non governato.

La prima tentazione potrebbe essere quella di bloccare le singole applicazioni non desiderate con App Control for Business. Tuttavia, emerge subito il limite di questo approccio, poiché App Control for Business lavora a livello device e non distingue tra utente interattivo e contesto System. Una deny sull’app finale rischia quindi di bloccare anche il deployment gestito da Intune, soprattutto se lo stesso software viene installato tramite il wrapper evergreen.

Per questo scenario, la soluzione più adatta è infatti AppLocker. Con una regola nella collection Regole app in pacchetto, possiamo bloccare Microsoft.DesktopAppInstaller agli utenti standard, lasciando invece funzionare i deployment Win32 eseguiti da Intune in contesto System. La differenza è sostanziale, non stiamo infatti bloccando Chrome, 7-Zip o un’altra applicazione finale, ma stiamo impedendo all’utente di usare App Installer e WinGet come canale interattivo di installazione.

Con questo approccio otteniamo una separazione pulita, infatti l’utente standard non può usare WinGet liberamente, mentre Intune continua a gestire le applicazioni evergreen in modo controllato. È un modello semplice da comprendere, sostenibile da gestire e più adatto al requisito rispetto a una deny device-wide su App Control for Business. In un percorso di application lifecycle management moderno, WinGet può essere un ottimo componente operativo, ma va inserito dentro un disegno di governance chiaro. AppLocker, in questo caso, ci permette proprio di aggiungere quel perimetro: non rimuoviamo la CLI dove serve all’IT, ma impediamo che diventi uno strumento libero nelle mani degli utenti finali.