Як відомо практично всім користувачам PowerShell, в цілях безпеки була введена політика запуску скриптів. Яка має 4 режими:
- Restricted - заборонено виконувати будь-які скрипти, можлива робота тільки в інтерактивній консолі
- AllSigned - всі скрипти повинні бути криптографически підписані
- RemoteSigned - тільки отримані з недовірених джерел (наприклад, інтернет) скрипти повинні бути підписані
- Unrestricted - найменш безпечний рівень, допускається виконання будь-яких скриптів
У версії V2 (поки ще CTP3) скрипти PowerShell прирівняли до виконуваних файлів і ці файли стали неотключаемо моніториться політикою Software Restriction Policies. Я про це вже писав раніше: PowerShell V2 і Software Restriction Policies. Спочатку мене це сильно напружувало, але після прийшов до думки, що це правильно. Неправильно тільки те, що ми цього не бачимо (ps1 розширення ніде не фігурує). З цим боротися можна двома методами - явно вказувати шляхи, звідки дозволений запуск .ps1 файлів або підписати їх все.
Якщо комп'ютерів в мережі більше одного, то саме ідеальне для вирішення завдання буде наявність домена Active Directory і, по можливості, Enterprise Certification Authity (CA). Наявність домену вирішить масу завдань, як поширення політики SRP в межах домену, поширення сертифіката в межах домену, контроль версії сертифікату, яким підписані скрипти.
Отже, для початку нам потрібно отримати сертифікат, яким будуть підписуватися скрипти. З метою безпеки слід створити обмежену обліковий запис користувача з під якої адміністратор (в більшості випадків) буде підписувати скрипти. У книзі PowerShell In Action для генерації сертифіката пропонується використовувати makecert.exe. який входить до складу Visual Studio SDK, але як мені здається більш правильним буде використання CA. У Windows Server CA для цих цілей є вже готовий шаблон, який називається Code Signing. Але принципової різниці немає, яким інструментом ви будете генерувати сертифікат і я опишу процес отримання сертифікату з використанням доменного CA.
Після чого потрібно залогінитися цим користувачем, запустити оснастку Certificate Manager (Start -> Run ... -> certmgr.msc) і виконати запит сертифіката. У списку шаблонів повинен бути і доданий нами Code Signing. Коли сертифікат буде запитано не треба закривати оснастку сертифікатів. Далі нам потрібно експортувати відкриту частину сертифіката в x509 файл (з розширенням .cer). Експорт відкритої частини нам буде потрібно для перевірки підпису і організації довіри підпису в межах домену. Експортований сертифікат необхідно тепер доставити адміністратору (-ам), який відповідає за групову політику.
У групових політиках (найчастіше в доменній політиці) необхідно створити нову політику Software Restriction Policies і в Additiona Rules додати правило сертифіката (Certificate Rule) і вказати експортований сертифікат. Це необхідно для того, що PowerShell для перевірки довіри сертифіката шукає його в контейнері Trusted Publishers і тільки Software Restriction Policies дозволяє централізовано поширювати сертифікати в цей контейнер.
Тепер можна приступати до підписування скриптів. Для цих цілей використовується командлет Set-AuthenticodeSignature і синтаксис його такий:
Де $ file - шлях до скрипту і $ cert - об'єкт сертифіката, який отримують у такий спосіб:
тут ми явно вказуємо, що нам потрібен сертифікат, у якого в EKU (Enchanced Key Usage) вказано Code Sgining. У нашому випадку він буде всього 1. Але якщо їх виявиться кілька, то ми виберемо найперший. Ось як це буде виглядати на практиці:
Я наочно показав, як це працює. Ми спочатку перевели політику виконання скриптів в AllSigned і переконалися, що непідписаний скрипт не виконується. Після чого я підписав цей скрипт і спробував знову. Як бачите, скрипт тепер виповнився.
Якщо не буде виконана умова поширення сертифіката за допомогою політики SRP в контейнер Trusted Publishers. то ви отримаєте ось таке повідомлення:
Ось таким чином ми вирішуємо завдання виконання тільки перевіреного набору скриптів. У цьому сенсі PowerShell 1.0 менш безпечний і зручний, оскільки ми не можемо політикою SRP блокувати виконання PS1 файлів як клас і маємо тільки один вихід - примусове підписування скриптів. У версії V2 політика виконання скриптів зручно інтегрується з SRP. Зручність інтегрування в тому, що SRP крім поширення сертифіката в межах домену так само на основі цього правила дозволяє виконувати ці скрипти в обхід загального обмеження на PS1 файли.
В наступному пості я розповім, як можна спростити процес підписування скриптів. Так що не відключаємося :-)