Belajar Cloud Architect - Identity & Access Architecture

#Pendahuluan

Di episode 7 kita menegaskan zero trust sebagai model keamanan. Landasan semua itu adalah identity: siapa (manusia atau mesin) yang boleh mengakses apa. Identity architecture yang buruk adalah akar dari sebagian besar pelanggaran — credential yang bocor, akses yang terlalu luas, dan akun yang tidak pernah dihapus.

Episode ini merancang arsitektur IAM enterprise dari tiga sudut: hierarki account & policy, federasi untuk manusia, dan service identity untuk workload. Ketiganya adalah pekerjaan arsitek — bukan sekadar konfigurasi console.

#Hierarki Account dan Policy

#Kenapa Struktur Multi-Account

Satu account untuk semua adalah resep bencana: blast radius terlalu besar, dan sulit membedakan environment (episode 6). Struktur enterprise memakai multi-account — tiap unit punya akun sendiri dengan batas yang jelas:

Organization
├─ Management account (org root, billing)
├─ Security account (audit log, kebijakan)
├─ Prod accounts  (prod-workload, prod-db)
├─ Staging account
└─ Dev accounts (per tim)

Di AWS ini diimplementasikan via AWS Organizations + Service Control Policies (SCP); di GCP via folder + organization policy; di Azure via management group + policy. Konsepnya sama: hierarki tempat policy ditegakkan dari atas ke bawah.

#Policy Hierarchy

Policy diterapkan berlapis — dan irisan dari semua lapisan menentukan akses efektif:

Prinsip kuncinya: jangan pernah meletakkan izin khusus di lapisan atas. Lapisan atas untuk batasan (deny), lapisan bawah untuk izin spesifik (allow). Ini mencegah tim terlalu banyak menumpuk policy.

#Federasi SSO untuk Manusia

#Kenapa Federasi

Membuat user cloud satu per satu adalah mimpi buruk operasional: akun yang ditinggalkan, password berceceran, dan tidak ada kontrol pusat. Federasi menghubungkan cloud dengan Identity Provider (IdP) yang sudah ada (Okta, Azure AD/Entra, Google Workspace) lewat SSO (SAML/OIDC).

#Alur Federasi

User login sekali ke IdP → cloud mempercayai IdP → user mendapatkan role sementara sesuai tugas. Tidak ada password cloud yang dikelola manual.

#Role vs User

Arsitektur yang benar: manusia tidak punya izin permanen di cloud. Mereka diasosiasikan ke IdP, dan saat perlu akses, mereka assume role dengan izin terbatas dan masa berlaku pendek.

aws sts assume-role \
  --role-arn "arn:aws:iam::123456789012:role/AdminBreakGlass" \
  --role-session-name "incident-response"

Perhatikan session: role ini dipakai sementara, bisa di-revoke, dan tercatat di audit. Ini menggantikan "admin selalu login sebagai root" — pola yang harus dihindari.

#Service Identity untuk Workload

#Manusia vs Mesin

Aplikasi yang berjalan di cloud juga butuh identitas — dan tidak boleh memakai credential manusia. Service identity memberi workload identitas terkelola dengan izin terbatas:

• AWS: IAM Role untuk EC2/Lambda/ECS, atau workload identity federation.
• GCP: Service Account dengan impersonation.
• Azure: Managed Identity.

#Pola: Workload Identity Federation

# Trust policy: GitHub action boleh assume role ini
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Principal": { "Federated": "accounts.google.com" },
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:company/payments:ref:refs/heads/main"
        }
      }
    }
  ]
}

Pola ini membuat pipeline CI tidak menyimpan secret statis — kredensial di-issue per-job, dengan batas repo & branch. Ini contoh nyata menerapkan zero trust (episode 7) dan short-lived credentials.

#Prinsip Service Identity

• Satu identitas per service, bukan per instance.
• Izin sempit: service hanya bisa akses resource yang dibutuhkannya.
• No static keys: pakai role/identity federation; jangan pernah hardcode credentials.
• Rotation: semua secret punya masa hidup dan rotasi otomatis (episode 19).

#Least Privilege yang Bisa Dijalankan

#Jangan "Least Privilege" ala Teori

Banyak organisasi mengklaim least privilege tapi praktiknya memberi admin*. Kuncinya adalah make it operational:

1. Start from minimal — berikan izin terkecil yang berfungsi; tambah saat terbukti perlu.
2. Review berkala — audit unused roles, izin berlebih, akun lama (episode 20).
3. Access review — siapa yang punya akses ke apa; perbarui saat orang pindah peran.
4. Break glass — sediakan akses darurat yang tercatat dan terbatas untuk insiden besar.

#Contoh Kerja

Setiap peran diberi izin minimal untuk kerjanya — bukan "akses semua account karena kebetulan punya kredensial".

#Praktik: Mendesain IAM Enterprise

Kerangka desain:

1. Strukturkan multi-account/hierarki dengan deny policy di atas.
2. Sambungkan federasi SSO dari IdP; hilangkan user cloud manual.
3. Ganti akses manusia dengan assume role sementara ber-privilege minimal.
4. Beri setiap workload service identity dengan izin sempit; tanpa static keys.
5. Terapkan least privilege operational: review berkala + access review.
6. Siapkan break glass yang tercatat untuk keadaan darurat.

#Penutup

Inti yang harus dibawa pulang:

• Hierarki multi-account + policy bertingkat membatasi blast radius.
• Federasi SSO menghapus pengelolaan user cloud manual.
• Manusia assume role sementara; workload memakai service identity.
• Tidak ada static keys; kredensial short-lived dan dirotasi.
• Least privilege harus operational: review berkala, access review, break glass.

Di episode 19 selanjutnya kita akan membahas network security & encryption — TLS/mTLS, KMS, secrets management, dan segmentasi jaringan. Sampai jumpa di episode 19!