Cloud & IT Cert Prep · Lekcja

Tożsamość w chmurze: role IAM i konta usług

Tożsamość w chmurze: role IAM i konta usług to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Podstawy tożsamości w chmurze

W środowiskach chmurowych tożsamość jest nowym obwodem bezpieczeństwa. Każde działanie — uruchomienie maszyny wirtualnej, odczyt bazy danych czy wywołanie API — jest autoryzowane na podstawie tożsamości wywołującej. Systemy Cloud IAM (Identity and Access Management) definiują, kto może zrobić co i w odniesieniu do których zasobów. W przeciwieństwie do środowisk lokalnych, w których lokalizacja w sieci zapewniała domyślne zaufanie, Cloud IAM traktuje każde żądanie jako wymagające jawnej autoryzacji, niezależnie od miejsca jego pochodzenia.

Użytkownicy, grupy i role w AWS IAM

AWS IAM ma trzy podstawowe typy tożsamości. Użytkownicy IAM reprezentują poszczególne osoby lub aplikacje i mają długoterminowe dane uwierzytelniające (klucz dostępu + klucz tajny). Grupy IAM łączą użytkowników i przypisują im wspólne uprawnienia. Role IAM to tożsamości z tymczasowymi danymi uwierzytelniającymi, które mogą przyjmować użytkownicy, usługi AWS (EC2, Lambda) lub inne konta. Role są preferowane względem długoterminowych kluczy dostępu, ponieważ ich dane uwierzytelniające automatycznie wygasają, zmniejszając ryzyko ich ujawnienia.

# IAM role trust policy — allows EC2 to assume this role
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': { 'Service': 'ec2.amazonaws.com' },
    'Action': 'sts:AssumeRole'
  }]
}

# EC2 instance with this role attached can call AWS APIs
# using temporary credentials from the instance metadata service

Minimalne uprawnienia w zasadach IAM

Zasady IAM definiują, jakie działania tożsamość może wykonywać na określonych zasobach. Zasada minimalnych uprawnień wymaga, aby zasady przyznawały wyłącznie konkretne działania niezbędne do wykonania zadania. Częste naruszenia tej zasady to: używanie symboli wieloznacznych * w działaniach (przyznaje wszystkie działania w usłudze), używanie * w zasobach (przyznaje dostęp do wszystkich zasobów) oraz przypisywanie kontom usług nadmiernie szerokich zarządzanych zasad, takich jak AdministratorAccess. Każdy symbol wieloznaczny należy uzasadnić i regularnie przeglądać.

# Overly permissive policy (AVOID)
{
  'Effect': 'Allow',
  'Action': 's3:*',      # all S3 actions
  'Resource': '*'         # all buckets
}

# Least-privilege policy (PREFERRED)
{
  'Effect': 'Allow',
  'Action': ['s3:GetObject', 's3:ListBucket'],
  'Resource': [
    'arn:aws:s3:::my-specific-bucket',
    'arn:aws:s3:::my-specific-bucket/*'
  ]
}

Konta usługowe w GCP

W Google Cloud Platform (GCP) obciążenia inne niż ludzkie uwierzytelniają się za pomocą kont usługowych — zarządzanych obiektów tożsamości z plikami kluczy JSON lub funkcją Workload Identity Federation. Każde konto usługowe powinno być zgodne z zasadą minimalnych uprawnień: należy przypisać mu dostęp wyłącznie do usług GCP, z których musi korzystać. Klucze kont usługowych (pliki JSON pobierane z konsoli) to dane uwierzytelniające o długim czasie ważności, które należy traktować jak hasła — regularnie je rotować i nigdy nie umieszczać w kodzie źródłowym ani nie przesyłać do publicznych repozytoriów.

# Check service account permissions (gcloud)
gcloud projects get-iam-policy my-project \
  --flatten='bindings[].members' \
  --format='table(bindings.role, bindings.members)' \
  --filter='bindings.members:serviceAccount'

# Prefer Workload Identity over service account keys
# (no downloadable key files — uses workload federation tokens)

Zarządzane tożsamości platformy Azure

Zarządzane tożsamości platformy Azure (dawniej MSI) są odpowiednikiem ról AWS IAM dla usług — umożliwiają zasobom platformy Azure (maszynom wirtualnym, App Services i Functions) uwierzytelnianie się względem interfejsów API platformy Azure bez przechowywania danych uwierzytelniających. Istnieją dwa typy: tożsamości zarządzane przypisane przez system są powiązane z konkretnym zasobem i usuwane wraz z jego usunięciem. Tożsamości zarządzane przypisane przez użytkownika są samodzielnymi obiektami, które można współdzielić między wieloma zasobami. Zarządzane tożsamości eliminują potrzebę przechowywania kluczy i wpisów tajnych.

# Azure CLI — assign managed identity to a VM
az vm identity assign \
  --name myVM \
  --resource-group myRG \
  --identities /subscriptions/.../userAssignedIdentities/myIdentity

# The VM can now call Azure Key Vault without any stored credentials:
# Token is fetched automatically from the Instance Metadata Service

Dane uwierzytelniające o długim czasie ważności: zagrożenie

Dane uwierzytelniające o długim czasie ważności — statyczne klucze dostępu, tokeny API i pliki kluczy kont usługowych, które nigdy nie wygasają — należą do elementów o najwyższym ryzyku w środowiskach chmurowych. Jeśli wyciekną (na przykład przez GitHub, zasobnik S3, dzienniki lub przejęty laptop dewelopera), zapewniają natychmiastowy dostęp do czasu ich ręcznego unieważnienia. Organizacje powinny: kontrolować wszystkie dane uwierzytelniające o długim czasie ważności, rotować je zgodnie z harmonogramem, preferować dostęp oparty na rolach lub federacji, który zapewnia tokeny krótkotrwałe, oraz natychmiast generować alerty, gdy dane uwierzytelniające pojawią się w publicznych repozytoriach.

# Find IAM access keys older than 90 days (AWS)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | \
  base64 -d | grep -v 'N/A' | \
  awk -F',' '$10 > 90 {print $1, $10}'

# Keys older than 90 days should be rotated or deleted

Łańcuchowanie ról IAM i eskalacja uprawnień

Eskalacja uprawnień IAM zachodzi wtedy, gdy tożsamość wykorzystuje kombinację uprawnień, aby nadać sobie dodatkowe uprawnienia. Klasyczne ścieżki eskalacji obejmują: przypisanie do własnego użytkownika zasad o szerszych uprawnieniach, utworzenie nowego użytkownika IAM z podwyższonymi uprawnieniami, przekazanie roli (iam:PassRole) usłudze oraz zaktualizowanie roli wykonawczej funkcji Lambda. AWS IAM Access Analyzer może wykrywać takie wzorce, a granice uprawnień IAM mogą rygorystycznie ograniczać maksymalny zakres uprawnień, jaki można nadać dowolnej tożsamości.

# Dangerous permission combination (enables privilege escalation):
# iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion
# Attacker can create a new policy version with AdministratorAccess

# Or: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
# Attacker creates Lambda with a privileged role, invokes it

# Defense: permission boundaries limit maximum grantable permissions

Przyjmowanie ról między kontami

Organizacje chmurowe często używają wielu kont (dev, staging, prod, security) jako granic ograniczających zasięg potencjalnego ataku. Przyjmowanie ról między kontami umożliwia tożsamościom z jednego konta przyjmowanie ról na innym koncie — dzięki temu scentralizowane narzędzia mogą działać w wielu kontach. Środki bezpieczeństwa obejmują: wymaganie External ID w zasadzie zaufania w celu zapobiegania atakom typu confused deputy, ograniczenie kont, które mogą przyjmować rolę, za pomocą identyfikatora ARN podmiotu Principal oraz rejestrowanie wszystkich operacji przyjmowania ról między kontami w CloudTrail na potrzeby audytu.

