Jak zmniejszyć powierzchnię ataku w chmurze poprzez eliminację stałych uprawnień

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ń administratora dostępem Just-In-Time (JIT), który jest przyznawany po zatwierdzeniu, ograniczony czasowo i automatycznie odbierany.

Osiągnięcie tego celu zaczyna się od zrozumienia, dlaczego stałe uprawnienia stanowią tak znaczną część powierzchni ataku w chmurze. Utrzymanie tego stanu wymaga odpowiedniej platformy do egzekwowania poprawek we wszystkich używanych chmurach i tożsamościach.

Dlaczego stałe uprawnienia stanowią Państwa największą powierzchnię ataku w chmurze

Państwa powierzchnia ataku w chmurze to pełny zbiór sposobów, w jakie atakujący może dostać się do Państwa środowiska lub podejmować w nim działania: każde konto, dane uwierzytelniające, uprawnienie i integracja, które mają z nim styczność. W środowisku lokalnym znaczna część tego ma charakter sieciowy. W chmurze ma to kształt tożsamości. Użytkownik, konto usługowe lub połączona aplikacja z prawidłowymi danymi uwierzytelniającymi i odpowiednimi uprawnieniami nie musi przełamywać zapory sieciowej, ponieważ znajduje się już wewnątrz.

Stałe uprawnienia narastają po cichu. Role się zmieniają, projekty dobiegają końca, a ludzie odchodzą, lecz dostęp zwykle pozostaje. Z biegiem czasu objawia się to w postaci kilku przewidywalnych problemów:

• Stopniowe narastanie uprawnień: Wraz ze zmianą ról uprawnienia się kumulują, a stare wnioski o dostęp nie są cofane, przez co konta mają znacznie więcej uprawnień, niż potrzebują.
• Administratorzy zombie: Konta pozostawione aktywne po odejściu danej osoby z organizacji lub zmianie przez nią roli nadal zachowują dostęp uprzywilejowany, którego nikt nie monitoruje.
• Ukryci administratorzy: Konta mające faktyczną kontrolę, które w grupach katalogowych nie wyglądają na uprzywilejowane, przez co standardowe przeglądy je pomijają.
• Tożsamości maszynowe i nieosobowe (NHI): konta usługowe, klucze API i tożsamości obciążeń roboczych są obecnie liczniejsze niż użytkownicy będący ludźmi, a większość z nich ma własne stałe uprawnienia.

Każdy z nich jest celem. Atakujący potrzebuje tylko jednych przejętych danych uwierzytelniających, aby uzyskać punkt zaczepienia, a stałe uprawnienia pozwalają mu pójść dalej. Pojedyncze konto z nadmiernymi uprawnieniami otwiera drzwi do ruchu bocznego i eskalacji uprawnień w Państwa środowisku.

Jak wyeliminować stałe uprawnienia

Oto co należy zrobić, aby rozpocząć eliminowanie stałych uprawnień:

1. Wykrywanie i audyt dostępu uprzywilejowanego:Odkrywaj i audytuj uprzywilejowany dostęp: Należy zinwentaryzować każdą ścieżkę uprzywilejowaną w AWS, Entra ID, GCP, Okta i Active Directory, obejmując tożsamości osobowe, konta usług i integracje innych firm.
2. Egzekwowanie zasady najmniejszych uprawnień: Należy usunąć nieużywane i nadmierne uprawnienia, zlikwidować osierocone konta i konta administratorów zombie oraz ujawnić ukrytych administratorów niewidocznych w grupach katalogowych.
3. Zastępowanie stałych uprawnień administratora dostępem JIT:Zastąp stałe uprawnienia administratora dostępem JIT: Nie należy pozostawiać uprawnień administratora przypisanych na stałe. Zamiast tego przyznawaj uprawnienia na żądanie: zatwierdzone, ograniczone do określonego przedziału czasowego i automatycznie cofane po upływie tego okresu.
4. Docelowy brak stałych uprawnień (ZSP): Zasada najmniejszych uprawnień ogranicza zakres uprawnień posiadanych przez każde konto. Brak stałych uprawnień idzie o krok dalej, całkowicie usuwając stały dostęp, dzięki czemu żadna tożsamość nie zachowuje trwałego uprzywilejowanego dostępu, a podwyższenie uprawnień jest możliwe wyłącznie w zatwierdzonym przedziale czasowym.
5. Przechowywanie wyjątków w sejfie: Niektóre dane uwierzytelniające nadal muszą istnieć, na przykład klucze główne, konta root i inne dane dostępu awaryjnego. ZSP nie zastępuje przechowywania w sejfie, dlatego należy przechowywać je w sejfie pod ścisłą kontrolą.
6. Zapewnienie ciągłości: Należy regularnie przeprowadzać przeglądy dostępu i rejestrować każde podwyższenie uprawnień, aby narastanie uprawnień nie powróciło niezauważenie.

Warto pamiętać, że usunięcie stałych uprawnień z AWS nie pomoże, jeśli nadal pozostają one w Entra ID lub Okta. Egzekwowanie zasad musi obejmować każdą tożsamość w chmurze i tożsamość federacyjną, z której Państwo korzystają, ponieważ pozostawione luki stają się powierzchnią ataku, której nie ograniczono.

Jak Keeper Privileged Cloud zmniejsza powierzchnię ataku w chmurze

Keeper Privileged Cloud obsługuje dostęp JIT, zastępując stałe uprawnienia administratora podnoszeniem uprawnień przyznawanym na żądanie i automatycznie odbieranym. Rozszerza strukturę just-in-time rozwiązania KeeperPAM na AWS IAM, Microsoft Entra ID, GCP, Okta i Active Directory, a także wszelkie aplikacje sfederowane za ich pośrednictwem.

Uprawnienie jest przyznawane dopiero po zatwierdzeniu, na określony czas i automatycznie usuwane po upływie tego okresu. To właśnie brak stałych uprawnień w praktyce: dostęp opiera się na zatwierdzeniach, jest ograniczony czasowo i w pełni audytowalny, egzekwowany w ten sam sposób w tożsamości chmurowej i sfederowanej z poziomu jednej platformy.

Trwałe zmniejszenie powierzchni ataku w chmurze

Niewiele mechanizmów kontroli zmniejsza powierzchnię ataku w chmurze tak bardzo, jak usunięcie stałych uprawnień, ponieważ eliminuje to ciągły dostęp, na którym polegają atakujący. Trudniejszym zadaniem jest niedopuszczenie do jego powrotu. Wymaga to regularnych przeglądów dostępu oraz zautomatyzowanego, ograniczonego czasowo podwyższania uprawnień, które zapobiegają ponownemu narastaniu uprawnień po usunięciu ich nadmiaru.

Aby wdrożyć to na wszystkich używanych platformach chmurowych i katalogowych, można rozpocząć bezpłatny okres próbny KeeperPAM.