Można zmniejszyć powierzchnię ataku w chmurze poprzez audyt każdego trwałego uprawnienia na platformach chmurowych i tożsamościowych, usunięcie niepotrzebnego dostępu oraz zastąpienie stale aktywnych uprawnień administra...
Konta uprzywilejowane nieustannie kuszą atakujących danymi uwierzytelniającymi, które można wykraść, i uprawnieniami, które można wykorzystać w niewłaściwy sposób. Jeśli uprawnienia administracyjne pozostają stale aktywne, nawet gdy nikt z nich nie korzysta, konta uprzywilejowane znacząco powiększają powierzchnię ataku. Zasada braku stałych uprawnień (ZSP) ogranicza to ryzyko: żaden użytkownik nie zachowuje na stałe dostępu z podwyższonymi uprawnieniami. Uprawnienia są przyznawane na wniosek dotyczący konkretnego zadania, na ograniczony czas i po zatwierdzeniu zgodnie z określonym procesem. Po upływie zatwierdzonego okresu są automatycznie odbierane. ZSP wpisuje się w szerszą zmianę podejścia do bezpieczeństwa: zastępowanie stałego dostępu dostępem tymczasowym, aby ograniczyć możliwości działania atakujących. Keeper wspiera egzekwowanie ZSP, przyznając dostęp Just-in-Time (JIT) i automatycznie odbierając go po upływie zatwierdzonego okresu; użytkownicy początkowo nie mają uprawnień, następnie otrzymują dokładnie taki dostęp, jakiego potrzebują, a potem automatycznie wracają do stanu bez uprawnień.
W dalszej części wyjaśniamy znaczenie ZSP, sposób jego działania w rozwiązaniu Keeper oraz środowiska, w których Keeper egzekwuje tę zasadę.
Dlaczego stałe uprawnienia zagrażają bezpieczeństwu
Konto uprzywilejowane aktywne bezterminowo jest dla atakujących stałym celem: dane uwierzytelniające nie wygasają, dostęp jest możliwy przez cały czas, a termin odebrania uprawnień nie został określony. Po wykradzeniu lub przejęciu takiego konta atakujący uzyskują wszystkie przypisane do niego stałe uprawnienia.
Jeszcze poważniejszym problemem jest zasięg skutków ataku: przejęte konto ze stałym dostępem rzadko służy atakującym wyłącznie do działań w systemie, dla którego je utworzono. Stałe uprawnienia umożliwiają atakującym przemieszczanie się między zasobami w różnych środowiskach i uzyskiwanie dostępu do kolejnych serwerów, baz danych oraz zasobów chmurowych. Jeśli użytkownik ma stały dostęp, przejęcie nawet jednych danych uwierzytelniających może szybko otworzyć atakującym drogę do całej infrastruktury. Stałe uprawnienia oznaczają, że dostęp nie jest powiązany z konkretnym wnioskiem, zadaniem ani okresem. Brakuje więc jednoznacznego zapisu wyjaśniającego, dlaczego dana osoba mogła w określonym momencie korzystać z systemu. Taki brak jednoznaczności znacznie utrudnia analizę incydentów bezpieczeństwa związanych ze stałymi uprawnieniami oraz wykazywanie zgodności z wymaganiami.
Jak Keeper realizuje zasadę braku stałych uprawnień
Keeper wspiera egzekwowanie ZSP dzięki rozwiązaniu Keeper Privileged Cloud, które rozszerza mechanizm dostępu JIT w KeeperPAM na wykorzystywanych dostawców tożsamości i aplikacje federacyjne. Zamiast nadawać stałe uprawnienia administracyjne, Keeper Privileged Cloud przyznaje dostęp z podwyższonymi uprawnieniami wyłącznie na wniosek, na zatwierdzony okres i zgodnie z określonymi przez Państwa regułami procesu. Użytkownicy domyślnie nie mają uprawnień. Otrzymują je w ramach kontrolowanego procesu podlegającego audytowi, a po zakończeniu zadania ponownie pozostają bez uprawnień. Poniżej opisano praktyczne działanie ZSP w rozwiązaniu Keeper.
Konfiguracja zasad dostępu
W rekordzie PAM Cloud administratorzy określają reguły dostępu za pomocą ustawień JIT i przepływu pracy. Określają między innymi, czy wniosek wymaga zatwierdzenia, kto może go zatwierdzić, na jak długo przyznawany jest dostęp oraz jaką rolę otrzyma użytkownik po podwyższeniu uprawnień. Ustawienia te precyzują sposób wnioskowania o dostęp uprzywilejowany, jego zatwierdzania i ograniczania w czasie. Dzięki temu podwyższenie uprawnień nie wykracza poza ustalone przez Państwa granice.

