Полезни PowerShell скриптове без администраторски права

PowerShell се превърна в незаменим инструмент за всеки, който работи с Windows, но често погрешно се свързва със задачи, изискващи администраторски права. Реалността е, че има много повече приложения за него. Полезни PowerShell скриптове, които можете да изпълнявате без повишени привилегииСтига да разбирате правилата на играта: директиви за изпълнение, контекст на сигурност и няколко трика за редуване между сесии с повишени права и нормални сесии.

В следващите редове ще видим Как работи защитата на PowerShell, какво можете да правите без администраторски праваЩе разгледаме какви ограничения не бива да се опитвате да заобикаляте и как да управлявате правилата за изпълнение, така че скриптовете да не бъдат блокирани с ужасяващото съобщение „изпълнението на скриптове е деактивирано на тази система“. Ще разгледаме и реални казуси, където трябва да смесите код, който се изпълнява като администратор, с команди, които би трябвало да се изпълняват като обикновен потребител.

PowerShell скриптове, привилегии и контекст

Първото нещо, което трябва да разберете е, че PowerShell не „създава“ привилегии от нищотоТой просто се възползва от разрешенията на процеса, с който е стартиран. Ако отворите конзолата с „Изпълни като администратор“, всичко, което стартирате оттам, ще наследи тези повишени привилегии; ако го отворите нормално, всичко ще се изпълнява със стандартните разрешения на вашия акаунт.

Тази подробност има ключово последствие: Всеки PowerShell скрипт, който стартира друг процес или скрипт, обикновено наследява същото ниво на разрешения.Следователно, когато администратор се опита да стартира скрипт от сесия с повишени права, който би трябвало да се изпълнява без привилегии, той открива, че вторият скрипт също е „догиран“ с администраторски разрешения.

От друга страна, потребител без администраторски права не може магически да отвори PowerShell с повишени привилегии, без да предостави идентификационни данни. Windows е проектирал това разделение именно за да предотврати неконтролиран достъп от страна на обикновен потребител.Следователно, всеки опит за автоматизиране на „отваряне на PowerShell като администратор“ без идентификационни данни ще се сблъска с механизмите за сигурност на системата.

Изпълнение на PowerShell със и без повишени привилегии

В ежедневната си работа ще редувате нормални и повишени PowerShell сесии. За да проверите дали текущата конзола е отворена като администратор, можете да използвате типичния модел за .NET класове за сигурност:

$currentPrincipal = New-Object Security.Principal.WindowsPrincipal( ::GetCurrent() )
$currentPrincipal.IsInRole(::Administrator)

Този фрагмент се връща $true, ако сте в сесия с повишени права, и $false, ако не сте администратор.Много е полезно вашите скриптове да реагират въз основа на контекста, в който се изпълняват, например като показват предупреждение на потребителя, ако се опита да направи нещо, което изисква разрешения, които той няма.

Когато трябва да стартирате нов PowerShell с администраторски права от нормална сесия, стандартният начин е да използвате Стартиране на процес с параметъра -Verb RunAs:

Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File "C:\Ruta\ScriptAdmin.ps1"' -Verb RunAs

Параметър Глаголът RunAs казва на Windows да повиши нивото на процесаТова задейства контрола на потребителските акаунти (UAC) и ако потребителят не е администратор, ще се поискат идентификационни данни за акаунт с необходимите привилегии. С други думи, няма пряк път за заобикаляне на тази проверка: ако потребителят не е нито администратор, нито знае идентификационните данни за акаунт, той не може да отваря скриптове с повишени привилегии.

Защо не можете да дадете администраторски права на обикновен потребител „чрез скрипт“?

Идеята е минавала през ума на повече от един човек. „предоставяне на администраторски права“ само за конкретна програмаили да докоснете разрешенията powershell.exe en C:\Windows\System32 така че стандартен потребител да може да изпълнява скриптове, сякаш е администратор. Това звучи чудесно на теория, но директно противоречи на модела за сигурност на Windows.

Променете ACL (списъци за контрол на достъпа) на системните изпълними файлове, така че потребители без привилегии могат да ги стартират с повишени права Това на практика отваря задна врата. Не само нарушава разделението на привилегиите, но е и перфектен подарък за всеки зловреден софтуер, който успее да се изпълни под този потребителски акаунт: той би могъл да използва този изпълним файл, за да поеме контрола над системата. За техники и препоръки как да защитите по-добре компютъра си вижте как да защитите системата си.

Нещо подобно се случва и с опитите за „автоматизиране“ на повдигането с помощта на Task SchedulerМожете да създадете планирана задача, която се изпълнява с администраторски акаунт и стартира скриптове, но Ако стандартният потребител може да принуди изпълнението му, когато пожелае, на практика му давате начин да действа като администратор без контрол.Освен това, това често води до странно поведение, като например скриптът да казва, че е изпълнен, но всъщност не прави това, което се очаква за този конкретен потребител, което усложнява поддръжката и сигурността.

Практическото заключение е ясно: Не е нито възможно, нито препоръчително да се позволи на непривилегирован потребител да стартира PowerShell като администратор без идентификационни данни.Ако някой трябва да тества неща с администраторски права, е много по-разумно да се създаде изолирана среда: виртуална машина с Hyper-V, тестова лаборатория или отделен екип за разработка.

Политики за изпълнение на PowerShell: „мекият“ слой за сигурност

В допълнение към системните разрешения, PowerShell има собствен механизъм за контрол. При какви условия могат да се качват скриптове и конфигурационни файлове?Политики за изпълнение. Този слой не е твърда система за сигурност (като NTFS или UAC), но помага за предотвратяване на случайно или неконтролирано изпълнение на скриптове.

В Windows, правилата основно определят дали скриптовете могат да се изпълняват и в кои случаи е необходим цифров подписВ системи, различни от Windows, PowerShell задава политиката на неограничен и въпреки че командата Set-ExecutionPolicy Съществува, но не се прилага както в Windows, защото тези платформи не използват зони за сигурност като операционната система на Microsoft.

Типове правила за изпълнение в PowerShell

PowerShell дефинира няколко нива на политики, всяко с различна степен на ограничение. Познаването на тези опции ви позволява да регулирате баланса между безопасност и комфорт в зависимост от вашата среда.

• Ограничен

  Е по-ограничителна конфигурация и настройката по подразбиране на много клиентски компютриПозволява само изпълнението на отделни команди в интерактивната конзола; блокира всички скриптови файлове (.ps1), модули ( ).psm1), форматни и конфигурационни файлове (.ps1xml) и потребителски профили. Ако се опитате да изпълните скрипт, ще получите класическата грешка, че изпълнението на скрипта е деактивирано.

• RemoteSigned

  Е политика по подразбиране в много съвременни WindowsПозволява ви да изпълнявате скриптове като цяло, но изисква тези, изтеглени от интернет (браузър, имейл, съобщения и др.), да бъдат подписани от надежден издател. Локално създадените скриптове не се нуждаят от подпис и изтеглените скриптове могат да бъдат изрично разподписани (например с Unblock-File), за да се позволи изпълнението им, дори ако не са подписани.

• AllSigned

  С тази политика, Всеки скрипт или конфигурационен файл трябва да бъде подписан от надежден издателТова включва код, който сте написали сами на тази машина. Когато изпълнявате скриптове, подписани от издатели, които все още не сте класифицирали, PowerShell ще поиска потвърждение. Въпреки това, все още съществува риск от изпълнение на подписани, но злонамерени скриптове, ако частният ключ на подписващия е бил компрометиран.

• неограничен

  Позволява ви да изпълнявате всеки скрипт, подписан или неподписан. Показва предупреждение само когато се изпълняват скриптове, които не произхождат от локалната интранет мрежа.Това е политиката по подразбиране на платформи, различни от Windows (където не може да се променя), и носи по-висок риск от изпълнение на нежелан код, така че обикновено не се препоръчва в корпоративни среди.

• Bypass

  В този режим, Нищо не е блокирано и не се показват никакви известия или предупреждения.Той е предназначен за сценарии, в които PowerShell работи вграден в друго приложение, което вече има собствен модел за сигурност. Също така е полезен ресурс в среди като Windows Server Core или Nano Server за предотвратяване на грешки при проверка на зоната.

• По подразбиране

  Връща политиката към настройките по подразбиране на платформата: RemoteSigned на клиенти и сървъри на WindowsТова е бърз начин да се върнете към „нормалното“ състояние, ако сте експериментирали с други нива.

