{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/cloud-iam","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/cloud-iam/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/cloud-iam/"},"term":{"en":"Cloud IAM","da":"Cloud IAM"},"aka":{"en":["cloud identity and access management"],"da":["cloud-identitets- og adgangsstyring"]},"domain":["platform","security"],"cluster":"cloud","layer":"identity","status":"current","era":2011,"summary":{"en":"The cloud provider's built-in system of policies that decides which users, roles and service accounts may do what to each resource.","da":"Cloududbyderens indbyggede system af politikker, der afgør, hvilke brugere, roller og servicekonti der må gøre hvad ved hver ressource."},"body":{"formal":{"en":"A service run by the cloud provider in which the customer writes policies binding an identity to the actions it may take on named resources; the provider checks them on every request and refuses anything not granted.","da":"En tjeneste, som cloududbyderen driver, hvor kunden skriver politikker, der kobler en identitet til de handlinger, den må udføre på navngivne ressourcer; udbyderen tjekker dem ved hver forespørgsel og afviser alt, der ikke er givet lov til."},"plain":{"en":"Like the key card system in an office building - one central list says whose card opens which doors, and every door checks that list each time.","da":"Som adgangskortsystemet i en kontorbygning - én central liste siger, hvis kort åbner hvilke døre, og hver dør tjekker listen hver gang."},"inPractice":{"en":"At a pension fund, the cloud architect gives the nightly backup job a service account that may only write to one storage bucket, and gives developers a role that can read logs but not delete databases.","da":"I en pensionskasse giver cloudarkitekten det natlige backupjob en servicekonto, der kun må skrive til én bestemt bucket, og udviklerne en rolle, der kan læse logs, men ikke slette databaser."},"whyItMatters":{"en":"The rights are the customer's job, not the provider's, and one policy that grants too much can open every resource in an account to whoever gets hold of it.","da":"Rettighederne er kundens ansvar, ikke udbyderens, og én politik, der giver for meget, kan åbne alle ressourcer på en konto for den, der får fat i den."}},"deepDive":{"en":"Every cloud IAM system evaluates the same four elements per API request: a principal (human user, group, federated identity or workload identity such as an AWS IAM role, a Google Cloud service account or an Azure managed identity), an action (a service-namespaced operation like s3:GetObject), a resource (an ARN in AWS, a full resource name in Google Cloud, a scope path in Azure) and optional conditions (source network, MFA present, tags, time). Authentication of the caller comes first, via a signed request or an OAuth 2.0 access token; authorisation then runs on every call, and the default outcome is an implicit deny.\n\nThe combination logic differs by provider. In AWS an explicit Deny in any applicable policy always wins; otherwise the request needs an Allow from an identity-based or resource-based policy, and it must also fall within every ceiling that applies: Organizations service control policies, permissions boundaries and session policies grant nothing themselves but cap what can be granted. Cross-account access needs an Allow on both sides. Google Cloud binds roles (bundles of permissions) to principals in allow policies at organisation, folder, project or resource level, inherited downwards as a union, with separate deny policies and IAM Conditions to restrict. Azure RBAC uses role assignments made of principal, role definition and scope (management group, subscription, resource group, resource), also inherited downwards; Microsoft Entra ID directory roles are a separate system, a frequent source of confusion.\n\nTypical privilege-escalation paths come from permissions that look harmless: iam:PassRole lets a user attach a powerful role to compute they control, iam:CreatePolicyVersion lets them rewrite their own policy, and write access to a function's code inherits the function's role. Trust policies are another weak point, for example an OIDC federation for CI pipelines that omits a condition on the token's sub claim and therefore trusts every repository on the platform, or a third-party role without sts:ExternalId, which opens the confused-deputy problem. Credentials stolen from the instance metadata service via SSRF are a classic route to abusing an over-permissive role.\n\nIn practice, least privilege is approached iteratively: start from provider-managed roles, then narrow using policies generated from access logs (AWS IAM Access Analyzer, Google Cloud's role recommendations), replace long-lived access keys with short-lived credentials from STS or workload identity federation, and review with CIEM tools that compute effective permissions across all layers. The CIS Foundations Benchmarks for each provider contain concrete IAM checks such as MFA on the root account and no root access keys. Cloud IAM should be distinguished from the workforce identity provider (Entra ID, Okta and similar): the IdP authenticates people, usually federated in via SAML 2.0 or OpenID Connect, while cloud IAM authorises calls against the provider's API.","da":"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.\n\nLogikken 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.\n\nTypiske 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.\n\nI 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."},"edges":[{"type":"requires","to":"platform/cloud-computing","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/access-control","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/authorization","confidence":"high","strength":"normal"},{"type":"implements","to":"security/access-management","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/least-privilege","why":{"en":"Cloud IAM policies are where the rule of granting only the rights needed is actually put into effect for cloud resources.","da":"Det er i Cloud IAM-politikkerne, at princippet om kun at give de nødvendige rettigheder faktisk føres ud i livet for cloudressourcer."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/service-account","confidence":"high","strength":"normal"}],"depth":6,"sources":[{"title":"AWS Identity and Access Management - User Guide","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html","tier":"official-doc","publisher":"Amazon Web Services"},{"title":"Google Cloud - IAM overview","url":"https://cloud.google.com/iam/docs/overview","tier":"official-doc","publisher":"Google"},{"title":"Azure role-based access control (Azure RBAC) - Overview","url":"https://learn.microsoft.com/en-us/azure/role-based-access-control/overview","tier":"official-doc","publisher":"Microsoft"}],"draft":true}