Udostępnianie rekordów uprawnionym użytkownikom
Po skonfigurowaniu zasad rekord PAM Cloud jest udostępniany użytkownikom, którzy mają mieć możliwość składania wniosków o dostęp. Podwyższanie uprawnień odbywa się za pośrednictwem dostawcy tożsamości, dlatego każdy użytkownik musi mieć konto zarówno u tego dostawcy, jak i w środowisku Keeper danej organizacji. Po udostępnieniu rekordu użytkownicy mogą wnioskować o dostęp z podwyższonymi uprawnieniami, gdy wymaga tego zadanie, bez zachowywania stałych uprawnień w pozostałym czasie.
Weryfikacja i zatwierdzanie wniosków
Użytkownik może złożyć wniosek o potrzebny dostęp bezpośrednio z poziomu sejfu Keeper Vault lub interfejsu wiersza poleceń Keeper Commander CLI. Osoby wyznaczone do zatwierdzania otrzymują natychmiastowe powiadomienia w narzędziach takich jak Slack, Teams, Jira i ServiceNow. Mogą zatwierdzać lub odrzucać wnioski w dowolnej aplikacji klienckiej Keeper, więc rozpatrzenie wniosku nie wymaga czekania, aż dana osoba wróci do biurka. W zależności od zasad osoby zatwierdzające mogą przed przyznaniem dostępu wymagać także uzasadnienia i numeru zgłoszenia. W ten sposób każde podwyższenie uprawnień ma udokumentowaną przyczynę.

Automatyczne przyznawanie i odbieranie dostępu
Po zatwierdzeniu wniosku brama Keeper Gateway podwyższa uprawnienia u dostawcy tożsamości lub w zasobie docelowym. Nadaje użytkownikowi skonfigurowane członkostwo w grupie, rolę lub uprawnienie, zapewniając dostęp zgodny z zasadami. Gdy zatwierdzony okres dobiegnie końca, brama Keeper Gateway automatycznie odbiera dostęp, usuwając tymczasowe członkostwo lub przypisanie. Użytkownik ponownie pozostaje bez stałych uprawnień, zgodnie z ZSP. Brama również rejestruje każde podwyższenie uprawnień związane z wnioskiem o dostęp, osobę zatwierdzającą oraz czas rozpoczęcia i zakończenia. Dzięki temu zespoły ds. bezpieczeństwa i zgodności z wymaganiami dysponują dla każdego wniosku przejrzystym zapisem sposobu przyznania i wykorzystania dostępu uprzywilejowanego.
Gdzie Keeper egzekwuje zasadę braku stałych uprawnień
W rozwiązaniu Keeper zasada ZSP nie ogranicza się do jednego systemu ani rodzaju konta. Ten sam mechanizm JIT obejmuje wszystkie miejsca w Państwa środowisku, w których występuje dostęp uprzywilejowany: od dostawców tożsamości uwierzytelniających użytkowników po powiązane z nimi zasoby chmurowe, bazy danych i maszyny.
U dostawców tożsamości
Keeper Privileged Cloud zapewnia dostęp JIT u już wykorzystywanych dostawców tożsamości: AWS IAM, Microsoft Entra ID, Google Cloud za pośrednictwem Google Identity, Okta oraz Active Directory. Keeper przyznaje i odbiera uprawnienia bezpośrednio w istniejącej infrastrukturze. Podwyższanie uprawnień odbywa się więc tam, gdzie konta są już utrzymywane, bez zmiany sposobu uwierzytelniania użytkowników. Dostawca tożsamości pozostaje nadrzędnym źródłem informacji, a Keeper kontroluje jedynie moment dodania użytkownika do grupy uprzywilejowanej oraz jego usunięcia z tej grupy.
Rozwiązanie obejmuje nie tylko same platformy, lecz także aplikacje korzystające z federacji dostępu i autoryzacji za pośrednictwem tych dostawców tożsamości. Aplikacje federacyjne mogą również korzystać z Keeper do kontroli dostępu. Pozwala to stosować ten sam model JIT w powiązanych aplikacjach, do których zespoły logują się na co dzień.
W chmurze, bazach danych i na maszynach
ZSP wykracza poza konsole chmurowe, dlatego KeeperPAM stosuje ten sam mechanizm podwyższania uprawnień również poza usługami dostawców tożsamości. Rekordy PAM Cloud, PAM Database i PAM Machine pozwalają objąć dostępem ograniczonym czasowo zasoby chmurowe, bazy danych i poszczególne maszyny. W ten sposób ten sam cykl przyznawania i odbierania dostępu obejmuje infrastrukturę powiązaną z warstwą tożsamości.
Oprócz podwyższania uprawnień brama Keeper Gateway przeprowadza rotację uprzywilejowanych danych uwierzytelniających, aby nie stanowiły niezmiennego celu ataku. Dla baz danych i maszyn może też tworzyć konta krótkotrwałe i przekazywać dane uwierzytelniające po stronie serwera, bez udziału użytkownika. Całość działa w architekturze zero-knowledge rozwiązania Keeper. Dane uwierzytelniające i tajne dane są więc przez cały czas szyfrowane metodą end-to-end i nigdy nie są ujawniane firmie Keeper ani żadnym innym podmiotom. Automatyczna rotacja w połączeniu z modelem zero knowledge sprawia, że nawet dane uwierzytelniające zapewniające dostęp uprzywilejowany nie pozostają trwale dostępne do wykradzenia i wykorzystania przez atakującego.
Ograniczenie powierzchni ataku dzięki Keeper
Zasada braku stałych uprawnień jest skuteczna tylko wtedy, gdy jest konsekwentnie egzekwowana. Właśnie w tym sprawdza się Keeper Privileged Cloud. Keeper zapewnia zespołom ds. bezpieczeństwa podlegający audytowi sposób przyznawania dostępu uprzywilejowanego na żądanie i jego automatycznego odbierania, z wykorzystaniem istniejących dostawców tożsamości oraz infrastruktury. Administratorzy zyskują kontrolę nad tym, kto, do czego i kiedy ma dostęp, oraz możliwość jej udokumentowania. Użytkownicy otrzymują potrzebny dostęp bez oczekiwania na ręczne nadanie uprawnień i bez zachowywania tych, których już nie potrzebują.
Zapraszamy do zamówienia prezentacji KeeperPAM, aby zobaczyć, jak dostęp JIT i jego automatyczne odbieranie działają w Państwa środowisku.
Często zadawane pytania (FAQ)
Czym różni się zasada braku stałych uprawnień od zasady najmniejszych uprawnień?
Zasada najmniejszych uprawnień zapewnia użytkownikom wyłącznie uprawnienia niezbędne do pełnienia ich roli. Zazwyczaj są one jednak stałe, czyli pozostają aktywne także wtedy, gdy nikt z nich nie korzysta. Zasada braku stałych uprawnień idzie o krok dalej: domyślnie nie przyznaje się żadnego dostępu, uprawnienia są nadawane dopiero po złożeniu i zatwierdzeniu wniosku, a po zakończeniu zadania zostają odebrane. Zasada najmniejszych uprawnień ogranicza więc zakres dostępu użytkownika, natomiast ZSP ogranicza czas jego posiadania, najlepiej do całkowitego braku dostępu, dopóki nie jest potrzebny. Więcej informacji zawiera nasz wpis porównujący zasadę braku stałych uprawnień z zasadą najmniejszych uprawnień.
Których dostawców tożsamości obsługuje Keeper?
Keeper Privileged Cloud wymusza stosowanie dostępu JIT w AWS IAM, Microsoft Entra ID, Google Cloud za pośrednictwem Google Identity, Okta i Active Directory. Aplikacje korzystające z federacji dostępu i autoryzacji za pośrednictwem tych platform również mogą wykorzystywać Keeper do kontroli dostępu. Dzięki temu ten sam model JIT obejmuje pozostałe aplikacje połączone z Państwa dostawcami tożsamości.
W jaki sposób użytkownicy uzyskują dostęp do zasobów po zatwierdzeniu wniosku?
Po zatwierdzeniu wniosku użytkownicy mogą połączyć się z zasobem za pomocą zdalnej izolacji przeglądarki w rozwiązaniu Keeper, która zapewnia bezpieczną sesję w przeglądarce, albo korzystać z dotychczasowych sposobów pracy, takich jak portal dostępu AWS czy AWS CLI. W obu przypadkach dostęp jest przyznawany wyłącznie na uzasadniony okres i automatycznie odbierany po upływie zatwierdzonego czasu.