• Неопределен

  Показва, че Няма установена политика за прилагане в тази конкретна областАко всички слоеве (всички обхвати) са зададени на Undefined, ефективната стойност ще бъде Restricted на Windows клиент и RemoteSigned на Windows Server.

Обхват на директивата за прилагане и ред на приоритет

Директивите за изпълнение не се прилагат цялостно за цялата система; можете да ги конфигурирате в различни случаи. обхват: екип, потребител, текущ процес и т.н. Всеки има приоритет и ефективната политика, която виждате в сесията, е резултат от комбинирането на всички тях в този ред.

Наличните стойности на обхвата са MachinePolicy, UserPolicy, Process, CurrentUser и LocalMachineКогато промените политиката, без да посочвате обхват, PowerShell използва настройката по подразбиране. ЛокалнаМашина, което засяга всички потребители на екипа.

• Правила за машинитеКонфигурира се чрез групови правила (GPO) за всички потребители на компютъра. Има най-висок приоритет.
• Потребителска политика: също се прилага чрез GPO, но само към текущия потребител. Приоритетът му е непосредствено по-нисък от MachinePolicy.
• ПроцесТова се отнася само за текущата PowerShell сесия. Политиката се съхранява в променливата на средата. $Env:PSExecutionPolicyPreferenceи се губи, когато сесията приключи.
• Текущ потребителТази настройка засяга само потребителя, с когото сте влезли в момента. Тя се запазва във файла с конфигурацията на потребителя.
• ЛокалнаМашина: важи за всички потребители на компютъра и се съхранява в конфигурационния файл „всички потребители“.

Когато изчислява коя политика е действително активна, PowerShell оценява слоевете в следния ред на приоритет:

Group Policy: MachinePolicy
Group Policy: UserPolicy
Execution Policy: Process (o pwsh.exe -ExecutionPolicy)
Execution Policy: LocalMachine
Execution Policy: CurrentUser

Ако например CurrentUser е в RemoteSigned, а LocalMachine е в AllSignedЕфективният резултат в тази сесия ще бъде RemoteSigned, защото политиката на текущия потребител има приоритет пред тази на локалния компютър, при условие че никой GPO не я е презаписал.

Преглед и промяна на политиката за изпълнение

За да разберете ефективната политика за изпълнение за вашата PowerShell сесия, можете да използвате:

Get-ExecutionPolicy

Ако искате да видите всички конфигурирани политики в различните области и стойността на всяка една от тяхНай-удобният вариант е:

Get-ExecutionPolicy -List

Резултатът ще изброи политиките от MachinePolicy до LocalMachine, като ще посочи стойността на всяка от тях. Ако искате да видите конкретната политика за даден обхват, можете да използвате параметъра . -Обхват:

Get-ExecutionPolicy -Scope CurrentUser

За да промените политиката за изпълнение в Windows, се използва командлетът Set-ExecutionPolicy, Например, ако искате да преминете към RemoteSigned:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Ако искате да коригирате политиката само за текущия потребител, без да засягате останалата част от екипа, можете да укажете обхвата:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Имайте предвид това Командата може да се изпълни успешно и все още да не промени действащата политика Ако има машина или потребителски GPO, който налага по-висок приоритет, ще трябва да промените конфигурационния файл, но груповите правила ще продължат да имат приоритет.

Ако това, което търсите, е премахване на директивата от дадена областНяма нужда да изтривате файлове ръчно: просто го задайте на Неопределено. Например, за да премахнете политиката, дефинирана за всички потребители на компютъра:

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope LocalMachine

И ако искате да изчистите данните на текущия потребител:

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

Когато не са конфигурирани правила в нито един обхват, Windows автоматично се връща към Ограничен на клиентите, което е еквивалентно на това да не се разрешават скриптове, докато не конфигурирате нещо различно отново.

Задайте политика за изпълнение само за една сесия

Има моменти, когато имате нужда облекчаване на политиката за прилагане само за конкретна сесиябез да докосвате нищо на устройството или потребителя. За целта можете да използвате параметъра -Политика за изпълнение при стартиране pwsh.exe o powershell.exe от командния ред (cmd, друга PowerShell сесия и т.н.).

Типичен пример би бил:

pwsh.exe -ExecutionPolicy AllSigned

