Mengapa Akun 'svc-' Anda Adalah Bom Waktu

By Mirko Peters · 2026-08-11

Selamat datang kembali di podcast dan pembahasan mendalam kami tentang arsitektur keamanan perusahaan. Jika organisasi Anda seperti kebanyakan, tinjauan singkat di Active Dir…

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

Selamat datang kembali di podcast dan pembahasan mendalam kami tentang arsitektur keamanan perusahaan. Jika organisasi Anda seperti kebanyakan, tinjauan singkat di Active Directory atau direktori Microsoft Entra ID akan menampilkan kumpulan akun yang berantakan dengan awalan "svc-", "app-", atau "admin-bot". Akun-akun ini menjaga operasional tetap berjalan, data terus mengalir, dan otomatisasi tetap bekerja. Namun, akun-akun ini juga merupakan titik buta keamanan terbesar dalam postur keamanan modern Anda. Dalam artikel blog ini, kami memperluas percakapan terbaru kami untuk menguraikan mengapa akun layanan tradisional sepenuhnya melemahkan arsitektur Zero Trust Anda, dan mengapa bermigrasi ke Microsoft Entra Workload Identities adalah satu-satunya jalan ke depan.

Untuk pembahasan audio lengkap tentang topik ini, pastikan Anda mendengarkan episode podcast pendamping kami, Replace Service Accounts with Entra Workload Identities. Sekarang, mari kita bahas mekanisme risiko non-manusia dan cara Anda dapat menghilangkannya sepenuhnya.

Poin Singkat (TL;DR)

Akun layanan dengan secret statis dan hak akses luas adalah celah identitas terbesar Anda. Workload Identities (di Microsoft Entra ID) memberikan setiap aktor non-manusia identitas yang terkelola dengan hak akses minimum, siklus hidup, kebijakan CA, rotasi, dan jejak audit lengkap, tanpa merusak otomatisasi Anda.

Mengapa Akun Layanan Gagal (dan Merusak Zero Trust)

Model akun layanan tradisional dibangun untuk era perimeter jaringan yang sudah tidak ada lagi. Ketika kepercayaan ditentukan oleh apakah perangkat terhubung ke LAN perusahaan, kata sandi statis yang disimpan dalam file konfigurasi terasa wajar. Hari ini, filosofi desain tersebut justru menjadi beban.

• Secret statis & tanpa MFA -> mudah dicuri, sulit dirotasi dengan aman
• Hak istimewa berlebih secara default -> izin "yang penting berfungsi" menjadi permanen
• Tanpa siklus hidup -> akun yatim piatu atau terlupakan tetap bertahan melalui migrasi dan reorganisasi
• Auditabilitas minim -> "siapa yang menggunakan ini dan untuk apa?" = tebakan dan tangkapan layar
• Budaya pengecualian -> pengecualian CA/MFA untuk bot diam-diam memperluas permukaan serangan Anda

Managed Identities: Langkah Baik, tetapi Terikat pada Azure

Ketika organisasi menyadari bahwa akun layanan statis itu berbahaya, langkah alami pertama mereka sering kali beralih ke Azure Managed Identities. Managed Identities merupakan lompatan besar ke depan karena sepenuhnya menghilangkan secret untuk sumber daya yang dihosting di Azure, tetapi tetap memiliki batasan yang jelas.

• ✅ Akses tanpa secret untuk sumber daya native Azure (Functions, VM, Logic Apps)
• ❌ Celah untuk target hybrid/pihak ketiga, pemetaan kepemilikan yang lemah, dan tampilan tata kelola yang terbatas
• ❌ Cakupan CA/hak akses tidak seragam di luar permukaan non-Azure

Workload Identities: Apa yang Sebenarnya Anda Dapatkan

Di sinilah Microsoft Entra Workload Identities berperan. Alih-alih memperlakukan aktor non-manusia sebagai warga kelas dua atau memaksa Anda ke batasan khusus Azure, Workload Identities mengangkat aplikasi, skrip, dan layanan otomatis menjadi principal keamanan kelas satu.

