Sichere Verwendung von Anmeldedaten in PowerShell

Inhaltsverzeichnis

Post Featured Image

Die Authentifizierung über Anmeldedaten ist die verbreitetste Form der Zugriffsidentifizierung in PowerShell.

 

Dies erfolgt mit dem Credential-Parameter, an den die Kombination aus Benutzername und Kennwort in Form eines PSCredential-Objekts übergeben wird. Da es sich um sensible Daten von privilegierten Konten handelt, hat die Sicherheit dieser Konten höchste Priorität. Die gängigsten Methoden zum Umgang mit Anmdeldedaten weisen jedoch erhebliche Sicherheitslücken auf, wie im Folgenden gezeigt wird.

 
 

  

PSCredential-Objekte mit dem New-Object Cmdlet

Der einfachste Weg, ein PSCredential-Objekt zu erstellen, ist ein Code wie dieser:

$user = "Max_Mustermann" $pwd = "Passwort123" $secure_pwd = $password | ConvertTo-SecureString -AsPlainText -Force $creds = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $secure_pwd

Benutzername und Kennwort werden als Klartext in das PowerShell-Script eingegeben. Das Passwort wird in eine SecureString konvertiert, da es nur in dieser Form übergeben werden kann. Anschließend wird das PSCredential-Objekt erstellt. Dieser Ansatz ist vom Sicherheitsstandpunkt aus gesehen äußerst kritisch. Da Benutzername und das Passwort als Klartext in das Script eingegeben werden, sind sie für jedermann sichtbar.

Der folgende Code bietet mehr Sicherheit:

$user = "Max_Mustermann" $secure_pwd = Read-Host -AsSecureString $cred = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $secure_pwd

Nur der Benutzername wird als Klartext in das PowerShell-Script eingegeben, das Kennwort wird direkt als SecureString erstellt. Allerdings gibt es auch bei dieser Methode Sicherheitslücken, da Sie im Script einen Verweis auf den Benutzernamen machen können. Zudem ist weder eine Automatisierung noch eine Delegation von Scripten möglich, da das Passwort bei jeder neuen Scriptausführung interaktiv eingegeben werden muss.

Das Passwort kann auch in einer externen Datei gespeichert werden:

Read-Host -AsSecureString |  ConvertFrom-SecureString | Out-File "C:passwort.txt" $user = "Max_Mustermann" $pwd = "C:Password.txt" $cred = New-Object -TypeName System.Management.Automation.PSCredential $User, (Get-Content $pwd | ConvertTo-SecureString)

Bei dieser Methode wird das Kennwort verschlüsselt und in einer externen Textdatei gespeichert. Diese wird in das Script zurückgelesen und in eine SecureString konvertiert. Dadurch können Scripte automatisiert werden, da Benutzernamen und Passwörter nicht mehr interaktiv eingegeben werden müssen.

Allerdings ist auch dieses Verfahren nicht ganz sicher, da SecureStrings auch zurückkonvertiert werden können, um das Passwort zu erhalten. Ein weiterer Nachteil ist, dass die Textdatei während der Ausführung zugänglich sein muss, was die Delegation von Scripten unmöglich macht. Auch hier wird der Benutzername als Klartext in das Script eingetragen.

 

Erstellen von PSCredential-Objekten mit dem Get-Credential Cmdlet

Eine sehr beliebte Methode zum Erstellen eines PSCredential-Objekts ist die Verwendung des Get-Credential Cmdlet:

$cred = Get-Credential -Message "Bitte geben Sie Nutzername und Passwort ein"

Dadurch kann der Benutzer ein Eingabefeld verwenden, um den Benutzernamen und das Passwort einzugeben (Abbildung 1). Das eingegebene Kennwort wird als SecureString gespeichert.

Figure 1: Fig. 1: Dialog box for entering username and password, based on a PSCredential object

Abb. 1: Dialogfenster zur Eingabe von Benutzername und Kennwort, basierend auf einem PSCredential-Objekt

Obwohl diese Methode keine Sicherheitslücken aufweist, muss sie jedes Mal, wenn das Script ausgeführt wird, interaktiv in der PowerShell-Konsole eingegeben werden. Dies verhindert sowohl die Automatisierung als auch die Delegation von Scripten, da immer noch User Eingaben erforderlich sind.

 

Verwendung von PSCredential-Objekten mit ScriptRunner

ScriptRunner ermöglicht es Ihnen, die Zugangsdaten sicher zu speichern und Ihre Scripte vollständig zu automatisieren. Unter dem Menüpunkt „Benutzerkonten“ werden alle privilegierten Konten mit Passwort gespeichert, die ScriptRunner verwenden soll, um Scripte auf anderen Systemen auszuführen (Abbildung 2). Passwörter und Benutzernamen werden im Windows Credential Manager auf dem lokalen System des ScriptRunner-Hosts gespeichert. Der Benutzername wird als zusätzliche Sicherheitsvorkehrung durch eine zufällig generierte Zahl ersetzt. Da die Informationen auf dem lokalen System gespeichert sind, kann ein normaler Windows-Benutzer nicht darauf zugreifen.

Figure 2: Figure 2: Screenshot of the ScriptRunner Admin App, menu item

Abb. 2: Alle privilegierten Konten und Passwörter, die ScriptRunner verwenden soll, um Scripte auf anderen Systemen auszuführen, werden lokal auf dem ScriptRunner Host gespeichert

Im PowerShell-Script werden die erforderlichen Anmeldedaten einfach als Variablen eingefügt, ohne Bezug auf den im Script verwendeten Benutzernamen oder das Kennwort.

Param ( [PSCredential] $PSCred1, [PSCredential] $PSCred1 )

Aktionen werden immer vom ScriptRunner-Host mit den dort gespeicherten Anmeldedaten gestartet. Die erforderlichen Anmeldedaten werden in der Aktion/Richtlinie konfiguriert und erst zur Laufzeit in den PowerShell-Prozess eingegeben.

Da es keine interaktive Eingabe von Benutzername und Passwort zur Laufzeit gibt, brauchen Service-Desk-Benutzer von delegierten Scripten den Namen oder das Passwort eines administrativen Kontos nicht zu kennen, um eine Aktion auszuführen.

 

ScriptRunner – Die Lösung für die sichere Verwendung von Anmeldedaten

Die Vorteile von ScriptRunner auf einen Blick:

  • Anmeldedaten oder privilegierte Konten werden sicher gespeichert
  • Kein Verweis auf die im Script verwendeten Benutzernamen, Passwörter oder Berechtigungsnachweise
  • Kein Hinweis auf die Verwendung von Berechtigungsnachweisen
  • Keine interaktive Eingabe während der Ausführung erforderlich
 

Zusammenhängende Posts

16 min read

ScriptRunner Portal Edition R4

4 min read

So nutzen Sie Azure Templates zur Automatisierung

Über den Autor: