Możliwości roli JEA

Artykuł
11/08/2024

Podczas tworzenia punktu końcowego JEA należy zdefiniować co najmniej jedną funkcję roli, która opisuje, co ktoś może zrobić w sesji JEA. Funkcja roli to plik danych programu PowerShell z .psrc rozszerzeniem zawierającym listę wszystkich poleceń cmdlet, funkcji, dostawców i programów zewnętrznych udostępnianych do łączenia użytkowników.

Określanie poleceń, które mają być dozwolone

Pierwszym krokiem tworzenia pliku możliwości roli jest rozważenie, do czego użytkownicy potrzebują dostępu. Proces zbierania wymagań może chwilę potrwać, ale jest to ważne. Zapewnienie użytkownikom dostępu do zbyt kilku poleceń cmdlet i funkcji może uniemożliwić im wykonanie zadania. Zezwolenie na dostęp do zbyt wielu poleceń cmdlet i funkcji może umożliwić użytkownikom wykonywanie większej liczby czynności niż zamierzone i osłabienie stanu zabezpieczeń.

Sposób pracy z tym procesem zależy od organizacji i celów. Poniższe porady mogą pomóc w upewnieniu się, że jesteś na właściwej ścieżce.

Zidentyfikuj polecenia używane przez użytkowników do wykonywania swoich zadań. Może to obejmować ankietowanie pracowników IT, sprawdzanie skryptów automatyzacji lub analizowanie transkrypcji i dzienników sesji programu PowerShell.
Zaktualizuj użycie narzędzi wiersza polecenia do odpowiedników programu PowerShell, jeśli to możliwe, aby uzyskać najlepsze środowisko inspekcji i dostosowywania JEA. Programy zewnętrzne nie mogą być ograniczone tak szczegółowo, jak natywne polecenia cmdlet i funkcje programu PowerShell w narzędziu JEA.
Ogranicz zakres poleceń cmdlet, aby zezwalać tylko na określone parametry lub wartości parametrów. Jest to szczególnie ważne, jeśli użytkownicy powinni zarządzać tylko częścią systemu.
Utwórz funkcje niestandardowe, aby zastąpić złożone polecenia lub polecenia, które są trudne do ograniczenia w narzędziu JEA. Prosta funkcja, która opakowuje złożone polecenie lub stosuje dodatkową logikę walidacji, może oferować dodatkową kontrolę dla administratorów i prostoty użytkownika końcowego.
Przetestuj listę dozwolonych poleceń w zakresie z użytkownikami lub usługami automatyzacji i dostosuj je w razie potrzeby.

Przykłady potencjalnie niebezpiecznych poleceń

Staranne wybieranie poleceń jest ważne, aby upewnić się, że punkt końcowy JEA nie zezwala użytkownikowi na podniesienie uprawnień.

Ważne

Podstawowe informacje wymagane do powodzenia użytkownikaPolecenia w sesji JEA są często uruchamiane z podwyższonym poziomem uprawnień.

Poniższa lista zawiera przykłady poleceń, które mogą być używane złośliwie, jeśli są dozwolone w stanie nieskonsekwowanym. Nie jest to wyczerpująca lista i powinna być używana tylko jako punkt wyjścia ostrzegawcza.

Ryzyko: udzielanie uprawnień administratora użytkownika łączącego w celu obejścia narzędzia JEA

Przykład:
```
Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
```
Powiązane polecenia:
- Add-ADGroupMember
- Add-LocalGroupMember
- net.exe
- dsadd.exe
Ryzyko: Uruchamianie dowolnego kodu, takiego jak złośliwe oprogramowanie, luki w zabezpieczeniach lub skrypty niestandardowe w celu obejścia ochrony

Przykład:
```
Start-Process -FilePath '\\san\share\malware.exe'
```
Powiązane polecenia:
- Start-Process
- New-Service
- Invoke-Item
- Invoke-WmiMethod
- Invoke-CimMethod
- Invoke-Expression
- Invoke-Command
- New-ScheduledTask
- Register-ScheduledJob

Tworzenie pliku możliwości roli

Nowy plik funkcji roli programu PowerShell można utworzyć za pomocą polecenia cmdlet New-PSRoleCapabilityFile .

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

Należy edytować utworzony plik możliwości roli, aby zezwolić tylko na polecenia wymagane dla roli. Dokumentacja pomocy programu PowerShell zawiera kilka przykładów sposobu konfigurowania pliku.

Zezwalanie na polecenia cmdlet i funkcje programu PowerShell

Aby autoryzować użytkowników do uruchamiania poleceń cmdlet lub funkcji programu PowerShell, dodaj polecenie cmdlet lub nazwę funkcji do pól VisibleCmdlets lub VisibleFunctions . Jeśli nie masz pewności, czy polecenie jest poleceniem cmdlet lub funkcją, możesz uruchomić Get-Command <name> polecenie i sprawdzić właściwość CommandType w danych wyjściowych.

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

Czasami zakres określonego polecenia cmdlet lub funkcji jest zbyt szeroki dla potrzeb użytkowników. Na przykład administrator DNS może potrzebować dostępu tylko do ponownego uruchomienia usługi DNS. W środowiskach z wieloma dzierżawami dzierżawcy mają dostęp do narzędzi do samoobsługowego zarządzania. Dzierżawy powinny być ograniczone do zarządzania własnymi zasobami. W takich przypadkach można ograniczyć, które parametry są udostępniane z polecenia cmdlet lub funkcji.

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

W bardziej zaawansowanych scenariuszach może być również konieczne ograniczenie wartości, których użytkownik może użyć z tymi parametrami. Funkcje roli umożliwiają zdefiniowanie zestawu wartości lub wzorca wyrażenia regularnego określającego, jakie dane wejściowe są dozwolone.

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

Uwaga

Typowe parametry programu PowerShell są zawsze dozwolone, nawet jeśli ograniczasz dostępne parametry. Nie należy jawnie wyświetlać ich w polu Parametry.

Poniższa lista zawiera opis różnych sposobów dostosowywania widocznego polecenia cmdlet lub funkcji. W polu VisibleCmdlets można mieszać i dopasować dowolną z poniższych wartości.

Przypadek użycia: zezwala użytkownikowi na uruchamianie My-Func bez żadnych ograniczeń dotyczących parametrów.
```
@{ Name = 'My-Func' }
```
Przypadek użycia: zezwala użytkownikowi na uruchamianie My-Func z modułu MyModule bez żadnych ograniczeń dotyczących parametrów.
```
@{ Name = 'MyModule\My-Func' }
```
Przypadek użycia: zezwala użytkownikowi na uruchamianie dowolnego polecenia cmdlet lub funkcji z czasownikiem My.
```
@{ Name = 'My-*' }
```
Przypadek użycia: zezwól użytkownikowi na uruchomienie dowolnego polecenia cmdlet lub funkcji z nounem Func.
```
@{ Name = '*-Func' }
```
Przypadek użycia: zezwala użytkownikowi na uruchamianie My-Func z parametrami Param1 i Param2 . Do parametrów można podać dowolną wartość.
```
@{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
```
Przypadek użycia: zezwala użytkownikowi na uruchamianie My-Func za pomocą parametru Param1 . Tylko Value1 i Value2 można go dostarczyć do parametru.
```
@{
    Name       = 'My-Func'
    Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
}
```
Przypadek użycia: zezwala użytkownikowi na uruchamianie My-Func za pomocą parametru Param1 . Do parametru można podać dowolną wartość rozpoczynającą contoso się od .
```
@{
    Name       = 'My-Func'
    Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
}
```

Ostrzeżenie

