Amazon SCS-C02: Zarządzanie tożsamością i dostępem — Przewodnik do nauki

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Część AWS Security Specialty SCS-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Tożsamości, podmioty (principals) i ewaluacja polityk

IAM rozróżnia tożsamości (użytkowników, grupy, role) i podmioty (principals), czyli uwierzytelnione jednostki wykonujące żądanie. Użytkownicy są długoterminowi i posiadają statyczne poświadczenia; role nie mają własnych poświadczeń i są przejmowane (assumed), aby uzyskać krótkoterminowe tokeny STS. Grupy to kontenery do dołączania polityk do użytkowników — nigdy nie są podmiotami (principals) i nie mogą być przejmowane.

Każde wywołanie API przechodzi przez deterministyczny łańcuch ewaluacji: jawne Deny (odmowa) w dowolnym miejscu ma pierwszeństwo, następnie SCP na poziomie organizacji muszą zezwalać, potem permissions boundaries muszą zezwalać, następnie polityki sesji (jeśli istnieją) muszą zezwalać, i na końcu co najmniej jedna polityka tożsamości lub zasobu musi zawierać Allow (zezwolenie). Brak jakiejkolwiek warstwy z Allow skutkuje niejawną odmową (implicit deny). Dlatego warstwowość ma znaczenie: polityka tożsamości przyznająca s3:* jest bezużyteczna, jeśli SCP odmawia s3:DeleteBucket lub permissions boundary całkowicie pomija S3.

Polityki bazujące na zasobach (resource-based policies), takie jak polityki bucketów S3, polityki kluczy KMS, polityki tematów SNS czy polityki funkcji Lambda, mogą przyznawać dostęp bezpośrednio podmiotowi (principal) bez żadnej polityki tożsamości po stronie wywołującej — w obrębie tego samego konta. W przypadku dostępu między kontami, zarówno polityka tożsamości na koncie źródłowym, jak i polityka zasobu na koncie docelowym muszą zezwalać na daną akcję.

Role, polityki zaufania (Trust Policies) i AssumeRole

Rola posiada dwa dokumenty polityk: politykę zaufania (trust policy) (kto może ją przejąć) oraz jedną lub więcej polityk uprawnień (permissions policies) (co można zrobić po jej przejęciu). Polityka zaufania jest polityką bazującą na zasobie (resource-based policy) dla samej roli, używającą akcji sts:AssumeRole. Bez pasującej polityki zaufania, wywołanie AssumeRole kończy się błędem AccessDenied, nawet jeśli wywołujący ma sts:AssumeRole w swojej polityce tożsamości.

W przypadku delegacji między kontami, polityka zaufania wskazuje zaufane konto lub konkretny ARN roli/użytkownika na tym koncie oraz — co jest kluczowe dla dostępu stron trzecich — wymusza użycie ExternalId:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId chroni przed problemem zdezorientowanego zastępcy (confused deputy): bez niego, zewnętrzny dostawca SaaS przejmujący role na wielu kontach klientów mógłby zostać oszukany i działać na roli niewłaściwego klienta. Pominięcie sts:ExternalId w warunku lub przekazanie nieprawidłowej wartości podczas wywołania sts:AssumeRole skutkuje błędem AccessDenied przy próbie przejęcia roli — jest to częsta błędna konfiguracja podczas wdrażania dostawców, takich jak narzędzia do monitoringu czy CSPM.

Dla usług AWS (Lambda, EC2, zadania ECS), polityka zaufania wskazuje podmiot usługi (service principal), np. "Service": "lambda.amazonaws.com". Funkcja Lambda potrzebująca dostępu do S3 powinna przejąć rolę wykonawczą (execution role), której polityka uprawnień przyznaje s3:GetObject i s3:PutObject na danym buckecie; alternatywnie, polityka bucketa S3 może wskazać ARN roli funkcji jako podmiot (principal). Każdy z tych mechanizmów działa samodzielnie w obrębie jednego konta.

Granice uprawnień (Permissions Boundaries)

Granica uprawnień (permissions boundary) to zaawansowana kontrola dołączana do użytkownika lub roli, która ogranicza maksymalne uprawnienia, jakie ta tożsamość może kiedykolwiek posiadać, niezależnie od tego, co przyznają polityki tożsamości. Efektywne uprawnienia to część wspólna (przecięcie) polityki tożsamości i granicy uprawnień. Jeśli polityka grupy przyznaje ec2:*, ale granica zezwala tylko na ec2:Describe*, użytkownik może jedynie wykonywać operacje typu describe.

Granice są powszechnie używane do delegowania uprawnień: pozwalają deweloperom tworzyć role IAM dla swoich aplikacji, ale wymagają, aby każda utworzona przez nich rola posiadała określoną granicę. Polityka IAM dla dewelopera zawiera warunek, taki jak "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary", dla akcji iam:CreateRole i iam:PutRolePolicy. Zapobiega to eskalacji uprawnień, jednocześnie umożliwiając samoobsługę (self-service).

Częstym nieporozumieniem jest przekonanie, że członkostwo w grupie lub dodatkowe dołączone polityki mogą „nadpisać” granicę uprawnień lub SCP. Nie mogą — granica i SCP to sufity (maksymalne uprawnienia), a nie podłogi (minimalne).

Wymuszanie MFA za pomocą warunków (Conditions)

Dwa klucze warunków (condition keys) sterują polityką MFA: aws:MultiFactorAuthPresent (wartość logiczna, true, jeśli sesja została uzyskana przy użyciu MFA) oraz aws:MultiFactorAuthAge (wartość numeryczna, sekundy od walidacji MFA). Wymuszanie MFA dla wrażliwych API i ograniczanie czasu życia sesji wygląda następująco:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Dwie godziny to 7200 sekund. Użycie BoolIfExists zamiast Bool jest subtelnie niebezpieczne dla wywołań od podmiotów usług (service principals), które nigdy nie zawierają tego klucza — warunek jest wtedy ewaluowany jako prawdziwy, co w praktyce omija sprawdzenie dla tych wywołujących. Dlatego preferuj Bool, gdy intencją jest wymuszenie MFA dla ludzkich użytkowników.

Ponieważ żądania z CLI i SDK używające długoterminowych kluczy dostępu nie przenoszą kontekstu MFA, użytkownicy muszą najpierw wywołać sts:GetSessionToken (z opcjami --serial-number i --token-code) lub sts:AssumeRole (z opcjami --serial-number/--token-code), aby uzyskać tymczasowe poświadczenia zawierające kontekst MFA. Te krótkoterminowe poświadczenia spełniają następnie warunek MultiFactorAuthPresent:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center i Federacja

IAM Identity Center (dawniej AWS SSO) centralizuje dostęp pracowników w całej organizacji AWS. Zestawy uprawnień to szablony, które Identity Center materializuje jako role IAM na każdym koncie docelowym, gdy przypisany jest użytkownik lub grupa. Przypisania łączą trzy elementy: podmiot zabezpieczeń (użytkownika lub grupę z katalogu Identity Center lub zewnętrznego dostawcy tożsamości (IdP), takiego jak Okta/Entra ID), zestaw uprawnień oraz jedno lub więcej kont.

Zestawy uprawnień mogą zawierać zasady zarządzane przez AWS, zasady zarządzane przez klienta (odwołujące się przez nazwę, więc muszą istnieć na każdym koncie docelowym), zasady wbudowane oraz granicę uprawnień. Gdy edytujesz zestaw uprawnień, Identity Center ponownie aprowizuje bazowe role — nigdy nie edytujesz tych ról bezpośrednio.

W przypadku federacji SAML poza Identity Center, AWS weryfikuje podpis asercji z metadanymi IdP zarejestrowanymi w obiekcie dostawcy SAML w IAM. Gdy IdP rotuje swój certyfikat podpisywania, wymagane jest przesłanie zaktualizowanych metadanych XML; w przeciwnym razie STS zwraca błąd InvalidIdentityToken / Response Signature Invalid. Aktualizacja metadanych za pomocą aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... jest naprawą o minimalnym narzucie — nie ma potrzeby ponownego tworzenia dostawcy ani rekonfiguracji relacji zaufania.

Konto Root, Raporty Poświadczeń i Zasada Najmniejszych Uprawnień

Użytkownik root ma nieusuwalny, pełny dostęp i musi być traktowany jako tożsamość awaryjna: włącz sprzętowe lub wirtualne urządzenie MFA, usuń wszelkie klucze dostępu użytkownika root, nie używaj go do codziennej pracy i przechowuj poświadczenia offline. Używaj zasad kontroli usług (SCP) na poziomie roota organizacji lub jednostki organizacyjnej (OU), aby uniemożliwić nawet administratorom na kontach członkowskich wyłączanie GuardDuty, usuwanie CloudTrail lub opuszczanie określonych regionów. SCP nigdy nie nadają uprawnień — filtrują jedynie to, co IAM na koncie członkowskim może przyznać.

