Cloudidentitet: IAM-roller og servicekonti
Konfigurér IAM-roller og servicekonti med mindst mulige privilegier på cloudplatforme, og undgå almindelige fejl som wildcard-tilladelser og nøgler med lang levetid.
Cloudidentitet: IAM-roller og servicekonti er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.
Grundlæggende om cloudidentitet
I cloudmiljøer er identitet den nye perimeter. Enhver handling – fra at starte en VM til at læse en database eller kalde en API – godkendes på grundlag af den kaldende identitet. Cloud-IAM-systemer (Identity and Access Management) definerer hvem der må gøre hvad på hvilke ressourcer. I modsætning til lokale miljøer, hvor netværksplaceringen gav implicit tillid, behandler cloud-IAM enhver anmodning som noget, der kræver eksplicit godkendelse, uanset hvor den kommer fra.
Brugere, grupper og roller i AWS IAM
AWS IAM har tre primære identitetstyper. IAM-brugere repræsenterer individuelle personer eller applikationer med legitimationsoplysninger med lang levetid (adgangsnøgle + hemmelig nøgle). IAM-grupper samler brugere og tildeler dem fælles tilladelser. IAM-roller er identiteter med midlertidige legitimationsoplysninger, som kan antages af brugere, AWS-tjenester (EC2, Lambda) eller andre konti. Roller foretrækkes frem for adgangsnøgler med lang levetid, fordi deres legitimationsoplysninger automatisk udløber, hvilket mindsker risikoen for eksponering.
# 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 serviceMindst mulige privilegier i IAM-politikker
IAM-politikker definerer, hvilke handlinger en identitet må udføre på hvilke ressourcer. Princippet om mindst mulige privilegier kræver, at politikker kun giver de specifikke handlinger, der er nødvendige for opgaven. Almindelige overtrædelser er brug af jokertegnet * for handlinger (giver alle handlinger i en tjeneste), brug af * for ressourcer (giver adgang til alle ressourcer) samt tilknytning af for bredt definerede administrerede politikker som AdministratorAccess til tjenestekonti. Ethvert jokertegn bør begrundes og gennemgås regelmæssigt.
# 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/*'
]
}Tjenestekonti i GCP
I Google Cloud Platform (GCP) godkender ikke-menneskelige arbejdsbelastninger deres identitet ved hjælp af tjenestekonti — administrerede identitetsobjekter med JSON-nøglefiler eller Workload Identity Federation. Hver tjenestekonto bør følge princippet om mindst mulige privilegier: Knyt den kun til de GCP-tjenester, den har brug for at kalde. Tjenestekontonøgler (JSON-filer, der downloades fra konsollen) er langtidsholdbare legitimationsoplysninger, som skal behandles som adgangskoder — de skal udskiftes regelmæssigt og må aldrig lægges i kildekode eller uploades til offentlige kodearkiver.
# 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)Azure-administrerede identiteter
Azure Managed Identities (tidligere MSI) er Azures modstykke til AWS IAM-roller for tjenester — de gør det muligt for Azure-ressourcer (VM'er, App Services, Functions) at godkende sig over for Azure-API'er uden at gemme legitimationsoplysninger. Der findes to typer: System-assigned administrerede identiteter er knyttet til en bestemt ressource og slettes, når ressourcen slettes. User-assigned administrerede identiteter er selvstændige objekter, der kan deles mellem flere ressourcer. Administrerede identiteter fjerner behovet for gemte nøgler eller hemmeligheder.
# 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 ServiceLangtidsholdbare legitimationsoplysninger: Risikoen
Langtidsholdbare legitimationsoplysninger — statiske adgangsnøgler, API-tokens og tjenestekontonøglefiler, der aldrig udløber — er blandt de mest risikable elementer i cloudmiljøer. Hvis de lækkes (via GitHub, en S3-bucket, logge eller en kompromitteret udviklerbærbar), giver disse legitimationsoplysninger øjeblikkelig adgang, indtil de tilbagekaldes manuelt. Organisationer bør: gennemgå alle langtidsholdbare legitimationsoplysninger, udskifte dem efter en fast plan, foretrække rollebaseret eller fødereret adgang, der udsteder korttidsholdbare tokens, og straks udløse en alarm, når legitimationsoplysninger vises i offentlige kodearkiver.
# 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 deletedKædning af IAM-roller og privilegieeskalering
IAM-privilegieeskalering sker, når en identitet kombinerer tilladelser for at give sig selv yderligere tilladelser. Klassiske eskaleringsveje omfatter: at knytte en mere tilladende politik til sin egen bruger, oprette en ny IAM-bruger med udvidede tilladelser, videregive en rolle (iam:PassRole) til en tjeneste og opdatere en Lambda-funktions udførelsesrolle. AWS's IAM Access Analyzer kan registrere disse mønstre, og IAM-tilladelsesgrænser kan sætte en hård øvre grænse for, hvilke maksimale tilladelser en identitet kan tildeles.
# 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 permissionsAntagelse af roller på tværs af konti
Cloud-organisationer bruger ofte flere konti (dev, staging, prod, sikkerhed) som grænser for påvirkningsområdet. Antagelse af roller på tværs af konti gør det muligt for identiteter i én konto at antage roller i en anden — så centraliserede værktøjer kan arbejde på tværs af konti. Sikkerhedskontroller omfatter: at kræve et External ID i tillidspolitikken for at forhindre angreb med en forvirret stedfortræder, begrænse hvilke konti der kan antage en rolle via Principal ARN og logge alle antagelser på tværs af konti i CloudTrail til revisionsformål.
# 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'
}
}
}IMDS og sikkerhed for metadatatjenesten
AWS EC2-instanser kan hente deres IAM-rollelegitimationsoplysninger fra Instance Metadata Service (IMDS) på http://169.254.169.254. Sårbarhedsklassen SSRF er særligt farlig her: Hvis en applikation er sårbar over for SSRF, kan en angriber eksfiltrere instansens IAM-rollelegitimationsoplysninger ved at få serveren til at hente data fra IMDS-URL'en. IMDSv2 (som kræver et sessionstoken) begrænser tyveri af legitimationsoplysninger via SSRF og bør håndhæves på alle EC2-instanser.
# 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 firstIAM Access Analyzer og gennemgang af politikker
IAM Access Analyzer (AWS) identificerer automatisk ressourcer, der er delt med eksterne principaler, samt IAM-politikker, der giver mere adgang end tilsigtet. Det analyserer bucket-politikker, tillidspolitikker for roller og KMS-nøglepolitikker for at markere ekstern adgang, som ikke udtrykkeligt var tilsigtet. Regelmæssige gennemgange af IAM-politikker — manuelt eller med værktøjer som Cloudsplaining, PMapper eller Permissions Boundary Analyzer — er afgørende for at identificere veje til privilegieeskalering, før angribere finder dem.
Workload Identity Federation
Workload Identity Federation gør det muligt for eksterne arbejdsbelastninger (GitHub Actions, lokale systemer og andre cloududbydere) at godkende sig over for cloud-IAM ved hjælp af korttidsholdbare OIDC-tokens i stedet for langtidsholdbare tjenestekontonøgler. Et GitHub Actions-arbejdsgangsforløb kan antage en AWS IAM-rolle ved hjælp af sit OIDC-token, så længe jobbet varer, hvorefter tokenet udløber. Denne tilgang eliminerer hele klassen af lækager af langtidsholdbare legitimationsoplysninger fra CI/CD-pipelines.
Hurtig kontrol
Afprøv din forståelse af CompTIA Security+-begreberne (SY0-701) fra denne lektion.
Opsummering af lektionen
I denne lektion har du lært, at: IAM-roller leverer midlertidige legitimationsoplysninger og foretrækkes frem for langtidsholdbare adgangsnøgler til cloud-arbejdsbelastninger, politikker med mindst mulige privilegier bør undgå jokertegn og kun give bestemte handlinger på bestemte ressourcer, og IMDSv2, tilladelsesgrænser og Workload Identity Federation fjerner almindelige veje til eksponering af legitimationsoplysninger. Dernæst undersøger vi Cloud Security Posture Management (CSPM).
Lær Cloud & IT Cert Prep med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 150
- Lektioner
- 600
Ofte stillede spørgsmål
Er lektionen “Cloudidentitet: IAM-roller og servicekonti” gratis?
Ja — hele teksten til “Cloudidentitet: IAM-roller og servicekonti” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Cloudidentitet: IAM-roller og servicekonti”?
Konfigurér IAM-roller og servicekonti med mindst mulige privilegier på cloudplatforme, og undgå almindelige fejl som wildcard-tilladelser og nøgler med lang levetid. Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?
Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.
Hvor lang tid tager lektionen “Cloudidentitet: IAM-roller og servicekonti”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?
Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Modellen for delt ansvar: IaaS, PaaS, SaaS
- Sikkerhed i cloudlagring og risiko for dataeksponering
- Cloudidentitet: IAM-roller og servicekonti
- Cloud Security Posture Management (CSPM)