Just Enough Administration (JEA) Schritt für Schritt

Der Leitfaden zur PowerShell-Sicherheit hat ein fünfzeiliges JEA-Beispiel gezeigt. Das reicht, um die Idee zu verstehen, aber nicht für den Produktivbetrieb. Dieser Leitfaden geht weiter: wie man Rollen entwirft, aus denen man nicht ausbrechen kann, wie man die Ausführungsidentität wählt, wie man Endpunkte auf viele Server verteilt und wie man nachweist, dass sie tun, was man denkt.

Just Enough Administration ist ein PowerShell-Remoting-Endpunkt mit drei Eigenschaften. Der verbindende Benutzer kann nur eine zugelassene Menge an Befehlen ausführen, die Befehle laufen unter einer temporären privilegierten Identität statt unter dem Konto des Benutzers, und alles wird transkribiert. Gut umgesetzt kann ein Helpdesk damit einen Dienst neu starten oder eine Druckwarteschlange leeren, ohne dass jemand lokale Adminrechte auf dem Server besitzt. Die Kurzdefinition finden Sie im Glossareintrag zu JEA.

Wie die Teile zusammenspielen

Rollenfunktionen werden beim Sitzungsstart geladen, eine Änderung an einer .psrc wirkt sich also sofort auf neue Sitzungen aus. Änderungen an einer .pssc gelten erst, nachdem Sie sie erneut registriert haben.

Was kaputtgeht

JEA-Sitzungen sind absichtlich unbequem. Planen Sie ein:

• Keine Variablen oder Skriptblöcke. RestrictedRemoteServer-Sitzungen laufen standardmäßig im Modus NoLanguage. Benutzer führen Befehle aus; sie können weder $x = Get-Service noch ForEach-Object { } schreiben. Legen Sie Logik in Funktionen innerhalb Ihres Moduls.
• Kein Double Hop. Ein virtuelles Konto ist lokal auf dem Server. Alles, was aus der Sitzung heraus eine Dateifreigabe, SQL oder AD erreichen muss, braucht stattdessen ein gMSA.
• Standardmäßig kein Kopieren von Dateien. Copy-Item -ToSession funktioniert nur mit einem Benutzerlaufwerk (MountUserDrive) und nur in dieses Laufwerk.
• GUI-Werkzeuge nutzen es nicht. Server-Manager, MMC-Snap-Ins und RDP ignorieren JEA-Endpunkte. Operatoren brauchen Skripte oder implizites Remoting.

Schritt 1: die Aufgaben inventarisieren

Beginnen Sie bei den Tickets, nicht bei den Cmdlets. Notieren Sie für jede wiederkehrende Aufgabe den genauen Befehl und die benötigten Parameterwerte:

• Die Druckwarteschlange auf Druckservern neu starten.
• Hängende Aufträge aus einer benannten Warteschlange löschen.
• Die letzten 50 Systemereignisse lesen.

Braucht eine Aufgabe beliebige Eingaben (beliebiger Dienst, beliebiger Pfad), ist das ein Warnsignal. Jeder frei wählbare Parameter ist ein möglicher Ausbruchsweg.

Schritt 2: das Rollenfunktionsmodul bauen

Legen Sie ein kleines Modul für die Rolle an. Das Modul braucht ein Manifest, auch wenn die .psm1 leer ist:

$mod = "C:\Program Files\WindowsPowerShell\Modules\CorpJEA"
New-Item -ItemType Directory -Path "$mod\RoleCapabilities" -Force | Out-Null
New-Item -ItemType File -Path "$mod\CorpJEA.psm1" -Force | Out-Null
New-ModuleManifest -Path "$mod\CorpJEA.psd1" -RootModule 'CorpJEA.psm1'

Jetzt die Rolle. Schränken Sie Parameter mit ValidateSet oder ValidatePattern ein, wo immer es geht:

New-PSRoleCapabilityFile -Path "$mod\RoleCapabilities\PrintOperator.psrc" `
  -VisibleCmdlets @(
    @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-Service';     Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-PrintJob';    Parameters = @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' } },
    @{ Name = 'Remove-PrintJob'; Parameters = @(
         @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' },
         @{ Name = 'ID' }) }
  ) `
  -VisibleFunctions 'Get-CorpSystemEvents'

Get-CorpSystemEvents ist eine Funktion, die Sie in CorpJEA.psm1 schreiben, zum Beispiel ein Wrapper um Get-WinEvent -LogName System -MaxEvents 50. Funktionen in Ihrem Modul sind der richtige Ort für alles, was Variablen oder Schleifen braucht: Benutzer können sie aufrufen, ihren Inhalt aber weder sehen noch ändern.

Lassen Sie Folgendes aus jeder Rolle heraus, sofern Sie nicht genau wissen, warum es dort steht, denn jedes davon macht den Endpunkt wieder zum vollen Admin-Zugang:

• Invoke-Expression, Invoke-Command, Start-Process, New-Service, Register-ScheduledTask, Add-Type.
• Alles, was Gruppenmitgliedschaften ändert (Add-LocalGroupMember, Add-ADGroupMember).
• Datei- und Registrierungsprovider über VisibleProviders sowie Set-Content, Copy-Item oder New-Item ohne Pfadeinschränkungen.
• VisibleExternalCommands, die auf cmd.exe, powershell.exe oder einen anderen Interpreter zeigen.

Ein Cmdlet mit einem uneingeschränkten Parameter -ScriptBlock, -FilePath oder -ComputerName verdient dasselbe Misstrauen.

Schritt 3: die Sitzungskonfiguration schreiben

New-PSSessionConfigurationFile -Path .\PrintOps.pssc `
  -SessionType RestrictedRemoteServer `
  -RunAsVirtualAccount `
  -RunAsVirtualAccountGroups 'JEA-PrintSvc' `
  -TranscriptDirectory 'C:\ProgramData\JEA\Transcripts' `
  -RoleDefinitions @{ 'CORP\JEA-PrintOps' = @{ RoleCapabilities = 'PrintOperator' } } `
  -RequiredGroups @{ And = 'CORP\JEA-PrintOps', 'CORP\SmartCardUsers' }

Test-PSSessionConfigurationFile -Path .\PrintOps.pssc

JEA-PrintSvc ist eine lokale Gruppe auf dem Server, der Sie nur die Rechte gewähren, die die Rolle braucht, zum Beispiel Start- und Stopprechte für den Spooler-Dienst (über dessen Sicherheitsbeschreibung) und Manage documents für die Druckwarteschlangen. Diese Gruppe aufzubauen ist aufwendiger, als lokale Adminrechte hinzunehmen, und genau dieser Aufwand macht den Endpunkt sicher.

Die Ausführungsidentität ist hier die wichtigste Entscheidung:

Der Standard Domain Admins auf Domänencontrollern überrascht viele. Ein JEA-Endpunkt auf einem DC mit unbegrenztem virtuellem Konto und einem einzigen Befehl mit Ausbruchsmöglichkeit ist eine Domain-Admin-Shell für jeden, der sich verbinden kann. Begrenzen Sie es immer oder verwenden Sie ein gMSA mit gezielt delegierten Rechten.

RequiredGroups fügt eine Bedingung hinzu, die unabhängig von der Rolle erfüllt sein muss, zum Beispiel dass sich der Benutzer zusätzlich mit einer Smartcard angemeldet hat (über eine Gruppe für Authentication Mechanism Assurance). Sie wird beim Verbindungsaufbau ausgewertet.

Schritt 4: den Endpunkt registrieren

Register-PSSessionConfiguration -Name PrintOps -Path .\PrintOps.pssc -Force

Die Registrierung startet den WinRM-Dienst neu, wodurch bestehende Remotesitzungen abbrechen. Machen Sie das auf ausgelasteten Servern in einem Wartungsfenster.

Prüfen Sie dann die Standardendpunkte. Get-PSSessionConfiguration listet jeden Endpunkt und wer ihn nutzen darf:

Get-PSSessionConfiguration | Select-Object Name, Permission

Die integrierten Endpunkte microsoft.powershell erlauben Administrators und Remote Management Users. JEA-Benutzer dürfen in keiner dieser Gruppen sein, sonst können sie Ihren Endpunkt komplett umgehen. Bereinigen Sie die Gruppenmitgliedschaften im Rahmen des Entzugs lokaler Adminrechte.

Schritt 5: im großen Maßstab bereitstellen

Endpunkte von Hand zu registrieren skaliert nicht über ein paar Server hinaus. Zwei gängige Muster:

• Softwareverteilung plus Skript. Paketieren Sie den Modulordner und die .pssc, kopieren Sie das Modul nach C:\Program Files\WindowsPowerShell\Modules und führen Sie dann Register-PSSessionConfiguration aus. Nutzen Sie die Modulversion im Manifest als Erkennungsregel.
• Desired State Configuration. Das Community-Ressourcenmodul JeaDsc deklariert Endpunkte und Rollenfunktionen als Konfiguration und korrigiert so auch Abweichungen. Prüfen Sie den aktuellen Pflegestatus des Moduls, bevor Sie sich darauf verlassen.

Halten Sie die .psrc- und .pssc-Dateien mit Code-Review in der Versionsverwaltung. Sie sind privilegierte Konfiguration, genau wie eine GPO, die Adminrechte vergibt.

Überprüfen

Fragen Sie zuerst den Server, was ein bestimmter Benutzer erhalten würde, ohne sich zu verbinden:

Get-PSSessionCapability -ConfigurationName PrintOps -Username 'CORP\alice'

Die Ausgabe listet genau die Befehle, die diesem Benutzer zur Verfügung stehen. Alles Unerwartete darin ist ein Designfehler.

Verbinden Sie sich dann als Testoperator:

Enter-PSSession -ComputerName prn01.corp.example -ConfigurationName PrintOps
Get-Command                      # nur die zugelassenen Befehle plus die Standardbefehle
Restart-Service -Name Spooler    # funktioniert
Restart-Service -Name WinRM      # scheitert an der Parametervalidierung
$env:USERNAME                    # scheitert: kein Sprachmodus

Prüfen Sie das Transkript in C:\ProgramData\JEA\Transcripts. Der Kopf zeigt sowohl den verbundenen Benutzer als auch das Ausführungskonto, und genau das macht JEA überprüfbar. Leiten Sie diese Transkripte und die innerhalb der Sitzung erzeugten PowerShell-4104-Ereignisse weiter, wie unter bösartige PowerShell erkennen beschrieben.

Versuchen Sie abschließend absichtlich auszubrechen. Führen Sie jeden sichtbaren Befehl mit ungewöhnlichen Argumenten aus, leiten Sie Ausgaben in andere sichtbare Befehle weiter und suchen Sie nach allem, was Dateien schreibt, Prozesse startet oder Gruppen ändert. Eine kurze interne Prüfung durch jemanden, der die Rolle nicht geschrieben hat, findet die meisten Ausbruchswege.

JEA betreiben

• Den Transport des Endpunkts schützen. JEA läuft über WinRM und übernimmt daher dessen Konfiguration. Wenden Sie die WinRM-Härtung an: Kerberos, kein Basic, kein CredSSP und Begrenzung per Firewall auf Managementhosts.
• Rollen Tiers zuordnen. Ein JEA-Endpunkt auf einem Tier-0-Server ist ein Tier-0-Asset, und die Gruppe, die die Rolle vergibt, ist eine Tier-0-Gruppe. Folgen Sie Ihrem Admin-Tiering-Modell.
• Vierteljährlich überprüfen. Vergleichen Sie Rollenfunktionen mit der tatsächlichen Nutzung in den Transkripten. Entfernen Sie Befehle, die niemand ausführt.
• Bei Änderungen am Endpunkt alarmieren. Eine neue oder geänderte Sitzungskonfiguration zeigt sich als Änderung unter WSMan:\localhost\Plugin; überwachen Sie das und den Modulordner mit Ihren Werkzeugen für Dateiintegrität oder Konfigurationsmanagement.

Mehr Hintergrund zu JEA und den übrigen PowerShell-Maßnahmen finden Sie auf der Themenseite PowerShell-Sicherheit.

Checkliste

• Wiederkehrende Betriebsaufgaben mit genauen Befehlen und Parameterwerten aufgelistet
• Rollenfunktionsmodul mit eingeschränkten Parametern; keine Interpreter, kein Prozessstart, keine Gruppenänderungen, kein uneingeschränkter Dateizugriff
• Sitzungskonfiguration nutzt RestrictedRemoteServer und ein begrenztes virtuelles Konto oder gMSA
• Kein unbegrenztes virtuelles Konto auf irgendeinem Domänencontroller
• RequiredGroups für sensible Rollen verwendet (zum Beispiel Smartcard- oder MFA-Nachweis)
• JEA-Benutzer aus Administrators und Remote Management Users entfernt
• Ausgabe von Get-PSSessionCapability für jede Rolle geprüft
• Transkripte und 4104-Ereignisse weitergeleitet und aufbewahrt
• Rollen- und Sitzungsdateien in der Versionsverwaltung und automatisch bereitgestellt