IAM #

Dalam pengelolaan infrastruktur komputasi cloud, keamanan tidak lagi ditentukan oleh batas perimeter fisik pusat data atau sekadar firewall jaringan. Di era cloud publik, identitas adalah perimeter keamanan baru (identity is the new perimeter). Layanan utama yang mengelola batas keamanan ini adalah Identity and Access Management (IAM). Setiap kali seorang administrator membuka konsol cloud, setiap kali kode aplikasi memanggil API penyimpanan objek, atau setiap kali pipeline CI/CD mendeploy arsitektur serverless — seluruh interaksi tersebut wajib melalui pemeriksaan ketat di bawah kendali IAM. IAM bukanlah fitur tambahan yang dikonfigurasi belakangan setelah sistem jadi. IAM adalah fondasi keamanan paling kritis yang menentukan apakah seluruh data korporasi kita dapat diretas hanya karena kebocoran satu file kredensial developer, atau tetap aman berkat pembatasan akses yang sangat presisi. Artikel ini akan membedah secara mendalam tiga pilar IAM, anatomi komponen identitas, logika evaluasi kebijakan, serta strategi delegasi kontrol tingkat lanjut.

Tiga Pilar Utama Keamanan IAM #

Untuk memahami bagaimana IAM melindungi sumber daya cloud, kita harus memisahkan proses pemeriksaan keamanan menjadi tiga pilar utama yang berjalan secara berurutan:

flowchart TD
    Request["1. Client API Request"] --> AuthN["2. AUTHENTICATION (AuthN) <br>Siapa subjek pengakses?<br>(Validasi: Password, Token, Access Key)"]
    AuthN -->|"Terverifikasi"| AuthZ["3. AUTHORIZATION (AuthZ) <br>Apa saja tindakan yang diizinkan?<br>(Evaluasi Dokumen Policy & Conditions)"]
    AuthN -->|"Gagal"| Reject1["HTTP 401 Unauthorized<br>(Akses Ditolak)"]
    
    AuthZ -->|"Diizinkan"| Execute["4. AKSI DIEKSEKUSI<br>(e.g., Baca file S3, Stop VM)"]
    AuthZ -->|"Ditolak"| Reject2["HTTP 403 Forbidden<br>(Akses Ditolak)"]
    
    Execute --> Audit["5. AUDIT LOGGING<br>(Pencatatan Aktivitas via CloudTrail / Audit Logs)"]
    Reject1 --> Audit
    Reject2 --> Audit

1. Authentication (Autentikasi / AuthN) #

Autentikasi adalah proses membuktikan identitas entitas yang mencoba masuk atau mengirim permintaan. IAM menanyakan: “Siapa subjek pengakses ini?”.

  • Mekanisme: Pengguna manusia membuktikannya menggunakan kombinasi username, password, dan kode Multi-Factor Authentication (MFA). Sedangkan aplikasi, server, atau script membuktikannya menggunakan sertifikat digital, token OIDC, atau pasangan kunci akses (Access Key ID & Secret Access Key).

2. Authorization (Otorisasi / AuthZ) #

Setelah identitas terverifikasi sebagai identitas yang sah, IAM melakukan proses otorisasi. IAM menanyakan: “Aksi apa saja yang diizinkan pada sumber daya ini?”.

  • Mekanisme: Mesin evaluasi IAM memindai seluruh kebijakan (policies) yang menempel pada identitas tersebut dan mencocokkan tindakan yang diminta (misal: menghapus tabel database) dengan aturan izin yang didefinisikan. Jika tidak ada aturan yang mengizinkannya secara eksplisit, request akan langsung ditolak dengan status error HTTP 403 Forbidden.

3. Auditing & Accounting (Audit / Pencatatan Aktivitas) #

Pilar ketiga bertugas mencatat dan merekam setiap aktivitas transaksi API yang terjadi di cloud secara transparan. Layanan seperti AWS CloudTrail atau Google Cloud Audit Logs secara otomatis mencatat metadata lengkap dari setiap panggilan API: “Siapa pelakunya, tindakan apa yang diminta, sumber daya mana yang diakses, kapan waktu eksekusinya, dari IP mana permintaan berasal, dan apa status hasilnya (Sukses/Ditolak)”. Catatan audit ini bersifat permanen dan tidak boleh dimodifikasi oleh siapa pun untuk kebutuhan forensik keamanan.

Komponen Identitas: User, Group, dan Role #

Sistem IAM membedakan entitas pengakses ke dalam tiga kategori utama untuk mempermudah tata kelola hak akses:

flowchart TD
    subgraph Users ["IAM Users (Manusia)"]
        Alice["Alice (Dev)"]
        Bob["Bob (Dev)"]
        Charlie["Charlie (Ops)"]
    end
    
    subgraph Groups ["IAM Groups"]
        DevGroup["Developer Group"]
        OpsGroup["Operations Group"]
    end
    
    subgraph Policies ["IAM Policies"]
        DevPolicy["Dev Environment Policy"]
        ProdPolicy["Prod Admin Policy"]
    end
    
    Alice --> DevGroup
    Bob --> DevGroup
    Charlie --> OpsGroup
    
    DevGroup --> DevPolicy
    OpsGroup --> ProdPolicy

1. IAM User #

Merepresentasikan identitas permanen tunggal yang biasanya diasosiasikan dengan satu orang manusia (misal: karyawan korporasi kita).

  • Root Account: Ini adalah identitas utama yang otomatis dibuat saat pertama kali mendaftar akun cloud. Akun root memiliki kekuasaan mutlak tanpa batas ke seluruh resource dan billing keuangan. ATURAN KRITIS: Jangan pernah menggunakan akun root untuk aktivitas operasional sehari-hari. Kredensial root harus dikunci dengan password panjang yang disimpan di brankas digital manager (password manager), diaktifkan MFA fisik, dan operasional didelegasikan penuh ke user administrator biasa di tingkat IAM.
  • Prinsip Identitas Individual: Setiap anggota tim harus memiliki user individual sendiri. Berbagi kredensial satu user di antara beberapa tim developer adalah anti-pattern berat karena merusak akuntabilitas audit logs (kita tidak bisa tahu siapa dari developer yang tidak sengaja menghapus database jika semuanya menggunakan akun “admin_developer”).

2. IAM Group #

Kumpulan dari beberapa IAM User yang memiliki fungsi pekerjaan yang sama.

  • Kemudahan Kelola: Sangat disarankan untuk menempelkan kebijakan izin (policies) ke tingkat Group, bukan langsung ke individual User. Ketika ada karyawan baru bergabung ke tim developer, kita cukup memasukkan user-nya ke “Developer Group” dan user tersebut otomatis mewarisi seluruh izin yang diperlukan. Jika ia pindah divisi ke tim Operations, kita cukup memindahkannya ke “Operations Group” untuk mencabut izin lamanya secara instan.

3. IAM Role (Workload Identity) #

Identitas sementara tanpa kredensial permanen. Berbeda dengan User yang memiliki password atau access key tetap yang tidak kedaluwarsa, Role bekerja menggunakan mekanisme token keamanan sementara (temporary security credentials) yang dibuat secara dinamis oleh Security Token Service (STS) dan otomatis kedaluwarsa dalam hitungan jam (misal 1 hingga 12 jam).

  • Prinsip Keamanan Workload: Jangan pernah menaruh Access Key fisik di dalam file konfigurasi kode aplikasi kita yang berjalan di Virtual Machine atau kontainer.
  • Cara Kerja Role: VM kita ditempeli sebuah Instance Profile yang terikat ke suatu Role. Saat aplikasi kita memanggil SDK cloud (misal untuk mengunggah file ke S3), SDK secara otomatis mengambil token sementara dari server metadata instans lokal. Token ini di-refresh secara transparan di latar belakang. Jika VM kita diretas oleh pihak luar, peretas hanya akan mendapatkan kunci token sementara yang akan segera hangus secara otomatis, meminimalkan durasi risiko kerentanan keamanan (window of exposure).
# ANTI-PATTERN: Menaruh credentials permanen di file konfigurasi aplikasi
aws_access_key_id: "AKIAIOSFODNN7EXAMPLE"       # JANGAN: Sangat rentan bocor di Git commit!
aws_secret_access_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# --- Separator ---

# BENAR: Menggunakan IAM Role yang diikat ke instans VM (Terraform deklaratif)
resource "aws_iam_instance_profile" "app_profile" {
  name = "app_server_instance_profile"
  role = aws_iam_role.app_role.name
}

