Zagadnienia dotyczące zabezpieczeń jea

Narzędzie JEA pomaga zwiększyć poziom zabezpieczeń, zmniejszając liczbę stałych administratorów na maszynach. Usługa JEA używa konfiguracji sesji programu PowerShell do utworzenia nowego punktu wejścia dla użytkowników do zarządzania systemem. Użytkownicy, którzy potrzebują podwyższonego poziomu uprawnień, ale nie nieograniczonego dostępu do maszyny do wykonywania zadań administracyjnych, mogą mieć dostęp do punktu końcowego JEA. Ponieważ usługa JEA umożliwia tym użytkownikom uruchamianie poleceń administracyjnych bez pełnego dostępu administratora, możesz usunąć tych użytkowników z wysoce uprzywilejowanych grup zabezpieczeń.

Konto Uruchom jako

Każdy punkt końcowy JEA ma wyznaczone konto Uruchom jako , na którym są wykonywane akcje łączącego użytkownika. To konto można skonfigurować w pliku konfiguracji sesji, a wybrane konto ma znaczący wpływ na bezpieczeństwo punktu końcowego.

Konta wirtualne to zalecany sposób konfigurowania konta Uruchom jako . Konta wirtualne to jednorazowe, tymczasowe konta lokalne, które są tworzone dla użytkownika łączącego do użycia w czasie trwania sesji JEA. Po zakończeniu sesji konto wirtualne zostanie zniszczone i nie będzie już możliwe. Użytkownik łączący nie zna poświadczeń dla konta wirtualnego. Nie można używać konta wirtualnego do uzyskiwania dostępu do systemu za pośrednictwem innych środków, takich jak pulpit zdalny lub nieuszkodzony punkt końcowy programu PowerShell.

Domyślnie konta wirtualne są członkami lokalnej grupy Administracja istratorów na maszynie. To członkostwo daje im pełne prawa do zarządzania wszystkimi elementami w systemie, ale nie ma uprawnień do zarządzania zasobami w sieci. Gdy użytkownik łączy się z innymi maszynami z sesji JEA, kontekstem użytkownika jest konto komputera lokalnego, a nie konto wirtualne.

Kontrolery domeny są specjalnym przypadkiem, ponieważ nie ma lokalnej grupy Administracja istratorów. Zamiast tego konta wirtualne należą do Administracja domeny i mogą zarządzać usługami katalogowymi na kontrolerze domeny. Tożsamość domeny jest nadal ograniczona do użycia na kontrolerze domeny, gdzie utworzono wystąpienie sesji JEA. Każdy dostęp sieciowy wydaje się pochodzić z obiektu komputera kontrolera domeny.

W obu przypadkach można przypisać konto wirtualne do określonych grup zabezpieczeń, zwłaszcza gdy zadanie można wykonać bez uprawnień administratora lokalnego lub domeny. Jeśli masz już grupę zabezpieczeń zdefiniowaną dla administratorów, przyznaj członkostwu konta wirtualnego tej grupie. Członkostwo w grupie dla kont wirtualnych jest ograniczone do lokalnych grup zabezpieczeń na stacjach roboczych i serwerach członkowskich. Na kontrolerach domeny konta wirtualne muszą być członkami grup zabezpieczeń domeny. Po dodaniu konta wirtualnego do co najmniej jednej grupy zabezpieczeń nie należy już do grup domyślnych (administratorów lokalnych lub domen).

Poniższa tabela zawiera podsumowanie możliwych opcji konfiguracji i wynikowych uprawnień dla kont wirtualnych:

Typ komputera	Konfiguracja grupy kont wirtualnych	Kontekst użytkownika lokalnego	Kontekst użytkownika sieciowego
Kontroler domeny	Wartość domyślna	Użytkownik domeny, członek <DOMAIN>\Domain Admins	Konto komputera
Kontroler domeny	Grupy domen A i B	Użytkownik domeny, członek ,<DOMAIN>\A<DOMAIN>\B	Konto komputera
Serwer członkowski lub stacja robocza	Wartość domyślna	Użytkownik lokalny, członek BUILTIN\Administrators	Konto komputera
Serwer członkowski lub stacja robocza	Grupy lokalne C i D	Użytkownik lokalny, członek i <COMPUTER>\C<COMPUTER>\D	Konto komputera

Po zapoznaniu się z dziennikami zdarzeń inspekcji zabezpieczeń i aplikacji zobaczysz, że każda sesja użytkownika JEA ma unikatowe konto wirtualne. To unikatowe konto ułatwia śledzenie akcji użytkownika w punkcie końcowym JEA z powrotem do oryginalnego użytkownika, który uruchomił polecenie. Nazwy kont wirtualnych są zgodne z formatem WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> Na przykład jeśli użytkownik Alice w domenie Contoso ponownie uruchomi usługę w punkcie końcowym JEA, nazwa użytkownika skojarzona z dowolnymi zdarzeniami menedżera kontroli usługi będzie .WinRM Virtual Users\WinRM_VA_1_contoso_alice

Konta usług zarządzane przez grupę (gMSA) są przydatne, gdy serwer członkowski musi mieć dostęp do zasobów sieciowych w sesji JEA. Na przykład gdy punkt końcowy JEA jest używany do kontrolowania dostępu do usługi interfejsu API REST hostowanej na innej maszynie. Funkcje można łatwo zapisywać w celu wywoływania interfejsów API REST, ale do uwierzytelniania za pomocą interfejsu API potrzebna jest tożsamość sieciowa. Użycie konta usługi zarządzanego przez grupę umożliwia drugi przeskok przy zachowaniu kontroli nad tym, które komputery mogą używać konta. Członkostwo grupy zabezpieczeń (lokalnej lub domeny) grupy zabezpieczeń grupy zarządzanej przez grupę zdefiniowało obowiązujące uprawnienia dla konta usługi gMSA.

Gdy punkt końcowy JEA jest skonfigurowany do używania konta zarządzanego przez grupę, akcje wszystkich użytkowników jea wydają się pochodzić z tego samego konta zarządzanego przez grupę. Jedynym sposobem śledzenia akcji z powrotem do określonego użytkownika jest zidentyfikowanie zestawu poleceń uruchamianych w transkrypcji sesji programu PowerShell.

Poświadczenia przekazywane są używane, gdy nie określisz konta Uruchom jako . Program PowerShell używa poświadczeń użytkownika łączącego do uruchamiania poleceń na serwerze zdalnym. Aby używać poświadczeń przekazywania, należy przyznać użytkownikowi nawiązujący bezpośredni dostęp do uprzywilejowanych grup zarządzania. Ta konfiguracja nie jest zalecana w przypadku serwera JEA. Jeśli łączący się użytkownik ma już uprawnienia administratora, może pominąć jea i zarządzać systemem przy użyciu innych metod dostępu.

Konta Uruchom jako w warstwie Standardowa umożliwiają określenie dowolnego konta użytkownika, w ramach którego jest uruchamiana cała sesja programu PowerShell. Konfiguracje sesji korzystające z stałych kont Uruchom jako (z parametrem) nie są uwzględniane przez usługę -RunAsCredential JEA. Definicje ról nie działają już zgodnie z oczekiwaniami. Każdy użytkownik autoryzowany do uzyskiwania dostępu do punktu końcowego ma przypisaną tę samą rolę.

Nie należy używać elementu RunAsCredential w punkcie końcowym JEA, ponieważ trudno jest śledzić akcje z powrotem do określonych użytkowników i nie obsługuje mapowania użytkowników na role.

Lista ACL punktu końcowego usługi WinRM

Podobnie jak w przypadku zwykłych punktów końcowych komunikacji zdalnej programu PowerShell, każdy punkt końcowy JEA ma oddzielną listę kontroli dostępu (ACL), która kontroluje, kto może uwierzytelniać się za pomocą punktu końcowego JEA. W przypadku nieprawidłowej konfiguracji zaufani użytkownicy mogą nie mieć dostępu do punktu końcowego JEA, a niezaufani użytkownicy mogą mieć dostęp. Lista ACL usługi WinRM nie ma wpływu na mapowanie użytkowników na role JEA. Mapowanie jest kontrolowane przez pole RoleDefinitions w pliku konfiguracji sesji używanym do rejestrowania punktu końcowego.

Domyślnie, gdy punkt końcowy JEA ma wiele funkcji roli, lista ACL usługi WinRM jest skonfigurowana tak, aby zezwalała na dostęp wszystkim zamapowanym użytkownikom. Na przykład sesja JEA skonfigurowana przy użyciu poniższych poleceń zapewnia pełny dostęp do CONTOSO\JEA_Lev1 poleceń i 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'

Uprawnienia użytkownika można przeprowadzić za pomocą polecenia cmdlet Get-PSSessionConfiguration .

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

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

Aby zmienić, którzy użytkownicy mają dostęp, uruchom polecenie w Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI celu wyświetlenia interakcyjnego monitu lub Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> zaktualizowania uprawnień. Użytkownicy potrzebują co najmniej uprawnień Invoke , aby uzyskać dostęp do punktu końcowego JEA.

Istnieje możliwość utworzenia punktu końcowego JEA, który nie mapuje zdefiniowanej roli na każdego użytkownika, który ma dostęp. Ci użytkownicy mogą rozpocząć sesję JEA, ale mają dostęp tylko do domyślnych poleceń cmdlet. Możesz przeprowadzić inspekcję uprawnień użytkownika w punkcie końcowym JEA, uruchamiając polecenie Get-PSSessionCapability. Aby uzyskać więcej informacji, zobacz Auditing and Reporting on JEA (Inspekcja i raportowanie dotyczące serwera JEA).

Role z najmniejszymi uprawnieniami

Podczas projektowania ról JEA należy pamiętać, że wirtualne i zarządzane przez grupy konta usług działające w tle mogą mieć nieograniczony dostęp do maszyny lokalnej. Funkcje roli JEA pomagają ograniczyć polecenia i aplikacje, które mogą być uruchamiane w tym uprzywilejowanym kontekście. Nieprawidłowo zaprojektowane role mogą zezwalać na niebezpieczne polecenia, które mogą zezwalać użytkownikowi na zerwanie granic JEA lub uzyskiwanie dostępu do poufnych informacji.

Rozważmy na przykład następujący wpis możliwości roli:

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

Ta funkcja roli umożliwia użytkownikom uruchamianie dowolnego polecenia cmdlet programu PowerShell z funkcją procesu noun z modułu Microsoft.PowerShell.Management. Użytkownicy mogą potrzebować dostępu do poleceń cmdlet, takich jak Get-Process wyświetlanie aplikacji uruchomionych w systemie i Stop-Process zabijanie aplikacji, które nie odpowiadają. Jednak ten wpis umożliwia Start-Processrównież funkcję , która może służyć do uruchamiania dowolnego programu z pełnymi uprawnieniami administratora. Program nie musi być zainstalowany lokalnie w systemie. Połączony użytkownik może uruchomić program z udziału plików, który daje użytkownikowi uprawnienia administratora lokalnego, uruchamia złośliwe oprogramowanie i nie tylko.

Bardziej bezpieczna wersja tej samej funkcji roli wyglądałaby następująco:

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

Unikaj używania symboli wieloznacznych w funkcjach roli. Pamiętaj, aby regularnie przeprowadzać inspekcję obowiązujących uprawnień użytkowników, aby zobaczyć, które polecenia są dostępne dla użytkownika. Aby uzyskać więcej informacji, zobacz sekcję Sprawdzanie obowiązujących praw w artykule Auditing and Reporting on JEA (Inspekcja i raportowanie w usłudze JEA ).

Zalecenia dotyczące najlepszych rozwiązań

Poniżej przedstawiono zalecenia dotyczące najlepszych rozwiązań w celu zapewnienia bezpieczeństwa punktów końcowych JEA:

Ograniczanie użycia i możliwości dostawców programu PowerShell

Zapoznaj się ze sposobem użycia dozwolonych dostawców, aby upewnić się, że nie tworzysz luk w zabezpieczeniach w skonfigurowanej sesji.

Ostrzeżenie

Nie zezwalaj na dostawcę systemu plików. Jeśli użytkownicy mogą zapisywać dane w dowolnej części systemu plików, można całkowicie pominąć zabezpieczenia.

Nie zezwalaj na dostawcę certyfikatów. Po włączeniu dostawcy użytkownik może uzyskać dostęp do przechowywanych kluczy prywatnych.

Nie zezwalaj na polecenia, które mogą tworzyć nowe przestrzenie uruchomieniowe.

Ostrzeżenie

Polecenia *-Job cmdlet mogą tworzyć nowe przestrzenie uruchomieniowe bez ograniczeń.

Nie zezwalaj na polecenie Trace-Command cmdlet.

Ostrzeżenie

Użycie Trace-Command powoduje przeniesienie wszystkich śledzonych poleceń do sesji.

Nie twórz własnych implementacji serwera proxy dla poleceń z ograniczeniami.

Program PowerShell ma zestaw poleceń serwera proxy dla scenariuszy poleceń z ograniczeniami. Te polecenia serwera proxy zapewniają, że parametry wejściowe nie mogą naruszyć bezpieczeństwa sesji. Następujące polecenia mają ograniczone serwery proxy:

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

Jeśli tworzysz własną implementację tych poleceń, możesz przypadkowo zezwolić użytkownikom na uruchamianie kodu zabronionego przez polecenia serwera proxy JEA.

Usługa JEA nie chroni przed administratorami

Jedną z podstawowych zasad jea jest umożliwienie administratorom wykonywania niektórych zadań administracyjnych. Usługa JEA nie chroni przed użytkownikami, którzy mają już uprawnienia administratora. Użytkownicy, którzy należą do Administracja domeny, lokalnych Administracja istratorów lub innych wysoce uprzywilejowanych grup, mogą obejść zabezpieczenia JEA w inny sposób. Mogą na przykład zalogować się przy użyciu protokołu RDP, użyć zdalnych konsoli MMC lub nawiązać połączenie z nieskonfikowanymi punktami końcowymi programu PowerShell. Ponadto administrator lokalny w systemie może modyfikować konfiguracje JEA, aby dodać więcej użytkowników lub zmienić możliwość roli, aby rozszerzyć zakres tego, co użytkownik może zrobić w sesji JEA. Ważne jest, aby ocenić rozszerzone uprawnienia użytkowników JEA, aby sprawdzić, czy istnieją inne sposoby uzyskania uprzywilejowanego dostępu do systemu.

Oprócz korzystania z narzędzia JEA do regularnej konserwacji codziennego, często jest dostępny system zarządzania dostępem uprzywilejowanym just in time. Te systemy pozwalają wyznaczonym użytkownikom tymczasowo zostać administratorem lokalnym dopiero po zakończeniu przepływu pracy, który dokumentuje korzystanie z tych uprawnień.