Belajar System Analyst - Security Requirements Analysis
Sistem yang memegang uang dan data pelanggan wajib aman sejak desain. Episode ini membahas cara menangkap security requirements sejak fase analisis — kerangka CIA, pendekatan STRIDE, dan menerjemahkan OWASP menjadi requirement konkret — dipraktikkan menjadi security specification lengkap untuk POS TokoKita
#Pendahuluan
Setelah di episode 17 pengetahuan proyek TokoKita ditransfer rapi lewat docs hub dan handover, kita membuka fase baru series ini: sistem yang layak secara keamanan dan kepatuhan. Episode ini membahas security requirements analysis — menangkap kebutuhan keamanan sejak fase analisis, bukan setelah insiden.
Mengapa ini ranah SA? Karena keamanan bukan sekadar teknologi enkripsi, melainkan persyaratan perilaku sistem: siapa boleh melakukan apa, data mana yang sensitif, apa yang terjadi saat autentikasi gagal. Developer mengimplementasikan kontrol keamanan; tetapi hanya analisis yang tahu aset apa yang dilindungi dan dari siapa. Requirement keamanan yang tidak tertulis tidak akan dibangun — dan biaya menambatkannya belakangan naik berlipat-lipat dibanding merancangnya sejak awal.
#Fondasi: Aset, Ancaman, Kontrol
Analisis keamanan dimulai dari tiga pertanyaan berurutan:
Untuk TokoKita, inventaris asetnya jelas:
| Aset | Nilai Bila Bocor/Rusak | Pemilik |
|---|---|---|
| Data transaksi & uang digital | Kerugian finansial langsung, rekonsiliasi kacau | Owner |
| Kredensial kasir & PIN manajer | Transaksi palsu, diskon liar | Owner/manajer cabang |
| Data member & kontak pelanggan | Pelanggaran privasi, kepercayaan hancur | Owner (dijamin SA) |
| Kunci integrasi QRIS & HMAC | Pembayaran dipalsukan | Vendor + tim dev |
Tiga pilar yang menjaga aset itu sering disingkat CIA: Confidentiality (hanya yang berhak bisa baca), Integrity (data tidak bisa diubah diam-diam), Availability (tersedia saat dibutuhkan — ingat NFR uptime episode 4). Tiap kebutuhan keamanan yang kalian tulis akan melayani satu atau lebih pilar ini; kalimat "supaya lebih aman" tanpa menyebut pilarnya adalah requirement kosong.
#Model Ancaman dengan STRIDE
STRIDE adalah lensa klasik untuk membedah tiap komponen sistem: Spoofing (menyamar jadi kasir), Tampering (mengubah angka stok), Repudiation (menyangkal pernah transaksi), Information disclosure (membaca data orang lain), Denial of service (melumpuhkan kasir), Elevation of privilege (kasir memberi dirinya hak manajer).
Cara pakainya sederhana: ambil satu alur — misal sinkronisasi offline INT-01/INT-02 dari episode 13 — lalu tanya keenam pertanyaan itu. Hasilnya langsung menjadi draf requirement: callback QRIS butuh signature (anti-spoof), audit log append-only (anti-tamper-repudiation), rate limit endpoint sync (anti-DoS). Tidak perlu jadi security engineer untuk memulai percakapan ini — cukup disiplin bertanya.
#Dari OWASP ke Requirement Konkret
OWASP Top 10 adalah daftar risiko keamanan aplikasi web paling umum. Untuk analyst, ia berguna sebagai checklist pertanyaan elicitation, bukan materi hafalan teknis:
| Risiko OWASP Umum | Pertanyaan Analisis | Requirement Lahir |
|---|---|---|
| Broken access control | Kasir boleh lihat data cabang lain? | SEC-03 isolasi data per tenant/cabang |
| Cryptographic failures | Data apa yang wajib terenkripsi di mana? | SEC-05 TLS transit + at-rest DB pusat |
| Injection | Input manual kode barang bebas bentuk apa saja? | SEC-07 validasi ketat semua input |
| Broken authentication | Bagaimana sesi kasir dijaga saat ganti shift? | SEC-01 lock otomatis akhir shift |
| Security logging failure | Insiden bisa direkonstruksi? | SEC-09 audit log append-only |
Praktiknya dalam wawancara pun sederhana: saat stakeholder mendeskripsikan proses, sisipkan pertanyaan penyusup — "bagaimana kalau mantan kasir mencoba login minggu depan?", "kalau dua kasir pakai akun sama, siapa yang disalahkan?". Jawaban mereka (atau keheningannya) adalah requirement mentah.
#Praktik: Security Specification TokoKita
Hasil analisis dikompilasi ke 03-design/security-spec.md — requirement bernomor, masing-masing dengan pilar CIA dan kriteria verifikasinya:
# Security Specification - TokoKita v1.0
## Identitas & Akses
SEC-01 [Integrity] Setiap kasir punya akun individual;
sesi terkunci otomatis saat tutup shift.
Verifikasi: TC-N03 audit log menunjukkan pemilik
aksi tunggal per transaksi.
SEC-02 [Confidentiality] Operasi sensitif (edit harga,
approval diskon > 10%, penyesuaian stok) wajib
PIN/kode manajer kedua.
Verifikasi: UAT scenario approval ditolak tanpa PIN.
SEC-03 [Confidentiality] Isolasi data antar cabang:
user cabang A tak dapat membaca transaksi cabang B;
agregat lintas-cabang hanya via role owner.
Verifikasi: test akses silang dengan token cabang A.
## Perlindungan Data
SEC-04 [Integrity] Callback gateway QRIS diverifikasi
HMAC signature; payload tanpa signature valid
ditolak dan dicatat.
SEC-05 [Confidentiality] TLS 1.2+ wajib untuk semua
komunikasi; database pusat terenkripsi at-rest.
SEC-06 [Integrity] Nominal & qty dikirim dengan checksum
pada sinkronisasi batch; mismatch = quarantined.
## Ketahanan & Jejak
SEC-07 [Semua] Semua input divalidasi server-side
(whitelist format SKU, nominal numerik positif).
SEC-08 [Availability] Rate limit endpoint publik
(login: 5 percobaan/menit/IP) + alert.
SEC-09 [Integrity+Repudiation] Audit log append-only:
user-waktu-aksi-detail; tak dapat diedit/dihapus
oleh role aplikasi mana pun.
SEC-10 [Availability] Backup harian DB pusat,
retensi 90 hari, restore diuji bulanan.Perhatikan pola setiap butir: pilar eksplisit, perilaku spesifik, cara verifikasi. Itulah yang membedakan requirement keamanan dari slogan keamanan. SEC-02 juga menunjukkan bagaimana keputusan bisnis episode 10 (koridor diskon Bu Rina) berevolusi menjadi kontrol teknis — keamanan selalu lahir dari konteks proses.
Important
Seimbangkan keamanan dengan operasional: PIN manajer untuk setiap transaksi akan membuat kasir menulis PIN di meja kasir. Ukur friksi setiap kontrol — kontrol yang dilewati pengguna bukan kontrol, melainkan teater keamanan. Selalu uji dengan skenario jam sibuk.
#Non-Functional Meets Security
Beberapa requirement keamanan sudah kita tanam diam-diam di episode-episode awal — sekarang mereka resmi masuk daftar: mode offline (SEC terkait availability, TC-N01), UUID idempotent anti-duplikasi (integrity sinkronisasi), soft-delete produk (jejak referensi). Ini bukti bahwa keamanan bukan babak terakhir, melainkan benang merah analisis.
#Kesalahan Umum
- Keamanan sebagai fase akhir — "nanti di-audit sebelum rilis." Audit menemukan cacat; memperbaiki arsitektur pasca-build mahal. Analisis sejak awal menemukan kebutuhan; audit kemudian hanya memverifikasi.
- Menyalin checklist tanpa konteks — menerapkan seluruh kontrol enterprise ke warung 12 cabang menghasilkan sistem tak terpakai. Skala kontrol ikut skala risiko dan kapasitas organisasi.
- Asumsi insider jujur sepenuhnya — mayoritas kebocoran data kecil melibatkan internal. Kontrol seperti SEC-01 (akun individual) justru melindungi kasir jujur dari tuduhan salah alamat.
- Lupa jalur fisik — tablet kasir dicuri, printer struk menyimpan salinan, lembar cheat sheet PIN ditempel meja. Requirement keamanan mencakup prosedur fisik: auto-lock, remote wipe, rotasi PIN berkala.
- Tanpa rencana respons — keamanan bukan cuma mencegah; siapkan runbook insiden: siapa dihubungi, data mana dievaluasi, kapan pelanggan/pemilik diberi tahu. Ini jembatan langsung ke topik compliance episode berikutnya.
Tip
Latihan STRIDE cepat: ambil alur retur barang TokoKita, jawab enam pertanyaan STRIDE satu per satu, dan hasilkan minimal tiga draf requirement keamanan. Bandingkan dengan security-spec di atas — celah yang kalian temukan di luar daftar adalah tanda analisis kalian mulai matang.
#Penutup
Inti yang harus dibawa pulang:
- Keamanan adalah requirement perilaku sistem yang lahir dari analisis aset-ancaman-kontrol; tanpa tertulis, tidak akan dibangun.
- Lensa CIA menjaga makna tiap requirement; STRIDE membedah alur sistem enam arah; OWASP Top 10 dipakai sebagai checklist pertanyaan elicitation.
- Security spec TokoKita berisi 10 requirement bernomor dengan pilar dan verifikasi eksplisit — dari akun individual sampai audit log append-only.
- Kontrol harus diimbangi friksi operasional; kontrol yang dilewati pengguna hanyalah teater keamanan.
Sistem kini aman secara desain — tetapi aman bagi siapa menurut aturan siapa? Di episode 19 selanjutnya kita membahas compliance & governance: memetakan regulasi yang relevan bagi TokoKita (termasuk undang-undang perlindungan data Indonesia), menyusun compliance map, dan membangun tata kelola supaya kepatuhan bukan proyek sekali-jalan. Pastikan tetap semangat!