Least Privilege #

Principle of Least Privilege (PoLP) adalah salah satu prinsip keamanan paling fundamental: setiap identitas — user, aplikasi, service, atau sistem — hanya boleh memiliki permission minimum yang diperlukan untuk menjalankan fungsinya, tidak lebih. Ini terdengar sederhana, tapi dalam praktik sangat sering dilanggar karena memberikan akses lebih mudah daripada menganalisis akses yang tepat. Dan konsekuensinya bisa sangat serius: satu credentials yang bocor dengan permission terlalu luas bisa menjadi pintu masuk ke seluruh infrastruktur.

Mengapa Least Privilege Penting #

Skenario Tanpa Least Privilege:

  Aplikasi web punya permission: AdministratorAccess
  (umum diberikan karena "lebih mudah daripada debug permission error")

  Yang terjadi jika ada vulnerability di aplikasi:
  → Attacker mengeksploitasi vulnerability
  → Attacker mendapat akses ke credentials aplikasi
  → Credentials punya AdministratorAccess
  → Attacker bisa:
      ✗ Baca semua data di seluruh akun (termasuk data sensitif)
      ✗ Hapus semua resource
      ✗ Buat backdoor user baru
      ✗ Eksfiltrasi data ke tempat lain
      ✗ Jalankan instance untuk mining cryptocurrency
  
  Blast radius: SELURUH akun cloud

Skenario Dengan Least Privilege:

  Aplikasi web punya permission: baca dari satu S3 bucket,
  tulis ke satu DynamoDB table, publish ke satu SNS topic

  Yang terjadi jika credentials bocor:
  → Attacker mendapat akses ke credentials aplikasi
  → Attacker hanya bisa:
      ✓ Baca dari S3 bucket yang sama (yang memang bisa diakses publik)
      ✓ Tulis ke DynamoDB table (damage terbatas, bisa di-rollback)
  → Tidak bisa akses resource lain
  → Tidak bisa buat user baru
  → Tidak bisa hapus infrastruktur

  Blast radius: SANGAT TERBATAS

Anti-Pattern yang Paling Umum #

// ANTI-PATTERN 1: AdministratorAccess untuk semua
  Hampir setiap role dan user punya AdministratorAccess
  karena "lebih mudah dan tidak perlu debug permission"

  Masalah:
  ✗ Satu credentials bocor = seluruh akun dikompromikan
  ✗ Tidak ada cara untuk membatasi blast radius saat insiden

// ANTI-PATTERN 2: Wildcard resource dan action
  {
    "Effect": "Allow",
    "Action": "s3:*",          ← semua aksi S3
    "Resource": "*"            ← semua bucket
  }
  
  Masalah:
  ✗ Aplikasi yang hanya butuh baca satu bucket
    bisa hapus semua bucket

// ANTI-PATTERN 3: "Nanti di-restrict, sekarang pakai yang luas dulu"
  Permission luas diberikan untuk mempercepat development
  Rencana untuk di-restrict nanti → tidak pernah terjadi
  
  Masalah:
  ✗ Technical debt keamanan yang terus menumpuk
  ✗ "Nanti" hampir tidak pernah datang

// BENAR: Definisikan permission spesifik dari awal
  {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",    ← hanya baca
      "s3:PutObject"     ← hanya tulis
    ],
    "Resource": "arn:aws:s3:::my-app-data/*"  ← hanya bucket ini
  }

Cara Menemukan Permission yang Benar-benar Dibutuhkan #

Salah satu tantangan terbesar least privilege adalah: bagaimana tahu permission apa yang sebenarnya dibutuhkan oleh sebuah aplikasi?

Pendekatan 1 — Analisis Kode (paling akurat):
  → Baca kode aplikasi dan identifikasi semua panggilan API cloud
  → Daftarkan service dan aksi yang dipanggil
  → Identifikasi resource spesifik yang diakses (bucket name, table name)
  → Buat policy berdasarkan daftar ini

Pendekatan 2 — IAM Access Analyzer:
  → Tools yang menganalisis akses AKTUAL yang digunakan identitas
  → Pantau selama periode representatif (misalnya 30 hari)
  → Generate policy berdasarkan akses yang benar-benar terjadi
  → Berguna untuk: review permission yang sudah ada, tidak untuk mulai dari nol

Pendekatan 3 — Policy Simulator:
  → Test policy sebelum diapply
  → Simulasi: "jika identitas ini punya policy ini, bolehkah ia melakukan X?"
  → Identifikasi permission yang kurang atau berlebih sebelum di-deploy

Pendekatan 4 — CloudTrail Analysis:
  → Audit log mencatat semua API call yang dibuat
  → Analisis log: API call apa yang dibuat oleh identitas ini?
  → Permission yang tidak pernah digunakan adalah kandidat untuk di-remove

Proses yang disarankan:
  1. Mulai dengan permission yang lebih luas saat development
  2. Aktifkan logging semua API call
  3. Sebelum go-live, analisis log dan buat policy yang minimal
  4. Review berkala — hapus permission yang tidak digunakan

Least Privilege untuk Resource Berbeda #

Untuk Aplikasi / Service:
  ✓ Gunakan role, bukan user dengan access key
  ✓ Role hanya punya permission untuk resource yang diakses aplikasi
  ✓ Pisahkan role per service — jangan satu role untuk semua service
  ✓ Gunakan resource-level permission bila tersedia
      (bukan "semua bucket S3", tapi "bucket ini saja")

Untuk Developer:
  ✓ Permission berbeda untuk environment berbeda
      dev: full access ke dev environment
      staging: read/write terbatas
      prod: read-only, deploy via CI/CD pipeline (bukan manual)
  ✓ Just-in-time access untuk produksi
      Minta akses elevated saat dibutuhkan → auto-expire setelah N jam
      Bukan permanent access yang tidak digunakan 99% waktu

Untuk CI/CD Pipeline:
  ✓ Pipeline hanya punya permission untuk resource yang di-deploy
  ✓ Pisahkan permission per environment
      Pipeline dev: deploy ke dev saja
      Pipeline prod: deploy ke prod saja (setelah approval)
  ✓ Gunakan OIDC federation, bukan long-lived access key
      Pipeline mendapat short-lived token per run, bukan credentials permanen

Privilege Escalation — Risiko yang Tersembunyi #

Bahkan dengan least privilege, ada risiko privilege escalation — ketika permission yang tampaknya terbatas bisa dimanfaatkan untuk mendapat akses lebih luas.

Contoh Privilege Escalation:

  User punya permission:
  → iam:CreateRole
  → iam:AttachRolePolicy
  → sts:AssumeRole

  Secara individual, ini terlihat terbatas.
  Tapi kombinasinya memungkinkan:
  
  1. User buat role baru dengan AdministratorAccess
  2. User attach AdministratorAccess policy ke role tersebut
  3. User assume role yang baru dibuat
  4. User kini punya AdministratorAccess!

  Mitigasi:
  ✓ Permission Boundary — batasi permission maksimum role yang bisa dibuat
  ✓ Service Control Policy — larang operasi IAM yang berbahaya di level org
  ✓ Audit regular permission yang memungkinkan eskalasi
  ✓ Deteksi: alert saat ada pembuatan role baru atau
    attachment policy yang privilege-nya tinggi

Ringkasan #

Least privilege membatasi blast radius saat insiden — credentials yang bocor dengan akses minimal hanya bisa lakukan kerusakan minimal.
AdministratorAccess dan wildcard permission adalah anti-pattern utama — mudah untuk development tapi sangat berbahaya di produksi.
Analisis kode + IAM Access Analyzer untuk menemukan permission yang tepat — pantau akses aktual selama periode representatif, bukan tebak-tebakan.
Pisahkan role per service dan per environment — satu role untuk semua aplikasi adalah kesalahan yang memperluas blast radius tanpa alasan.
Just-in-time access untuk produksi — minta akses elevated saat dibutuhkan dengan expiry otomatis, bukan permanent access yang jarang dipakai.
Waspadai privilege escalation — kombinasi permission yang tampaknya terbatas bisa dimanfaatkan untuk akses yang jauh lebih luas.

← Sebelumnya: IAM Berikutnya: Authentication vs Authorization →