Контроль приложений Windows

Требования для работы Ansible с контролем приложений

Целевая версия Windows для Ansible должна быть Windows Server 2019 или Windows 10 Build 1803 либо более поздней. Это связано с тем, что для выполнения Ansible задач на узле Windows требуется функция Dynamic Code Security, добавленная в этой версии Windows.

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

Настройка контроля приложений и конфигурирование политик не рассматриваются в этой документации. Прочитайте документацию Microsoft по контролю приложений для Windows или контролю приложений с помощью PowerShell, чтобы узнать, как настраивать контроль приложений и политики. Мастер контроля приложений для бизнеса — это инструмент, упрощающий создание политик благодаря более удобному графическому интерфейсу.

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

• Целостность кода в пользовательском режиме (0 Enabled:UMCI) включена
• Отключение проверки сценариев (11 Disabled:Script Enforcement) не включено
• Безопасность динамического кода (19 Enabled:Dynamic Code Security) включена

Затем политика должна добавить сертификат в качестве доверенного издателя в User Mode Signing Scenario. Например, ниже приведена конфигурация политики с доверенным издателем:

<SiPolicy>
   ...
   <Signers>
      <Signer Name="Some Signer" ID="ID_SIGNER_S_0">
         <CertRoot Type="TBS" Value="1DBF60AFC6313593EDB09B6C6239BE493FF3461D4BD6D0A8C6E1723A12C06438F471BB7F6BAA73BD142D0698CEFF9DBB" />
         <CertPublisher Value="Some Publisher" />
      </Signer>
   </Signers>
   <SigningScenarios>
      <SigningScenario ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Kernel Mode Signing Scenario" Value="131">
         <ProductSigners />
      </SigningScenario>
      <SigningScenario ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="User Mode Signing Scenario" Value="12">
         <ProductSigners>
         <AllowedSigners>
            <AllowedSigner SignerId="ID_SIGNER_S_0" />
         </AllowedSigners>
         </ProductSigners>
      </SigningScenario>
   </SigningScenarios>
   ...
</SiPolicy>

После создания политики и того, как узел Windows начнёт доверять сертификату, используемому для подписания содержимого Ansible, политику можно применить.

Как подписать содержимое Ansible

После создания сертификата подписи кода и установки доверия к нему со стороны узла Windows его можно использовать для подписания сценариев, запускаемых Ansible. Сценарий PowerShell New-AnsiblePowerShellSignature.ps1 можно использовать для подписания как оболочки выполнения, с помощью которой Ansible вызывает модули, так и любых модулей PowerShell в коллекции Ansible. Для его запуска требуются:

• PowerShell 7.4 или более поздней версии
• Модуль PowerShell OpenAuthenticode
• Python с установленными Ansible и необходимыми коллекциями
• Доступ к сертификату и закрытому ключу, которым доверяет политика контроля приложений; обычно они хранятся в файле PFX

Чтобы подписать сценарии-оболочки PowerShell Ansible и модули в коллекции, можно использовать следующий сценарий PowerShell с загруженной выше функцией:

$certPassword = Read-Host "Enter the password for the certificate" -AsSecureString
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new(
   "wdac-cert.pfx"
   $certPassword)

$signingParams = @{
   Certificate = $cert

   Collection = @(
      # Includes all the builtin execution wrappers and scripts needed for Ansible
      'ansible.builtin'

      # Add any remaining collections used in the playbook like microsoft.ad, community.windows, etc.
      'ansible.windows'
      'microsoft.ad'
      'microsoft.iis'
      'community.windows'
   )

   # The URL of the Authenticode timestamp server to use for timestamping
   # the signature.
   # https://learn.microsoft.com/en-us/windows/win32/seccrypto/time-stamping-authenticode-signatures
   TimeStampServer = '...'
}
New-AnsiblePowerShellSignature @signingParams -Verbose

Коллекция ansible.builtin содержит встроенные сценарии выполнения, используемые в Ansible. Любые другие коллекции с модулями PowerShell, используемыми в плейбуке, следует добавить в параметр -Collection. Сценарий создаст сценарий powershell_signatures.psd1, подписанный сертификатом и содержащий хеши всех модулей коллекции, которым следует разрешить запуск. Он также создаст подпись для сценария-оболочки выполнения Ansible в каталоге установки Ansible, чтобы Ansible мог автоматически запускать сценарий, которому доверяет политика контроля приложений. Текущее поведение New-AnsiblePowerShellSignature заключается в подписании всех модулей коллекции и сценария-оболочки выполнения Ansible, даже если они могут содержать способ обхода ограничений. Рекомендуется пропускать с помощью параметра -Skip модули, которые не требуются в плейбуке, например:

New-AnsiblePowerShellSignature ... -Skip @(
    'ansible.windows.win_dsc'
    'ansible.windows.win_timezone'
)

Любое содержимое PowerShell, не входящее в коллекцию, например пользовательские сценарии или код, используемый в ansible.windows.win_powershell, необходимо подписывать вручную с помощью командлета Set-AuthenticodeSignature в Windows или Set-OpenAuthenticodeSignature через модуль OpenAuthenticode в Linux. Важно использовать эти подписанные сценарии так, чтобы их содержимое не изменялось, иначе подпись станет недействительной. Например, модуль ansible.builtin.script копирует файл сценария на целевой узел без изменений, сохраняя подпись, тогда как поиск ansible.builtin.file удаляет все оставшиеся символы перевода строки, если не используется параметр rstrip=False.

Известные различия в работе модулей

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

• ansible.windows.win_command может запускать только исполняемые файлы, которым доверяет политика контроля приложений. Если исполняемый файл не является доверенным, модуль завершится с ошибкой
• ansible.windows.win_shell будет выполнять весь код в режиме ограниченного языка (CLM), который накладывает строгие ограничения и может привести к сбою некоторых сценариев
• ansible.windows.win_powershell по умолчанию будет работать в CLM, если предоставленный сценарий не подписан
• ansible.builtin.script по умолчанию будет работать в CLM, если предоставленный сценарий не подписан
• ansible.windows.win_package может запускать только исполняемые файлы, которым доверяет политика контроля приложений, поэтому его работа зависит от исполняемого файла
• ansible.windows.win_updates в настоящее время не поддерживается и работать не будет

Другие модули, запускающие дочерние процессы или использующие неподписанное содержимое PowerShell, скорее всего, не будут работать с включённым контролем приложений.

При попытке запустить сценарий PowerShell с помощью ansible.windows.win_powershell или ansible.builtin.script сам сценарий необходимо подписать, иначе он будет выполняться в CLM.

- name: Test out LanguageMode
  ansible.windows.win_powershell:
    script: $ExecutionContext.SessionState.LanguageMode

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

При обращении к подписанному сценарию в Ansible важно использовать его так, чтобы содержимое не изменялось, поскольку это нарушит подпись. Например, разместите подписанный сценарий в локальном каталоге files, связанном с плейбуком/задачами, и укажите его одним из следующих способов:

- name: Run signed script through the script module
  ansible.builtin.script: signed-script.ps1

- name: Run signed script through win_powershell as a path
  ansible.windows.win_powershell:
    path: signed-script.ps1

- name: Run signed script through win_powershell as inline content
  ansible.windows.win_powershell:
    # rstrip=False is important so the last \r\n of the signature is not removed.
    script: "{{ lookup('ansible.builtin.file', 'signed-script.ps1', rstrip=False) }}"