Язык сценариев Windows PowerShell. А вот тут, пожалуйста, подпись...

В январском выпуске колонки Windows PowerShell за 2008 год я рассказывал о том, насколько важно ставить цифровую подпись на сценарии Windows PowerShell. Я приводил в качестве примера сценарии, в которых политика выполнения отличалась от AllSigned, что становилось причиной высокой уязвимости системы безопасности среды.

Собственно процедуры создания подписей я тогда подробно не рассматривал. Предыдущую статью можно найти на странице technetmagazine.com/issues/2008/01/PowerShell. Догадались, о чем речь пойдет в этот раз?

Больше, чем просто подпись

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

Эти ключи называют асимметричными, поскольку они разные. Один ключ закрытый, он известен только вам, второй — открытый, к нему может получить доступ кто угодно. Я несколько все упрощаю, но по сути дело обстоит так: то, что зашифровано при помощи закрытого ключа, может быть расшифровано только при помощи соответствующего открытого ключа.

Вот как все это работает на практике. Еще раз оговорюсь, что я несколько упрощаю ситуацию, посто чтобы не затягивать изложение. Допустим, у меня есть сценарий Windows PowerShell®, который мне нужно подписать, и есть сертификат, содержащий закрытый ключ, — он будет использоваться для создания подписи сертификата. В самой Windows PowerShell есть командлет (я еще расскажу о нем поподробнее), который берет сценарий с сертификатом и собственно создает подпись. При этом Windows PowerShell шифрует содержимое сценария, используя закрытый ключ. Зашифрованная копия выглядит как бессмысленный набор символов, который добавляется в конец сценария в виде набора комментариев (см. рис. 1). Удостоверение тоже добавляется в комментарии, правда не шифруется. Собственно, удостоверение можно прочитать, не прибегая к средствам криптографии.

Рис. 1 Блок подписи в конце сценария 

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

Вот таким образом подпись и защищает открытый текст сценария от незаметных изменений. Сам-то сценарий можно изменить без труда, а вот подпись невозможно подменить так, чтобы она совпала с открытым текстом сценария: для этого нужен мой закрытый ключ, а он есть только у меня.

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

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

Получение сертификата

Командлет месяца: Export-CSV

Ребята на форуме PowerShellCommunity.org часто спрашивают, можно ли экспортировать данные из Windows PowerShell в Microsoft Excel®. Разумеется, можно. Делает это командлет Export-CSV: программа Excel позволяет открывать, редактировать и сохранять файлы CSV. Например, если вам нужно экспортировать список служб, запустите команду Get-Service | Export-CSV MyServices.csv. Командлет Export-CSV можно поместить в конец любого конвейера, и все объекты, проходящие по нему, будут выводиться в файл CSV. По умолчанию Export-CSV добавляет троку заголовка в начало файла, в которой указывается тип экспортированных объектов. Строка заголовка занесена в комментарий, поэтому Excel без проблем открывает эти файлы. Если вы не хотите записывать эту информацию в файл, нужно использовать параметр -notype для командлета Export-CSV. Кроме него можно также применять параметр -force (старый файл CSV заменяется новым файлом с тем же именем без подтверждения) и параметр –noClobber, который запрещает заменять существующие файлы.

Чтобы подписать сценарий, вам потребуется специальный сертификат — сертификат Authenticode для подписывания кода класса III. Получить его можно тремя способами. Первый вариант — использовать инфраструктуру открытого ключа (PKI), если она в вашей организации есть. В грамотно построенной инфраструктуре PKI корневому центру сертификации доверяют все компьютеры организации: только в таком случае сертификаты, выданые им, можно с организации использовать.

В Windows Server® есть свой сервер сертификатов начиная с версии Windows® 2000, и это программное обеспечение вы можете использовать для создания собственной инфраструктуры PKI. Для полноценной реализации PKI требуется продуманное планирование, но если инфраструктура PKI нужна только для выпуска сертификатов для подписи кода, особой работы не потребуется. Вы можете просто при помощи групповой политики получить корневой сертификат центра сертификации на свои компьютеры, и они будут считать его доверенным.

Второй вариант — использовать коммерческий центр сертификации. Одно из преимуществ такого подхода состоит в том, что если выбрать известный центр сертификации, есть шанс, что на компьютерах организации уже настроено доверие для этого центра. (В Windows XP большое количество центров сертификации считаются доверенными по умолчанию, в Windows Vista® их часло гораздо меньше.) Один из известных коммерческих центров сертификации — VeriSign (verisign.com), но есть и другие: CyberTrust (cybertrust.com), Thawte (thawte.com).

