Ta strona używa plików cookies, aby zapewnić najlepszą jakość korzystania z naszego serwisu oraz do celów analitycznych. Klikając "Akceptuję", wyrażasz zgodę na używanie wszystkich plików cookies. Możesz również odrzucić zgodę, co spowoduje zablokowanie plików cookies analitycznych. Więcej informacji znajdziesz w naszej Polityce Prywatności.
Widoczność tożsamości staje się fundamentem bezpieczeństwa IAM
Widoczność tożsamości łączy inwentaryzację kont, mapowanie uprawnień i analizę zachowania.
Raporty IAM pokazują głównie dostęp zaplanowany, a nie zawsze dostęp faktycznie wykorzystywany.
Największe ryzyko często dotyczy niezarządzanych kont usługowych, uprawnień produkcyjnych i braku MFA.
W chmurze trzeba analizować także relacje zaufania, dostęp między kontami oraz tożsamości maszynowe.
Sponsorowane
Odkryj rewolucyjną metodę nauki języków
Sprawdź jak w 30 dni opanować podstawy dowolnego języka obcego bez wychodzenia z domu.
Widoczność tożsamości jest punktem wyjścia dla współczesnego bezpieczeństwa dostępu. W badaniach dotyczących naruszeń bezpieczeństwa skradzione lub niewłaściwie użyte poświadczenia należą do najczęściej wskazywanych sposobów uzyskania początkowego dostępu, co regularnie odnotowują także doroczne raporty Verizon Data Breach Investigations Report. Problem nie ogranicza się jednak do ustalenia, czy dane konto istnieje. Organizacja musi wiedzieć, do czego dana tożsamość może się dostać, jakie uprawnienia ma w praktyce oraz jak z nich korzysta podczas działania systemów.
Widoczność to więcej niż lista kont
Widoczność tożsamości oznacza ciągły obraz wszystkich tożsamości obecnych w środowisku, ich uprawnień i faktycznego użycia. Łączy trzy rodzaje informacji: inwentaryzację, mapowanie uprawnień oraz dane o zachowaniu w czasie działania systemów. Dzięki temu zastępuje okresowy raport bieżącą obserwacją. Taka różnica ma znaczenie, ponieważ stan zapisany w katalogu może nie odpowiadać temu, co rzeczywiście dzieje się w aplikacji, chmurze lub infrastrukturze.
Inwentaryzacja tożsamości pokazuje, jakie konta, poświadczenia i podmioty występują w środowisku.
Mapa uprawnień wskazuje, jakie działania może wykonać każda tożsamość oraz z czego wynikają te możliwości.
Telemetria działania pokazuje, które poświadczenia się uwierzytelniły i jakie uprawnienia zostały faktycznie użyte.
Weryfikacja porównuje dostęp zaplanowany w politykach z dostępem rzeczywiście egzekwowanym przez aplikacje i infrastrukturę.
, trzeba rozróżnić zamiar od wykonania. Platformy IAM opisują zamiar polityki: kto powinien mieć dostęp, w jakich warunkach i przez jaki czas. Aplikacje oraz infrastruktura pokazują wykonanie: które poświadczenie zostało użyte, jakie uprawnienia zadziałały i przez jaką ścieżkę przebiegło żądanie. Pomiędzy tymi warstwami powstaje luka. Może obejmować lokalne konta aplikacji, osadzone dane uwierzytelniające, starsze mechanizmy logowania i integracje, których nie podłączono do centralnego dostawcy tożsamości.
Ukryte tożsamości tworzą realną powierzchnię ryzyka
Ta ukryta część środowiska nie jest wyjątkowym przypadkiem. Powstaje między innymi w wyniku wieloletniego wdrażania usług SaaS, migracji do chmury i rozwoju automatyzacji. Systemy są dodawane szybciej, niż programy tożsamościowe są w stanie objąć je kontrolą. W rezultacie rośnie różnica między dostępem udokumentowanym a dostępem rzeczywistym. Z perspektywy obrony oznacza to, że organizacja może mieć poprawnie opisane konta w centralnym katalogu, ale nie wiedzieć o wszystkich poświadczeniach akceptowanych przez aplikacje i infrastrukturę.
Napastnicy mogą wykorzystywać tę lukę bez uruchamiania działań, które od razu przypominają typową infekcję urządzenia. Przejęte, legalne poświadczenie może zostać użyte w ramach uprawnień, które już posiada. Taka aktywność może wyglądać podobnie do zwykłych operacji wykonywanych przez użytkownika, usługę lub administratora. Dlatego sama obecność kontroli endpointów albo centralnego systemu IAM nie daje pewności, że organizacja widzi cały przebieg dostępu.
Od inwentaryzacji do efektywnego dostępu
Raporty IAM i katalogi uprawnień najczęściej odpowiadają na pytanie, co zostało przyznane. Nie zawsze pokazują, czy aplikacja rzeczywiście egzekwuje tę zasadę, czy konto ma jeszcze właściciela albo czy uprawnienie było używane w ostatnim czasie. Podobne ograniczenie dotyczy narzędzi, które raportują wyłącznie o aplikacjach podłączonych do ich własnego systemu. Jeśli aplikacja nigdy nie została zintegrowana, może nie pojawić się w raporcie, a jej brak może zostać błędnie odczytany jako brak ryzyka. Zasada weryfikacji jest więc ważniejsza niż założenie, że pokrycie narzędzia odpowiada pokryciu całej organizacji.
Praktyczna widoczność opiera się na trzech powiązanych elementach. Pierwszym jest dokładna inwentaryzacja aktorów, zarówno ludzkich, jak i nieosobowych. Drugim jest mapa uprawnień, która opisuje nie tylko role, ale także relacje między tożsamościami, grupami, aplikacjami i kontami. Trzecim jest analiza kontekstu. Sama lista znalezisk nie określa jeszcze priorytetu. Dopiero zestawienie uprawnień z właścicielem, celem, sposobem uwierzytelniania, historią użycia i wrażliwością systemu pozwala ocenić znaczenie danego konta.
Niekontrolowane konto usługowe z prawem zapisu do środowiska produkcyjnego powinno mieć wyższy priorytet niż nieużywane konto z dostępem tylko do systemu testowego.
Konto administracyjne logujące się bez MFA wymaga szczególnej uwagi, zwłaszcza gdy może zmieniać konfigurację infrastruktury.
Poświadczenie, którego nie rotowano przez długi czas, powinno zostać powiązane z właścicielem, celem i harmonogramem wymiany.
Uśpione konto należące do byłego pracownika jest konkretnym znaleziskiem, które można szybko przypisać do procesu odebrania dostępu.
Chmura i multicloud komplikują obraz
Środowiska chmurowe nie muszą mieć mniej danych o tożsamościach. Problem polega na tym, że poszczególni dostawcy opisują je w różny sposób i nie pokazują automatycznie pełnego obrazu pozostałych środowisk. Każda platforma używa własnego języka uprawnień, ról i relacji. Widoczność multicloud wymaga więc normalizacji tych modeli, aby można było prześledzić jedną tożsamość we wszystkich miejscach, w których może działać. Bez takiego ujednolicenia zespoły mogą analizować dostawców osobno i przeoczyć połączenia między nimi, w tym federację zaufania, dostęp między kontami oraz współdzielone poświadczenia.
W chmurze ruch boczny często przebiega przez relacje IAM, a nie przez klasyczne ścieżki sieciowe. Szczególnej uwagi wymagają tożsamości maszynowe, czyli konta i poświadczenia używane przez potoki automatyzacji, narzędzia infrastrukturalne oraz systemy orkiestracji. Powstają one poza typowym cyklem kadrowym, który obejmuje zatrudnienie, zmianę stanowiska i odejście pracownika. W efekcie mogą omijać mechanizmy stworzone dla kont ludzi. Tożsamość nieosobowa powinna mieć nazwę właściciela, określony cel, termin wygaśnięcia lub rotacji oraz aktywny monitoring. Dotyczy to zwłaszcza tożsamości sterujących infrastrukturą, ponieważ ich przejęcie może pozwolić na tworzenie nowych dostępów, zmianę ustawień rejestrowania albo osłabienie mechanizmów wykrywania.
Widoczność powinna zasilać istniejące procesy
Widoczność tożsamości nie musi zastępować dotychczasowych narzędzi. Jej rolą jest dostarczenie warstwy obserwacyjnej, która pozwala sprawdzić, czy działają one zgodnie z założeniami. Systemy zarządzania tożsamością zwykle koncentrują się na projektowaniu dostępu, cyklu życia, politykach i nadawaniu uprawnień, a także na egzekwowaniu uwierzytelniania i autoryzacji podczas sesji. Warstwa widoczności porównuje te dwa poziomy i pokazuje różnice. Dane mogą zasilać przeglądy dostępu, wskazywać uprzywilejowane konta działające poza mechanizmami PAM oraz dostarczać zespołom bezpieczeństwa kontekstu potrzebnego do odtworzenia przebiegu zdarzenia.
Takie podejście jest zgodne z założeniem ciągłej weryfikacji obecnym w koncepcji zero trust. Decyzja o dostępie powinna uwzględniać nie tylko samą nazwę konta, ale także kontekst sesji, typ poświadczenia, wcześniejsze zachowanie i wrażliwość systemu docelowego. Równie ważne jest wykrywanie miejsc, w których zasada nie jest faktycznie egzekwowana, na przykład aplikacji nadal akceptujących starsze protokoły uwierzytelniania albo kont administracyjnych bez MFA. Bez ciągłej obserwacji organizacja może znać zaprojektowaną politykę, ale nie wiedzieć, czy środowisko rzeczywiście ją realizuje.
Budowę programu najlepiej prowadzić etapami. Pierwszy etap to przejście od ręcznego i okresowego zarządzania do automatycznej, ciągłej kontroli. Następnie można rozszerzyć analizę o zachowanie tożsamości w aplikacjach i infrastrukturze. Sama faza odkrywania zwykle generuje dużo wyników, dlatego potrzebna jest kolejność napraw oraz jasno przypisani właściciele. Dobrym początkiem są przypadki, w których nadmiar uprawnień łączy się z ekspozycją: nieposiadane przez nikogo konta usługowe z prawem zapisu do produkcji, konta administracyjne bez MFA, długo niezmieniane poświadczenia oraz uśpione konta byłych pracowników. Każde z tych znalezisk ma konkretny zakres, możliwą ścieżkę naprawy i właściciela. To pozwala ograniczać zmęczenie alertami i budować program bezpieczeństwa oparty na faktach, a nie na założeniu, że centralny katalog pokazuje cały dostęp.