W przypadku najlepszych rozwiązań w zakresie zabezpieczeń nie zaleca się używania symboli wieloznacznych podczas definiowania widocznych poleceń cmdlet lub funkcji. Zamiast tego należy jawnie wyświetlić każde zaufane polecenie, aby upewnić się, że żadne inne polecenia, które współużytkują ten sam schemat nazewnictwa, nie są przypadkowo autoryzowane.

Nie można zastosować zarówno elementu ValidatePattern , jak i ValidateSet do tego samego polecenia cmdlet lub funkcji.

Jeśli to zrobisz, funkcja ValidatePattern zastępuje element ValidateSet.

Aby uzyskać więcej informacji na temat ValidatePattern, zapoznaj się z tym wpisem Hey, Scripting Guy! i zawartością referencyjną wyrażeń regularnych programu PowerShell.

Zezwalanie na polecenia zewnętrzne i skrypty programu PowerShell

Aby umożliwić użytkownikom uruchamianie plików wykonywalnych i skryptów programu PowerShell (.ps1) w sesji JEA, należy dodać pełną ścieżkę do każdego programu w polu VisibleExternalCommands .

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

Jeśli to możliwe, użyj polecenia cmdlet programu PowerShell lub odpowiedników funkcji dla wszystkich zewnętrznych plików wykonywalnych, ponieważ masz kontrolę nad parametrami dozwolonymi za pomocą poleceń cmdlet i funkcji programu PowerShell.

Wiele plików wykonywalnych umożliwia odczytywanie bieżącego stanu, a następnie zmianę go przez podanie różnych parametrów.

Rozważmy na przykład rolę administratora serwera plików, który zarządza udziałami sieciowymi hostowanymi w systemie. Jednym ze sposobów zarządzania udziałami jest użycie polecenia net share. Jednak zezwolenie net.exe jest niebezpieczne, ponieważ użytkownik może użyć polecenia , aby uzyskać uprawnienia administratora za pomocą polecenia net group Administrators unprivilegedjeauser /add. Bezpieczniejszą opcją jest zezwolenie na polecenie cmdlet Get-SmbShare , które osiąga ten sam wynik, ale ma znacznie bardziej ograniczony zakres.

Podczas udostępniania poleceń zewnętrznych użytkownikom w sesji JEA należy zawsze określić pełną ścieżkę do pliku wykonywalnego. Zapobiega to wykonaniu podobnie nazwanych i potencjalnie złośliwych programów znajdujących się gdzie indziej w systemie.

Zezwalanie na dostęp do dostawców programu PowerShell

Domyślnie żadni dostawcy programu PowerShell nie są dostępni w sesjach JEA. Zmniejsza to ryzyko ujawnienia poufnych informacji i ustawień konfiguracji użytkownikowi łączącemu się.

W razie potrzeby możesz zezwolić na dostęp do dostawców programu PowerShell przy użyciu VisibleProviders polecenia . Aby uzyskać pełną listę dostawców, uruchom polecenie Get-PSProvider.

VisibleProviders = 'Registry'

W przypadku prostych zadań, które wymagają dostępu do systemu plików, rejestru, magazynu certyfikatów lub innych poufnych dostawców, rozważ napisanie funkcji niestandardowej, która współpracuje z dostawcą w imieniu użytkownika. Funkcje, polecenia cmdlet i programy zewnętrzne dostępne w sesji JEA nie podlegają tym samym ograniczeniom co JEA. Domyślnie mogą uzyskiwać dostęp do dowolnego dostawcy. Rozważ również użycie dysku użytkownika, gdy użytkownicy muszą kopiować pliki do punktu końcowego JEA lub z tego punktu końcowego.

Tworzenie funkcji niestandardowych

Funkcje niestandardowe można tworzyć w pliku funkcji roli, aby uprościć złożone zadania dla użytkowników końcowych. Funkcje niestandardowe są również przydatne, gdy wymagana jest zaawansowana logika walidacji dla wartości parametrów polecenia cmdlet. Proste funkcje można napisać w polu FunctionDefinitions :

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
    }
}

