Поделиться через

Разрешение бизнес-приложений Win32 на устройствах S-режима, управляемых Intune

Примечание.

Некоторые возможности управления приложениями Защитник Windows (WDAC) доступны только в определенных версиях Windows. Дополнительные сведения см. в разделе доступность функций управления приложениями Защитник Windows.

Вы можете использовать Microsoft Intune для развертывания и запуска критически важных приложений Win32 и компонентов Windows, которые обычно блокируются в S-режиме, на управляемых Intune Windows 10 в S-режиме. Например, PowerShell.exe.

С помощью Intune можно настроить управляемые устройства S-режима с помощью дополнительной политики управления приложениями Защитник Windows (WDAC), которая расширяет базовую политику S-режима для авторизации приложений, которые используются в вашей организации. Эта функция изменяет состояние безопасности S-режима с "Корпорация Майкрософт проверила каждое приложение" на "Майкрософт или ваша организация проверила каждое приложение".

Общие сведения об этой функции и краткие демонстрации см. в этом видео:

Процесс авторизации политики

Базовая схема потока авторизации политики.

Общие действия по расширению базовой политики S-режима на управляемых Intune Windows 10 на устройствах S-режима— создать дополнительную политику, подписать эту политику, отправить подписанную политику в Intune и назначить ее группам пользователей или устройств. Так как для создания дополнительной политики требуется доступ к командлетам PowerShell, следует создавать политики и управлять ими на устройстве, отличном от S-режима. После отправки политики в Intune перед развертыванием политики в более широком смысле назначьте ее одной тестовой Windows 10 на устройстве S-режима, чтобы проверить ожидаемую работу.

  1. Создайте дополнительную политику с помощью инструментов WDAC.

    Эта политика расширяет базовую политику S-режима, чтобы авторизовать больше приложений. Все, что разрешено базовой политикой S-режима или дополнительной политикой, разрешено выполнять. Дополнительные политики могут указывать правила пути к файлам, доверенных издателей и многое другое.

    Дополнительные сведения о создании дополнительных политик см. в статье Развертывание нескольких политик WDAC. Дополнительные сведения о правильном типе правил для политики см. в статье Развертывание правил политики WDAC и правил файлов.

    Ниже приведены инструкции по созданию дополнительной политики S-режима.

    • Создайте новую базовую политику с помощью Команды New-CIPolicy.

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

    • Измените его на дополнительную политику с помощью Set-CIPolicyIdInfo.

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

      Для политик, дополняющих базовую политику S-режима, используйте -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784. Этот идентификатор является идентификатором политики режима S.

    • Переведите политику в режим принудительного применения с помощью Set-RuleOption.

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

      Эта команда удаляет квалификатор "режим аудита".

    • Так как вы подписываете политику, необходимо авторизовать сертификат подписи, используемый для подписи политики. При необходимости также авторизуйте одного или нескольких дополнительных подписывающего, которые можно использовать для подписывания обновлений политики в будущем. На следующем шаге общего процесса, Подписывая политику, она описывается более подробно.

      Чтобы добавить сертификат подписи в политику WDAC, используйте Add-SignerRule.

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

    • Преобразовать в .bin с помощью ConvertFrom-CIPolicy.

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

  2. Подпишите политику.

    Дополнительные политики S-режима должны иметь цифровую подпись. Чтобы подписать политику, используйте настраиваемую инфраструктуру открытых ключей (PKI) организации. Дополнительные сведения о подписи с помощью внутреннего ЦС см. в статье Создание сертификата подписи кода для WDAC.

    Совет

    Дополнительные сведения см. в статье Подписывание кода Azure, демократизация доверия для разработчиков и потребителей.

    После подписания переименуйте политику в {PolicyID}.p7b. Получите PolicyID из XML-файла дополнительной политики.

  3. Разверните подписанную дополнительную политику с помощью Microsoft Intune.

    Перейдите на портал Microsoft Intune, перейдите на страницу Клиентские приложения и выберите дополнительные политики режима S. Отправьте подписанную политику в Intune и назначьте ее группам пользователей или устройств. Intune создает маркеры авторизации для клиента и определенных устройств. Intune затем развертывает соответствующий маркер авторизации и дополнительную политику на каждом устройстве в назначенной группе. Вместе эти маркеры и политики расширяют базовую политику S-режима на устройстве.

Примечание.

При обновлении дополнительной политики убедитесь, что номер новой версии строго больше предыдущей. Intune не позволяет использовать один и тот же номер версии. Дополнительные сведения о настройке номера версии см. в разделе Set-CIPolicyVersion.

Стандартный процесс развертывания приложений через Intune

Базовая схема развертывания приложений с помощью Intune.

Дополнительные сведения о существующей процедуре упаковки подписанных каталогов и развертывания приложений см. в статье Управление приложениями Win32 в Microsoft Intune.

Необязательно. Процесс развертывания приложений с помощью каталогов

Базовая схема развертывания приложений с помощью каталогов.

Дополнительная политика может быть использована для существенного ослаблять базовую политику S-режима, но при этом необходимо учитывать компромиссы по безопасности. Например, можно использовать правило подписывающих, чтобы доверять внешнему подписывшему, но которое разрешает все приложения, подписанные этим сертификатом, которые могут включать приложения, которые вы также не хотите разрешить.

Вместо авторизации подписывателей, внешних по своей организации, у Intune есть функциональные возможности, упрощающие авторизацию существующих приложений с помощью подписанных каталогов. Для этой функции не требуется переупаковка или доступ к исходному коду. Он подходит для приложений, которые могут быть неподписанными или даже подписанными, если вы не хотите доверять всем приложениям, которые могут использовать один и тот же сертификат подписи.

Основной процесс заключается в создании файла каталога для каждого приложения с помощью инспектора пакетов, а затем подписывая файлы каталога с помощью пользовательской PKI. Чтобы авторизовать сертификат подписи каталога в дополнительной политике, используйте командлет PowerShell Add-SignerRule , как показано выше на шаге 1 процесса авторизации политики. После этого используйте стандартный процесс развертывания приложений с помощью Intune, описанных ранее. Дополнительные сведения о создании каталогов см. в разделе Развертывание файлов каталога для поддержки WDAC.

Примечание.

При каждом обновлении приложения необходимо развертывать обновленный каталог. Старайтесь не использовать файлы каталога для приложений, которые обновляются автоматически, и не рекомендует пользователям самостоятельно обновлять приложения.

Пример политики

Следующая политика является примером, который разрешает отладчики ядра, среду интегрированной среды сценариев PowerShell и Редактор реестра. В ней также показано, как указать сертификаты подписи кода и политики вашей организации.

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

Удаление политики

Чтобы отменить изменения пользователей в неизмененную политику S-режима, удалите пользователя или пользователей из целевой группы Intune, которая получила политику. Это действие активирует удаление политики и маркера авторизации с устройства.

Вы также можете удалить дополнительную политику с помощью 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>

Опечатки

Если Windows 10 в S-режиме устройства с маркером авторизации политики и дополнительной политикой откатывается с обновления 1909 до сборки 1903, он не будет отменить изменения заблокирован режим S до следующего обновления политики. Чтобы немедленно изменить состояние S в заблокированном режиме, ИТ-специалисты должны удалить все маркеры в папке %SystemRoot%\System32\CI\Token\Active.