Dari Gatekeeper ke Watcher: Menjembatani Keamanan Pra-Autentikasi dan Pasca-Autentikasi

By Mirko Peters · 2026-08-11

Selamat datang kembali di podcast dan pembahasan teknis pendampingnya! Jika Anda pernah merasa strategi keamanan identitas Anda memiliki titik buta tepat setelah pengguna berhasil masuk…

Automatically translated with AI from the original post. Read the English original

Selamat datang kembali di podcast dan pembahasan teknis pendampingnya! Jika Anda pernah merasa strategi keamanan identitas Anda memiliki titik buta tepat setelah pengguna berhasil masuk, Anda pasti tidak sendirian. Selama bertahun-tahun, organisasi sangat bergantung pada kontrol pra-autentikasi untuk menghalau penyerang, dan memperlakukan pintu depan sebagai garis pertahanan terakhir. Namun, apa yang terjadi ketika penyerang berhasil melewati pintu itu dengan token yang valid atau kredensial curian? Dilema itulah yang menjadi inti episode terbaru kami, Conditional Access with Defender for Identity Signals. Dalam tulisan ini, kami akan mengembangkan konsep-konsep tersebut dan menguraikan cara menggabungkan gatekeeper pra-autentikasi dengan watcher pasca-autentikasi untuk membangun arsitektur identitas yang benar-benar tangguh.

Gagasan Inti (TL;DR)

Untuk benar-benar memahami perlindungan identitas modern, Anda perlu melihat alat-alat Anda sebagai peran khusus yang bekerja sama secara real-time:

• Conditional Access (CA) ibarat penjaga pintu Anda. Alat ini sangat andal dalam mengambil keputusan pra-autentikasi berdasarkan siapa yang mencoba masuk, dari mana asalnya, dan kondisi perangkatnya.
• Defender for Identity (DfI) ibarat sistem CCTV Anda yang dipadukan dengan pengamanan lantai. Alat ini unggul dalam memantau perilaku pasca-autentikasi, pergerakan lateral, dan anomali internal.
• Ketahanan yang sesungguhnya hanya terjadi ketika risiko pasca-autentikasi menaikkan hambatan pra-autentikasi secara otomatis dan dinamis, tepat di sana, dalam sesi.

Model Mental

Mari kita sempurnakan model mental tentang cara komponen-komponen ini berinteraksi dalam ekosistem Anda:

• Gatekeeper (CA): Mengevaluasi siapa yang sedang masuk, lokasinya, kondisi perangkat, risiko saat masuk, dan menerapkan kontrol sesi secara langsung.
• Watcher (DfI + M365 Defender): Memburu pergerakan lateral, pola akses sumber daya yang tidak normal, Kerberoasting, penyalahgunaan NTLM, dan eskalasi hak istimewa yang tidak terduga.
• Umpan balik (feedback loop): Watcher menandai perilaku mencurigakan, yang kemudian menaikkan skor risiko pengguna atau risiko sesi. Hal ini memaksa Gatekeeper untuk segera memperketat kontrol dengan meningkatkan MFA, memblokir akses sepenuhnya, atau membatasi sesi yang sedang aktif.

Cetak Biru Integrasi (apa yang diaktifkan, secara berurutan)

Agar sistem-sistem ini dapat saling berkomunikasi, diperlukan peluncuran yang terstruktur. Berikut cetak biru yang sebaiknya Anda ikuti:

1. CA sadar risiko (dasar)
   • Entra ID Protection: aktifkan evaluasi Risiko pengguna dan Risiko saat masuk.
   • Buat kebijakan CA:
     • Blokir saat Risiko pengguna = Tinggi (atau wajibkan penggantian kata sandi jika alur kerja helpdesk Anda mendukungnya).
     • Wajibkan MFA saat Risiko saat masuk ≥ Sedang.
     • Wajibkan perangkat yang patuh untuk aplikasi dengan sensitivitas sedang hingga tinggi; gunakan filter perangkat untuk endpoint yang tidak dikelola agar langsung diarahkan ke kontrol sesi yang dibatasi.
2. Biarkan watcher berkomunikasi dengan gatekeeper
   • Pastikan DfI secara aktif mengalirkan peringatan ke Microsoft 365 Defender dan Sentinel (jika Anda menggunakannya untuk SIEM/SOAR).
   • Otomatiskan tindakan "Konfirmasi telah disusupi" pada pengguna untuk peringatan DfI berkeparahan tinggi. Tindakan ini menetapkan Risiko pengguna = Tinggi di Entra ID Protection, sehingga kebijakan CA Anda langsung bereaksi.
   • Jalur otomasi: Insiden M365 Defender → Logic App atau Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → opsional Keluarkan dari sesi (Force sign-out).
   • Aktifkan Continuous Access Evaluation (CAE) pada semua aplikasi yang didukung (Exchange, SharePoint, Graph) agar perubahan kebijakan benar-benar menghentikan token yang sedang aktif.
3. Kontrol sesi untuk penahanan
   • Untuk sesi yang tidak dikelola atau berisiko, terapkan Defender for Cloud Apps (session proxy) langsung dari CA:
     • CA → Use Conditional Access App Control (pantau terlebih dahulu, lalu blokir eksfiltrasi data seperti unduhan, salin-tempel, pencetakan, dan sinkronisasi).
   • Pasangkan ini dengan risiko perangkat MDE → kepatuhan Intune → Akses Bersyarat "Require compliant device" untuk semua aplikasi sensitif.
4. Pagar pengaman identitas istimewa
   • PIM harus menerapkan akses Just-in-Time. Wajibkan MFA + perangkat yang patuh + tidak ada status pengguna berisiko sebelum peningkatan hak akses diizinkan.
   • Terapkan kebijakan Akses Bersyarat untuk memblokir peran istimewa jika risiko pengguna ≥ Rendah (ya, bahkan untuk risiko Rendah) agar triase segera dilakukan sebelum peran administratif dapat diambil alih.

"If This, Then That": Memetakan Sinyal DfI ke Tindakan Akses Bersyarat

Memetakan sinyal deteksi tertentu dari Defender for Identity ke tindakan Akses Bersyarat dan respons otomatis menjembatani kesenjangan antara observasi pasif dan pertahanan aktif:

Mulailah dengan menjalankan ini dalam mode audit/pantau selama 1 hingga 2 minggu, lalu ubah respons ke mode terapkan per kelas peringatan seiring meningkatnya keyakinan Anda.

Contoh Kebijakan (praktis, minimal)

Untuk menerapkan strategi ini di lingkungan produksi, berikut empat kebijakan dasar yang sebaiknya Anda konfigurasi:

1. Blokir saat risiko pengguna = Tinggi
   • Tetapkan untuk: Semua pengguna (kecualikan akun break-glass), Semua aplikasi cloud
   • Kondisi: Risiko pengguna = Tinggi
   • Pemberian akses: Blokir akses
2. Step-up saat risiko masuk
   • Tetapkan untuk: Semua pengguna, aplikasi bernilai tinggi (portal admin, Exchange, SharePoint, pusat admin Entra)
   • Kondisi: Risiko masuk ≥ Sedang
   • Pemberian akses: Wajibkan MFA + Wajibkan perangkat yang patuh (atau perangkat terkelola)
3. Kontrol sesi untuk perangkat tidak terkelola
   • Tetapkan untuk: Semua pengguna, SharePoint/OneDrive/Teams
   • Status perangkat: Hybrid/Patuh = lewati; Tidak terkelola = terapkan
   • Sesi: Gunakan Conditional Access App Control (Blokir unduhan)
4. Pengaman peningkatan hak akses istimewa
   • Tetapkan untuk: Peran direktori = Peran administratif istimewa
   • Kondisi: Risiko pengguna ≥ Rendah ATAU Risiko masuk ≥ Sedang
   • Pemberian akses: Wajibkan MFA + Wajibkan perangkat yang patuh; Blokir jika risiko ≥ Tinggi

Playbook Otomasi (siap dihubungkan)

Otomasi adalah kunci yang mengurangi Mean Time to Contain (MTTC) Anda. Berikut dua playbook yang bisa Anda bangun hari ini:

Playbook A: Peringatan DfI berkeparahan tinggi → Tahan identitas

• Pemicu: Insiden M365 Defender yang diberi tag IdentityThreatHigh
• Tindakan:
  1. Graph API – konfirmasi pengguna disusupi (mengatur risiko pengguna menjadi Tinggi)
  2. Entra ID – cabut token penyegaran segera
  3. Intune/MDE – isolasi perangkat (jika terkait satu perangkat utama)
  4. ServiceNow/JSM – buat tiket insiden dengan linimasa dan artefak yang dikumpulkan
  5. Beri tahu SOC dan pemilik pengguna melalui kartu adaptif Teams dengan tombol rollback satu klik jika terjadi false positive

Playbook B: Lonjakan akses SharePoint yang tidak wajar

• Pemicu: Peringatan Defender "Unusual file download"
• Tindakan:
  1. Beri tag pengguna dengan UnderInvestigation melalui atribut ekstensi AAD
  2. Pindahkan pengguna ke kebijakan Akses Bersyarat yang mengarahkan mereka ke App Control (memblokir unduhan dan pencetakan)
  3. Jalankan hold eDiscovery pada situs SharePoint yang terdampak (opsional, bergantung pada kebutuhan kepatuhan)
  4. Kedaluwarsakan penahanan secara otomatis dalam 72 jam kecuali SOC memperpanjangnya secara manual

Hunting & Kueri yang Berguna

Proactive hunting membantu Anda menangkap celah sebelum penyerang memanfaatkannya. Gunakan kueri berikut di Advanced Hunting M365 Defender:

Lonjakan akses situs SharePoint oleh pengguna dibandingkan dengan baseline 30 hari:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Lonjakan risiko masuk yang berkaitan erat dengan peringatan DfI setelahnya:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Metrik yang Membuktikan Hasilnya

Saat melaporkan ke jajaran pimpinan, Anda memerlukan metrik yang menunjukkan pengurangan risiko yang nyata. Pantau indikator kinerja utama berikut:

• Mean Time To Contain (MTTC) untuk insiden identitas (waktu dari pembuatan peringatan hingga penerapan CA) ↓
• Attacker dwell time (waktu dari tindakan mencurigakan awal hingga remediasi penuh) ↓
• Sesi berisiko yang diblokir (peristiwa yang dipicu kebijakan) ↑ sementara tingkat positif palsu ↓
• Usia backlog pengguna berisiko (kasus terbuka yang lebih dari 24 jam) ↓
• Latensi pencabutan token (diukur dalam detik) ↓
• Kegagalan elevasi hak istimewa akibat risiko (tertangkap lebih awal sebelum menimbulkan kerusakan) ↑ lalu menurun dan menjadi stabil seiring waktu
• Secure Score di seluruh Identity, Devices, dan Apps ↑ tanpa lonjakan yang sepadan pada tiket helpdesk

Strategi Rollout 30/60/90

Hindari upaya mengubah semuanya sekaligus. Gunakan lini masa bertahap berikut:

Hari 0–30 (Fondasi)

• Aktifkan pengaturan User and Sign-in risk di Entra, lalu terapkan kebijakan dasar CA dalam mode audit sebelum beralih ke mode penegakan.
• Onboard Defender for Identity ke M365 Defender; validasi peringatan dan pemetaan entitas inti.
• Aktifkan Continuous Access Evaluation (CAE) untuk aplikasi yang didukung dan integrasikan risiko perangkat MDE dengan kepatuhan Intune.

Hari 31–60 (Umpan Balik & Penahanan)

• Bangun Playbook A dan B di Logic Apps; uji secara menyeluruh dalam status dry-run.
• Lakukan pilot App Control untuk sesi tak terkelola bersama 2 hingga 3 tim bisnis yang berkolaborasi.
• Terapkan kebijakan pengaman elevasi PIM.

Hari 61–90 (Penegakan & Pengukuran)

• Ubah playbook otomatis Anda ke mode enforce penuh untuk peringatan dengan tingkat keyakinan tinggi.
• Siapkan workbook keamanan identitas (di Sentinel atau Power BI) yang melacak metrik di atas.
• Lakukan latihan purple-team triwulanan untuk memvalidasi MTTC, kecepatan pencabutan token, dan perubahan kebijakan CA dalam skenario live-fire.

Kesalahan Umum (dan Default yang Lebih Aman)

Waspadai kekeliruan umum berikut selama implementasi Anda:

• Kesalahan: Hanya mengandalkan risiko sign-in CA → Perbaikan: Tanggapi juga risiko pengguna dan peringatan DfI pasca-autentikasi.
• Kesalahan: Tidak ada CAE yang dikonfigurasi, sehingga token usang membuat sesi yang disusupi tetap aktif → Perbaikan: Aktifkan CAE dan tanamkan pencabutan token langsung ke playbook otomatis Anda.
• Kesalahan: Memblokir unduhan file secara luas di seluruh perusahaan sehingga memicu protes pengguna → Perbaikan: Terapkan App Control secara selektif, hanya ketika sesi tidak terkelola atau berisiko.
• Kesalahan: Badai peringatan dan positif palsu akibat alur auto-compromise yang agresif → Perbaikan: Batasi otomatisasi Anda di balik verifikasi multi-sinyal (misalnya, peringatan tinggi DfI + volume unduhan yang tidak biasa + akses di luar jam kerja).
• Kesalahan: Akun break-glass terkunci secara tidak sengaja oleh kebijakan risiko otomatis → Perbaikan: Kecualikan dua akun break-glass yang dipantau ketat dan rotasi kredensialnya setiap triwulan.

Artefak Salin/Tempel

Untuk membantu Anda mengomunikasikan perubahan ini ke seluruh organisasi, gunakan cuplikan siap pakai berikut:

Ringkasan satu baris CAB untuk eksekutif:

Kami berhasil menghubungkan perilaku pengguna pasca-login dengan keputusan kontrol akses kami. Jika sebuah akun mulai bertindak tidak biasa, kami menambahkan gesekan keamanan atau memblokir akses dalam sesi. Hal ini secara signifikan memperpendek waktu tinggal penyerang tanpa memperlambat pekerjaan harian yang normal.

Catatan perubahan untuk administrator:

• Kebijakan Conditional Access baru dapat meminta MFA step-up atau memblokir akses ketika risiko anomali terdeteksi. Token autentikasi aktif kini dapat dicabut di tengah sesi berdasarkan telemetri. Akun break-glass tetap dikecualikan secara eksplisit. Silakan pantau workbook Identity Resilience untuk analisis dampak.

Kartu notifikasi Teams untuk pemilik (otomatis):

• “Kami mendeteksi aktivitas file yang tidak biasa dari akun Anda. Kami telah menerapkan perlindungan sementara (seperti menonaktifkan unduhan pada perangkat tidak terkelola). Jika ini Anda, cukup klik Acknowledge; jika bukan, segera klik Report.”