Bezpieczne zdalne zarządzanie programem PowerShell z funkcją Just-Enough-Administration (JEA)

Korzystanie z funkcji zdalnego sterowania za pomocą programu PowerShell stało się niemal niezbędne w każdym środowisku Windows Nowoczesne, ale udzielanie zdalnego dostępu bez kontroli to jak zostawianie kluczy do centrum danych na stole. Tu właśnie zaczyna się gra. Just-Enough-Administration (JEA), warstwa zabezpieczeń umożliwiająca delegowanie zadań bez konieczności oddawania uprawnień administratora na prawo i lewo.

Dzięki JEA możesz skonfigurować bardzo ograniczoną liczbę punktów dostępu zdalnego, w których konkretni użytkownicy będą mogli uruchamiać tylko polecenia które autoryzowałeś na kontach z większymi uprawnieniami, ale nie znając prawdziwych kwalifikacji ani nie mogąc odejść od scenariuszaWszystko to zostało zapisane w transkryptach i dzienniki szczegółowe, które umożliwiają sprawdzenie, kto co zrobił, kiedy i skąd.

Czym jest Just-Enough-Administration (JEA) i dlaczego jest to takie ważne?

Just-Enough-Administration to technologia bezpieczeństwa oparta na programie PowerShell który implementuje model delegowanego administrowania z minimalnymi wymaganymi uprawnieniami. W praktyce JEA umożliwia udostępnianie zdalnych punktów końcowych, gdzie dostępny jest tylko zamknięty zestaw poleceń cmdlet, funkcji, skryptów i poleceń zewnętrznych zdefiniowanych przez użytkownika.

Dzięki takiemu podejściu możesz drastycznie zmniejszyć liczbę kont z podwyższonymi uprawnieniami Na swoich serwerach możesz korzystać z kont wirtualnych lub grupowo zarządzanych kont usług (gMSA), które wykonują uprzywilejowane działania w imieniu użytkowników standardowych. Użytkownik loguje się przy użyciu swoich standardowych danych logowania i, za pośrednictwem sesji JEA, uruchamia polecenia, które są wykonywane w tle z wyższymi uprawnieniami.

Kolejnym kluczowym filarem JEA jest zdolność do precyzyjnie zdefiniować, co może zrobić każda rolaPliki możliwości ról definiują, które polecenia cmdlet, funkcje niestandardowe, polecenia zewnętrzne lub dostawcy programu PowerShell są widoczne. Reszta po prostu nie istnieje dla użytkownika: nie może on improwizować skryptów, swobodnie poruszać się po systemie plików ani uzyskiwać dostępu do usług lub procesów, które nie zostały określone.

Co więcej, wszystkie sesje JEA można skonfigurować tak, aby generowały pełne transkrypcje i wydarzenia audytoweRejestrowanie poleceń, parametrów, danych wyjściowych, błędów, tożsamości użytkowników i czasów wykonania nie tylko pomaga spełnić wymogi regulacyjne, ale jest również nieocenione podczas badania incydentów bezpieczeństwa lub awarii operacyjnych.

Ryzyko związane z kontami uprzywilejowanymi i sposoby jego ograniczania przez JEA

Konta administratorów lokalnych, domeny lub aplikacji z podwyższonymi uprawnieniami oznaczają jeden z najpoważniejszych wektorów ryzyka w każdej organizacjiJeśli atakujący zdobędzie takie dane uwierzytelniające, będzie mógł poruszać się po sieci, podwyższać uprawnienia i uzyskiwać dostęp do krytycznych danych, kluczowych usług, a nawet wyłączać całe systemy.

Usuwanie uprawnień nie zawsze jest proste. Klasycznym przykładem jest serwer obsługujący zarówno DNS, jak i kontroler domeny Active DirectoryZespół DNS potrzebuje uprawnień administratora lokalnego, aby rozwiązywać problemy z usługami DNS, ale dodanie ich do grupy „Administratorzy domeny” skutecznie daje im kontrolę nad całym lasem i dostęp do wszystkich zasobów na tej maszynie. To klasyczny przykład poświęcenia bezpieczeństwa na rzecz wygody operacyjnej.

JEA rozwiązuje ten dylemat, ściśle stosując zasada najmniejszych uprawnieńZamiast mianować administratorów DNS administratorami domeny, można utworzyć dedykowany punkt końcowy DNS JEA, który udostępnia tylko polecenia cmdlet potrzebne do czyszczenia pamięci podręcznej, ponownego uruchamiania usługi, przeglądania logów i podobnych zadań. Dzięki temu operator może wykonywać swoje zadania bez konieczności przeglądania Active Directory, nawigacji po systemie plików, uruchamiania losowych skryptów lub uruchamiania potencjalnie niebezpiecznych narzędzi.

Podczas konfigurowania sesji JEA do użycia konta wirtualne z uprawnieniami tymczasowymiTen ruch jest jeszcze ciekawszy: użytkownik łączy się z nieuprawnionymi uprawnieniami i w ramach tej sesji może wykonywać zadania, które normalnie wymagają uprawnień administratora. Pozwala to na usunięcie wielu użytkowników z lokalnych lub domenowych grup administratorów, co pozwala na utrzymanie operacji przy jednoczesnym znacznym wzmocnieniu powierzchni ataku.

Koncepcje bezpieczeństwa leżące u podstaw JEA

JEA nie wzięła się z niczego: Opiera się na kilku sprawdzonych zasadach i modelach bezpieczeństwa. co zapewnia jej spójność i solidność. Pierwszą z nich jest wspomniana zasada najmniejszych uprawnień, która stanowi, że zarówno użytkownicy, jak i procesy powinni posiadać wyłącznie uprawnienia niezbędne do wykonywania swoich funkcji.

Drugim ważnym filarem jest model Kontrola dostępu oparta na rolach (RBAC)JEA implementuje RBAC za pomocą plików uprawnień ról, w których definiuje się, co dana rola może robić w ramach sesji zdalnej. Na przykład rola pomocy technicznej może wyświetlać listę usług, wyświetlać zdarzenia i restartować określoną usługę, podczas gdy rola administratora SQL Server może wykonywać tylko polecenia cmdlet związane z... Bazy danych i trochę więcej.

La Podstawą techniczną JEA jest program PowerShell i jego infrastruktura zdalnaPowerShell zapewnia język, polecenia cmdlet i warstwę komunikacji zdalnej (WinRM/WS-Management), a JEA dodaje na wierzch system ograniczonych punktów końcowych, kont wirtualnych i szczegółową kontrolę nad dostępnością poleceń.

Inną ważną koncepcją jest ograniczona administracja, podobny do a Przypisany dostęp w trybie kiosku Windows 11Zamiast dawać operatorowi pełną powłokę, JEA konstruuje sesję, w której język skryptowy jest ograniczony (domyślnie NoLanguage), tworzenie nowych funkcji lub zmiennych jest zablokowane, pętle i instrukcje warunkowe są zabronione, a uruchamiany jest tylko zatwierdzony zestaw poleceń cmdlet. To poważnie ogranicza możliwości atakującego, któremu uda się uzyskać dostęp do tej sesji.

Główne komponenty: pliki .psrc i .pssc

Podstawą każdego wdrożenia JEA są dwa typy plików: pliki możliwości roli (.psrc) i pliki konfiguracji sesji (.pssc)Razem przekształcają powłokę ogólnego przeznaczenia w idealnie dostosowany punkt końcowy dla konkretnych użytkowników.

W pliku możliwości roli definiujesz dokładnie, które polecenia są dostępne dla roliDo najważniejszych elementów zaliczamy:

• Widoczne polecenia cmdlet:lista dozwolonych poleceń cmdlet, umożliwiająca nawet ograniczenie parametrów.
• Widoczne funkcje: funkcje niestandardowe ładowane w sesji.
• Widoczne polecenia zewnętrzne:konkretne zewnętrzne pliki wykonywalne, do których uzyskuje się dostęp.
• Widoczni dostawcy:Dostawcy programu PowerShell (na przykład FileSystem lub Registry) widoczni w sesji.

Z drugiej strony pliki konfiguracji sesji .pssc Opisują punkt końcowy JEA jako taki i łączą go z rolami.Tutaj deklarowane są następujące elementy:

• Definicje ról:mapowanie użytkowników lub grup zabezpieczeń do możliwości ról.
• Typ sesji: gdzie „RestrictedRemoteServer” jest zwykle ustawiany w celu wzmocnienia sesji.
• Katalog transkryptów:folder, w którym przechowywane są transkrypcje każdej sesji.
• Uruchom jako konto wirtualne i powiązane opcje, takie jak to, czy konto wirtualne ma zostać dodane do określonych grup.

JEA materializuje się w formie Punkty końcowe zdalnego dostępu PowerShell zarejestrowane w systemieTe punkty końcowe są tworzone i włączane za pomocą poleceń cmdlet, takich jak Nowy plik konfiguracji sesji PS, Rejestracja‑PSSessionConfiguration lub narzędzia graficzne, takie jak JEA Helper Tool, które ułatwiają generowanie plików .pssc i .psrc bez konieczności zmagania się ze składnią.

Cykl życia sesji JEA

Podczas konfigurowania kompletnego środowiska JEA proces zazwyczaj przebiega według szeregu logicznych kroków, które Przekształcają otwarty system zdalnego sterowania w system ściśle kontrolowany.Typowa sekwencja jest następująca:

Najpierw tworzysz grupa bezpieczeństwa lub kilka grup reprezentujące role, które chcesz delegować (na przykład HelpdeskDNS, operatorzy sieci Web, operatorzy SQL). Korzystanie z grup nie jest obowiązkowe, ale znacznie upraszcza administrację w miarę rozwoju środowiska.

Następnie przygotowuje się jeden lub więcej pliki możliwości roli .psrc Lista zawiera dozwolone akcje: polecenia cmdlet, funkcje, skrypty, polecenia zewnętrzne, aliasy, dostawców oraz dodatkowe ograniczenia (konkretne parametry, dozwolone ścieżki itp.). Na przykład możesz zezwolić na wszystkie polecenia cmdlet rozpoczynające się od Get-, ograniczyć działanie Restart-Service do usługi buforowania i autoryzować tylko dostawcę systemu plików.

Generowane jest następujące plik konfiguracji sesji .pssc Używając New-PSSessionConfigurationFile. Definiuje on opcje takie jak SessionType = RestrictedRemoteServer, ścieżkę TranscriptDirectory, informację o tym, czy używane są konta wirtualne, oraz blok RoleDefinitions, który łączy grupy z możliwościami roli, na przykład 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Po przygotowaniu pliku .pssc punkt końcowy jest rejestrowany za pomocą Register‑PSSessionConfiguration -Name JEASession Nazwa -Path Ścieżka\Plik.psscOd tego momentu, jeśli dostępne konfiguracje zostaną wyświetlone za pomocą polecenia Get-PSSessionConfiguration, nowy punkt połączenia będzie widoczny jako gotowy do odbierania połączeń.

Użytkownicy łączą się z tym punktem końcowym ze swoich komputerów za pomocą Enter‑PSSession -ComputerName Server -ConfigurationName JEASession Name lub za pomocą New-PSSession, a następnie Invoke-Command. Po wejściu sesja automatycznie zastosuje ograniczenia zdefiniowane w uprawnieniach przypisanych do roli użytkownika.

Podczas sesji Zdalna obsługa programu PowerShell wykorzystuje usługę WinRM z szyfrowanymi kanałamiZintegrowane uwierzytelnianie (zazwyczaj Kerberos w domenie) i reguły zapory zdefiniowane dla usługi. W związku z tym, jeśli opcja RunAsVirtualAccount jest włączona, tworzone jest tymczasowe konto wirtualne, dodawane do niezbędnych grup i niszczone po zakończeniu sesji.

Na koniec, po zamknięciu sesji JEA, Zapisy protokołów audytu i zdarzeń są zapisywane Logi te pozostawiają wyraźny ślad wykonanych poleceń, wyników i kontekstu użytkownika. Można je następnie wysłać do systemu SIEM lub zestawić w nim w celu generowania alertów i dalszej analizy.

Zdalna obsługa programu PowerShell, kontrola dostępu i wzmacnianie zabezpieczeń

Zdalna obsługa programu PowerShell obsługiwana przez usługę Zdalne zarządzanie systemem Windows (WinRM) Protokół WS-Management umożliwia scentralizowane wykonywanie poleceń i skryptów na komputerach zdalnych. Jest to potężne narzędzie do automatyzacji, masowego zarządzania serwerami, debugowania i zdalnego wsparcia.

Domyślna, lokalni administratorzy i członkowie grupy użytkowników zdalnego zarządzania Mogą korzystać ze standardowych punktów końcowych programu PowerShell. W wielu środowiskach ta możliwość została wykorzystana, aby umożliwić użytkownikom bez uprawnień administratora zdalne uruchamianie zadań, co samo w sobie nie jest niebezpieczne, ale jeśli nie jest odpowiednio kontrolowane, otwiera poważne możliwości nadużyć.

Aby wzmocnić postawę bezpieczeństwa, wspólna strategia obejmuje Ogranicz zdalny dostęp do programu PowerShell wyłącznie do kont administratorów. Albo, jeszcze lepiej, połączyć to ograniczenie z punktami końcowymi JEA, które przyznają określonym użytkownikom tylko ściśle niezbędny dostęp. Można to osiągnąć poprzez:

• Obiekty GPO definiujące, które grupy mogą używać usługi WinRM i domyślne punkty końcowe.
• Reguły zapory sieciowej zezwalające na usługę WinRM wyłącznie z podsieci lub komputerów zarządzających.
• Usuwanie grupy użytkowników zarządzania zdalnego z list kontroli dostępu standardowych punktów końcowych.

Dodatkowo możesz wybrać Całkowicie zablokuj program PowerShell dla użytkowników niebędących administratorami korzystając z rozwiązań takich jak AppLocker. W ten sposób uniemożliwiasz standardowemu użytkownikowi uruchamianie złośliwych skryptów lokalnie, ale jednocześnie pozwalasz kontom uprzywilejowanym na korzystanie z programu PowerShell do zarządzania i automatyzacji zadań.

JEA a inne metody ograniczeń programu PowerShell

Istnieje kilka sposobów ograniczenia tego, co użytkownicy mogą robić za pomocą zdalnego dostępu do programu PowerShell. JEA jest cieńszą i bardziej elastyczną opcją w zakresie obejmującym szersze podejścia, takie jak:

Z jednej strony wykorzystanie GPO do kontrolowania, kto wchodzi do domyślnych punktów końcowych programu PowerShellDostęp do programu Microsoft PowerShell można ograniczyć do administratorów, a nawet do wszystkich użytkowników, wymuszając korzystanie z określonych punktów końcowych. Jest to przydatne do ograniczania dostępu metodą „brute force”, ale nie rozwiązuje problemu granularności: każdy, kto uzyska dostęp, może zrobić praktycznie wszystko.

Z drugiej strony istnieją narzędzia do kontroli aplikacji, takie jak Zasady ograniczeń aplikacji lub oprogramowaniaTe metody pozwalają uniemożliwić uruchamianie plików PowerShell.exe lub pwsh.exe użytkownikom standardowym, według ścieżki, wydawcy lub skrótu. To podejście jest przydatne do wzmacniania zabezpieczeń stacji roboczych i uniemożliwiania użytkownikom uruchamiania programu PowerShell, ale wiąże się z ograniczeniami, gdy chcemy, aby ktoś wykonywał ograniczone zadania administracyjne z poziomu swojego konta użytkownika.

Inną opcją są Ograniczone punkty końcowe bez osiągnięcia pełnego JEAMożna tworzyć niestandardowe konfiguracje sesji, które ograniczają liczbę poleceń cmdlet, funkcji i modułów, ale bez tak dużego polegania na modelu ról, kontach wirtualnych czy ustrukturyzowanym RBAC, które zapewnia JEA. To rozwiązanie pośrednie, odpowiednie dla prostych scenariuszy, ale mniej skalowalne w dużych środowiskach.

JEA łączy w sobie to, co najlepsze z kilku światów: ścisłe ograniczenie poleceń, RBAC, kontrolowane wykonywanie z podwyższonymi uprawnieniami i kompleksowe rejestrowanieDzięki temu jest to zalecane rozwiązanie, gdy trzeba umożliwić użytkownikom niebędącym administratorami zdalne korzystanie z programu PowerShell, nie udostępniając im jednak pełnego środowiska zarządzania.

Zaawansowane funkcje: uruchom jako inne konto i zaloguj się

Jedną z najpotężniejszych możliwości JEA jest wykonywać polecenia z innego, bardziej uprzywilejowanego konta bez ujawniania swoich danych uwierzytelniającychRozwiązuje to typowy problem polegający na tym, że „podam ci hasło do tej usługi, żebyś mógł zrobić X”, którego nigdy nie zmieniamy, co w efekcie niesie ze sobą ogromne ryzyko.

