IAM #

Identity and Access Management (IAM) adalah sistem yang mengontrol siapa yang bisa mengakses apa di cloud kamu. Setiap kali seorang engineer membuka console, setiap kali aplikasi memanggil API cloud, setiap kali pipeline CI/CD men-deploy infrastruktur — semua melalui IAM. IAM bukan fitur opsional yang bisa dikonfigurasi belakangan. Ia adalah lapisan keamanan paling fundamental yang menentukan apakah sistem kamu bisa dikompromikan hanya karena satu credentials bocor, atau tetap aman karena setiap identitas hanya punya akses yang benar-benar dibutuhkan.

Tiga Konsep Dasar IAM #

Authentication (Autentikasi):
  "Siapakah kamu?"
  → Verifikasi identitas: username/password, key pair, token
  → Setelah berhasil: sistem tahu SIAPA yang sedang berinteraksi

Authorization (Otorisasi):
  "Apa yang boleh kamu lakukan?"
  → Evaluasi permission: bolehkah identitas ini melakukan aksi ini
    pada resource ini?
  → Setelah evaluasi: aksi diizinkan atau ditolak

Accounting / Audit:
  "Apa yang sudah kamu lakukan?"
  → Semua aksi dicatat di audit log
  → Siapa, melakukan apa, pada resource apa, kapan, dari mana

Komponen Utama IAM #

User — Identitas Manusia #

IAM User merepresentasikan seorang manusia (atau sistem) yang
berinteraksi langsung dengan cloud.

Karakteristik:
  ✓ Punya credentials permanen (username/password, access key)
  ✓ Bisa di-assign ke group untuk manajemen permission yang efisien

Best practice untuk user:
  ✓ Aktifkan MFA untuk semua user — wajib untuk akun dengan privilege
  ✓ Jangan gunakan root account untuk operasional sehari-hari
  ✓ Buat user individual per orang — jangan berbagi credentials
  ✓ Rotasi access key secara berkala
  ✗ Jangan buat access key untuk user jika bisa pakai role
  ✗ Jangan hardcode credentials di kode atau config file

Root Account:
  → Account pertama yang dibuat saat daftar ke cloud provider
  → Punya akses tak terbatas ke semua resource
  → Hanya gunakan untuk: setup awal, billing, menutup akun
  ✗ Jangan gunakan untuk operasional sehari-hari
  ✓ Aktifkan MFA segera setelah akun dibuat
  ✓ Simpan credentials root di tempat yang sangat aman (password manager)

Group — Kelompok User #

Group adalah kumpulan user yang berbagi permission yang sama.
Lebih mudah dikelola daripada assign permission satu per satu.

Contoh struktur group:
  Group: developers
    → Permission: read/write ke dev environment
    → Members: alice, bob, charlie

  Group: ops
    → Permission: deploy ke staging dan production
    → Members: dave, eve

  Group: security-auditors
    → Permission: read-only ke semua resource, akses ke audit logs
    → Members: frank

Manajemen permission via group:
  ✓ Developer baru masuk? Tambahkan ke group developers
  ✓ Engineer pindah ke tim ops? Pindah dari developers ke ops group
  ✗ Hindari assign permission langsung ke individual user —
    sulit di-audit dan di-maintain

Role — Identitas Sementara #

Role adalah mekanisme paling penting untuk workload non-manusia
(aplikasi, service, pipeline CI/CD).

Perbedaan User vs Role:
  User: identitas permanen dengan credentials tetap
  Role: identitas sementara yang di-assume oleh entitas lain
        Credentials berupa temporary token yang expire otomatis

Siapa yang bisa assume role:
  → EC2 instance / VM (instance profile)
  → Lambda function / serverless function
  → Kubernetes pod (service account)
  → User dari AWS account lain (cross-account access)
  → CI/CD pipeline (OIDC federation)

Contoh: EC2 instance dengan role

  // ANTI-PATTERN: Hardcode credentials di instance
  AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
  AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  // Jika instance dikompromikan → credentials bocor
  // Credentials tidak expire → window of exposure permanen

  // BENAR: Gunakan instance role
  Instance mendapat role: "app-server-role"
  Role punya permission: baca dari S3 bucket tertentu saja
  SDK otomatis ambil temporary credentials dari metadata service
  Credentials expire setiap jam dan di-refresh otomatis
  // Jika instance dikompromikan → credentials expire dalam 1 jam
  // Tidak ada credentials tetap yang bisa dicuri

