14 min read
Der Schlüssel zu produktiver Softwareverwaltung: winget & PowerShell
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
ScriptRunner Blog
Lüfte die Geheimnisse der sicheren Passwortverwaltung in PowerShell! Entdecke, wie die Secrets Management Module von Microsoft deine Sicherheitspraktiken verändern, Schwachstellen im Klartext beseitigen und deine Automatisierungsskripte optimieren können. Sichere deine IT-Umgebung, wie es sich für einen Profi gehört!
Wenn du andere IT-Fachleute fragst, was bei ihrer Arbeit wichtig ist, steht das Thema Sicherheit meist ganz oben auf der Liste, oder? Sicherheit kann viele Formen annehmen, von der Verwaltung von Zugangsdaten über die Konfiguration von Software bis hin zu Schutzdiensten. In diesem Artikel konzentrieren wir uns auf die sichere Verwendung von Passwörtern mit der PowerShell, sei es als einmaliges Skript oder als automatisiertes Skript, unter besonderer Berücksichtigung der Secrets Management Module von Microsoft.
Es gibt zahlreiche böswillige Akteure, die Plattformen angreifen, die von IT-Fachleuten und Unternehmen für eine Vielzahl von Aufgaben verwendet werden. Die Angriffsmöglichkeiten reichen von Schwachstellen in Software und Hardware bis hin zu selbst geschaffenen Sicherheitslücken wie Klartext-Passwörtern in Skripten. Die Reduzierung dieser Angriffsfläche sollte auf der Aufgabenliste eines jeden Administrators stehen. Mit Secrets Management können die Mechanismen der Passwortverwaltung verbessert werden. Lass uns herausfinden, wie das geht.
"Jein!" sagt der IT- Consultant. Bei der Verwendung eines Tresors geht es nicht nur darum, sicherer zu sein, sondern auch darum, einen zentralen Ort für Passwörter zu haben. Darauf gehe ich nachfolgend genauer ein.
Visuelle Darstellung des Vorteils eines Tresors gegenüber einer einzelnen Passwortdatei
Um auf einen Tresor zugreifen zu können, müssen wir dem Tresor irgendeine Art von Anmeldedaten übergeben. Wir könnten ein Klartext-Passwort verwenden (was wir nicht tun sollten), wir könnten eine Passwort-Datei verwenden (was wir in Skripten auch ohne Tresor tun können), oder es gibt vielleicht einen REST-API-Aufruf oder eine XML-Datei, auf die wir zugreifen müssen. Alle diese Methoden haben ihre Stärken und Schwächen:
Ohne einen Tresor verwendet ein 'sicheres' Skript eine Passwortdatei, die von der PowerShell gehasht wird und nur lokal zugänglich ist. Mit dem Geheimnistresor haben wir nun eine One-to-Many-Lösung, die den Zugriff auf eine Vielzahl von Geheimnissen oder Anmeldeinformationen ermöglicht.
Wie bei allem, was mit PowerShell zu tun hat, müssen wir zuerst die beiden benötigten PowerShell-Module installieren und sie dann in eine PowerShell-Sitzung importieren.
Install-Module Microsoft.PowerShell.SecretManagement
Install-Module Microsoft.PowerShell.SecretStore
Import-Module Microsoft.PowerShell.SecretManagement
Import-Module Microsoft.PowerShell.SecretStore
Nachdem wir nun die Module installiert und importiert haben, können wir die Cmdlets testen:
SecretManagement Modul |
SecretStore Modul |
Get-Secret | Get-SecretStoreConfiguration |
Get-SecretInfo | Reset-SecretStore |
Get-SecretVault | Set-SecretStoreConfiguration |
Register-SecretVault | Set-SecretStorePassword |
Remove-Secret | Unlock-SecretStore |
Set-Secret | |
Set-SecretInfo | |
Set-SecretVaultDefault | |
Test-SecretVault | |
Unlock-SecretVault | |
Unregister-SecretVault |
Microsoft.PowerShell.SecretManagement und Microsoft.PowerShell.SecretStore – beide Module verfügen über eine begrenzte Anzahl von Cmdlets
Nach dem Laden der beiden Module, wie es oben beschrieben wurde, müssen wir einen Tresor registrieren, der verwendet werden soll. Im folgenden Beispiel erstellen wir einen Tresor für einen lokalen Rechner, auf den nur der lokale Nutzer Zugriff hat.
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
Nach der Registrierung müssen wir einige Konfigurationseinstellungen für den Tresor vornehmen, als erstes das Passwort:
$Password = Import-CliXml -Path $securePasswordPath
Dann legen wir die Authentifizierungsparameter für den Zugriff auf den Tresor fest:
$StoreConfiguration = @{
Authentication = 'Password'
PasswordTimeout = 3600 # 1 hour
Interaction = 'None'
Password = $password
Confirm = $false
}
Diese Einstellungen werden auf den Tresor angewandt und wir haben jetzt einen Ort, an dem wir Anmeldedaten speichern können.
Set-SecretStoreConfiguration @storeConfiguration
Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore
Set-Secret -Name M365GA01 -Secret "!@dF45#281*sdf" -Vault SecretStore
Remove-Secret -Name TestSecret -Vault SecretStore
Set-Secret -Name M365GA01- Vault SecretStore
Verwende, wenn möglich, Timeouts für Tresore, auch für Automatisierungen. Wenn deine Automatisierung zu lange dauert (Zeitüberschreitung), versuche, die Automatisierung effizienter zu gestalten. Wenn das nicht funktioniert, verlängere die Timeout-Zeit ein wenig, um auch Zeiten außerhalb der Runtime abzudecken. Obwohl es möglich wäre, ein offenes Zeit-Limit mit einer Automatisierung zu verwenden, sollte das nicht genutzt werden, da ein unbegrenzt offener Tresor anfälliger ist für Angriffe.
Get-SecretStoreConfiguration
Wie wir sehen, beträgt das voreingestellte Zeitlimit 900 Sekunden oder 15 Minuten
Set-SecretStoreConfiguration -PasswordTimeout 1800
Wie oben gezeigt, muss die Änderung der Timeout-Zeit bestätigt werden
Set-SecretStoreConfiguration -PasswordTimeout 450
Wenn wir die Zeitüberschreitung verkürzen, erhalten wir eine ähnliche Meldung und werden möglicherweise auch nach dem Passwort für den Tresor gefragt.
Es gibt eine Reihe von Praxisanwendungen, wie z.B. Wartungsaufgaben im Rechenzentrum, Skripte für Cloud-Ressourcen und allgemeine Workload-Automatisierung. Alle diese Anwendungen können den Tresor nutzen, da sie darauf angewiesen sind, dass PowerShell sich bei Ressourcen authentifiziert und dann verschiedene Aufgaben mit dem gewährten Zugriff ausführt. Um zu zeigen, wie Geheimnisse in Skripte integriert werden können, gehen wir einige kurze Beispiele durch.
Im Idealfall verfügen Administratoren bei der Wartung vor Ort über ein normales Nutzerkonto und ein Nutzerkonto mit höheren Rechten. Neben diesen Konten gibt es möglicherweise auch allgemeine Dienstkonten oder Group Managed Service Accounts (gMSAs). In diesem Beispiel verwenden wir ein Dienstkonto und eine mittels PowerShell erstellte Anmeldedatei, auf die nur eine administrativ erstellte AD-Gruppe Zugriff hat.
$Credential = Get-Credential -UserName 'SecureStore'
$PasswordPath = 'C:\data\password.xml'
$Credential.Password | Export-Clixml -Path $PasswordPath
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
$Password = Import-CliXml -Path $PasswordPath
Unlock-SecretVault -Name SecretStore -Password $Password
Unlock-SecretVault -Name SecretStore -Password $Password
Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore
$automationPassword = Get-Secret -Vault SecretStore -Name TestSecret
Verwende das Geheimnis im Tresor, um die anstehenden Aufgaben auszuführen. Verwende niemals PlainText, sondern stelle sicher, dass das Passwort als SecureString ausgegeben wird.
Hinweis: Sobald der Tresor einen Timeout hat, wird er gesperrt und wir können die Zugangsdaten erst wieder abfragen, wenn er wieder entsperrt wird.
Wir können nicht nur mit lokalen Windows-Speichern arbeiten, sondern mit zusätzlichen Sub-Modulen auch mit anderen Geheimnisspeichern. Was ist, wenn du bereits einen Passwort-Tresor hast? Dann hast du Glück, denn das Microsoft Secrets-Modul lässt sich mit einigen der bekannteren Anbieter integrieren. Viele Unternehmen vertrauen ihre Kennwortverwaltung Anbietern wie Cyberark an.
** Diese Sub-Module werden in der Regel auch von Nicht-Microsoft-Autoren erstellt. Es kann sein, dass sie nicht unterstützt werden, und der Support für die Nutzung des Moduls kann variieren.
Find-Module SecretManagement.* | Sort Name
# Alternativ kannst du auch mit dem Tag Extension Vaults suchen
Find-Module -Tag SecretManagement. | Sort Name
Liste der Sub-Module für die Verwaltung von Geheimnissen, die in der PSGallery verfügbar sind
Installiere und importiere das Sub-Modul:
Install-Module SecretManagement.Chromium
Import-Module SecretManagement.Chromium
Registriere den Tresor, damit das Secret Management-Modul mit dem Tresor arbeiten kann:
Register-ChromiumSecretVault -Preset Chrome
Abfrage aller gespeicherten Geheimnisse, die Chrome auf deiner lokalen Arbeitsstation angelegt hat:
Get-SecretInfo -Value Chrome
Wie oben gezeigt, hat dieser Arbeitsplatzrechner vier gespeicherte Berechtigungsnachweise (Credential Sets) in Chrome
Beachte, dass es gespeicherte Anmeldeinformationen für Microsoft-Dienste, Archive.Org und Dominos gibt, obwohl Dominos unvollständig zu sein scheint. Auch wenn dies unsicher erscheint, solltest du bedenken, dass alle geheimen Speicherplätze unter deinem Profil liegen und mit deinen Anmeldedaten freigeschaltet werden.
Hinweis: Mit diesem PowerShell-Modul können wir keine Geheimnisse entfernen.
PowerShell verwenden, um ein Geheimnis aus dem Chrome-Tresor zu entfernen
Aber wenn wir die Passwörter nicht entfernen können, was nützt es dann, wenn wir nur die Anmeldedaten abrufen? Genau wie bei anderen Tresoren können wir die Anmeldeinformationen abfragen, sie in der PowerShell speichern und mit anderen Operationen/PowerShell-Cmdlets verwenden.
Beachte, dass dieses Modul nur zwei Cmdlets hat:
Get-ChromiumError
Register-ChromiumSecretVault
Das Cmdlet Get-ChromiumError dient nur zur Anzeige von Fehlern, die bei der Verwendung des Moduls aufgetreten sind. Sieh dir unbedingt die Readme.md an, die du auf der GitHub-Seite des Moduls findest.
CyberArk ist eine beliebte Sicherheitslösung für Unternehmen, die ihre Umgebung mit den angebotenen Funktionen absichern möchten. Eine dieser Funktionen ist der Passwort-Safe. Mit dem Modul Secrets Management können wir nun auf einen CyberArk-Safe zugreifen und die dort gespeicherten Anmeldeinformationen für verschiedene PowerShell-Operationen verwenden. Wirf auch einen Blick auf die GitHub-Seite zu diesem Modul.
Vergiss nicht, alle Voraussetzungen für die einzelnen Untermodule zu prüfen
Wir können die zusätzlichen Module installieren:
Install-Module psPAS
Install-Module CredentialRetriever
Install-Module SecretManagement.CyberArk
Import-Module SecretManagement.CyberArk
Verfügbare Befehle im Modul:
Get-Command | Where Source -eq SecretManagement.CyberArk
Dadurch werden diese Cmdlets angezeigt:
Get-Secret
Get-SecretInfo
Remove-Secret
Set-Secret
Test-SecretVault
Hinweis: Je nach deinem Setup musst du eventuell -AllowClobber für das Modul ausführen.
Wenn du die Dokumentation zu CyberArk GitHub liest, wirst du feststellen, dass es drei verschiedene Verbindungskonfigurationen für deinen CyberArk-Tresor gibt: Credential Provider, Central Credential Provider und REST. Verwende diejenige, die deiner individuellen CyberArk-Konfiguration entspricht. Nach der Konfiguration können wir das entsprechende Secret Management Cmdlet verwenden, um unsere im Tresor gespeicherten Geheimnisse zu verwalten.
Die Sicherung unserer Geheimnisse sollte etwas sein, das uns im Technologiebereich immer beschäftigt. Nach dem Salesforce-Hack und dem Vorfall mit den Klartext-Zugangsdaten sollten wir uns dessen noch mehr bewusst sein. Microsofts Secrets-Modul für die PowerShell bietet eine sicherere Möglichkeit, Skripte auszuführen, sei es als einmalige Aktionen oder als Automatisierungen. Jedes Skript, das Anmeldedaten verwendet, sollte wie ein Geheimnis behandelt werden, auf das niemand sonst Zugriff haben sollte, und wenn du deine Geheimnisse nicht verwaltest, solltest du es tun. Als Erstes kannst du ein Testing Lab einrichten und zumindest die in Microsoft integrierten Secret Stores verwenden. Wenn du das getestet hast, wähle einen Credential Provider, den du vielleicht schon für andere Anwendungscredentials verwendest (z.B. CyberArk), und verwende ihn für deinen PowerShell Secrets Manager. Wenn dieser Test oder Proof of Concept abgeschlossen und geprüft ist, kannst du ihn in die Produktivumgebung übertragen und deine PowerShell-Skripte sichern.
Die sichere Verwendung von PowerShell ist der Schlüssel zur erfolgreichen Automatisierung von IT-Administrationsaufgaben. Unser 150-seitiges PowerShell Security E-Book deckt alle integrierten Funktionen ab, die deine PowerShell-Umgebung sicher und zuverlässig machen.
Wir führen immer wieder Webinare zum Thema Security durch, hier findest du unser letztes Webinar dazu!
Dez 19, 2024 by Jeffery Hicks
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
Dez 19, 2024 by Damian Scoles
Mit Microsoft Purview verstehst und verwaltest du Daten in deinem gesamten Datenbestand – wie kannst du PowerShell...
Dez 17, 2024 by Sonny Jamwal
Erweitere PowerShell mit .NET für eine leistungsstarke Ereignisautomatisierung. Systemereignisse wie ein Profi...
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".