JEA-Rollenfunktionen

Beim Erstellen eines JEA-Endpunkts müssen Sie eine oder mehrere Rollenfunktionen definieren, die festlegen, welche Befehle ein Benutzer in einer JEA-Sitzung ausführen kann. Eine Rollenfunktion ist eine PowerShell-Datendatei mit der .psrc Erweiterung, die alle Cmdlets, Funktionen, Anbieter und externen Programme auflistet, die zum Verbinden von Benutzern zur Verfügung gestellt werden.

Bestimmen, welche Befehle zugelassen werden sollen

Der erste Schritt beim Erstellen einer Rollenfunktionsdatei besteht darin, zu berücksichtigen, auf welche Elemente die Benutzer zugreifen müssen. Der Prozess zum Sammeln von Anforderungen kann eine Weile dauern, aber es ist wichtig. Wenn Benutzer auf zu wenige Cmdlets und Funktionen zugreifen können, können sie daran hindern, ihre Arbeit zu erledigen. Wenn Sie den Zugriff auf zu viele Cmdlets und Funktionen zulassen, können Benutzer mehr tun als beabsichtigt und Ihre Sicherheitsposition schwächen.

Wie Sie diesen Prozess behandeln, hängt von Ihrer Organisation und Ihren Zielen ab. Mit den folgenden Tipps können Sie sicherstellen, dass Sie auf dem richtigen Pfad sind.

1. Identifizieren Sie die Befehle, die Benutzer verwenden, um ihre Aufgaben zu erledigen. Dies kann das Verfragen von IT-Mitarbeitern, das Überprüfen von Automatisierungsskripts oder das Analysieren von PowerShell-Sitzungstranskripts und -protokollen umfassen.
2. Aktualisieren Sie die Verwendung von Befehlszeilentools auf PowerShell-Entsprechungen, sofern möglich, für die beste Überwachung und JEA-Anpassung. Externe Programme können nicht so präzise wie systemeigene PowerShell-Cmdlets und -Funktionen in JEA eingeschränkt werden.
3. Beschränken Sie den Bereich der Cmdlets, um nur bestimmte Parameter oder Parameterwerte zuzulassen. Dies ist besonders wichtig, wenn Benutzer nur einen Teil eines Systems verwalten sollten.
4. Erstellen Sie benutzerdefinierte Funktionen, um komplexe Befehle oder Befehle zu ersetzen, die in JEA nur schwer eingeschränkt werden können. Eine einfache Funktion, die einen komplexen Befehl umschließt oder zusätzliche Validierungslogik anwendet, kann zusätzliche Kontrolle für Administratoren und Endbenutzer-Einfachheit bieten.
5. Testen Sie die bereichsbezogene Liste der zulässigen Befehle mit Ihren Benutzern oder Automatisierungsdiensten, und passen Sie sie bei Bedarf an.

Beispiele für potenziell gefährliche Befehle

Die sorgfältige Auswahl von Befehlen ist wichtig, um sicherzustellen, dass der JEA-Endpunkt dem Benutzer nicht erlaubt, seine Berechtigungen zu erhöhen.

Die folgende Liste enthält Beispiele für Befehle, die böswillig verwendet werden können, wenn dies in einem nicht eingeschränkten Zustand zulässig ist. Dies ist keine vollständige Liste und sollte nur als vorsichtiger Ausgangspunkt verwendet werden.

• Risiko: Gewähren der Benutzeradministratorberechtigungen zum Umgehen von JEA

  Beispiel:

  Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
  

  Verwandte Befehle:

  • Add-ADGroupMember
  • Add-LocalGroupMember
  • net.exe
  • dsadd.exe

• Risiko: Ausführen von beliebigem Code, z. B. Schadsoftware, Exploits oder benutzerdefinierten Skripts, um Schutz zu umgehen

  Beispiel:

  Start-Process -FilePath '\\san\share\malware.exe'
  

  Verwandte Befehle:

  • Start-Process
  • New-Service
  • Invoke-Item
  • Invoke-WmiMethod
  • Invoke-CimMethod
  • Invoke-Expression
  • Invoke-Command
  • New-ScheduledTask
  • Register-ScheduledJob

Erstellen einer Rollenfunktionsdatei

Sie können eine neue PowerShell-Rollenfunktionsdatei mit dem New-PSRoleCapabilityFile-Cmdlet erstellen.

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

