Политика выполнения PowerShell и подпись скриптов — как отказаться от Bypass в роли постоянной заглушки

«На новом ПК скрипт не запускается: „выполнение сценариев в данной системе отключено…“». «Добавили -ExecutionPolicy Bypass — заработало, теперь так прописано во всех задачах». «Файл .ps1 из общей папки выдаёт ошибку подписи только на одном компьютере». Политика выполнения PowerShell — почти неизбежный барьер, когда внутри компании начинают автоматизировать работу. И на многих площадках без понимания механизма копится практика «закрыть проблему Bypass».

Сложность в том, что легко неверно понять, что именно эта политика защищает. Одни принимают её за функцию безопасности, закручивают слишком туго — и останавливается работа. Другие решают, что «всё равно обходится», ставят Bypass везде и снимают последний защитный механизм против случайного запуска. Обе крайности отпадают, если знать, как устроена политика.

Статья рассчитана на сотрудников ИТ малых и средних компаний и на тех, кто автоматизирует внутренние рутинные задачи в PowerShell. По официальной документации разберём, чем на самом деле является политика выполнения, как устроен приоритет областей действия, как она связана с Zone.Identifier (Mark of the Web) и как раздавать скрипты с подписью.

1. Сначала выводы

• Политика выполнения — защитный механизм, а не граница безопасности. Официальная документация прямо говорит: «это не система безопасности, ограничивающая действия пользователя» и «её легко обойти, введя содержимое скрипта в командную строку». Цель — задать базовые правила и не дать случайно запустить не то, что собирались.¹
• Политика влияет только на запуск скриптов. Интерактивные команды всегда доступны. В Windows PowerShell 5.1 по умолчанию на клиентских ОС стоит Restricted (скрипты запрещены), на Windows Server — RemoteSigned. В PowerShell 7 по умолчанию считается RemoteSigned.²¹
• Политику задают в пяти областях действия. Приоритет: MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. MachinePolicy и UserPolicy существуют только для групповой политики: Set-ExecutionPolicy их не меняет, параметр командной строки тоже не перекрывает.¹³
• RemoteSigned требует подпись только у скриптов «из интернета». Происхождение смотрят по альтернативному потоку данных Zone.Identifier (Mark of the Web). Проверили содержимое — сняли поток Unblock-File и запустили, политику не трогая.¹⁴
• AllSigned требует подпись доверенного издателя у всех скриптов, включая созданные локально. Подпись ставит Set-AuthenticodeSignature и встраивает её в конец файла блоком комментариев # SIG #.¹⁵
• При подписи всегда ставьте метку времени (-TimestampServer). С ней скрипт остаётся действительным после истечения сертификата. У большинства сертификатов подписи кода срок — год; без метки это ежегодная бомба замедленного действия.⁶⁵
• Самоподписанный сертификат — только для тестов. Скрипт, подписанный таким сертификатом, на других компьютерах не запускается. Для раздачи в организации нужен сертификат подписи кода от удостоверяющего центра (внутреннего ЦС или коммерческого).⁵⁷
• Чтобы управлять политикой в организации, задайте её централизованно параметром групповой политики «Включить выполнение сценариев». Этот параметр имеет приоритет над всеми областями действия на стороне PowerShell.¹

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 18, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что это на самом деле: не «граница безопасности», а «защитный механизм»

Сначала исходная посылка. Формулировка официальной документации (about_Execution_Policies) прямая. Политика выполнения — это «функция безопасности» (safety feature): она задаёт условия, при которых PowerShell загружает файлы конфигурации и выполняет скрипты, и «не является системой безопасности, ограничивающей действия пользователя». Даже тот, кому запрещено запускать скрипт, выполнит ту же обработку, вставив содержимое в командную строку. Роль политики — задать базовые правила и не дать нарушить их непреднамеренно.¹ Во вводной документации то же самое: «это не граница безопасности; она не остановит пользователя, который сознательно пытается запустить скрипт».²