Zasada najmniejszych uprawnień jest wdrażana za pomocą narzędzi, a nie intuicji. Wygeneruj raport poświadczeń IAM (aws iam generate-credential-report, a następnie get-credential-report), aby znaleźć nieużywanych użytkowników, starzejące się klucze dostępu i użytkowników bez MFA. Użyj IAM Access Analyzer, aby zidentyfikować zasady zasobów udostępniające dane między kontami oraz aby generować precyzyjnie dopasowane zasady na podstawie aktywności w CloudTrail. Użyj danych o ostatnim dostępie (aws iam get-service-last-accessed-details), aby usunąć nieużywane uprawnienia do usług z ról.

Ostatnia pułapka, którą warto wyraźnie nazwać: założenie, że dodanie zezwolenia (Allow) w tożsamości jest wystarczające. Jeśli zasada klucza KMS nie wymienia Twojej roli, SCP odmawia działania lub granica uprawnień ją pomija, wywołanie i tak zakończy się niepowodzeniem. Zawsze audytuj cały stos — SCP, granicę uprawnień, zasadę tożsamości, zasadę zasobu i zasadę sesji — podczas rozwiązywania problemów z AccessDenied.

Problem Praktyczny: Scenariusz Użycia

Scenariusz: Meridian Financial zarządza organizacją AWS składającą się z trzech kont dla obciążeń zarządczych, produkcyjnych i deweloperskich, z wrażliwymi danymi handlowymi i klienckimi na koncie produkcyjnym. Obecnie posiadają mieszankę starszych, długożyjących użytkowników IAM, kont kontraktorów oraz dostawcę tożsamości Okta SAML, co prowadzi do niespójnych kontroli dostępu i rozproszonych konfiguracji ról na różnych kontach.

Wyzwanie: Niedawny incydent dotyczył przejętych poświadczeń kontraktora, który przyjął rolę międzykontową bez MFA i wykonał nadmierne działania, ponieważ nie było granic uprawnień ani scentralizowanych zestawów uprawnień. Meridian musi wzmocnić federację, zaufanie ról oraz wdrożyć MFA i zasadę najmniejszych uprawnień na wszystkich kontach.

Zalecane Podejście:

1. Wdróż AWS IAM Identity Center zintegrowany z Okta SAML jako pojedynczą płaszczyznę tożsamości federacyjnej i zmigruj wszystkich ludzkich użytkowników i kontraktorów z długożyjących użytkowników IAM na konta oparte na Identity Center, wyłączając konsolę/klucze dla starszych użytkowników IAM.
2. Stwórz scentralizowane zestawy uprawnień w IAM Identity Center, które mapują się na role IAM na kontach członkowskich, i zaimplementuj granice uprawnień IAM (zdefiniowane jako zasady IAM) dla wszystkich ról; wdróż te granice i szablony ról na wszystkich kontach za pomocą AWS CloudFormation StackSets.
3. Zaktualizuj zasady zaufania ról międzykontowych, aby zezwalały na sts:AssumeRole tylko z numerów ARN podmiotów zabezpieczeń Identity Center i zawierały warunki wymagające MFA (np. aws:MultiFactorAuthPresent) oraz ograniczenia konta źródłowego; wymagaj, aby tagi sesji przenosiły atrybuty tożsamości.
4. Wymuś MFA na poziomie dostawcy tożsamości (IdP, czyli Okta) i odzwierciedlaj to wymuszenie w AWS, wymagając warunków MFA w sesjach ról; zablokuj tworzenie dostępu do konsoli lub nowych użytkowników IAM, stosując zasady kontroli usług (SCP) w AWS Organizations.
5. Włącz AWS CloudTrail, AWS Config i IAM Access Analyzer w celu ciągłego monitorowania i walidacji zasad, a wyniki wysyłaj do CloudWatch/GuardDuty w celu alertowania i uruchamiania zautomatyzowanych przepływów pracy naprawczej.

Uzasadnienie: Centralizacja federacji za pomocą IAM Identity Center, egzekwowanie zasady najmniejszych uprawnień za pomocą zestawów uprawnień i granic, wymaganie MFA w zasadach zaufania oraz stosowanie SCP na poziomie organizacji wraz z monitoringiem jest zgodne z najlepszymi praktykami AWS w celu zmniejszenia promienia rażenia, zapobiegania eskalacji uprawnień i zapewnienia audytowalności.

Role IAM i polityki zaufania: PassRole i AssumeRole

Rola IAM ma dwie odrębne płaszczyzny polityk, a ich mylenie jest główną przyczyną większości niepowodzeń autoryzacji między kontami. Polityka zaufania (AssumeRolePolicyDocument) określa, kto może przyjąć rolę i na jakich warunkach. Polityka uprawnień określa, co rola może zrobić po jej przyjęciu. Obie muszą zezwalać na daną akcję; sama polityka zaufania nigdy nie przyznaje dostępu do S3, KMS ani niczego innego.