Третий вариант получения сертификата для подписи кода — создать свой собственный сертификат при помощи средства вроде Makecert.exe. Оно есть в комплекте Windows Platform SDK, в некоторых выпусках Microsoft® Office, да и много где еще. Плюсом такого сертификата является то, что он бесплатный и не требует никакой специальной инфраструктуры. Минус его в том, что использовать его, по сути, можно только на вашем собственном компьютере. Если нужно обеспечить выполнение сценариев на одном компьютере, к примеру для тестирования или для изучения возможностей подписей кода, Makecert.exe незаменим. Документацию к этому средству можно найти на странице go.microsoft.com/fwlink/?LinkId=108538. Только имейте в виду, что уже было выпущено несколько версий этого средства и что, возможно, та версия, которая установлена у вам, отличается от той, что описана в документации.

После того как Makecert.exe установлен, сертификат создается путем выполнения примерно таких команд в командной строке Windows PowerShell (и не дай бог я застану кого за работой с cmd.exe во время чтения статьи):

makecert -n "CN=MyRoot" -a sha1 –eku  1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer   –ss Root -sr localMachine 

Затем необходимо ввести следующее:

makecert -pe -n "CN=MyCertificate" -ss MY   –a sh1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk   –c root.cer 

Makecert.exe попросит вас ввести пароль для защиты ключа, после чего создаст сертификат. Проверить результат можно, запустив в Windows PowerShell следующий код:

gci cert:\CurrentUser\My -codesigning 

На экране появится список всех элементов на диске CERT: (это хранилище сертификатов в Windows), представляющих собой сертификаты для подписи кода. Кстати, все это также описано в документации к самой Windows PowerShell. Чтобы ее найти, нужно открыть справку (help About_Signing) и пролистать несколько экранов.

Создание подписи для сценария

Теперь у нас есть сертификат. И есть сценарий (можно в целях проверки быстренько состряпать что-нибудь). Можем приступать к созданию подписи. В Windows PowerShell делается это до безобразия просто. Нужно ввести следующее:

$cert = @(gci cert:\currentuser\my  -codesigning)[0]  Set-AuthenticodeSignature myscript.ps1 $cert 

Первая часть команды получает первый из установленных сертификатов для подписи кода (если у вас несколько сертификатов и вы не хотите использовать первый, замените цифру 0 номером нужного сертификата). Вторая часть команды подписывает файл (разумеется, имя файла вы должны вписать свое). Вот, собственно, и все. Единственное, имя командлета Set-AuthenticodeSignature показалось мне слишком длинным, и я создал псевдоним Sign. Теперь та же команда у меня выглядит так:

Sign myscript.ps1 $cert 

Если вы откроете свой сценарий, вы обнаружите в конце блок подписи. Установите для политики выполнения режим AllSigned (Set-ExecutionPolicy AllSigned) и попробуйте запустить сценарий. Все должно работать. Теперь измените текст сценария и сохраните его. Подпись не меняйте. Windows PowerShell откажется запускать измененную версию сценария, поскольку подпись нарушена.

Оно того стоит

Время от времени невольно задаешься вопросом: а стоит ли результат всей этой суеты? Если лишь изредка создавать сценарии для задач администрирования, так ли уж нужно тратить 500 долларов на сертификат, создавать совершенно новую инфраструктуру? Я сам администратор, и я вас прекрасно понимаю. Но все, что я вам могу на это сказать: стоит. Стоит любых усилий.

Безопасность всегда требует определенного количества работы. Антивирус может раздражать до невозможности, но вы же не станете работать без него. Брандмауэр — сплошная головная боль, но и без него никак. Контроль учетных записей в Windows Vista тоже требует определенной заботы, но зато безопасность системы повышается. А не защиты ли ради мы все это и затеяли?

Windows PowerShell — весьма мощное средство, и оно, как и многие другие, может стать причиной уязвимости системы, которой не преминет воспользоваться какой-нибудь злоумышленник. Именно поэтому так важно предпринять заранее действия, которые не дадут злоумышленнику проникнуть в систему.

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

Можно обойтись и без редактора. Можно создать специальный профиль в Windows PowerShell (создать файл Microsoft.PowerShell_profile.ps1 в папке WindowsPowerShell, расположенной в папке с вашими документами) и добавить в него такую функцию:

function sign ($filename) {    $cert = @(gci cert:\currentuser\my   -codesigning)[0]  Set-AuthenticodeSignature $filename $cert  } 

Теперь сценарии будут подписываться при помощи вот этой команды:

Sign c:\scripts\myscript.ps1 

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

Развертывание инфраструкутры PKI для одного сервера, если она будет использоваться только для выпуска сертификатов, тоже больших проблем не доставит. (Помните, правда, что инфраструктуру нужно будет спланировать, продумать систему защиты корневого центра сертификации и план аварийного восстановления — тем более если вы будете использовать PKI еще и в других целях.) В конце концов, всегда можно воспользоваться Makecert.exe, если кроме вас сценарии запускать никто не будет. Не забудьте о том, что в справке Windows PowerShell, в разделе About_Signing, есть информация и о том, как защитить сертификаты, созданные при помощи программы Makecert.exe