Managed Identity untuk Autentikasi Tanpa Kata Sandi
Tetapkan managed identity yang ditetapkan sistem ke VM atau App Service, berikan akses RBAC ke Key Vault dan Blob Storage, lalu hapus rahasia dari kode aplikasi Anda.
Managed Identity untuk Autentikasi Tanpa Kata Sandi adalah pelajaran Cloud & IT Cert Prep gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Cloud & IT Cert Prep, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Cloud & IT Cert Prep mencakup 4 pelajaran total.
Masalah dengan Kredensial yang Disimpan
Secara tradisional, aplikasi terhubung ke layanan Azure seperti Storage atau Key Vault menggunakan string koneksi atau kunci API yang disimpan dalam file konfigurasi atau variabel lingkungan. Kredensial ini dapat tidak sengaja dikomit ke kontrol sumber, terekspos dalam log, atau dicuri dalam suatu pembobolan. Identitas Terkelola menghilangkan kebutuhan aplikasi untuk menyimpan kredensial sepenuhnya — sebagai gantinya, Azure sendiri menerbitkan dan merotasi token atas nama sumber daya, lalu aplikasi cukup meminta token terbaru kepada Azure saat runtime.
Apa Itu Identitas Terkelola?
Identitas Terkelola adalah perwakilan layanan yang dikelola secara otomatis di Microsoft Entra ID dan ditautkan ke sumber daya Azure (seperti VM, App Service, atau Function App). Platform Azure membuat dan memelihara kredensial identitas tersebut — serta merotasinya secara berkala — sehingga kode Anda tidak pernah menangani kata sandi atau rahasia. Aplikasi yang berjalan pada sumber daya tersebut memanggil titik akhir Azure Instance Metadata Service (IMDS) di http://169.254.169.254 untuk memperoleh token OAuth berumur pendek, yang kemudian diberikan kepada layanan Azure.
# Get a token from IMDS (runs inside an Azure VM or App Service)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' \
-H 'Metadata: true'Identitas yang Ditetapkan Sistem vs. Ditujukan Pengguna
Ada dua jenis identitas terkelola: Yang ditetapkan sistem terikat pada satu sumber daya Azure; identitas ini dibuat saat Anda mengaktifkannya pada sumber daya dan dihapus secara otomatis saat sumber daya dihapus. Yang ditujukan pengguna adalah identitas Entra ID independen yang Anda buat secara terpisah, lalu lampirkan ke satu atau beberapa sumber daya Azure. Identitas yang ditujukan pengguna berguna ketika beberapa layanan (misalnya, beberapa Function App) perlu berbagi identitas dan izin RBAC yang sama, sehingga menghindari duplikasi penetapan peran.
# Enable system-assigned managed identity on an App Service
az webapp identity assign \
--resource-group myRG \
--name myWebApp
# Create and assign a user-assigned identity
az identity create --name mySharedIdentity --resource-group myRG
az webapp identity assign \
--resource-group myRG \
--name myWebApp \
--identities mySharedIdentityMemberikan Izin RBAC
Setelah mengaktifkan identitas terkelola, Anda harus memberikan izin RBAC pada sumber daya Azure target. Misalnya, untuk mengizinkan App Service membaca blob, tetapkan peran Storage Blob Data Reader kepada identitas terkelola App Service pada akun penyimpanan. Penetapan RBAC mengikuti prinsip hak istimewa minimum — berikan hanya izin minimum yang diperlukan. Jangan pernah menetapkan Owner atau Contributor kepada identitas terkelola kecuali benar-benar diperlukan.
# Get the managed identity object ID
PRINCIPAL_ID=$(az webapp identity show \
--resource-group myRG --name myWebApp \
--query principalId --output tsv)
# Assign Storage Blob Data Reader role
az role assignment create \
--assignee $PRINCIPAL_ID \
--role 'Storage Blob Data Reader' \
--scope '/subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct'Menggunakan DefaultAzureCredential dalam Kode
Azure SDK menyediakan kelas DefaultAzureCredential yang secara otomatis mencoba beberapa metode autentikasi secara berurutan: variabel lingkungan, identitas beban kerja, identitas terkelola, Azure CLI, Visual Studio, dan lainnya. Saat aplikasi Anda berjalan di Azure (App Service, VM, Function App), DefaultAzureCredential secara otomatis menggunakan identitas terkelola tanpa perubahan kode apa pun. Secara lokal, pengembang melakukan autentikasi melalui sesi Azure CLI mereka. Kelas kredensial tunggal ini berfungsi di semua lingkungan tanpa logika bersyarat.
# Python example using DefaultAzureCredential
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
credential = DefaultAzureCredential()
client = BlobServiceClient(
account_url='https://mystorageacct.blob.core.windows.net',
credential=credential
)
blobs = client.get_container_client('mycontainer').list_blobs()
for blob in blobs:
print(blob.name)Identitas Terkelola dengan Azure Key Vault
Pola yang umum adalah menggunakan identitas terkelola untuk mengakses rahasia Azure Key Vault saat runtime. Daripada menyimpan kata sandi basis data dalam pengaturan aplikasi, Anda menyimpannya di Key Vault dan memberikan peran Key Vault Secrets User pada identitas terkelola aplikasi untuk vault tersebut. Saat dimulai, aplikasi mengambil rahasia dari Key Vault menggunakan DefaultAzureCredential. Pola ini memastikan rahasia tidak pernah disimpan dalam kode, file konfigurasi, atau variabel lingkungan — rahasia hanya ada di Key Vault dan diambil secara sementara.
# Python: Read a Key Vault secret using managed identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
credential = DefaultAzureCredential()
client = SecretClient(
vault_url='https://mykeyvault.vault.azure.net/',
credential=credential
)
secret = client.get_secret('DatabasePassword')
print('Secret value retrieved successfully')Identitas Terkelola untuk Akses Azure SQL
Azure SQL Database mendukung autentikasi Entra ID, yang berarti identitas terkelola dapat melakukan autentikasi ke SQL tanpa nama pengguna dan kata sandi. Untuk mengaktifkannya: tetapkan administrator Entra ID pada server SQL, lalu jalankan pernyataan CREATE USER dalam basis data target untuk nama tampilan identitas terkelola, dan berikan peran basis data yang sesuai. Aplikasi terhubung menggunakan DefaultAzureCredential dari Azure SDK dan token akses yang dicakup ke https://database.windows.net/, sepenuhnya tanpa kata sandi.
-- In Azure SQL: create a user for the managed identity
CREATE USER [myWebApp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [myWebApp];
ALTER ROLE db_datawriter ADD MEMBER [myWebApp];Identitas Terkelola untuk Beban Kerja AKS
Di Azure Kubernetes Service, pod individual dapat memperoleh token identitas terkelola menggunakan Workload Identity (penerus AAD Pod Identity). Anda membuat identitas terkelola yang ditujukan pengguna, memfederasikannya dengan penerbit OIDC AKS, memberi anotasi pada akun layanan Kubernetes, lalu webhook Azure Workload Identity menyisipkan variabel lingkungan yang diperlukan agar DefaultAzureCredential pada pod dapat memperoleh token. Ini memperluas autentikasi tanpa kata sandi ke layanan mikro dalam kontainer tanpa menyimpan rahasia dalam objek Kubernetes Secrets.
# Create federated identity credential for AKS workload identity
az identity federated-credential create \
--name myFederatedCredential \
--identity-name mySharedIdentity \
--resource-group myRG \
--issuer $(az aks show --resource-group myRG --name myAKS --query 'oidcIssuerProfile.issuerUrl' -o tsv) \
--subject 'system:serviceaccount:default:myapp-sa' \
--audiences 'api://AzureADTokenExchange'Mengaudit Akses Identitas Terkelola
Meskipun kredensial identitas terkelola tidak terlihat oleh pengembang, semua peristiwa penerbitan token dan akses sumber daya dicatat dalam log. Log masuk Entra ID mencatat setiap permintaan token oleh identitas terkelola, termasuk sumber daya yang diakses, waktu, dan keberhasilan permintaan. Log aktivitas Azure Storage dan log audit Key Vault mencatat operasi spesifik yang dilakukan menggunakan token. Log ini sangat penting untuk audit keamanan dan penyelidikan insiden yang melibatkan identitas terkelola.
# Query Entra ID sign-in logs for a managed identity
az monitor activity-log list \
--resource-group myRG \
--caller myWebApp \
--start-time 2024-06-01 \
--output tableBermigrasi dari String Koneksi
Jika aplikasi Anda saat ini menggunakan string koneksi atau kunci API, lakukan migrasi ke identitas terkelola dalam tiga langkah: Langkah 1 — Aktifkan identitas terkelola pada sumber daya komputasi. Langkah 2 — Tetapkan peran RBAC yang sesuai kepada identitas tersebut pada setiap layanan target. Langkah 3 — Perbarui kode aplikasi agar menggunakan DefaultAzureCredential, bukan string koneksi. Hapus string koneksi dari konfigurasi App Service dan Key Vault setelah migrasi diverifikasi. Migrasi ini biasanya dapat diselesaikan dengan perubahan kode minimal pada aplikasi Azure SDK modern.
Ringkasan Manfaat Keamanan
Identitas Terkelola memberikan empat manfaat keamanan utama dibandingkan autentikasi berbasis kredensial: Tidak ada penyimpanan kredensial — tidak ada yang dapat dicuri atau tidak sengaja dikomit. Rotasi otomatis — Azure merotasi sertifikat yang mendasarinya tanpa waktu henti. Izin tercakup — identitas hanya diberi peran RBAC yang diperlukan, sesuai prinsip hak istimewa minimum. Jejak audit lengkap — semua upaya akses dicatat dalam Entra ID dan log audit layanan yang diakses. Untuk setiap integrasi layanan Azure baru, identitas terkelola sebaiknya menjadi pendekatan autentikasi bawaan.
Pemeriksaan Singkat
Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.
Rangkuman Pelajaran
Dalam pelajaran ini Anda telah mempelajari: identitas terkelola menghilangkan kredensial yang disimpan dengan memberikan identitas Entra ID yang dikelola secara otomatis kepada sumber daya Azure, DefaultAzureCredential dalam Azure SDK menggunakan identitas terkelola secara transparan di Azure dan kredensial pengembang secara lokal, serta penetapan peran RBAC pada layanan target mengontrol hal-hal yang dapat diakses oleh identitas tersebut. Selanjutnya kita akan mempelajari Azure Service Bus untuk perpesanan yang tidak saling bergantung antara komponen aplikasi.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Managed Identity untuk Autentikasi Tanpa Kata Sandi” gratis?
Ya — teks lengkap “Managed Identity untuk Autentikasi Tanpa Kata Sandi” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Cloud & IT Cert Prep, upgrade ke CoddyKit PRO. Kursus Cloud & IT Cert Prep mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Managed Identity untuk Autentikasi Tanpa Kata Sandi”?
Tetapkan managed identity yang ditetapkan sistem ke VM atau App Service, berikan akses RBAC ke Key Vault dan Blob Storage, lalu hapus rahasia dari kode aplikasi Anda. Kamu berlatih Cloud & IT Cert Prep dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai Cloud & IT Cert Prep?
Tidak diperlukan pengalaman sebelumnya. Cloud & IT Cert Prep di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.
Berapa lama pelajaran “Managed Identity untuk Autentikasi Tanpa Kata Sandi” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran Cloud & IT Cert Prep ini?
Ya. Setiap pelajaran Cloud & IT Cert Prep menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Managed Identity untuk Autentikasi Tanpa Kata Sandi
- Azure Service Bus untuk Pesan yang Terpisah
- Azure Container Apps
- Alur Kerja Pengembang Menyeluruh