Konfiguracje sesji JEA
Punkt końcowy JEA jest rejestrowany w systemie przez utworzenie i zarejestrowanie pliku konfiguracji sesji programu PowerShell. Konfiguracje sesji określają, kto może używać punktu końcowego JEA i do których ról mają dostęp. Definiują również ustawienia globalne, które mają zastosowanie do wszystkich użytkowników sesji JEA.
Tworzenie pliku konfiguracji sesji
Aby zarejestrować punkt końcowy JEA, należy określić sposób konfigurowania tego punktu końcowego. Istnieje wiele opcji do rozważenia. Najważniejsze opcje to:
- KtoTo ma dostęp do punktu końcowego JEA
- Które role mogą być przypisane
- Która tożsamość jest używana przez usługę JEA w ramach
- Nazwa punktu końcowego JEA
Te opcje są definiowane w pliku danych programu PowerShell z .pssc rozszerzeniem znanym jako plik konfiguracji sesji programu PowerShell. Plik konfiguracji sesji można edytować przy użyciu dowolnego edytora tekstów.
Uruchom następujące polecenie, aby utworzyć pusty plik konfiguracji szablonu.
New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc
Napiwek
Domyślnie w pliku szablonu są uwzględniane tylko najbardziej typowe opcje konfiguracji. Użyj przełącznika -Full , aby uwzględnić wszystkie odpowiednie ustawienia w wygenerowanych programach PSSC.
Pole -SessionType RestrictedRemoteServer wskazuje, że konfiguracja sesji jest używana przez usługę JEA do bezpiecznego zarządzania. Sesje tego typu działają w trybie NoLanguage i mają dostęp tylko do następujących poleceń domyślnych (i aliasów):
Clear-Host(cls,clear)Exit-PSSession(exsn,exit)Get-Command(gcm)Get-FormatDataGet-HelpMeasure-Object(measure)Out-DefaultSelect-Object(select)
Żaden dostawca programu PowerShell nie jest dostępny ani żadnych programów zewnętrznych (wykonywalnych lub skryptów).
Aby uzyskać więcej informacji na temat trybów języka, zobacz about_Language_modes.
Wybieranie tożsamości JEA
W tle narzędzie JEA wymaga tożsamości (konta) do użycia podczas uruchamiania poleceń połączonego użytkownika. Zdefiniuj tożsamość, która jest używana przez usługę JEA w pliku konfiguracji sesji.
Lokalne konto wirtualne
Lokalne konta wirtualne są przydatne, gdy wszystkie role zdefiniowane dla punktu końcowego JEA są używane do zarządzania maszyną lokalną, a konto administratora lokalnego jest wystarczające do pomyślnego uruchomienia poleceń. Konta wirtualne to konta tymczasowe, które są unikatowe dla określonego użytkownika i trwają tylko przez czas trwania sesji programu PowerShell. Na serwerze członkowskim lub stacji roboczej konta wirtualne należą do grupy Administracja istratorów komputera lokalnego. Na kontrolerze domena usługi Active Directory konta wirtualne należą do grupy Administracja domeny.
# Setting the session to use a virtual account
RunAsVirtualAccount = $true
Jeśli role zdefiniowane przez konfigurację sesji nie wymagają pełnych uprawnień administracyjnych, możesz określić grupy zabezpieczeń, do których będzie należeć konto wirtualne. Na serwerze członkowskim lub stacji roboczej określone grupy zabezpieczeń muszą być grupami lokalnymi, a nie grupami z domeny.
Po określeniu co najmniej jednej grupy zabezpieczeń konto wirtualne nie jest przypisane do grupy administratorów lokalnych ani domen.
# Setting the session to use a virtual account that only belongs to the NetworkOperator and NetworkAuditor local groups
RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = 'NetworkOperator', 'NetworkAuditor'
Uwaga
Konta wirtualne są tymczasowo przyznawane logowanie jako usługa w zasadach zabezpieczeń serwera lokalnego. Jeśli jedno z określonych grup VirtualAccountGroups zostało już przyznane to prawo w zasadach, indywidualne konto wirtualne nie zostanie już dodane i usunięte z zasad. Może to być przydatne w scenariuszach, takich jak kontrolery domeny, w których poprawki zasad zabezpieczeń kontrolera domeny są ściśle poddawane inspekcji. Jest to dostępne tylko w systemie Windows Server 2016 z pakietem zbiorczym z listopada 2018 r. lub nowszym oraz systemem Windows Server 2019 z pakietem zbiorczym ze stycznia 2019 r. lub nowszym.
Konto usługi zarządzane przez grupę
Konto usługi zarządzane przez grupę (GMSA) jest odpowiednią tożsamością do użycia, gdy użytkownicy JEA muszą uzyskiwać dostęp do zasobów sieciowych, takich jak udziały plików i usługi internetowe. Usługi GMSA zapewniają tożsamość domeny, która jest używana do uwierzytelniania za pomocą zasobów na dowolnej maszynie w domenie. Prawa udostępniane przez usługę GMSA są określane przez zasoby, do których uzyskujesz dostęp. Nie masz uprawnień administratora na żadnych maszynach lub usługach, chyba że administrator maszyny lub usługi jawnie przyznał te prawa do GMSA.
# Configure JEA sessions to use the GMSA in the local computer's domain
# with the sAMAccountName of 'MyJEAGMSA'
GroupManagedServiceAccount = 'Domain\MyJEAGMSA'
Usługi GMSA powinny być używane tylko w razie potrzeby:
W przypadku korzystania z usługi GMSA trudno jest prześledzić akcje wsteczne do użytkownika. Każdy użytkownik współudzieli tę samą tożsamość uruchom jako. Należy przejrzeć transkrypcje i dzienniki sesji programu PowerShell, aby skorelować poszczególnych użytkowników z ich akcjami.
GmSA może mieć dostęp do wielu zasobów sieciowych, do których użytkownik łączący nie potrzebuje dostępu. Zawsze staraj się ograniczyć obowiązujące uprawnienia w sesji JEA, aby postępować zgodnie z zasadą najniższych uprawnień.
Uwaga
Konta usług zarządzanych przez grupę są dostępne tylko na maszynach przyłączonych do domeny przy użyciu programu PowerShell 5.1 lub nowszego.
Aby uzyskać więcej informacji na temat zabezpieczania sesji JEA, zobacz artykuł dotyczący zagadnień dotyczących zabezpieczeń.
Transkrypcje sesji
Zaleca się skonfigurowanie punktu końcowego JEA w celu automatycznego rejestrowania transkrypcji sesji użytkowników. Transkrypcje sesji programu PowerShell zawierają informacje o połączonym użytkowniku, przebiegu jako tożsamości przypisanej do użytkownika oraz poleceniach uruchamianych przez użytkownika. Mogą one być przydatne dla zespołu ds. inspekcji, który musi zrozumieć, kto dokonał konkretnej zmiany w systemie.
Aby skonfigurować automatyczną transkrypcję w pliku konfiguracji sesji, podaj ścieżkę do folderu, w którym powinny być przechowywane transkrypcje.
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
Transkrypcje są zapisywane w folderze przez konto systemu lokalnego, co wymaga dostępu do odczytu i zapisu w katalogu. Użytkownicy standardowi nie powinni mieć dostępu do folderu. Ogranicz liczbę administratorów zabezpieczeń, którzy mają dostęp do inspekcji transkrypcji.
Dysk użytkownika
Jeśli łączący użytkowników musi kopiować pliki do punktu końcowego jea lub z punktu końcowego JEA, możesz włączyć dysk użytkownika w pliku konfiguracji sesji. Dysk użytkownika to usługa PSDrive zamapowana na unikatowy folder dla każdego użytkownika łączącego. Ten folder umożliwia użytkownikom kopiowanie plików do lub z systemu bez udzielania im dostępu do pełnego systemu plików lub uwidaczniania dostawcy systemu plików. Zawartość dysku użytkownika jest trwała między sesjami, aby uwzględnić sytuacje, w których łączność sieciowa może zostać przerwana.
MountUserDrive = $true
Domyślnie dysk użytkownika umożliwia przechowywanie maksymalnie 50 MB danych na użytkownika. Możesz ograniczyć ilość danych, które użytkownik może używać za pomocą pola UserDriveMaximumSize .
# Enables the user drive with a per-user limit of 500MB (524288000 bytes)
MountUserDrive = $true
UserDriveMaximumSize = 524288000
Jeśli nie chcesz, aby dane na dysku użytkownika stały, możesz skonfigurować zaplanowane zadanie w systemie, aby automatycznie wyczyścić folder każdej nocy.
Uwaga
Dysk użytkownika jest dostępny tylko w programie PowerShell 5.1 lub nowszym.
Aby uzyskać więcej informacji na temat usługi PSDrives, zobacz Zarządzanie dyskami programu PowerShell.
Definicje ról
Definicje ról w pliku konfiguracji sesji definiują mapowanie użytkowników na role. Każdy użytkownik lub grupa uwzględniona w tym polu ma uprawnienie do punktu końcowego JEA po jego zarejestrowaniu.
Każdy użytkownik lub grupa może być uwzględniony jako klucz w tabeli skrótów tylko raz, ale można przypisać wiele ról. Nazwa możliwości roli powinna być nazwą pliku możliwości roli bez .psrc rozszerzenia.
RoleDefinitions = @{
'CONTOSO\JEA_DNS_ADMINS' = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_AUDITORS' = @{ RoleCapabilities = 'DnsAuditor' }
}
Jeśli użytkownik należy do więcej niż jednej grupy w definicji roli, uzyskuje dostęp do ról każdego z nich. Gdy dwa role udzielają dostępu do tych samych poleceń cmdlet, najbardziej permissive zestaw parametrów jest udzielany użytkownikowi.
Podczas określania lokalnych użytkowników lub grup w polu definicji ról należy użyć nazwy komputera, a nie hosta lokalnego ani symboli wieloznacznych. Nazwę komputera można sprawdzić, sprawdzając zmienną $env:COMPUTERNAME .
RoleDefinitions = @{
'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}
Kolejność wyszukiwania możliwości roli
Jak pokazano w powyższym przykładzie, możliwości ról są przywołyyzowane przez nazwę podstawową pliku możliwości roli. Podstawową nazwą pliku jest nazwa pliku bez rozszerzenia. Jeśli w systemie jest dostępnych wiele funkcji roli o tej samej nazwie, program PowerShell używa niejawnej kolejności wyszukiwania, aby wybrać efektywny plik funkcji roli. JeA nie zapewnia dostępu do wszystkich plików funkcji roli o tej samej nazwie.
JeA używa zmiennej środowiskowej $env:PSModulePath do określenia ścieżek do skanowania pod kątem plików funkcji roli. W każdej z tych ścieżek narzędzie JEA szuka prawidłowych modułów programu PowerShell zawierających podfolder "RoleCapabilities". Podobnie jak w przypadku importowania modułów usługa JEA preferuje funkcje roli dostarczane z systemem Windows do niestandardowych funkcji roli o tej samej nazwie.
W przypadku wszystkich innych konfliktów nazewnictwa pierwszeństwo jest określane przez kolejność, w której system Windows wylicza pliki w katalogu. Kolejność nie jest gwarantowana alfabetycznie. Pierwszy plik możliwości roli został znaleziony, który jest zgodny z określoną nazwą, jest używany dla użytkownika łączącego. Ponieważ kolejność wyszukiwania możliwości roli nie jest deterministyczna, zdecydowanie zaleca się, aby możliwości ról miały unikatowe nazwy plików.
Reguły dostępu warunkowego
Wszyscy użytkownicy i grupy zawarte w polu RoleDefinitions automatycznie otrzymują dostęp do punktów końcowych JEA. Reguły dostępu warunkowego umożliwiają uściślenie tego dostępu i wymaganie od użytkowników, aby należeli do dodatkowych grup zabezpieczeń, które nie mają wpływu na przypisane role. Jest to przydatne, gdy chcesz zintegrować rozwiązanie do zarządzania dostępem uprzywilejowanym just in time, uwierzytelnianie za pomocą karty inteligentnej lub inne rozwiązanie do uwierzytelniania wieloskładnikowego z usługą JEA.
Reguły dostępu warunkowego są definiowane w polu RequiredGroups w pliku konfiguracji sesji. W tym miejscu można podać tabelę skrótu (opcjonalnie zagnieżdżoną), która używa kluczy "And" i "Or" do konstruowania reguł. Oto kilka przykładów użycia tego pola:
# Example 1: Connecting users must belong to a security group called "elevated-jea"
RequiredGroups = @{ And = 'elevated-jea' }
# Example 2: Connecting users must have signed on with 2 factor authentication or a smart card
# The 2 factor authentication group name is "2FA-logon" and the smart card group
# name is "smartcard-logon"
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
# Example 3: Connecting users must elevate into "elevated-jea" with their JIT system and
# have logged on with 2FA or a smart card
RequiredGroups = @{ And = 'elevated-jea', @{ Or = '2FA-logon', 'smartcard-logon' }}
Uwaga
Reguły dostępu warunkowego są dostępne tylko w programie PowerShell 5.1 lub nowszym.
Inne właściwości
Pliki konfiguracji sesji mogą również robić wszystko, co może zrobić plik funkcji roli, bez możliwości zapewniania użytkownikom dostępu do różnych poleceń. Jeśli chcesz zezwolić wszystkim użytkownikom na dostęp do określonych poleceń cmdlet, funkcji lub dostawców, możesz to zrobić bezpośrednio w pliku konfiguracji sesji.
Aby uzyskać pełną listę obsługiwanych właściwości w pliku konfiguracji sesji, uruchom polecenie Get-Help New-PSSessionConfigurationFile -Full.
Testowanie pliku konfiguracji sesji
Konfigurację sesji można przetestować przy użyciu polecenia cmdlet Test-PSSessionConfigurationFile . Zaleca się przetestowanie pliku konfiguracji sesji, jeśli plik został ręcznie edytowany .pssc . Testowanie zapewnia poprawność składni. Jeśli plik konfiguracji sesji zakończy się niepowodzeniem, ten test nie może zostać zarejestrowany w systemie.
Przykładowy plik konfiguracji sesji
W poniższym przykładzie pokazano, jak utworzyć i zweryfikować konfigurację sesji dla serwera JEA. Definicje ról są tworzone i przechowywane w zmiennej $roles dla wygody i czytelności. nie jest to wymagane.
$roles = @{
'CONTOSO\JEA_DNS_ADMINS' = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_AUDITORS' = @{ RoleCapabilities = 'DnsAuditor' }
}
$parameters = @{
SessionType = 'RestrictedRemoteServer'
Path = '.\JEAConfig.pssc'
RunAsVirtualAccount = $true
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
RoleDefinitions = $roles
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
}
New-PSSessionConfigurationFile @parameters
Test-PSSessionConfigurationFile -Path .\JEAConfig.pssc # should yield True
Aktualizowanie plików konfiguracji sesji
Aby zmienić właściwości konfiguracji sesji JEA, w tym mapowanie użytkowników na role, należy wyrejestrować. Następnie ponownie zarejestruj konfigurację sesji JEA przy użyciu zaktualizowanego pliku konfiguracji sesji.
Następne kroki
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla