Rekomendasi untuk manajemen identitas dan akses

Artikel
11/15/2023

Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Security ini:

SE:05	Terapkan manajemen identitas dan akses (IAM) yang ketat, bersyukur, dan dapat diaudit di semua pengguna beban kerja, anggota tim, dan komponen sistem. Batasi akses secara eksklusif seperlunya. Gunakan standar industri modern untuk semua implementasi autentikasi dan otorisasi. Membatasi dan mengaudit akses secara ketat yang tidak didasarkan pada identitas.

Panduan ini menjelaskan rekomendasi untuk mengautentikasi dan mengotorisasi identitas yang mencoba mengakses sumber daya beban kerja Anda.

Dari perspektif kontrol teknis, identitas selalu menjadi perimeter utama. Cakupan ini tidak hanya menyertakan tepi beban kerja Anda. Ini juga termasuk komponen individual yang ada di dalam beban kerja Anda. Identitas umum meliputi:

Manusia. Pengguna aplikasi, admin, operator, auditor, dan pelaku jahat.
Sistem. Identitas beban kerja, identitas terkelola, kunci API, perwakilan layanan, dan sumber daya Azure.
Anonim. Entitas yang belum memberikan bukti tentang siapa mereka.

Definisi

Istilah	Definisi
Autentikasi (AuthN)	Proses yang memverifikasi bahwa identitas adalah siapa atau apa yang dikatakannya.
Otorisasi (AuthZ)	Proses yang memverifikasi apakah identitas memiliki izin untuk melakukan tindakan yang diminta.
Akses Bersyarat	Sekumpulan aturan yang memungkinkan tindakan berdasarkan kriteria yang ditentukan.
IdP	IdP, seperti ID Microsoft Entra.
Persona	Fungsi pekerjaan atau judul yang memiliki serangkaian tanggung jawab dan tindakan.
Kunci yang dibagikan sebelumnya	Jenis rahasia yang dibagikan antara penyedia dan konsumen dan digunakan melalui mekanisme yang aman dan disepakati.
Identitas sumber daya	Identitas yang ditentukan untuk sumber daya cloud yang dikelola oleh platform.
Peran	Sekumpulan izin yang menentukan apa yang dapat dilakukan pengguna atau grup.
Cakupan	Berbagai tingkat hierarki organisasi di mana peran diizinkan untuk beroperasi. Juga sekelompok fitur dalam sistem.
Prinsip keamanan	Identitas yang menyediakan izin. Ini bisa menjadi pengguna, grup, atau perwakilan layanan. Setiap anggota grup mendapatkan tingkat akses yang sama.
Identitas pengguna	Identitas untuk seseorang, seperti karyawan atau pengguna eksternal.
Identitas beban kerja	Identitas sistem untuk aplikasi, layanan, skrip, kontainer, atau komponen lain dari beban kerja yang digunakan untuk mengautentikasi dirinya ke layanan dan sumber daya lain.

Catatan

Identitas dapat dikelompokkan dengan identitas lain yang serupa di bawah induk yang disebut prinsip keamanan. Grup keamanan adalah contoh prinsip keamanan. Hubungan hierarkis ini menyederhanakan pemeliharaan dan meningkatkan konsistensi. Karena atribut identitas tidak ditangani pada tingkat individual, kemungkinan kesalahan juga berkurang. Dalam artikel ini, istilah identitas sudah termasuk prinsip keamanan.

Peran Penyedia Identitas

Penyedia identitas (IdP) adalah layanan yang dihosting cloud yang menyimpan dan mengelola pengguna sebagai identitas digital.

Manfaatkan kemampuan yang disediakan oleh IdP tepercaya untuk manajemen identitas dan akses Anda. Jangan terapkan sistem kustom untuk menggantikan IdP. Sistem IdP sering ditingkatkan berdasarkan vektor serangan terbaru dengan menangkap miliaran sinyal di beberapa penyewa setiap hari. ID Microsoft Entra adalah IdP untuk platform cloud Azure.

Autentikasi

Autentikasi adalah proses yang memverifikasi identitas. Identitas yang meminta diperlukan untuk memberikan beberapa bentuk identifikasi yang dapat diverifikasi. Contohnya:

Nama pengguna dan kata sandi.
Rahasia yang dibagikan sebelumnya, seperti kunci API yang memberikan akses.
Token tanda tangan akses bersama (SAS).
Sertifikat yang digunakan dalam autentikasi bersama TLS.

Sebanyak mungkin, proses verifikasi harus ditangani oleh IdP Anda.

Authorization

Otorisasi adalah proses yang memungkinkan atau menolak tindakan yang diminta oleh identitas terverifikasi. Tindakan tersebut mungkin bersifat operasional atau terkait dengan manajemen sumber daya.

Otorisasi mengharuskan Anda menetapkan izin ke identitas, yang perlu Anda lakukan dengan menggunakan fungsionalitas yang disediakan oleh IdP Anda.

Strategi desain utama

Untuk mendapatkan tampilan holistik kebutuhan identitas untuk beban kerja, Anda perlu membuat katalog alur, aset beban kerja, dan persona, dan tindakan yang akan dilakukan aset dan persona. Strategi Anda harus mencakup semua kasus penggunaan yang menangani alur yang mencapai beban kerja atau komponennya (akses luar masuk) dan alur yang menjangkau dari beban kerja ke sumber lain (akses luar dalam).

Setiap kasus penggunaan mungkin akan memiliki serangkaian kontrol sendiri yang perlu Anda desain dengan pola pikir asumsi-pelanggaran. Berdasarkan persyaratan identitas kasus penggunaan atau persona, identifikasi pilihan kondisional. Hindari menggunakan satu solusi untuk semua kasus penggunaan. Sebaliknya, kontrol seharusnya tidak begitu terperinci sehingga Anda memperkenalkan overhead manajemen yang tidak perlu.

Anda perlu mencatat jejak akses identitas. Melakukannya membantu memvalidasi kontrol, dan Anda dapat menggunakan log untuk audit kepatuhan.

Menentukan semua identitas untuk autentikasi

Akses luar ke dalam. Desain identitas Anda harus mengautentikasi semua pengguna yang mengakses beban kerja untuk berbagai tujuan. Misalnya, pengguna akhir yang mengakses aplikasi dengan memanggil API.

Pada tingkat terperinci, komponen beban kerja mungkin juga memerlukan akses dari luar. Misalnya, operator yang membutuhkan akses melalui portal atau akses ke komputasi untuk menjalankan perintah.

Keduanya adalah contoh identitas pengguna yang memiliki persona berbeda.
Akses dalam ke luar. Aplikasi Anda harus mengakses sumber daya lain. Misalnya, membaca dari atau menulis ke platform data, mengambil rahasia dari penyimpanan rahasia, dan mencatat telemetri ke layanan pemantauan. Bahkan mungkin perlu mengakses layanan pihak ketiga. Kebutuhan akses ini memerlukan identitas beban kerja, yang memungkinkan aplikasi untuk mengautentikasi dirinya sendiri terhadap sumber daya lain.

Konsep ini berlaku pada tingkat komponen. Dalam contoh berikut, kontainer mungkin memerlukan akses ke alur penyebaran untuk mendapatkan konfigurasinya. Kebutuhan akses ini memerlukan identitas sumber daya.

Semua identitas ini harus diautentikasi oleh IdP Anda.

Berikut adalah contoh bagaimana identitas dapat diimplementasikan dalam arsitektur:

Menentukan tindakan untuk otorisasi

Selanjutnya, Anda perlu mengetahui apa yang coba dilakukan setiap identitas terautentikasi sehingga tindakan tersebut dapat diotorisasi. Tindakan dapat dibagi dengan jenis akses yang mereka butuhkan:

