Belajar IAM Engineer - Role-Based Access Control (RBAC)

#Pendahuluan

Setelah di episode 8 kita membahas identity lifecycle & provisioning, pada episode ini kita masuk ke RBAC (Role-Based Access Control) — model authorization yang menentukan akses berdasarkan role yang dimiliki user. RBAC adalah standar industri untuk mengelola akses di organisasi dari semua ukuran.

Mengapa RBAC penting? Karena tanpa model yang terstruktur, akses akan menjadi kekacauan. User mendapat terlalu banyak atau terlalu sedikit akses, dan tidak ada yang tahu dengan pasti siapa bisa mengakses apa. RBAC membawa ketertiban ke dalam kompleksitas ini.

#Konsep RBAC

#Komponen RBAC

User → Role → Permissions → Resources
 
Alice → Developer → read/write → code repositories
Alice → Developer → read → staging server
Bob → Manager → approve → deployment pipeline
Bob → Manager → read → team reports

#Hierarchy Role

CEO
├── VP Engineering
│   ├── Engineering Manager
│   │   ├── Senior Developer
│   │   │   └── Developer
│   │   └── QA Lead
│   │       └── QA Engineer
│   └── DevOps Manager
│       └── DevOps Engineer
└── VP Sales
    └── Sales Manager
        └── Sales Rep

Role di atas mewarisi permissions dari role di bawah — VP Engineering memiliki semua permission yang dimiliki Engineering Manager, dst.

#RBAC Design

#Langkah Desain

1. Identifikasi resources — aplikasi, data, dan services yang perlu di-protect
2. Identifikasi actions — CRUD (create, read, update, delete) dan custom actions
3. Buat role — kelompokkan permissions ke dalam role yang logis
4. Assign users ke roles — berdasarkan job function, bukan individual
5. Review & refine — audit berkala untuk menghilangkan role creep

#Contoh Role di Perusahaan

#Role Naming Convention

[department]-[function]-[scope]
 
Contoh:
engineering-developer-global
engineering-manager-us
finance-accountant-apac
security-analyst-tier1

#Least Privilege

#Prinsip Least Privilege

User hanya mendapat a minimum akses yang dibutuhkan untuk melakukan pekerjaannya — tidak lebih.

#Implementasi Least Privilege

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

Policy di atas hanya mengizinkan read access ke folder development/ di S3 — tidak lebih.

#RBAC vs ABAC vs PBAC

#Common RBAC Pitfalls

1. Role explosion — terlalu banyak role spesifik yang sulit dikelola
2. Role creep — user mengakumulasi role yang tidak relevan
3. Standing privileges — akses yang selalu aktif, tidak pernah dicabut
4. No regular review — tidak ada audit untuk memvalidasi role assignments

#Penutup

Inti yang harus dibawa pulang:

• RBAC menentukan akses berdasarkan role, bukan individual assignment.
• Least privilege memastikan user hanya mendapat akses minimum yang dibutuhkan.
• Role hierarchy memudahkan inheritance permission dari level atas ke bawah.
• Regular access review diperlukan untuk mencegah role creep dan standing privileges.

Di episode 10 selanjutnya kita akan membahas access governance & reviews — access reviews, attestation, dan Segregation of Duties (SoD). Siapkan proses governance kalian!