Dostęp just-in-time — jak wyeliminować stałe uprawnienia w przedsiębiorstwie
Większość incydentów bezpieczeństwa w przedsiębiorstwach obejmujących dostęp uprzywilejowany ma wspólną główną przyczynę: skompromitowane konto miało dostęp, którego nie potrzebowało, do systemów, których nie tknęło od tygodni, z poświadczeniami ważnymi od miesięcy. Atakujący nie eskalował uprawnień — uprawnienia już tam były, stałe, czekające. To jest problem stałych uprawnień, a dostęp just-in-time jest zaprojektowany właśnie do zamknięcia tej luki.
Czym jest dostęp just-in-time — i jak różni się od tradycyjnego PAM
Tradycyjny PAM działa w modelu sejf i pobieranie. Uprzywilejowane poświadczenia są przechowywane w sejfie. Gdy administrator systemu potrzebuje dostępu, pobiera poświadczenia, łączy się z systemem docelowym i zwraca poświadczenia po zakończeniu. To jest lepsze niż współdzielone arkusze kalkulacyjne i karteczki samoprzylepne, ale nadal ma fundamentalny strukturalny problem: samo konto uprzywilejowane istnieje na stałe w systemie docelowym. Konto Administrator na serwerze Windows, konto root na hoście Linux, konto sa w bazie danych — te konta są zawsze obecne, zawsze włączone, zawsze celem.
Dostęp just-in-time (JIT) przyjmuje inne podejście: wyeliminuj stałe konto całkowicie lub przynajmniej zapewnij, że konto jest wyłączone, a poświadczenia rotowane bezpośrednio przed i po każdym użyciu. Dostęp jest przydzielany na żądanie dla konkretnego użytkownika, konkretnego celu i konkretnego okna czasowego. Gdy okno wygasa, dostęp jest automatycznie odwoływany — nie zwracany do sejfu, ale usuwany.
Zasada zerowych stałych uprawnień (ZSP) rozszerza to dalej: żadne konto uprzywilejowane nie powinno mieć trwałego dostępu do żadnego systemu produkcyjnego. Każda uprzywilejowana sesja to tymczasowe przyznanie z zdefiniowanym początkiem, zdefiniowanym końcem i kompletnym dziennikiem audytu. Gdy żadna sesja nie jest aktywna, żaden dostęp uprzywilejowany nie istnieje.
Praktyczna różnica między tradycyjnym PAM a JIT/ZSP:
- Tradycyjny PAM: Grupa
Domain Adminsma 15 członków. Poświadczenia są w sejfie. Członkowie pobierają poświadczenia gdy są potrzebne. Konta istnieją 24/7 na każdym serwerze dołączonym do domeny. - JIT PAM: Brak stałego członkostwa w
Domain Admins. Gdy administrator systemu potrzebuje podwyższonego dostępu, składa żądanie zakrojone na konkretny serwer i konkretny czas trwania. System przydziela dostęp, tworzy sesję, nagrywa ją i odbiera po zakończeniu okna czasowego.
Powierzchnia ataku w modelu tradycyjnym to każdy moment, gdy konto istnieje, względem każdego systemu, do którego może dotrzeć. Powierzchnia ataku w modelu JIT to czas trwania zatwierdzonej sesji, względem konkretnego zatwierdzonego celu.
Przed JIT vs po JIT — konkretny scenariusz
Przed JIT: Starszy administrator systemu w firmie liczącej 500 osób pracuje w zespole od czterech lat. Jest stałym członkiem grupy Domain Admins i ma stały dostęp administracyjny RDP do około 200 serwerów — deweloperskich, stagingowych i produkcyjnych. Aktywnie używa tego dostępu do może 20 serwerów regularnie. Pozostałe 180 to infrastruktura, którą skonfigurował podczas migracji i nie tknął od tamtej pory. Jego poświadczenia są w korporacyjnym SSO, jego konto nigdy nie było przeglądane pod kątem redukcji zakresu, a jego dostęp nie zmienił się od chwili dołączenia.
Gdy jego laptop zostaje przejęty w ukierunkowanym ataku phishingowym, atakujący ma natychmiastowy, trwały, niekwestionowany dostęp do wszystkich 200 serwerów. Zasięg wybuchu to cała infrastruktura.
Po JIT: Ten sam administrator nie ma stałego dostępu uprzywilejowanego. Gdy potrzebuje wykonać konserwację konkretnego serwera produkcyjnego, składa żądanie: „Potrzebuję dostępu administratora RDP do prod-db-03 na 4 godziny, aby zastosować kwartalną łatkę". Żądanie jest przeglądane przez jego menedżera i członka zespołu bezpieczeństwa przez przepływ zatwierdzania w Slacku. Po zatwierdzeniu system przydziela ograniczone czasowo poświadczenie zakrojone na ten konkretny serwer. Sesja jest automatycznie nagrywana od początku do końca. Po 4 godzinach dostęp jest odwoływany, a poświadczenie rotowane.
Gdy jego laptop zostaje przejęty, atakujący ma dostęp do jakichkolwiek aktywnych sesji, które istnieją w tym momencie. Jeśli żadna sesja nie jest aktualnie zatwierdzona i aktywna, atakujący nie ma dostępu uprzywilejowanego do żadnego systemu produkcyjnego. Zasięg wybuchu jest ograniczony przez to, co zostało zatwierdzone i było aktywne w momencie kompromitacji — nie całą historyczną powierzchnię dostępową kariery administratora.
Dostęp JIT i zgodność — jak ZSP mapuje się do NIS2, SOC 2 i ISO 27001
Dostęp JIT i zerowe stałe uprawnienia to nie tylko dobra praktyka bezpieczeństwa — są coraz bardziej wyraźnymi wymaganiami w frameworkach compliance, które firmy z CEE i Europy muszą spełniać.
NIS2 art. 21 — zasada minimalnych uprawnień: NIS2 wymaga, aby podmioty kluczowe wdrożyły kontrolę dostępu opartą na zasadach minimalnych uprawnień. „Minimalne uprawnienia" w kontekście NIS2 oznacza, że dostęp powinien być przyznawany tylko w zakresie niezbędnym do wykonania konkretnego zadania. Stały dostęp administracyjny do 200 serwerów nie spełnia tego testu z definicji — administrator, który regularnie używa 20 z tych serwerów, ma stały dostęp do 180, których nie potrzebuje. Dostęp JIT strukturalnie wymusza zasadę minimalnych uprawnień: dostęp jest zawsze zakrojony na konkretny system i okno czasowe rzeczywistej potrzeby.
SOC 2 CC6.3 — odwołanie dostępu: Kryteria Usług Zaufania SOC 2 wymagają, aby dostęp był usuwany niezwłocznie, gdy nie jest już wymagany. CC6.3 konkretnie obejmuje odwołanie dostępu dla zakończonych pracowników, zmian ról i zakończeń projektów. Dostęp JIT automatycznie spełnia CC6.3: dostęp wygasa na końcu zatwierdzonego okna czasowego bez żadnego ręcznego kroku odwołania. Pytanie audytora — „jak zapewniasz, że dostęp jest usuwany, gdy nie jest już potrzebny?" — ma deterministyczną odpowiedź: „Wygasa automatycznie; oto dziennik audytu każdego wygaśnięcia sesji."
ISO 27001 Załącznik A.9.2 — przydzielanie dostępu: ISO 27001 A.9.2.2 wymaga formalnego procesu przydzielania dostępu, a A.9.2.3 wymaga, aby prawa dostępu uprzywilejowanego były przydzielane na zasadzie „need-to-use". „Need-to-use" to język ISO 27001 dla zasady minimalnych uprawnień i mapuje bezpośrednio do JIT: dostęp powinien istnieć gdy jest potrzebny i nie istnieć gdy nie jest potrzebny. A.9.2.5 wymaga okresowego przeglądu praw dostępu użytkowników — z dostępem JIT, przegląd jest ciągły, a nie okresowy, ponieważ dostęp jest ponownie przyznawany od zera dla każdej sesji.
Argument compliance dla JIT jest prosty: stałe uprawnienia są strukturalnie niezgodne z zasadą minimalnych uprawnień, której wymagają NIS2, SOC 2 CC6.3 i ISO 27001 A.9.2. JIT to wzorzec implementacyjny, który sprawia, że zasada minimalnych uprawnień jest operacyjnie wykonalna w skali.
Jak VaultPAM implementuje dostęp JIT
VaultPAM implementuje dostęp JIT przez cztery zintegrowane mechanizmy:
Przepływy zatwierdzania: Gdy użytkownik żąda dostępu uprzywilejowanego do systemu docelowego, VaultPAM kieruje żądanie do odpowiedniego zatwierdzającego — menedżera, zespołu bezpieczeństwa lub obu, w zależności od poziomu dostępu i wrażliwości systemu. Zatwierdzenia można wykonać przez interfejs webowy VaultPAM lub zintegrowane kanały powiadomień. Żądanie zawiera system docelowy, żądany czas trwania i uzasadnienie, dając zatwierdzającemu kontekst do podjęcia świadomej decyzji.
Sesje ograniczone czasowo: Każde zatwierdzone przyznanie dostępu zawiera twardy czas wygaśnięcia. Okno sesji jest ustawiane w momencie zatwierdzania — 1 godzina, 4 godziny, 8 godzin lub niestandardowy czas do maksimum polityki. Gdy okno sesji wygasa, VaultPAM automatycznie odbiera dostęp. Nie ma ręcznego kroku, e-maila z przypomnieniem, zależności od wylogowania przez użytkownika. Dostęp po prostu przestaje istnieć.
Automatyczne wygasanie i rotacja poświadczeń: Dla sesji RDP i SSH, VaultPAM przydziela poświadczenie specyficzne dla sesji na początku zatwierdzonego okna i rotuje je przy wygaśnięciu. Poświadczenie, które istniało dla zatwierdzonej sesji, nie działa po wygaśnięciu. Atakujący, który przechwyci poświadczenie w trakcie sesji, nie może go ponownie użyć po zamknięciu okna.
Dziennik audytu: Każde żądanie JIT — złożenie, zatwierdzenie lub odmowa, rozpoczęcie sesji, czas trwania sesji, nagranie sesji i wygaśnięcie — jest rejestrowane w niezmiennym dzienniku audytu VaultPAM. Dziennik audytu zawiera tożsamość zatwierdzającego, znacznik czasu zatwierdzenia, tekst uzasadnienia i kompletne nagranie aktywności sesji. To jest pakiet dowodów, który spełnia żądania audytowe NIS2, próbkowanie audytorów SOC 2 i wyrywkowe kontrole ISO 27001.
Zobacz dostęp JIT VaultPAM w akcji — wyeliminuj stałe uprawnienia w swoim środowisku