Policy — Definisi Permission #

Policy adalah dokumen JSON yang mendefinisikan apa yang boleh
dan tidak boleh dilakukan oleh identitas yang memilikinya.

Anatomi Policy (generik, bukan syntax spesifik provider):

  {
    "Statement": [
      {
        "Effect": "Allow",           // Allow atau Deny
        "Principal": "user:alice",   // Siapa (bisa omit di identity policy)
        "Action": [                  // Aksi apa yang diizinkan/ditolak
          "storage:GetObject",
          "storage:ListBucket"
        ],
        "Resource": [               // Pada resource mana
          "arn:bucket:my-app-data/*"
        ],
        "Condition": {              // Kondisi tambahan (opsional)
          "IpAddress": {
            "SourceIp": "10.0.0.0/8"
          }
        }
      }
    ]
  }

Evaluasi policy:
  1. Default: tolak semua (implicit deny)
  2. Cek apakah ada Allow yang cocok
  3. Cek apakah ada Deny eksplisit yang cocok
  4. Deny eksplisit selalu menang atas Allow

Jenis Policy #

Managed Policy (direkomendasikan):
  → Policy yang berdiri sendiri dan bisa di-attach ke banyak identitas
  → Perubahan policy berlaku ke semua yang memakai policy tersebut
  → Lebih mudah di-audit dan di-maintain

  Provider-managed: dibuat dan dikelola provider
    → Contoh: ReadOnlyAccess, AdministratorAccess
    → Tidak perlu buat dari nol untuk permission umum
    ✗ Sering terlalu broad — gunakan hanya sebagai referensi

  Customer-managed: dibuat dan dikelola kamu
    → Bisa di-customize sesuai kebutuhan spesifik
    → Versi-controlled dan bisa di-audit perubahannya
    ✓ Disarankan untuk permission yang spesifik ke sistem kamu

Inline Policy (hindari jika bisa):
  → Policy yang langsung tertanam di satu identitas
  → Tidak bisa di-share atau di-reuse
  → Sulit di-audit karena tersebar
  ✗ Gunakan hanya jika ada kebutuhan yang sangat spesifik

Permission Boundary dan Service Control Policy #

Permission Boundary:
  → Definisikan batas maksimum permission yang bisa dimiliki identitas
  → Meski identitas punya policy yang mengizinkan lebih,
    boundary membatasi efektif permission-nya

  Contoh use case:
  Tim platform memberikan permission kepada tim aplikasi untuk
  membuat IAM role sendiri — tapi dengan boundary bahwa role
  yang dibuat tidak boleh punya permission lebih dari
  yang dimiliki tim aplikasi itu sendiri
  → Mencegah privilege escalation

Service Control Policy (SCP) — untuk multi-account:
  → Berlaku di level organisasi atau account group
  → Membatasi permission maksimum untuk semua identitas dalam account
  → Bahkan jika IAM policy mengizinkan, SCP bisa memblokir

  Contoh SCP yang umum:
  → Larang pembuatan resource di region yang tidak diizinkan
  → Larang modifikasi CloudTrail (audit log) oleh siapapun
  → Wajibkan enkripsi untuk semua bucket storage yang dibuat

Ringkasan #

IAM adalah lapisan keamanan paling fundamental di cloud — authentication memverifikasi identitas, authorization menentukan akses, audit mencatat semua aktivitas.
Gunakan role untuk workload, bukan user dengan access key — role memberikan temporary credentials yang expire otomatis, jauh lebih aman dari credentials permanen.
Root account hanya untuk setup awal — aktifkan MFA segera, jangan gunakan untuk operasional sehari-hari.
Kelola permission melalui group, bukan individual — lebih mudah di-audit dan di-maintain saat tim berkembang.
Customer-managed policy lebih baik dari provider-managed yang terlalu broad — sesuaikan dengan kebutuhan spesifik dan terapkan prinsip least privilege.
Permission boundary mencegah privilege escalation — batasi permission maksimum yang bisa didelegasikan, bukan hanya yang saat ini dimiliki.

← Sebelumnya: Spot/Preemptible Instance Berikutnya: Least Privilege →