Permitir aplicativos Win32 de linha de negócios em dispositivos do Modo S gerenciados por Intune

Observação

Alguns recursos do WDAC (Controle de Aplicativo) Windows Defender estão disponíveis apenas em versões específicas do Windows. Para obter mais informações, consulte Windows Defender disponibilidade de recursos do Controle de Aplicativo.

Você pode usar Microsoft Intune para implantar e executar aplicativos Win32 críticos e componentes do Windows normalmente bloqueados no modo S, em seu Windows 10 gerenciado por Intune em dispositivos de modo S. Por exemplo, PowerShell.exe.

Com Intune, você pode configurar dispositivos de modo S gerenciados usando uma política complementar do WDAC (Controle de Aplicativo) Windows Defender que expande a política base de modo S para autorizar os aplicativos que sua organização usa. Esse recurso altera a postura de segurança do modo S de "A Microsoft verificou todos os aplicativos" para "A Microsoft ou sua organização verificou todos os aplicativos".

Para obter uma visão geral e uma breve demonstração desse recurso, confira este vídeo:

Processo de autorização de política

Diagrama básico do fluxo de autorização de política.

As etapas gerais para expandir a política de base de modo S em seu Windows 10 gerenciado por Intune em dispositivos de modo S são gerar uma política suplementar, assinar essa política, carregar a política assinada para Intune e atribuí-la a grupos de usuários ou dispositivos. Como você precisa de acesso a cmdlets do PowerShell para gerar sua política suplementar, você deve criar e gerenciar suas políticas em um dispositivo de modo não S. Depois que a política tiver sido carregada no Intune, antes de implantar a política de forma mais ampla, atribua-a a um único Windows 10 de teste no dispositivo de modo S para verificar o funcionamento esperado.

  1. Gere uma política complementar com ferramentas WDAC.

    Essa política expande a política de base de modo S para autorizar mais aplicativos. Qualquer coisa autorizada pela política de base do modo S ou sua política suplementar pode ser executada. Suas políticas complementares podem especificar regras de filepath, editores confiáveis e muito mais.

    Para obter mais informações sobre como criar políticas complementares, consulte Implantar várias políticas do WDAC. Para obter mais informações sobre o tipo certo de regras a serem criadas para sua política, consulte Implantar regras de política do WDAC e regras de arquivo.

    As instruções a seguir são um conjunto básico para criar uma política complementar do modo S:

    • Crie uma nova política de base usando o New-CIPolicy.

      New-CIPolicy -MultiplePolicyFormat -ScanPath <path> -UserPEs -FilePath "<path>\SupplementalPolicy.xml" -Level FilePublisher -Fallback SignedVersion,Publisher,Hash
      
    • Altere-a para uma política complementar usando Set-CIPolicyIdInfo.

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

      Para políticas que complementam a política de base do modo S, use -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784. Essa ID é a ID da política de modo S.

    • Coloque a política no modo de impor usando Set-RuleOption.

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

      Esse comando exclui o qualificador 'modo de auditoria'.

    • Como você está assinando sua política, você deve autorizar o certificado de assinatura usado para assinar a política. Opcionalmente, também autorize um ou mais signatários extras que podem ser usados para assinar atualizações na política no futuro. A próxima etapa do processo geral, Assinar a política, descreve-a com mais detalhes.

      Para adicionar o certificado de assinatura à política WDAC, use Add-SignerRule.

      Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
      
    • Converter em .bin usando ConvertFrom-CIPolicy.

      ConvertFrom-CIPolicy -XmlFilePath "<path>\SupplementalPolicy.xml" -BinaryFilePath "<path>\SupplementalPolicy.bin>
      
  2. Assine a política.

    As políticas de modo S suplementar devem ser assinadas digitalmente. Para assinar sua política, use a PKI (Infraestrutura de Chave Pública) personalizada da sua organização. Para obter mais informações sobre como assinar usando uma AC interna, consulte Criar um certificado de assinatura de código para WDAC.

    Depois de assinar, renomeie sua política para {PolicyID}.p7b. Obtenha o PolicyID da política suplementar XML.

  3. Implante a política suplementar assinada usando Microsoft Intune.

    Acesse o portal Microsoft Intune, acesse a página Aplicativos cliente e selecione Políticas complementares do modo S. Carregue a política assinada para Intune e atribua-a a grupos de usuários ou dispositivos. Intune gera tokens de autorização para o locatário e dispositivos específicos. Intune então implanta o token de autorização correspondente e a política suplementar para cada dispositivo no grupo atribuído. Juntos, esses tokens e políticas expandem a política de base de modo S no dispositivo.

Observação

Ao atualizar sua política suplementar, verifique se o número da nova versão é estritamente maior que o anterior. Intune não permite o uso do mesmo número de versão. Para obter mais informações sobre como definir o número da versão, consulte Set-CIPolicyVersion.

Processo padrão para implantar aplicativos por meio de Intune

Diagrama básico para implantar aplicativos por meio de Intune.

Para obter mais informações sobre o procedimento existente de empacotamento de catálogos assinados e implantação de aplicativo, consulte Gerenciamento de aplicativos Win32 em Microsoft Intune.

Opcional: processo para implantar aplicativos usando catálogos

Diagrama básico para implantar aplicativos usando catálogos.

Sua política suplementar pode ser usada para relaxar significativamente a política de base do modo S, mas há compensações de segurança que você deve considerar ao fazê-lo. Por exemplo, você pode usar uma regra de signatário para confiar em um signatário externo, mas que autoriza todos os aplicativos assinados por esse certificado, o que pode incluir aplicativos que você não deseja permitir também.

Em vez de autorizar os signatários externos à sua organização, Intune tem funcionalidade para facilitar a autorização de aplicativos existentes usando catálogos assinados. Esse recurso não requer reempacotar ou acessar o código-fonte. Ele funciona para aplicativos que podem não ser assinados ou até mesmo aplicativos assinados quando você não deseja confiar em todos os aplicativos que podem compartilhar o mesmo certificado de assinatura.

O processo básico é gerar um arquivo de catálogo para cada aplicativo usando o Inspetor de Pacotes e, em seguida, assinar os arquivos de catálogo usando um PKI personalizado. Para autorizar o certificado de assinatura de catálogo na política suplementar, use o cmdlet Add-SignerRule PowerShell, conforme mostrado anteriormente na etapa 1 do processo de autorização de política. Depois disso, use o processo Standard para implantar aplicativos por meio de Intune descrito anteriormente. Para obter mais informações sobre como gerar catálogos, consulte Implantar arquivos de catálogo para dar suporte ao WDAC.

Observação

Sempre que um aplicativo é atualizado, você precisa implantar um catálogo atualizado. Tente evitar o uso de arquivos de catálogo para aplicativos que atualizam automaticamente e direcione os usuários a não atualizar aplicativos por conta própria.

Política de exemplo

A política a seguir é um exemplo que permite depuradores de kernel, ISE do PowerShell e Editor de Registro. Ele também demonstra como especificar os certificados de assinatura de código e assinatura de política da sua organização.

<?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>

Remoção de política

Para reverter usuários a uma política de modo S não modificada, remova um usuário ou usuários do grupo de Intune de destino que recebeu a política. Essa ação dispara uma remoção da política e do token de autorização do dispositivo.

Você também pode excluir uma política suplementar por meio de 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 um Windows 10 no dispositivo de modo S com um token de autorização de política e política suplementar for revertido da atualização de 1909 para o build de 1903, ele não reverter para o modo S bloqueado até a próxima atualização da política. Para obter uma alteração imediata em um estado de modo S bloqueado, os profissionais de TI devem excluir todos os tokens em %SystemRoot%\System32\CI\Tokens\Active.