zarządzanie dostępem uprzywilejowanym (PAM)

Zarządzanie dostępem uprzywilejowanym (privileged access management, PAM) to zbiór zasad, kontroli i narzędzi do bezpiecznego zarządzania kontami o podwyższonych uprawnieniach. MITRE ATT&CK opisuje je jako wdrażanie polityk, kontroli i narzędzi dla kont takich jak SYSTEM, root czy konta administracyjne ^[2]. Użytkownik uprzywilejowany to według NIST osoba upoważniona, a więc obdarzona zaufaniem, do wykonywania funkcji związanych z bezpieczeństwem, których zwykli użytkownicy wykonywać nie mogą ^[1]. Konto uprzywilejowane NIST definiuje jako konto systemowe z uprawnieniami użytkownika uprzywilejowanego ^[8]; nie musi więc należeć do człowieka, może to być konto usługi albo integracji. PAM jest częścią szerszego zarządzania tożsamością i dostępem.

Jak działa

Punktem wyjścia jest zasada najmniejszych uprawnień. Microsoft uzasadnia potrzebę PAM tym, że im mniej osób ma dostęp do ważnych zasobów, tym mniejsza szansa, że dostanie go napastnik albo że uprawniony użytkownik przypadkiem coś uszkodzi ^[3]. Ludzie nadal muszą jednak wykonywać zadania administracyjne, dlatego systemy PAM zamieniają stałe uprawnienia na dostęp przyznawany na czas zadania ^[3].

Microsoft Entra PIM, przykład takiego narzędzia, oferuje m.in. dostęp just-in-time, przydziały ograniczone datami, zatwierdzanie aktywacji ról, wymóg uwierzytelniania wieloskładnikowego przy aktywacji, uzasadnienie, powiadomienia, okresowe przeglądy dostępu i historię audytu ^[3]. Microsoft rozróżnia przydział aktywny, z którego można korzystać od razu, i przydział kwalifikujący, który trzeba najpierw aktywować, np. przez MFA, uzasadnienie albo zgodę zatwierdzającego ^[3]. Oba dają ten sam dostęp; różnica polega na tym, że uprawnienie nie jest czynne cały czas ^[3]. Dostęp just-in-time Microsoft definiuje jako model, w którym użytkownik dostaje tymczasowe uprawnienia, a po ich wygaśnięciu nikt niepowołany nie może z nich skorzystać ^[3]. Cykl takiego dostępu pokazuje schemat poniżej.

RYS. 1Dostęp uprzywilejowany na czas zadania

Składniki

Na PAM składa się kilka mechanizmów, zwykle łączonych w jednym systemie.

• Sejf haseł administracyjnych z regularną zmianą tych haseł; pokrewne jest hasło menedżer haseł i rotacja kluczy.
• Dostęp na czas zadania zamiast stałego członkostwa w grupach administratorów ^[2].
• Rozdzielenie kont: MITRE zaleca, by konta administratora domeny nie służyły do codziennej pracy i by ograniczać powtarzanie tych samych poświadczeń w różnych systemach ^[2].
• Konta usługowe z minimalnymi uprawnieniami, także bez członkostwa w grupach uprzywilejowanych ^[2].
• Kontrola grup lokalnych administratorów: MITRE odradza dodawanie kont domenowych do lokalnych grup administratorów, jeśli nie są ściśle kontrolowane ^[2].
• Punkt wejścia i zapis sesji: administracja przez jeden kontrolowany bastion host i przechowywanie zapisów sesji; zob. retencja logów.

Zagrożenia i skutki

Konto uprzywilejowane to najcenniejszy łup, bo daje od razu to, do czego napastnik zwykle dochodzi przez eskalację uprawnień. MITRE wskazuje, że ograniczanie wspólnych poświadczeń zmniejsza szkody po ich przejęciu i utrudnia lateral movement między systemami ^[2]. Nadużycie może też przyjść od środka, ze strony insidera; Microsoft wymienia obok napastnika uprawnionego użytkownika, który przypadkiem naruszy wrażliwy zasób ^[3].

W WordPressie

WordPress nie ma wbudowanego systemu PAM, ale jego konta dzielą się wyraźnie według uprawnień ^[4].

Na pojedynczej witrynie administrator jest w praktyce superadministratorem: może instalować, edytować i usuwać wtyczki i motywy, tworzyć użytkowników oraz aktualizować rdzeń ^[4]. Każde dodatkowe konto administratora zwiększa więc liczbę dróg do przejęcia strony. Podręcznik utwardzania radzi, by nie nazywać kont administracyjnych admin ani webmaster, bo takie nazwy atakuje się najpierw, i by włączyć drugi składnik logowania ^[5]. Stała DISALLOW_FILE_EDIT odbiera wszystkim użytkownikom uprawnienia edit_themes, edit_plugins i edit_files ^[5], czyli wyłącza edytor plików motywów i wtyczek.

// wp-config.php — administrator nie edytuje kodu z poziomu panelu
define( 'DISALLOW_FILE_EDIT', true );

Hasła aplikacji pojawiły się w WordPressie 5.6 i służą do wywołań API przez programy, a nie do logowania ludzi w panelu ^[6]. Każde można osobno unieważnić, a system zapisuje datę utworzenia oraz datę i adres IP ostatniego użycia ^[6]. W chwili wprowadzenia nie dało się ich zawężać; ograniczanie zakresu zapowiedziano na przyszłe wersje ^[6]. Dla integracji warto więc zakładać osobne konto z możliwie niską rolą, a nie wydawać hasła aplikacji na konto administratora.

Dobre praktyki

• Utrzymywać możliwie mało kont administratorów i regularnie sprawdzać, czy nie pojawiło się nieautoryzowane konto administratora.
• Nadawać uprawnienia na czas zadania i odbierać je po jego zakończeniu ^[3].
• Wymagać MFA przy każdym użyciu uprawnień ^[3] i logować się do serwera kluczem SSH przez SFTP; podręcznik WordPressa zaleca SFTP, jeśli hosting go udostępnia ^[5].
• Oddzielić konto do codziennej pracy od konta administracyjnego ^[2].
• Prowadzić przeglądy dostępu i zachowywać historię audytu ^[3].

W sektorach nadzorowanych kontrola dostępu uprzywilejowanego jest też tematem audytów. Sekurak w 2022 roku omawiał ją w kontekście PCI DSS, Rekomendacji D i ustawy o krajowym systemie cyberbezpieczeństwa, pisząc, że Privileged Access Manager „nie stanowi już wygody, stał się koniecznością” ^[7].