CompTIA SY0-701: Zarządzanie tożsamością i dostępem — Przewodnik do nauki

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Część CompTIA Security+ SY0-701 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów CompTIA, albo rozwiąż testy na czas na ExamRoll.io.

Zarządzanie tożsamością i dostępem (IAM) to dyscyplina zapewniająca, że odpowiednie podmioty — użytkownicy, usługi i urządzenia — uzyskują właściwy dostęp do właściwych zasobów we właściwym czasie i tylko na tak długo, jak jest to konieczne. Opiera się na dwóch koncepcyjnie odrębnych filarach, które są często, i niebezpiecznie, mylone: uwierzytelnianiu, które dowodzi, kim jest podmiot, oraz autoryzacji, która określa, co ten uwierzytelniony podmiot może zrobić. Użytkownik logujący się na stację roboczą za pomocą odcisku palca został uwierzytelniony; to, czy może on otworzyć bazę danych płac, jest kwestią autoryzacji. Każdy projekt mechanizmu kontroli, który zaciera tę różnicę, naraża system na kompromitację.

Składniki uwierzytelniania i uwierzytelnianie wieloskładnikowe

Składniki uwierzytelniania tradycyjnie grupuje się w pięciu kategoriach: coś, co wiesz (hasła, kody PIN), coś, co masz (karty inteligentne, tokeny sprzętowe, telefony z aplikacjami TOTP), coś, czym jesteś (odcisk palca, siatkówka, geometria twarzy), miejsce, w którym jesteś (geolokalizacja lub kontekst sieciowy) oraz coś, co robisz (biometria behawioralna, np. rytm pisania na klawiaturze). Uwierzytelnianie wieloskładnikowe (MFA) wymaga dowodów z co najmniej dwóch różnych kategorii. Hasło połączone z pytaniem bezpieczeństwa nie jest MFA — oba należą do kategorii „coś, co wiesz”. Hasło połączone z kodem TOTP z aplikacji Google Authenticator jest MFA.

Tokeny sprzętowe występują w kilku formach. Klucze bezpieczeństwa FIDO2/WebAuthn, takie jak YubiKey, wykorzystują kryptografię asymetryczną: klucz prywatny nigdy nie opuszcza urządzenia, a serwer przechowuje jedynie klucz publiczny, co zapobiega phishingowi i atakom typu replay. Tokeny HOTP generują hasła jednorazowe na podstawie licznika; tokeny TOTP generują je na podstawie bieżącego czasu przy użyciu konstrukcji HMAC-SHA1:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Karty inteligentne, powszechnie znane jako karty PIV lub CAC w środowiskach rządowych, przechowują certyfikat X.509 i klucz prywatny na chipie odpornym na manipulacje. Okazanie karty w połączeniu z kodem PIN spełnia wymogi dwóch składników i umożliwia uwierzytelnianie oparte na certyfikatach w systemach takich jak Active Directory za pośrednictwem Kerberos PKINIT.

MFA jest najskuteczniejszym pojedynczym mechanizmem kontroli chroniącym przed kradzieżą poświadczeń. Gdy użytkownicy zgłaszają logowania z adresów IP, z których nie korzystali, resetowanie haseł jest leczeniem objawów; wdrożenie MFA eliminuje przyczynę źródłową, ponieważ samo skradzione hasło staje się niewystarczające.

Logowanie jednokrotne i federacja

Logowanie jednokrotne (SSO) pozwala użytkownikowi uwierzytelnić się raz i uzyskać dostęp do wielu aplikacji bez ponownego wprowadzania poświadczeń. Federacja rozszerza to działanie poza granice organizacji lub zaufania — dostawca tożsamości (IdP) użytkownika w jednej domenie poświadcza jego tożsamość dostawcy usług (SP) w innej. Najczęstszym błędem jest traktowanie SAML i OAuth jako rozwiązań zamiennych; rozwiązują one różne problemy.