Sie sollten die erstellte Rollenfunktionsdatei bearbeiten, um nur die befehle zuzulassen, die für die Rolle erforderlich sind. Die PowerShell-Hilfedokumentation enthält mehrere Beispiele dafür, wie Sie die Datei konfigurieren können.

Zulassen von PowerShell-Cmdlets und -Funktionen

Um Benutzer zum Ausführen von PowerShell-Cmdlets oder -Funktionen zu autorisieren, fügen Sie das Cmdlet oder den Funktionsnamen den Feldern VisibleCmdlets oder VisibleFunctions hinzu. Wenn Sie nicht sicher sind, ob es sich bei einem Befehl um ein Cmdlet oder eine Funktion handelt, können Sie die CommandType-Eigenschaft in der Ausgabe ausführen Get-Command <name> und überprüfen.

VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')

Manchmal ist der Umfang eines bestimmten Cmdlets oder einer bestimmten Funktion zu breit für die Anforderungen Ihrer Benutzer. Ein DNS-Administrator benötigt beispielsweise nur Zugriff, um den DNS-Dienst neu zu starten. In Umgebungen mit mehreren Mandanten haben Mandanten Zugriff auf Self-Service-Verwaltungstools. Mandanten sollten auf die Verwaltung ihrer eigenen Ressourcen beschränkt sein. In diesen Fällen können Sie einschränken, welche Parameter aus dem Cmdlet oder der Funktion verfügbar gemacht werden.

VisibleCmdlets = @{
    Name       = 'Restart-Computer'
    Parameters = @{ Name = 'Name' }
}

In komplexeren Szenarien müssen Sie möglicherweise auch die Werte einschränken, die ein Benutzer mit diesen Parametern verwenden kann. Mithilfe von Rollenfunktionen können Sie einen Satz von Werten oder ein Muster eines regulären Ausdrucks definieren, mit dem bestimmt wird, welche Eingabe zulässig ist.

VisibleCmdlets = @(
    @{
        Name       = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
    }
    @{
        Name       = 'Start-Website'
        Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
    }
)

In der folgenden Liste werden die verschiedenen Möglichkeiten beschrieben, wie Sie ein sichtbares Cmdlet oder eine sichtbare Funktion anpassen können. Im Feld "VisibleCmdlets " können Sie eine beliebige der unten stehenden Elemente mischen und abgleichen.

• Anwendungsfall: Zulassen, dass der Benutzer ohne Einschränkungen für die Parameter ausgeführt werden My-Func kann.

  @{ Name = 'My-Func' }
  

• Anwendungsfall: Zulassen, dass der Benutzer ohne Einschränkungen für die Parameter vom Modul "MyModule" ausgeführt werden My-Func kann.

  @{ Name = 'MyModule\My-Func' }
  

• Anwendungsfall: Zulassen, dass der Benutzer ein beliebiges Cmdlet oder eine beliebige Funktion mit dem Verb Myausführen kann.

  @{ Name = 'My-*' }
  

• Anwendungsfall: Zulassen, dass der Benutzer ein beliebiges Cmdlet oder eine Funktion mit dem Substantiv Funcausführt.

  @{ Name = '*-Func' }
  

• Anwendungsfall: Zulassen, dass der Benutzer mit den Param1 Parametern ausgeführt Param2 werden My-Func kann. Jeder Wert kann den Parametern bereitgestellt werden.

  @{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
  

• Anwendungsfall: Zulassen, dass der Benutzer mit dem Param1 Parameter ausgeführt wirdMy-Func. Nur Value1 und Value2 kann für den Parameter angegeben werden.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
  }
  

• Anwendungsfall: Zulassen, dass der Benutzer mit dem Param1 Parameter ausgeführt wirdMy-Func. Jeder Wert, der mit contoso dem Parameter beginnt, kann an den Parameter übergeben werden.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
  }
  

Sie können sowohl eine ValidatePattern - als auch " ValidateSet" nicht auf dasselbe Cmdlet oder dieselbe Funktion anwenden.

Wenn Sie dies tun, überschreibt validatePattern das ValidateSet.

Weitere Informationen zu ValidatePattern finden Sie in diesem Beitrag "Hey" und "Scripting Guy!" und den Referenzinhalt für reguläre PowerShell-Ausdrücke.

Zulassen externer Befehle und PowerShell-Skripts

Damit Benutzer ausführbare Dateien und PowerShell-Skripts (.ps1) in einer JEA-Sitzung ausführen können, müssen Sie den vollständigen Pfad zu jedem Programm im Feld VisibleExternalCommands hinzufügen.

