Bagikan melalui


Menyambungkan dari aplikasi Anda ke sumber daya tanpa menangani kredensial

Sumber daya Azure dengan dukungan identitas terkelola selalu menyediakan opsi untuk menentukan identitas terkelola untuk tersambung ke sumber daya Azure yang mendukung autentikasi Microsoft Entra. Dukungan identitas terkelola membuatnya tidak perlu bagi pengembang untuk mengelola kredensial dalam kode. Identitas terkelola adalah opsi autentikasi yang direkomendasikan saat bekerja dengan sumber daya Azure yang mendukungnya. Baca gambaran umum identitas terkelola.

Halaman ini menunjukkan cara mengonfigurasi App Service sehingga dapat tersambung ke Azure Key Vault, Azure Storage, dan Microsoft SQL Server. Prinsip yang sama dapat digunakan untuk sumber daya Azure apa pun yang mendukung identitas terkelola dan yang akan terhubung ke sumber daya yang mendukung autentikasi Microsoft Entra.

Sampel kode menggunakan pustaka klien Azure Identity, yang merupakan metode yang direkomendasikan karena secara otomatis menangani banyak langkah untuk Anda, termasuk memperoleh token akses yang digunakan dalam koneksi.

Sumber daya apa yang dapat disambungkan dengan identitas terkelola?

Identitas terkelola dapat tersambung ke sumber daya apa pun yang mendukung autentikasi Microsoft Entra. Secara umum, tidak ada dukungan khusus yang diperlukan untuk sumber daya untuk memungkinkan identitas terkelola terhubung ke sumber daya tersebut.

Beberapa sumber daya tidak mendukung autentikasi Microsoft Entra, atau pustaka klien mereka tidak mendukung autentikasi dengan token. Terus baca untuk melihat panduan kami tentang cara menggunakan identitas Terkelola untuk mengakses kredensial dengan aman tanpa perlu menyimpannya dalam kode atau konfigurasi aplikasi Anda.

Membuat identitas terkelola

Ada dua jenis identitas terkelola: ditetapkan sistem dan ditetapkan pengguna. Identitas yang ditetapkan sistem langsung ditautkan ke satu sumber daya Azure. Saat sumber daya Azure dihapus, begitu juga identitasnya. Identitas terkelola yang ditetapkan pengguna dapat dikaitkan dengan beberapa sumber daya Azure, dan siklus hidupnya tidak bergantung pada sumber daya tersebut.

Kami menyarankan agar Anda menggunakan identitas terkelola yang ditetapkan pengguna, untuk sebagian besar skenario. Jika sumber daya sumber yang Anda gunakan tidak mendukung identitas terkelola yang ditetapkan pengguna, maka Anda harus merujuk ke dokumentasi penyedia sumber daya tersebut untuk mempelajari cara mengonfigurasinya agar memiliki identitas terkelola yang ditetapkan sistem.

Penting

Akun yang digunakan untuk membuat identitas terkelola memerlukan peran seperti "Kontributor Identitas Terkelola" untuk membuat identitas terkelola baru yang ditetapkan pengguna.

Buat identitas terkelola yang ditetapkan pengguna menggunakan opsi pilihan Anda:

Setelah Anda membuat identitas terkelola yang ditetapkan pengguna, perhatikan clientId dan principalId nilai yang dikembalikan saat identitas terkelola dibuat. Anda menggunakan principalId saat menambahkan izin, dan clientId dalam kode aplikasi Anda.

Mengonfigurasi App Service dengan identitas terkelola yang ditetapkan pengguna

Sebelum Anda dapat menggunakan identitas terkelola dalam kode Anda, kita harus menetapkannya ke App Service yang akan menggunakannya. Proses mengonfigurasi App Service untuk menggunakan identitas terkelola yang ditetapkan pengguna mengharuskan Anda menentukan pengidentifikasi sumber daya identitas terkelola di konfigurasi aplikasi Anda.

Menambahkan izin ke identitas

Setelah mengonfigurasi App Service untuk menggunakan identitas terkelola yang ditetapkan pengguna, berikan izin yang diperlukan ke identitas. Dalam skenario ini, kami menggunakan identitas ini untuk berinteraksi dengan Azure Storage, jadi Anda perlu menggunakan sistem Azure Role Based Access Control (RBAC) untuk memberikan izin identitas terkelola yang ditetapkan pengguna ke sumber daya.

Penting

Anda akan memerlukan peran seperti "Administrator Akses Pengguna" atau "Pemilik" untuk sumber daya target guna menambahkan penetapan Peran. Pastikan Anda memberikan hak istimewa paling sedikit yang diperlukan agar aplikasi dapat berjalan.

Sumber daya apa pun yang ingin Anda akses mengharuskan Anda memberikan izin identitas. Misalnya, jika Anda meminta token untuk mengakses Key Vault, Anda juga harus menambahkan kebijakan akses yang menyertakan identitas terkelola aplikasi atau fungsi Anda. Jika tidak, panggilan Anda ke Key Vault akan ditolak, bahkan jika Anda menggunakan token yang valid. Hal yang sama berlaku untuk Azure SQL Database. Untuk mempelajari selengkapnya tentang sumber daya mana yang mendukung token Microsoft Entra, lihat Layanan Azure yang mendukung autentikasi Microsoft Entra.

Menggunakan identitas terkelola dalam kode Anda

Setelah Anda menyelesaikan langkah-langkah yang diuraikan di atas, App Service Anda memiliki identitas terkelola dengan izin ke sumber daya Azure. Anda dapat menggunakan identitas terkelola untuk mendapatkan token akses yang dapat digunakan kode Anda untuk berinteraksi dengan sumber daya Azure, alih-alih menyimpan kredensial dalam kode Anda.

Kami menyarankan agar Anda menggunakan pustaka Azure Identity untuk bahasa pemrograman pilihan Anda. Pustaka memperoleh token akses untuk Anda, sehingga mudah untuk terhubung ke sumber daya target.

Baca selengkapnya tentang pustaka Azure Identity di bawah ini:

Menggunakan pustaka Azure Identity di lingkungan pengembangan Anda

Pustaka Azure Identity masing-masing menyediakan DefaultAzureCredential jenis. DefaultAzureCredential secara otomatis mencoba mengautentikasi melalui beberapa mekanisme, termasuk variabel lingkungan atau masuk interaktif. Jenis kredensial dapat digunakan di lingkungan pengembangan Anda menggunakan kredensial Anda sendiri. Ini juga dapat digunakan di lingkungan Azure produksi Anda menggunakan identitas terkelola. Tidak ada perubahan kode yang diperlukan saat Anda menyebarkan aplikasi Anda.

Jika Anda menggunakan identitas terkelola yang ditetapkan pengguna, Anda juga harus secara eksplisit menentukan identitas terkelola yang ditetapkan pengguna yang ingin Anda autentikasi dengan meneruskan ID klien identitas sebagai parameter. Anda dapat mengambil ID klien dengan menelusuri identitas di portal Azure.

Mengakses Blob di Azure Storage

using Azure.Identity;
using Azure.Storage.Blobs;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);                        

var blobServiceClient1 = new BlobServiceClient(new Uri("<URI of Storage account>"), credential);
BlobContainerClient containerClient1 = blobServiceClient1.GetBlobContainerClient("<name of blob>");
BlobClient blobClient1 = containerClient1.GetBlobClient("<name of file>");

if (blobClient1.Exists())
{
    var downloadedBlob = blobClient1.Download();
    string blobContents = downloadedBlob.Value.Content.ToString();                
}

Mengakses rahasia yang disimpan di Azure Key Vault

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);        

var client = new SecretClient(
    new Uri("https://<your-unique-key-vault-name>.vault.azure.net/"),
    credential);
    
KeyVaultSecret secret = client.GetSecret("<my secret>");
string secretValue = secret.Value;

Mengakses Azure SQL Database

using Azure.Identity;
using Microsoft.Data.SqlClient;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};

AccessToken accessToken = await new DefaultAzureCredential(credentialOptions).GetTokenAsync(
    new TokenRequestContext(new string[] { "https://database.windows.net//.default" }));                        

using var connection = new SqlConnection("Server=<DB Server>; Database=<DB Name>;")
{
    AccessToken = accessToken.Token
};
var cmd = new SqlCommand("select top 1 ColumnName from TableName", connection);
await connection.OpenAsync();
SqlDataReader dr = cmd.ExecuteReader();
while(dr.Read())
{
    Console.WriteLine(dr.GetValue(0).ToString());
}
dr.Close();	

Menyambungkan ke sumber daya yang tidak mendukung ID Microsoft Entra atau autentikasi berbasis token di pustaka

Beberapa sumber daya Azure belum mendukung autentikasi Microsoft Entra, atau pustaka klien mereka tidak mendukung autentikasi dengan token. Biasanya sumber daya ini adalah teknologi sumber terbuka yang mengharapkan nama pengguna dan kata sandi atau kunci akses dalam string koneksi.

Untuk menghindari penyimpanan kredensial dalam kode atau konfigurasi aplikasi, Anda dapat menyimpan kredensial sebagai rahasia di Azure Key Vault. Dengan menggunakan contoh yang ditampilkan di atas, Anda dapat mengambil rahasia dari Azure KeyVault menggunakan identitas terkelola, dan meneruskan kredensial ke string koneksi Anda. Pendekatan ini berarti bahwa tidak ada kredensial yang perlu ditangani langsung di kode atau lingkungan Anda.

Panduan jika Anda menangani token secara langsung

Dalam beberapa skenario, Anda mungkin ingin memperoleh token untuk identitas terkelola secara manual alih-alih menggunakan metode bawaan untuk terhubung ke sumber daya target. Skenario ini tidak mencakup pustaka klien untuk bahasa pemrograman yang Anda gunakan atau sumber daya target yang Anda sambungkan, atau menyambungkan ke sumber daya yang tidak berjalan di Azure. Saat memperoleh token secara manual, kami memberikan panduan berikut:

Cache token yang Anda peroleh

Untuk performa dan keandalan, sebaiknya aplikasi Anda menyimpan token dalam memori lokal, atau dienkripsi jika Anda ingin menyimpannya ke disk. Karena token Identitas terkelola berlaku selama 24 jam, tidak ada manfaat dalam meminta token baru secara teratur, karena yang di-cache akan dikembalikan dari titik akhir penerbitan token. Jika Anda melebihi batas permintaan, Anda akan dibatasi lajunya dan menerima kesalahan HTTP 429.

Saat memperoleh token, Anda dapat mengatur cache token kedaluwarsa 5 menit sebelum expires_on (atau properti yang setara) yang akan dikembalikan saat token dihasilkan.

Inspeksi token

Aplikasi Anda tidak boleh mengandalkan konten token. Konten token hanya ditujukan untuk audiens (sumber daya target) yang sedang diakses, bukan klien yang meminta token. Konten token dapat berubah atau dienkripsi di masa mendatang.

Jangan mengekspos atau memindahkan token

Token harus diperlakukan seperti kredensial. Jangan mengeksposnya kepada pengguna atau layanan lain; misalnya, solusi pengelogan/pemantauan. Mereka tidak boleh dipindahkan dari sumber daya sumber yang menggunakannya, selain untuk mengautentikasi terhadap sumber daya target.

Langkah berikutnya