Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Di Microsoft, kami berkomitmen untuk memberi pelanggan kami tingkat keamanan tertinggi. Salah satu langkah keamanan paling efektif yang tersedia untuk mereka adalah autentikasi multifaktor (MFA). Penelitian oleh Microsoft menunjukkan bahwa MFA dapat memblokir lebih dari 99,2% serangan kompromi akun.
Itu sebabnya, mulai tahun 2024, kami akan memberlakukan MFA wajib untuk semua upaya masuk Azure. Untuk latar belakang lebih lanjut tentang persyaratan ini, lihat posting blog kami Azure autentikasi multifaktor wajib: Fase 2 mulai Oktober 2025 dan Mengumumkan autentikasi multifaktor wajib untuk masuk Azure. Topik ini mencakup aplikasi dan akun mana yang terpengaruh, bagaimana penegakan diluncurkan ke penyewa, dan pertanyaan dan jawaban umum lainnya.
Tidak ada perubahan bagi pengguna jika organisasi Anda sudah memberlakukan MFA untuk mereka, atau jika mereka masuk dengan metode yang lebih kuat seperti tanpa kata sandi atau kode akses (FIDO2). Untuk memverifikasi bahwa MFA diaktifkan, lihat Cara memverifikasi bahwa pengguna disiapkan untuk MFA wajib.
Cakupan penegakan
Cakupan penegakan mencakup waktu penegakan, aplikasi yang terpengaruh, dan persyaratan akun.
Fase penegakan
Note
Tanggal pemberlakuan untuk Fase 2 telah berubah menjadi 1 Oktober 2025.
Pemberlakuan MFA untuk aplikasi diluncurkan dalam dua fase.
Aplikasi Fase 1
Mulai Oktober 2024, MFA diperlukan untuk akun yang masuk ke Azure portal, pusat admin Microsoft Entra, dan pusat admin Microsoft Intune untuk melakukan operasi Buat, Baca, Perbarui, atau Hapus (CRUD). Penerapan ini akan diluncurkan secara bertahap ke semua penyewa di seluruh dunia. Mulai Februari 2025, penerapan MFA secara bertahap dimulai untuk masuk ke Microsoft 365 admin center. Fase 1 tidak akan berdampak pada klien Azure lain seperti Azure CLI, Azure PowerShell, aplikasi seluler Azure, atau alat IaC.
Aplikasi Fase 2
Mulai 1 Oktober 2025, penerapan MFA akan dimulai secara bertahap untuk akun yang masuk ke Azure CLI, Azure PowerShell, Azure aplikasi seluler, alat IaC, dan titik akhir REST API untuk melakukan operasi Buat, Perbarui, atau Hapus apa pun. Operasi baca tidak memerlukan MFA.
Beberapa pelanggan dapat menggunakan akun pengguna di Microsoft Entra ID sebagai akun layanan. Disarankan untuk memigrasikan akun layanan berbasis pengguna ini untuk mengamankan akun layanan berbasis cloud dengan identitas beban kerja.
ID dan URL Aplikasi
Tabel berikut mencantumkan aplikasi, ID aplikasi, dan URL yang terpengaruh untuk Azure.
| Nama Aplikasi | App ID | Pemberlakuan dimulai |
|---|---|---|
| Portal Azure | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | Paruh kedua 2024 |
| Pusat admin Microsoft Entra | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | Paruh kedua 2024 |
| Pusat Admin Microsoft Intune | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | Paruh kedua 2024 |
| antarmuka baris perintah Azure (Azure CLI) | 04b07795-8ddb-461a-bbee-02f9e1bf7b46 | 1 Oktober 2025 |
| Azure PowerShell | 1950a258-227b-4e31-a9cf-717495945fc2 | 1 Oktober 2025 |
| aplikasi seluler Azure | 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa | 1 Oktober 2025 |
| Alat Infrastruktur sebagai Kode (IaC) | Menggunakan ID Azure CLI atau Azure PowerShell | 1 Oktober 2025 |
| REST API (Sarana Kontrol) | N/A | 1 Oktober 2025 |
| Azure SDK | N/A | 1 Oktober 2025 |
Tabel berikut mencantumkan aplikasi dan URL yang terpengaruh untuk Microsoft 365.
| Nama Aplikasi | URL | Pemberlakuan dimulai |
|---|---|---|
| Pusat admin Microsoft 365 | https://portal.office.com/adminportal/home |
Februari 2025 |
| Pusat admin Microsoft 365 | https://admin.cloud.microsoft |
Februari 2025 |
| Pusat admin Microsoft 365 | https://admin.microsoft.com |
Februari 2025 |
Accounts
Semua akun yang masuk untuk melakukan operasi yang dikutip di bagian aplikasi harus menyelesaikan MFA ketika penerapan dimulai. Pengguna tidak diharuskan menggunakan MFA jika mereka access aplikasi, situs web, atau layanan lain yang dihosting di Azure. Setiap aplikasi, situs web, atau pemilik layanan yang tercantum sebelumnya mengontrol persyaratan autentikasi untuk pengguna.
Break glass atau akun akses darurat juga diperlukan untuk masuk dengan MFA setelah penegakan dimulai. Sebaiknya perbarui akun ini untuk menggunakan passkey (FIDO2) atau mengonfigurasi autentikasi berbasis sertifikat untuk MFA. Kedua metode memenuhi persyaratan MFA.
Identitas beban kerja, seperti identitas terkelola dan prinsipal layanan, tidak terpengaruh oleh kedua fase penerapan MFA ini. Jika identitas pengguna digunakan untuk masuk sebagai akun layanan untuk menjalankan otomatisasi (termasuk skrip atau tugas otomatis lainnya), identitas pengguna tersebut perlu masuk dengan MFA setelah penerapan dimulai. Identitas pengguna tidak disarankan untuk otomatisasi. Anda harus memigrasikan identitas pengguna tersebut ke identitas beban kerja.
Perpustakaan Klien
Alur pemberian token OAuth 2.0 Resource Owner Password Credentials (ROPC) tidak kompatibel dengan MFA. Setelah MFA diaktifkan di penyewa Microsoft Entra Anda, API berbasis ROPC yang digunakan dalam aplikasi Anda menghasilkan pengecualian. Untuk informasi selengkapnya tentang cara bermigrasi dari API berbasis ROPC di Microsoft Authentication Libraries (MSAL), lihat Cara bermigrasi jauh dari ROPC. Untuk panduan MSAL khusus bahasa, lihat tab berikut.
Perubahan diperlukan jika Anda menggunakan paket Microsoft.Identity.Client dan salah satu API berikut di aplikasi Anda. API publik klien sudah usang sejak rilis 4.74.0:
- IByUsernameAndPassword.AcquireTokenByUsernamePassword (API klien rahasia)
- PublicClientApplication.AcquireTokenByUsernamePassword (API klien publik) [tidak digunakan lagi]
Panduan MSAL umum yang sama berlaku untuk pustaka identitas Azure. Kelas UsernamePasswordCredential yang disediakan dalam pustaka tersebut menggunakan API berbasis MSAL ROPC. Untuk panduan khusus bahasa, lihat tab berikut.
Perubahan diperlukan jika Anda menggunakan Azure. Identitas paket dan lakukan salah satu hal berikut dalam aplikasi Anda:
- Gunakan DefaultAzureCredential atau EnvironmentCredential dengan dua variabel lingkungan berikut ditetapkan:
AZURE_USERNAMEAZURE_PASSWORD
- Menggunakan
UsernamePasswordCredential(dihentikan penggunaannya pada rilis1.14.0-beta.2)
Memigrasikan akun layanan berbasis pengguna ke identitas beban kerja
Sebaiknya pelanggan menemukan akun pengguna yang digunakan sebagai akun layanan dan mulai memigrasikannya ke identitas beban kerja. Migrasi sering memerlukan pembaruan skrip dan proses otomatisasi untuk menggunakan identitas beban kerja.
Tinjau Cara memverifikasi bahwa pengguna telah disiapkan untuk MFA yang wajib untuk mengidentifikasi semua akun pengguna, termasuk akun pengguna yang digunakan sebagai akun layanan, yang login ke aplikasi.
Untuk informasi selengkapnya tentang cara bermigrasi dari akun layanan berbasis pengguna ke identitas beban kerja untuk autentikasi dengan aplikasi ini, lihat:
- Sign ke Azure dengan identitas terkelola menggunakan Azure CLI
- Sign ke Azure dengan perwakilan layanan menggunakan Azure CLI
- Masuk ke Azure PowerShell secara non-interaktif untuk skenario otomatisasi mencakup panduan dengan identitas terkelola dan perwakilan layanan
Beberapa pelanggan menerapkan kebijakan Akses Bersyarat ke akun layanan berbasis pengguna. Anda dapat merebut kembali lisensi berbasis pengguna, dan menambahkan lisensi identitas beban kerja untuk menerapkan Akses Bersyarat untuk identitas beban kerja.
Memigrasikan Penyedia Identitas federasi ke MFA eksternal
Dukungan untuk solusi MFA eksternal tersedia dengan MFA eksternal, dan dapat digunakan untuk memenuhi persyaratan MFA. Pratinjau kontrol kustom Akses Bersyarat lama tidak memenuhi persyaratan MFA. Anda harus bermigrasi ke MFA eksternal untuk menggunakan solusi eksternal dengan ID Microsoft Entra.
Jika Anda menggunakan Penyedia Identitas federasi (IdP), seperti Active Directory Federation Services, dan penyedia MFA Anda terintegrasi langsung dengan IdP federasi ini, IdP federasi harus dikonfigurasi untuk mengirim klaim MFA. Untuk informasi selengkapnya, lihat Pernyataan masuk yang diharapkan untuk Microsoft Entra MFA.
Bersiap untuk pemberlakuan MFA wajib
Untuk mempersiapkan penerapan MFA secara efektif, konfigurasikan kebijakan Conditional Access yang mengharuskan pengguna untuk masuk dengan MFA. Jika Anda mengonfigurasi pengecualian atau pengecualian dalam kebijakan, pengecualian tersebut tidak lagi berlaku. Jika Anda memiliki kebijakan Access Bersyarat yang lebih ketat yang menargetkan Azure dan memerlukan autentikasi yang lebih kuat, seperti MFA tahan pengelabuan, kebijakan tersebut tetap diberlakukan.
Access bersyarat memerlukan lisensi P1 atau P2 Microsoft Entra ID. Jika Anda tidak dapat menggunakan Access Bersyarkat, aktifkan default keamanan.
Anda dapat memberlakukan MFA sendiri dengan menggunakan definisi bawaan dalam Azure Policy. Untuk mempelajari selengkapnya dan mengikuti gambaran umum langkah demi langkah untuk menerapkan penetapan kebijakan ini di lingkungan Anda, lihat Tutorial: Menerapkan penerapan mandiri MFA melalui Azure Policy.
Untuk pengalaman kompatibilitas terbaik, pastikan pengguna di penyewa Anda menggunakan Azure CLI versi 2.76 dan Azure PowerShell versi 14.3 atau yang lebih baru. Jika tidak, Anda dapat mengharapkan untuk melihat pesan kesalahan seperti yang dijelaskan dalam topik-topik ini:
- Memecahkan masalah kesalahan MFA di Azure PowerShell
- Memecahkan masalah kesalahan MFA di Azure CLI
Note
Pengguna yang masuk tanpa MFA dapat menggunakan aplikasi Fase 2. Tetapi jika mereka mencoba membuat, memperbarui, atau menghapus sumber daya, aplikasi mengembalikan kesalahan yang mengatakan bahwa mereka perlu masuk dengan Otentikasi Multi-Faktor (MFA) dan verifikasi klaim. Beberapa klien menggunakan tantangan klaim untuk meminta pengguna untuk meningkatkan dan melakukan MFA. Aplikasi lain hanya mengembalikan kesalahan tanpa permintaan MFA. Kebijakan Akses Bersyarat atau pengaturan keamanan default disarankan untuk membantu pengguna memenuhi MFA sebelum mereka melihat pesan kesalahan.
Minta lebih banyak waktu untuk mempersiapkan penerapan MFA Fase 1
Kami memahami bahwa beberapa pelanggan mungkin membutuhkan lebih banyak waktu untuk mempersiapkan persyaratan MFA ini. Microsoft memungkinkan pelanggan dengan lingkungan kompleks atau hambatan teknis untuk menunda penerapan Fase 1 untuk penyewa mereka hingga 30 September 2025.
Untuk setiap penyewa tempat mereka ingin menunda tanggal mulai penerapan, Global Administrator dapat masuk ke https://aka.ms/managemfaforazure untuk memilih tanggal mulai.
Caution
Dengan menunda tanggal mulai penerapan, Anda mengambil risiko ekstra karena akun yang access layanan Microsoft seperti Azure portal adalah target yang sangat berharga bagi pelaku ancaman. Kami menyarankan semua penyewa menyiapkan MFA sekarang untuk mengamankan sumber daya cloud.
Minta lebih banyak waktu untuk mempersiapkan penerapan MFA Fase 2
Microsoft memungkinkan pelanggan dengan lingkungan yang kompleks atau hambatan teknis untuk menunda penerapan Fase 2 untuk penyewa mereka hingga 1 Juli 2026. Anda dapat meminta lebih banyak waktu untuk mempersiapkan pemberlakuan Fase 2 MFA di https://aka.ms/postponePhase2MFA. Pilih tanggal mulai lain, dan pilih Terapkan. Setelah penerapan Fase 2 dimulai, Anda dapat mengirimkan permintaan ke Bantuan dan Dukungan Microsoft untuk mengangkat penegakan sementara. Permintaan harus dilakukan oleh Global Administrator karena implikasi keamanan.
Note
Jika Anda menunda awal Fase 1, awal Fase 2 juga ditunda ke tanggal yang sama. Anda dapat memilih tanggal mulai yang lebih baru untuk Fase 2.
Mengonfirmasi penerapan wajib Otentikasi Multifaktor
Konfirmasi penegakan Tahap 1
Untuk mengonfirmasi bahwa MFA wajib Fase 1 diberlakukan untuk penyewa Anda:
Masuk ke portal Microsoft Azure sebagai Administrator Global.
Telusuri menuju https://aka.ms/managemfaforazure.
Verifikasi bahwa halaman Autentikasi multifaktor (Fase 1) menunjukkan banner yang mengonfirmasi bahwa penerapan dimulai untuk penyewa Anda.
Konfirmasi penerapan Fase 2
Untuk mengonfirmasi bahwa MFA wajib Fase 2 diberlakukan untuk penyewa Anda:
Masuk ke portal Microsoft Azure sebagai Administrator Global.
Telusuri menuju https://aka.ms/postponePhase2MFA.
Verifikasi bahwa halaman Autentikasi multifaktor (Fase 2) memperlihatkan spanduk yang mengonfirmasi penerapan dimulai untuk penyewa Anda.
Microsoft Entra ID log masuk menunjukkan bahwa aplikasi tersebut yang memberlakukan MFA sebagai sumber persyaratan MFA.
FAQs
Pertanyaan: Akun mana yang terpengaruh oleh penerapan MFA Fase 2?
Answer: Penegakan Fase 2 Azure berlaku untuk semua akun pengguna yang melakukan tindakan pengelolaan sumber daya Azure melalui klien Azure, termasuk PowerShell, CLI, SDK, atau bahkan REST API. Penerapan ini berada di sisi server Azure Resource Manager, sehingga setiap permintaan yang menargetkan https://management.azure.com berada di bawah cakupan penerapan. Akun Automation tidak berada dalam cakupan selama mereka menggunakan identitas terkelola atau perwakilan layanan. Setiap akun otomatisasi yang disiapkan sebagai identitas pengguna akan dikenakan tindakan tegas.
Question: Bagaimana cara memahami dampak penegakan MFA tanpa Akses Bersyarat?
Answer: Jika lisensi Microsoft Entra ID Anda tidak menyertakan Access Kondisional, Anda dapat menggunakan Azure Policy untuk memahami bagaimana penerapan MFA memengaruhi penyewa Anda. Selama penerapan sistem, Microsoft menyebarkan Azure Policy ke penyewa Anda. Anda dapat mengikuti langkah-langkah tersebut untuk menyebarkan Azure policy yang sama kapan saja. Anda dapat menyebarkan kebijakan dalam mode Audit, lalu mengonversi ke mode Penegakan. Anda dapat memilih tanggal untuk menerapkan kebijakan ini di penyewa saat Anda berada dalam mode Penegakan. Kemudian saat Microsoft memberlakukan MFA, tidak ada dampak lebih lanjut pada penyewa Anda.
Pertanyaan: Apakah ada pengecualian untuk akun tertentu?
Answer: Penerapan sistem berlaku untuk semua akun pengguna, terlepas dari apakah mereka adalah akun siswa, akun break-glass, akun administrator dengan peran yang diaktifkan atau memenuhi syarat, atau pengecualian pengguna yang diaktifkan untuk mereka. Masing-masing jenis akun ini dapat melakukan tindakan manajemen sumber daya di Azure, yang menimbulkan risiko keamanan yang sama jika disusupi.
Question: Apakah API Microsoft Graph berada di bawah cakupan penerapan Fase 2?
Answer: Umumnya, API Microsoft Graph tidak berada dalam cakupan untuk penerapan MFA Azure. Hanya permintaan yang dikirim ke https://management.azure.com/ yang berada di bawah cakupan penerapan.
Pertanyaan: Jika penyewa hanya digunakan untuk pengujian, apakah MFA diperlukan?
Answer: Ya, setiap penyewa Azure akan memerlukan MFA, tanpa pengecualian untuk lingkungan pengujian.
Question: Bagaimana dampak persyaratan ini terhadap Microsoft 365 admin center?
Answer: Wajib MFA akan diluncurkan ke Microsoft 365 admin center mulai Februari 2025. Pelajari lebih lanjut tentang persyaratan MFA wajib untuk Microsoft 365 admin center pada posting blog Mengabulkan autentikasi multifaktor wajib untuk Microsoft 365 admin center.
Pertanyaan: Apakah saya perlu menyelesaikan MFA jika saya memilih opsi untuk Tetap masuk?
Jawaban: Ya, bahkan jika Anda memilih Tetap masuk, Anda harus menyelesaikan MFA sebelum dapat masuk ke aplikasi ini.
Pertanyaan: Apakah penerapan berlaku untuk akun tamu B2B?
Jawaban: Ya, MFA harus dipatuhi baik dari penyewa sumber daya mitra, atau penyewa asal pengguna jika disiapkan dengan benar untuk mengatur klaim MFA ke penyewa sumber daya dengan menggunakan akses lintas penyewa.
Pertanyaan: Apakah pemberlakuan berlaku untuk Azure untuk Pemerintah AS atau Azure sovereign clouds?
Answer: Microsoft memberlakukan MFA wajib hanya di cloud Azure publik. Microsoft saat ini tidak memberlakukan MFA di Azure untuk Pemerintah AS atau sovereign cloud Azure lainnya.
Pertanyaan: Bagaimana kami dapat mematuhi jika kami menerapkan MFA dengan menggunakan penyedia identitas atau solusi MFA lain, dan kami tidak memberlakukan dengan menggunakan Microsoft Entra MFA?
Answer: MFA pihak ketiga dapat diintegrasikan langsung dengan Microsoft Entra ID. Untuk informasi selengkapnya, lihat Referensi penyedia metode eksternal autentikasi multifaktor Microsoft Entra. Microsoft Entra ID dapat dikonfigurasi secara opsional dengan penyedia identitas federasi. Jika demikian, solusi penyedia identitas perlu dikonfigurasi dengan benar untuk mengirim multipleauthn klaim ke Microsoft Entra ID. Untuk informasi selengkapnya, lihat Penuhi kontrol autentikasi multifaktor (MFA) Microsoft Entra ID dengan klaim MFA dari IdP yang terfederasi.
Pertanyaan: Apakah MFA wajib akan memengaruhi kemampuan saya untuk menyinkronkan dengan Microsoft Entra Connect atau Microsoft Entra Cloud Sync?
Jawaban: Tidak. Akun layanan sinkronisasi tidak terpengaruh oleh persyaratan MFA wajib. Hanya aplikasi yang tercantum sebelumnya yang memerlukan MFA untuk masuk.
Pertanyaan: Apakah saya dapat menolak?
Answer: Tidak ada cara untuk memilih keluar. Gerakan keamanan ini sangat penting bagi keselamatan dan keamanan platform Azure dan sedang diulang di seluruh vendor cloud. Misalnya, lihat Secure by Design: AWS untuk meningkatkan persyaratan MFA di 2024.
Opsi untuk menunda tanggal mulai penerapan tersedia untuk pelanggan. Administrator Global dapat membuka Azure portal untuk menunda tanggal mulai penerapan untuk penyewa mereka. Administrator Global harus memiliki akses yang ditingkatkan sebelum mereka menunda tanggal mulai penerapan MFA di halaman ini. Mereka harus melakukan tindakan ini untuk setiap penyewa yang membutuhkan penundaan.
Question: Dapatkah saya menguji MFA sebelum Azure memberlakukan kebijakan untuk memastikan tidak ada yang rusak?
Pertanyaan: Bagaimana jika saya sudah mengaktifkan MFA, apa yang terjadi selanjutnya?
Answer: Pelanggan yang sudah memerlukan MFA untuk pengguna mereka yang mengakses aplikasi yang disebutkan sebelumnya tidak melihat perubahan apa pun. Jika Anda hanya memerlukan MFA untuk subset pengguna, maka setiap pengguna yang belum menggunakan MFA sekarang perlu menggunakan MFA saat mereka masuk ke aplikasi.
Question: Bagaimana cara meninjau aktivitas MFA di Microsoft Entra ID?
Jawaban: Untuk meninjau detail tentang kapan pengguna diminta untuk masuk dengan MFA, gunakan log masuk Microsoft Entra. Untuk informasi selengkapnya, lihat Detail peristiwa masuk untuk autentikasi multifaktor Microsoft Entra.
Pertanyaan: Bagaimana jika saya menghadapi skenario darurat "break glass"?
Jawaban: Sebaiknya perbarui akun ini untuk menggunakan kode akses (FIDO2) atau mengonfigurasi autentikasi berbasis sertifikat untuk MFA. Kedua metode memenuhi persyaratan MFA.
Pertanyaan: Bagaimana jika saya tidak menerima email tentang mengaktifkan MFA sebelum diberlakukan, dan kemudian saya dikunci. Bagaimana cara mengatasinya?
Jawaban: Pengguna tidak boleh dikunci, tetapi mereka mungkin mendapatkan pesan yang meminta mereka untuk mengaktifkan MFA setelah penerapan untuk penyewa mereka dimulai. Jika pengguna dikunci, mungkin ada masalah lain. Untuk informasi selengkapnya, lihat Akun telah dikunci.
Konten terkait
Tinjau topik berikut untuk mempelajari selengkapnya tentang cara mengonfigurasi dan menyebarkan MFA:
- Cara menunda penegakan untuk penyewa di mana pengguna tidak dapat menandatangani
- Cara memverifikasi bahwa pengguna disiapkan untuk MFA wajib
- Tutorial: Mengamankan peristiwa masuk pengguna dengan autentikasi multifaktor Microsoft Entra
- Merencanakan penyebaran autentikasi multifaktor Microsoft Entra
- Metode MFA yang resistan terhadap phishing
- Autentikasi multifaktor Microsoft Entra
- Metode autentikasi