IAM (Identity and Access Management) är den viktigaste säkerhetskomponenten i molnet. Denna guide täcker best practices för IAM i AWS, Azure och GCP – least privilege, roller vs användare, policies, federation, access analyzers, permission boundaries och SCIM.
Identity and Access Management (IAM) är grunden för all säkerhet i molnet. Oavsett om du använder AWS, Azure eller GCP är IAM den första försvarslinjen – det styr vem som får göra vad med dina molnresurser. Ändå är IAM en av de mest missförstådda och felkonfigurerade tjänsterna i molnet, och orsaken till en stor andel av alla molnsäkerhetsincidenter.
Den här guiden ger dig en komplett genomgång av IAM best practices som fungerar över alla tre stora molnplattformar. Jag har granskat IAM-konfigurationer för allt från startups till storföretag och ser samma misstag om och om igen – överprivilegierade roller, långlivade access keys och bristande automatisering. Här är vad du behöver veta.
IAM – grundläggande koncept i AWS, Azure och GCP
AWS IAM är den mest mogna IAM-tjänsten av de tre. AWS IAM använder användare, grupper och roller. En IAM-användare är en permanent identitet (människa eller service account). En IAM-roll är en temporär identitet som antas av användare, tjänster eller federation. Policies är JSON-dokument (eller AWS-hanterade) som definierar åtkomst.
Azure använder Microsoft Entra ID (tidigare Azure AD) som identitetsplattform. Azure RBAC (Role-Based Access Control) styr åtkomst till Azure-resurser via rolltilldelningar (role assignments) som består av en säkerhetsobjekt (användare, grupp, tjänsthuvudnamn), en rolldefinition (ägare, bidragsgivare, läsare) och ett scope (hanteringsgrupp, prenumeration, resursgrupp, resurs).
GCP använder Google Cloud IAM med roller som kan vara fördefinierade (roles/viewer, roles/editor, roles/owner) eller anpassade. GCP IAM har en unik approach med resource hierarchy (Organization -> Folder -> Project -> Resource) där policyer ärvs nedåt. GCP saknar permanenta användare i samma mening som AWS – identiteter är Google-konton, service accounts eller Google Groups.
Least privilege – principen som räddar dig
Principen om least privilege innebär att varje identitet (användare, roll, tjänst) ska ha endast de behörigheter som krävs för att utföra sin uppgift – varken mer eller mindre. Detta minskar skadeverkan vid en kompromettering och minskar risken för oavsiktliga ändringar. Det låter enkelt, men i praktiken är det svårt att implementera korrekt.
AWS IAM Access Analyzer genererar policy-förslag baserade på faktisk användning. Aktivera det på dina roller och användare – det identifierar överprivilegierade policies och föreslår snävare alternativ. Azure har samma funktion i Microsoft Entra Permissions Management (CIEM) och Azure Policy. GCP har Policy Analyzer och Recommender för samma syfte.
Börja med en restriktiv policy (deny all) och lägg till specifika tillåtelser efter behov. Använd AWS IAM policy simulator, Azure What If Tool eller GCP Policy Troubleshooter för att testa policies innan de appliceras. Granska och revidera policies minst kvartalsvis – behov ändras, roller ackumulerar onödiga rättigheter över tid.
Roller vs användare – när använder du vad?
IAM roller är alltid att föredra framför IAM-användare för arbetsbelastningar och tjänster. Roller ger temporära autentiseringsuppgifter (via AWS STS, Azure Managed Identity, GCP Service Account) som roteras automatiskt. IAM-användare med långlivade access keys är en säkerhetsrisk – nycklar läcker, roteras inte, och förblir giltiga i åratal.
Använd IAM-roller för: EC2-instanser (Instance Profile), Lambda-funktioner (Execution Role), ECS-tasks (Task Role), Kubernetes (Service Account with IAM), och CI/CD-pipelines (OIDC-federation). Använd IAM-användare endast för människor – och helst med federation (SSO) i stället för separata IAM-användare.
För mänskliga användare: använd Azure AD/Entra ID som central identitetsleverantör och federera åtkomst till AWS och GCP. Använd AWS IAM Identity Center (tidigare SSO) för att ge Entra ID-användare åtkomst till AWS-konton. Använd GCP Workforce Identity Federation för att federera Entra ID till GCP. Detta ger central användarhantering, enhetlig autentiseringsupplevelse och automatisk avaktivering vid medarbetaravslut.
Policies – strukturera och organisera
IAM policies i AWS är JSON-dokument som består av en eller flera statements med Effect (Allow/Deny), Action (lista över tjänster och operationer), Resource (ARN eller wildcard) och Condition (valfria villkor som IP-adress, tidpunkt, MFA-status). AWS utvärderar policies i följande ordning: explicit Deny > explicit Allow > implicit Deny.
Skapa anpassade policies i stället för att använda AWS-hanterade FullAdmin-policyer. Bryt ner policies per funktion: en policy för S3-läsning, en för DynamoDB-skrivning, etc. Använd taggar som styrparameter – ge åtkomst baserat på resurstagg (t.ex. `iam:ResourceTag/Environment=production`). Detta förenklar administrationen och gör policies mer återanvändbara.
Använd permission boundaries i AWS för att begränsa maxbehörigheterna för en användare eller roll. Permission boundaries sätter en övre gräns – även om en policy ger full admin-åtkomst, kan användaren inte överskrida permission boundary. Detta är användbart för att ge utvecklingsteam självbetjäning inom definierade gränser.
Service accounts i molnet
Service accounts (AWS IAM-roll, Azure Managed Identity, GCP Service Account) används av applikationer och tjänster för att autentisera sig mot moln-API:er. En Azure Managed Identity är en Azure AD-identitet som automatiskt hanteras av Azure och kan kopplas till en Azure-resurs (VM, App Service, Functions). Managed Identity eliminerar behovet av att hantera credentials i din applikation.
GCP Service Accounts är JSON-nyckelpar som används av applikationer. Ladda ner nyckelfilen en gång och lagra den säkert (i Secrets Manager, inte i källkod). GCP Workload Identity Federation låter dig ersätta långlivade service account-nycklar med temporära tokens från externa identitetsleverantörer (GitHub Actions, GitLab CI, AWS, Azure AD).
Bästa praxis: en service account per applikation/komponent, inte en delad service account för flera applikationer. Rotera nycklar regelbundet (minst var 90:e dag). Använd Workload Identity Federation när möjligt – det eliminerar behovet av långlivade nycklar helt.
OIDC-federation – moderna CI/CD utan hemligheter
OIDC (OpenID Connect) federation låter dig ge CI/CD-plattformar (GitHub Actions, GitLab CI, CircleCI) temporär åtkomst till dina molnkonton utan att lagra långlivade hemligheter. CI/CD-flödet använder OIDC-tokens från sin plattform för att byta mot moln-credentials via AWS STS, Azure OIDC eller GCP Workload Identity Federation.
AWS: konfigurera en OIDC-identitetsleverantör i IAM som pekar på GitHub Actions OIDC-provider. Skapa en IAM-roll med en trust policy som begränsar åtkomst till specifika repos och grenar. GitHub Actions använder `aws-actions/configure-aws-credentials` för att byta OIDC-token mot temporära AWS-credentials.
Azure: använd federated identity credentials för att ge GitHub Actions åtkomst till Azure-resurser. Skapa en app registration i Entra ID, konfigurera federerad identitetscredential för GitHub, och tilldela RBAC-roller till app registrationen. GCP: använd Workload Identity Federation med en workload identity pool och provider som pekar på GitHub Actions.
Access analyzers och permission boundaries
AWS IAM Access Analyzer analyserar dina policies och resurser för att identifiera åtkomst som delas med externa entiteter (andra konton, offentlig åtkomst). Den upptäcker även oanvända behörigheter och föreslår snävare policies. Aktivera Access Analyzer på organisationsnivå för att få en helhetsbild över alla konton.
Azure har Microsoft Entra Permissions Management (CIEM) som ger en komplett bild av identitetsbehörigheter över Azure, AWS och GCP. Det identifierar överprivilegierade identiteter, oanvända behörigheter, och riskfyllda åtkomstvägar. GCP Policy Analyzer och Recommender ger motsvarande funktionalitet – rekommenderar roller och policies baserat på faktisk användning.
Permission boundaries (AWS) och exclusion scopes (Azure) låter dig sätta en övre gräns för vilka behörigheter en användare/roll kan ha. Detta är viktigt i multi-team-miljöer där du vill ge team självbetjäning utan att ge dem full kontroll. En utvecklare kan skapa valfria resurser men inte eskalera sina egna privilegier bortom permission boundary.
SCIM – automatisk identitetshantering
SCIM (System for Cross-domain Identity Management) automatiserar synkronisering av användarkonton mellan din identitetsleverantör (Entra ID, Okta, OneLogin) och molntjänster. När en anställd avslutas i HR-systemet, inaktiveras deras konton automatiskt i AWS, Azure, GCP, Salesforce, Slack och alla andra SCIM-anslutna tjänster.
AWS IAM Identity Center stöder SCIM-integrering med Entra ID och Okta. Användare och grupper synkroniseras automatiskt från Entra ID till AWS. När en användare tas bort från Entra ID, försvinner deras AWS-åtkomst inom minuter. Azure AD (Entra ID) har inbyggt SCIM-stöd för tusentals applikationer via Enterprise Applications.
GCP stöder SCIM via Google Cloud Directory Sync (GCDS). GCDS synkroniserar användare och grupper från din LDAP-katalog (AD) till Google Cloud Identity. Kombinera SCIM med automatisk borttagning av inaktiva konton (90 dagar utan inloggning) och automatisk rotation av service account-nycklar.
IAM för containers
IAM för containers kräver en annan approach än traditionell IAM. I AWS EKS använder du IAM Roles for Service Accounts (IRSA) – varje Kubernetes service account kan associeras med en IAM-roll. Podden får temporära AWS-credentials via OIDC-federation mellan EKS och IAM. Detta ger granular IAM per pod, inte per nod.
Azure använder Workload Identity för AKS – varje Kubernetes service account kan associeras med en Azure Managed Identity. Podden byter ut sin service account-token mot en Azure AD-token via OIDC-federation. GCP använder GKE Workload Identity Federation för samma syfte – varje Kubernetes service account motsvarar en GCP service account.
Använd aldrig enbart nodens IAM-roll för pods – det bryter mot least privilege och gör att alla pods på samma nod har samma åtkomst. Implementera kontinuerlig övervakning av IAM med verktyg som CloudSploit, ScoutSuite eller kommersiella CIEM-lösningar.
Sammanfattning: IAM best practices
- Använd roller i stället för användare för arbetsbelastningar – undvik långlivade credentials.
- Federera mänskliga användare med Entra ID eller Okta – en identitetskälla för allt.
- Implementera OIDC-federation för CI/CD – inga hemligheter i pipelines.
- Använd access analyzers och recommender-verktyg för att identifiera överprivilegierade roller.
- Använd permission boundaries för att begränsa max-behörigheter i multi-team-miljöer.
- Använd SCIM för automatisk synkronisering och avaktivering av användarkonton. 7. Implementera IAM för containers (IRSA, Workload Identity) – per pod, inte per nod.
- Rotera nycklar regelbundet – minst var 90:e dag för service accounts.
- Använd conditions i policies för att begränsa åtkomst baserat på IP, MFA, tid och taggar.
- Granska IAM-konfiguration minst kvartalsvis och efter varje organisationsförändring.
IAM är den viktigaste säkerhetskomponenten i molnet. Investera tid i att få det rätt från början – det förebygger de flesta molnsäkerhetsincidenter och gör din molnmiljö både säkrare och enklare att administrera.
Vill du ha hjälp med IAM-säkerhet?
Jag hjälper företag att granska och förbättra IAM-konfigurationer i AWS, Azure och GCP. Läs mer om säkerhetstjänster eller boka ett samtal.
“IAM är den första försvarslinjen i molnet. Rätt konfigurerat förhindrar det de flesta incidenter – felaktigt konfigurerat är det den vanligaste orsaken till dataintrång.”
- Simon Axelsson
Vanliga frågor
- Vad är skillnaden mellan en IAM-roll och en IAM-användare?
- En IAM-användare är en permanent identitet med långlivade credentials (access key/secret key eller lösenord). En IAM-roll är en temporär identitet som antas via STS (Security Token Service) – credentials är giltiga i max 1 timme (standard) och roteras automatiskt. Roller är alltid att föredra för applikationer och tjänster.
- Hur implementerar jag least privilege i AWS?
- Börja med en Deny-all-policy och lägg till specifika Allow per funktion. Använd IAM Access Analyzer för att generera policy-förslag baserat på faktisk användning. Använd permission boundaries för att begränsa max-behörigheter. Testa policies med IAM Policy Simulator innan de appliceras. Granska och revidera kvartalsvis.
- Vad är OIDC-federation och varför är det viktigt?
- OIDC-federation låter CI/CD-plattformar (GitHub Actions, GitLab CI) autentisera sig mot moln API:er utan långlivade hemligheter. Plattformen skickar en OIDC-token som molnleverantören kan verifiera och byta mot temporära credentials. Detta eliminerar risken att hemligheter läcker via commits, logs eller artifacts.
- Hur hanterar jag IAM för många AWS-konton?
- Använd AWS Organizations + IAM Identity Center (SSO). Skapa en central identitetskälla (Entra ID eller Okta), federera med IAM Identity Center med SCIM, och tilldela behörigheter per konto baserat på gruppmedlemskap. Använd permission boundaries per konto för att begränsa vad lokala administratörer kan göra.
- Vad är en service account och hur skiljer den sig mellan molnen?
- En service account är en icke-mänsklig identitet som används av applikationer. AWS: IAM-roll (assumeras av EC2, Lambda, ECS). Azure: Managed Identity (automatiskt kopplad till Azure-resurser) eller Enterprise Application. GCP: Service Account (JSON-nyckel eller Workload Identity Federation). Alla tre bör använda temporära credentials och Workload Identity Federation när möjligt.
Om författaren
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar av Simon