Identity and Access Management (IAM)

Identity and Access Management (IAM), czyli zarządzanie tożsamością i dostępem, to obszar cyberbezpieczeństwa, który odpowiada na dwa proste pytania: kto lub co prosi o dostęp oraz do czego ma prawo. Pierwsze z nich to uwierzytelnianie, drugie to autoryzacja. Celem IAM jest to, żeby właściwe osoby, usługi i urządzenia miały dostęp tylko do tych zasobów, których naprawdę potrzebują, tylko wtedy, gdy go potrzebują. Inaczej mówiąc: każdy dostaje dokładnie tyle uprawnień, ile trzeba, i ani trochę więcej. Tę zasadę nazywa się regułą najmniejszych uprawnień.

Czym różni się uwierzytelnianie (AuthN) od autoryzacji (AuthZ)?

To dwa różne kroki, które łatwo pomylić. Uwierzytelnianie sprawdza, kim jesteś. Autoryzacja decyduje, co możesz zrobić.

• Uwierzytelnianie (authentication, w skrócie AuthN) to potwierdzenie, że ktoś jest tym, za kogo się podaje. Opiera się na trzech rodzajach dowodów: czymś, co wiesz (hasło, PIN), czymś, co masz (token sprzętowy, klucz FIDO2, jednorazowy kod TOTP), oraz czymś, czym jesteś (biometria, np. odcisk palca). Na tym etapie działają takie mechanizmy jak SSO, MFA i federacja tożsamości.
• Autoryzacja (authorization, w skrócie AuthZ) przyznaje konkretny zakres uprawnień, ale dopiero po udanym uwierzytelnieniu. Tutaj wchodzą w grę modele kontroli dostępu (RBAC, ABAC) i pilnowanie, żeby nikt nie miał więcej niż musi.

Łatwo to zapamiętać tak: AuthN sprawdza tożsamość, AuthZ przyznaje dostęp. Najpierw trzeba wiedzieć, kto puka, a dopiero potem zdecydować, co mu wolno.

Jak działa IAM?

IAM zarządza tożsamością przez całe jej życie, od założenia konta aż po jego wyłączenie. Typowy cykl wygląda tak:

1. Założenie tożsamości (provisioning) — utworzenie konta i nadanie uprawnień, na przykład gdy firma zatrudnia pracownika albo rejestruje nową usługę.
2. Uwierzytelnianie — sprawdzenie tożsamości przy logowaniu, coraz częściej z dodatkowym czynnikiem (MFA).
3. Autoryzacja — ustalenie zakresu dostępu na podstawie roli lub atrybutów.
4. Zarządzanie sesją i monitorowanie — śledzenie aktywności, zapis zdarzeń, ponowne sprawdzenie przy ryzykownych operacjach.
5. Odebranie dostępu (de-provisioning) — zabranie uprawnień, gdy ktoś zmienia rolę albo odchodzi z firmy.

Ten ostatni krok bywa zaniedbywany, a to częsty problem. Gdy nikt na czas nie odbierze dostępu, zostają porzucone konta (orphaned accounts), a uprawnienia z czasem się nawarstwiają (privilege creep) — i jedno, i drugie ułatwia atak.

Z jakich elementów składa się IAM?

• Single Sign-On (SSO), czyli jednokrotne logowanie — logujesz się raz i masz dostęp do wielu aplikacji bez ponownego wpisywania hasła. Działa zwykle przez federację (SAML, OIDC).
• Multi-Factor Authentication (MFA), czyli uwierzytelnianie wieloskładnikowe — wymaga co najmniej dwóch niezależnych dowodów tożsamości. Im dalej od kodów SMS i TOTP w stronę kluczy sprzętowych FIDO2/WebAuthn, tym trudniej oszukać taki mechanizm phishingiem.
• Role-Based Access Control (RBAC), czyli kontrola dostępu oparta na rolach — uprawnienia przypisuje się do roli powiązanej ze stanowiskiem. Jest skalowalna, ale liczba ról potrafi szybko urosnąć.
• Attribute-Based Access Control (ABAC), czyli kontrola oparta na atrybutach — decyzje zależą od cech takich jak rola, lokalizacja, typ urządzenia, pora dnia czy wrażliwość zasobu. Jest bardziej precyzyjna i elastyczna niż RBAC.
• Provisioning i SCIM — automatyczne zakładanie, aktualizowanie i usuwanie kont między systemami za pomocą standardu SCIM (System for Cross-domain Identity Management).
• Federacja tożsamości (identity federation) — uznawanie tożsamości z innej, zaufanej organizacji bez znajomości jej hasła. Działa to przez relację między dostawcą tożsamości (IdP) a dostawcą usługi (SP).
• Audyt i raportowanie — rejestr zdarzeń dostępu na potrzeby zgodności z przepisami i analizy bezpieczeństwa.

Jakie protokoły federacji stosuje IAM (SAML, OIDC, OAuth)?

• SAML 2.0 — standard oparty na formacie XML, służący do wymiany informacji o uwierzytelnieniu i uprawnieniach między domenami. To klasyczna podstawa firmowego SSO w aplikacjach webowych.
• OAuth 2.0 — framework do autoryzacji (nie do uwierzytelniania). Pozwala aplikacji uzyskać ograniczony dostęp do zasobów w imieniu użytkownika za pomocą tokenów, bez pokazywania jej jego hasła.
• OpenID Connect (OIDC) — warstwa tożsamości dobudowana nad OAuth 2.0. Dodaje token ID (w formacie JWT), który potwierdza, kim jest użytkownik. Dominuje w aplikacjach chmurowych i mobilnych.

Częsty błąd to traktowanie OAuth 2.0 jako protokołu logowania. OAuth tylko przekazuje dostęp; tożsamość użytkownika potwierdza dopiero OIDC zbudowany na jego bazie.

Czym różni się IAM od PAM i IGA?

• IAM to szeroka dziedzina obejmująca wszystkie tożsamości: pracowników, klientów, partnerów, konta usług i tożsamości maszynowe.
• PAM (Privileged Access Management), czyli zarządzanie dostępem uprzywilejowanym, to wąska część IAM skupiona na kontach z dużymi uprawnieniami (administratorzy, root, konta serwisowe). Obejmuje sejf na hasła, ich rotację, dostęp przyznawany na czas (just-in-time) i nagrywanie sesji. Takie konta są łakomym celem ataków, bo dają szeroką kontrolę nad infrastrukturą.
• IGA (Identity Governance and Administration), czyli nadzór nad tożsamościami, to warstwa kontroli: zarządzanie cyklem życia, okresowy przegląd uprawnień (access reviews), wnioskowanie o dostęp, rozdział obowiązków (SoD) i raportowanie zgodności.

Jak IAM łączy się z Zero Trust?

W modelu Zero Trust to tożsamość, a nie sieć, staje się główną granicą bezpieczeństwa. Zaufanie nie bierze się z tego, że ktoś jest „w środku” sieci albo za firewallem. IAM dostarcza trzech filarów tego podejścia: sprawdzaj każde żądanie, dawaj jak najmniej uprawnień i zakładaj, że doszło już do naruszenia. W praktyce oznacza to uwierzytelnianie adaptacyjne, które ocenia ryzyko na podstawie sygnałów takich jak urządzenie, lokalizacja czy zachowanie, ciągłe sprawdzanie sesji i ścisłe ograniczanie zakresu dostępu.

Dlaczego IAM jest kluczowy dla bezpieczeństwa i wykrywania zagrożeń?

Tożsamość to dziś jedna z najczęstszych dróg ataku: kradzież haseł, phishing, credential stuffing (podstawianie wykradzionych haseł), przejęcie sesji i nadużycie kont uprzywilejowanych. Co istotne, atakujący, który zdobędzie prawdziwe hasło, często nie musi już niczego włamywać — po prostu się loguje. Dlatego klasyczne metody łatwo to przeoczają.

Dla zespołu SOC oraz monitoringu sieci (NDR/SIEM) dane z IAM są cennym źródłem sygnałów ostrzegawczych:

• logi logowań i przyznawania dostępu — nietypowe logowania, takie, które geograficznie nie mają prawa się zdarzyć (impossible travel), próby siłowe i password spraying (testowanie jednego hasła na wielu kontach);
• zdarzenia MFA — masowe odrzucenia próśb albo tak zwane zmęczenie potwierdzaniem (MFA fatigue), które bywa oznaką ataku;
• zmiany uprawnień — nagłe nadanie roli administratora lub modyfikacja polityk dostępu;
• aktywność kont serwisowych i tożsamości maszynowych — odstępstwa od normy, które w zestawieniu z ruchem sieciowym mogą wskazywać na ruch boczny (lateral movement), czyli przemieszczanie się atakującego po sieci.

Gdy połączy się logi tożsamości z danymi o ruchu w sieci, widać nie tylko kto się zalogował, ale też co robi w sieci. To podstawa wykrywania nadużyć kont i ataków opartych na tożsamości.

Jak IAM wspiera zgodność z regulacjami?

IAM dostarcza mechanizmów, których wymagają normy i przepisy, w tym RODO, ISO/IEC 27001 oraz dyrektywa NIS2: pilnowanie najmniejszych uprawnień, MFA, rozdział obowiązków, okresowy przegląd dostępu oraz pełne ścieżki audytowe. Dzięki nim można odpowiedzieć na pytanie, kto, kiedy i do czego miał dostęp.

Dowiedz się więcej

• Zero Trust Architecture — IAM wspiera Zero Trust przez ścisłe uwierzytelnianie i kontrolę dostępu do zasobów.
• Błędy konfiguracji sieci – jak unikać network configuration errors i poprawić konfigurację routera — IAM wymaga poprawnej konfiguracji sieci, by polityki dostępu działały zgodnie z założeniami.
• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR dotyczy błędów autoryzacji, czyli obszaru objętego kontrolą IAM.