Ważne

Nie zapomnij dodać nazwy funkcji niestandardowych do pola VisibleFunctions , aby mogły być uruchamiane przez użytkowników JEA.

Treść (blok skryptu) funkcji niestandardowych działa w trybie domyślnym dla systemu i nie podlega ograniczeniom języka JEA. Oznacza to, że funkcje mogą uzyskiwać dostęp do systemu plików i rejestru oraz uruchamiać polecenia, które nie zostały widoczne w pliku możliwości roli. Należy zachować ostrożność, aby uniknąć uruchamiania dowolnego kodu podczas używania parametrów. Unikaj potokowania danych wejściowych użytkownika bezpośrednio do poleceń cmdlet, takich jak Invoke-Expression.

W powyższym przykładzie zwróć uwagę, że użyto w pełni kwalifikowanej nazwy modułu (FQMN) Microsoft.PowerShell.Utility\Select-Object zamiast skrótu Select-Object. Funkcje zdefiniowane w plikach funkcji roli nadal podlegają zakresowi sesji JEA, które obejmują funkcje serwera proxy tworzone przez jea w celu ograniczenia istniejących poleceń.

Domyślnie Select-Object jest ograniczonym poleceniem cmdlet we wszystkich sesjach JEA, które nie zezwalają na wybór dowolnych właściwości w obiektach. Aby użyć funkcji nieprzyciągniętych Select-Object , należy jawnie zażądać pełnej implementacji przy użyciu nazwy FQMN. Każde ograniczone polecenie cmdlet w sesji JEA ma te same ograniczenia podczas wywoływania z funkcji. Aby uzyskać więcej informacji, zobacz about_Command_Precedence.

Jeśli piszesz kilka funkcji niestandardowych, wygodniejsze jest umieszczenie ich w module skryptu programu PowerShell. Te funkcje są widoczne w sesji JEA przy użyciu pola VisibleFunctions , tak jak w przypadku wbudowanych i modułów innych firm.

Aby ukończenie karty działało prawidłowo w sesjach JEA, należy uwzględnić wbudowaną funkcję tabexpansion2 na liście VisibleFunctions .

Udostępnianie możliwości roli w konfiguracji

Przed programem PowerShell 6, aby program PowerShell znalazł plik funkcji roli, musi być przechowywany w RoleCapabilities folderze w module programu PowerShell. Moduł może być przechowywany w dowolnym folderze dołączonym do $env:PSModulePath zmiennej środowiskowej, jednak nie należy umieszczać go w folderze lub folderze, w $env:SystemRoot\System32 którym niezaufani użytkownicy mogą modyfikować pliki.

Poniższy przykład obejmuje tworzenie modułu skryptu programu PowerShell o nazwie ContosoJEA w $env:ProgramFiles ścieżce do hostowania pliku możliwości roli.

# 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

Aby uzyskać więcej informacji na temat modułów programu PowerShell, zobacz Omówienie modułu programu PowerShell.

Począwszy od programu PowerShell 6, właściwość RoleDefinitions została dodana do pliku konfiguracji sesji. Ta właściwość umożliwia określenie lokalizacji pliku konfiguracji roli dla definicji roli. Zobacz przykłady w pliku New-PSSessionConfigurationFile.

Aktualizowanie możliwości roli

Plik możliwości roli można edytować, aby zaktualizować ustawienia w dowolnym momencie. Wszystkie nowe sesje JEA rozpoczęte po zaktualizowaniu funkcji roli będą odzwierciedlać zmienione możliwości.

Dlatego kontrolowanie dostępu do folderu możliwości roli jest tak ważne. Tylko wysoce zaufani administratorzy powinni mieć możliwość zmiany plików funkcji roli. Jeśli niezaufany użytkownik może zmienić pliki funkcji roli, może łatwo przyznać sobie dostęp do poleceń cmdlet, które umożliwiają im podniesienie uprawnień.