SAML 2.0 to protokół oparty na XML, zaprojektowany do obsługi SSO w przedsiębiorstwach i asercji uwierzytelniania. Gdy użytkownik żąda dostępu do aplikacji SaaS, SP przekierowuje przeglądarkę do IdP, który uwierzytelnia użytkownika i zwraca podpisaną asercję SAML zawierającą atrybuty tożsamości. Jest to standardowy mechanizm umożliwiający pracownikom dostęp do aplikacji chmurowych, takich jak Salesforce czy Workday, przy użyciu korporacyjnych poświadczeń Active Directory.

OAuth 2.0 to framework autoryzacji, a nie protokół uwierzytelniania. Umożliwia on aplikacji zewnętrznej uzyskanie delegowanego dostępu do zasobu w imieniu użytkownika za pomocą tokenów dostępu. Zezwolenie aplikacji na publikowanie postów na Twoim kanale na Twitterze to przepływ OAuth. OpenID Connect (OIDC) to warstwa tożsamości zbudowana na bazie OAuth 2.0, która dodaje id_token (JWT) dostarczający asercji uwierzytelniania — to właśnie umożliwia działanie funkcji „Zaloguj się przez Google”.

Krytyczna pułapka: SSO i federacja ograniczają rozrost poświadczeń, ale nie eliminują potrzeby stosowania MFA. Co więcej, koncentrują one ryzyko — jedno skompromitowane poświadczenie SSO odblokowuje dostęp do każdej sfederowanej aplikacji. MFA musi być wymuszane na poziomie IdP, a konta uprzywilejowane powinny wymagać uwierzytelniania step-up nawet po zalogowaniu przez SSO.

Modele kontroli dostępu

Po ustaleniu tożsamości, model kontroli dostępu zarządza decyzjami o autoryzacji. Dyskrecjonalna kontrola dostępu (DAC) pozwala właścicielom zasobów na ustawianie uprawnień, zazwyczaj za pomocą list kontroli dostępu (ACL). Mandatoryjna kontrola dostępu (MAC) centralnie egzekwuje politykę opartą na etykietach i poświadczeniach bezpieczeństwa, co jest powszechne w systemach wojskowych i wymuszane przez frameworki takie jak SELinux. Kontrola dostępu oparta na rolach (RBAC) przypisuje uprawnienia do ról, a użytkowników do ról — rola „Analityk ds. rozliczeń” niesie ze sobą zdefiniowany zestaw uprawnień, a użytkownicy dziedziczą uprawnienia poprzez przynależność do roli. Kontrola dostępu oparta na atrybutach (ABAC) ocenia polityki na podstawie atrybutów podmiotu, zasobu, akcji i środowiska, umożliwiając tworzenie reguł takich jak „zezwalaj na dostęp do odczytu plików HR tylko w godzinach pracy z urządzeń zarządzanych przez firmę”.

Nadrzędna wobec każdego modelu jest zasada najmniejszych uprawnień: podmioty otrzymują tylko minimalny dostęp niezbędny do wykonania swoich funkcji i nic ponadto. Uzupełnia ją separacja obowiązków, która zapobiega sytuacji, w której jedna osoba kontroluje cały wrażliwy proces — osoba, która wnioskuje o płatność, nie powinna jej również zatwierdzać.

Praktyczne mechanizmy kontroli dostępu obejmują listy ACL systemu plików, sieciowe listy ACL na routerach i zaporach sieciowych oraz ograniczenia czasowe, które zezwalają na logowanie tylko w autoryzowanych godzinach. Wpis na liście ACL systemu Windows przyznający dostęp tylko do odczytu do udziału finansowego może wyglądać następująco:

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Zarządzanie Dostępem Uprzywilejowanym

Konta uprzywilejowane — administratorzy domeny, konta root, administratorzy baz danych, konta root w chmurze, konta usługowe — to klejnoty koronne każdego środowiska. Systemy zarządzania dostępem uprzywilejowanym (Privileged Access Management, PAM), takie jak CyberArk, BeyondTrust czy HashiCorp Vault, wymuszają kontrolę nad tymi kontami: poświadczenia są przechowywane w sejfie (vault) i automatycznie rotowane, sesje są nagrywane, uzyskanie dostępu (checkout) wymaga uzasadnienia i często zatwierdzenia, a hasła są często jednorazowe lub efemeryczne.

