Cara Managed Identity Menghilangkan Kata Sandi Hardcoded di Azure

By Mirko Peters · 2026-08-13

Selamat datang kembali di blog pendamping podcast kami! Jika Anda sudah membangun aplikasi selama beberapa waktu, Anda kemungkinan besar pernah menemui masalah klasik yang sudah lama ada…

Automatically translated with AI from the original post. Read the English original

Selamat datang kembali di blog pendamping podcast kami! Jika Anda sudah membangun aplikasi cukup lama, kemungkinan besar Anda pernah menghadapi masalah klasik tentang cara menghubungkan kode ke database, API, atau akun penyimpanan cloud. Dahulu, pengembang mengatasinya dengan memasukkan connection string, kata sandi database, atau client secret langsung ke dalam file konfigurasi, variabel lingkungan, atau, yang lebih buruk, menuliskannya langsung (hardcode) di dalam repositori kode sumber. Selama aplikasi bisa membaca secret tersebut, aplikasi bisa melakukan autentikasi dan menjalankan tugasnya. Namun, apa yang terjadi ketika kode tersebut tidak sengaja di-push ke repositori GitHub publik? Apa yang terjadi ketika seorang karyawan yang kecewa keluar dari perusahaan, atau penyerang mendapatkan akses baca ke pengaturan aplikasi Anda? Seketika itu juga, seluruh infrastruktur Anda terkompromi. Dalam arsitektur cloud modern, ini adalah risiko yang tidak dapat diterima. Hari ini, kita akan membahas secara mendalam bagaimana Managed Identity di Microsoft Azure sepenuhnya menghilangkan kebutuhan akan kata sandi hardcoded, dengan menggantikan secret statis dengan access token dinamis yang berumur pendek.

Pengantar Keamanan Cloud dan Secret Hardcoded

Model keamanan berbasis perimeter tradisional sangat mengandalkan anggapan bahwa begitu Anda berada di dalam jaringan perusahaan, Anda dapat dipercaya. Di dalam perimeter tersebut, aplikasi berkomunikasi menggunakan service account statis, kata sandi hardcoded, dan token berumur panjang yang jarang, atau bahkan tidak pernah, kedaluwarsa. Jika penyerang berhasil menembus perimeter, mereka memperoleh akses ke kumpulan kredensial statis yang dapat digunakan kembali tanpa batas waktu.

Komputasi cloud sepenuhnya meruntuhkan perimeter ini. Workload kami kini tersebar di lingkungan multi-cloud, pusat data on-premises, platform SaaS, dan fungsi serverless yang terdistribusi. Dalam dunia baru ini, keamanan harus mengikuti identitas workload itu sendiri. Secret hardcoded adalah bom waktu. Secret tersebut tidak dirotasi secara otomatis, sangat sulit diaudit, dan tidak memberi ruang sedikit pun untuk kesalahan jika bocor. Untuk benar-benar menerapkan keamanan Zero Trust, kita harus memisahkan kredensial dari kode sumber sepenuhnya. Kita membutuhkan mekanisme autentikasi di mana aplikasi dapat membuktikan identitasnya tanpa perlu mengetahui atau menyimpan kata sandi.

Memahami Identitas Pengguna vs. Identitas Workload di Entra ID

Untuk memahami bagaimana keamanan cloud berkembang, kita terlebih dahulu perlu melihat bagaimana Microsoft Entra ID mengelola entitas yang mengakses sistem kita. Secara garis besar, Microsoft Entra ID mengelompokkan identitas ke dalam dua kategori utama: identitas pengguna dan identitas workload.

Identitas pengguna merepresentasikan manusia: karyawan, mitra, kontraktor, dan pelanggan. Manusia berinteraksi dengan sistem secara dinamis dan melakukan autentikasi menggunakan metode yang dirancang untuk orang, seperti kata sandi, Windows Hello for Business, kunci keamanan FIDO2, dan autentikasi multifaktor. Manusia lupa kata sandi, menjadi korban serangan phishing, dan memerlukan pengaturan ulang kata sandi oleh administrator.

Identitas workload, di sisi lain, merepresentasikan perangkat lunak. Ini mencakup aplikasi, layanan latar belakang, skrip otomatisasi, Azure Functions, Logic Apps, pipeline deployment DevOps, dan agen AI. Workload tidak minum kopi, tidak mengklik email phishing, dan tidak dapat menyelesaikan permintaan autentikasi multifaktor interaktif di ponsel. Mereka perlu melakukan autentikasi secara non-interaktif, terprogram, dan terus-menerus. Memperlakukan identitas workload seperti identitas pengguna dengan memberinya kata sandi statis adalah salah satu jebakan paling umum dalam arsitektur cloud. Identitas workload memerlukan model tata kelola, manajemen siklus hidup, dan alur autentikasi otomatis tersendiri yang khusus.

Mengurai App Registration, Service Principal, dan Managed Identity

Jika Anda pernah mengonfigurasi aplikasi di Microsoft Entra ID, Anda pasti pernah menemui tiga istilah yang sering menimbulkan kebingungan: Application Registration, Service Principal, dan Managed Identity. Mari kita uraikan secara sederhana.

Sebuah Application Registration adalah definisi global atau cetak biru dari aplikasi Anda. Saat Anda mendaftarkan aplikasi di Microsoft Entra ID, Anda sedang membuat identitas globalnya di seluruh ekosistem multi-penyewa. Di sinilah Anda menentukan izin apa saja yang mungkin dibutuhkan aplikasi, endpoint autentikasi apa yang digunakannya, dan URI apa saja yang terkait dengannya. Anggap Application Registration sebagai templat paspor.

Sebuah Service Principal adalah instans lokal dari aplikasi tersebut di dalam penyewa tertentu. Jika sebuah aplikasi bersifat multi-penyewa, aplikasi itu akan memiliki satu Application Registration di penyewa penerbit, tetapi memiliki Service Principal terpisah di setiap penyewa pelanggan tempat aplikasi itu di-deploy dan diberi persetujuan. Service Principal adalah tempat administrator benar-benar memberikan izin, menerapkan kebijakan Akses Bersyarat, dan mengontrol siapa yang dapat mengakses aplikasi secara lokal. Anggap Service Principal sebagai paspor yang sudah dicap resmi untuk masuk ke negara tertentu.

Sebuah Managed Identity membawa konsep ini selangkah lebih jauh, khususnya untuk resource yang berjalan di dalam Microsoft Azure. Alih-alih developer harus membuat Application Registration secara manual, menghasilkan client secret, menyimpan secret tersebut di variabel lingkungan, dan menulis kode untuk menangani siklus hidup autentikasi, Azure menangani seluruh proses itu di balik layar. Azure membuat, mengelola, dan merotasi kredensial yang mendasarinya secara otomatis untuk Anda. Developer cukup meminta resource Azure untuk menggunakan Managed Identity-nya, dan Azure yang mengurus sisanya.

Bagaimana Managed Identity Menghilangkan Kata Sandi dan Kredensial yang Ditanamkan dalam Kode

Keunggulan Managed Identity terletak pada cara ia mengubah transaksi autentikasi secara mendasar. Saat Anda menggunakan Managed Identity untuk resource Azure, seperti Azure App Service, Virtual Machine, atau Azure Function, benar-benar tidak ada kata sandi, secret, atau sertifikat yang disimpan di dalam kode atau pengaturan konfigurasi Anda.

Ketika aplikasi Anda perlu mengakses resource yang dilindungi, seperti database atau API, aplikasi tidak mencari kata sandi yang tersimpan. Sebaliknya, aplikasi membuat panggilan lokal ke endpoint Azure Instance Metadata Service (IMDS), yang hanya dapat diakses secara aman dari dalam resource Azure tertentu tersebut. Platform yang mendasari resource Azure kemudian meminta JSON Web Token (JWT) berumur pendek langsung dari Microsoft Entra ID atas nama aplikasi.

Microsoft Entra ID memverifikasi identitas resource Azure, menerbitkan access token yang ditandatangani secara kriptografis dengan masa berlaku yang sangat singkat (biasanya sekitar satu jam), lalu mengembalikannya ke aplikasi. Aplikasi kemudian menggunakan token ini untuk mengautentikasi ke layanan target. Karena token cepat kedaluwarsa, bahkan jika penyerang berhasil mencegatnya, celah kerentanannya sangat sempit. Selain itu, karena tidak ada kata sandi statis yang ditulis di dalam kode, tidak ada yang bisa secara tidak sengaja bocor ke repositori publik oleh developer.

Mengintegrasikan Azure Key Vault dan Access Token Berumur Pendek

Meskipun Managed Identity menghilangkan kebutuhan akan kata sandi aplikasi, Anda mungkin bertanya-tanya bagaimana aplikasi menangani secret yang benar-benar berasal dari luar, seperti API key untuk layanan pihak ketiga yang tidak mendukung autentikasi Microsoft Entra. Di sinilah Azure Key Vault berperan, bekerja berdampingan dengan Managed Identity.

Alih-alih menanamkan API key pihak ketiga di kode sumber, Anda menyimpan secret tersebut dengan aman di dalam Azure Key Vault. Kemudian, Anda memberikan izin kepada Managed Identity dari resource Azure Anda untuk membaca secret dari Key Vault tersebut menggunakan Azure Role-Based Access Control (RBAC) atau kebijakan akses Key Vault.

Saat aplikasi Anda mulai berjalan, aplikasi menggunakan Managed Identity-nya untuk mengautentikasi ke Azure Key Vault, mengambil API key pihak ketiga yang dibutuhkan secara dinamis di memori, lalu menggunakannya. Tidak ada satu titik pun di mana kredensial terekspos di kode sumber. Aplikasi menggunakan mekanisme berbasis identitas yang aman untuk mengambil secret, alih-alih bergantung pada string statis yang tertanam di file konfigurasi.

Mengamankan Workload Identity dengan Prinsip Hak Akses Minimum dan Tata Kelola