Scenariusze domenowe są powszechnie używane Konta usług zarządzane grupowo (gMSA) Umożliwia to punktom końcowym JEA wykonywanie działań w ramach centralnie zarządzanej tożsamości usługi, z automatyczną rotacją haseł i bez ujawniania sekretu przez operatora. W innych przypadkach używane są tymczasowe konta wirtualne, lokalne dla danej maszyny, tworzone ad hoc w momencie połączenia użytkownika i usuwane po zakończeniu sesji.

Z perspektywy audytu każdą sesję JEA można skonfigurować tak, aby: generuj transkrypty programu PowerShell i rozbudowane wpisy w dzienniku zdarzeńTypowo gromadzone są następujące informacje:

• Pełna historia wprowadzonych poleceń i parametrów.
• Wygenerowane dane wyjściowe i komunikaty o błędach.
• Znak czasu rozpoczęcia i zakończenia sesji oraz jej czas trwania.
• Tożsamość zalogowanego użytkownika i przypisana rola/uprawnienia.

Jeżeli połączysz te ślady z funkcjonalnościami Rejestrowanie modułu PowerShell i Scenariusz Blokuj rejestrowanie za pomocą GPOWysyłając logi do systemu SIEM, zyskujesz kompleksowy wgląd w to, co dzieje się na punktach końcowych zarządzania. Jest to kluczowe zarówno dla zachowania zgodności (audyty SOX, ISO 27001 itp.), jak i wykrywania incydentów i reagowania na nie.

Typowe przypadki użycia JEA w rzeczywistych środowiskach

JEA świeci szczególnie wtedy, gdy tego potrzebujesz Delegowanie bardzo specyficznych zadań zespołom, które nie powinny być administratoramiDo bardzo powszechnych przykładów w praktyce należą:

W obszarze wsparcia technicznego możesz powierzyć zadania technikom najwyższej klasy Dostęp JEA umożliwiający ponowne uruchomienie usług, przeglądanie dzienników zdarzeń i sprawdzanie stanu procesów na serwerach, ale bez możliwości instalowania oprogramowania, modyfikowania krytycznych konfiguracji ani dostępu do Active Directory. Typowa rola helpdesku może obejmować polecenia cmdlet, takie jak Get-Service, Restart-Service dla określonych usług, Get-EventLog w trybie tylko do odczytu oraz niektóre polecenia cmdlet do diagnostyki sieci.

W zespołach operacyjnych lub programistycznych możesz skonfigurować role skupione na określonych zadaniach, takich jak administracja usługą IIS lub konserwacja witryny internetowejNa przykład można zezwolić na dostęp do poleceń cmdlet zarządzania pulą aplikacji, ponownych uruchomień witryn, przeszukiwania dzienników z ograniczonego katalogu i zarządzania certyfikatami dla określonych usług, wykluczając jednocześnie możliwość ponownego uruchomienia całego serwera lub modyfikowania zasad bezpieczeństwa.

W środowiskach hybrydowych i chmurowych JEA jest często wykorzystywana do: ograniczyć to, co każdy zespół może zrobić maszyny wirtualne, magazynowanie lub sieciMożesz udostępnić punkty końcowe umożliwiające zarządzanie wyłącznie maszynami wirtualnymi danego działu, modyfikowanie reguł zapory określonego segmentu lub zarządzanie określonym zestawem kont usług, dzięki czemu dostęp będzie oddzielony od reszty infrastruktury.

Jednocześnie JEA bardzo dobrze wpisuje się w Strategie zarządzania dostępem uprzywilejowanym (PAM)gdzie sesje uprzywilejowane są przyznawane tymczasowo, rejestrowane i przypisywane tożsamościom osobistym, co pozwala uniknąć współdzielenia kont i zminimalizować ryzyko związane z każdą czynnością uprzywilejowaną.

Podobne artykuł:

Jak ograniczyć dostęp do folderów współdzielonych w systemie Windows krok po kroku

Isaac

Pisarz z pasją zajmujący się światem bajtów i technologii w ogóle. Uwielbiam dzielić się swoją wiedzą poprzez pisanie i właśnie to będę robić na tym blogu, pokazywać Ci wszystkie najciekawsze rzeczy o gadżetach, oprogramowaniu, sprzęcie, trendach technologicznych i nie tylko. Moim celem jest pomóc Ci poruszać się po cyfrowym świecie w prosty i zabawny sposób.