Share via

Consenti app Win32 line-of-business nei dispositivi in modalità S gestiti Intune

Nota

Alcune funzionalità di Windows Defender controllo delle applicazioni (WDAC) sono disponibili solo in versioni specifiche di Windows. Per altre informazioni, vedere Windows Defender disponibilità delle funzionalità di Controllo applicazioni.

È possibile usare Microsoft Intune per distribuire ed eseguire applicazioni Win32 critiche e i componenti Windows normalmente bloccati in modalità S, nei Windows 10 gestiti da Intune nei dispositivi in modalità S. Ad esempio, PowerShell.exe.

Con Intune, è possibile configurare i dispositivi in modalità S gestita usando un criterio supplementare WDAC (Windows Defender Application Control) che espande i criteri di base della modalità S per autorizzare le app usate dall'organizzazione. Questa funzionalità modifica il comportamento di sicurezza della modalità S da "Microsoft ha verificato ogni app" a "Microsoft o l'organizzazione ha verificato ogni app".

Per una panoramica e una breve demo di questa funzionalità, vedere questo video:

Processo di autorizzazione dei criteri

Diagramma di base del flusso di autorizzazione dei criteri.

I passaggi generali per espandere i criteri di base della modalità S nei Windows 10 gestiti da Intune nei dispositivi in modalità S sono la generazione di un criterio supplementare, la firma di tale criterio, il caricamento dei criteri firmati in Intune e l'assegnazione a gruppi di utenti o dispositivi. Poiché è necessario accedere ai cmdlet di PowerShell per generare i criteri supplementari, è necessario creare e gestire i criteri in un dispositivo in modalità non S. Dopo aver caricato il criterio in Intune, prima di distribuire il criterio in modo più ampio, assegnarlo a un singolo Windows 10 di test nel dispositivo in modalità S per verificare il funzionamento previsto.

  1. Generare un criterio supplementare con gli strumenti WDAC.

    Questo criterio espande i criteri di base della modalità S per autorizzare altre applicazioni. Qualsiasi elemento autorizzato dai criteri di base della modalità S o dai criteri supplementari può essere eseguito. I criteri supplementari possono specificare regole di percorso file, autori attendibili e altro ancora.

    Per altre informazioni sulla creazione di criteri supplementari, vedere Distribuire più criteri WDAC. Per altre informazioni sul tipo corretto di regole da creare per i criteri, vedere Distribuire le regole dei criteri WDAC e le regole dei file.

    Le istruzioni seguenti sono un set di base per la creazione di un criterio supplementare in modalità S:

    • Creare un nuovo criterio di base usando New-CIPolicy.

      New-CIPolicy -MultiplePolicyFormat -ScanPath <path> -UserPEs -FilePath "<path>\SupplementalPolicy.xml" -Level FilePublisher -Fallback SignedVersion,Publisher,Hash

    • Modificarlo in un criterio supplementare usando Set-CIPolicyIdInfo.

      Set-CIPolicyIdInfo -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784 -FilePath "<path>\SupplementalPolicy.xml"

      Per i criteri che integrano i criteri di base della modalità S, usare -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784. Questo ID è l'ID criterio della modalità S.

    • Impostare i criteri in modalità imponi tramite Set-RuleOption.

      Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 -Delete

      Questo comando elimina il qualificatore "modalità di controllo".

    • Poiché si firmano i criteri, è necessario autorizzare il certificato di firma usato per firmare il criterio. Facoltativamente, autorizzare anche uno o più firmatari aggiuntivi che possono essere usati per firmare gli aggiornamenti ai criteri in futuro. Il passaggio successivo del processo complessivo, Firma i criteri, lo descrive in modo più dettagliato.

      Per aggiungere il certificato di firma ai criteri WDAC, usare Add-SignerRule.

      Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update

    • Eseguire la conversione in .bin usando ConvertFrom-CIPolicy.

      ConvertFrom-CIPolicy -XmlFilePath "<path>\SupplementalPolicy.xml" -BinaryFilePath "<path>\SupplementalPolicy.bin>

  2. Firmare i criteri.

    I criteri di modalità S supplementari devono essere firmati digitalmente. Per firmare i criteri, usare l'infrastruttura a chiave pubblica (PKI) personalizzata dell'organizzazione. Per altre informazioni sulla firma tramite una CA interna, vedere Creare un certificato di firma del codice per WDAC.

    Suggerimento

    Per altre informazioni, vedere Firma del codice di Azure, democratizzazione dell'attendibilità per sviluppatori e consumer.

    Dopo averlo firmato, rinominare i criteri in {PolicyID}.p7b. Ottenere policyID dal codice XML dei criteri supplementari.

  3. Distribuire i criteri supplementari firmati usando Microsoft Intune.

    Passare al portale di Microsoft Intune, passare alla pagina App client e selezionare Criteri supplementari della modalità S. Caricare i criteri firmati per Intune e assegnarli ai gruppi di utenti o dispositivi. Intune genera token di autorizzazione per il tenant e dispositivi specifici. Intune quindi distribuisce il token di autorizzazione e i criteri supplementari corrispondenti a ogni dispositivo nel gruppo assegnato. Insieme, questi token e criteri espandono i criteri di base della modalità S nel dispositivo.

Nota

Quando si aggiornano i criteri supplementari, assicurarsi che il nuovo numero di versione sia rigorosamente maggiore di quello precedente. Intune non consente l'uso dello stesso numero di versione. Per altre informazioni sull'impostazione del numero di versione, vedere Set-CIPolicyVersion.

Processo standard per la distribuzione di app tramite Intune

Diagramma di base per la distribuzione di app tramite Intune.

Per altre informazioni sulla procedura esistente relativa alla creazione di pacchetti di cataloghi firmati e alla distribuzione di app, vedere Gestione delle app Win32 in Microsoft Intune.

Facoltativo: processo per la distribuzione di app tramite cataloghi

Diagramma di base per la distribuzione di app tramite cataloghi.

I criteri supplementari possono essere usati per ridurre significativamente il criterio di base modalità S, ma ci sono compromessi di sicurezza che è necessario prendere in considerazione in questo modo. Ad esempio, è possibile usare una regola del firmatario per considerare attendibile un firmatario esterno, ma che autorizza tutte le app firmate da tale certificato, che possono includere anche le app che non si vuole consentire.

Invece di autorizzare i firmatari esterni all'organizzazione, Intune dispone di funzionalità che semplificano l'autorizzazione delle applicazioni esistenti tramite cataloghi firmati. Questa funzionalità non richiede il riconfezionamento o l'accesso al codice sorgente. Funziona per le app che potrebbero non essere firmate o anche app firmate quando non si vuole considerare attendibili tutte le app che potrebbero condividere lo stesso certificato di firma.

Il processo di base consiste nel generare un file di catalogo per ogni app usando Controllo pacchetti, quindi firmare i file di catalogo usando un'infrastruttura a chiave pubblica personalizzata. Per autorizzare il certificato di firma del catalogo nei criteri supplementari, usare il cmdlet Di PowerShell Add-SignerRule come illustrato in precedenza nel passaggio 1 del processo di autorizzazione dei criteri. Successivamente, usare il processo Standard per distribuire le app tramite Intune descritte in precedenza. Per altre informazioni sulla generazione di cataloghi, vedere Distribuire file di catalogo per supportare WDAC.

Nota

Ogni volta che un'app viene aggiornata, è necessario distribuire un catalogo aggiornato. Provare a evitare di usare i file di catalogo per le applicazioni che aggiornano automaticamente e indirizzare gli utenti a non aggiornare le applicazioni autonomamente.

Criteri di esempio

I criteri seguenti sono un esempio che consente i debugger del kernel, PowerShell ISE e Editor del Registro di sistema. Viene inoltre illustrato come specificare i certificati di firma del codice e firma dei criteri dell'organizzazione.

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
  <VersionEx>10.0.0.0</VersionEx>
  <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
  <!--Standard S mode GUID-->
  <BasePolicyID>{5951A96A-E0B5-4D3D-8FB8-3E5B61030784}</BasePolicyID>
  <!--Unique policy GUID-->
  <PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>
  <!--EKUS-->
  <EKUs />
  <!--File Rules-->
  <FileRules>
    <!--Allow kernel debuggers-->
    <Allow ID="ID_ALLOW_CBD_0" FriendlyName="cdb.exe" FileName="CDB.Exe" />
    <Allow ID="ID_ALLOW_KD_0" FriendlyName="kd.exe" FileName="kd.Exe" />
    <Allow ID="ID_ALLOW_WINDBG_0" FriendlyName="windbg.exe" FileName="windbg.Exe" />
    <Allow ID="ID_ALLOW_MSBUILD_0" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe" />
    <Allow ID="ID_ALLOW_NTSD_0" FriendlyName="ntsd.exe" FileName="ntsd.Exe" />
    <!--Allow PowerShell ISE and Registry Editor-->
    <Allow ID="ID_ALLOW_POWERSHELLISE_0" FriendlyName="powershell_ise.exe" FileName="powershell_ise.exe" />
    <Allow ID="ID_ALLOW_REGEDIT_0" FriendlyName="regedit.exe" FileName="regedit.exe" />
  </FileRules>
  <!--Signers-->
  <Signers>
    <!--info of the certificate you will use to do any code/catalog signing-->
    <Signer ID="EXAMPLE_ID_SIGNER_CODE" Name="Example Code Signing Certificate Friendly Name">
      <CertRoot Type="TBS" Value="<value>" />
    </Signer>
    
    <!--info of the certificate you will use to sign your policy-->
    <Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
      <CertRoot Type="TBS" Value="<value>" />
    </Signer>
  </Signers>
  <!--Driver Signing Scenarios-->
  <SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Example Name">
      <ProductSigners />
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="Example Name">
      <ProductSigners>
        <AllowedSigners>
          <AllowedSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
        </AllowedSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_CBD_0" />
          <FileRuleRef RuleID="ID_ALLOW_KD_0" />
          <FileRuleRef RuleID="ID_ALLOW_WINDBG_0" />
          <FileRuleRef RuleID="ID_ALLOW_MSBUILD_0" />
          <FileRuleRef RuleID="ID_ALLOW_NTSD_0" />
          <FileRuleRef RuleID="ID_ALLOW_POWERSHELLISE_0" />
          <FileRuleRef RuleID="ID_ALLOW_REGEDIT_0" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
  </SigningScenarios>
  <!--Specify one or more certificates that can be used to sign updated policy-->
  <UpdatePolicySigners>
    <UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
  </UpdatePolicySigners>
  <!--Specify one or more codesigning certificates to trust-->
  <CiSigners>
    <CiSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
  </CiSigners>
  <!-- example remove core isolation a.k.a. Hypervisor Enforced Code Integrity (HVCI) options, consider enabling if your system supports it-->
  <HvciOptions>0</HvciOptions>
  <Settings>
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
      <Value>
        <String>Example Policy Name</String>
      </Value>
    </Setting>
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
      <Value>
        <String>Example-Policy-10.0.0.0</String>
      </Value>
    </Setting>
  </Settings>
</SiPolicy>

Rimozione dei criteri

Per ripristinare gli utenti a un criterio di modalità S non modificato, rimuovere un utente o un utente dal gruppo di Intune di destinazione che ha ricevuto i criteri. Questa azione attiva la rimozione del criterio e del token di autorizzazione dal dispositivo.

È anche possibile eliminare un criterio supplementare tramite Intune.

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
  <VersionEx>10.0.0.1</VersionEx>
  <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
  <BasePolicyID>{5951A96A-E0B5-4D3D-8FB8-3E5B61030784}</BasePolicyID>
  <PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>
  <Rules>
  </Rules>
  <!--EKUS-->
  <EKUs />
  <!--File Rules-->

  <!--Signers-->
  <Signers>
    <!--info of the certificate you will use to sign your policy-->
    <Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
      <CertRoot Type="TBS" Value="<value>" />
    </Signer>
  </Signers>
  <!--Driver Signing Scenarios-->
  <SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="KMCI">
      <ProductSigners>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="UMCI">
      <ProductSigners>
      </ProductSigners>
    </SigningScenario>
  </SigningScenarios>
  <UpdatePolicySigners>
    <UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
  </UpdatePolicySigners>
  <!-- example remove core isolation a.k.a. Hypervisor Enforced Code Integrity (HVCI) options, consider enabling if your system is supported-->
  <HvciOptions>0</HvciOptions>
  <Settings>
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
      <Value>
        <String>Example Policy Name - Empty</String>
      </Value>
    </Setting>
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
      <Value>
        <String>Example-Policy-Empty-10.0.0.1</String>
      </Value>
    </Setting>
  </Settings>
</SiPolicy>

Errata

Se viene eseguito il rollback di un Windows 10 in modalità S con un token di autorizzazione dei criteri e criteri supplementari dall'aggiornamento 1909 alla build 1903, non verrà ripristinata la modalità S bloccata fino al successivo aggiornamento dei criteri. Per ottenere una modifica immediata a uno stato di modalità S bloccato, i professionisti IT devono eliminare tutti i token in %SystemRoot%\System32\CI\Tokens\Active.