Akses sarana data. Tindakan yang terjadi di bidang data menyebabkan transfer data untuk akses keluar atau luar. Misalnya, aplikasi membaca data dari database dan menulis data ke database, mengambil rahasia, atau menulis log ke sink pemantauan. Pada tingkat komponen, komputasi yang menarik atau mendorong gambar ke atau dari registri dianggap sebagai operasi sarana data.
Akses sarana kontrol. Tindakan yang terjadi di sarana kontrol menyebabkan sumber daya Azure dibuat, dimodifikasi, atau dihapus. Misalnya, perubahan pada properti sumber daya.

Aplikasi biasanya menargetkan operasi data plane, sementara operasi sering mengakses sarana kontrol dan data. Untuk mengidentifikasi kebutuhan otorisasi, perhatikan tindakan operasional yang dapat dilakukan pada sumber daya. Untuk informasi tentang tindakan yang diizinkan untuk setiap sumber daya, lihat Operasi penyedia sumber daya Azure.

Memberikan otorisasi berbasis peran

Berdasarkan tanggung jawab setiap identitas, otorisasi tindakan yang harus diizinkan. Identitas tidak boleh diizinkan untuk melakukan lebih dari yang perlu dilakukan. Sebelum menetapkan aturan otorisasi, Anda harus memiliki pemahaman yang jelas tentang siapa atau apa yang membuat permintaan, peran apa yang diizinkan untuk dilakukan, dan sejauh mana peran tersebut dapat melakukannya. Faktor-faktor tersebut menyebabkan pilihan yang menggabungkan identitas, peran, dan cakupan.

Pertimbangkan identitas beban kerja sebagai contoh. Aplikasi harus memiliki akses data plane ke database, sehingga tindakan baca dan tulis ke sumber daya data harus diizinkan. Namun, apakah aplikasi memerlukan akses sarana kontrol ke penyimpanan rahasia? Jika identitas beban kerja disusupi oleh pelaku yang buruk, apa dampaknya terhadap sistem, dalam hal kerahasiaan, integritas, dan ketersediaan?

Penetapan peran

Peran adalah sekumpulan izin yang ditetapkan ke identitas. Tetapkan peran yang hanya memungkinkan identitas menyelesaikan tugas, dan tidak ada lagi. Ketika izin pengguna dibatasi untuk persyaratan pekerjaan mereka, lebih mudah untuk mengidentifikasi perilaku yang mencurigakan atau tidak sah dalam sistem.

Ajukan pertanyaan seperti ini:

Apakah akses baca-saja sudah cukup?
Apakah identitas memerlukan izin untuk menghapus sumber daya?

Membatasi tingkat akses yang dimiliki pengguna, aplikasi, atau layanan ke sumber daya Azure mengurangi potensi permukaan serangan. Jika Anda hanya memberikan izin minimum yang diperlukan untuk melakukan tugas tertentu, risiko keberhasilan serangan atau akses yang tidak sah akan berkurang secara signifikan. Misalnya, tim keamanan hanya memerlukan akses baca-saja ke atribut keamanan untuk semua lingkungan teknis. Tingkat itu cukup untuk menilai faktor risiko, mengidentifikasi potensi mitigasi, dan melaporkan risiko.

Ada skenario di mana pengguna membutuhkan lebih banyak akses karena struktur organisasi dan organisasi tim. Mungkin ada tumpang tindih antara berbagai peran, atau pengguna tunggal mungkin melakukan beberapa peran standar. Dalam hal ini, gunakan beberapa penetapan peran yang didasarkan pada fungsi bisnis alih-alih membuat peran kustom untuk masing-masing pengguna ini. Melakukannya membuat peran lebih mudah dikelola.

Hindari izin yang secara khusus mereferensikan sumber daya atau pengguna individual. Izin granular dan kustom menciptakan kompleksitas dan kebingungan karena tidak meneruskan niat ke sumber daya baru yang serupa. Ini dapat menciptakan konfigurasi warisan kompleks yang sulit dipertahankan dan berdampak negatif pada keamanan dan keandalan.

Tradeoff: Pendekatan kontrol akses terperinci memungkinkan audit dan pemantauan aktivitas pengguna yang lebih baik.

Peran juga memiliki cakupan terkait. Peran dapat beroperasi di grup manajemen, langganan, grup sumber daya, atau cakupan sumber daya yang diizinkan, atau di cakupan kustom lain. Bahkan jika identitas memiliki sekumpulan izin terbatas, memperluas cakupan untuk menyertakan sumber daya yang berada di luar fungsi pekerjaan identitas berisiko. Misalnya, akses baca ke semua kode sumber dan data bisa berbahaya dan harus dikontrol.

Anda menetapkan peran ke identitas dengan menggunakan kontrol akses berbasis peran (RBAC). Selalu gunakan RBAC yang disediakan IdP untuk memanfaatkan fitur yang memungkinkan Anda menerapkan kontrol akses secara konsisten dan mencabutnya secara ketat.

Gunakan peran bawaan. Mereka dirancang untuk mencakup sebagian besar kasus penggunaan. Peran kustom sangat kuat dan terkadang berguna, tetapi Anda harus mencadangkannya untuk skenario di mana peran bawaan tidak akan berfungsi. Kustomisasi mengarah pada kompleksitas yang meningkatkan kebingungan dan membuat otomatisasi lebih kompleks, menantang, dan rapuh. Semua faktor ini berdampak negatif terhadap keamanan.

Berikan peran yang dimulai dengan hak istimewa paling sedikit dan tambahkan lebih banyak berdasarkan kebutuhan operasional atau akses data Anda. Tim teknis Anda harus memiliki panduan yang jelas untuk menerapkan izin.

Jika Anda ingin kontrol terperinci pada RBAC, tambahkan kondisi pada penetapan peran berdasarkan konteks, seperti tindakan dan atribut.

Membuat pilihan akses bersyarah

Jangan berikan semua identitas tingkat akses yang sama. Mendasarkan keputusan Anda pada dua faktor utama:

Waktunya. Berapa lama identitas dapat mengakses lingkungan Anda.
Hak istimewa. Tingkat izin.

Faktor-faktor itu tidak saling eksklusif. Identitas yang disusupi yang memiliki lebih banyak hak istimewa dan durasi akses tak terbatas dapat memperoleh lebih banyak kontrol atas sistem dan data atau menggunakan akses tersebut untuk terus mengubah lingkungan. Batasi faktor akses tersebut baik sebagai tindakan pencegahan maupun untuk mengontrol radius ledakan.

Pendekatan Just in Time (JIT) memberikan hak istimewa yang diperlukan hanya ketika diperlukan.
Just Enough Access (JEA) hanya menyediakan hak istimewa yang diperlukan.

Meskipun waktu dan hak istimewa adalah faktor utama, ada kondisi lain yang berlaku. Misalnya, Anda juga dapat menggunakan perangkat, jaringan, dan lokasi asal akses untuk menetapkan kebijakan.

Gunakan kontrol kuat yang memfilter, mendeteksi, dan memblokir akses yang tidak sah, termasuk parameter seperti identitas dan lokasi pengguna, kesehatan perangkat, konteks beban kerja, klasifikasi data, dan anomali.

Misalnya, beban kerja Anda mungkin perlu diakses oleh identitas pihak ketiga seperti vendor, mitra, dan pelanggan. Mereka membutuhkan tingkat akses yang sesuai daripada izin default yang Anda berikan kepada karyawan penuh waktu. Diferensiasi akun eksternal yang jelas memudahkan untuk mencegah dan mendeteksi serangan yang berasal dari vektor ini.

Pilihan IdP Anda harus dapat memberikan diferensiasi tersebut, menyediakan fitur bawaan yang memberikan izin berdasarkan hak istimewa paling sedikit, dan memberikan inteligensi ancaman bawaan. Ini termasuk pemantauan permintaan akses dan rincian masuk. IdP Azure adalah ID Microsoft Entra. Untuk informasi selengkapnya, lihat bagian fasilitasi Azure di artikel ini.

Akun dampak kritis

Identitas administratif memperkenalkan beberapa risiko keamanan berdampak tertinggi karena tugas yang mereka lakukan memerlukan akses istimewa ke serangkaian sistem dan aplikasi ini yang luas. Penyusupan atau penyalahgunaan dapat memiliki efek yang merugikan pada bisnis Anda dan sistem informasinya. Keamanan administrasi adalah salah satu area keamanan yang paling penting.

Melindungi akses dengan hak istimewa dari musuh yang ditentukan mengharuskan Anda mengambil pendekatan yang lengkap dan bijaksana untuk mengisolasi sistem ini dari risiko. Berikut adalah beberapa strateginya:

Minimalkan jumlah akun dampak penting.
Gunakan peran terpisah alih-alih meningkatkan hak istimewa untuk identitas yang ada.
Hindari akses permanen atau berdiri dengan menggunakan fitur JIT IdP Anda. Untuk situasi break glass, ikuti proses akses darurat.
Gunakan protokol akses modern seperti autentikasi tanpa kata sandi atau autentikasi multifaktor. Eksternalisasi mekanisme tersebut ke IdP Anda.
Menerapkan atribut keamanan utama dengan menggunakan kebijakan akses bersyarah.
Menonaktifkan akun administratif yang tidak digunakan.

Gunakan satu identitas di seluruh lingkungan dan kaitkan satu identitas dengan pengguna atau prinsipal. Konsistensi identitas di seluruh lingkungan cloud dan lokal mengurangi kesalahan manusia dan risiko keamanan yang dihasilkan. Tim di kedua lingkungan yang mengelola sumber daya memerlukan sumber otoritatif yang konsisten untuk memenuhi jaminan keamanan. Bekerja dengan tim identitas pusat Anda untuk memastikan bahwa identitas di lingkungan hibrid disinkronkan.

Risiko: Ada risiko yang terkait dengan sinkronisasi identitas hak istimewa tinggi. Penyerang bisa mendapatkan kontrol penuh atas aset lokal, dan ini dapat menyebabkan penyusupan akun cloud yang sukses. Evaluasi strategi sinkronisasi Anda dengan memfilter akun yang dapat ditambahkan ke permukaan serangan.

Menetapkan proses untuk mengelola siklus hidup identitas

Akses ke identitas tidak boleh berlangsung lebih lama dari sumber daya yang diakses identitas. Pastikan Anda memiliki proses untuk menonaktifkan atau menghapus identitas ketika ada perubahan dalam struktur tim atau komponen perangkat lunak.

Panduan ini berlaku untuk kontrol sumber, data, sarana kontrol, pengguna beban kerja, infrastruktur, perkakas, pemantauan data, log, metrik, dan entitas lainnya.

Buat proses tata kelola identitas untuk mengelola siklus hidup identitas digital, pengguna dengan hak istimewa tinggi, pengguna eksternal/tamu, dan pengguna beban kerja. Terapkan tinjauan akses untuk memastikan bahwa ketika identitas meninggalkan organisasi atau tim, izin beban kerja mereka dihapus.

Melindungi rahasia berbasis nonidentitas

Rahasia aplikasi seperti kunci yang dibagikan sebelumnya harus dianggap sebagai titik rentan dalam sistem. Dalam komunikasi dua arah, jika penyedia atau konsumen disusupi, risiko keamanan yang signifikan dapat diperkenalkan. Kunci tersebut juga dapat membebani karena memperkenalkan proses operasional.

Ketika Anda dapat, hindari menggunakan rahasia dan pertimbangkan untuk menggunakan autentikasi berbasis identitas untuk akses pengguna ke aplikasi itu sendiri, bukan hanya ke sumber dayanya.

Daftar berikut ini menyediakan ringkasan panduan. Untuk informasi selengkapnya, lihat Rekomendasi untuk rahasia aplikasi.

Perlakukan rahasia ini sebagai entitas yang dapat ditarik secara dinamis dari penyimpanan rahasia. Mereka tidak boleh dikodekan secara permanen dalam kode aplikasi Anda, skrip IaC, alur penyebaran, atau di artefak lainnya.
Pastikan Anda memiliki kemampuan untuk mencabut rahasia.
Terapkan praktik operasional yang menangani tugas seperti rotasi kunci dan kedaluwarsa.

Untuk informasi tentang kebijakan rotasi, lihat Mengotomatiskan rotasi rahasia untuk sumber daya yang memiliki dua set kredensial autentikasi dan Tutorial: Memperbarui frekuensi rotasi otomatis sertifikat di Key Vault.

Menjaga lingkungan pengembangan tetap aman

Semua kode dan skrip, alat alur, dan sistem kontrol sumber harus dianggap sebagai aset beban kerja. Akses ke penulisan harus terjaga dengan otomatisasi dan peninjauan serekan. Akses baca ke kode sumber harus terbatas pada peran berdasarkan yang perlu diketahui. Repositori kode harus memiliki penerapan versi, dan tinjauan kode keamanan oleh rekan-rekan harus merupakan praktik rutin yang terintegrasi dengan siklus hidup pengembangan. Anda harus memiliki proses yang memindai sumber daya secara teratur dan mengidentifikasi kerentanan terbaru.

Gunakan identitas beban kerja untuk memberikan akses ke sumber daya dari lingkungan penyebaran, seperti GitHub.

Mempertahankan jejak audit

Salah satu aspek manajemen identitas adalah memastikan bahwa sistem dapat diaudit. Audit memvalidasi apakah strategi asumsi-pelanggaran efektif. Mempertahankan jejak audit membantu Anda:

Verifikasi bahwa identitas diautentikasi dengan autentikasi yang kuat. Tindakan apa pun harus dapat dilacak untuk mencegah serangan penolakan.
Deteksi protokol autentikasi yang lemah atau hilang dan dapatkan visibilitas ke dalam dan wawasan tentang rincian masuk pengguna dan aplikasi.
Evaluasi akses dari identitas ke beban kerja berdasarkan persyaratan keamanan dan kepatuhan dan pertimbangkan risiko akun pengguna, status perangkat, serta kriteria dan kebijakan lain yang Anda tetapkan.
Lacak kemajuan atau penyimpangan dari persyaratan kepatuhan.

Sebagian besar sumber daya memiliki akses sarana data. Anda perlu mengetahui identitas yang mengakses sumber daya dan tindakan yang mereka lakukan. Anda dapat menggunakan informasi tersebut untuk diagnostik keamanan.

Untuk informasi selengkapnya, lihat Rekomendasi tentang pemantauan keamanan dan analisis ancaman.

Fasilitasi Azure

Kami menyarankan agar Anda selalu menggunakan protokol autentikasi modern yang mempertimbangkan semua titik data yang tersedia dan menggunakan akses bersyarah. Microsoft Entra ID menyediakan manajemen identitas dan akses di Azure. Ini mencakup bidang manajemen Azure dan terintegrasi dengan bidang data sebagian besar layanan Azure. ID Microsoft Entra adalah penyewa yang terkait dengan langganan beban kerja. Ini melacak dan mengelola identitas dan izin yang diizinkan dan menyederhanakan manajemen keseluruhan untuk meminimalkan risiko pengawasan atau kesalahan manusia.

Kemampuan ini terintegrasi secara asli ke dalam model identitas dan izin Microsoft Entra yang sama untuk segmen pengguna:

ID Microsoft Entra. Karyawan dan sumber daya perusahaan.
Microsoft Entra External ID. Mitra.
Azure AD B2C. Pelanggan.
Microsoft Entra daftar kompatibilitas federasi. Solusi federasi pihak ketiga.

Anda dapat menggunakan ID Microsoft Entra untuk autentikasi dan otorisasi aplikasi kustom melalui Microsoft Authentication Library (MSAL) atau fitur platform, seperti autentikasi untuk aplikasi web. Ini mencakup bidang manajemen Azure, bidang data dari sebagian besar layanan Azure, dan kemampuan integrasi untuk aplikasi Anda.