Gdy podmiot (principal) wywołuje sts:AssumeRole, usługa STS ocenia politykę zaufania docelowej roli w kontekście tożsamości wywołującej oraz kontekstu sesji (źródłowy adres IP, stan MFA, tagi sesji, zewnętrzny identyfikator). Wywołujący podmiot musi również posiadać politykę tożsamości z regułą Allow dla akcji sts:AssumeRole na ARN tej roli. Ten podwójny wymóg sprawia, że przyjmowanie ról między kontami jest bezpieczne.

Kanoniczna polityka zaufania między kontami, która wymaga MFA i zewnętrznego ID, wygląda następująco:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

Klucz aws:MultiFactorAuthPresent ma znaczenie tylko w polityce zaufania roli, którą można przyjąć, ponieważ kontekst MFA jest ustanawiany podczas wywołania STS, a nie podczas późniejszych wywołań usług. Dodawanie warunków MFA do polityki bucketu S3 lub do polityki uprawnień roli jest częstym błędem: sesja przyjętej roli zazwyczaj nie przenosi atrybutu aws:MultiFactorAuthPresent=true, nawet jeśli pierwotny użytkownik uwierzytelnił się za pomocą MFA, więc takie warunki po cichu odmawiają wszystkich operacji. Wymuszaj MFA w momencie przyjmowania roli; użyj aws:MultiFactorAuthAge, aby wymusić ponowne uwierzytelnienie dla długotrwałych sesji.

PassRole to druga bramka, na której potykają się uczestnicy w scenariuszach egzaminacyjnych. Gdy zlecasz usłudze takiej jak CloudFormation, EC2, Lambda czy CodeBuild uruchomienie jako rola, tożsamość wywołująca musi mieć uprawnienie `iam:PassRole

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial zarządza wielokontową organizacją AWS Organization z oddzielnymi kontami dla środowisk produkcyjnych, deweloperskich i narzędzi CI/CD. Używają scentralizowanych ról IAM do wdrożeń między kontami oraz agentów CI firm trzecich, którzy przyjmują role w celu wprowadzania zmian w infrastrukturze.

Wyzwanie: Niedawny audyt wykazał, że zbyt szerokie uprawnienie iam:PassRole pozwoliło podmiotowi CI/CD przekazać rolę administratora do profilu instancji EC2, a atakujący wykorzystał zaufanie AssumeRole do uzyskania nadmiernych uprawnień na różnych kontach.

Zalecane podejście:

1. Użyj AWS CloudTrail i Amazon EventBridge do zidentyfikowania ostatnich wywołań API iam:PassRole i sts:AssumeRole, a następnie uruchom zapytania w CloudTrail Lake lub Athena, aby wyświetlić listę podmiotów, które przekazały określone ARN ról i kiedy to zrobiły.
2. Uruchom IAM Access Analyzer (dla IAM) na wszystkich kontach, aby odkryć luki w politykach zaufania opartych na zasobach i wyświetlić listę ról, które mogą być przyjęte spoza Organizacji lub przez zewnętrzne podmioty.
3. Zastąp szerokie polityki iam:PassRole politykami IAM o najniższych uprawnieniach, które określają dokładne ARN ról w polu Resource, i dodaj klucze warunkowe, takie jak aws:PassedToService lub aws:PrincipalOrgID, aby ograniczyć, kto i co może otrzymać rolę.
4. Wzmocnij polityki zaufania ról, aby wymagały warunków — użyj aws:PrincipalOrgID, sts:ExternalId dla firm trzecich, wymagaj aws:SourceIdentity i egzekwuj maksymalny czas trwania sesji — aby zapobiec szerokiemu stosowaniu AssumeRole przez nieznane podmioty.
5. Skonfiguruj reguły Amazon EventBridge do wykrywania anomalii w użyciu iam:PassRole i AssumeRole, wysyłaj alerty do Amazon SNS i twórz zautomatyzowane playbooki Lambda w celu unieważniania lub naprawiania zbyt szerokich polityk, a także zapisuj wyniki w AWS Security Hub i AWS Config w celu zapewnienia ciągłej zgodności.

Uzasadnienie: Takie podejście wymusza zasadę najniższych uprawnień (least privilege) i obrony w głąb (defense-in-depth) poprzez zacieśnienie celów PassRole i polityk zaufania, jednocześnie umożliwiając wykrywanie i automatyczne naprawianie problemów dzięki logowaniu i monitorowaniu — zgodnie z najlepszymi praktykami AWS dotyczącymi IAM i federacji.

Wszystkie domeny · Wykrywanie zagrożeń i alertowanie →

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

Przeglądaj Amazon →