VisibleExternalCommands = @(
    'C:\Windows\System32\whoami.exe'
    'C:\Program Files\Contoso\Scripts\UpdateITSoftware.ps1'
)

Verwenden Sie nach Möglichkeit PowerShell-Cmdlets oder Funktionsäquivalente für alle externen ausführbaren Dateien, die Sie autorisieren, da Sie die Kontrolle über die parameter haben, die mit PowerShell-Cmdlets und -Funktionen zulässig sind.

Mit vielen ausführbaren Dateien können Sie den aktuellen Zustand lesen und dann ändern, indem Sie verschiedene Parameter angeben.

Betrachten Sie beispielsweise die Rolle eines Dateiserveradministrators, der Netzwerkfreigaben verwaltet, die auf einem System gehostet werden. Eine Möglichkeit zum Verwalten von Aktien ist die Verwendung net share. Das Zulassen net.exe ist jedoch gefährlich, da der Benutzer den Befehl verwenden konnte, um Administratorrechte mit dem Befehl net group Administrators unprivilegedjeauser /addzu erhalten. Eine sicherere Option besteht darin, das Get-SmbShare-Cmdlet zuzulassen, das dasselbe Ergebnis erreicht, aber einen viel eingeschränkteren Bereich hat.

Wenn Externe Befehle benutzern in einer JEA-Sitzung zur Verfügung gestellt werden, geben Sie immer den vollständigen Pfad zur ausführbaren Datei an. Dies verhindert die Ausführung von ähnlich benannten und potenziell schädlichen Programmen, die sich an anderer Stelle im System befinden.

Zugriff auf PowerShell-Anbieter zulassen

Standardmäßig sind keine PowerShell-Anbieter in JEA-Sitzungen verfügbar. Dadurch wird das Risiko reduziert, dass vertrauliche Informationen und Konfigurationseinstellungen für den verbindenden Benutzer offengelegt werden.

Bei Bedarf können Sie den Zugriff auf die PowerShell-Anbieter mithilfe des VisibleProviders Befehls zulassen. Führen Sie eine vollständige Liste der Anbieter aus Get-PSProvider.

VisibleProviders = 'Registry'

Für einfache Aufgaben, die Zugriff auf das Dateisystem, die Registrierung, den Zertifikatspeicher oder andere vertrauliche Anbieter erfordern, sollten Sie eine benutzerdefinierte Funktion schreiben, die mit dem Anbieter im Namen des Benutzers arbeitet. Die in einer JEA-Sitzung verfügbaren Funktionen, Cmdlets und externen Programme unterliegen nicht den gleichen Einschränkungen wie JEA. Sie können standardmäßig auf jeden Beliebigen Anbieter zugreifen. Erwägen Sie auch die Verwendung des Benutzerlaufwerks , wenn Benutzer Dateien in oder von einem JEA-Endpunkt kopieren müssen.

Erstellen benutzerdefinierter Funktionen

Sie können benutzerdefinierte Funktionen in einer Rollenfunktionsdatei erstellen, um komplexe Aufgaben für Ihre Endbenutzer zu vereinfachen. Benutzerdefinierte Funktionen sind auch hilfreich, wenn Sie erweiterte Validierungslogik für Cmdlet-Parameterwerte benötigen. Sie können einfache Funktionen im Feld "FunctionDefinitions " schreiben:

VisibleFunctions = 'Get-TopProcess'

FunctionDefinitions = @{
    Name        = 'Get-TopProcess'
    ScriptBlock = {
        param($Count = 10)

        Get-Process |
            Sort-Object -Property CPU -Descending |
            Microsoft.PowerShell.Utility\Select-Object -First $Count
    }
}

Der Textkörper (Skriptblock) von benutzerdefinierten Funktionen wird im Standardsprachenmodus für das System ausgeführt und unterliegt nicht den Spracheinschränkungen von JEA. Dies bedeutet, dass Funktionen auf das Dateisystem und die Registrierung zugreifen und Befehle ausführen können, die in der Rollenfunktionsdatei nicht sichtbar gemacht wurden. Achten Sie darauf, bei der Verwendung von Parametern keine beliebigen Code auszuführen. Vermeiden Sie die Direkteinleitung von Benutzereingaben in Cmdlets wie Invoke-Expressionz. B.

Beachten Sie im obigen Beispiel, dass der vollqualifizierte Modulname (FQMN) Microsoft.PowerShell.Utility\Select-Object anstelle der Kurzhand Select-Objectverwendet wurde. Funktionen, die in Rollenfunktionsdateien definiert sind, unterliegen weiterhin dem Umfang von JEA-Sitzungen, einschließlich der Proxyfunktionen, die JEA erstellt, um vorhandene Befehle einzuschränken.

