Belajar Solution Architect - Compliance Solution

#Pendahuluan

Setelah di episode 18 kalian bisa menyusun pertahanan berlapis dengan identitas zero trust dan deteksi threat-informed, kini kita bahas dimensi yang mengubah semua kontrol itu dari "praktik baik" menjadi kewajiban yang dibuktikan: compliance. Regulasi perlindungan data (UU PDP di Indonesia, GDPR di Eropa), standar kartu pembayaran (PCI-DSS), sampai sertifikasi organisasi (ISO 27001, SOC 2) semuanya bermuara ke pertanyaan sama: bisakah kalian membuktikan sistem berjalan sesuai aturan?

Peran SA di sini unik: bukan compliance officer yang membaca pasal, juga bukan engineer yang hanya eksekusi. Kalian adalah penerjemah dua arah — pasal regulasi menjadi kontrol teknis, dan realitas teknis menjadi evidence yang bisa diaudit. Penerjemahan ini dilakukan di fase desain, karena retrofit compliance ke sistem jadi selalu 5-10x lebih mahal.

#Dari Pasal ke Kontrol Teknis

Regulasi ditulis abstrak; tugas kalian membuatnya konkret. Contoh penerjemahan UU PDP untuk studi kasus tiket:

Metode kerja yang saya rekomendasikan: ambil regulasi yang berlaku → daftar prinsip/kewajibannya → untuk tiap baris tulis kontrol eksplisit atau nyatakan gap. Hasilnya adalah gap assessment ringkas satu-dua halaman — dokumen paling berharga di awal proyek yang menyentuh data pribadi, sebelum satu baris skema ditulis.

#Peta Regulasi Umum

Empat keluarga yang paling sering muncul dalam brief solusi:

• Data protection (PDP/GDPR) — fokus pada PII: legal basis, hak subjek data, notifikasi breach, transfer lintas negara. Berlaku hampir untuk setiap solusi konsumen.
• PCI-DSS — standar keamanan data kartu. Insight arsitektur terpenting: scope reduction — jika kartu ditokenisasi lewat gateway, mayoritas sistem kalian keluar dari scope PCI; itulah kenapa keputusan episode 8 (tidak menyimpan kartu) bernilai compliance besar.
• ISO 27001 / SOC 2 — kerangka manajemen keamanan organisasi; solusi kalian akan ditarik ke dalam scope auditnya, jadi siapkan bukti kontrol.
• Sektor spesifik — OJK untuk fintech, Kemenkes untuk health data, dsb. Selalu tanyakan di discovery: regulasi sektor apa yang mengikat klien?

Catatan penting lintas-batas: residency data. Kalau regulasi mensyaratkan data tertentu tinggal di Indonesia, region deployment (episode 5) dan lokasi replika DR (episode 15) harus konsisten dengan itu — dua keputusan arsitektur yang tiba-tiba saling berkaitan lewat compliance.

#Evidence Pipeline: Bukti yang Terotomasi

Kesakitan klasik audit: tim berharian mencari screenshot konfigurasi selama dua minggu. Solusi modernnya adalah evidence pipeline — bukti dikumpulkan otomatis oleh sistem, kontinu:

Kontrol                        Sumber Bukti Otomatis
Enkripsi at rest aktif         Config audit harian (AWS Config rule)
IAM tanpa wildcard prod        Policy scanner CI + IaC lint
MFA wajib akun admin           Identity report mingguan
Backup terjadwal & di-restorasi Job history + hasil restore test
Akses produksi via JIT         Log sesi + approval record
Patch dependency critical      Laporan scanner pipeline per rilis

Tiga prinsip membangunnya:

1. Bukti lahir bersama kontrol — saat mendesain kontrol di IaC/pipeline, tentukan sekalian artefak auditnya (log, report, snapshot config).
2. Kontinu > periodik — config rule dan scanner berjalan tiap commit/hari, bukan kumpul manual tiap audit tahunan.
3. Retensi bukti disiplin — simpan sesuai periode audit (biasanya 1 tahun rolling) dengan akses terkontrol.