Избраната политика се съхранява в $Env:PSExecutionPolicyPreference И това е валидно само за продължителността на тази сесия (и всички дъщерни процеси, свързани с нея). Не се запазва на диска и не можете да го заобиколите, като ръчно промените променливата на средата, за да промените политиката; стойността се задава при стартиране на сесията.

В рамките на тази сесия, Политиката, зададена при стартиране, ще има по-висок приоритет от тези, конфигурирани в LocalMachine или CurrentUser.но никога няма да може да замести групова политика, която произлиза от MachinePolicy или UserPolicy.

Управление на директиви за изпълнение с групови правила

В корпоративна среда е нормално тези решения да се централизират чрез Group PolicyИма специфична конфигурация, наречена „Активиране на изпълнението на скриптове“което може да се приложи както към клона „Конфигурация на компютъра“, така и към клона „Конфигурация на потребителя“ в редактора на групови правила:

Plantillas administrativas\Componentes de Windows\Windows PowerShell

Тази конфигурация налага политика за изпълнение, която презаписва всяка стойност, която се опитвате да дефинирате от PowerShell чрез Set-ExecutionPolicy, Архивите PowerShellExecutionPolicy.adm y .admx Те са тези, които добавят тази опция към редактора.

Наличните опции са:

• Ако деактивирате „Разрешаване на изпълнението на скриптове“, скриптовете няма да могат да се изпълняват. Това е еквивалентно на политиката Ограничен.
• Ако активирате правилото, можете да избирате между разрешаване на всички скриптове (неограничен), позволявайте само подписани локални и отдалечени скриптове (RemoteSigned) или да се разрешат само подписани скриптове (AllSigned).
• Ако го оставите неконфигурирано, то няма да наложи нищо самостоятелно и каквото и да е зададено от PowerShell, ще има предимство.

Когато една и съща настройка съществува както в настройките на устройството, така и в потребителските настройки, Политиката, дефинирана на ниво екип, има предимство пред политиката на потребителя.Това позволява на администраторите да осигурят минимално ниво на защита на всички компютри, като същевременно предоставят определени допълнителни свободи на конкретни потребители чрез специфични за потребителя политики.

Работа с подписани скриптове и файлове, изтеглени от интернет

В Windows браузърите и други програми, които изтеглят файлове (като някои имейл или мессенджери), добавят алтернативен поток от данни (ADS), който маркира файла като „от интернет“Ако вашата политика за изпълнение е RemoteSigned, PowerShell ще използва този флаг, за да реши дали да изпълни неподписания скрипт или не.

Когато срещнете изтеглен скрипт, който PowerShell отказва да изпълни, имате няколко опции: Подпишете го с надежден сертификат, отключете го изрично или променете политиката за изпълнениеПървият вариант обикновено е най-безопасният в контролирана среда, но за бързи тестове е обичайно да се отключва.

Започвайки с PowerShell 3.0, можете да изброявате и управлявате тези потоци от данни, като използвате параметъра -Поток de Get-Itemи можете да използвате Unblock-File За да премахнете интернет маркировката от файла и да позволите на политиката RemoteSigned да я приеме:

Get-Item .\ScriptDescargado.ps1 -Stream *
Unblock-File -Path .\ScriptDescargado.ps1

Във всеки случай, Не пренебрегвайте здравия разум: отключването или облекчаването на политиката за изпълнение не прави подозрителен скрипт безопасен.Това просто премахва една от бариерите.

Политики за изпълнение в Windows Server Core и Nano Server

В издания като Windows Server Core или Nano сървърА също и в други контексти, където работният плот на Windows (explorer.exe) е недостъпен или се инициализира бавно, PowerShell може да се провали при опит за проверка на зоната за сигурност на скрипт. Това води до грешки като:

AuthorizationManager check failed.
At line:1 char:1
+ C:\scriptpath\scriptname.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Причината е, че PowerShell използва Windows shell API, за да определи от коя зона произхожда даден файл.И ако обвивката не работи, проверката е неуспешна и блокира скрипта. В тези среди често е добра идея да се използват правила като Заобикаляне или AllSignedкоито не зависят от проверката на тази зона и избягват този тип грешка при оторизация.

Пример от реалния свят: комбиниране на задачи и действия на високо ниво с текущия потребител

Често срещан сценарий е необходимостта Изпълнявайте в същия скрипт задачи, които изискват администраторски права, и други, които трябва да се изпълняват, докато потребителят е влязъл в системата.Например, копиране на изпълним файл в C:\Windows (необходимо е повишаване на правата) и след това експортирайте оформлението на началното меню на текущия потребител с Export-StartLayout.