W przypadku administratorów, którzy chcą zablokować dostęp do funkcji roli, upewnij się, że system lokalny ma dostęp tylko do odczytu do plików funkcji roli i zawierających moduły.

Jak funkcje roli są scalane

Użytkownicy otrzymują dostęp do wszystkich pasujących funkcji roli w pliku konfiguracji sesji podczas wprowadzania sesji JEA. JeA próbuje nadać użytkownikowi najbardziej permissywny zestaw poleceń dozwolonych przez dowolną z ról.

VisibleCmdlets i VisibleFunctions

Najbardziej złożona logika scalania ma wpływ na polecenia cmdlet i funkcje, które mogą mieć ich parametry i wartości parametrów ograniczone w narzędziu JEA.

Reguły są następujące:

Jeśli polecenie cmdlet jest widoczne tylko w jednej roli, jest widoczne dla użytkownika z dowolnymi odpowiednimi ograniczeniami parametrów.
Jeśli polecenie cmdlet jest widoczne w więcej niż jednej roli, a każda rola ma te same ograniczenia dotyczące polecenia cmdlet, polecenie cmdlet jest widoczne dla użytkownika z tymi ograniczeniami.
Jeśli polecenie cmdlet jest widoczne w więcej niż jednej roli, a każda rola zezwala na inny zestaw parametrów, polecenie cmdlet i wszystkie parametry zdefiniowane w każdej roli są widoczne dla użytkownika. Jeśli jedna rola nie ma ograniczeń dotyczących parametrów, wszystkie parametry są dozwolone.
Jeśli jedna rola definiuje zestaw weryfikacji lub walidować wzorzec dla parametru cmdlet, a druga rola zezwala na parametr, ale nie ogranicza wartości parametrów, zestaw weryfikacji lub wzorzec jest ignorowany.
Jeśli zestaw weryfikacji jest zdefiniowany dla tego samego parametru polecenia cmdlet w więcej niż jednej roli, wszystkie wartości ze wszystkich zestawów weryfikacji są dozwolone.
Jeśli wzorzec weryfikacji jest zdefiniowany dla tego samego parametru polecenia cmdlet w więcej niż jednej roli, wszystkie wartości zgodne z dowolnymi wzorcami są dozwolone.
Jeśli zestaw weryfikacji jest zdefiniowany w co najmniej jednej roli, a wzorzec weryfikacji jest zdefiniowany w innej roli dla tego samego parametru polecenia cmdlet, zestaw weryfikacji jest ignorowany, a reguła (6) ma zastosowanie do pozostałych wzorców walidacji.

Poniżej przedstawiono przykład scalania ról zgodnie z tymi regułami:

# 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

Wszystkie inne pola w pliku możliwości roli są dodawane do zbiorczego zestawu dozwolonych poleceń zewnętrznych, aliasów, dostawców i skryptów uruchamiania. Dowolne polecenie, alias, dostawca lub skrypt dostępny w jednej funkcji roli jest dostępne dla użytkownika JEA.

Należy zachować ostrożność, aby łączny zestaw dostawców z jednej funkcji roli i poleceń cmdlet/funkcji/poleceń z innego nie zezwalał użytkownikom na niezamierzony dostęp do zasobów systemowych. Jeśli na przykład jedna rola zezwala na Remove-Item polecenie cmdlet, a druga zezwala FileSystem na dostawcę, istnieje ryzyko usunięcia przez użytkownika JEA dowolnych plików na komputerze. Dodatkowe informacje na temat identyfikowania skutecznych uprawnień użytkowników można znaleźć w artykule dotyczącym inspekcji serwera JEA .

Następne kroki

Tworzenie pliku konfiguracji sesji

Udostępnij za pośrednictwem