Alat pendukungnya melimpah (AWS Config/Audit Manager, Azure Policy, GCP Assured Workloads, atau compliance-as-code open source), tetapi prinsipnya lebih penting daripada produk: audit adalah query terhadap bukti, dan bukti harus sudah ada sebelum auditor datang.

#Merancang agar Lolos Audit

Beberapa praktik desain yang membuat audit berjalan tenang:

• Audit trail append-only untuk aksi sensitif — siapa mengubah harga, merilis refund, mengubah IAM. Log ini sendiri tidak boleh bisa diedit/dihapus aplikasi.
• Separation of duties — orang yang menyetujui perubahan ≠ yang mengeksekusi (terlihat di approval record pipeline); developer tidak punya izin langsung ke produksi.
• Change management otomatis — pull request + review + pipeline adalah prosedur perubahan resmi; dokumentasikan bahwa inilah mekanismenya, sehingga tiap rilis punya jejak lengkap tanpa formulir tambahan.
• Data classification di level skema — tag kolom PII/sensitif sejak awal (metadata tabel/katalog data); ia menjadi dasar kontrol akses, retensi, dan jawaban cepat saat audit menanya "di mana data pribadi tersimpan?".
• Vendor & sub-processor list — layanan pihak ketiga yang menyentuh data (email gateway, analytics) dicatat dengan basis hukumnya; pertanyaan audit yang pasti.

#Retensi dan Siklus Hidup Data

Compliance menuntut dua arah sekaligus: simpan cukup lama (audit, pajak) tapi hapus tepat waktu (privasi). Rancang retention matrix per kelas data:

Transaksi & faktur   : 10 tahun   (kewajiban pajak) -> arsip dingin
Log aplikasi         : 90 hari    -> auto-delete
Audit trail akses    : 1 tahun    -> immutable store
PII profil pembeli   : sampai akun dihapus + 30 hari grace -> purge job
Data analitik        : agregat tanpa PII, tanpa batas

Teknisnya sudah kalian punya dari episode 7: partitioning per bulan agar purging = drop partisi, object lifecycle policy untuk arsip/hapus otomatis, dan purge job yang juga menyentuh backup (atau minimal mendokumentasikan kapan backup lama berisi data tersebut kedaluwarsa — pertanyaan auditor yang cerdas).

#Menyeimbangkan Compliance dan Kecepatan

Terakhir, sudut pandang SA: compliance bukan alasan melambat jika didesain benar.

• Shift left — kontrol sebagai kode (policy di IaC, scanner di CI) berarti temuan muncul di menit pertama, bukan di audit setahun kemudian.
• Golden path — template infrastruktur yang sudah compliant-by-default; tim yang mengikuti template otomatis patuh. Ini cara paling efektif membuat kepatuhan murah secara psikologis.
• Risk-based prioritization — tidak semua kontrol sama mahal-nilainya; sepakati dengan compliance officer mana yang blocking dan mana yang dapat dijadwalkan.
• Exception process formal — ketidakpatuhan sementara boleh, asal direkam: risiko, mitigasi sementara, owner, tanggal kadaluarsa. Exception diam-diam adalah bom audit.

#Penutup

Inti yang harus dibawa pulang:

• SA menerjemahkan pasal regulasi menjadi kontrol teknis konkret lewat gap assessment sejak fase desain; retrofit selalu mahal.
• Kenali empat keluarga utama (data protection, PCI-DSS, ISO/SOC, sektor) — dan gunakan scope reduction (tokenisasi, residency) sebagai senjata desain.
• Bangun evidence pipeline: bukti lahir otomatis bersama kontrol, kontinu, dan tertata retensinya.
• Lolos audit = audit trail append-only, separation of duties, change management via pipeline, klasifikasi data, daftar vendor.
• Retention matrix menyeimbangkan kewajiban simpan vs hak hapus; exception compliance harus formal dan bertanggal.

Di episode 20 selanjutnya kita akan membahas multi-tenant SaaS solution — model tenancy dari silo sampai pool, isolasi data dengan row-level security, strategi pricing dan tiering yang selaras dengan biaya infrastruktur, serta operasi noisy neighbor di platform multi-pelanggan. Sampai jumpa di episode 20!