Menghilangkan kata sandi yang ditanamkan dalam kode adalah kemenangan besar bagi keamanan, tetapi men-deploy Managed Identity bukan model operasional yang bisa dibiarkan begitu saja. Workload identity memerlukan tata kelola yang kuat, sama seperti akun pengguna manusia.

Pertama-tama, Anda harus benar-benar menerapkan prinsip hak akses minimal (least privilege). Jangan memberikan peran kontributor yang luas atau izin Microsoft Graph yang berlebihan kepada identitas beban kerja hanya agar segalanya cepat berjalan. Jika skrip otomatisasi latar belakang hanya perlu membaca item dari kontainer Azure Storage tertentu, berikan akses Storage Blob Data Reader ke kontainer persis itu, tidak lebih. Jika identitas beban kerja tersebut suatu saat disusupi, dampaknya tetap minimal.

Kedua, Anda perlu terus memantau dan mengaudit identitas beban kerja Anda. Organisasi sering membuat service principal dan managed identity untuk proyek proof-of-concept, skrip otomatisasi, dan integrasi sementara, lalu membiarkannya berjalan tanpa batas waktu dengan hak akses tinggi. Terapkan tinjauan keamanan secara berkala untuk mengidentifikasi service principal yatim piatu, akun otomatisasi yang tidak digunakan, dan kredensial yang sudah usang. Memanfaatkan fitur seperti Microsoft Entra ID Protection dan menyiapkan logging yang andal melalui Azure Monitor akan memastikan Anda memiliki visibilitas penuh tentang kapan dan bagaimana identitas beban kerja Anda mengakses lingkungan Anda.

Memilih Strategi Identitas yang Tepat untuk Setiap Beban Kerja Cloud

Dengan begitu banyak opsi dalam ekosistem identitas Microsoft, bagaimana Anda memilih strategi autentikasi yang tepat untuk beban kerja spesifik Anda? Keputusannya umumnya bergantung pada di mana aplikasi Anda berjalan dan bagaimana arsitekturnya dirancang.

Jika kode Anda berjalan di dalam Microsoft Azure, baik di Azure App Services, Azure Functions, Virtual Machines, Container Instances, maupun Azure Kubernetes Service, pilihan pertama Anda selalu harus berupa Managed Identity. Anda dapat memilih antara System-Assigned Managed Identity (yang siklus hidupnya terikat 1:1 langsung dengan resource Azure) atau User-Assigned Managed Identity (yang dapat dibuat secara independen dan ditetapkan ke beberapa resource Azure untuk pengelolaan yang lebih mudah).

Jika aplikasi Anda berjalan di luar Azure, misalnya di server on-premises, di AWS, atau sebagai bagian dari pipeline CI/CD di GitHub Actions, Managed Identity yang dihosting langsung oleh infrastruktur Azure bukanlah pilihan. Dalam skenario ini, Anda sebaiknya memanfaatkan Workload Identity Federation. Cara ini memungkinkan platform eksternal untuk menukar token langsung dengan Microsoft Entra ID menggunakan kepercayaan OpenID Connect (OIDC), sehingga sepenuhnya menghilangkan kebutuhan untuk mengelola, merotasi, atau menyimpan client secret berumur panjang.

Terakhir, untuk aplikasi enterprise kustom tradisional yang memerlukan autentikasi klien ketika Managed Identity maupun federasi tidak memungkinkan, sertifikat yang dikelola dengan hati-hati selalu harus diutamakan dibandingkan client secret berumur panjang. Dengan menggabungkan Microsoft Entra Workload Identities, Azure Key Vault, prinsip Zero Trust, dan akses hak minimal, organisasi Anda dapat sepenuhnya menghapus kata sandi yang tertanam di dalam kode dan membangun arsitektur cloud yang sangat tangguh.

Kesimpulan dan Langkah Selanjutnya untuk Keamanan Cloud Modern

Kata sandi yang tertanam di dalam kode dan string koneksi statis adalah peninggalan era yang sudah usang dalam keamanan TI. Dengan merangkul Microsoft Entra Workload Identities dan Azure Managed Identities, kita dapat sepenuhnya menghilangkan risiko yang terkait dengan kredensial yang tertanam, melindungi repositori kode sumber kita dari kebocoran yang tidak disengaja, dan menerapkan akses hak minimal yang ketat di seluruh aplikasi cloud-native kita. Token akses berumur pendek memastikan bahwa meskipun sebuah token berhasil disadap, masa berlakunya terlalu singkat untuk menimbulkan kerusakan jangka panjang, sehingga postur keamanan kita bergeser secara mendasar dari pertahanan reaktif menuju perlindungan proaktif.

Untuk mendalami topik ini lebih jauh dan mendengarkan tips implementasi praktis dari lapangan, jangan lewatkan episode podcast terkait: Entra Workload Identities - Simply Explained. Simak selagi kami menguraikan konsep-konsep ini lebih lanjut untuk membantu Anda mengamankan lingkungan Azure dan Microsoft 365 Anda seperti seorang profesional!