9.2.1 IAM (Identity & Access Management)

Identity and Access Management (IAM) adalah kerangka kerja keamanan yang mengatur siapa (identity) yang bisa melakukan apa (action) terhadap sumber daya cloud (resource) dalam kondisi bagaimana (condition). IAM adalah komponen keamanan paling fundamental di cloud - kesalahan konfigurasi IAM menjadi penyebab utama data breach di lingkungan cloud.

Komponen IAM

1. Users

User mewakili individu atau aplikasi yang perlu mengakses resource cloud.

AWS: IAM User - memiliki long-term credentials (access key + secret key)
Azure: Azure AD User - identity di Microsoft Entra ID
GCP: Google Account atau Service Account

Contoh pembuatan IAM user di AWS CLI:

aws iam create-user --user-name devops-engineer
aws iam create-access-key --user-name devops-engineer

Output:

{
  "AccessKey": {
    "UserName": "devops-engineer",
    "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Status": "Active"
  }
}

2. Groups

Group adalah kumpulan user yang mewarisi izin yang sama - mempermudah manajemen daripada attach policy ke masing-masing user.

aws iam create-group --group-name engineers
aws iam add-user-to-group --user-name devops-engineer --group-name engineers

Best practice: always use groups, never attach policies directly to users.

3. Roles

Role adalah identity yang tidak terkait dengan user tertentu dan bisa diasumsikan oleh entity yang membutuhkan:

AWS service (EC2, Lambda)
User dari AWS account lain (cross-account)
Federated users (SSO, SAML)
Aplikasi yang berjalan di EC2

Contoh membuat role untuk EC2:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

aws iam create-role --role-name ec2-s3-access-role \
  --assume-role-policy-document file://trust-policy.json

4. Policies

Policy adalah dokumen JSON yang mendefinisikan izin. Dua jenis utama:

Managed Policies

Dibuat dan dikelola oleh AWS (AWS managed) atau oleh customer (customer managed). Bisa di-reuse untuk banyak principal.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-data-bucket",
        "arn:aws:s3:::company-data-bucket/*"
      ]
    }
  ]
}

Inline Policies

Policy yang ditanam langsung ke user, group, atau role. Tidak bisa di-reuse. Dianjurkan hanya untuk exceptional cases.

aws iam put-user-policy \
  --user-name devops-engineer \
  --policy-name temp-debug-policy \
  --policy-document file://inline-policy.json

5. Trust Policies

Trust policy menentukan siapa yang boleh mengasumsikan sebuah role. Ini adalah komponen yang membedakan role dari user.

Untuk cross-account access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_B:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-audit-id-12345"
        }
      }
    }
  ]
}

6. Service Roles

Role yang diasumsikan oleh AWS service untuk mengakses service lain atas nama kita.

Contoh: Lambda function yang perlu membaca dari S3 dan menulis ke DynamoDB.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "dynamodb:PutItem"
      ],
      "Resource": [
        "arn:aws:s3:::input-bucket/*",
        "arn:aws:dynamodb:us-east-1:123456789012:table/Results"
      ]
    }
  ]
}

7. Cross-Account Access

Mengizinkan user dari Account A mengakses resource di Account B:

Buat role di Account B dengan trust policy mengarah ke Account A
Beri izin user di Account A untuk sts:AssumeRole
User menjalankan aws sts assume-role untuk mendapatkan temporary credentials

aws sts assume-role \
  --role-arn "arn:aws:iam::ACCOUNT_B:role/CrossAccountAuditor" \
  --role-session-name "audit-session"

IAM Policy Evaluation Logic

Memahami bagaimana AWS mengevaluasi policy sangat penting untuk mendeteksi konfigurasi yang salah.

Aturan Dasar

Default: semua akses denied secara implisit
Explicit Allow: mengizinkan akses secara eksplisit
Explicit Deny: memblokir akses secara eksplisit - override apapun, termasuk allow
Deny selalu menang: jika ada satu deny, maka akses ditolak

Decision Flow

Request → Organization SCP → Resource Policy → 
  Permission Boundary → Session Policy → 
    Identity Policy (Allow/Deny) → 
      Jika ada Explicit Deny → DENY
      Jika ada Explicit Allow → ALLOW
      Tidak ada keduanya → DENY (default)

Contoh: user memiliki policy allow S3 full access, tapi ada SCP di AWS Organizations yang mencegah akses ke bucket tertentu.

