Tentang Sesi Ini
Ringkasan & metadata
Sesi ini membahas satu masalah yang nyaris selalu muncul saat startup tumbuh cepat: bagaimana mengelola akses dan identitas di AWS secara aman dan terukur tanpa menumpuk banyak IAM User? Di awal, membuat satu IAM User untuk tiap orang terasa praktis. Tetapi ketika tim membesar dan jumlah akun AWS bertambah, kebiasaan itu berubah menjadi bom waktu: kredensial jangka panjang tersebar di banyak tempat, sulit dilacak siapa punya akses ke apa, dan audit jadi mimpi buruk.
Berangkat dari pengalaman PayFazz (perusahaan fintech), sesi ini menawarkan cara pandang modern: berhenti "mencetak kunci permanen", dan mulai memberi kredensial sementara yang otomatis kedaluwarsa. Lebih jauh, izin tidak lagi diklik satu per satu di konsol, melainkan dikelola sebagai kode — pendekatan yang disebut "Access as Code": akses didefinisikan, ditinjau, dan diaudit lewat berkas yang bisa di-review layaknya kode program.
Kenapa penting untuk Anda? Jika tim Anda masih menambah IAM User setiap kali ada karyawan atau proyek baru, dan mulai bingung "siapa sebenarnya yang bisa masuk ke akun produksi?", sesi ini memberi peta jalan keluar dari kekusutan itu — cocok untuk startup, scaleup, dan tim yang menghadapi audit kepatuhan.
PayFazz adalah fintech asal Indonesia yang membangun jaringan agen keuangan untuk melayani masyarakat yang belum tersentuh bank (unbanked) — memungkinkan warung dan agen melakukan transfer uang, tarik tunai, isi pulsa, serta bayar tagihan lewat satu platform. Perusahaan ini alumni Y Combinator dan mengklaim ratusan ribu agen terdaftar (dilaporkan 700.000+ agen di 514 kabupaten) serta belasan juta pengguna, dan telah mengantongi izin uang elektronik dari Bank Indonesia. Pada Maret 2021, PayFazz bergabung dengan Xfers (Singapura) membentuk Fazz Financial Group — yang pada 2022 meraih pendanaan Seri C sekitar US$100 juta dipimpin Tiger Global; belakangan PayFazz melakukan rebranding menjadi Fazz Agen. Sebagai fintech yang tumbuh cepat lintas negara, tantangan mengelola akses tim dan banyak akun cloud secara aman selaras dengan tema sesi ini.
Sumber: TechCrunch, Fintech Singapore, Infobank, dan situs resmi Fazz (fazz.com). Detail arsitektur AWS/IAM spesifik PayFazz tidak dipublikasikan secara terbuka; contoh penerapan & arsitektur di sesi ini bersifat ilustratif kecuali disebutkan.
Masalahnya & Cara Modern Mengatasinya
Masalah "IAM user sprawl"
Di AWS, IAM User adalah identitas permanen yang biasanya membawa kredensial jangka panjang: kata sandi konsol dan/atau pasangan access key yang tidak pernah kedaluwarsa dengan sendirinya. Membuatnya mudah — dan itulah masalahnya. Kemudahan itu mendorong tim terus menambah IAM User seiring bertambahnya orang, layanan, dan skrip, hingga terjadi apa yang disebut "IAM user sprawl": penumpukan pengguna dan kunci yang tak terkendali.
Kenapa penumpukan ini riskan?
- Kredensial jangka panjang tersebar. Access key yang tak kedaluwarsa gampang tercecer — masuk ke berkas konfigurasi, riwayat terminal, repo kode, atau laptop yang hilang. Sekali bocor, ia berlaku selamanya sampai seseorang sadar dan mencabutnya.
- Sulit diaudit. Saat ada ratusan IAM User di banyak akun, menjawab "siapa yang bisa mengakses data produksi?" jadi pekerjaan berhari-hari.
- Karyawan datang dan pergi. Onboarding berarti membuat user baru; offboarding berarti mencabut manual di banyak tempat — dan yang terlupa menjadi celah keamanan.
- Izin berlebih menumpuk. Karena repot, izin sering diberikan berlebihan "supaya tidak error", melanggar prinsip hak akses paling minim.
Pendekatan modern
Alih-alih menambah IAM User, sesi mendorong enam pilar berikut. Ganti kunci permanen dengan identitas terpusat dan kredensial sementara, lalu kelola izinnya sebagai kode.
Benang merahnya: identitas terpusat sekali, akses diberikan sementara, dan aturannya ditulis sebagai kode. Dengan begitu, menambah atau mencabut akses tim menjadi soal mengubah satu berkas yang di-review — bukan mengklik puluhan tombol di banyak akun.
Analogi yang Mudah Dicerna
Kartu akses sementara vs kunci permanen
Ibaratnya, bayangkan sebuah gedung perkantoran besar dengan banyak ruangan (akun AWS). Cara lama: setiap orang diberi seikat kunci logam permanen untuk tiap pintu yang pernah ia butuhkan. Awalnya rapi. Tapi setelah ratusan karyawan dan proyek, kunci-kunci itu menumpuk, digandakan, tercecer, dan tak ada yang tahu pasti siapa memegang kunci apa. Kalau satu kunci hilang, ia tetap membuka pintu selamanya sampai kuncinya diganti.
Cara modern: pasang satu meja resepsionis (IAM Identity Center). Setiap orang cukup menunjukkan identitasnya sekali di sana (login SSO / federasi), lalu diberi kartu akses sementara yang otomatis kedaluwarsa beberapa jam kemudian. Kartu itu hanya membuka pintu yang sesuai perannya hari itu. Selesai kerja, kartu mati sendiri — tak ada kunci permanen yang perlu ditarik kembali, tak ada tumpukan yang menggunung.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, pola "Access as Code" bekerja seperti ini: identitas karyawan berasal dari penyedia identitas (Google Workspace, Okta, atau Active Directory) yang difederasikan ke IAM Identity Center. Di sana didefinisikan permission set (kumpulan izin) yang ditulis dan dikelola sebagai kode lewat Terraform/CloudFormation. Saat login, pengguna menerima kredensial sementara untuk meng-assume peran (IAM Role) di akun tujuan — bukan IAM User permanen. Semua aktivitas tercatat oleh layanan audit.
Alur akses satu kali login
Ketika seorang engineer perlu masuk ke akun produksi untuk memeriksa sesuatu, inilah yang terjadi — tanpa satu pun IAM User baru dibuat:
- Login sekali. Engineer masuk lewat penyedia identitas perusahaan (mis. Google/Okta) ke portal IAM Identity Center.
- Pilih peran. Portal menampilkan akun & peran yang boleh ia gunakan, sesuai permission set yang didefinisikan sebagai kode.
- Terbitkan kartu sementara. Identity Center menerbitkan kredensial sementara (berlaku beberapa jam) untuk meng-assume IAM Role di akun tujuan.
- Kerja dengan izin minim. Ia bekerja hanya dalam batas izin peran itu (least-privilege).
- Otomatis kedaluwarsa. Setelah masa berlaku habis, kredensial mati sendiri — tak perlu dicabut manual.
- Terekam. Seluruh aktivitas tercatat untuk audit & kepatuhan.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas — mulai dari startup yang tumbuh cepat hingga organisasi multi-akun yang menghadapi audit.
PayFazz — kelola akses tim yang tumbuh cepat
Sebagai fintech yang berkembang pesat, PayFazz menghadapi lonjakan jumlah engineer dan akun AWS. Alih-alih menambah IAM User setiap kali ada orang baru, mereka memusatkan identitas di IAM Identity Center dengan federasi dari penyedia identitas perusahaan. Setiap akses ke akun diberikan lewat peran & kredensial sementara, dan izinnya dikelola sebagai kode. Onboarding karyawan menjadi soal menambahkan mereka ke grup, sementara offboarding cukup mencabut satu keanggotaan — tanpa berburu kunci permanen di banyak tempat.
Perusahaan dengan puluhan akun AWS
Sebuah perusahaan memisahkan lingkungan (dev, staging, produksi) dan tim ke dalam banyak akun AWS di bawah satu organisasi. Tanpa strategi, tiap akun akan punya IAM User-nya sendiri — mimpi buruk pengelolaan. Dengan Identity Center di tingkat organisasi dan permission set yang didefinisikan lewat Terraform, akses lintas akun menjadi konsisten dan dapat direview. Perubahan izin melewati proses pull request dengan persetujuan, sehingga tak ada lagi perubahan diam-diam di konsol.
Menjawab auditor dengan tenang
Saat regulator atau auditor bertanya "siapa yang bisa mengakses data produksi, dan atas dasar apa?", tim yang memakai Access as Code tinggal menunjukkan berkas kode yang menjadi sumber kebenaran, ditambah audit trail yang mencatat setiap sesi akses sementara. Karena kredensial otomatis kedaluwarsa dan izin bersifat least-privilege, permukaan risiko jauh lebih kecil — dan jawaban atas pertanyaan audit tersedia dalam hitungan menit, bukan hari.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- IAM User bukan default yang sehat. Menumpuknya menciptakan kredensial jangka panjang yang tersebar dan sulit diaudit.
- Pusatkan identitas dengan IAM Identity Center dan federasi (Google/Okta/AD): satu pintu masuk untuk banyak akun.
- Ganti kunci permanen dengan kartu sementara. Peran & kredensial sementara yang kedaluwarsa otomatis, dengan izin paling minim.
- Kelola akses sebagai kode. Terraform/CloudFormation + permission set + review otomatis membuat izin dapat ditelusuri dan diaudit.
- Mulai bertahap. Tak perlu migrasi semuanya sekaligus — pindahkan tim dan akun satu per satu, sambil menghentikan pembuatan IAM User baru.