Standardmäßig ist ein eingeschränktes Cmdlet in allen JEA-Sitzungen, Select-Object das die Auswahl beliebiger Eigenschaften für Objekte nicht zulässt. Um die nicht eingeschränkten Select-Object Funktionen zu verwenden, müssen Sie die vollständige Implementierung explizit mithilfe des FQMN anfordern. Alle eingeschränkten Cmdlets in einer JEA-Sitzung haben dieselben Einschränkungen, wenn sie von einer Funktion aufgerufen werden. Weitere Informationen finden Sie unter about_Command_Precedence.

Wenn Sie mehrere benutzerdefinierte Funktionen schreiben, ist es praktischer, sie in einem PowerShell-Skriptmodul zu platzieren. Diese Funktionen werden in der JEA-Sitzung mithilfe des Felds "VisibleFunctions" wie bei integrierten Und Drittanbietermodulen sichtbar.

Damit der Registerkartenabschluss in JEA-Sitzungen ordnungsgemäß funktioniert, müssen Sie die integrierte Funktion TabExpansion2 in die Liste "VisibleFunctions" einschließen.

Bereitstellung der Rollenfunktionen für eine Konfiguration

Vor PowerShell 6 muss powerShell eine Rollenfunktionsdatei finden, die in einem Ordner in einem RoleCapabilities PowerShell-Modul gespeichert werden muss. Das Modul kann in einem beliebigen Ordner gespeichert werden, der in der $Env:PSModulePath Umgebungsvariable enthalten ist. Sie sollten es jedoch nicht in einem Ordner platzieren, in $Env:SystemRoot\System32 dem nicht vertrauenswürdige Benutzer die Dateien ändern können.

Im folgenden Beispiel wird ein PowerShell-Skriptmodul namens "ContosoJEA " im $Env:ProgramFiles Pfad zum Hosten der Rollenfunktionendatei erstellt.

# Create a folder for the module
$modulePath = Join-Path $Env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
New-Item -ItemType Directory -Path $modulePath

# Create an empty script module and module manifest.
# At least one file in the module folder must have the same name as the folder itself.
$rootModulePath = Join-Path $modulePath "ContosoJEAFunctions.psm1"
$moduleManifestPath = Join-Path $modulePath "ContosoJEA.psd1"
New-Item -ItemType File -Path $RootModulePath
New-ModuleManifest -Path $moduleManifestPath -RootModule "ContosoJEAFunctions.psm1"

# Create the RoleCapabilities folder and copy in the PSRC file
$rcFolder = Join-Path $modulePath "RoleCapabilities"
New-Item -ItemType Directory $rcFolder
Copy-Item -Path .\MyFirstJEARole.psrc -Destination $rcFolder

Weitere Informationen zu PowerShell-Modulen finden Sie unter Grundlegendes zu einem PowerShell-Modul.

Ab PowerShell 6 wurde die RoleDefinitions-Eigenschaft der Sitzungskonfigurationsdatei hinzugefügt. Mit dieser Eigenschaft können Sie den Speicherort einer Rollenkonfigurationsdatei für Ihre Rollendefinition angeben. Sehen Sie sich die Beispiele in New-PSSessionConfigurationFile an.

Aktualisieren von Rollenfunktionen

Sie können eine Rollenfunktionsdatei bearbeiten, um die Einstellungen jederzeit zu aktualisieren. Alle neuen JEA-Sitzungen, die nach der Aktualisierung der Rollenfunktion gestartet wurden, spiegeln die überarbeiteten Funktionen wider.

Aus diesem Grund ist es so wichtig, den Zugriff auf den Rollenfunktionenordner zu steuern. Nur vertrauenswürdige Administratoren sollten rollenfähige Dateien ändern dürfen. Wenn ein nicht vertrauenswürdiger Benutzer Rollenfunktionsdateien ändern kann, kann er sich problemlos Zugriff auf Cmdlets gewähren, mit denen er seine Berechtigungen erhöhen kann.

Administratoren, die den Zugriff auf die Rollenfunktionen sperren möchten, stellen Sie sicher, dass das lokale System schreibgeschützten Zugriff auf die Rollenfunktionsdateien und module hat.

Zusammenführen von Rollenfunktionen

Benutzern wird Zugriff auf alle übereinstimmenden Rollenfunktionen in der Sitzungskonfigurationsdatei gewährt, wenn sie eine JEA-Sitzung eingeben. JEA versucht, dem Benutzer die berechtigungsstärkste Gruppe von Befehlen zu geben, die von einer der Rollen zulässig sind.

VisibleCmdlets und VisibleFunctions

Die komplexeste Zusammenführungslogik wirkt sich auf Cmdlets und Funktionen aus, die ihre Parameter und Parameterwerte in JEA einschränken können.

Die Regeln sind wie folgt:

1. Wenn ein Cmdlet nur in einer Rolle sichtbar gemacht wird, ist es für den Benutzer mit allen anwendbaren Parametereinschränkungen sichtbar.
2. Wenn ein Cmdlet in mehreren Rollen sichtbar gemacht wird und jede Rolle dieselben Einschränkungen für das Cmdlet aufweist, ist das Cmdlet für den Benutzer mit diesen Einschränkungen sichtbar.
3. Wenn ein Cmdlet in mehreren Rollen sichtbar gemacht wird und jede Rolle einen anderen Satz von Parametern zulässt, sind das Cmdlet und alle parameter, die in jeder Rolle definiert sind, für den Benutzer sichtbar. Wenn eine Rolle keine Einschränkungen für die Parameter enthält, sind alle Parameter zulässig.
4. Wenn eine Rolle ein Überprüfungssatz- oder Überprüfungsmuster für einen Cmdlet-Parameter definiert und die andere Rolle den Parameter zulässt, aber die Parameterwerte nicht einschränkt, wird der Validate-Satz oder das Muster ignoriert.
5. Wenn ein Gültigkeitssatz für denselben Cmdlet-Parameter in mehr als einer Rolle definiert ist, sind alle Werte aus allen Validate-Sätzen zulässig.
6. Wenn ein Überprüfungsmuster für denselben Cmdlet-Parameter in mehr als einer Rolle definiert ist, sind alle Werte zulässig, die mit einem der Muster übereinstimmen.
7. Wenn ein Gültigkeitssatz in einer oder mehreren Rollen definiert ist und ein Überprüfungsmuster in einer anderen Rolle für denselben Cmdlet-Parameter definiert ist, wird der Gültigkeitssatz ignoriert, und die Regel (6) gilt für die verbleibenden Überprüfungsmuster.

Nachfolgend finden Sie ein Beispiel dafür, wie Rollen gemäß den folgenden Regeln zusammengeführt werden:

# Role A Visible Cmdlets
$roleA = @{
    VisibleCmdlets = @(
        'Get-Service'
         @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Client' }
        }
    )
}

# Role B Visible Cmdlets
$roleB = @{
    VisibleCmdlets = @(
        @{
            Name       = 'Get-Service';
            Parameters = @{ Name = 'DisplayName'; ValidatePattern = 'DNS.*' }
        }
        @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Server' }
        }
    )
}

# Resulting permissions for a user who belongs to both role A and B
# - The constraint in role B for the DisplayName parameter on Get-Service
#   is ignored because of rule #4
# - The ValidateSets for Restart-Service are merged because both roles use
#   ValidateSet on the same parameter per rule #5
$mergedAandB = @{
    VisibleCmdlets = @(
        'Get-Service'
        @{
            Name = 'Restart-Service';
            Parameters = @{
                Name = 'DisplayName'
                ValidateSet = 'DNS Client', 'DNS Server'
            }
        }
    )
}

VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess

Alle anderen Felder in der Rollenfunktionsdatei werden einem kumulativen Satz zulässiger externer Befehle, Aliase, Anbieter und Startskripts hinzugefügt. Jeder Befehl, Alias, Anbieter oder Skript, der in einer Rollenfunktion verfügbar ist, ist für den JEA-Benutzer verfügbar.

Achten Sie darauf, dass die kombinierte Gruppe von Anbietern aus einer Rollenfunktion und cmdlets/functions/commands/commands von einem anderen nicht unbeabsichtigten Zugriff auf Systemressourcen ermöglicht. Wenn beispielsweise eine Rolle das Remove-Item Cmdlet zulässt und ein anderer den FileSystem Anbieter zulässt, besteht das Risiko, dass ein JEA-Benutzer willkürliche Dateien auf Ihrem Computer löscht. Weitere Informationen zum Identifizieren der effektiven Berechtigungen von Benutzern finden Sie im JeA-Artikel zur Überwachung .

Nächste Schritte

Erstellen einer Sitzungskonfigurationsdatei