Bagian 2: Kebutuhan autentikasi dalam skenario contoh ini

Bagian sebelumnya: Pengenalan dan latar belakang

Dalam skenario contoh ini, aplikasi utama memiliki tiga persyaratan autentikasi yang berbeda:

• Azure Key Vault

  Aplikasi harus mengautentikasi dengan Azure Key Vault untuk mengambil kunci API yang disimpan dengan aman yang diperlukan untuk memanggil layanan pihak ketiga.

• API pihak ketiga

  Setelah aplikasi mengambil kunci API, aplikasi menggunakan kunci untuk mengautentikasi dengan API pihak ketiga eksternal.

• Azure Queue Storage

  Setelah memproses permintaan, aplikasi harus mengautentikasi dengan Azure Queue Storage untuk mengantrekan pesan untuk pemrosesan asinkron atau ditangguhkan.

Tugas-tugas ini mengharuskan aplikasi mengelola tiga set kredensial:

• Dua set untuk sumber daya Azure (Key Vault dan Storage)

• Satu set untuk layanan eksternal (API pihak ketiga)

Tantangan autentikasi utama

Membangun aplikasi cloud yang aman memerlukan penanganan kredensial yang cermat, terutama ketika beberapa layanan terlibat. Contoh skenario ini menyajikan beberapa tantangan penting:

• Dependensi melingkar pada Key Vault

  Aplikasi ini menggunakan Azure Key Vault untuk menyimpan rahasia dengan aman, seperti kunci API pihak ketiga atau kredensial Azure Storage. Namun, untuk mengambil rahasia tersebut, aplikasi harus terlebih dahulu mengautentikasi dengan Key Vault. Situasi ini menciptakan masalah melingkar: Aplikasi memerlukan kredensial untuk mengakses Key Vault, tetapi Anda harus menyimpan kredensial tersebut dengan aman. Tanpa solusi yang aman, masalah ini dapat menyebabkan kredensial yang dikodekan secara permanen atau konfigurasi yang tidak aman di lingkungan pengembangan.

• Penanganan aman kunci API pihak ketiga

  Setelah mengambil kunci API dari Key Vault, aplikasi harus menggunakannya untuk memanggil layanan pihak ketiga eksternal. Tangani kunci ini dengan sangat hati-hati:

  • Jangan pernah hardcode dalam kode sumber atau file konfigurasi
  • Jangan pernah mencatatnya ke stdout, stderr, atau log aplikasi
  • Simpan hanya di memori dan akses saat runtime, tepat sebelum digunakan
  • Buang segera setelah permintaan selesai

  Kegagalan untuk mengikuti praktik ini meningkatkan risiko kebocoran kredensial atau penggunaan yang tidak sah.

• Mengamankan kredensial Azure Queue Storage

  Untuk menulis pesan ke Azure Queue Storage, aplikasi biasanya memerlukan string koneksi atau token akses bersama. Kredensial ini:

  • Harus disimpan di lokasi yang aman, seperti Key Vault
  • Tidak boleh muncul di log, jejak tumpukan, atau alat pengembang
  • Harus diakses hanya melalui mekanisme runtime aman
  • Memerlukan konfigurasi RBAC yang tepat jika menggunakan identitas terkelola

• Fleksibilitas lingkungan

  Aplikasi harus berjalan dengan andal di lingkungan pengembangan lokal dan produksi cloud, menggunakan basis kode yang sama dan logika kondisional minimal.

  Persyaratan ini berarti:

  • Jangan sematkan rahasia khusus lingkungan dalam kode
  • Jangan alihkan kredensial atau jalur logika secara manual
  • Menggunakan autentikasi berbasis identitas secara konsisten di seluruh lingkungan

autentikasi pertama Azure dengan Microsoft Entra ID

Seiring dengan meningkatnya kompleksitas dan integrasi aplikasi cloud dengan lebih banyak layanan, autentikasi yang aman dan lancar menjadi sangat penting. Azure menawarkan model identitas Azure-first melalui Microsoft Entra ID, memungkinkan manajemen identitas terpadu dan integrasi yang mulus dengan layanan Azure untuk autentikasi yang aman dan bebas kredensial.

Daripada mengelola rahasia secara manual atau menyematkan kredensial dalam kode aplikasi—praktik yang rentan terhadap risiko keamanan—Microsoft Entra ID memungkinkan aplikasi mengautentikasi dengan aman dengan menggunakan identitas terkelola.

Manfaat utama identitas terkelola Microsoft Entra adalah:

• Tidak ada rahasia dalam kode

  Aplikasi tidak lagi memerlukan string koneksi yang dikodekan secara permanen, rahasia klien, atau kunci.

• Identitas bawaan untuk aplikasi

  Azure dapat secara otomatis menetapkan identitas terkelola ke aplikasi Anda, sehingga dapat mengakses layanan dengan aman seperti Key Vault, Penyimpanan, dan SQL tanpa kredensial tambahan.

• Konsistensi lingkungan

  Model kode dan identitas yang sama berfungsi baik dalam pengembangan lokal maupun lingkungan yang dihosting Azure dengan menggunakan Azure SDK DefaultAzureCredential.

Alur identitas khusus lingkungan

Aplikasi yang menggunakan Microsoft Entra ID untuk autentikasi mendapatkan manfaat dari model identitas yang fleksibel dan berfungsi dengan mulus di lingkungan pengembangan yang dihosting di Azure maupun di lokal. Azure SDK DefaultAzureCredential menyediakan konsistensi ini dengan secara otomatis memilih metode identitas yang sesuai berdasarkan lingkungan.

Lingkungan Azure

Saat Anda menyebarkan aplikasi ke Azure:

• Aplikasi secara otomatis mendapatkan identitas terkelola.
• Azure mengelola penerbitan token dan siklus hidup kredensial secara internal, sehingga Anda tidak perlu menangani rahasia apa pun.
• Aplikasi mengakses layanan dengan menggunakan kebijakan akses Role-Based Access Control (RBAC) atau Key Vault.

Lingkungan pengembangan lokal

Selama pengembangan lokal:

• Perwakilan layanan berfungsi sebagai identitas aplikasi.
• Pengembang mengautentikasi dengan menggunakan integrasi Azure CLI (az login), variabel lingkungan, atau Visual Studio/VISUAL Code.
• Kode aplikasi yang sama berjalan tanpa modifikasi apa pun - hanya sumber identitas yang berubah.

Di kedua lingkungan, Azure SDK menggunakan DefaultAzureCredential, yang mengabstraksi sumber identitas dan secara otomatis memilih metode yang tepat.

Praktik terbaik untuk pengembangan yang aman

Meskipun Anda dapat mengatur rahasia sebagai variabel lingkungan (misalnya, melalui Pengaturan Azure App), pendekatan ini memiliki kelemahan:

• Anda harus mereplikasi rahasia secara manual di lingkungan lokal.
• Ada risiko rahasia bocor ke kontrol sumber.
• Anda mungkin memerlukan logika tambahan untuk membedakan antara lingkungan.

Sebagai gantinya, gunakan pendekatan berikut:

• Gunakan Key Vault untuk menyimpan kunci API pihak ketiga dan rahasia lainnya.
• Tetapkan identitas terkelola ke aplikasi yang Anda sebarkan.
• Gunakan prinsipal layanan untuk pengembangan lokal dan berikan hak akses yang sama.
• Gunakan DefaultAzureCredential dalam kode Anda untuk mengabstraksi logika autentikasi.
• Hindari menyimpan atau mencatat kredensial apa pun.

Alur autentikasi dalam praktik

Berikut cara kerja autentikasi saat runtime:

• Kode Anda membuat satu buah instance DefaultAzureCredential.
• Anda menggunakan kredensial ini untuk membuat instans klien (misalnya, SecretClient, QueueServiceClient).
• Saat aplikasi memanggil metode (misalnya, get_secret()), klien menggunakan kredensial untuk mengautentikasi permintaan.
• Azure memverifikasi identitas dan memeriksa apakah memiliki peran atau kebijakan yang benar untuk melakukan operasi.

Alur ini memastikan bahwa aplikasi Anda dapat mengakses layanan Azure dengan aman tanpa menyematkan rahasia dalam file kode atau konfigurasi. Ini juga memungkinkan Anda untuk beralih dengan mulus antara pengembangan lokal dan penyebaran cloud tanpa mengubah logika autentikasi Anda.