Если принять эту рамку, становится ясно, как проектировать эксплуатацию. Оба утверждения ошибочны: и «ужесточили политику — атаки закрыты», и «раз обходится, смысла нет». Защита от атак — работа другого уровня (контроль приложений, минимизация прав, журналы аудита). Политика выполнения отвечает за предотвращение случайного запуска.⁸

Различия основных политик выглядят так.¹

Часто не замечают, что Restricted останавливает не только рабочие скрипты, но и загрузку профилей (.ps1), модулей (.psm1) и файлов конфигурации форматирования (.ps1xml).¹ Типичное обращение: «на новом компьютере не загружается профиль» — и причина оказывается в политике выполнения.

3. Области действия и приоритет: почему «настроил, а ничего не изменилось»

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

Стандартный способ разобрать «настроил, а ничего не изменилось» — смотреть не действующее значение, а полный список.

# Смотрите не только действующую политику, но и то, какая область её задаёт
Get-ExecutionPolicy -List

# Пример: LocalMachine стоит AllSigned, но побеждает RemoteSigned из CurrentUser
#         Scope ExecutionPolicy
#         ----- ---------------
# MachinePolicy       Undefined
#    UserPolicy       Undefined
#       Process       Undefined
#   CurrentUser    RemoteSigned
#  LocalMachine       AllSigned

# Чтобы изменить только своё окружение, удобна CurrentUser — права администратора не нужны
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

CurrentUser выше LocalMachine, поэтому в примере действующая политика — RemoteSigned.¹ Set-ExecutionPolicy по умолчанию пишет в LocalMachine и требует права администратора; в CurrentUser обычный пользователь может изменить её сам.³

Главный инструмент управления в организации — групповая политика. Параметр «Включить выполнение сценариев» (Turn on Script Execution) имеет приоритет над всеми областями, заданными на стороне PowerShell. Если его отключить, эффект как у Restricted; если включить, выбирают один из вариантов: «Разрешить все сценарии» (Unrestricted), «Разрешить локальные сценарии и подписанные удалённые сценарии» (RemoteSigned) или «Разрешить только подписанные сценарии» (AllSigned). Параметр лежит в административных шаблонах, в разделе Компоненты Windows\Windows PowerShell. Конфигурация компьютера сильнее конфигурации пользователя.¹ В среде под GPO Set-ExecutionPolicy настройку сохранит, но она не будет действовать, и появится сообщение о конфликте.³

Отсюда один важный вывод. Если политикой управляет GPO, -ExecutionPolicy Bypass в задаче или ярлыке не действует. Документация прямо говорит: указание области Process побеждает LocalMachine/CurrentUser, но не групповую политику.¹ Приём «пропиши Bypass — как-нибудь заработает» срабатывает только там, где организация политикой выполнения вообще не управляет.

4. Zone.Identifier (Mark of the Web) и Unblock-File

«Удалённый (из интернета)» в RemoteSigned определяется не местом файла, а меткой. Браузеры и похожие программы прикрепляют к скачанным файлам альтернативный поток данных и помечают их как «файл из интернета».¹ Этот поток — Zone.Identifier, в нём значение 3, то есть интернет-зона. Это и есть Mark of the Web.⁴

Альтернативные потоки данных (Alternate Data Streams) — функция NTFS. Один файл на NTFS может нести несколько потоков; привычное «содержимое файла» лежит в безымянном потоке по умолчанию. Отдельно к файлу можно прикрепить именованный поток в виде имя_файла:имя_потока.⁹ Zone.Identifier — один из таких потоков, поэтому текст скрипта не меняется ни на байт, а возможность запуска — меняется. Один и тот же файл на разных машинах то работает, то нет именно из-за этого. Если файл прошёл через файловую систему без NTFS (например FAT32 на USB-накопителе), поток теряется, метка исчезает — и скрипт вдруг начинает запускаться.

В среде RemoteSigned неподписанный скрипт с этой меткой блокируется ошибкой «не имеет цифровой подписи». Действуют в два шага.

# 1) Сначала посмотрите, какие файлы заблокированы (только чтение, безопасно)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

# 2) Снимайте блокировку только с тех файлов, чьё содержимое вы проверили и признали безопасным
#    (Unblock-File удаляет поток Zone.Identifier; сама политика выполнения не меняется)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1

Unblock-File удаляет альтернативный поток Zone.Identifier — это та же операция, что кнопка «Разблокировать» (Unblock) в свойствах файла в Проводнике. Суть в том, что пропускают только проверенные файлы, политику не ослабляя.⁴ Официальная документация требует как обязательный шаг: перед использованием проверить файл и источник и убедиться, что они безопасны.⁴³

Есть ловушка и в обратную сторону. Не каждый способ получения файла ставит Mark of the Web. Прямо сказано: файлы, скачанные через curl.exe, Invoke-WebRequest или Invoke-RestMethod, метку интернет-зоны иногда не получают.¹ RemoteSigned не гарантирует, что «все опасные скачанные файлы будут остановлены» — именно поэтому это защитный механизм, а не граница. Есть и предупреждение: в системах, которые не различают UNC-пути и интернет-пути, скрипт на общей папке при RemoteSigned иногда отклоняется.¹ Если «.ps1 из общей папки останавливается только на части компьютеров», смотрите настройки зон и наличие Zone.Identifier.

Похожий симптом у скачанных исполняемых файлов (.exe) даёт SmartScreen — об этом в статье «Почему Windows показывает «Windows защитил ваш компьютер»».

5. Практика подписи скриптов: Set-AuthenticodeSignature и метка времени

Чтобы перейти к AllSigned или подписывать раздаваемые файлы в среде RemoteSigned, нужен сертификат подписи кода. Способы получения сводятся к трём.⁵

Официальная документация даёт ту же картину: «сертификат удостоверяющего центра доверяют и на других компьютерах», а «самостоятельно созданный бесплатен, но только для вашего компьютера и только для тестов».⁵ Если цель — внутренняя раздача, на практике сертификат подписи кода выдают внутренним ЦС, например Active Directory Certificate Services (AD CS).

Если выдаёте через внутренний ЦС: что делать дальше

Фраза «внутренний ЦС — реалистичный вариант» сама по себе не даёт следующего шага, поэтому распишем порядок. AD CS — роль Windows Server, которая даёт инфраструктуру открытых ключей (PKI): помимо роли удостоверяющего центра (ЦС) туда входят веб-регистрация, сетевой ответчик (OCSP) и другие службы роли.¹⁰

1. Проверьте, есть ли внутренний ЦС. Сначала ИТ смотрит, есть ли в компании корпоративный ЦС AD CS. Если нет, поднимать ЦС только ради подписи кода — тяжёлое решение. Сравните стоимость одного коммерческого сертификата с затратами на развёртывание ЦС, резервное копирование, публикацию списка отзыва (CRL) и защиту ключей.
2. Попросите подготовить шаблон сертификата для подписи кода. Это работа на стороне ЦС. Дублируют стандартный шаблон «Подпись кода», на копии задают срок, длину ключа и группу безопасности, которой разрешено запрашивать (только те, кто подписывает), и добавляют копию в список шаблонов, доступных для выдачи, в оснастке «Центр сертификации». Стандартный шаблон не правят напрямую: изменение бьёт по всему домену и его трудно откатить.

3. Тот, кто подписывает, запрашивает сертификат. На компьютере для подписи вызывают Get-Certificate с именем шаблона. После выдачи сертификат сразу попадает в личное хранилище (этот командлет умеет класть сертификаты только в хранилище My).¹¹

   # Запрос к корпоративному ЦС по имени шаблона (встроенная проверка подлинности Windows)
   # 'CodeSigning' замените на имя шаблона, которое опубликовал администратор ЦС
   $result = Get-Certificate -Template 'CodeSigning' -Url ldap: `
       -CertStoreLocation Cert:\CurrentUser\My
   $result.Status        # Issued — выдан, Pending — ждёт одобрения
   

4. Раздайте доверие на машины. Корневой сертификат внутреннего ЦС — в хранилище «Доверенные корневые центры сертификации», сертификат издателя, которым подписывают, — в «Доверенные издатели». Раздают групповой политикой (Конфигурация компьютера > Политики > Конфигурация Windows > Параметры безопасности > Политики открытого ключа). Официально описан путь: в каждом хранилище под политиками открытого ключа — правый щелчок и импорт сертификата.¹² После этого из эксплуатации пропадает запрос AllSigned «Выполнить программное обеспечение от этого ненадежного издателя?».¹⁵

Шаг 2 на стороне ЦС часто нельзя закрыть одним ИТ-отделом, поэтому сначала зафиксируйте проверку из шага 1 и схему раздачи из шага 4 — и уже с этим идите к администратору ЦС. Так разговор идёт быстрее.

Если компьютеры не в домене (рабочая группа)

У малых и средних компаний часто нет AD-домена или в нём только часть машин. Если нет ни GPO, ни внутреннего ЦС, реалистичные решения складывают в таком порядке.

• Политику выполнения задают на каждой машине и проверяют, что она совпадает. В чек-лист подготовки ПК включают Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser (если нужно на всех пользователей — LocalMachine с правами администратора).³ Раз GPO ничего не фиксирует, значение всё ещё можно сменить локально, поэтому инвентаризацию дополняют проверкой Get-ExecutionPolicy -List.
• Эталон скрипта — в одном месте, запись — узкому кругу. Одну общую папку объявляют эталоном, писать туда могут только администраторы. Политика выполнения ловит только «случайный запуск»; за то, чтобы скрипт не правили, отвечают права доступа NTFS.
• Если нужна и подпись, сравнивают стоимость: раздать самоподписанный сертификат или купить коммерческий ЦС. Документация пишет: «скрипт с самоподписанным сертификатом на других компьютерах не запускается» и «для скриптов, которыми хотят делиться, это не подходит».⁵ Это описание состояния по умолчанию: другие машины сертификату не доверяют, поэтому и не запускают. Иначе говоря, если раздать доверие, запустится. Ниже это разведено отдельно.
• Обращение с Mark of the Web запишите в инструкцию. У .ps1, пришедших почтой или с внешнего ресурса, метка часто есть, поэтому в процедуру явно включают: «сначала ревью содержимого, потом Unblock-File» (глава 4).⁴

Если самоподписанный сертификат всё же используют в рабочей группе

Если остановиться на «самоподписанный работает только на той машине, где подписали», компанию с 10–20 компьютерами фактически заставляют покупать коммерческий ЦС. На практике AllSigned проходит, если открытую часть сертификата раздать на каждую машину. Отличие от GPO только в канале: руками, установщиком или MDM (Intune и аналоги).

Раздают только открытую часть. Закрытый ключ с компьютера, на котором подписывают, не выносят.

# 【один раз на компьютере подписи】экспорт только открытой части (-Cert закрытый ключ не включает)
$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
        Where-Object Subject -eq 'CN=KomuraSoft Code Signing (Test)'
Export-Certificate -Cert $cert -FilePath .\KomuraSoftCodeSigning.cer

# 【один раз на каждой машине, нужны права администратора】кладём и в корень, и к издателям.
# Без корня проверка подписи не проходит (самоподписанный сертификат сам себе корень),
# без издателей AllSigned продолжает спрашивать подтверждение
Import-Certificate -FilePath .\KomuraSoftCodeSigning.cer `
    -CertStoreLocation Cert:\LocalMachine\Root
