Глава 4. Применение PowerShell 7 в вашей корпорации

Для многих пользователей PowerShell и те команды, которые поставляются с Windows Server и клиентом Windows, вполне достаточны. Однако в более крупных организациях требуются дополнительные моменты для управления инфраструктурой ИТ вашей организации. Они включают инструменты, которые способны упрощать ваши задания.

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

Для управления ролями и свойствами Windows, а также управления самим Windows при помощи PowerShell вы можете применять модули команд PowerShell. Вы можете управлять большинством свойств Windows при помощи PowerShell, применяя те инструменты, которые поставляются с самой этой функциональной возможностью. Вы можете устанавливать такие инструменты совместно с самим свойством - устанавливая модуль ActiveDirectory при установке в вашей системе Active Directory.

Вы также можете устанавливать такие инструменты управления отдельно и управлять свойствами удалённо. RSAT (Remote Server Administration Tools, Инструменты удалённого администрирования сервером) позволяют вам управлять ролями и свойствами Windows. В рецепте Устанавливаем инструменты RSAT в Windows Server вы получите сведения относительно самих инструментов RSAT и того как их устанавливать в Windows Server.

Хотя инструменты RSAT и и обеспечивают отличную функциональность, они не позволяют вам выполнять всё, что вы бы могли пожелать. Для заполнения таких пробелов сообщество PowerShell создало большое число сторонних модулей/ команд, которые вы можете применять для расширения предоставляемых Microsoft модулей. Чтобы справляться с ними, вам потребуется управление пакетами, которое вы изучите в Изучаем управление пакетами. В рецепте Изучаем PowerShellGet и PS Gallery вы взглянете на один из источников модулей и исследуете как находить и применять модули, содержащиеся в Галерее PS.

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

Для того чтобы вы могли подписывать как приложения, так и сценарии PowerShell PowerShell применяет технологию Microsoft Authenticode. Собственно подпись это криптографический хэш соответствующих исполняемого файла или сценария, основанный на сертификате кода подписи X.509. Основным ключевым преимуществом является то, что подпись предоставляет криптографическое доказательство того, что подписанный исполняемый файл или сценарий не изменялись с момента их подписания. Кроме того, вы можете применять такую цифровую подпись для предоставления невозможности отказа от авторства (non-repudiation) - то есть, лишь та персона, которая была способна подписать данный файл будет той единственной персоной, которая обладает таким частным ключом подписи сертификата.

В Работаем с закладками и модулем PSShortcut вы изучите как создавать закладки (ярлыки) и управлять ими. Некая закладка (ярлык), это файл, который указывает на другой файл. Вы можете обладать неким файлом ссылки (в расширением .LNK), который предоставляет некий ярлык на исполняемую программу. Вы можете разместить закладку на VS Code или PowerShell на своём рабочем столе. Второй тип ярлыков, закладки URL это файл (с расширением .URL). Вы можете помещать на рабочем столе закладку, которая будет указывать на определённый вебсайт. Для установления ярлыка ссылки вы можете применять объект COM Wscript.Shell. Вы также можете пользоваться модулем PSShortcut для создания, обнаружения и управления обоими типами ярлыков.

Некий архив это файл, который содержит прочие, обычно сжатые, файлы и папки. Вы запросто можете создавать новые файлы архивов и расширять уже имеющиеся. Архивы очень полезны, как для содержания в них большого числа документов, так и для их сжатия. Вы можете собирать вместе в пакет документы, сценарии и графические файлы в виде единого архива. Вы также можете применять сжатие для передачи файлов журналов - текстовый файл журнала в 100 МБ может быть сжат менее чем до 3-4 МБ, что позволяет вам отправлять такие файлы журналов электронной почтой. В Работаем с файлами архивов вы создадите и примените файлы архивов.

Инструменты RSAT основополагающие для администрирования ролей и свойств, которые вы можете устанавливать в Windwos Server. Всякая функциональная возможность в Windows Server может опционально обладать инструментами управления, причём так обстоят дела для большинства из них. Эти инструменты могут включать в себя командлеты PowerShell, функции и псевдонимы, а также GUI файлы MMC (Microsoft Management Console, Консоли управления Microsoft. Некоторые функциональные возможности также обладают более ранними консольными приложениями Win32. В большинстве случаев вам не нужны консольные приложения, ибо вы можете применять командлеты, но это не всегда так. У вас могут иметься более старые сценарии, которые применяют такие консольные приложения.

Вы также можете устанавливать в Windows Server инструменты RSAT независимо от функциональных возможностей Windows Server. Данный рецепт охватывает установку инструментов RSAT в Windows Server 2022.

Вы также можете устанавливать инструменты RSAT в Windows 10 и выполнять удалённое администрирование своими серверами. Сам конкретный метод установки инструментов RSAT разнится в зависимости от конкретной применяемой вами версии Windows. Для более ранних версий Windows вы можете выгружать эти инструменты отсюда: https://www.microsoft.com/download/details.aspx?id=45520. {https://www.microsoft.com/ru-ru/download/details.aspx?id=45520}

В более поздних редакциях Windows 10, начиная с октябрьского обновления Windows 10 {1809}, вы устанавливаете инструменты RSAT при помощи механизма "Features on Demand" (Компоненты по запросу) внутри Windows 10. Ссылка URL из предыдущего параграфа снабдит вас полными подробностями относительно того как устанавливать инструменты RSAT в Windows 10.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server 2022 Datacenter Edition.

На Шаге 1 для получения всех команд внутри всех модулей в SRV1 мы пользуемся командой Get-Command. Этот шаг затем отображает счётчик общего числа доступных в SRV1 команд и того сколько реальных командлетов имеется в SRV1 перед установкой инструментов RSAT. Получаемый на этом этапе вывод выглядит примерно так:

На Шаге 2 мы отображаем счётчик типа команд доступных до сих пор в SRV1, что выглядит так:

В powerShell, когда вы применяете Get-Command, этот командлет для описания различных типов команд возвращает различные типы объектов. Как вы можете наблюдать из предыдущего этапа, имеется три различных типа команд, которые PowerShell возвращает в различных классах объектов. На Шаге 3 вы можете видеть названия соответствующих классов для этих трёх типов команд, что отображено ниже:SRV1

На Шаге 4, который не производит вывод, вы получаете все типы доступных в SRV1 модулей. На Шаге 5 вы отображаете счётчик общег числа доступных модулей (79), что выглядит как-то так:

На Шаге 6 вы получаете счётчики доступных компонентов и установленных компонентов, а также общее число доступных и установленных функциональных возможностей RSAT. Этот этап не вырабатывает вывод.

На Шаге 7 вы отображаете значения полученных на Шаге 6 счётчиков, что отображается следующим образом:

На Шаге 8 вы получаете все компоненты RSAT и устанавливаете их в Windows Server. Этот процесс потребует некоторого времени и выработает вывод, подобный такому:

Установка этих инструментов потребует перезапуска, как вы могли заметить на нашем предыдущем снимке экрана. Таким образом, на Шаге 9 мы перезапускаем свою систему. После такого перезапуска для продолжения вы регистрируетесь в SRV1 в качестве администратора.

Теперь, когда вы добавили все относящиеся к RSAT компоненты Windows, вы можете получить подробности о том что вы установили. На Шаге 10, который не производит вывод, вы получаете подробности только что установленных компонентов и числа команд, которые они содержат. На Шаге 11 вы отображаете счётчик не доступных в SRV1 компонентов RSAT, что выглядит так:

На Шаге 12 вы отображаете те компоненты RSAT, которые вы установили на более раннем шаге. Вывод этого шага приводится ниже:

Вывод на Шаге 1 показывает что, перед добавлением инструментов RSAT, доступными в SRV1в сумме имеются 1 829 команд и 594 командлета на основе модулей. Значение получаемого числа может отличаться в зависимости от того какие дополнительные инструменты, компоненты или приложения вы могли добавлять в SRV1 или в саму версию Windows Server.

На Шаге 2 и на Шаге 3 вы находите виды доступных команд и название типа их объектов, которые PowerShell применяет для описания этих различных типов команд. Когда вы получили значения названий классов, вы можете воспользоваться предпочитаемым вами механизмом поиска для выявления дополнительных подробностей относительно этих типов команд.

Модуль PowerShell PackageManagement предоставляет инструменты, которые позволяют вам выгружать или устанавливать пакеты программного обеспечения из различных источников. Этот модуль, по существу, реализует некое взаимодействие с поставщиком, который применяется системами управления пакетами программного обеспечения для управления пакетами программного обеспечения.

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

Этот модуль, по существу. Это некий API для поставщиков управления пакетами, такими как PowerShellGet, обсуждается в нашем рецепте Изучаем PowerShellGet и PS Gallery. Самая первейшая функция этого модуля PackageManagement состоит в управлении определёнными репозиториями наборов программного обеспечения, в которых инструменты управления пакетами способны выполнять поиск, получать, устанавливать и удалять пакеты. Этот модуль позволяет вам выявлять и применять пакеты программного обеспечения из различных источников. Имеющиеся в такой галерее модули отличаются по качеству. Некоторые из них исключительны и интенсивно применяются всем сообществом, в то время как прочие менее полезны или обладают меньшим качеством. Будьте уверены что вы тщательно рассмотрели модули сторонних производителей для помещения их в промышленную среду.

Данный модуль исследует модуль PackageManagement в сервере SRV1.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 вы применяете Get-Command для просмотра производимых PackageManagement команд, что выглядит примерно так:

На Шаге 2 вы пользуетесь командлетом Get-PackageProvider для выявления установленных поставщиков, что выглядит следующим образом:

На Шаге 3 вы используете Find-PackageProvider для выявления всех прочих поставщиков, которых вы можете применять. Её вывод отображается так:

На Шаге 4 вы выявляете и подсчитываете те пакеты, которые вы можете найти с помощью Find-Package со следующим выводом:

Чтобы проиллюстрировать некоторые из тех пакетов, которые мы только что выявили, на Шаге 5 вы просматриваете самые первые пять пакетов, которые отображаются так:

На Шаге 6 вы устанавливаете поставщика пакетов Chocolatier, который снабдит вас через управление пакетами его репозиторием Chocolatey. Chocolatey это репозиторий сторонних приложений, хотя и не напрямую, но поддерживаемый Microsoft. Для дополнительных сведений относительно репозитория Chocolatey обращайтесь к https://chocolatey.org/.

На Шаге 7 вы пересматриваете тех поставщиков, которые теперь доступны в SRV1, чтобы убедиться что в них включён Chocolatier, что выглядит теперь так:

На Шаге 8 вы выявляете те пакеты, которые доступны через поставщика Chocolatier и отображаете счётчик пакетов. На этом шаге вы также фиксируете дату и время между началом и концом поиска пакетов. Вывод с данного этапа выглядит так:

На Шаге 9 вы отображаете то время, которое потребовалось для поиска пакетов в Chocolatier, который отображается следующим образом:

На Шаге 4 вы получаете список пакетов (и отображаете счётчик обнаруженных пакетов) и затем, на Шаге 5, отображаете первые пять. Те пакеты, которые вы наблюдаете на этом шаге, скорее всего изменятся - все репозитории пакетов в состоянии почти постоянного изменения. Когда вы ищите пакеты, окажется полезным подход, предлагаемый на этих двух шагах. Вы выгружаете весь список пакетов, которые хранятся локально. Затем мы дополнительно исследуем о существующих пакетах не тратя слишком много времени для выемки полного списка пакетов с любого выбранного репозитория. Позднее, на Шаге 9, вы отображаете сколько времени потребовалось для получения списка пакетов с Chocolatey. В вашей среде это время может отличаться от показанного здесь, однако это иллюстрирует полезность получения перечня пакетов прежде чем погружаться в поиски.

На Шаге 6 вы устанавливаете другого поставщика пакетов, Chocolatier. Этот поставщик предоставляет вам доступ через имеющиеся команды управления пакетами к репозиторию Chocolatey. Chocolatey снабжает вас доступом к общим приложениям платформ подобно apt-get в Linux (но для Windows). Как всегда, будьте внимательны при получении приложений или компонентов приложений из репозиториев сторонних разработчиков, поскольку ваши производители и партнёры могут не предоставлять полную поддержку в случае некого инцидента.

На Шаге 9 вы просматриваете насколько долго продолжалось выявление пакетов из одного репозитория. Этот шаг отображает длительность затраченного времени и это время может меняться. Обратите внимание, что когда вы самый первый раз исполняете это шаг, его код выдаёт приглашение на установку choco.exe.

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

С тех пор, как была выпущена V1 (а возможно и ранее!) члены сообщества предоставляли надстройки. Некоторые попытки любезными, не совсем оптимальными, но это всё же лучше чем ничего. По мере роста PowerShell и сообщества росло и качество этих надстроек.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 вы исследуете команды внутри модуля PowerShellGet, что выглядит так:

На Шаге 2 вы обнаруживаете в модуле PowerShellGet, которые позволяют вам выполнять поиск ресурсов. Естественно, они применяют глагол Find. Вывод на этом этапе выглядит подобно следующему:

На Шаге 3 вы применяете несколько команд Find-* для поиска ключевых ресурсов в Галерее PowerShell, которые не производят вывода. На Шаге 4 вы просматриваете счётчик для каждого типа ресурсов:

На Шаге 5 вы используете возвращаемый список модулей для выявления относящихся к NTFS модулей, подобно таким:

На Шаге 6 вы устанавливаете модуль NTFSSecurity, что не приводит к выводу. На Шаге 7 вы просматриваете команды в модуле NTFSSecurity, что производит следующий вывод:

При подготовке к выгрузке другого модуля, на Шаге 9 вы создаёте новую папку для сохранения соответствующего выгружаемого модуля. На Шаге 10 вы выгружаете модуль CountriesPS. Ни один из этих шагов не вырабатывает вывод.

На Шаге 11 вы исследуете те файлы, которые составляют это модуль, что выглядит так:

На Шаге 12 вы находите модуль CountriesPS и импортируете его. Благодаря переключателю -Verbose, Import-Module производит дополнительный вывод, который вы можете наблюдать здесь:

На Шаге 13 вы пользуетесь командой Get-Command для проверки команд, доступных в модуле CountriesPS, что выглядит так:

На окончательном шаге данного рецепта, Шаге 14, вы пользуетесь командой Get-Country для возврата подробностей страны для United Kingdom, что отображается ниже:

На Шаге 2 вы обнаруживаете команды внутри модуля PowerShellGet, который позволяет вам находить ресурсы в Галерее PS. Существует пять типов поддерживаемых ресурсов:

На Шаге 3 и на Шаге 4 вы выявляете число команд, модулей, ресурсов DSC и сценариев, доступных в галерее. Поскольку присутствует активность, значение числа ресурсов PowerShell, которое вы выявите, скорее всего будет отличаться от того, что вы наблюдаете в этой книге.

На Шаге 5 вы выполняете поиск в Галерее PS модулей, которые содержат строку "NTFS". Вы также можете применять в PowerShell командлет Find-Command для просмотра конкретных команд, которые могут содержать символы "NTFS".

На Шагах с 6 по 8, вы пользуетесь модулем NTFSSecurity из галереи PowerShell. Этот модуль, который вы позднее будете применять позднее в главах этой книги, позволяют вам управлять ACL (Access Control Lists, Списками управления доступа) NTFS. Этот модуль являет исключительный пример полезного набора команд, который команда разработки PowerShell могла бы включить, на не стала, ни внутри Windows PowerShell, ни в PowerShell 7. Однако при помощи модуля PowerShellGet вы можете находить, выгружать и использовать модули из Галереи PowerShell.

На Шагах с 9 по 14 вы проходите процесс выгрузки и проверки модуля CountriesPS. Эти этапы показывают как вы можете выгружать и применять модули без необходимости их установки. Тот подход, который отражён в данных шагах, полезен когда вы изучаете модуль на предмет возможности его применения. Имеющаяся в этом модуле команда, Get-Country, пользуется интерфейсом REST для вебсайта https://restcountries.eu/. Репозиторий GitHub обладает набором образцов того, как вы некоторыми способами можете применять Get-Country, которые вы можете обнаружить в https://github.com/lazywinadmin/CountriesPS.

Те два рецепта, которые вы изучили в этом рецепте, лишь маленькая часть всей Галереи PowerShell. Как вы обнаружили, имеются тысячи модулей, команд и сценариев. Будет справедливым сказать, что некоторые из этих объектов не самого высшего качества и вы можете не применять их. Прочие же являются исключительным добавлением для вашей коллекции модулей, что продемонстрируют многие рецепты из этой книги.

Для большинства ИТ специалистов Галерея PowerShell это достойное место, где можно найти полезные модули, которые избавят вас от необходимости изобретать велосипед. В некоторых ситуациях вы можете разработать особенно полезный модуль, а затем опубликовать его в Галерее PS, чтобы поделиться им с другими. Для получения инструкций по публикации в Галерее PS обращайтесь к https://docs.microsoft.com/powershell/scripting/gallery/concepts/publishing-guidelines. И, пока вы просматриваете эту страницу, задумайтесь о применении передовых методов, предлагаемых в любом разрабатываемом вами промышленном сценарии.

В рецепте Изучаем PowerShellGet и PS Gallery вы выдели как вы можете выгружать модули и тому подобное PowerShell из Галереи PS. Вы можете устанавливать или сохранять их для исследования. Одной из приятных функциональных возможностей является то, что после установки модуля с применением Install-Module, позднее вы можете позднее воспользоваться Update-Module для их обновления.

Альтернативой применению общедоступного репозитория выступает создание частного внутреннего репозитория. Затем вы можете применять команды из модуля PowerShellGet для поиска, установки и управления вашими модулями. Частный репозиторий позволяет вам создавать ваш модуль и помещать его в локальном репозитории для доступа вашим профессионалов ИТ, разработчикам или пользователям.

Имеются различные способы настройки внутреннего репозитория. Одним из подходов будет применение стороннего инструмента, например, ProGet от Inedo (для подробностей относительно ProGet, обращайтесь к https://inedo.com/).

Простым способом создания репозитория является установка некого совместного ресурса SMB. Затем, вы применяете команду Register-PSRepository чтобы позволить каждой системе применять команды PowerShellGet для просмотра этого совместного ресурса в качестве репозитория PowerShell. После того как вы создаёте такой совместный ресурс и зарегистрируете этот репозиторий, вы можете публиковать свои модули в этом новом репозитории при помощи команды Publish-Module.

После того как вы настроите такой репозиторий, вам просто надлежит проверить что вы воспользовались Register-PSRepository во всех системах, в которых вы бы желали применять такой новый репозиторий, как мы сможем наблюдать в этом рецепте.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 вы создаёте в SRV1 папку, которую планируете применять для содержания репозитория. На этом шаге нет вывода. На Шаге 2 вы создаёте в SRV1 совместный ресурс SMB, RKRepo, что выглядит следующим образом:

Прежде чем команды из модуля PowerShellGet смогут пользоваться этим совместным совместным ресурсом в качестве репозитория, вам надлежит зарегистрировать этот репозиторий. Вам следует выполнить это действие из любого хоста, кторый должен применять данный репозиторий посредством команд из модуля PowerShellGet На Шаге 3 вы регистрируете этот репозиторий что не создаёт вывод.

На Шаге 4 для просмотра доступных вам репозиториев вы пользуетесь Get-PSRepository, что выглядит следующим образом:

Для иллюстрации того как вы можете применять репозиторий, вы программируете некий модуль. На Шаге 5 вы создаёте новую папку для содержания в ней рабочей копии своего модуля. На Шаге 6 вы создаёте некий модуль сценария и сохраняете его в этой рабочей папке. Эти два этапа не производят вывод.

На Шаге 7 вы проверяете свой модуль HW импортируя соответствующий файл .PSM1 непосредственно в свою рабочую папку и затем применяя псевдоним GHW. Чтобы просмотреть те действия, которые предпринимает Import-Module при импорте вашего нового модуля вы предписываете переключатель -Verbose. Вот вывод этого шага:

Прежде чем вы сможете публиковать модуль в своём репозитории, вы должны создать манифест модуля для сопровождения файла этого модуля сценария. На Шаге 8 для создания манифеста данного модуля вы применяете New-ModuleManifest. На Шаге 9 вы публикуете свой вывод. Оба этапа не производят вывод.

На Шаге 10 вы просматриваете только что созданный репозиторий при помощи Find-Module и определяете свой репозиторий RKRepo. Вывод этого этапа приводится ниже.

На Шаге 11 вы исследуете ту папку, которая содержит ваш репозиторий. В получаемом выводе вы можете наблюдать модули пакета NuGet, что выглядит как-то так:

На Шаге 1 вы создаёте папку в устройстве C:\ для хранения содержимого репозитория. В промышленном применении вам следует рассмотреть создание такой папки в отдельных томах высокой доступности.

На Шаге 4 вы просматриваете доступность репозиториев. По умолчанию вам доступна Галерея PS, хотя и в качестве репозитория без доверия. Вы также можете наблюдать репозиторий RKRepo. Поскольку вы зарегистрировали этот репозиторий, вы видите, что он отображается как обладающий доверием.

На Шаге 11 вы исследуете папку, содержащую репозиторий RKRepo. После публикации вашего модуля HW, эта папка содержит файл, который хранит ваш модуль HW. Когда файл хранится с расширением nupkg, указывающим на то, что это пакет NuGet. Пакет NuGet это отдельный файл ZIP, который содержит откомпилированный код, сценарии, манифест модуля PowerShell и прочее. Галерея PowerShell в действительности это набор пакетов NuGet. За дополнительными сведениями относительно NuGet обращайтесь к https://docs.microsoft.com/nuget/what-is-nuget.

Часто вы находите, что существенно обладать знанием того, что некое приложение или сценарий PowerShell не был изменён с момента его выпуска. Для этого вы можете применять Windows Authenticode Digital Signatures (Цифровые подписи Microsoft Authenticode). Authenticode это технология подписи кода Microsoft, которая идентифицирует самого издателя подписанного Authenticode программного обеспечения. Authenticode к тому же проверяет что в это программное обеспечение не осуществлялось вмешательство с момента его подписи и публикации.

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

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

Это звучит как великолепная вещь, однако будет не лишним отметить, что даже когда вы настроили политику исполнения в AllSigned, достаточно просто запускать некий сценарий без подписи. Просто скиньте свой сценарий в VS Code, выберите весь имеющийся в этом сценарии текст и затем выполните этот выбранный сценарий. А когда политика исполнения RemoteSigned блокирует некий конкретный сценарий, вы можете воспользоваться соответствующим командлетом Unblock-File для того, чтобы в действительности переключить удалённый сценарий на локальный. Подпись сценария просто превращает это в слегка затруднительное, однако не в невозможное, исполнять некий сценарий, который не обладает подписью, или подпись которого отказывает.

Подписывание сценария выполняется просто когда вы обладаете цифровым сертификатом, выпущенным CA (Certifcate Authority, Органом сертификации). У вас имеются три варианта для получения соответствующего сертификата подписи кода:

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

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

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 вы создаёте новый сертификат подписи кода с самостоятельной подписью и сохраняете этот сертификат в хранилище My certificate текущего пользователя. Поскольку вы отправляете конвейером вывод из New-SelfSignedCertificate в Out-Null, этот этап не производит вывод.

На Шаге 2 вы выполняете выборку сертификата подписи кода из хранилища сертификатов текущего пользователя, а затем просматриваете этот сертификат, что выглядит так:

На Шаге 3 вы создаёте простой сценарий, который выводит две строки текста, одна из которых содержит название хоста. На приводимом ниже снимке экрана вы можете видеть этот сценарий:

Теперь, когда у вас имеется сценарий, на Шаге 4 вы подписываете этот сценарий вновь созданным сертификатом подписи кода с самостоятельным подписыванием. Вывод с этого шага выглядит следующим образом:

На Шаге 5 вы просматриваете этот подписанный код, что отражается так:

На Шаге 6 вы просматриваете данный сценарий, включая цифровую подпись самого сценария, что показано ниже:

На Шаге 7 вы пользуетесь командлетом Get-AuthenticodeSignature для проверки его цифровой подписи, что выглядит так:

На Шаге 8 вы исполняете подписанный сценарий, что отображается ниже:

На Шаге 9 вы установили политику в AllSigned для настройки PowerShell на обеспечение того, чтобы всякий запускаемый вами сценарий в данном сеансе обязан быть подписанным. На этом шаге нет вывода.

На Шаге 10 вы пробуете исполнить этот сценарий, что в результате приводит к ошибке, что выглядит так:

На Шаге 11 вы копируете свой сертификат в хранилище Trusted Root текущего пользователя. По причинам безопасности PowerShell выводит подтверждающий диалог, который вам надлежит согласовать для завершения копирования, что отображается следующим образом:

На Шаге 12 вы повторно проверяете подпись этого файла, что выглядит так:

На Шаге 13 вы снова пробуете запутить свой сценарий, но с иным результатов, выглядящим следующим образом:

Хотя ваш сертификат и из доверенного (теперь) Центра Сертификации, он не от доверенного издателя. Чтобы разрешить это, на Шаге 14 вы копируете в хранилище Trusted Publishers, что не производит никакого вывода.

Теперь, когда у вас имеются сертификаты как для доверительного корневого хранилища, так и для доверенного хранилища издателя (для вашего пользователя), на Шаге 15 вы повторно исполняете свой сценарий, который выводит следующее:

В этом сценарии вы начинаете с создания сертификата подписи кода и его применения к подписи сценария. По умолчанию, Windows и PowerShell не доверяют самостоятельно подписываемым сертификатам подписи кода.

Чтобы позволить PowerShell доверять такой подписи, вы копируете его сертификат подписи кода в корневое хранилище Центра Авторизации(CA) своего текущего пользователя, что обладает воздействием превращения этого сертификата подписи кода в доверенный для текущего пользователя. Вы осуществляете это на Шаге 11 и замечаете, что вырабатывается всплывающий диалог. Вам также надлежит скопировать этот сертификат в хранилище доверенного издателя, что вы и выполняете на Шаге 14.

В промышленной среде вы бы получили сертификат подписи кода из доверенного Центра Авторизации и аккуратно управились бы со своим хранилищем доверенных сертификатов. Для корпоративных сред вы можете настраивать некий Центр Авторизации и обеспечивать пользователям автоматический контроль для сертификатов корневого Центра Авторизации. При автоматической раскрутке PowerShell (и Windows) способны доверять таким сертификатам, выпускаемым их Центром Авторизации.

В качестве альтернативы для получения сертификатов подписи кода вы можете применять сторонние Центры Авторизации, например, DigiCert, которые по умолчанию обладают доверием со стороны Windows. В распространении доверенный сертификатов корневого Центра Авторизации способствует Программа Доверенного Корня Microsoft. Относительно дополнительных сведений о сертификатах подписи кода DigiCert обращайтесь к https://digicert.leaderssl.com/suppliers/digicert/products#codesigning-products. За подробностями по программе Доверенного Корня Microsoft отсылаем вас к https://docs.microsoft.com/security/trusted-root/program-requirements.

Закладка (ярлык, shortcut) это файл, содержащий указатель н иной файл или URL. Вы можете помещать некий ярлык ссылки оболочки на какую- то исполняемую программу, скажем, PowerShell, на свой рабочий стол Windows. Когда вы кликните по такой закладке в Проводнике Windows, Windows запустит целевую программу. Также вы можете создать некий ярлык для URL.

Ярлык ссылки оболочки обладает расширением .LNK, в то время как закладки URL обладают расширением .URL. Внутри себя файл закладки обладает двоичной структурой, которая не редактируется напрямую. Для получения дополнительных сведений относительно их внутреннего формата смотрите https://docs.microsoft.com/openspecs/windows_protocols/ms-shllink/.

Закладка URL это текстовый документ, который вы можете изменять в VS Code или в Блокноте. Для подробностей относительно формата файла закладок URL отсылаем вас к http://www.lyberty.com/encyc/articles/tech/dot_url_format_-_an_unofficial_guide.html.

Для управления ярлыками в PowerShell 7 нет никаких встроенных команд. Как вы видели ранее в этой книге, для создания ярлыков вы можете пользоваться более старыми объектами COM. Более последовательный способ состоит в применении модуля PSShortcut, который вы можете выгрузить из Галереи PowerShell.

В данном рецепте вы обнаружите в своей системе ярлыки и создадите ярлыки как для исполняемого файла, так и для URL.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 вы применяете команду Find-Module для обнаружения модулей в Галерее PowerShell, чьи названия заканчиваются на "shortcut". Получаемый вывод выглядит примерно так:

На Шаге 2 вы пользуетесь командой Install-Module для установки модуля PSShortcut. Этот шаг не производит вывод.

После того как вы установили модуль PSShortcut, на Шаге 3 вы при помощи команды Get-Module выводите дополнительные сведения относительно этого модуля PSShortcut. Вот что производит вывод на этом шаге:

На Шаге 4 вы обнаруживаете команды, предоставляемые установленным модулем PSShortcut, что выглядит так:

На Шаге 5 для поиска всех ярлыков в SRV1 и сохранения в некой переменной вы применяете Get-Module. Затем вы отображаете счётчик того, сколько вы их обнаружили с выводом, подобным следующему:

На Шаге 6 вы изучаете набор ярлыков файлов ссылок из SRV1 для выявления тех, которые указывают на PWSH (то есть закладки на PowerShell 7), что выглядит так:

На Шаге 7 для обнаружения каких- нибудь закладок URL из SRV1 вы применяете Get-Shortcut, что выглядит примерно так:

На Шаге 8 вы изучаете содержимое найденного файла .URL, что отображено ниже:

На Шаге 9 вы создаёте закладку для google.com, что не производит вывод. На Шаге 10 вы исполняете эту закладку. PowerShell затем запускает ваш браузер по умолчанию (то есть Internet Explorer, например) и переходит по указанному в этом файле URL, что показано далее:

На Шаге 11 вы создаёте ярлык ссылки, что не производит вывод. На Шаге 12 вы исполняете этот ярлык, что переносит нас в Блокнот подобно следующему:

На Шаге 7 вы обнаруживаете ярлыки URL и, как вы можете обнаружить, имеется всего один: к Bing. Установщик Windows создаёт его при установке в данном хосте Windows Server.

На Шаге 8 вы изучаете содержимое закладки URL. В отличии от файлов закладок ссылок, которые обладают двоичным форматом и не полностью читаемы, закладки URL представляют собой текстовые файлы.

С самого начала эры ПК пользователи работали с разнообразием механизмов сжатия файлов. Ранние методы применяли формат файла ZIP, первоначально реализованный программой PKZip PKWare, который быстро превратился практически в стандарт для передачи данных. Позднее стала популярной версия Windows, WinZip, а в Windows 98 Microsoft предоставил встроенную поддержку для файлов архивов .ZIP. В наши дни Windows поддерживает файлы ZIP с размером до 2 ГБ. Дополнительные сведения относительно формата файла ZIP вы можете почерпнуть в https://en.wikipedia.org/wiki/Zip_(file_format).

С годами многие разработчики предоставили альтернативные схемы сжатия и связанных с ним утилит, включая WinRAR и 7-Zip. И WinZip, и WinRAR великолепные программы, но являются коммерческими. 7-Zip бесплатный инструмент и также популярен. Все три представляют свои собственные механизмы сжатия (с соответствующими расширениями файлов), а также поддерживают и прочие.

За подробностями относительно WinZip обращайтесь к https://www.winzip.com/win/en; сведения относительно WinRAR можно найти на https://www.win-rar.com/, а больше узнать об 7-Zip вы можете на https://www.7-zip.org/. Каждая из этих утилит сжатия, предлагаемых данными группами, также поддерживает механизмы сжатия из прочих сред, например, TAR.

В данном рецепте вы рассмотрите встроенные в PowerShell 7 команды для управления файлами архивов. Эти команды работают лишь с файлами ZIP. Вы можете найти модуль PowerShell для 7-Zip в https://github.com/thoemmi/7Zip4Powershell, хотя этот модуль достаточно древний и не обновлялся какое- то время.

Вы выполняете этот рецепт в SRV1, в котором вы установили PowerShell 7 и VS Code. SRV1 является сервером рабочей группы, запущенным с Windows Server Datacenter Edition.

На Шаге 1 мы пользуемся Get-Module для изучения своего модуля Microsoft.PowerShell.Archive , что выглядит так:

Для выявления всех команд в нашем модуле Microsoft.PowerShell.Archive на Шаге 2 мы применяем Get-Command, что отображается следующим образом:

На Шаге 3 вы создаёте новую папку, которую на Шаге 4 вы заполняете 100 текстовыми файлами. Эти два шага не производят вывод.

На Шаге 5 для получения всех файлов в своей папке архива и измерения значения размера всех этих файлов вы применяете Get-ChildItem. Его вывод отображён ниже:

На Шаге 6 вы сжимаете весь набор файлов, созданных вами на Шаге 5. Этот шаг сжимает набор файлов в некий файл архива, что не производит вывода. На Шаге 7 вы сжимаете папку и её содержимое. Данный шаг создаёт некую корневую папку в получаемом файле архива, которая содержит все заархивированные (и сжатые) файлы. Этот шаг также не производит вывод.

На Шаге 8 вы пользуетесь Get-ChildItem для просмотра своих двух файлов архивов, что отображается так:

На Шаге 9 вы применяете Проводник Windows для просмотра всех файлов в своём первом файле архива, что показывает индивидуальные сжатые вами в общий архив файлы. Вот вывод с этого шага:

На Шаге 10 вы при помощи Проводника Windows просматриваете свой второй файл архива, что показано далее:

На Шаге 11 вы создаёте новую папку (C:\Foo\Decompressed), что не производит вывода. На Шаге 12 вы применяете Expand-Archive для распаковки всех файлов в Archive1.ZIP в созданную на предыдущем шаге папку, что также не приводит к выводу.

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

На Шаге 6 и на Шаге 7 вы сжали 100 файлов, которые вы создали в данном рецепте ранее. Основное отличие между этими двумя шагами заключается в том, что первый шаг просто сжимает набор файлов, в то время как второй создаёт некую корневую папку, содержащую 100 файлов. На Шаге 8 вы можете наблюдать в размерах этих файлов, когда второй архив несколько больше чем первый, обладая наличием корневой папки.

На Шаге 12 вы распаковываете свой первый архив, а на Шаге 13 вы можете наблюдать, что он содержит то же самое число файлов и тот же самый общий размер файлов что и те 100 файлов, которые вы первоначально сжали.