• Identitas non-manusia kelas satu (aplikasi, skrip, konektor, RPA, integrasi)
• Izin yang dibatasi lingkupnya (peran Graph/sumber daya, autentikasi hanya-aplikasi) dengan hak akses minimum
• Siklus hidup (pemilik, ritme tinjauan, alur penonaktifan) yang terkait dengan proses bisnis
• Conditional Access untuk workload (gerbang berbasis risiko/konteks, kontrol sesi jika didukung)
• Kebersihan kredensial (secret berumur pendek, sertifikat, kebijakan rotasi kunci)
• Visibilitas terpadu (sign-in, token, akses sumber daya, riwayat perubahan) -> siap audit

Matriks Perbandingan (sekilas)

Pola Arsitektur (kasus penggunaan umum)

Menerapkan workload identity memerlukan pemetaan yang tepat terhadap pola arsitektur Anda. Berikut penerapannya pada beban kerja enterprise yang paling umum:

• Konektor Power Platform / cloud flow -> Tetapkan workload identity untuk setiap integrasi; berikan hanya cakupan Graph/Dataverse yang dibutuhkan.
• Aplikasi line-of-business (web API, daemon) -> Pendaftaran aplikasi + sertifikat; gunakan peran aplikasi + Graph hanya-aplikasi; terapkan CA jika memungkinkan.
• Skrip otomasi (Azure Automation, GitHub Actions, DevOps) -> Gunakan federated credential (OIDC), tanpa menyimpan secret.
• Tugas lintas penyewa / B2B -> Gunakan workload identity khusus untuk setiap batas penyewa; isolasi hak akses dan pencatatannya.

Playbook Migrasi (90 hari, minim gangguan)

Menangani ratusan akun layanan lama bisa terasa melelahkan. Karena itu, Anda membutuhkan playbook migrasi terstruktur yang berjalan selama 90 hari dan berfokus pada pengurangan risiko.

Fase 1 — Temukan & Pilah (Minggu 0–3)

1. Inventarisasi sign-in dan objek non-manusia: svc-*, app-*, shared mailbox, pendaftaran aplikasi, secret yang kedaluwarsa dalam <90 hari.
2. Petakan setiap objek ke pemilik, tujuan bisnis, target, izin, dan ketergantungan pada break glass.
3. Peringkat risiko: kata sandi statis, peran global, tanpa pemilik, tanpa rotasi terbaru.

Fase 2 — Konversi Lebih Dulu yang Berisiko Tinggi (Minggu 4–8)

1. Buat workload identity untuk setiap integrasi (jangan digunakan ulang).
2. Ganti autentikasi kata sandi dengan sertifikat atau federated credential; tetapkan rotasi.
3. Beralih ke izin hanya-aplikasi; hapus izin delegasi pengguna yang tidak diperlukan.
4. Terapkan kebijakan Conditional Access untuk sign-in workload (jika didukung).
5. Terapkan tinjauan akses (triwulanan) + kepemilikan di CMDB/ITSM.

Fase 3 — Hentikan & Atur Tata Kelola (Minggu 9–12)

1. Nonaktifkan akun layanan lama; pantau selama 14 hari; kemudian hapus.
2. Terapkan standar pembuatan: penamaan, pemilik, klasifikasi data, dan jadwal tinjauan.
3. Tambahkan peringatan: sign-in anomali, identitas tidak aktif >30/60/90 hari, secret yang akan kedaluwarsa.
4. Tanamkan pemeriksaan identitas ke CI/CD (policy-as-code).

Conditional Access & Izin (pagar pengaman praktis)

Salah satu fitur paling kuat dari platform identitas modern adalah kemampuan menerapkan pagar pengaman yang disesuaikan khusus untuk aktor non-manusia. Dengan memisahkan kebijakan manusia dan workload, Anda mencegah bot memicu peringatan perjalanan mustahil sekaligus tetap memblokir lalu lintas berbahaya.

• Kebijakan terpisah untuk identitas manusia vs. workload; blokir logon interaktif untuk workload.
• Lokasi bernama / pembatasan jaringan untuk akses hanya-aplikasi jika memungkinkan.
• Hak akses berbatas waktu (PIM untuk peran aplikasi jika tersedia; tinjauan akses terjadwal).
• Cakupan: utamakan peran aplikasi / peran spesifik sumber daya dibanding hak tingkat direktori.

Pencatatan & Audit (apa yang ditunjukkan kepada auditor)

Ketika petugas kepatuhan dan auditor datang, mereka tidak lagi menerima spreadsheet atau jaminan lisan tentang siapa yang memiliki akses ke skrip backend. Anda harus mampu membuktikan tata kelola secara instan dengan pencatatan terpusat.

• Pemilik app/workload, tujuan, sensitivitas data
• Log sign-in (sign-in service principal), audiens token, IP, aplikasi klien
• Penetapan peran (siapa yang menyetujui, kapan dikonfirmasi)
• Riwayat kredensial (jenis, rotasi terakhir, kedaluwarsa)
• Siklus hidup: dibuat/diubah/dinonaktifkan/dihapus beserta pelaku perubahan

Dashboard KPI (buktikan peningkatannya)

Untuk menjaga dukungan pimpinan secara berkelanjutan, pantau dan laporkan indikator kinerja utama yang menunjukkan pengurangan risiko identitas non-manusia Anda dari waktu ke waktu.

• % identitas non-manusia dengan pemilik + jadwal tinjauan (target ≥ 95%)
• Akun layanan yatim (target -> 0)
• Secret berusia lebih dari 90 hari (target -> 0; utamakan sertifikat/federated)
• Keluasan peran hanya-aplikasi (jumlah “Directory.ReadWrite.All” -> tren menurun)
• Temuan audit untuk akses non-manusia (kuartal ke kuartal ↓)

Anti-Pola yang Harus Dihilangkan

Saat Anda membersihkan lingkungan, pastikan tim Anda tidak kembali ke kebiasaan lama. Hentikan anti-pola berikut segera:

• Menggunakan ulang satu akun layanan generik untuk banyak sistem
• Menyimpan kata sandi dalam skrip, web.config, atau Key Vault tanpa kebijakan rotasi
• Memberikan Global Admin / Owner “untuk jaga-jaga” agar tugas tetap berjalan
• Pengecualian “sementara” pada CA yang tidak pernah berakhir

Langkah Cepat (minggu ini)

Anda tidak perlu menunggu dimulainya proyek besar untuk mulai meningkatkan postur keamanan Anda. Berikut empat langkah cepat yang dapat Anda jalankan minggu ini:

• Beri tag pada setiap identitas non-manusia dengan Owner, System, Data Class.
• Alihkan satu tugas berisiko tinggi ke federated credentials (GitHub OIDC -> Entra).
• Ganti akun layanan bersama di Power Automate dengan workload identity.
• Buat laporan service principal dengan secret yang akan atau sudah kedaluwarsa; jadwalkan peringatan.

Pertanyaan Umum (jawaban singkat)

Apakah workload identity merusak tugas on-prem lama?
Tidak. Jembatani dengan autentikasi app-only, sertifikat, atau layanan broker, lalu hentikan penggunaan kata sandi secara bertahap.

Bisakah saya menerapkan Conditional Access pada sign-in non-manusia?
Bisa, untuk alur yang didukung (sign-in service principal). Gunakan sinyal jaringan, lokasi, atau perangkat jika relevan, dan blokir sign-in interaktif.

Bagaimana cara menghindari sprawl?
Gunakan satu workload identity per integrasi, bukan per tim. Terapkan penamaan, owner, dan tinjauan saat pembuatan; otomatiskan pembersihan untuk identitas yang tidak aktif.

Bagaimana dengan Power Platform?
Gunakan Service Principals / Workload Identities untuk konektor dan Dataverse; hentikan penggunaan akun pengguna bersama.

Kesimpulan

Anda tidak bisa mengatasi risiko akun layanan hanya dengan rotasi. Entra Workload Identities membawa akses non-manusia ke dalam model Zero Trust, siklus hidup, dan audit yang sama seperti yang sudah Anda tuntut untuk manusia, tanpa gangguan layanan atau upaya heroik. Mulailah dari akun “svc-” yang paling berisiko, ubah menjadi workload identity yang terkelola, dan kembalikan pengecualian menjadi benar-benar pengecualian.

Jika Anda menikmati tulisan ini, jangan lewatkan diskusi lengkapnya di episode podcast kami, Replace Service Accounts with Entra Workload Identities. Berlangganlah ke acara ini untuk pembahasan mendalam lainnya tentang strategi keamanan Microsoft 365 dan Azure di tingkat perusahaan!