PowerShell
При первом запуске PowerShell внешний вид консоли определяется настройками свойств по умолчанию или параметрами, которые установлены «горячей клавишей» и проходят как аргументы к исполняемому файлу PowerShell. Например, когда вы запускаете PowerShell, дважды щелкая на файле powershell.exe, он открывается с установками свойств по умолчанию. То же касается и запуска PowerShell «горячей клавишей», которую вы создали для исполняемого файла или запуска PowerShell из командной строки Windows. Вы увидите маленькое окно командного процессора с черным фоном и серым шрифтом Независимо от того, как вы запускаете PowerShell, вы можете изменить внешний вид консоли через настройки свойств. Для доступа к ним щелкните на значке PowerShell в верхнем левом углу окна консоли, а затем на Properties, чтобы открыть диалоговое окно «Свойства».
В прошлом, когда скрипты 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 — отличный способ познакомиться с модулем 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