Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
ID Microsoft Entra, saat digunakan dengan Azure Key Vault, menyediakan pendekatan yang kuat dan aman untuk mengautentikasi aplikasi ke layanan Azure dan platform pihak ketiga yang memerlukan kunci akses atau kredensial. Kombinasi ini menghilangkan kebutuhan untuk mengodekan rahasia dalam kode aplikasi, alih-alih mengandalkan identitas terkelola, kontrol akses berbasis peran (RBAC), dan manajemen rahasia terpusat melalui Key Vault. Pendekatan ini menyederhanakan manajemen identitas dan meningkatkan postur keamanan di lingkungan cloud.
Panduan ini menjelajahi mekanisme autentikasi ini melalui contoh praktis yang disediakan di repositori GitHub: github.com/Azure-Samples/python-integrated-authentication.
Sampel menunjukkan bagaimana aplikasi Python dapat:
Mengautentikasi dengan Azure menggunakan DefaultAzureCredential
Mengakses rahasia Azure Key Vault tanpa menyimpan kredensial
Berkomunikasi dengan aman dengan layanan Azure lainnya seperti Azure Storage, Cosmos DB, dan banyak lagi
Artikel ini adalah bagian dari seri yang menyediakan panduan terperinci tentang cara mengautentikasi aplikasi Python dengan ID Microsoft Entra, Azure Key Vault, dan Azure Queue Storage dengan menggunakan pustaka Azure Python SDK azure-identity .
Bagian 1: Latar Belakang
Meskipun banyak layanan Azure mengandalkan kontrol akses berbasis peran (RBAC) secara eksklusif, sementara yang lain memerlukan akses melalui rahasia atau kunci. Layanan tersebut termasuk Azure Storage, database, Foundry Tools, Key Vault, dan Event Hubs
Saat membangun aplikasi cloud yang berinteraksi dengan layanan ini, pengembang dapat menggunakan portal Microsoft Azure, CLI, atau PowerShell untuk menghasilkan dan mengonfigurasi kunci akses khusus layanan. Kunci ini terkait dengan kebijakan akses tertentu untuk mencegah akses yang tidak sah. Namun, model ini mengharuskan aplikasi Anda mengelola kunci secara eksplisit dan mengautentikasi secara terpisah dengan setiap layanan, proses yang melelahkan dan rawan kesalahan.
Menyematkan rahasia secara langsung dalam kode atau menyimpannya pada mesin pengembang berisiko mengeksposnya di:
- Kontrol sumber
- Lingkungan lokal yang tidak aman
- Log atau ekspor konfigurasi yang tidak disengaja
Azure Menawarkan Dua Layanan Utama untuk Meningkatkan Keamanan dan Menyederhanakan Autentikasi:
- Azure Key Vault Azure Key Vault menyediakan penyimpanan berbasis cloud yang aman untuk rahasia, termasuk kunci akses, string koneksi, dan sertifikat. Dengan mengambil rahasia dari Key Vault hanya pada runtime, aplikasi menghindari mengekspos data sensitif dalam kode sumber atau file konfigurasi.
- Dengan identitas terkelola Microsoft Entra, aplikasi Anda dapat mengautentikasi sekali dengan ID Microsoft Entra. Dari sana, layanan Azure dapat mengakses layanan Azure lainnya—termasuk Key Vault—tanpa mengelola kredensial secara langsung.
Pendekatan ini menyediakan:
- Kode bebas kredensial (tidak ada rahasia dalam kontrol sumber)
- Integrasi yang mulus dengan layanan Azure
- Konsistensi lingkungan: kode yang sama berjalan secara lokal dan di cloud dengan konfigurasi minimal
Panduan ini menunjukkan cara menggunakan identitas terkelola Microsoft Entra dan Key Vault bersama-sama di aplikasi yang sama. Dengan menggunakan ID Microsoft Entra dan Key Vault bersama-sama, aplikasi Anda tidak perlu mengautentikasi dirinya sendiri dengan layanan Azure individual, dan dapat dengan mudah dan aman mengakses kunci apa pun yang diperlukan untuk layanan pihak ketiga.
Penting
Artikel ini menggunakan istilah umum generik "kunci" untuk merujuk ke apa yang disimpan sebagai "rahasia" di Azure Key Vault, seperti kunci akses untuk REST API. Penggunaan ini tidak boleh dikacaukan dengan manajemen kunci kriptografi Key Vault, yang merupakan fitur terpisah dari rahasia Key Vault.
Contoh skenario aplikasi cloud
Untuk memahami proses autentikasi Azure lebih dalam, pertimbangkan skenario berikut: Aplikasi web Flask disebarkan ke Azure App Service. Ini mengekspos titik akhir API publik yang tidak terautentikasi, yang mengembalikan data JSON sebagai respons permintaan HTTP.
Untuk menghasilkan responsnya, API memanggil API pihak ketiga yang memerlukan kunci akses. Alih-alih menyimpan kunci ini dalam file kode atau konfigurasi, aplikasi mengambilnya dengan aman saat runtime dari Azure Key Vault menggunakan identitas terkelola Microsoft Entra.
Sebelum mengembalikan responsnya ke klien, aplikasi menulis pesan ke Azure Storage Queue untuk pemrosesan asinkron. Pesan dapat mewakili tugas, log, atau sinyal, meskipun pemrosesan hilir bukan fokus skenario ini.
Nota
Meskipun titik akhir API publik biasanya dilindungi oleh kunci akses atau mekanisme autentikasi mereka sendiri, panduan ini mengasumsikan titik akhir terbuka dan tidak diautentikasi.
Penyederhanaan ini membantu mengisolasi persyaratan autentikasi internal aplikasi—seperti mengakses Azure Key Vault dan Azure Storage—dari masalah autentikasi apa pun yang terkait dengan klien eksternal.
Skenario ini hanya berfokus pada perilaku aplikasi dan tidak menunjukkan atau melibatkan pemanggil eksternal yang mengautentikasi dengan titik akhir.