# Trust policy with External ID (confused deputy protection)
{
  'Effect': 'Allow',
  'Principal': { 'AWS': 'arn:aws:iam::PARTNER-ACCOUNT-ID:root' },
  'Action': 'sts:AssumeRole',
  'Condition': {
    'StringEquals': {
      'sts:ExternalId': 'unique-shared-secret-12345'
    }
  }
}

Bezpieczeństwo IMDS i usługi metadanych

Instancje AWS EC2 mogą pobierać dane uwierzytelniające swojej roli IAM z Instance Metadata Service (IMDS) pod adresem http://169.254.169.254. Klasa podatności SSRF jest w tym przypadku szczególnie niebezpieczna: jeśli aplikacja jest podatna na SSRF, atakujący może wykraść dane uwierzytelniające roli IAM instancji, nakazując serwerowi pobranie danych z adresu URL IMDS. IMDSv2 (wymagająca tokenu sesji) ogranicza kradzież danych uwierzytelniających za pomocą SSRF i powinna być wymuszana na wszystkich instancjach EC2.

# Enforce IMDSv2 on a new EC2 instance (requires token for IMDS)
aws ec2 run-instances \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  ...

# IMDSv1 (insecure) just needs a GET request:
# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a PUT to get a session token first

IAM Access Analyzer i przegląd zasad

IAM Access Analyzer (AWS) automatycznie identyfikuje zasoby udostępnione zewnętrznym podmiotom oraz zasady IAM przyznające szerszy dostęp, niż zamierzano. Analizuje zasady zasobników, zasady zaufania ról i zasady kluczy KMS, aby oznaczać dostęp zewnętrzny, który nie był wyraźnie zamierzony. Regularne przeglądy zasad IAM — ręczne lub przeprowadzane za pomocą narzędzi takich jak Cloudsplaining, PMapper czy Permissions Boundary Analyzer — są niezbędne do identyfikowania ścieżek eskalacji uprawnień, zanim odkryją je atakujący.

Federacja tożsamości obciążeń

Workload Identity Federation umożliwia zewnętrznym obciążeniom (GitHub Actions, systemom lokalnym i dostawcom innych chmur) uwierzytelnianie się względem chmurowego IAM za pomocą krótkotrwałych tokenów OIDC zamiast kluczy kont usługowych o długim czasie ważności. Przepływ pracy GitHub Actions może przyjąć rolę AWS IAM, używając swojego tokenu OIDC przez czas trwania zadania, po czym token wygasa. Takie podejście eliminuje całą klasę wycieków danych uwierzytelniających o długim czasie ważności z potoków CI/CD.

Szybkie sprawdzenie

Sprawdź swoją wiedzę na temat zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji nauczyli się Państwo, że: role IAM zapewniają tymczasowe dane uwierzytelniające i są preferowane zamiast kluczy dostępu o długim czasie ważności w przypadku obciążeń chmurowych, zasady minimalnych uprawnień powinny unikać symboli wieloznacznych i przyznawać wyłącznie określone działania dla określonych zasobów, a także że IMDSv2, granice uprawnień i federacja tożsamości obciążeń eliminują typowe ścieżki ujawniania danych uwierzytelniających. Następnie omówimy Cloud Security Posture Management (CSPM).

Często zadawane pytania

Czy lekcja „Tożsamość w chmurze: role IAM i konta usług” jest bezpłatna?

Tak — pełny tekst „Tożsamość w chmurze: role IAM i konta usług” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Tożsamość w chmurze: role IAM i konta usług”?

Skonfigurują Państwo role IAM i konta usług zgodnie z zasadą minimalnych uprawnień na platformach chmurowych oraz unikną typowych błędów, takich jak uprawnienia z symbolami wieloznacznymi i klucze dł… Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?

Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Tożsamość w chmurze: role IAM i konta usług”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?

Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Model współodpowiedzialności: IaaS, PaaS, SaaS
Bezpieczeństwo pamięci masowej w chmurze i ryzyko ujawnienia danych
Tożsamość w chmurze: role IAM i konta usług
Zarządzanie stanem bezpieczeństwa chmury (CSPM)

← Powrót do Cloud & IT Cert Prep