Anda dapat tetap terkini dengan mengunjungi Apa yang baru dalam ID Microsoft Entra.

Tradeoff: Microsof Microsoft Entra ID adalah satu titik kegagalan sama seperti layanan dasar lainnya. Tidak ada solusi sementara sampai pemadaman diperbaiki oleh Microsoft. Namun, kumpulan fitur kaya Microsoft Entra melebihi risiko menggunakan solusi kustom.

Azure mendukung protokol terbuka seperti OAuth2 dan OpenID Connect. Kami menyarankan agar Anda menggunakan mekanisme autentikasi dan otorisasi standar ini alih-alih merancang alur Anda sendiri.

RBAC Azure

Azure RBAC mewakili prinsip keamanan dalam ID Microsoft Entra. Semua penetapan peran dilakukan melalui Azure RBAC. Manfaatkan peran bawaan yang memberikan sebagian besar izin yang Anda butuhkan. Untuk informasi selengkapnya, lihat Microsoft Entra peran bawaan.

Berikut adalah beberapa kasus penggunaan:

Dengan menetapkan pengguna ke peran, Anda dapat mengontrol akses ke sumber daya Azure. Untuk informasi selengkapnya, lihat Gambaran umum kontrol akses berbasis peran di ID Microsoft Entra.
Anda dapat menggunakan Privileged Identity Management untuk menyediakan aktivasi peran berbasis waktu dan berbasis persetujuan untuk peran yang terkait dengan identitas berdampak tinggi. Untuk informasi selengkapnya, lihat Apa itu Privileged Identity Management?.

Untuk informasi selengkapnya tentang RBAC, lihat Praktik terbaik untuk Azure RBAC.

Untuk informasi tentang kontrol berbasis atribut, lihat Apa itu Azure ABAC?.

Identitas beban kerja

ID Microsoft Entra dapat menangani identitas aplikasi Anda. Perwakilan layanan yang terkait dengan aplikasi dapat menentukan cakupan aksesnya.

Untuk informasi selengkapnya, lihat Apa itu identitas beban kerja?.

Perwakilan layanan juga diabstraksi saat Anda menggunakan identitas terkelola. Keuntungannya adalah Azure mengelola semua kredensial untuk aplikasi.

Tidak semua layanan mendukung identitas terkelola. Jika Anda tidak dapat menggunakan identitas terkelola, Anda dapat menggunakan perwakilan layanan. Namun, menggunakan perwakilan layanan meningkatkan overhead manajemen Anda. Untuk informasi selengkapnya, lihat Apa yang dimaksud dengan identitas terkelola untuk sumber daya Azure?.

Identitas sumber daya

Konsep identitas terkelola dapat diperluas ke sumber daya Azure. Sumber daya Azure dapat menggunakan identitas terkelola untuk mengautentikasi diri mereka ke layanan lain yang mendukung autentikasi Microsoft Entra. Untuk informasi selengkapnya, lihat Layanan Azure yang dapat menggunakan identitas terkelola untuk mengakses layanan lain.

Kebijakan akses bersyarat

Akses bersyarah menjelaskan kebijakan Anda untuk keputusan akses. Untuk menggunakan akses bersyarat, Anda perlu memahami pembatasan yang diperlukan untuk kasus penggunaan. Konfigurasikan Microsoft Entra Akses Bersyar dengan menyiapkan kebijakan akses untuk itu didasarkan pada kebutuhan operasional Anda.

Untuk informasi selengkapnya, lihat Akses bersyar: Pengguna, grup, dan identitas beban kerja.

Manajemen akses grup

Alih-alih memberikan izin kepada pengguna tertentu, tetapkan akses ke grup di ID Microsoft Entra. Jika grup tidak ada, bekerja samalah dengan tim identitas Anda untuk membuatnya. Anda kemudian dapat menambahkan dan menghapus anggota grup di luar Azure dan memastikan bahwa izin adalah saat ini. Anda juga bisa menggunakan grup untuk tujuan lain, seperti milis.

Untuk informasi selengkapnya, lihat Kontrol akses aman menggunakan grup di ID Microsoft Entra.

Deteksi ancaman

Perlindungan Microsoft Entra ID dapat membantu Anda mendeteksi, menyelidiki, dan memulihkan risiko berbasis identitas. Untuk informasi selengkapnya, lihat Apa itu Perlindungan Identitas?.

Deteksi ancaman dapat berupa bereaksi terhadap pemberitahuan aktivitas mencurigakan atau secara proaktif mencari peristiwa anomali dalam log aktivitas. Analitik Perilaku Pengguna dan Entitas (UEBA) di Microsoft Azure Sentinel memudahkan untuk mendeteksi aktivitas yang mencurigakan. Untuk informasi selengkapnya, lihat Mengidentifikasi ancaman tingkat lanjut dengan UEBA.

Sistem hibrid

Di Azure, jangan sinkronkan akun ke ID Microsoft Entra yang memiliki hak istimewa tinggi di Direktori Aktif Anda yang sudah ada. Sinkronisasi ini diblokir dalam konfigurasi default Microsoft Entra Connect Sync, jadi Anda hanya perlu mengonfirmasi bahwa Anda belum menyesuaikan konfigurasi ini.

Untuk informasi tentang pemfilteran di ID Microsoft Entra, lihat Microsoft Entra Connect Sync: Mengonfigurasi pemfilteran.

Pengelogan identitas

Aktifkan pengaturan diagnostik pada sumber daya Azure untuk memancarkan informasi yang dapat Anda gunakan sebagai jejak audit. Informasi diagnostik menunjukkan identitas mana yang mencoba mengakses sumber daya mana dan hasil upaya tersebut. Log yang dikumpulkan dikirim ke Azure Monitor.

Tradeoff: Pengelogan dikenakan biaya karena penyimpanan data yang digunakan untuk menyimpan log. Ini juga dapat menyebabkan dampak performa, terutama pada kode dan pada solusi pengelogan yang Anda tambahkan ke aplikasi.

Contoh

Contoh berikut menunjukkan implementasi identitas. Berbagai jenis identitas digunakan bersama-sama untuk menyediakan tingkat akses yang diperlukan.

Komponen identitas

Identitas yang dikelola sistem. Microsoft Entra ID menyediakan akses ke bidang data layanan yang tidak menghadapi pengguna, seperti Azure Key Vault dan penyimpanan data. Identitas ini juga mengontrol akses, melalui RBAC, ke bidang manajemen Azure untuk komponen beban kerja, agen penyebaran, dan anggota tim.
Identitas beban kerja. Layanan aplikasi di kluster Azure Kubernetes Service (AKS) menggunakan identitas beban kerja untuk mengautentikasi diri mereka sendiri ke komponen lain dalam solusi.
Identitas Terkelola. Komponen sistem dalam peran klien menggunakan identitas yang dikelola sistem, termasuk agen build.
Identitas manusia. Autentikasi pengguna dan operator didelegasikan ke ID Microsoft Entra atau ID Microsoft Entra (asli, B2B, atau B2C).

Keamanan rahasia yang dibagikan sebelumnya sangat penting untuk aplikasi apa pun. Azure Key Vault menyediakan mekanisme penyimpanan yang aman untuk rahasia ini, termasuk Redis dan rahasia pihak ketiga.

Mekanisme rotasi digunakan untuk membantu memastikan bahwa rahasia tidak disusupi. Token untuk implementasi platform identitas Microsoft OAuth 2 dan OpenID Connect digunakan untuk mengautentikasi pengguna.

Azure Policy digunakan untuk memastikan bahwa komponen identitas seperti Key Vault menggunakan RBAC alih-alih kebijakan akses. JIT dan JEA menyediakan izin berdiri tradisional untuk operator manusia.

Log akses diaktifkan di semua komponen melalui Diagnostik Azure, atau melalui kode untuk komponen kode.

Daftar periksa keamanan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keamanan