Представете си подобен скрипт:

# Parte que requiere elevación
Copy-Item -Path "\\Servidor\Herramientas\plink.exe" -Destination "C:\Windows"

# Parte que debería ejecutarse como usuario actual
Export-StartLayout -Path 'C:\Temp\Orig.xml'

Копието до C:\Windows Работи само ако скриптът се изпълнява с повишени идентификационни данни или можете да го управлявате с инструменти като WingetНо Export-StartLayout има смисъл само в контекста на потребителя, който е отворил графичната сесия.Ако се стартира като SYSTEM или друг администраторски потребител, експортираният стартов шаблон няма да съответства на очакванията на крайния потребител.

В съвременните версии на PowerShell има модул като Invoke-AsCurrentUser (Насочено към PowerShell 7), което ви позволява да изпълнявате команди от името на интерактивния потребител. В PowerShell 5.1 обаче тази опция не е налична по подразбиране и намирането най-лесният начин да „намалите привилегиите си“ Не е тривиално. Често решението включва разделяне на работата: една част се извършва в повишен контекст (инсталации, копия в защитени директории), а друга се делегира на скриптове, стартирани от обикновения потребител (например при влизане в системата, чрез GPO или преки пътища в менюто „Старт“).

Класическата грешка: „Изпълнението на скриптове е деактивирано на тази система“

Ако тепърва започвате с PowerShell, има вероятност да се сблъскате с проблеми веднага щом се опитате да стартирате първата си команда. .ps1 съобщението се появява, че Файлът не може да бъде зареден, защото изпълнението на скрипта е деактивирано.Това предупреждение е точно практическото приложение на политиката за ограничено изпълнение, за която говорихме по-рано.

Типичен случай: създавате прост скрипт, например FirstScript.ps1който само записва текст на екрана. От конзолата на PowerShell се опитвате да го стартирате с нещо подобно & "C:\Users\TuUsuario\Documents\FirstScript.ps1"и PowerShell отговаря с грешката, сочеща към проблема about_Execution_Policies в официалната документация.

За да видите какво се случва, нормалното нещо, което трябва да направите, е Отворете PowerShell като администратор (щракнете с десния бутон върху „Windows PowerShell“ > „Изпълни като администратор“) и изпълнете:

Get-ExecutionPolicy -List

В много случаи ще откриете, че ефективната политика е или Ограничен или е недефиниран в съответните домейни, което в крайна сметка се държи като „Ограничен“. За да се отблокира ситуацията, без да се усложняват нещата прекалено, разумен вариант е да се активира RemoteSigned за текущия потребител:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

След прилагането на тази промяна, ако изброите отново правилата, ще видите, че правилото на текущия потребител вече има стойност RemoteSigned. Ще можете да изпълнявате скриптове, които сами създавате в профила си, без да е необходимо да ги подписвате., а тези, идващи от интернет, трябва да бъдат подписани или отключени ръчно.

Когато изпълните скрипта си отново, грешката изчезва и кодът се изпълнява нормално. Този малък тест ясно демонстрира, че Windows дава приоритет на сигурността по подразбиране.Това блокира скриптове на трети страни, докато не решите да отворите тази врата. Промяната не изисква обширни технически познания, но е важно да се разберат напълно нейните последици в производствена среда.

Заключителни съображения

Ако целта ви е да автоматизирате отвъд PowerShell (например в браузъра), инструменти като iMacros ви позволяват да Записване и възпроизвеждане на действия в мрежатаНо това попада в различна категория от системните скриптове. Въпреки това, философията е подобна: автоматизирате повтарящи се задачи, за да спестите време, като винаги внимателно контролирате какво се изпълнява и с какви разрешения.

Овладяването на начина, по който PowerShell обработва разрешенията, повишените сесии, правилата за изпълнение и разликата между подписани и изтеглени скриптове, ви поставя в много изгодна позиция: можете да се възползвате от полезни скриптове дори без администраторски права, да знаете кога трябва да повишите привилегиите си, да избягвате досадни грешки и най-вече да не нарушавате модела за сигурност на Windows, като се опитвате да напреднете твърде бързо и да научите как да... Поддържайте Windows 11 защитен.