Dostęp Just-in-Time (JIT) podnosi uprawnienia tylko na czas wykonania określonego zadania, eliminując stałe uprawnienia administracyjne. Deweloper, który musi przeprowadzić migrację bazy danych, otrzymuje ograniczone czasowo poświadczenie, które wygasa automatycznie po 30 minutach — nie ma stałego konta uprzywilejowanego, które można by ukraść. Privileged Identity Management (PIM) w Azure AD natywnie implementuje ten wzorzec, wymagając przepływów zatwierdzania i ponownego uwierzytelnienia MFA przed podniesieniem uprawnień.

Konta usługowe stanowią odrębne wyzwanie. Często mają nadmierne uprawnienia, ich hasła są rzadko zmieniane, a ich użycie rzadko audytowane. Konta Managed Service Accounts (MSAs) i Group Managed Service Accounts (gMSAs) w Active Directory automatyzują rotację haseł i całkowicie eliminują potrzebę znajomości poświadczeń kont usługowych przez ludzi.

Usługi Katalogowe i Provisioning

Active Directory (AD) pozostaje dominującym lokalnym (on-premises) magazynem tożsamości. Użytkownicy, komputery i grupy są zorganizowane w jednostki organizacyjne (Organizational Units, OU), a obiekty zasad grupy (Group Policy Objects, GPO) hierarchicznie stosują ustawienia konfiguracyjne i bezpieczeństwa. Relacje zaufania (trusts) w AD rozszerzają uwierzytelnianie na inne domeny i lasy. Azure Active Directory (Entra ID) rozszerza te koncepcje na chmurę, dodając polityki dostępu warunkowego, ocenę ryzyka w ramach ochrony tożsamości oraz bezproblemową integrację z tysiącami aplikacji SaaS.

LDAP (Lightweight Directory Access Protocol) to podstawowy protokół do odpytywania usług katalogowych. RADIUS centralizuje uwierzytelnianie dla dostępu do sieci — VPN, Wi-Fi i uwierzytelnianie przewodowe 802.1X powszechnie uwierzytelniają się na serwerze RADIUS opartym o AD. TACACS+ pełni podobną rolę w administracji urządzeniami sieciowymi, z dodatkową korzyścią w postaci rozdzielenia uwierzytelniania, autoryzacji i rozliczania (accounting) na odrębne fazy.

Provisioning i deprovisioning użytkowników muszą być ściśle powiązane z procesami HR. Najczęstszym błędem w zarządzaniu tożsamością i dostępem (IAM) jest osierocone konto — konto byłego pracownika, które pozostaje aktywne tygodniami lub miesiącami po jego odejściu. Zautomatyzowany provisioning za pomocą SCIM (System for Cross-domain Identity Management) lub konektorów HR-do-AD, w połączeniu z obowiązkowymi listami kontrolnymi deprovisioningu, zamyka tę lukę.

Praktyczny Scenariusz: Kompromitacja Poświadczeń z Użyciem Osieroconego Konta

Zespół IT firmy produkcyjnej odkrył nietypowy dostęp do swojego systemu ERP poza godzinami pracy z konta usługowego, które zostało utworzone na potrzeby wycofanego już projektu integracyjnego. Konto miało uprawnienia użytkownika domenowego i nigdy nie było weryfikowane podczas kwartalnych przeglądów dostępu, ponieważ nie było powiązane z żadnym imiennym pracownikiem. Atakujący, który kupił poświadczenia ze zrzutu z dark webu, użył konta do wyliczenia (enumerate) udziałów plików, eksfiltracji danych cenowych i ustanowienia trwałego punktu zaczepienia za pomocą zaplanowanego zadania. Naruszenie zostało odkryte dopiero wtedy, gdy dostawca systemu ERP zasygnalizował anomalne wzorce wywołań API. Przyczyną źródłową był nieudany proces deprovisioningu — integracja została wycofana, ale konto nigdy nie zostało wyłączone. Wdrożenie systemu PAM z automatycznym wykrywaniem osieroconych kont i obowiązkowymi cyklami przeglądów ujawniłoby to konto na długo przed jego wykorzystaniem.

← Ład · Wszystkie domeny · Zagrożenia →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →