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 kunci API diambil, aplikasi menggunakannya 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 untuk sumber daya Azure (Key Vault dan Storage)

• Satu 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. Ini menciptakan masalah melingkar: Aplikasi memerlukan kredensial untuk mengakses Key Vault, tetapi kredensial tersebut harus disimpan dengan aman. Tanpa solusi yang aman, 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. Kunci ini harus ditangani dengan kehati-hatian yang sangat tinggi.

  • Tidak pernah dikodekan secara permanen dalam kode sumber atau file konfigurasi
  • Tidak pernah masuk ke log stdout, stderr, atau aplikasi
  • Hanya disimpan dalam memori dan diakses saat runtime, tepat sebelum digunakan
  • Segera dibuang 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.

  Ini berarti:

  • Tidak ada rahasia khusus lingkungan yang disematkan dalam kode
  • Tidak perlu mengalihkan info masuk atau jalur logika secara manual
  • Penggunaan autentikasi berbasis identitas yang konsisten di seluruh lingkungan

autentikasi Azure-First dengan ID Microsoft Entra

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—ID Microsoft Entra memungkinkan aplikasi mengautentikasi dengan aman 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, memungkinkan akses aman ke layanan, seperti Key Vault, Storage, dan SQL tanpa kredensial tambahan.

• Konsistensi lingkungan

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

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. Konsistensi ini dicapai menggunakan Azure SDK DefaultAzureCredential, yang secara otomatis memilih metode identitas yang sesuai berdasarkan lingkungan.

Lingkungan Azure

Saat aplikasi disebarkan ke Azure:

• Identitas terkelola secara otomatis ditetapkan ke aplikasi.
• Azure menangani penerbitan token dan siklus hidup kredensial secara internal—tidak diperlukan rahasia manual.
• Aplikasi ini menggunakan kebijakan akses Role-Based Access Control (RBAC) atau Key Vault untuk mengakses layanan

Lingkungan pengembangan lokal

Selama pengembangan lokal:

• Prinsipal layanan bertindak sebagai identitas aplikasi.
• Pengembang mengautentikasi menggunakan integrasi Azure CLI (az login), variabel lingkungan, atau Visual Studio/VS Code.
• Kode aplikasi yang sama berjalan tanpa modifikasi—hanya sumber identitas yang berubah.

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

Praktik terbaik untuk pengembangan yang aman

Meskipun dimungkinkan untuk mengatur rahasia sebagai variabel lingkungan (misalnya, melalui Pengaturan Aplikasi Azure), pendekatan ini memiliki kelemahan:

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

Sebagai gantinya, pendekatan yang direkomendasikan adalah:

• 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.

Bagian 3 - Implementasi API pihak ketiga >>>