Identitas aplikasi dan manajemen akses
Artikel ini menjelaskan pertimbangan dan rekomendasi yang dapat digunakan pemilik dan pengembang aplikasi untuk merancang manajemen identitas dan akses untuk aplikasi cloud-native.
Jika tim Anda memigrasikan atau membuat aplikasi cloud-native, Anda harus mempertimbangkan persyaratan autentikasi dan akses untuk aplikasi. Persyaratan ini menentukan bagaimana pengguna mengautentikasi ke aplikasi dan bagaimana sumber daya aplikasi mengautentikasi satu sama lain, misalnya ketika aplikasi web mengakses database SQL.
Di area otomatisasi platform dan desain DevOps, kami sarankan tim aplikasi Anda melakukan transisi beban kerja ke penjual langganan. Sebagai bagian dari proses penjual langganan, tim aplikasi Anda perlu memberikan persyaratan identitas dan akses ke tim platform sehingga mereka dapat membuat langganan yang sesuai. Pemilik aplikasi bertanggung jawab atas manajemen identitas dan akses aplikasi individual. Mereka harus mengelola aplikasi mereka dengan menggunakan layanan terpusat yang disediakan tim platform.
Pertimbangan Desain
Untuk membantu mengurangi risiko akses tidak sah ke aplikasi Anda, masukkan pertimbangan berikut ke dalam desain Anda.
Ada beberapa standar autentikasi dan otorisasi, seperti OAuth 2.0, OpenID Koneksi, token web JSON (JWT), dan SAML (Security Assertion Markup Language). Tentukan standar autentikasi dan otorisasi mana yang akan digunakan untuk aplikasi Anda.
Saat Anda meminta zona pendaratan aplikasi dari tim platform, Anda dapat membantu memastikan bahwa mereka membuat langganan yang sesuai dengan mengajukan pertanyaan berikut:
Bagaimana pengguna akhir akan mengautentikasi dan mengakses aplikasi?
Siapa memerlukan izin kontrol akses berbasis peran (RBAC) untuk sumber daya dan layanan yang digunakan aplikasi?
Apakah peran bawaan yang ada mencakup persyaratan akses RBAC untuk akses sarana kontrol dan sarana data, atau apakah Anda perlu membuat peran kustom baru?
Apakah tim platform menerapkan kebijakan kepatuhan apa pun yang dapat menyebabkan masalah dengan aplikasi?
Komponen aplikasi mana yang perlu berkomunikasi satu sama lain?
Apakah ada persyaratan untuk mengakses sumber daya bersama, seperti Microsoft Entra Domain Services, yang disebarkan di zona pendaratan platform?
Azure Key Vault dan identitas terkelola
Pelanggaran keamanan sumber daya cloud publik sering berasal dari kredensial bocor yang disematkan dalam kode atau teks lainnya. Anda dapat menggunakan identitas terkelola dan Key Vault untuk menerapkan akses terprogram dan membantu mengurangi risiko pencurian kredensial.
Jika aplikasi atau beban kerja Anda memerlukan layanan untuk menyimpan kredensial dengan aman, Anda dapat menggunakan Key Vault untuk mengelola rahasia, kunci, dan sertifikat.
Untuk menghindari kredensial dalam kode, Anda dapat menggunakan identitas terkelola dengan Azure VM untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi ID Microsoft Entra. Untuk informasi selengkapnya, lihat Menggunakan identitas terkelola untuk sumber daya Azure pada VM untuk memperoleh token akses.
Identitas terkelola menyediakan prinsip identitas terkelola secara otomatis yang digunakan aplikasi dan sumber daya saat terhubung ke sumber daya yang mendukung autentikasi ID Microsoft Entra. Aplikasi dapat menggunakan identitas terkelola untuk mendapatkan token ID Microsoft Entra tanpa harus mengelola kredensial apa pun.
Anda dapat menggunakan identitas terkelola yang ditetapkan sistem atau ditetapkan pengguna.
Sangat mudah untuk membingungkan bagaimana perwakilan layanan dan identitas terkelola mengakses sumber daya Azure. Untuk memahami perbedaan antara keduanya, lihat Demystifying service principals—Managed identities.
Jika memungkinkan, gunakan identitas terkelola untuk mendukung autentikasi daripada menggunakan perwakilan layanan dan pendaftaran aplikasi ID Microsoft Entra. Anda harus memiliki peran RBAC Administrator Aplikasi atau Pengembang Aplikasi untuk membuat perwakilan layanan dan pendaftaran aplikasi. Peran istimewa ini biasanya ditetapkan ke tim platform atau tim identitas. Gunakan identitas terkelola untuk menghilangkan kebutuhan tim platform untuk membuat perwakilan layanan dan pendaftaran aplikasi untuk tim aplikasi Anda.
Anda dapat menggunakan identitas terkelola untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra. Namun, tidak semua layanan mendukung identitas terkelola untuk mengakses layanan lain. Untuk beberapa layanan, mungkin perlu menyimpan kredensial. Anda harus menyimpan kredensial dengan aman, menghindari berbagi kredensial dengan layanan lain, dan mengikuti prinsip hak istimewa paling sedikit. Untuk informasi selengkapnya, lihat Layanan Azure yang dapat menggunakan identitas terkelola untuk mengakses layanan lain.
Anda dapat menggunakan identitas terkelola dengan komputer virtual (VM) Azure untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi ID Microsoft Entra. Untuk informasi selengkapnya, lihat Menggunakan identitas terkelola untuk sumber daya Azure pada VM untuk memperoleh token akses.
Ada batasan pemindahan sumber daya dengan identitas terkelola antara langganan dan wilayah. Misalnya, Anda dapat memindahkan sumber daya antara langganan atau wilayah untuk merger, akuisisi, atau repatriasi sumber daya karena alasan kedaulatan data.
Jika sumber daya Azure memiliki identitas yang ditetapkan pengguna atau ditetapkan sistem, Anda tidak dapat mentransfer sumber daya ke langganan atau wilayah Azure lain. Anda harus menghapus identitas terkelola sebelum memindahkan sumber daya. Setelah pemindahan, Anda harus membuat ulang identitas terkelola dan menetapkannya ke sumber daya. Untuk informasi selengkapnya, lihat Memindahkan sumber daya ke grup sumber daya baru atau langganan.
Jika Anda memindahkan langganan dari satu direktori ke direktori lain, identitas terkelola tidak dipertahankan. Anda harus memindahkan sumber daya lalu membuat ulang identitas terkelola secara manual.
Mirip dengan penetapan peran RBAC pengguna, ikuti prinsip hak istimewa paling sedikit saat Anda memberikan akses identitas terkelola ke sumber daya.
Pengguna eksternal
Anda dapat mengevaluasi skenario yang melibatkan penyiapan pengguna, pelanggan, atau mitra eksternal sehingga mereka dapat mengakses sumber daya. Tentukan apakah skenario ini melibatkan konfigurasi Microsoft Entra B2B atau Azure Active Directory B2C (Azure AD B2C ). Untuk informasi selengkapnya, lihat Gambaran Umum ID Eksternal Microsoft Entra.
Rekomendasi desain
Pertimbangkan rekomendasi berikut saat merancang manajemen identitas dan akses aplikasi Anda.
OpenID Connect
Jika tim aplikasi Anda menggunakan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) untuk menyebarkan aplikasi secara terprogram, konfigurasikan OpenID Koneksi autentikasi ke layanan Azure Anda. OpenID Koneksi menggunakan token sementara yang bebas kredensial untuk mengautentikasi ke layanan Azure. Untuk informasi selengkapnya, lihat Federasi identitas beban kerja.
Jika Koneksi OpenID tidak didukung, buat perwakilan layanan dan tetapkan izin yang diperlukan untuk memungkinkan infrastruktur atau kode aplikasi disebarkan. Untuk informasi selengkapnya, lihat modul pelatihan, Mengautentikasi alur penyebaran Azure Anda dengan menggunakan perwakilan layanan.
Kontrol akses berbasis atribut
Untuk lebih membatasi akses dan mencegah akses tidak sah ke data, gunakan kontrol akses berbasis atribut (ABAC) jika didukung, misalnya dengan Azure Blob Storage.
Akses komputer virtual
Jika memungkinkan, gunakan identitas ID Microsoft Entra untuk mengontrol akses ke komputer virtual Azure. Gunakan ID Microsoft Entra alih-alih autentikasi lokal untuk menyediakan akses ke komputer virtual, memanfaatkan Akses Bersyarat Microsoft Entra, pengelogan audit, dan autentikasi multifaktor Microsoft Entra (MFA). Konfigurasi ini mengurangi risiko penyerang mengeksploitasi layanan autentikasi lokal yang tidak aman. Untuk informasi selengkapnya, lihat Masuk ke komputer virtual Linux di Azure dengan menggunakan ID Microsoft Entra dan OpenSSH dan Masuk ke komputer virtual Windows di Azure menggunakan ID Microsoft Entra termasuk tanpa kata sandi.
Platform identitas Microsoft
Saat pengembang membangun aplikasi cloud-native, mereka harus menggunakan platform identitas Microsoft untuk pengembang sebagai penyedia identitas untuk aplikasi mereka. platform identitas Microsoft menyediakan layanan autentikasi OpenID Koneksi sesuai standar yang dapat digunakan pengembang untuk mengautentikasi beberapa jenis identitas termasuk:
Akun kantor atau sekolah, disediakan melalui ID Microsoft Entra
Akun Microsoft pribadi (Skype, Xbox, Outlook.com)
Akun sosial atau lokal, dengan menggunakan ID Microsoft Entra
Daftar periksa praktik terbaik dan rekomendasi platform identitas Microsoft memberikan panduan tentang mengintegrasikan aplikasi secara efektif dengan platform identitas Microsoft.
Identitas Terkelola
Untuk mengaktifkan akses antara sumber daya Azure yang tidak perlu menggunakan kredensial, gunakan identitas terkelola.
Anda tidak boleh berbagi kredensial atau identitas terkelola di antara berbagai lingkungan atau aplikasi. Misalnya, jangan gunakan identitas untuk sumber daya produksi dan juga dalam sumber daya dev/test, bahkan untuk aplikasi yang sama. Buat kredensial terpisah untuk setiap instans aplikasi untuk mengurangi kemungkinan instans pengujian yang disusupi yang memengaruhi data produksi. Kredensial terpisah juga mempermudah pencabutan kredensial saat kredensial tidak lagi diperlukan.
Saat ada persyaratan untuk menggunakan identitas terkelola dalam skala besar, gunakan identitas terkelola yang ditetapkan pengguna untuk setiap jenis sumber daya di setiap wilayah. Pendekatan ini mencegah churn identitas. Misalnya, Agen Azure Monitor memerlukan identitas terkelola pada Azure VM yang dipantau, yang dapat menyebabkan ID Microsoft Entra membuat (dan menghapus) sejumlah besar identitas. Anda dapat membuat identitas terkelola yang ditetapkan pengguna sekali dan membagikannya di beberapa VM. Gunakan Azure Policy untuk menerapkan rekomendasi ini.
Key Vault
Anda dapat menggunakan Key Vault untuk mengelola rahasia, kunci, sertifikat yang digunakan aplikasi.
Untuk mengelola akses ke rahasia (data plane) dan untuk akses administratif (sarana kontrol), gunakan RBAC.
Untuk mengontrol akses aplikasi ke Key Vault, gunakan identitas terkelola.
Anda harus menggunakan brankas kunci terpisah untuk setiap lingkungan aplikasi (pengembangan, praproduksi, produksi) di setiap wilayah. Gunakan RBAC untuk mengelola akses ke rahasia, kunci, dan sertifikat (operasi sarana data) dan akses ke Key Vault (sarana kontrol). Sebarkan brankas kunci yang memiliki rahasia aplikasi ke zona pendaratan aplikasi.
Proksi aplikasi Microsoft Entra
Untuk mengakses aplikasi yang menggunakan autentikasi lokal dari jarak jauh melalui ID Microsoft Entra, gunakan proksi aplikasi Microsoft Entra. Proksi aplikasi Microsoft Entra menyediakan akses jarak jauh yang aman ke aplikasi web lokal, termasuk aplikasi yang menggunakan protokol autentikasi yang lebih lama. Setelah akses menyeluruh ke ID Microsoft Entra, pengguna dapat mengakses aplikasi cloud dan lokal melalui URL eksternal atau portal aplikasi internal.
Anda dapat menyebarkan proksi aplikasi Microsoft Entra sebagai satu instans ke penyewa ID Microsoft Entra. Konfigurasi memerlukan peran ID Microsoft Entra istimewa Administrator Aplikasi atau Administrator Global. Jika organisasi Anda menggunakan demokratisasi langganan sebagai model penetapan peran, pemilik aplikasi mungkin tidak memiliki izin yang diperlukan untuk mengonfigurasi proksi aplikasi Microsoft Entra. Dalam hal ini, tim platform harus mengonfigurasi proksi aplikasi Microsoft Entra untuk pemilik aplikasi.
Jika Anda menggunakan alur penyebaran CI/CD dengan izin yang memadai, pemilik aplikasi dapat mengonfigurasi proksi aplikasi Microsoft Entra dengan menggunakan Microsoft Graph API.
Jika aplikasi menggunakan protokol warisan, seperti Kerberos, pastikan bahwa zona pendaratan aplikasi memiliki konektivitas jaringan ke pengendali domain dalam langganan platform identitas Microsoft.