Rekomendasi untuk manajemen identitas dan akses

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

SE:05	Terapkan manajemen identitas dan akses (IAM) yang ketat, bersyarkat, 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. Batasi dan audit 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 serupa lainnya 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 telah 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 asumsikan-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 yang 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 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 dalam atau luar masuk. 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 sarana data 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 mengizinkan identitas untuk menyelesaikan tugas, dan tidak 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 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 serangan yang berhasil 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 risikonya.

Ada skenario di mana pengguna membutuhkan lebih banyak akses karena struktur organisasi dan organisasi tim. Mungkin ada tumpang tindih antara berbagai peran, atau satu pengguna 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 serangkaian izin terbatas, melebarkan 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. Penyesuaian menyebabkan 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 akses operasional atau 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 mendapatkan kontrol lebih besar 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 tempat akses berasal untuk mengatur 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.

Lindungi 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 kritis.

• 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 daya yang konsisten dan otoritatif 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 keberhasilan kompromi akun cloud. 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, alat, 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 keluar dari 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-kunci tersebut juga dapat memberatkan 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 dijaga dengan otomatisasi dan tinjauan 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 reguler 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 asumsikan 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 data plane. 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 memperhitungkan semua titik data yang tersedia dan menggunakan akses bersyar. ID Microsoft Entra menyediakan manajemen identitas dan akses di Azure. Ini mencakup bidang manajemen Azure dan terintegrasi dengan sarana 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 secara asli terintegrasi ke dalam model identitas dan izin Microsoft Entra yang sama untuk segmen pengguna:

• ID Microsoft Entra. Karyawan dan sumber daya perusahaan.

• ID Eksternal Microsoft Entra. Mitra.

• Azure AD B2C. Pelanggan.

• Daftar kompatibilitas federasi Microsoft Entra. 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 di ID Microsoft Entra.

Tradeoff: ID Microsoft Entra adalah satu titik kegagalan sama seperti layanan dasar lainnya. Tidak ada solusi sampai pemadaman diperbaiki oleh Microsoft. Namun, kumpulan fitur Microsoft Entra yang kaya melebihi risiko penggunaan 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.

Azure RBAC

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

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 berskala menjelaskan kebijakan Anda untuk keputusan akses. Untuk menggunakan akses bersyarat, Anda perlu memahami batasan yang diperlukan untuk kasus penggunaan. Konfigurasikan Microsoft Entra Conditional Access dengan menyiapkan kebijakan akses untuk yang didasarkan pada kebutuhan operasional Anda.

Untuk informasi selengkapnya, lihat Akses bersyarah: 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 saat ini. Anda juga dapat menggunakan grup untuk tujuan lain, seperti milis.

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

Deteksi ancaman

Microsoft Entra ID Protection 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 Yang sudah ada. Sinkronisasi ini diblokir dalam konfigurasi Sinkronisasi Microsoft Entra Connect default, jadi Anda hanya perlu mengonfirmasi bahwa Anda belum menyesuaikan konfigurasi ini.

Untuk informasi tentang pemfilteran di ID Microsoft Entra, lihat Sinkronisasi Microsoft Entra Connect: 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 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 sarana 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 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 Azure Diagnostics, atau melalui kode untuk komponen kode.

Tautan terkait

• Tutorial: Mengotomatiskan rotasi rahasia untuk sumber daya yang memiliki dua set kredensial autentikasi
• Tutorial: Memperbarui frekuensi rotasi otomatis sertifikat di Key Vault
• Apa yang baru dalam ID Microsoft Entra?
• Peran bawaan Microsoft Entra
• Gambaran umum kontrol akses berbasis peran di Microsoft Entra ID
• Apa yang dimaksud dengan identitas beban kerja?
• Apa identitas terkelola untuk sumber daya Azure?
• Akses berskala: Pengguna, grup, dan identitas beban kerja
• Sinkronisasi Microsoft Entra Connect: Konfigurasikan pemfilteran

Daftar periksa keamanan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keamanan