Belajar Solution Architect - Security Solution Design

#Pendahuluan

Setelah di episode 7 kalian bisa merancang lapisan data yang sehat — storage dipilih dari pola akses, analitik terpisah dari OLTP, cache terencana — kini kita bahas dimensi yang tidak boleh jadi renungan belakangan: security. Bukan karena idealisme, tetapi karena ekonominya: kontrol keamanan yang ditambahkan saat desain harganya menit; yang ditambahkan setelah insiden harganya reputasi, denda, dan minggu-minggu remediasi.

Mengapa security sering gagal di solusi nyata? Karena diperlakukan sebagai checklist di akhir ("sudah pakai HTTPS kan?") alih-alih properti desain. Pada episode ini kita membangun kerangka berpikir security-in-design; pendalaman arsitektur berlapisnya menyusul di episode 18, dan compliance formalnya di episode 19.

#Threat Modeling Ringkas

Sebelum menambahkan kontrol apa pun, jawab tiga pertanyaan: apa aset yang dilindungi, siapa penyerang potensial, dan dari mana mereka masuk? Kerangka paling praktis adalah STRIDE — enam kategori ancaman yang dipetakan ke kontrol:

Ancaman (STRIDE)	Contoh pada Studi Kasus Tiket	Kontrol Desain
Spoofing	Penipuan login akun panitia	MFA wajib, session aman
Tampering	Ubah harga tiket di request checkout	Tanda tangan payload, validasi sisi server
Repudiation	Panitia menyangkal pernah memvalidasi tiket palsu	Audit log append-only
Information disclosure	Data pembeli bocor dari dump database	Enkripsi at rest, minimalkan PII
Denial of service	Banjir request di window sale	Rate limiting, WAF, autoscaling
Elevation of privilege	Service biasa membaca tabel pembayaran	IAM granular least privilege

Latihan yang saya sarankan: ambil diagram solusi kalian, telusuri tiap panah dan kotak, tanyakan keenam kata itu satu per satu, tulis temuannya. Satu jam threat modeling di awal menghasilkan daftar kontrol konkret — jauh lebih produktif daripada "pasang firewall semua".

#Enkripsi: In Transit dan At Rest

Dua fondasi yang tidak bisa dinegosiasikan di solusi modern:

In transit — TLS 1.2+ untuk semua jalur: user ke edge, service ke service internal pun. "Jaringan internal kami aman" adalah asumsi yang sudah berkali-kali terbukti salah (lateral movement). Di dalam VPC gunakan mTLS atau minimal TLS antar-service.
At rest — semua storage dienkripsi: database (KMS/cloud KMS), object storage, snapshot, backup, log sensitif.

Detail desain yang sering terlewat:

Siapa pemegang key? Gunakan managed KMS provider dengan key yang bisa dirotasi; hindari key hard-coded yang mustahil diganti.
Enkripsi field-level untuk data sangat sensitif (nomor kartu, NIK) — sehingga bocornya backup atau log tidak langsung membocorkan isinya.
Data minimization: pertanyaan security terbaik kadang bukan "bagaimana melindunginya" melainkan "apakah perlu disimpan?" — tokenisasi pembayaran lewat gateway menghilangkan kebutuhan menyimpan kartu sama sekali (sekaligus menyelesaikan PCI scope).

Keputusan enkripsi studi kasus tiket

In transit : TLS 1.3 di edge (CDN/LB), mTLS antar-service internal
At rest    : RDS + S3 + Redis terenkripsi CMK KMS, rotasi tahunan
Field      : nomor kartu TIDAK disimpan (token gateway pembayaran)
             QR tiket = JWT bertanda tangan, tanpa data PII di payload

#Manajemen Secret

Secret (password DB, API key partner, kredensial SMTP) butuh perlakuan khusus:

Simpan di secret manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) — bukan environment variable yang ikut ter-dump di crash report, apalagi file .env yang ter-commit.
Rotasi otomatis berkala; aplikasi harus sanggup mengambil ulang secret saat runtime, bukan sekali saat boot.
Audit akses: siapa membaca secret apa dan kapan.

Contoh pola pengambilan secret runtime (AWS)

aws secretsmanager get-secret-value \
  --secret-id prod/ticket/db-password \
  --query SecretString --output text

Perintah semacam ini dieksekusi oleh platform/service account saat deploy atau via sidecar — bukan oleh developer yang menyalin hasilnya ke file konfigurasi.

#Identity & Least Privilege

Dua populasi identitas dalam solusi kalian, dua perlakuan:

#Identitas Manusia

SSO/MFA untuk semua akses administratif; tidak ada akun lokal terpisah per sistem.
Akses produksi via break-glass procedure: diminta, disetujui, dicatat, kedaluwarsa otomatis. SSH langsung ke server production sebagai rutinitas adalah red flag arsitektur.

#Identitas Service

Ini yang paling sering bocor. Setiap service punya identitas sendiri (IAM role, workload identity) dengan izin minimum yang dibutuhkan — bukan satu role besar dipakai semua. Bandingkan:

IAM policy buruk vs baik (potongan)

// BURUK: satu policy luas untuk semua service
{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" }
 
// BAIK: service tiket hanya boleh baca bucket poster
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::ticket-assets/posters/*"
}

Policy kedua membatasi dampak saat service tersebut dikompromikan: penyerang mendapat akses baca poster, bukan seluruh bucket. Prinsip yang sama berlaku di database (user aplikasi vs user migrasi), message broker, dan API internal.

Tip

Uji cepat least privilege: untuk setiap service, tanyakan "kalau kredensialnya bocor sekarang, apa maksimal kerusakan yang mungkin?" Kalau jawabannya "semua", perkecil lingkupnya sebelum production.

#Kontrol Lapisan Aplikasi

Di atas fondasi tadi, beberapa kontrol yang wajib ada di level desain aplikasi:

Authentication & authorization terpisah rapi: authN menjawab "siapa kamu", authZ menjawab "bolehkah kamu". Jangan campur keduanya di middleware tunggal.
Rate limiting bertingkat: global di WAF/gateway, per-user di aplikasi, plus limit khusus endpoint mahal (search, export).
Input validation di boundary: validasi ketat pada semua input eksternal (schema validation), output encoding saat render — fondasi anti injection/XSS.
Audit log append-only: kejadian penting (login, ubah harga, refund) dicatat dengan aktor dan waktu, tidak bisa diedit/dihapus oleh aplikasi.
Dependency hygiene: lockfile ter-audit (misal npm audit/ Dependabot), image base minimal, SBOM sederhana untuk traceability.

Untuk referensi teknis web application, OWASP Top 10 dan OWASP ASVS adalah checklist gratis terbaik — gunakan ASVS level sesuai sensitivitas solusi saat review.

#Security sebagai Bagian SDD

Tutup episode ini dengan mengisi bagian baru di template SDD kalian:

Bagian security di SDD (tambahan template episode 2)

Aset kritis     : data pembayaran, PII pembeli, kredensial panitia
Ancaman utama   : DoS saat sale, credential stuffing, insider tampering
Kontrol         : (ringkas per STRIDE - lihat tabel threat model)
Residu & rencana: pen-test eksternal pra-launch, bug bounty pasca-launch

Bagian inilah yang akan dibaca reviewer security — dan yang menyelamatkan kalian saat pertanyaan "kenapa tidak pakai X?" datang: jawabannya sudah tertulis sebagai keputusan dengan alasannya.

#Penutup

Inti yang harus dibawa pulang:

Security mulai dari threat modeling: aset → ancaman (STRIDE) → kontrol, tertulis sebelum kode.
Enkripsi ganda non-negosiable: TLS di semua jalur termasuk internal, at rest di semua storage; pertimbangkan field-level untuk data super sensitif dan minimalkan apa yang disimpan.
Secret hidup di secret manager dengan rotasi; service identity ber-principle least privilege dengan blast radius kecil.
Kontrol aplikasi: authN/authZ terpisah, rate limiting bertingkat, audit log append-only, dependency hygiene.
Semua kontrol itu didokumentasikan di SDD sebagai keputusan, bukan tersimpan di kepala.

Di episode 9 selanjutnya kita akan membahas cost & budget solution — cara menghitung TCO secara jujur, memahami pricing model cloud (on-demand, reserved, spot), dan teknik desain yang ramah budget tanpa mengorbankan reliability target kalian. Sampai jumpa di episode 9!