Überlegungen zur JEA-Sicherheit

JEA hilft Ihnen, Ihren Sicherheitsstatus zu verbessern, indem Sie die Anzahl der dauerhaften Administratoren auf Ihren Computern reduzieren. JEA verwendet eine PowerShell-Sitzungskonfiguration, um einen neuen Einstiegspunkt für Benutzer zum Verwalten des Systems zu erstellen. Benutzern, die erhöhten, aber nicht unbegrenzten Zugriff auf den Computer benötigen, um Verwaltungsaufgaben auszuführen, können Zugriff auf den JEA-Endpunkt gewährt werden. Da JEA diesen Benutzern das Ausführen von Administrativen Befehlen ermöglicht, ohne voll Administratorzugriff zu haben, können Sie diese Benutzer dann aus Sicherheitsgruppen mit hoher Berechtigung entfernen.

Run-As Konto

Jeder JEA-Endpunkt hat ein festgelegtes Ausführungskonto, unter dem die Aktionen des verbindenden Benutzers ausgeführt werden. Dieses Konto kann in der Sitzungskonfigurationsdatei konfiguriert werden, und das von Ihnen ausgewählte Konto hat erhebliche Auswirkungen auf die Sicherheit Ihres Endpunkts.

Virtuelle Konten sind die empfohlene Konfigurationsmethode für das Run-as-Konto. Virtuelle Konten sind einmalige, temporäre lokale Konten, die für den verbindenden Benutzer während der Dauer ihrer JEA-Sitzung erstellt werden. Sobald die Sitzung beendet wird, wird das virtuelle Konto zerstört und kann nicht mehr verwendet werden. Der verbindende Benutzer kennt die Anmeldeinformationen für das virtuelle Konto nicht. Das virtuelle Konto kann nicht für den Zugriff auf das System über andere Methoden wie Remotedesktop oder einen nicht eingeschränkten PowerShell-Endpunkt verwendet werden.

Standardmäßig sind virtuelle Konten Mitglieder der lokalen Administratorgruppe auf dem Computer. Diese Mitgliedschaft gewährt ihnen vollständige Rechte zum Verwalten von Elementen im System, aber keine Rechte zum Verwalten von Ressourcen im Netzwerk. Wenn der Benutzer über die JEA-Sitzung eine Verbindung mit anderen Computern herstellt, ist der Benutzerkontext das des lokalen Computerkontos, nicht das virtuelle Konto.

Domänencontroller sind ein Sonderfall, da keine lokale Administratorgruppe vorhanden ist. Stattdessen gehören virtuelle Konten zu Domänenadministratoren und können die Verzeichnisdienste auf dem Domänencontroller verwalten. Die Domänenidentität ist weiterhin für die Verwendung auf dem Domänencontroller eingeschränkt, in dem die JEA-Sitzung instanziiert wurde. Jeder Netzwerkzugriff scheint stattdessen vom Domänencontroller-Computerobjekt zu stammen.

In beiden Fällen können Sie das virtuelle Konto bestimmten Sicherheitsgruppen zuweisen, insbesondere, wenn die Aufgabe ohne lokale oder Domänenadministratorberechtigungen ausgeführt werden kann. Wenn Sie bereits eine Sicherheitsgruppe für Ihre Administratoren definiert haben, gewähren Sie der Gruppe die Mitgliedschaft für virtuelle Konten. Die Gruppenmitgliedschaft für virtuelle Konten ist auf lokale Sicherheitsgruppen auf Arbeitsstationen- und Mitgliedsservern beschränkt. Auf Domänencontrollern müssen virtuelle Konten Mitglieder von Domänensicherheitsgruppen sein. Nachdem das virtuelle Konto einer oder mehreren Sicherheitsgruppen hinzugefügt wurde, gehört es nicht mehr zu den Standardgruppen (lokale oder Domänenadministratoren).

In der folgenden Tabelle sind die möglichen Konfigurationsoptionen und resultierenden Berechtigungen für virtuelle Konten zusammengefasst:

Computertyp	Konfiguration virtueller Kontengruppen	Lokaler Benutzerkontext	Netzwerkbenutzerkontext
Domänencontroller	Standard	Domänenbenutzer, Mitglied von <DOMAIN>\Domain Admins	Computerkonto
Domänencontroller	Domänengruppen A und B	Domänenbenutzer, Mitglied von <DOMAIN>\A, <DOMAIN>\B	Computerkonto
Mitgliedsserver oder Arbeitsstation	Standard	Lokaler Benutzer, Mitglied von BUILTIN\Administrators	Computerkonto
Mitgliedsserver oder Arbeitsstation	Lokale Gruppen C und D	Lokaler Benutzer, Mitglied von <COMPUTER>\C und <COMPUTER>\D	Computerkonto

Wenn Sie sich sicherheitsüberwachungs- und Anwendungsereignisprotokolle ansehen, sehen Sie, dass jede JEA-Benutzersitzung über ein eindeutiges virtuelles Konto verfügt. Mit diesem eindeutigen Konto können Sie Benutzeraktionen in einem JEA-Endpunkt wieder auf den ursprünglichen Benutzer nachverfolgen, der den Befehl ausgeführt hat. Die Namen virtueller Konten folgen dem Format WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> , z. B. wenn Der Benutzer Alice in domäne Contoso einen Dienst in einem JEA-Endpunkt neu startet, lautet der Benutzername, der allen Dienststeuerungs-Manager-Ereignissen zugeordnet ist WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Gruppenverwaltete Dienstkonten (gMSAs) sind nützlich, wenn ein Mitgliedsserver Zugriff auf Netzwerkressourcen in der JEA-Sitzung haben muss. Wenn beispielsweise ein JEA-Endpunkt verwendet wird, um den Zugriff auf einen REST-API-Dienst zu steuern, der auf einem anderen Computer gehostet wird. Es ist einfach, Funktionen zum Aufrufen der REST-APIs zu schreiben, aber Sie benötigen eine Netzwerkidentität, um sich mit der API zu authentifizieren. Die Verwendung eines gruppenverwalteten Dienstkontos ermöglicht den zweiten Hop, während gleichzeitig die Kontrolle darüber beibehalten wird, welche Computer das Konto verwenden können. Die Sicherheitsgruppenmitgliedschaften (lokale oder Domänen) der gMSA definierten die effektiven Berechtigungen für das gMSA-Konto.

Wenn ein JEA-Endpunkt für die Verwendung eines gMSA konfiguriert ist, scheinen die Aktionen aller JEA-Benutzer aus demselben gMSA zu stammen. Die einzige Möglichkeit, Aktionen auf einen bestimmten Benutzer zurückzuverfolgen, besteht darin, die Gruppe von Befehlen zu identifizieren, die in einem PowerShell-Sitzungstranskript ausgeführt werden.

Pass-Through-Anmeldeinformationen werden verwendet, wenn Sie kein Run-as-Konto angeben. PowerShell verwendet die Anmeldeinformationen des verbindenden Benutzers, um Befehle auf dem Remoteserver auszuführen. Um Pass-Through-Anmeldeinformationen zu verwenden, müssen Sie dem verbindenden Benutzer direkten Zugriff auf privilegierte Verwaltungsgruppen gewähren. Diese Konfiguration wird für JEA NICHT empfohlen. Wenn der verbindende Benutzer bereits über Administratorrechte verfügt, kann er JEA umgehen und das System mithilfe anderer Zugriffsmethoden verwalten.

Standardausführungskonten ermöglichen es Ihnen, ein beliebiges Benutzerkonto anzugeben, unter dem die gesamte PowerShell-Sitzung ausgeführt wird. Sitzungskonfigurationen, die feste Run-as-Konten (mit dem -RunAsCredential Parameter) verwenden, sind nicht JEA-fähig. Rollendefinitionen funktionieren nicht mehr wie erwartet. Jedem Benutzer, der für den Zugriff auf den Endpunkt autorisiert ist, wird dieselbe Rolle zugewiesen.

Sie sollten keine RunAsCredential auf einem JEA-Endpunkt verwenden, da es schwierig ist, Aktionen auf bestimmte Benutzer zurückzuverfolgen und keine Unterstützung für die Zuordnung von Benutzern zu Rollen zu haben.

WinRM-Endpunkt-ACL

Wie bei normalen PowerShell-Remoting-Endpunkten verfügt jeder JEA-Endpunkt über eine separate Zugriffssteuerungsliste (Access Control List, ACL), die steuert, wer sich beim JEA-Endpunkt authentifizieren kann. Wenn sie nicht ordnungsgemäß konfiguriert sind, können vertrauenswürdige Benutzer möglicherweise nicht auf den JEA-Endpunkt zugreifen, und nicht vertrauenswürdige Benutzer haben möglicherweise Zugriff. Die WinRM-ACL wirkt sich nicht auf die Zuordnung von Benutzern zu JEA-Rollen aus. Die Zuordnung wird vom RoleDefinitions-Feld in der Sitzungskonfigurationsdatei gesteuert, die zum Registrieren des Endpunkts verwendet wird.

Wenn ein JEA-Endpunkt über mehrere Rollenfunktionen verfügt, ist die WinRM-ACL standardmäßig so konfiguriert, dass der Zugriff auf alle zugeordneten Benutzer ermöglicht wird. Beispielsweise gewährt eine MIT den folgenden Befehlen konfigurierte JEA-Sitzung vollzugriff auf CONTOSO\JEA_Lev1 und CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Sie können Benutzerberechtigungen mit dem Cmdlet Get-PSSessionConfiguration überwachen.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Um zu ändern, welche Benutzer Zugriff haben, führen Sie entweder Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI eine interaktive Eingabeaufforderung aus, oder Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> aktualisieren Sie die Berechtigungen. Benutzer benötigen mindestens Aufrufrechte für den Zugriff auf den JEA-Endpunkt.

Es ist möglich, einen JEA-Endpunkt zu erstellen, der keine definierte Rolle jedem Benutzer zugeordnet, der Zugriff hat. Diese Benutzer können eine JEA-Sitzung starten, haben jedoch nur Zugriff auf die Standard-Cmdlets. Sie können Benutzerberechtigungen in einem JEA-Endpunkt prüfen, indem Sie Get-PSSessionCapability ausführen. Weitere Informationen finden Sie unter Audit and Reporting on JEA.

Rollen mit minimalen Berechtigungen

Beim Entwerfen von JEA-Rollen ist es wichtig zu beachten, dass die virtuellen und gruppenverwalteten Dienstkonten, die hinter den Kulissen ausgeführt werden, uneingeschränkten Zugriff auf den lokalen Computer haben können. JEA-Rollenfunktionen helfen beim Einschränken der Befehle und Anwendungen, die in diesem privilegierten Kontext ausgeführt werden können. Nicht ordnungsgemäß gestaltete Rollen können gefährliche Befehle zulassen, mit denen ein Benutzer aus den JEA-Grenzen herausbrechen oder Zugriff auf vertrauliche Informationen erhalten kann.

Betrachten Sie beispielsweise den folgenden Rollenfunktionseintrag:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Mit dieser Rollenfunktion können Benutzer jedes PowerShell-Cmdlet mit dem Nomen Process aus dem Modul "Microsoft.PowerShell.Management" ausführen. Benutzer müssen möglicherweise auf Cmdlets wie Get-Process zugreifen, um zu sehen, welche Anwendungen auf dem System ausgeführt werden, und Stop-Process die Anwendungen zu beenden, die nicht reagieren. Dieser Eintrag ermöglicht Start-Processjedoch auch das Starten eines beliebigen Programms mit vollständigen Administratorberechtigungen. Das Programm muss nicht lokal auf dem System installiert werden. Ein verbundener Benutzer könnte ein Programm über eine Dateifreigabe starten, die dem Benutzer lokale Administratorrechte gewährt, Schadsoftware ausführt und vieles mehr.