resource "aws_iam_role" "app_role" {
  name = "app_server_role"

  # Mengizinkan instans EC2 (VM) untuk meng-assume role ini secara temporer
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

Evaluasi Kebijakan (Policy Evaluation Logic) #

Ketika sebuah permintaan API masuk ke IAM, mesin otorisasi cloud akan mengevaluasi kebijakan menggunakan alur logika terstruktur yang sangat ketat untuk memutuskan apakah permintaan tersebut diizinkan atau ditolak.

flowchart TD
    Start["API Request Diterima"] --> DefaultDeny["1. DEFAULT DENY<br>(Secara bawaan semua akses ditolak)"]
    DefaultDeny --> CheckDeny{"2. ADA EXPLICIT DENY?<br>(Cek apakah ada aturan penolakan eksplisit)"}
    
    CheckDeny -- "Ya" --> Denied["AKSES DITOLAK (Deny wins)"]
    CheckDeny -- "Tidak" --> CheckAllow{"3. ADA EXPLICIT ALLOW?<br>(Cek apakah ada aturan izin)"}
    
    CheckAllow -- "Ya" --> Allowed["AKSES DIIZINKAN (Allow)"]
    CheckAllow -- "Tidak" --> Denied

Logika Pengambilan Keputusan IAM: #

  1. Default Deny (Implicit Deny): Secara bawaan, seluruh permintaan akses ke sumber daya cloud ditolak secara default. Jika kita tidak membuat aturan apa pun, tidak ada satu pun pengguna yang bisa mengakses apa pun.
  2. Explicit Deny: Mesin evaluasi memindai seluruh kebijakan yang berlaku. Jika ditemukan satu saja aturan Deny eksplisit yang cocok dengan tindakan atau sumber daya yang diminta, maka permintaan akan langsung ditolak seketika, terlepas dari seberapa banyak aturan Allow lain yang mengizinkannya di kebijakan berbeda. Di dalam IAM: “Deny selalu menang atas Allow”.
  3. Explicit Allow: Jika tidak ada Deny yang terdeteksi, mesin mencari apakah ada aturan Allow eksplisit yang cocok. Jika ditemukan, akses diberikan.
  4. Implicit Deny (Fallback): Jika tidak ada Deny dan tidak ada Allow yang cocok, permintaan kembali ditolak berdasarkan aturan default deny pertama.

Jenis-Jenis Policy: Managed vs Inline dan Identity-based vs Resource-based #

Kebijakan izin ditulis dalam format dokumen JSON. Kita harus memisahkan kebijakan ini berdasarkan cara penempelan dan cara pengelolaannya.

1. Managed Policy vs Inline Policy #

  • Managed Policy (Direkomendasikan): Kebijakan mandiri yang memiliki ID unik di cloud (ARN) dan dapat kita tempelkan ke banyak identitas sekaligus (User, Group, dan Role). Jika kita memperbarui isi dari Managed Policy ini, perubahannya otomatis berlaku seketika ke seluruh identitas yang menggunakannya. Managed Policy terbagi menjadi:
    • Provider-managed: Disediakan langsung oleh penyedia cloud (seperti AdministratorAccess atau AmazonS3ReadOnlyAccess). HATI-HATI: Kebijakan bawaan provider sering kali terlalu luas (too broad) dan melanggar prinsip hak akses minimum.
    • Customer-managed: Kita tulis sendiri dari nol sesuai kebutuhan aplikasi kita. Ini adalah praktek terbaik untuk produksi.
  • Inline Policy (Hindari jika bisa): Kebijakan yang tertanam langsung secara internal di dalam satu identitas tertentu dan tidak dapat dibagikan ke identitas lain. Hal ini membuat tata kelola kepatuhan keamanan menjadi sangat sulit dilacak (audit spaghetti).

2. Identity-based vs Resource-based Policy #

  • Identity-based Policy: Dokumen kebijakan yang kita tempelkan pada objek identitas pengakses (User, Group, atau Role) untuk menentukan apa yang boleh mereka akses.
  • Resource-based Policy: Dokumen kebijakan yang kita tempelkan langsung pada objek sumber daya yang dituju (seperti S3 Bucket, KMS Key, atau SQS Queue) untuk mendefinisikan siapa saja yang diizinkan untuk masuk ke sumber daya tersebut.
// Contoh Resource-based Policy yang ditempelkan langsung pada S3 Bucket
// Aturan ini mengizinkan peran IAM Role aplikasi tertentu untuk membaca berkas di bucket ini
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAppReadAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/app_server_role"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::corporate-finance-data",
        "arn:aws:s3:::corporate-finance-data/*"
      ]
    }
  ]
}

Kontrol Batas Akses: Permission Boundary dan SCP #

Pada organisasi berskala besar dengan ratusan akun cloud dan puluhan tim developer, tim keamanan pusat (cloud security team) tidak mungkin mengonfigurasi IAM secara manual setiap hari untuk setiap pengembang. Mereka harus mendelegasikan wewenang pembuatan IAM Role kepada tim developer lokal. Namun, pendelegasian ini memicu risiko baru: Developer dapat membuat Role dengan hak akses Administrator untuk diri mereka sendiri (Privilege Escalation).

Untuk memitigasi bahaya ini, kita wajib menerapkan teknik pembatasan akses tingkat lanjut:

1. Permission Boundary (Batas Izin) #

Sebuah kebijakan kontrol khusus yang bertugas membatasi kemampuan maksimum dari hak akses yang dapat dimiliki oleh sebuah identitas IAM (seperti Role baru yang dibuat oleh developer).

  • Cara Kerja: Meskipun developer membuat IAM Role baru dengan menempelkan kebijakan AdministratorAccess (Allow All), jika Role baru tersebut dikonfigurasi di bawah Permission Boundary yang hanya mengizinkan akses ke S3 dan DynamoDB, maka hak akses efektif yang dimiliki oleh Role baru tersebut hanya terbatas pada S3 dan DynamoDB. Akses administrasi lainnya diblokir secara otomatis oleh boundary.
Formula Hak Akses Efektif:
┌─────────────────────────────┐
│  IAM Policy (Izin Biasa)    │ ────────┐
│  e.g., Allow All (*)        │         │
└─────────────────────────────┘         │
                                        ├──> Intersect (Irisan) = Hak Akses Efektif
┌─────────────────────────────┐         │                         (Hanya S3 & DynamoDB)
│  Permission Boundary (Batas)│ ────────┘
│  e.g., Allow S3 & DynamoDB  │
└─────────────────────────────┘

2. Service Control Policy (SCP) #

Untuk tata kelola multi-account di tingkat organisasi cloud (Organization Units). SCP berada di atas tingkat IAM lokal akun masing-masing.

  • Cara Kerja: SCP digunakan oleh tim keamanan pusat untuk membatasi hak akses maksimum untuk seluruh entitas (termasuk User Administrator lokal akun) di dalam akun cloud anak.
  • Contoh SCP yang Wajib Diterapkan:
    • Mencegah penghapusan atau penonaktifan log audit CloudTrail oleh akun mana pun.
    • Membatasi agar seluruh instans komputasi hanya boleh dideploy di region tertentu yang patuh hukum (misal: hanya di ap-southeast-3 Jakarta) untuk mematuhi kedaulatan data regional.
    • Melarang pembuatan database publik yang terekspos langsung ke internet.

Ringkasan #

  • Identitas adalah perimeter keamanan baru di cloud — IAM mengontrol autentikasi (AuthN), otorisasi (AuthZ), dan pencatatan audit secara ketat dan terpusat.
  • Gunakan IAM Role dengan token sementara (temporary credentials) untuk beban kerja server dan kontainer, hindari menaruh Access Key fisik di dalam file konfigurasi kode.
  • Root Account adalah target serangan utama — Kunci dengan MFA fisik, simpan password di password manager, dan jangan gunakan untuk operasional harian.
  • Kelola hak akses di tingkat Group daripada menempelkannya langsung ke individual User untuk meminimalkan kompleksitas audit keamanan.
  • Deny selalu menang atas Allow — Manfaatkan aturan penolakan eksplisit ini untuk memblokir akses sensitif secara permanen.
  • Terapkan Permission Boundary dan SCP saat mendelegasikan hak pembuatan IAM role kepada tim pengembang guna mencegah celah privilege escalation.

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

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact