Bagaimana Conditional Access dan PIM Benar-Benar Menghentikan Serangan?

Kebijakan kata sandi menghentikan serangan tebakan. Mereka tidak melakukan apa pun terhadap token sesi yang dicuri, permintaan MFA yang di-phishing, atau akun admin yang berdiri dengan hak Global Administrator selama dua tahun. Conditional Access dan Privileged Identity Management (PIM) adalah dua kontrol Azure AD / Entra ID yang benar-benar mengatasi celah tersebut, dan mereka bekerja paling baik bersama.

Apa yang dilakukan Conditional Access di balik layar

Conditional Access adalah mesin if-this-then-that yang dievaluasi pada waktu sign-in. Sisi "if" (sinyal) mencakup keanggotaan pengguna/grup, status kepatuhan perangkat, lokasi jaringan, risiko sign-in (dari Identity Protection), aplikasi yang diakses, dan tipe aplikasi klien (browser vs. protokol legacy). Sisi "then" (kontrol) mencakup: memerlukan MFA, memerlukan perangkat yang patuh, memerlukan aplikasi klien yang disetujui, memblokir akses sepenuhnya, atau memerlukan penerimaan terms-of-use.

Kebijakan yang penting di hampir setiap tenant: blokir autentikasi legacy. Protokol seperti POP, IMAP, dan SMTP yang lebih lama tidak mendukung tantangan MFA modern, jadi mereka adalah hal pertama yang dicoba alat credential-stuffing. Periksa log sign-in yang disaring dengan "Client App = Other clients" sebelum Anda memblokir — Anda akan sering menemukan satu pemindai legacy atau printer multifungsi lama yang masih melakukan autentikasi dengan basic auth.

Yang kedua patut dimiliki sejak hari pertama: memerlukan MFA untuk semua pengguna, disertai pengecualian grup hanya untuk akun break-glass. Jangan cakup MFA hanya pada "admin saja." Akun pengguna standar yang dikompromikan adalah cara penyerang mendapatkan pijakan pertama mereka sebelum eskalasi privilege bahkan dimulai.

Risiko sign-in vs. risiko pengguna — sinyal berbeda, respons berbeda

Identity Protection (bagian dari Entra ID P2) menghasilkan dua skor risiko terpisah dan mudah untuk mengacaukan keduanya:

• Sign-in risk — upaya autentikasi spesifik ini terlihat anomali (impossible travel, anonymous IP, properti sign-in yang tidak familiar).
• User risk — akun ini telah ditandai karena alasan yang terikat pada identitas itu sendiri (kredensial yang bocor ditemukan dalam korpus pelanggaran, aktivitas kompromasi yang dikonfirmasi).

Kebijakan Conditional Access yang merespons risiko sign-in biasanya harus menantang dengan MFA — jika pengguna nyata dapat menyelesaikan tantangan, biarkan mereka masuk. Kebijakan yang merespons risiko pengguna harus memaksa reset kata sandi, karena MFA saja tidak membantu jika kredensial itu sendiri sudah terbakar.

Mengapa akses admin yang berdiri adalah masalah yang lebih besar

Bahkan dengan Conditional Access yang sangat ketat, akun yang memegang Global Administrator secara permanen adalah target yang duduk di hadapan mata di direktori. Siapa pun yang mengomprominya mewarisi kontrol tenant penuh tanpa langkah tambahan yang diperlukan. PIM menghilangkan bagian "permanen".

Dengan PIM, peran admin ditugaskan sebagai eligible daripada active. Pengguna harus secara eksplisit mengaktifkan peran, yang memicu justifikasi yang diperlukan, alur kerja persetujuan opsional, konfirmasi ulang MFA, dan jendela terikat waktu — biasanya 1 hingga 8 jam — setelah itu peran secara otomatis dinonaktifkan. Tidak ada orang, termasuk pemilik akun, yang memiliki Global Admin yang berdiri kecuali mereka secara aktif menggunakannya.

Konfigurasi PIM minimum yang benar-benar dapat digunakan

• Setiap peran di atas Helpdesk Administrator: eligible, bukan permanen.
• Global Administrator dan Privileged Role Administrator: memerlukan persetujuan dari admin kedua, bukan hanya self-activation.
• Aktivasi MFA diperlukan, tidak ada pengecualian.
• Durasi aktivasi maksimum 4 jam memaksa orang untuk mengaktifkan kembali untuk sesi kerja yang benar-benar terpisah, yang juga menghasilkan jejak audit yang lebih bersih.
• Access reviews setiap 90 hari di semua penugasan eligible — akun ditambahkan untuk satu proyek dan tidak pernah dihapus sebaliknya.

Di mana tim melakukan ini dengan salah

Kegagalan paling umum bukan desain kebijakan, tetapi daftar pengecualian. Kebijakan Conditional Access dengan grup "exclude users ini karena aplikasi tidak mendukung MFA" yang terus bertambah akhirnya mengecualikan setengah tenant. Lacak pengecualian sebagai item backlog dengan pemilik dan tanggal penghapusan, bukan bucket permanen.

Kegagalan kedua adalah akun break-glass yang tidak benar-benar diuji. Dua akun darurat, dikecualikan dari Conditional Access dan PIM, dengan kata sandi panjang acak yang disimpan offline dan alerting pada sign-in apa pun — dan seseorang harus mencoba masuk ke dalamnya setiap kuartal untuk mengonfirmasi mereka masih berfungsi.

Conditional Access dan PIM bukan centang untuk audit kepatuhan. Mereka adalah perbedaan antara kredensial yang di-phishing menjadi gangguan dan menjadi kompromasi tenant penuh. Jika Anda memetakan kontrol identitas sebagai bagian dari build-out Blue Team, segmen Cloud dan Blue Team Korra Studio mencakup sisi deteksi — peristiwa risiko Identity Protection apa yang sebenarnya terlihat di Sentinel dan cara memberikan alert pada pola aktivasi PIM yang mustahil.