Mengapa Checklist, Bukan Penetration Test Saja
Penetration test penting, tetapi ia memotret kondisi pada satu titik waktu. Checklist kontrol justru membangun disiplin harian: setiap pull request, setiap rilis, setiap perubahan konfigurasi lolos gerbang yang sama. Checklist ini kami distilasi dari standar OWASP ASVS level 2 dan pengalaman mendampingi go-live sistem keuangan multi-cabang yang memproses ribuan e-invoice per bulan - termasuk temuan yang paling sering muncul di minggu-minggu menjelang rilis.
Cara pakai: setiap butir harus punya jawaban konkret (“ya, dibuktikan dengan X” atau “tidak berlaku karena Y”). Butir tanpa pemilik jelas dianggap gagal.
A. Identitas dan Akses (1–7)
- SSO / IdP terpusat - autentikasi terhubung ke penyedia identitas (Azure AD, Google Workspace) sehingga offboarding karyawan otomatis mencabut akses.
- MFA untuk semua role internal - minimal TOTP; untuk role keuangan wajib. Sistem approval yang kami bangun mewajibkan OTP kedua untuk aksi beresiko tinggi.
- Prinsip least privilege - role dibangun dari matriks RBAC tertulis, bukan dari salin-tempel role admin.
- Rotasi kredensial otomatis - API key dan secret database punya umur maksimal 90 hari, disimpan di secret manager, bukan di file .env yang ikut repo.
- Lockout dan rate limit login - 5 percobaan gagal memicu cooldown eksponensial; endpoint login dilindungi rate limiter terpisah.
- Sesi punya umur dan bisa dicabut - refresh token berotasi, logout benar-benar mematikan sesi di server.
- Audit trail akses admin - setiap login dan aksi admin tercatat dengan IP, waktu, dan target; log tidak bisa dihapus dari aplikasi.
B. Keamanan Aplikasi (8–15)
- Validasi di sisi server untuk semua input - validasi frontend hanyalah kenyamanan; keputusan akhir selalu di server.
- Query berparameter penuh - nol string concatenation SQL; ORM bukan jaminan bila raw query masih dipakai di laporan.
- Output encoding kontekstual - anti-XSS diterapkan sesuai konteks (HTML, atribut, JS), termasuk untuk konten rich-text dari CMS.
- Otorisasi diperiksa per objek - IDOR ditutup dengan policy per-record: user hanya menyentuh data miliknya, diuji dengan akun biasa mencoba akses ID orang lain.
- Upload divalidasi total - tipe file, ukuran, re-naming, penyimpanan di luar webroot, dan tidak pernah dieksekusi.
- Dependency di-scan otomatis - composer audit / npm audit berjalan di CI; CVE critical memblokir rilis.
- Headers keamanan terpasang - CSP, HSTS, X-Frame-Options, Referrer-Policy diverifikasi lewat scanner.
- Endpoint admin tidak “tersembunyi” - dilindungi otorisasi eksplisit, bukan sekadar URL yang tidak dipublikasikan.
C. Perlindungan Data (16–20)
- TLS 1.2+ di semua jalur - termasuk antar-service internal; sertifikat diperbarui otomatis.
- Enkripsi at-rest - database dan object storage terenkripsi; kunci dikelola KMS, tidak berada di server yang sama dengan datanya.
- Data sensitif diminimalkan - nomor kartu dan kredensial tidak pernah di-log; field yang tidak wajib tidak dikumpulkan.
- Backup teruji restore-nya - backup harian dengan uji restore bulanan; backup yang belum pernah direstore adalah hipotesis.
- Retensi dan penghapusan terdefinisi - data ex-klien bisa dihapus menyeluruh sesuai perjanjian.
D. Infrastruktur dan Operasi (21–25)
- Hardening server dasar - SSH tanpa password, firewall default-deny, patch otomatis untuk CVE critical.
- Pemisahan environment - produksi tidak pernah berbagi kredensial dengan staging; akses produksi via bastion ber-MFA.
- Monitoring dan alerting aktif - error rate, latency, dan login anomaly memicu notifikasi dalam hitungan menit, bukan ditemukan sepekan kemudian.
- Rencana insiden tertulis - siapa dihubungi, siapa memutuskan rollback, bagaimana komunikasi ke klien.
- Rollback yang pernah dijalankan - uji rollback di staging menjelang rilis; tombol yang belum pernah ditekan bukan tombol.
Keamanan yang baik terasa membosankan: tidak ada drama, tidak ada temuan mendadak, hanya gerbang yang lolos satu per satu.
Cara Menjalankan Checklist dalam Tim
Checklist bernilai dari cara ia dieksekusi. Pola yang kami pakai: satu pemilik per butir, ditulis di kolom paling kanan - bukti kepatuhan berupa link ke konfigurasi, screenshot, atau hasil test, bukan klaim lisan. Butir A1–A7 dan C16–C20 biasanya milik backend lead dan DevOps; B8–B15 dibagi per area fitur; D21–D25 milik infrastruktur. Seluruh checklist direview bersama dalam satu sesi 90 menit dua minggu sebelum rilis, dengan aturan sederhana: butir tanpa bukti diperlakukan gagal, dan kegagalan kategori A serta C16–C18 adalah pemblokir go-live, sisanya boleh dinegosiasikan dengan mitigasi tertulis.
Dua hal yang mempercepat eksekusi drastis: mulai checklist ini sejak sprint pertama (bukan H-14), dan otomatisasi butir yang bisa - dependency scan, security headers, dan rate limit dapat diverifikasi CI sehingga manusia hanya memeriksa yang memang butuh penilaian.
Tiga Temuan Paling Sering Muncul
Jika kami harus bertaruh, tiga temuan ini akan muncul di hampir setiap review pra-rilis. Pertama, IDOR pada endpoint detail - aplikasi berfungsi normal untuk pengguna sah, tetapi mengganti ID di URL memunculkan data orang lain; selalu uji dengan dua akun berbeda. Kedua, secret yang pernah masuk git - kredensial staging ter-commit bulan lalu; rotasi wajib meski sudah dihapus, karena history repo tidak pernah benar-benar hilang. Ketiga, backup yang belum pernah direstore - semuanya yakin backup berjalan; hampir tak pernah ada yang bisa menunjukkan bukti restore sukses. Ketiganya murah diperbaiki sebelum rilis, dan sangat mahal setelahnya.
| Tingkat Temuan | Contoh | Sikap Go-Live |
|---|---|---|
| Pemblokir | Kebocoran data antar-user, secret bocor aktif | Tunda rilis |
| Beresiko | MFA belum jalan untuk satu role internal | Rilis + deadline 7 hari |
| Perbaikan | Header CSP belum ketat penuh | Rilis + masuk sprint berikut |
Menempelkan Checklist ke Siklus Pengembangan
Checklist paling sering gagal bukan karena butirnya salah, melainkan karena ia hidup sebagai dokumen terpisah dari pekerjaan sehari-hari. Cara menempelkannya ke siklus: butir aplikasi (B8–B15) menjadi bagian Definition of Done tiap fitur - reviewer menolak pull request yang menambah endpoint tanpa otorisasi per objek atau input validation; butir infrastruktur (D21–D25) dikodifikasi sebagai infrastructure-as-code sehingga server baru otomatis lahir hardened, dan kepatuhan tidak lagi bergantung pada ingatan; butir identitas dan data diverifikasi sekali di awal proyek lalu diuji ulang tiap ada perubahan arsitektur auth. Dengan pola ini, sesi review 90 menit pra-rilis tinggal memverifikasi - bukan menemukan dari nol.
Bila tim Anda menggunakan sprint, tambahkan satu tiket berulang “security gate” di sprint terakhir sebelum rilis besar. Tiket yang sama berulang setiap rilis menciptakan muscle memory: butir yang relevan makin cepat dicek, dan temuan baru semakin jarang.
30 Hari Pertama Pasca Go-Live
Keamanan tidak berhenti di tombol rilis. Sebulan pertama pasca go-live adalah periode pembelajaran penting - manfaatkan dengan tiga rutinitas. Pekan 1: tinjau harian log autentikasi dan error rate; pola aneh (lonjakan login gagal, akses dari wilayah tak wajar) paling mudah ditangkap saat baseline masih segar. Pekan 2–3: jalankan vulnerability scan eksternal pertama dan bandingkan dengan hasil pra-rilis - regresi konfigurasi sering terjadi karena perbaikan darurat rilis. Pekan 4: tutup bulan dengan retro keamanan singkat: temuan apa yang lolos checklist, mana kontrol yang ternyata mengganggu operasi (dan justru mendorong orang mencari jalan pintas), lalu perbarui checklist versi berikutnya. Checklist ini dokumen hidup - versi terbaiknya selalu hasil iterasi pertama Anda sendiri.
Penutup
Dua puluh lima kontrol ini bukan daftar sempurna, tetapi ia menutup 90% temuan yang biasanya muncul di audit pra-rilis sistem enterprise. Jadikan ia bagian dari Definition of Done tim Anda, bukan dokumen yang dibuka saat audit. Bila Anda ingin sesi review checklist terhadap aplikasi yang akan go-live - dengan prioritas perbaikan yang jelas - hubungi Ayah2Ngoding di hello@ayah2ngoding.com.
Diskusi & Komentar (0)