Просмотр исходного кода

Добавить 'Лекции/2.2.53_PowerShell_Автоматизация_настроек/goev.md'

u23-27goev 5 дней назад
Родитель
Сommit
ea2a03603a

+ 94 - 0
Лекции/2.2.53_PowerShell_Автоматизация_настроек/goev.md

@@ -0,0 +1,94 @@
+# PowerShell Автоматизация настроек
+---
+**PowerShell** 
+- это средство автоматизации разработанное и выпущенное Microsoft в 2006 году на замену Командной строке и её батникам, помимо всего функционала cmd - Powershell обзавелась собственным скриптовым языком с поддержкой классов, объектов, переменных и т.д. По сути с её помощью можно обращаться ко всему функционалу Windows и Windows Server как к объектам и выполнять с ними действия.
+
+---
+### **Настройка свойств консоли PowerShell**
+При первом запуске PowerShell внешний вид консоли определяется настройками свойств по умолчанию или параметрами, которые установлены «горячей клавишей» и проходят как аргументы к исполняемому файлу PowerShell. Например, когда вы запускаете PowerShell, дважды щелкая на файле powershell.exe, он открывается с установками свойств по умолчанию. То же касается и запуска PowerShell «горячей клавишей», которую вы создали для исполняемого файла или запуска PowerShell из командной строки Windows. Вы увидите маленькое окно командного процессора с черным фоном и серым шрифтом
+Независимо от того, как вы запускаете PowerShell, вы можете изменить внешний вид консоли через настройки свойств. Для доступа к ним щелкните на значке PowerShell в верхнем левом углу окна консоли, а затем на Properties, чтобы открыть диалоговое окно «Свойства».
+
+---
+### **УЧЕТНЫЕ ДАННЫЕ И БЕЗОПАСНЫЕ СТРОКИ В POWERSHELL**
+
+В прошлом, когда скрипты PowerShell работали только локально, а все серверы были подключены к одному домену Active Directory, проблем с аутентификацией не возникало. Достаточно было настроить планировщик заданий и запускать скрипт от лица определенного пользователя. Сегодня, в условиях гибридных кросс-платформенных систем, одному скрипту часто приходится подключаться к ресурсам из разных сред. В большинстве случаев при этом нужно передавать пароли, API-ключи и другие учетные данные. И чтобы не хранить их в виде текста в файлах и памяти, в PowerShell предусмотрены объекты SecureString и PSCredential.
+
+---
+### **Безопасные строки**
+
+При изменении стандартной строки PowerShell сначала создает в памяти ее копию. Поэтому даже при удалении переменной или присвоении ей значения null старые копии строки могут остаться в памяти. Экземпляры объекта SecureString работают по-другому: они хранятся в зашифрованном виде, а новых копий не создается. Шифрование защищает от риска получить строку путем анализа дампов памяти. Отсутствие копий гарантирует, что строка будет полностью уничтожена при удалении переменной или завершении процесса.
+
+
+ПРИМЕЧАНИЕ Прежде чем перейти к разговору о безопасных строках, важно сказать, что их можно использовать только на Windows. В основе объекта SecureString — API .NET Framework API, а не .NET Core. Применять их на Linux и MaxOS технически возможно, но строки в памяти шифроваться не будут.
+
+Создать экземпляр объекта SecureString можно двумя способами: при помощи командлетов ConvertTo-SecureString или Read-Host. Во втором случае в качестве параметра нужно указать AsSecureString. При этом поступит запрос на ввод значения, а введенная пользователем строка будет сохранена как безопасная:
+
+
+$SecureString = Read-Host -AsSecureString
+$SecureString
+System.Security.SecureString
+
+Командлет ConvertTo-SecureString с параметром AsPlainText преобразует стандартную строку в безопасную. Однако нужно помнить, что эта строка уже хранится в памяти, а значит, такой подход не столь безопасен, как Read-Host. Если включить в скрипт текстовую строку, она может попасть в журнал событий или остаться в истории PowerShell. Поэтому в подтверждение того, что разработчик понимает все риски, командлет требует использования параметра Force.
+
+---
+### **Объект учетных данных**
+
+Для хранения учетных данных в PowerShell предусмотрен объект PSCredential. Он включает стандартную строку для имени пользователя и безопасную строку для пароля. Как и в случае SecureString, создать экземпляр PSCredential можно двумя способами.
+
+Первый из них — командлет Get-Credential, который предложит пользователю ввести учетные данные:
+
+
+$Credential = Get-Credential
+
+Второй способ — создать экземпляр PSCredential вручную, объединив обычную строку с именем и объект SecureString с паролем. При этом незащищенные копии этих строк останутся в памяти
+
+Объекты PSCredential можно использовать только в системах и командах, которые их поддерживают, в том числе передавать командлетам PowerShell в качестве параметров. При работе с системами, где такая поддержка отсутствует, можно преобразовать PSCredential в объект .NET NetworkCredential. Например, такой подход применим при подключении к базам данных и веб-приложениям, а также при базовой, дайджест-, NTLM- и Kerberos-аутентификации
+
+---
+### **Настройка хранилища SecretStore**
+
+Хранилище SecretStore — отличный способ познакомиться с модулем SecretManagement. У него есть большой недостаток: хранилище всегда привязано к пользователю и компьютеру, а значит, его нельзя переместить на другую систему либо использовать совместно с другими. Однако создать такое хранилище можно за считаные минуты. Чтобы увидеть, как это просто, настроим модули SecretStore и SecretManagement. В дальнейшем мы будем использовать их при проверке состояния баз данных.
+
+
+Установка модулей
+
+Прежде всего установим эти два модуля. Оба они доступны в каталоге PowerShell, поэтому можно использовать команду PowerShellGet:
+
+
+Install-Module Microsoft.PowerShell.SecretStore
+Install-Module Microsoft.PowerShell.SecretManagement
+ 
+
+Настройка хранилища SecretStore
+
+После установки модулей нужно создать хранилище SecretStore. Для этого предназначен командлет Get-SecretStoreConfiguration. При первой настройке SecretStore понадобится ввести пароль для доступа к хранилищу
+
+---
+### **Регистрация хранилища**
+
+Предыдущие шаги касались настройки хранилища SecretStore. Но для того чтобы SecretManagement знал, где искать секретные данные, это хранилище нужно зарегистрировать. Передадим его имя, а также название модуля-расширения в качестве параметров командлета Register-SecretVault. Имя хранилища в дальнейшем будет указываться в скрипте.
+
+---
+### **Выбор подходящего хранилища**
+
+Выбор хранилища зависит от требований проекта. Например, SecretStore всегда привязано к одному пользователю и компьютеру, что повышает уровень безопасности, но затрудняет переносимость скриптов. В KeePass таких ограничений нет, поэтому хранилище легко перенести на другой компьютер. Однако файл данных более уязвим и может быть скомпрометирован при недостаточной защите.
+Одно из преимуществ модуля SecretManagement — возможность работы с разными хранилищами на стороне сервера
+
+---
+### **Добавление данных в хранилище**
+
+Когда все хранилища будут настроены и зарегистрированы, можно поместить в них необходимые данные. Для этого служит командлет Set-Secret со следующими параметрами:
+
+Name — Имя секретных данных (секретов). Оно понадобится для их получения.
+Vault — Имя хранилища данных. Если оно не указано, используется имя по умолчанию.
+Secret — Объект, содержащий секреты. Поддерживаются объекты следующих типов:
+byte[]
+String
+SecureString
+PSCredential
+Hashtable
+Секреты нужно передавать только в параметре Secret. Важно упомянуть, что, если в хранилище уже есть данные с указанным именем, они будут перезаписаны. Чтобы этого не случилось, при вызове Set-Secret нужно добавить переключатель NoClobber
+
+---
+https://habr.com/ru/articles/813279/  
+https://www.piter.com/blog/powershell-prakticheskaya-avtomatizatsiya