Как проверить издателя скрипта PowerShell по цифровой подписи

Перед запуском чужого скрипта PowerShell разумно убедиться в двух вещах: файл действительно подписан тем издателем, который заявлен, и подпись не была повреждена после публикации. Обе проверки выполняются одной командой — Get-AuthenticodeSignature. Она показывает имя подписавшего сертификата, статус подписи и цепочку доверия. Если статус не равен Valid, а издатель вам незнаком или не совпадает с ожидаемым, запускать скрипт не стоит.

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

Зачем вообще проверять подпись скрипта

Цифровая подпись решает две задачи одновременно:

• Идентификация. Подпись содержит сертификат издателя, из которого видно, какая организация или разработчик выпустила файл. Если злоумышленник подделывает популярный скрипт, его подпись либо отсутствует, либо принадлежит другому сертификату.
• Целостность. Подпись вычисляется на основе содержимого файла. Изменение хотя бы одного байта после подписания делает подпись недействительной — это защищает от скрытой вставки вредоносного кода в уже распространяемый скрипт.

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

Быстрая проверка одной командой

Откройте консоль PowerShell и выполните:

Get-AuthenticodeSignature -FilePath «C:\Scripts\script.ps1» | Format-List

Вместо пути подставьте расположение вашего файла. Команда вернёт объект со следующими ключевыми полями:

• Status — итоговый статус проверки: Valid, NotSigned, HashMismatch, UnknownError и другие;
• StatusMessage — текстовое пояснение к статусу;
• SignerCertificate — сертификат подписавшего: субъект (кто подписал), издатель сертификата (кто его выдал), срок действия, отпечаток;
• TimeStamperCertificate — сертификат службы штампов времени, если она использовалась.

Чтобы сразу увидеть только самое важное, удобнее такой вариант:

(Get-AuthenticodeSignature .\script.ps1).SignerCertificate | Format-List Subject, Issuer, NotBefore, NotAfter, Thumbprint

Что означает каждый статус

Статус	Что произошло	Что делать
Valid	Подпись целая, сертификат действителен, цепочка доверия построена до корневого центра сертификации	Можно запускать, если вы доверяете самому издателю
NotSigned	Файл не имеет цифровой подписи	Не запускать без дополнительного анализа содержимого
HashMismatch	Файл изменён после подписания	Не запускать: это главный признак подмены или повреждения
NotTrusted	Сертификат есть, но он явно внесён в список недоверенных на этом компьютере	Не запускать; проверить, кто добавил сертификат в недоверенные
UnknownError	Цепочка доверия не построена: самоподписанный сертификат, отсутствие промежуточных сертификатов, нет доступа к сети для проверки отзыва	Разобраться в причине, прежде чем принимать решение

Отдельно про UnknownError: этот статус часто возникает у легитимных скриптов, например когда разработчик подписал файл самоподписанным сертификатом или корпоративным сертификатом внутреннего центра сертификации, которого нет в хранилище доверия вашей машины. Это не обязательно признак угрозы, но и не основание для автоматического доверия.

Как оценить издателя, а не только факт подписи

Статус Valid отвечает лишь на вопрос «подпись цела?». Второй вопрос — «доверяю ли я этому издателю?» — решается вручную. Посмотрите поля сертификата:

• Subject — имя владельца. У коммерческих сертификатов для подписи кода здесь обычно указано юридическое лицо, прошедшее проверку у удостоверяющего центра. Формулировки вроде «CN=SelfSigned» или случайные имена — признак самоподписанного сертификата.
• Issuer — удостоверяющий центр, выдавший сертификат. Известные публичные центры дают больше оснований для доверия, чем неизвестный или локальный.
• NotBefore / NotAfter — срок действия. Сертификат, выпущенный неделю назад для «давно известного» продукта, должен насторожить.
• Thumbprint — отпечаток. Если вы уже получали скрипты от этого издателя, сравните отпечаток с предыдущим: подмена сертификата будет видна сразу.

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

Проверка цепочки сертификатов вручную

Если нужно убедиться, что цепочка доверия действительно строится до корня, откройте сертификат двойным щелчком по файлу .ps1 (вкладка «Цифровые подписи») или экспортируйте его и просмотрите путь сертификации. Цепочка должна заканчиваться корневым центром, присутствующим в хранилище «Доверенные корневые центры сертификации» вашего компьютера.

Взаимодействие с политикой выполнения

PowerShell использует подписи не только для информации, но и для контроля запуска. Политика выполнения (Execution Policy) определяет, какие скрипты разрешено выполнять:

• Restricted — выполнение скриптов запрещено полностью;
• AllSigned — разрешены только подписанные скрипты, причём от каждого нового издателя система запросит явное подтверждение;
• RemoteSigned — локальные скрипты работают свободно, а скачанные из сети должны быть подписаны;
• Bypass / Unrestricted — ограничения практически сняты, подходит только для временных задач.

