Bagian 2: Kebutuhan autentikasi dalam skenario

Bagian sebelumnya: Pendahuluan dan latar belakang

Dalam skenario contoh ini, aplikasi utama memiliki persyaratan autentikasi berikut:

• Autentikasi dengan Azure Key Vault untuk mengakses kunci API pihak ketiga yang tersimpan.
• Autentikasi dengan API pihak ketiga menggunakan kunci API.
• Autentikasi dengan Azure Queue Storage menggunakan kredensial yang diperlukan untuk akun penyimpanan.

Dengan tiga persyaratan yang berbeda ini, aplikasi harus mengelola tiga set kredensial: dua untuk sumber daya Azure (Key Vault dan Queue Storage) dan satu untuk sumber daya eksternal (API pihak ketiga).

Seperti disebutkan sebelumnya, Anda dapat mengelola semua kredensial di Key Vault dengan aman kecuali kredensial yang diperlukan untuk Key Vault itu sendiri. Setelah aplikasi diautentikasi dengan Key Vault, aplikasi kemudian dapat mengambil kunci lain pada waktu proses untuk mengautentikasi dengan layanan seperti Queue Storage.

Namun, pendekatan ini masih mengharuskan aplikasi untuk mengelola kredensial secara terpisah untuk Key Vault. Bagaimana kemudian Anda dapat mengelola kredensial tersebut dengan aman dan membuatnya berfungsi baik untuk pengembangan lokal maupun dalam penyebaran produksi Anda di cloud?

Solusi parsial adalah menyimpan kunci dalam variabel lingkungan sisi server, yang setidaknya menjaga kunci di luar kontrol sumber. Misalnya, Anda dapat mengatur variabel lingkungan melalui pengaturan aplikasi dengan Azure App Service dan Azure Functions. Kelemahan dari pendekatan ini adalah bahwa kode pada stasiun kerja pengembang, Anda harus mereplikasi variabel lingkungan tersebut secara lokal, yang berisiko terpapar kredensial dan/atau penyertaan yang tidak disengaja dalam kontrol sumber. Anda dapat mengatasi masalah sampai batas tertentu dengan menerapkan prosedur khusus dalam versi pengembangan kode Anda, tetapi hal itu menambah kompleksitas pada proses pengembangan Anda.

Untungnya, autentikasi terintegrasi dengan MICROSOFT Entra ID memungkinkan aplikasi untuk menghindari penanganan kredensial Azure sama sekali.

Autentikasi terintegrasi dengan identitas terkelola

Banyak layanan Azure, seperti Storage dan Key Vault, terintegrasi dengan Microsoft Entra sehingga ketika aplikasi mengautentikasi dengan ID Microsoft Entra menggunakan identitas terkelola, aplikasi akan diautentikasi secara otomatis dengan sumber daya terhubung lainnya. Otorisasi untuk identitas ditangani melalui kontrol akses berbasis peran (RBAC) dan kadang-kadang melalui kebijakan akses lainnya.

Integrasi ini berarti Bahwa Anda tidak perlu menangani kredensial terkait Azure dalam kode aplikasi Anda dan kredensial tersebut tidak pernah muncul di workstation pengembang atau dalam kontrol sumber. Selain itu, setiap penanganan kunci untuk API dan layanan pihak ketiga dilakukan sepenuhnya pada waktu berjalan, sehingga menjaga kunci tersebut tetap aman.

Identitas terkelola hanya berfungsi dengan aplikasi yang disebarkan ke Azure. Untuk pengembangan lokal, Anda membuat perwakilan layanan terpisah untuk berperan sebagai identitas aplikasi saat berjalan secara lokal. Anda membuat perwakilan layanan ini tersedia untuk pustaka Azure menggunakan variabel lingkungan seperti yang dijelaskan dalam Mengautentikasi aplikasi Python ke layanan Azure selama pengembangan lokal menggunakan perwakilan layanan. Anda juga menetapkan izin peran ke perwakilan layanan ini di samping identitas terkelola yang digunakan di cloud.

Setelah Anda mengonfigurasi dan menetapkan peran untuk perwakilan layanan lokal, kode yang sama berfungsi baik secara lokal maupun di cloud untuk mengautentikasi aplikasi dengan sumber daya Azure. Detail-detail ini dibahas dalam Cara mengautentikasi dan mengotorisasi aplikasi, tetapi versi singkatnya adalah sebagai berikut:

1. Di kode Anda, buat objek DefaultAzureCredential yang secara otomatis menggunakan identitas terkelola Anda saat berjalan di Azure dan perwakilan layanan terpisah Anda saat berjalan secara lokal.

2. Gunakan kredensial ini saat Anda membuat objek klien yang sesuai untuk sumber daya apa pun yang ingin Anda akses (Key Vault, Queue Storage, dll.).

3. Autentikasi kemudian terjadi ketika Anda memanggil metode operasi melalui objek klien, yang menghasilkan panggilan REST API ke sumber daya.

4. Jika identitas aplikasi valid, Maka Azure juga memeriksa apakah identitas tersebut diotorisasi untuk operasi tertentu.

Bagian akhir tutorial ini menunjukkan semua detail proses dalam konteks skenario contoh dan kode sampel yang menyertainya.

Dalam skrip provisi sampel, semua sumber daya dibuat di bawah grup sumber daya bernama auth-scenario-rg. Grup ini dibuat menggunakan perintah Azure CLI az group create.

Bagian 3 - Implementasi API pihak ketiga >>>