Consenti automaticamente le app distribuite da un programma di installazione gestito con Controllo delle applicazioni per le aziende

Controllo app per le aziende include un'opzione denominata programma di installazione gestito che consente di bilanciare sicurezza e gestibilità nell'applicazione dei criteri di Controllo app. Questa opzione consente di consentire automaticamente le applicazioni installate da una soluzione di distribuzione software designata, come Microsoft Configuration Manager o Microsoft Intune.

Come funziona un programma di installazione gestito?

Il programma di installazione gestito usa una speciale raccolta di regole in AppLocker per designare i file binari considerati attendibili dall'organizzazione come origine autorizzata per l'installazione delle applicazioni. Quando viene eseguito uno di questi file binari attendibili, Windows monitora il processo del file binario (e tutti i processi figlio avviati) e verifica la presenza di file scritti su disco. Man mano che i file vengono scritti, vengono contrassegnati come provenienti da un programma di installazione gestito.

È quindi possibile configurare Controllo app in modo che consideri attendibili i file installati da un programma di installazione gestito aggiungendo l'opzione "Enabled:Managed Installer" ai criteri di Controllo app. Quando questa opzione è impostata, Controllo app controllerà le informazioni sull'origine del programma di installazione gestito per determinare se consentire o meno l'esecuzione di un file binario. Finché non esistono regole di negazione per il file binario, Controllo app ne consentirà l'esecuzione esclusivamente in base all'origine del programma di installazione gestito.

Informazioni sulle attestazioni di origine

Quando il programma di installazione gestito o Intelligent Security Graph (ISG) autorizza un file, Controllo app registra il motivo per cui quel file è attendibile aggiungendo un attributo esteso gestito dal kernel (EA) al file. Nota come attestazione di origine, l'EA acquisisce l'origine della reputazione del file, in modo che l'integrità del codice possa valutare il file in un secondo momento senza ricontrollare l'origine originale. La rivendicazione dell'origine si chiama $KERNEL.SMARTLOCKER.ORIGINCLAIM. Un'attestazione di origine registra cosa ha scritto il file, indica che il processo che ha scritto il file è stato considerato attendibile come programma di installazione gestito o in base alla reputazione e se l'attendibilità è stata ereditata da un padre. Puoi usare il fsutil comando per visualizzare questo EA su un file. Per i passaggi esatti, vedere Utilizzo di fsutil per eseguire query sugli attributi estesi per il programma di installazione gestito (MI).

• Origine del programma di installazione gestito: Il file è stato scritto da un processo considerato attendibile dai criteri come programma di installazione gestito (ad esempio, uno strumento di distribuzione come Microsoft Configuration Manager o Microsoft Intune). Questa attendibilità si basa sul modo in cui il file è arrivato sul dispositivo, non sulle proprietà, le firme o il valore hash del file. Per altre informazioni, vedere Considerazioni sulla sicurezza con il programma di installazione gestito.
• Origine di Intelligent Security Graph (ISG): Il file ha ricevuto una risposta di reputazione favorevole o ha ereditato la risposta di reputazione favorevole dal processo padre, ovvero un programma di installazione che ha creato il file. Queste risposte sulla reputazione provengono dai servizi di intelligence sulla sicurezza di Microsoft chiamati Intelligent Security Graph. La reputazione è associata al file specifico, quindi se il file viene modificato, la reputazione non è più applicabile e la dichiarazione di origine non viene più onorata. In questo caso, il file viene rivalutato da Controllo app alla successiva esecuzione. Per altre informazioni, vedere Autorizzare app affidabili con Intelligent Security Graph (ISG).

Le attestazioni di origine si propagano lungo un albero di processo. Quando un programma di installazione gestito è in esecuzione o quando un programma di installazione riceve una risposta di reputazione del programma di installazione attendibile dall'ISG, passa un'attendibilità equivalente ai file scritti e ai processi figlio avviati. Questa fiducia continua a fluire lungo l'albero del processo attivo attraverso i processi figlio, i loro figli e le generazioni successive, in modo che tutti i file di cui un programma di installazione ha bisogno per installare ed eseguire un'app siano autorizzati.

La propagazione non è illimitata. Termina quando la struttura ad albero del processo attendibile si interrompe, inclusi i casi seguenti:

• Il processo di installazione originale termina. L'ambito dell'attendibilità è la durata dell'albero del processo attendibile. Un file creato dopo la chiusura del programma di installazione gestito originale o del processo del programma di installazione attendibile ISG non eredita la propria attestazione di origine. Nei dati dell'attributo esteso, tale file è contrassegnato come "figlio di un bambino" e non è autorizzato per l'esecuzione autonomamente, ma deve essere consentito con altri mezzi, ad esempio una regola esplicita, l'origine del programma di installazione gestito o la reputazione ISG.
• Un processo attraversa un confine di sicurezza. Se un processo viene generato in un contesto di protezione o utente diverso, il processo padre può passare la propria attestazione di origine al processo figlio. In caso contrario, l'albero del processo viene interrotto e tutti i file creati dal processo figlio o dai suoi figli non sono autorizzati in base alla rivendicazione di origine del processo iniziale.

Dopo che l'albero del processo si interrompe per qualsiasi motivo, tutti i file creati devono essere autorizzati con altri mezzi, incluso se vengono eseguiti come programma di installazione gestito o ricevono una risposta di reputazione del programma di installazione attendibile dall'ISG.

Considerazioni sulla sicurezza del programma di installazione gestito

Poiché il programma di installazione gestito è un meccanismo basato sull'euristica, non fornisce le stesse garanzie di sicurezza delle regole esplicite di consenso o di negazione. Il programma di installazione gestito è più adatto quando gli utenti operano come utenti standard e in cui tutto il software viene distribuito e installato da una soluzione di distribuzione software, ad esempio Gestione configurazione.

Gli utenti con privilegi di amministratore o il malware in esecuzione come utente amministratore nel sistema potrebbero essere in grado di aggirare l'intento dei criteri di Controllo app quando l'opzione del programma di installazione gestito è consentita.

Se un processo del programma di installazione gestito viene eseguito nel contesto di un utente con privilegi standard, è possibile che gli utenti standard o il malware in esecuzione come utente standard siano in grado di aggirare lo scopo dei criteri di Controllo delle app.

Alcuni programmi di installazione dell'applicazione possono eseguire automaticamente l'applicazione al termine del processo di installazione. Se l'applicazione viene eseguita automaticamente e il programma di installazione è stato eseguito da un programma di installazione gestito, il rilevamento euristico e l'autorizzazione del programma di installazione gestito si estenderanno a tutti i file creati durante la prima esecuzione dell'applicazione. Questa estensione potrebbe comportare l'autorizzazione non intenzionale di un eseguibile. Per evitare questo problema, assicurarsi che il metodo di distribuzione delle applicazioni usato come programma di installazione gestito limiti l'esecuzione delle applicazioni come parte dell'installazione.

Limitazioni note con il programma di installazione gestito

• Controllo app, basato sul programma di installazione gestito, non supporta le applicazioni che si aggiornano automaticamente. Se un'applicazione distribuita da un programma di installazione gestito si aggiorna in seguito, i file dell'applicazione aggiornati non includeranno le informazioni sull'origine del programma di installazione gestito e potrebbero non essere in grado di eseguirli. Quando ci si affida a programmi di installazione gestiti, è necessario distribuire e installare tutti gli aggiornamenti dell'applicazione usando un programma di installazione gestito o includere regole per autorizzare l'app nei criteri di controllo delle app. In alcuni casi, potrebbe essere anche possibile designare un binario dell'applicazione che esegue gli aggiornamenti automatici come programma di installazione gestito. Una revisione appropriata dei livelli di sicurezza e delle funzionalità deve essere eseguita per l'applicazione prima di usare questo metodo.

• Alcune applicazioni o programmi di installazione possono estrarre, scaricare o generare file binari e tentare immediatamente di eseguirli. I file eseguiti da un processo di questo tipo potrebbero non essere consentiti dall'euristica del programma di installazione gestito. In alcuni casi, potrebbe essere possibile designare anche un file binario di un'applicazione che esegue tale operazione come programma di installazione gestito. Una revisione appropriata dei livelli di sicurezza e delle funzionalità deve essere eseguita per l'applicazione prima di usare questo metodo.

• L'euristica del programma di installazione gestito non autorizza i driver del kernel. I criteri Controllo app devono disporre di regole che consentano l'esecuzione dei driver necessari.

Configurare il rilevamento del programma di installazione gestito con AppLocker e Controllo app

Per attivare il rilevamento del programma di installazione gestito, è necessario:

• Creare e distribuire criteri di AppLocker che definiscano le regole del programma di installazione gestito e consentano l'imposizione dei servizi per eseguibili e DLL.
• Abilitare i servizi Identità applicazione e AppLockerFltr di AppLocker.

Creare e distribuire criteri di AppLocker che definiscano le regole del programma di installazione gestito e consentano l'applicazione dei servizi per eseguibili e DLL

L'interfaccia utente per la creazione dei criteri di AppLocker nell'Editor dell'oggetto Criteri di gruppo e i cmdlet di PowerShell per AppLocker non possono essere usati direttamente per creare regole per la raccolta regole del programma di installazione gestito. Tuttavia, è possibile usare un XML o un editor di testo per convertire un criterio di raccolta regole EXE in una raccolta regole ManagedInstaller.

1. Usa New-AppLockerPolicy per creare una regola EXE per il file che stai designando come programma di installazione gestito. In questo esempio viene creata una regola per l'estensione di gestione Intune di Microsoft usando il tipo di regola Publisher, ma è possibile usare qualsiasi tipo di regola AppLocker. Potrebbe essere necessario riformattare l'output per renderlo leggibile.

   Get-ChildItem ${env:ProgramFiles(x86)}'\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
   

2. Modificare manualmente il tipo di raccolta regole da "Exe" a "ManagedInstaller" e impostare EnforcementMode su "AuditOnly"

   Modifica:

   <RuleCollection Type="Exe" EnforcementMode="NotConfigured">
   

   a:

   <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
   

3. Modificare manualmente i criteri di AppLocker e aggiungere le raccolte regole EXE e DLL con almeno una regola per ognuna. Per garantire che i criteri possano essere applicati in modo sicuro nei sistemi che potrebbero già avere criteri di AppLocker attivi, è consigliabile usare una regola DENY benigna per bloccare un file binario falso e impostare EnforcementMode della raccolta regole su AuditOnly. Inoltre, poiché molti processi di installazione si basano sui servizi, è necessario abilitare il rilevamento dei servizi per ognuna di queste raccolte di regole. L'esempio seguente mostra un criterio parziale di AppLocker con le raccolte regole EXE e DLL configurate come consigliato.

   <RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
     <FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
       <Conditions>
         <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
       </Conditions>
     </FilePathRule>
     <RuleCollectionExtensions>
       <ThresholdExtensions>
         <Services EnforcementMode="Enabled" />
       </ThresholdExtensions>
       <RedstoneExtensions>
         <SystemApps Allow="Enabled"/>
       </RedstoneExtensions>
     </RuleCollectionExtensions>
   </RuleCollection>
   <RuleCollection Type="Exe" EnforcementMode="AuditOnly">
     <FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
       <Conditions>
         <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
       </Conditions>
     </FilePathRule>
     <RuleCollectionExtensions>
       <ThresholdExtensions>
         <Services EnforcementMode="Enabled" />
       </ThresholdExtensions>
       <RedstoneExtensions>
         <SystemApps Allow="Enabled"/>
       </RedstoneExtensions>
     </RuleCollectionExtensions>
   </RuleCollection>
   

4. Verificare i criteri di AppLocker. L'esempio seguente mostra un criterio di AppLocker completo che imposta Gestione Gestione configurazione e Microsoft Intune come programmi di installazione gestiti. Solo le raccolte regole di AppLocker per cui sono state definite regole effettive vengono incluse nel codice XML finale. Questa inclusione basata sulle condizioni garantisce l'unione dei criteri nei dispositivi che potrebbero già avere un criterio di AppLocker.

   <AppLockerPolicy Version="1">
     <RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
       <FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
         <Conditions>
           <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
         </Conditions>
       </FilePathRule>
       <RuleCollectionExtensions>
         <ThresholdExtensions>
           <Services EnforcementMode="Enabled" />
         </ThresholdExtensions>
         <RedstoneExtensions>
           <SystemApps Allow="Enabled"/>
         </RedstoneExtensions>
       </RuleCollectionExtensions>
     </RuleCollection>
     <RuleCollection Type="Exe" EnforcementMode="AuditOnly">
       <FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
         <Conditions>
           <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
         </Conditions>
       </FilePathRule>
       <RuleCollectionExtensions>
         <ThresholdExtensions>
           <Services EnforcementMode="Enabled" />
         </ThresholdExtensions>
         <RedstoneExtensions>
           <SystemApps Allow="Enabled"/>
         </RedstoneExtensions>
       </RuleCollectionExtensions>
     </RuleCollection>
     <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
       <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT&reg; INTUNE&trade; from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
         <Conditions>
             <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
               <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
             </FilePublisherCondition>
       </Conditions>
       </FilePublisherRule>
       <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
         <Conditions>
           <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
             <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
           </FilePublisherCondition>
         </Conditions>
       </FilePublisherRule>
       <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
         <Conditions>
           <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
             <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
             </FilePublisherCondition>
           </Conditions>
         </FilePublisherRule>
       </RuleCollection>
     </AppLockerPolicy>
   

5. Distribuire i criteri di configurazione del programma di installazione gestito di AppLocker. È possibile importare i criteri di AppLocker e distribuirli con Criteri di gruppo oppure usare uno script per distribuire i criteri con il cmdlet Set-AppLockerPolicy, come illustrato nel comando di PowerShell seguente.

   Set-AppLockerPolicy -XmlPolicy <AppLocker XML FilePath> -Merge -ErrorAction SilentlyContinue
   

6. Se si distribuiscono i criteri di AppLocker tramite script, usare appidtel.exe per configurare il servizio Identità applicazione AppLocker e il driver del filtro AppLocker.

   appidtel.exe start [-mionly]
   

   Specificare "-mionly" se non si prevede di usare Intelligent Security Graph (ISG).

Abilitare l'opzione del programma di installazione gestito nei criteri di controllo delle app

Per abilitare l'attendibilità per i file binari stabiliti dai programmi di installazione gestiti, è necessario specificare l'opzione "Abilitato: Programma di installazione gestito" nei criteri di Controllo app. Questa impostazione può essere definita usando il cmdlet Set-RuleOption con l'opzione 13.

Di seguito sono riportati i passaggi per creare un criterio Controllo app che consenta l'avvio di Windows e abiliti l'opzione del programma di installazione gestito.

1. Copiare il criterio DefaultWindows_Audit nella cartella di lavoro da "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"

2. Reimpostare l'ID criteri per assicurarsi che sia in un formato a più criteri e assegnargli un GUID diverso dai criteri di esempio. Assegnagli anche un nome descrittivo per facilitare l'identificazione.

   Ad esempio:

   Set-CIPolicyIdInfo -FilePath <XML filepath> -PolicyName "<friendly name>" -ResetPolicyID
   

3. Impostare l'opzione 13 (abilitata:programma di installazione gestito).

   Set-RuleOption -FilePath <XML filepath> -Option 13
   

4. Distribuire i criteri di Controllo delle app. Vedere Distribuzione dei criteri di Controllo delle applicazioni per le aziende.

Verificare la configurazione del programma di installazione gestito con un criterio di controllo delle app in modalità di controllo

Seguire questa procedura per confermare la configurazione del programma di installazione gestito usando un criterio di Controllo app in modalità di controllo.

1. Distribuire i criteri Controllo app in modalità di controllo con il programma di installazione gestito e le opzioni ISG abilitate. La modalità di controllo consente di osservare ciò che Controllo app autorizzerebbe senza bloccare le app.
2. Distribuire il programma di installazione gestito, ad esempio Microsoft Intune o Microsoft Configuration Manager, e installare le app che si desidera valutare tramite il programma di installazione gestito.
3. Conferma le autorizzazioni previste esaminando gli eventi di origine centralmente nella ricerca avanzata. Utilizzare i tipi di AppControlCodeIntegrityOriginAllowedazione di origine , AppControlCodeIntegrityOriginBlockedAppControlCodeIntegrityOriginAuditede per gli ID evento 3090, 3091 e 3092 come segnali che l'origine del programma di installazione gestito o la reputazione ISG hanno autorizzato un file.
4. Per la verifica locale, utilizzare i fsutil controlli nel programma di installazione gestito e nel riferimento tecnico ISG per esaminare gli attributi estesi nei file.
5. Dopo aver convalidato il comportamento previsto, è possibile spostare i criteri di controllo delle app dalla modalità di controllo alla modalità applicata con maggiore sicurezza che le app continueranno a essere eseguite normalmente.

Rimuovere la funzionalità del programma di installazione gestito

Per rimuovere la funzionalità del programma di installazione gestito dal dispositivo, è necessario rimuovere i criteri AppLocker del programma di installazione gestito dal dispositivo seguendo le istruzioni in Eliminare una regola di AppLocker: Cancellare i criteri di AppLocker in un singolo sistema o in sistemi remoti.

Articoli correlati

• Documentazione tecnica per programma di installazione gestito e ISG e guida alla risoluzione dei problemi