Import-Certificate -FilePath .\KomuraSoftCodeSigning.cer `
    -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

Дальше сразу посмотрите, какую цену вы за это принимаете. Здесь и проявляется разница с коммерческим ЦС.

Если машин мало, подготовка ПК описана и компьютер подписи можно защитить, раздачи самоподписанного сертификата достаточно. Если машины постоянно прибывают, подготовка держится на одном человеке или до компьютера подписи может добраться кто угодно — дешевле отдать отзыв и обновление коммерческому ЦС.

Хранилище сертификатов и диск Cert:

Перед кодом подписи коротко про Cert:. Это виртуальный диск провайдера сертификатов PowerShell: хранилища обходят как файловую систему по путям.¹³ Два уровня: Cert:\<расположение>\<имя хранилища>. Расположения — CurrentUser (текущий вошедший пользователь) и LocalMachine (весь компьютер). Имена хранилищ — My (личное), Root (доверенные корневые центры сертификации), TrustedPublisher (доверенные издатели) и другие. Каждый сертификат идентифицируют по отпечатку (Thumbprint), список даёт Get-ChildItem.¹³

То есть Cert:\CurrentUser\My — «личное хранилище текущего пользователя», а Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert — «покажи все сертификаты подписи кода оттуда». -CodeSigningCert — параметр именно этого провайдера: оставляет сертификаты, у которых в расширенном использовании ключа (EKU) есть подпись кода.¹³

Сначала прогоните весь поток на тестовом самоподписанном сертификате.

# Тестовый сертификат подписи кода (самоподписанный — ему доверяют только на этой машине)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate создаёт самоподписанный сертификат для тестов; -Type CodeSigningCert добавляет расширение для подписи кода. Срок по умолчанию — один год.⁷ Если таким сертификатом проверяете AllSigned, его нужно положить в хранилище доверенных корневых центров сертификации на этой же машине.⁵

Сама боевая подпись — одна команда.

# Берём сертификат подписи кода из хранилища и подписываем
# -CodeSigningCert только сужает выбор до «пригодных для подписи кода»,
# поэтому оставляем действующие с закрытым ключом,
# а если их несколько — уточняем по Subject или Thumbprint
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
    Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
                   $_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1   # Если из-за продления несколько с одним Subject, берём тот, у которого срок дальше

# Метка времени обязательна. Благодаря ей подпись живёт после истечения сертификата
# URL — служба меток времени по RFC 3161. В первую очередь берите ту, которую указывает издатель сертификата (продавец).
# Пример: сервер меток времени DigiCert http://timestamp.digicert.com
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
    -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.digicert.com'

# Состояние подписи смотрят Get-AuthenticodeSignature (Valid/NotSigned/HashMismatch и т. д.)
# Если TimeStamperCertificate не пуст, метка времени стоит
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 |
    Format-List -Property Status, SignerCertificate, TimeStamperCertificate

Три свойства, которые стоит зафиксировать.⁶⁵

• Подпись встраивается в конец файла блоком комментариев # SIG #. Если подпись уже была, её заменяют. Достаточно изменить скрипт на один символ после подписи — и подпись станет недействительной. Именно так обнаруживают правки.
• Если указать -TimestampServer, скрипт не перестанет работать после истечения сертификата. Подпись действительна «пока действителен сертификат подписи» либо «пока сервер меток может подтвердить, что подписали, когда сертификат ещё был действителен». У большинства сертификатов подписи кода срок — год, поэтому метка времени — основа долгой эксплуатации.⁶⁵ URL должен указывать на реальную службу по RFC 3161, не на выдуманное значение. Первый кандидат — URL, который даёт издатель сертификата (ЦС, у которого покупали). Например, DigiCert публикует http://timestamp.digicert.com.¹⁴ Среди служб роли AD CS ответа меток времени нет¹⁰, поэтому даже при сертификате внутреннего ЦС метку обычно берут у внешней службы. Это часто забывают, когда только обсуждают внутренний ЦС: проверьте, что до URL можно достучаться по сети (прокси, разрешение на брандмауэре). После подписи смотрите, что TimeStamperCertificate у Get-AuthenticodeSignature не пуст — так убеждаетесь, что метка действительно встала.
• В Windows PowerShell 5.1 и в PowerShell до 7.2 подписываемый скрипт нужно было сохранять в ASCII или UTF8NoBOM. С PowerShell 7.2 подписанные скрипты работают с любой кодировкой.⁵ Там, где ещё живёт 5.1, из-за кодировки часто ломается проверка подписи у скриптов с комментариями на японском. Общие различия 5.1 и 7 — в статье «Различия между Windows PowerShell 5.1 и PowerShell 7 и переход».

В среде AllSigned даже подписанный скрипт, если издатель ещё не отнесён к доверенным или отклонённым, при запуске спрашивает: «Выполнить программное обеспечение от этого ненадежного издателя?». Если выбрать «Всегда выполнять», для этого издателя больше не спрашивают.¹⁵ При внутреннем ЦС сертификат издателя дополнительно разносят в «Доверенные издатели» на каждой машине — и этот запрос из эксплуатации исчезает.

6. Рабочая таблица решений: от «заглушки Bypass» до процесса подписи

Распространение и запуск внутренних скриптов удобно продумывать по такой таблице.

Последнюю строку стоит пояснить. Проблема эксплуатации, которая «закрывает дыру ExecutionPolicy Bypass», не в том, что открывается дыра в безопасности (политика выполнения границей и не была). Проблема в трёх пунктах.

• Отказ от защитного механизма. Вы навсегда снимаете последнюю сетку, которая ловит случайный запуск другого скрипта и запуск уже изменённого скрипта, которого не заметили.
• Расхождение с управлением. Как только политикой начинает управлять GPO, Bypass перестаёт действовать, и все задачи, которые им «закрывали», падают разом.¹ Это технический долг: «почему работало» оказалось неуправляемой лазейкой.
• Путаница при разборе причин. Если Bypass разбросан по задачам, по действующей политике окружения поведение уже не угадаешь, и разбор «почему падает только на этой машине» затягивается.

Сам Bypass предусмотрен для приложений, которые встраивают PowerShell и держат собственную модель безопасности.¹ Это не опция запуска, которую стоит постоянно вешать на рабочие скрипты, написанные людьми. Как собрать безопасный регулярный запуск в Планировщике заданий — в статье «Почему задачи Планировщика не запускаются или завершаются с кодом 0x1 — разбор причин и безопасная эксплуатация».

7. Итог

• Политика выполнения — защитный механизм, а не граница безопасности. Защиту от атак делайте на другом уровне; политике выполнения оставьте предотвращение случайного запуска.
• У политики пять областей действия с приоритетом MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. Диагностику начинайте с Get-ExecutionPolicy -List.
• RemoteSigned смотрит на Zone.Identifier (Mark of the Web). Проверенные файлы пропускайте Unblock-File, политику не ослабляя.
• Подписывайте Set-AuthenticodeSignature и всегда указывайте -TimestampServer. Для внутренней раздачи — сертификат внутреннего ЦС; самоподписанный только для тестов.
• Управление в организации централизуйте параметром групповой политики «Включить выполнение сценариев». Он сильнее всех областей и параметра -ExecutionPolicy.
• Постоянный -ExecutionPolicy Bypass — отказ от защитного механизма, и под GPO он не действует. Правильный путь — настроить политику окружения и подпись, чтобы «заглушка» стала не нужна.

Похожие статьи

• Основы команд PowerShell — что выучить в первую очередь и как пользоваться безопасно
• Почему Windows показывает «Windows защитил ваш компьютер»
• Почему задачи Планировщика не запускаются или завершаются с кодом 0x1 — разбор причин и безопасная эксплуатация
• Обработка ошибок и повторные попытки (retry) в скриптах PowerShell
• Различия между Windows PowerShell 5.1 и PowerShell 7 и переход
• Переход с bat-файлов на PowerShell: как принять решение

Смежные области консультирования

KomuraSoft LLC (合同会社小村ソフト) проектирует политику выполнения и процесс подписи внутренних скриптов PowerShell, рассматривает развёртывание через групповую политику и разбирает различия окружения вроде «скрипт не работает только на некоторых машинах». Можем помочь перевести существующие bat-файлы и скрипты на безопасную эксплуатацию.

• Техническая консультация и ревью проекта
• Расследование сбоев и анализ причин
• Модернизация и сопровождение Windows-приложений
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Является ли политика выполнения PowerShell функцией безопасности?

Официальная документация прямо говорит: «политика выполнения — это не система безопасности, ограничивающая действия пользователя». Её легко обойти: достаточно вставить содержимое скрипта в командную строку. Политика задаёт базовые правила и служит защитным механизмом против случайного запуска не того скрипта. На ней нельзя строить границу, которая должна останавливать злоумышленника. Защиту от атак делают на другом уровне: контроль приложений, минимизация прав и так далее.

Чем RemoteSigned отличается от AllSigned?

RemoteSigned требует подпись доверенного издателя только у скриптов из интернета (с Mark of the Web). Скрипты, созданные локально, запускаются без подписи. AllSigned требует подпись у всех скриптов и файлов конфигурации, включая локальные, и перед запуском скрипта от ещё не классифицированного издателя спрашивает подтверждение. Если в компании можно выстроить процесс подписи (раздача сертификатов подписи кода и сама процедура), выбирайте AllSigned. Если такой инфраструктуры нет, реалистичнее RemoteSigned.

Почему скачанный скрипт не запускается с ошибкой «не имеет цифровой подписи»?

К файлам, скачанным через браузер и похожие программы, прикрепляется альтернативный поток данных Zone.Identifier, и Windows считает их «файлами из интернета». При политике RemoteSigned неподписанный скрипт с этой меткой блокируется. Если вы проверили содержимое и признали его безопасным, снимите Zone.Identifier командлетом Unblock-File или флажком «Разблокировать» в свойствах файла в Проводнике. Политику выполнения менять не нужно.

Как реалистично раздавать внутренние скрипты PowerShell?

Два основных варианта. Первый — RemoteSigned плюс размещение на файловом сервере: можно начать без инфраструктуры подписи, но в зависимости от канала раздачи может появиться Mark of the Web и заблокировать запуск, а изменение скрипта никто не заметит. Второй — AllSigned плюс процесс подписи: скрипты подписывают Set-AuthenticodeSignature сертификатом подписи кода (на практике чаще внутренним ЦС), а политику задают централизованно через групповую политику. Контроль политики и обнаружение изменений есть, но появляются затраты на раздачу и обновление сертификатов.

Можно ли и дальше указывать -ExecutionPolicy Bypass в Планировщике заданий?

Запустится, но так делать не стоит. Если политикой выполнения управляет групповая политика, параметр ExecutionPolicy в командной строке её не перебивает и просто не действует. Постоянный Bypass сам снимает защитный механизм против случайного запуска и со временем разводит официальную политику организации и то, что происходит на местах. Для постоянной эксплуатации задайте политику окружения через групповую политику или Set-ExecutionPolicy от имени администратора, а доверие к скриптам подтверждайте подписью.

Зачем при подписи скрипта нужна метка времени (-TimestampServer)?

Действительность подписи в общем случае привязана к сроку сертификата. Если есть метка времени, сервер меток подтверждает, что подпись поставили, пока сертификат ещё был действителен, и скрипт можно использовать после истечения срока. У большинства сертификатов подписи кода срок около года: без метки каждый год есть риск, что в один день все подписанные внутренние скрипты перестанут запускаться. При подписи всегда указывайте -TimestampServer.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.