Skip to content

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
Cloud Security Glossary

Cloud IAM (Identity and Access Management in der Cloud)

Cloud IAM manages identities and access rights in cloud environments (AWS, Azure, GCP). Overprivileged IAM roles are the most common cause of cloud data breaches. Best practices: least privilege, short-lived credentials, managed identities instead of access keys, regular access reviews, and automated policy analysis using cloud-native tools.

Cloud IAM refers to the management of identities, access rights, and permissions in cloud environments. Due to the complexity of modern cloud setups and the "Infrastructure as Code" paradigm, overprivileged roles and access keys often arise—the most common cause of serious cloud security incidents.

AWS IAM - Best Practices and Common Mistakes

AWS IAM - Basic Principles:

1. Secure the root account immediately:
   □ Enable MFA (immediately!)
   □ No access keys for root (Delete all root access keys!)
   □ Use root only for initial setup and emergencies
   □ Set up an alert for root logins (CloudWatch Event Rule)

2. Least Privilege for all IAM entities:
   Incorrect (over-privileged):
   {
     "Effect": "Allow",
     "Action": "*",
     "Resource": "*"
   }
   → "Administrator Access" for service = immediate super-blast radius of compromise!

   Correct (minimal permissions):
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject"
         ],
         "Resource": "arn:aws:s3:::my-specific-bucket/*"
       }
     ]
   }

3. Use IAM Access Analyzer:
   → Finds: external access to resources (other AWS accounts, public)
   → Unused Access: which permissions are never used?
   → Policy Validation: check JSON policy for errors

   aws accessanalyzer create-analyzer \
     --analyzer-name my-analyzer \
     --type ACCOUNT_UNUSED_ACCESS

4. No long-lived access keys for EC2/Lambda:
   Wrong: Access Key + Secret Key in code or environment variable
   → Keys compromised → Full access until manually deleted!

   Correct: IAM roles for EC2/Lambda/ECS
   → Temporary credentials via Instance Metadata Service
   → Automatic rotation, no static key!

   # Create IAM role for EC2 (Terraform):
   resource "aws_iam_role" "ec2_role" {
     name = "ec2-app-role"
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Action    = "sts:AssumeRole"
         Effect    = "Allow"
         Principal = { Service = "ec2.amazonaws.com" }
       }]
     })
   }

   resource "aws_iam_role_policy" "ec2_policy" {
     role = aws_iam_role.ec2_role.id
     policy = jsonencode({
       Statement = [{
         Action   = ["s3:GetObject"]
         Effect   = "Allow"
         Resource = "arn:aws:s3:::my-bucket/*"
       }]
     })
   }

5. SCPs (Service Control Policies) for Organizations:
   → Guardrails for all accounts in AWS Organization
   → Example: no root account usage, no disabling of CloudTrail

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "DenyDisablingCloudTrail",
         "Effect": "Deny",
         "Action": [
           "cloudtrail:StopLogging",
           "cloudtrail:DeleteTrail"
         ],
         "Resource": "*"
       }
     ]
   }

Azure RBAC and Managed Identities

Azure RBAC (Role-Based Access Control):

Built-in roles:
  Owner:       Full access + role management
  Contributor: Manage resources, no role delegation
  Reader:      Read-only
  + 100+ specific roles (Storage Blob Data Contributor, etc.)

Least Privilege in Azure:
  Wrong: Contributor at the subscription level for a service principal
  Correct: Specific role on a specific resource group

  # Azure CLI: minimal permissions
  az role assignment create \
    --assignee "service-principal-id" \
    --role "Storage Blob Data Reader" \
    --scope "/subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Storage/storageAccounts/STORAGE_NAME"

Azure Managed Identities (analogous to AWS IAM Roles for EC2):
  System-assigned MI:
  → Automatically linked to Azure resource (VM, App Service, etc.)
  → Lifecycle = Resource lifecycle (deleted when VM is deleted)
  → No credentials, no password

  User-assigned MI:
  → Standalone resource, assignable to multiple services
  → More centralized management

  # VM with Managed Identity in Azure CLI:
  az vm identity assign \
    --name myVM \
    --resource-group myRG

  # Permissions for MI:
  az role assignment create \
    --assignee $(az vm show -g myRG -n myVM --query identity.principalId -o tsv) \
    --role "Key Vault Secrets User" \
    --scope /subscriptions/SUB_ID/.../vaults/VAULT_NAME

Azure Privileged Identity Management (PIM):
  → Just-in-time admin rights (like AWS STS assume-role)
  → Request + approval for privileged roles
  → Maximum activation duration (e.g., 8 hours)
  → Alert + audit upon activation

GCP IAM:
  → Service Accounts = AWS IAM Roles + Azure Managed Identities
  → Workload Identity Federation: external identities (GitHub Actions, K8s) without keys
  → IAM Recommender: "This permission hasn’t been used in 90 days"
  → Access Transparency: what are Google employees doing in your account?

CIEM - Cloud Infrastructure Entitlement Management

CIEM (Cloud Infrastructure Entitlement Management):

What is CIEM?
  → Specialized tool for cloud IAM analysis
  → Analyzes: who is allowed to do what in the cloud (effective permissions)
  → Finds: over-privileged roles, unused permissions
  → Recommends: minimal policies based on actual usage

Why IAM Access Analyzer alone isn’t enough:
  → Access Analyzer: identifies external access, unused access
  → CIEM: Deeper analysis, cross-account, lateral movement paths
  → “If this IAM role is compromised, what can the attacker do?”

CIEM Tools:
  AWS IAM Access Analyzer (free in AWS):
    aws accessanalyzer list-findings \
      --analyzer-name my-analyzer

  Ermetic / Sonrai Security (commercial):
    → Graph-based analysis of IAM relationships
    → "Path from this compromised EC2 to the database?"

  Wiz CIEM (part of Wiz Cloud Security):
    → Integrated with overall cloud security posture
    → Attack path: "Compromised instance → IAM role →
      S3 buckets containing PII data"

IAM hardening checklist (AWS):
  □ Root account: MFA enabled, no access keys
  □ All IAM users: MFA enabled (especially admins!)
  □ IAM Access Analyzer enabled in every region
  □ AWS Config: iam-user-no-policies-check enabled
    (Policies ONLY via groups/roles, not directly assigned to users!)
  □ AWS Config: access-keys-rotated
    (Alert if access key is > 90 days old)
  □ No wildcard permissions (*:* ) except in absolute emergencies
  □ IAM Password Policy: min. 14 characters, MFA
  □ Quarterly access reviews via IAM Access Advisor