Текущую политику можно посмотреть командой Get-ExecutionPolicy -List. При политике AllSigned PowerShell сам проверит подпись перед первым запуском и покажет сертификат издателя — но полагаться только на это не стоит: политика может быть ослаблена администратором или обойдена запуском через обходные механизмы, поэтому ручная проверка перед запуском незнакомого файла остаётся полезной привычкой.

Обратите внимание на маркер зоны безопасности: файлы, загруженные из интернета, помечаются потоком Zone.Identifier. Его можно увидеть командой Get-Item .\script.ps1 -Stream Zone.Identifier, а снять — командлетом Unblock-File. Снятие блокировки убирает предупреждения, но не заменяет проверку подписи.

Массовая проверка папки со скриптами

Если нужно проверить несколько файлов сразу, используйте конвейер:

Get-ChildItem «C:\Scripts» -Filter *.ps1 | ForEach-Object { $s = Get-AuthenticodeSignature $_.FullName; [PSCustomObject]@{ File = $_.Name; Status = $s.Status; Signer = $s.SignerCertificate.Subject } } | Format-Table -AutoSize

Такой вывод удобно использовать для аудита: сразу видно, какие файлы в каталоге не подписаны или имеют проблемные статусы. Аналогично можно проверять модули (.psm1), файлы формата (.ps1xml) и каталоги с установленными модулями перед обновлением.

Типичные ошибки при проверке

• Доверие факту подписи вместо издателю. Подписанный вредоносный скрипт возможен, если злоумышленник получил собственный сертификат. Всегда смотрите, кому именно выдан сертификат.
• Игнорирование статуса UnknownError. Частая реакция — «наверное, сеть недоступна, запущу всё равно». Правильнее выяснить причину: самоподписанный сертификат, неполная цепочка или проблема с проверкой отзыва требуют разных решений.
• Сравнение имени издателя «на глаз». Имена в Subject могут быть похожими. Надёжнее сравнивать отпечаток (Thumbprint) — он уникален для каждого сертификата.
• Отключение политики выполнения ради одного скрипта. Запуск с Bypass снимает защиту для всего сеанса. Лучше один раз подтвердить конкретного издателя при AllSigned, чем глобально ослаблять настройки.
• Проверка после скачивания из ненадёжного канала. Если файл пришёл по почте или из мессенджера, сверьте его хеш или повторно скачайте с официального ресурса издателя, даже если подпись формально валидна.

Сценарии: что делать в зависимости от результата

• Статус Valid, издатель известен и ожидаем. Можно запускать. Для регулярной работы с этим издателем достаточно подтвердить доверие при первом запуске под AllSigned.
• Статус Valid, но издатель незнаком. Прочитайте код скрипта или найдите независимые сведения об издателе. Валидная подпись постороннего сертификата ничего не говорит о безопасности кода.
• HashMismatch. Не запускайте ни при каких условиях. Если файл нужен, получите его заново из первоисточника и проверьте снова.
• NotSigned. Решение принимается по содержимому: прочитайте скрипт целиком, обратите внимание на загрузку внешних файлов, вызовы Invoke-Expression, работу с сетью и реестром. Неподписанные скрипты допустимо запускать только из источников, которым вы доверяете лично.
• Самоподписанный сертификат от известного разработчика. Такое встречается во внутренних инструментах и open-source проектах. Здесь решение зависит от того, можете ли вы проверить отпечаток сертификата через канал самого разработчика — документацию, репозиторий, релизные заметки.

Как подписывать свои скрипты

Если вы сами распространяете скрипты, подписание делается командлетом Set-AuthenticodeSignature. Понадобится сертификат подписи кода (Code Signing): коммерческий от публичного удостоверяющего центра — для публичного распространения, либо корпоративный или самоподписанный — для внутренних нужд. Базовый вызов выглядит так:

$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert; Set-AuthenticodeSignature -FilePath .\script.ps1 -Certificate $cert

Для публичных скриптов стоит использовать сертификат со штампом времени: тогда подпись останется действительной и после истечения срока самого сертификата. Без штампа времени подпись «умирает» вместе с сертификатом, и пользователи начнут получать ошибки доверия.

Краткий порядок действий

1. Выполните Get-AuthenticodeSignature для файла и посмотрите Status.
2. При статусе, отличном от Valid, определите причину через StatusMessage и свойства сертификата.
3. При Valid оцените издателя: Subject, Issuer, срок действия, отпечаток.
4. Сверьте источник файла: официальный сайт или репозиторий против пересылки через сторонние каналы.
5. Только после этого запускайте скрипт; при сомнениях сначала прочитайте его код.

Главный принцип прост: подпись отвечает на вопрос «файл дошёл до вас без изменений от того, кто его подписал», а решение о доверии принимает человек. Проверка занимает секунды, а предотвращает большинство сценариев подмены популярных скриптов вредоносными копиями.

Материал носит информационный характер и описывает общую практику проверки подписей. Решение о запуске конкретного скрипта в рабочей среде принимайте с учётом внутренних политик безопасности вашей организации и при необходимости консультируйтесь со специалистом по информационной безопасности.