Cloud IAM

Alle cloud-IAM-systemer vurderer de samme fire elementer ved hvert API-kald: en principal (menneskelig bruger, gruppe, fødereret identitet eller workload-identitet som en AWS IAM-rolle, en Google Cloud-servicekonto eller en Azure managed identity), en handling (en operation navngivet efter tjeneste, fx s3:GetObject), en ressource (en ARN i AWS, et fuldt ressourcenavn i Google Cloud, en scope-sti i Azure) og eventuelle betingelser (netværk, om MFA er brugt, tags, tidspunkt). Først autentificeres kalderen via en signeret forespørgsel eller et OAuth 2.0-adgangstoken; derefter kører autorisationen ved hvert eneste kald, og standardresultatet er en implicit afvisning.

Logikken for at kombinere politikker varierer mellem udbyderne. I AWS vinder en eksplicit Deny i en hvilken som helst gældende politik altid; ellers kræver forespørgslen en Allow fra en identitetsbaseret eller ressourcebaseret politik, og den skal samtidig ligge inden for alle gældende lofter: service control policies i Organizations, permissions boundaries og session policies giver ingen rettigheder selv, men begrænser, hvad der kan gives. Adgang på tværs af konti kræver Allow på begge sider. Google Cloud knytter roller (bundter af rettigheder) til principals i allow-politikker på organisations-, folder-, projekt- eller ressourceniveau, som nedarves nedad som en forening, mens deny-politikker og IAM Conditions begrænser. Azure RBAC bruger rolletildelinger bestående af principal, rolledefinition og scope (management group, abonnement, ressourcegruppe, ressource), som også nedarves; Microsoft Entra ID's katalogroller er et separat system, hvilket ofte skaber forvirring.

Typiske veje til rettighedseskalering kommer fra rettigheder, der ser harmløse ud: iam:PassRole lader en bruger knytte en stærk rolle til compute, vedkommende selv styrer, iam:CreatePolicyVersion lader brugeren omskrive sin egen politik, og skriveadgang til en funktions kode arver funktionens rolle. Trust policies er et andet svagt punkt, fx en OIDC-føderation til CI-pipelines uden betingelse på tokenets sub-claim, som derfor stoler på alle repositories på platformen, eller en tredjepartsrolle uden sts:ExternalId, som åbner for confused deputy-problemet. Loginoplysninger stjålet fra instansens metadata-tjeneste via SSRF er en klassisk vej til at misbruge en for bred rolle.

I praksis nærmer man sig mindste privilegium iterativt: man starter med udbyderens færdige roller, indsnævrer dem med politikker genereret ud fra adgangslogs (AWS IAM Access Analyzer, Google Clouds rolleanbefalinger), erstatter langlivede adgangsnøgler med kortlivede loginoplysninger fra STS eller workload identity federation og gennemgår med CIEM-værktøjer, der beregner de effektive rettigheder på tværs af alle lag. CIS Foundations Benchmarks for hver udbyder indeholder konkrete IAM-kontroller som MFA på root-kontoen og ingen adgangsnøgler til root. Cloud IAM skal skelnes fra organisationens identitetsudbyder (Entra ID, Okta og lignende): IdP'en autentificerer personer, typisk fødereret ind via SAML 2.0 eller OpenID Connect, mens cloud IAM autoriserer kald mod udbyderens API.