Zero Trust Architecture: Worksheet Assessment Praktis
Zero trust bukan pembelian produk atau slogan jaringan. NIST SP 800-207 menjelaskannya sebagai kumpulan paradigma keamanan siber yang berkembang, yang memindahkan fokus dari perimeter jaringan statis ke pengguna, aset, dan resource. Tidak ada trust implisit hanya karena lokasi jaringan atau kepemilikan. Authentication dan authorization untuk subject serta perangkat dilakukan sebelum sesi menuju resource perusahaan. Karena itu assessment harus menguji keputusan pada batas setiap resource, bukan sekadar menanyakan apakah organisasi punya MFA atau VPN.
Worksheet ini menghasilkan bukti untuk scope tertentu, bukan sertifikasi arsitektur. Catat aplikasi, antarmuka administrasi, API, data store, workload, dan layanan pendukung; tandai resource tidak dikelola sebagai celah scope.
Buat inventaris resource
Catat setiap resource dengan owner, tujuan bisnis, sensitivitas data, jalur administrasi, paparan jaringan, dependency, dan mode pemulihan. “Aplikasi internal” bukan identitas yang cukup. Pisahkan resource jika populasi pengguna, permukaan administrasi, kelas data, atau kebijakan aksesnya berbeda. Portal pelanggan, konsol database production, dan dashboard observability memerlukan keputusan terpisah.
Untuk setiap resource, identifikasi subject dan kelas perangkat. Dokumentasikan aksi, protokol, lokasi bila relevan, kekuatan authentication, sinyal perangkat dan risiko, serta aturan sesi. Lokasi dapat menjadi input keputusan, bukan pemberian trust tunggal.
Contoh alur keputusan:
request /admin/export
| subjek: peran finance-admin, MFA tahan phishing
| perangkat: terkelola, terenkripsi, agen keamanan terkini
| kebijakan: change ticket disetujui dan jalur jaringan disetujui
| keputusan: izinkan sesi 30 menit, tanpa unduh file
| bukti: event identitas, hasil posture, versi kebijakan, trace IDUbah kebijakan menjadi keputusan yang dapat diuji
Pernyataan kebijakan harus menjelaskan perilaku saat bukti hilang. “Wajib perangkat compliant” perlu definisi, owner, sumber sinyal, jendela freshness, fallback, dan deny. Izinkan administrator production hanya saat role aktif, MFA terpenuhi, posture baru, perangkat terkelola, dan permintaan menuju layanan administrasi disetujui. Tolak bila sinyal wajib tidak ada. Jalankan break-glass melalui kebijakan berbeda dan berbatas waktu.
Uji input keputusan satu per satu. Hilangkan sinyal device management, pakai posture kedaluwarsa, turunkan role pengguna, ubah resource tujuan, pakai workload identity dengan audience salah, lalu lanjutkan setelah entitlement habis. Hasil yang diharapkan adalah deny atau step-up yang tercatat. Bukti harus mencakup versi kebijakan serta trace keputusan, bukan screenshot saja.
Bukti harus dapat merekonstruksi akses
Kumpulkan artefak: pemohon, resource, perangkat atau workload, kebijakan, dan keputusan. Bukti mencakup event identity provider, conditional access, posture, evaluasi kebijakan, authorization aplikasi, gateway, dan audit resource. Korelasikan dengan ID permintaan atau trace ID stabil. Samarkan data pribadi dan secret.
Ketiadaan bukti juga penting. Bila log resource mengenali user tetapi tidak menyimpan versi kebijakan, keputusan tidak dapat direproduksi setelah kebijakan berubah. Bila gateway mengetahui posture tetapi aplikasi tidak dapat mengenali entitlement, batas authorization mungkin tidak jelas. Tandai sebagai temuan dengan resource terdampak, pernyataan risiko, owner, perbaikan, dan bukti retest.
Pisahkan jalur administrasi
Antarmuka administrasi perlu catatan resource terpisah, authentication lebih kuat, role terbatas, dan sesi pendek. Pisahkan akses control-plane dari penggunaan aplikasi serta permission workload dari administrasi manusia.
Akses break-glass harus sempit, berbatas waktu, dipantau, dan direview. Bukti mencakup identitas eligible, aktivasi, approval atau referensi insiden, sesi, dan pencabutan.
Lembar assessment lengkap
| Resource dan aksi | Input kebijakan wajib | Bukti | Owner | Hasil | Pengecualian atau perbaikan |
|---|---|---|---|---|---|
| konsol admin production: konfigurasi | role aktif, MFA kuat, perangkat terkelola, sesi pendek | ekspor kebijakan, uji perangkat kedaluwarsa ditolak, log sesi | owner sistem | Pass/Fail | tambah claim perangkat; tanggal retest |
| API payroll: baca data | identitas service, audience, kebijakan workload | claim token, audit API, audience salah ditolak | owner API | Pass/Fail | batasi role service |
| document store: unduh | entitlement user, perangkat disetujui, aturan unduh | event akses, hasil posture, trace kebijakan | owner data | Pass/Fail | definisikan kebijakan aksi data |
| akses darurat: recovery | role eligible, catatan aktivasi, expiry | log aktivasi, log sesi, catatan review | owner insiden | Pass/Fail | hapus standing privilege |
Entri lengkap menyebut versi kebijakan, bukti, tanggal uji, penguji, owner, dan hasil. Pass berarti keputusan sesuai untuk permintaan dan konteks tertentu. Fail berarti aturan tidak ada, dapat dibypass, tidak terlihat, atau hasilnya salah. Pengecualian perlu alasan bisnis, kontrol kompensasi, approver, masa berlaku, dan owner perbaikan.
Nilai rollout per irisan
Jangan menyatakan seluruh organisasi sudah zero trust karena satu aplikasi memiliki conditional access. Mulai dari resource bernilai tinggi, petakan dependency, tulis kebijakan, jalankan uji allow dan deny, kumpulkan bukti, lalu ukur kegagalan operasional. Periksa pemulihan help desk, penggantian perangkat, onboarding kontraktor, rotasi service account, dan respons insiden. Kebijakan yang ketat secara teknis tetapi tanpa jalur pemulihan dapat mendorong workaround tidak aman.
Model NIST berpusat pada resource, bukan segmen jaringan. Segmentasi jaringan tetap berguna, tetapi tidak menggantikan kebijakan per resource. MFA, endpoint management, identity federation, proxy, dan logging dapat berkontribusi, tetapi tidak satu pun sendiri adalah zero trust. Kualitas keputusan datang dari syarat yang jelas, kebijakan yang bisa ditegakkan, bukti yang terlihat, serta review saat konteks berubah.
Pertanyaan buyer
Minta inventaris resource, matriks kebijakan, definisi sinyal identitas dan perangkat, trace keputusan akses, catatan uji deny, register pengecualian, dan tracker perbaikan. Tanyakan bagaimana workload identity dibedakan dari identitas manusia dan bagaimana resource administrasi dibedakan dari penggunaan aplikasi biasa. Tanyakan apa yang terjadi saat layanan posture, identity provider, atau telemetry tidak tersedia.
Tutup dengan catatan assessment: scope, daftar resource, versi kebijakan, bukti, uji, hasil pass/fail, pengecualian, owner perbaikan, dan pemicu retest. Nilai ulang saat resource, sumber identitas, aturan device management, atau jalur authorization berubah.
Simpan input keputusan
Untuk setiap uji allow atau deny, simpan versi objek kebijakan, set claim identitas dengan nilai sensitif tersamarkan, waktu posture perangkat, identifier resource target, hasil evaluator, dan event audit resource. Catat terpisah perilaku saat evaluator outage: deny, akses terbatas, atau break-glass disetujui. Keputusan akses yang dapat direproduksi membuat reviewer membedakan kegagalan kebijakan dari telemetry hilang dan mencegah fallback berbasis lokasi menjadi trust tanpa catatan.