// SCP (Service Control Policy) - deny menyeluruh
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::restricted-bucket"
    }
  ]
}

Meskipun user punya policy allow di level identity, SCP deny akan memblokir.

Permission Boundaries

Permission boundary membatasi izin maksimal yang bisa dimiliki oleh user/role. Izin efektif adalah irisan antara identity policy dan permission boundary.

// Permission boundary untuk developer - maksimal EC2 + S3 read
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

Best Practices IAM

1. Least Privilege

Berikan izin minimal yang diperlukan untuk menjalankan tugas. Gunakan AWS IAM Access Analyzer untuk mendeteksi policy yang terlalu permisif.

aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://policy.json

2. Gunakan Roles, Bukan Long-Term Credentials

Jangan pernah menyimpan access key di EC2 instance atau Lambda. Gunakan IAM Roles yang diasumsikan service.

aws ec2 associate-iam-instance-profile \
  --instance-id i-123456789 \
  --iam-instance-profile Name=ec2-s3-readonly

3. Rotasi Credentials Secara Berkala

Gunakan AWS IAM Access Last Used untuk mengidentifikasi key yang tidak dipakai dan mencabutnya.

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

4. Gunakan Condition Keys

Persempit izin dengan kondisi spesifik:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    },
    "Bool": {
      "aws:SecureTransport": "true"
    }
  }
}

5. Terapkan Password Policy

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters

IAM di GCP

GCP menggunakan model Resource Hierarchy dan Roles yang terdiri dari primitive roles (Owner, Editor, Viewer) dan predefined roles.

gcloud projects add-iam-policy-binding my-project \
  --member="user:[email protected]" \
  --role="roles/compute.admin"

GCP IAM Recommender memberikan rekomendasi untuk mengurangi izin berlebih:

gcloud recommender recommendations list \
  --recommender=google.iam.policy.Recommender \
  --project=my-project

IAM di Azure

Azure menggunakan Azure RBAC (Role-Based Access Control) dengan Built-in Roles:

Owner: full access + delegasi
Contributor: manage resources, tidak bisa delegasi
Reader: readonly
Custom Role: kustomisasi sesuai kebutuhan

az role assignment create \
  --assignee "[email protected]" \
  --role "Reader" \
  --scope "/subscriptions/xxx/resourceGroups/prod-rg"

Azure AD Privileged Identity Management (PIM) memberikan just-in-time access ke role admin:

# Aktivasi role via PIM - temporary, perlu approval
az role assignment create \
  --assignee "[email protected]" \
  --role "Contributor" \
  --scope "/subscriptions/xxx" \
  --start-time "2026-07-22T09:00:00Z" \
  --end-time "2026-07-22T17:00:00Z"

Common IAM Misconfigurations

User dengan AdministratorAccess penuh: terlalu permisif, sebaiknya gunakan role dengan Just-In-Time activation
S3 bucket policy publik: "Principal": "*" tanpa kondisi - penyebab utama data leak
IAM role trust policy terlalu luas: "Principal": {"AWS": "*"} - siapa pun bisa assume role
Access key tidak pernah dirotasi: key berusia >90 hari meningkatkan risiko exposure
Group tidak digunakan: policy langsung menempel ke user - sulit diaudit
Permission boundary tidak di-set: role bisa escalate privilege tanpa batas
Wildcard "Resource": "*" terlalu sering digunakan: persempit ke ARN spesifik

Tools Audit IAM

Tool	Cloud	Fungsi
AWS IAM Access Analyzer	AWS	Deteksi policy publik dan cross-account yang tidak disengaja
AWS IAM Policy Simulator	AWS	Uji coba effect policy sebelum deploy
GCP Policy Analyzer	GCP	Analisis akses IAM di resource hierarchy
Azure AD Privileged Identity Management	Azure	JIT access + approval workflow
CloudSploit / ScoutSuite	Multi-cloud	Open source cloud security auditing

Kesimpulan

IAM adalah gerbang keamanan utama di cloud. Setiap resource, setiap API call, setiap akses - semuanya melalui IAM. Dengan memahami komponen, evaluation logic, dan best practices, serta menghindari misconfigurations umum, Anda bisa membangun fondasi keamanan cloud yang kuat. Gunakan tools otomatis untuk audit dan validasi IAM secara berkala.