Eine sicherere Version dieser Rollenfunktion würde wie folgt aussehen:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Vermeiden Sie die Verwendung von Wildcards in Rollenfunktionen. Achten Sie darauf, dass Sie regelmäßig effektive Benutzerberechtigungen überwachen, um festzustellen, auf welche Befehle für einen Benutzer zugegriffen werden kann. Weitere Informationen finden Sie im Abschnitt " Überprüfen effektiver Rechte " des Artikels "Audit and Reporting on JEA ".

Empfehlungen für bewährte Methoden

Es folgen empfehlungen für bewährte Methoden, um die Sicherheit Ihrer JEA-Endpunkte zu gewährleisten:

Beschränken der Verwendung und Funktionen von PowerShell-Anbietern

Überprüfen Sie, wie die zulässigen Anbieter verwendet werden, um sicherzustellen, dass Sie in Ihrer konfigurierten Sitzung keine Sicherheitsrisiken erstellen.

Warnung

Lassen Sie den FileSystem-Anbieter nicht zu. Wenn Benutzer in einen beliebigen Teil des Dateisystems schreiben können, ist es möglich, die Sicherheit vollständig zu umgehen.

Lassen Sie den Zertifikatanbieter nicht zu. Wenn der Anbieter aktiviert ist, kann ein Benutzer Zugriff auf gespeicherte private Schlüssel erhalten.

Lassen Sie keine Befehle zu, die neue Runspaces erstellen können.

Warnung

Die *-Job Cmdlets können neue Runspaces ohne Einschränkungen erstellen.

Lassen Sie das Trace-Command Cmdlet nicht zu.

Warnung

Durch die Verwendung Trace-Command werden alle nachverfolgten Befehle in die Sitzung eingefügt.

Erstellen Sie keine eigenen Proxyimplementierungen für die eingeschränkten Befehle.

PowerShell verfügt über eine Reihe von Proxybefehlen für eingeschränkte Befehlsszenarien. Diese Proxybefehle stellen sicher, dass Eingabeparameter die Sicherheit der Sitzung nicht gefährden können. Die folgenden Befehle verfügen über eingeschränkte Proxys:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Wenn Sie eine eigene Implementierung dieser Befehle erstellen, können Sie Benutzern versehentlich das Ausführen von Code gestatten, der durch die JEA-Proxybefehle verboten ist.

JEA schützt nicht vor Administratoren

Einer der Kernprinzipien von JEA besteht darin, dass es nichtadministratoren ermöglicht, einige administrative Aufgaben auszuführen. JEA schützt nicht vor Benutzern, die bereits über Administratorrechte verfügen. Benutzer, die Domänenadministratoren, lokale Administratoren oder andere streng privilegierte Gruppen angehören, können die Schutzmechanismen von JEA auf andere Weise umgehen. Sie können sich beispielsweise mit RDP anmelden, remote MMC-Konsolen verwenden oder eine Verbindung mit nicht eingeschränkten PowerShell-Endpunkten herstellen. Außerdem kann der lokale Administrator auf einem System JEA-Konfigurationen ändern, um weitere Benutzer hinzuzufügen oder eine Rollenfunktion zu ändern, um den Umfang der Aktionen zu erweitern, die ein Benutzer in seiner JEA-Sitzung ausführen kann. Es ist wichtig, die erweiterten Berechtigungen Ihrer JEA-Benutzer auszuwerten, um festzustellen, ob es andere Möglichkeiten gibt, privilegierten Zugriff auf das System zu erhalten.

Neben der Verwendung von JEA für regelmäßige tägliche Wartungen ist es üblich, ein Just-in-Time-Management-System für privilegierten Zugriff zu haben. Diese Systeme ermöglichen es bestimmten Benutzern, vorübergehend zu einem lokalen Administrator zu werden, nachdem sie einen Workflow abgeschlossen haben, der die Verwendung dieser Berechtigungen dokumentiert.