🚨 Saat Kode Si BE-Dev Jadi Bukti Pelanggaran

Jadi ceritanya, si BE-Dev disuruh bikin API login. Karena ngejar deadline, dia log semua request ke file. Katanya: “Biar gampang debug, bro.”

Tiga minggu kemudian… file log itu nongol di ruang audit. Isinya lengkap: email, IP address, bahkan NIK user. Dan pas ditanya?

📘 Compliance Itu Apa?

Dalam konteks teknologi dan software development, compliance itu artinya:

• Sistem yang kamu bangun gak cuma bisa jalan, tapi juga harus patuh sama aturan
• Yang dilindungi bukan cuma performa sistem, tapi hak-hak user sebagai pemilik data

Di Indonesia, aturan yang paling relevan adalah UU PDP (Undang-Undang Perlindungan Data Pribadi).

Dan ini bukan urusan tim legal doang. Karena faktanya:

• Yang bikin form pendaftaran? Dev.
• Yang nentuin data apa yang disimpan dan di-log? Dev.
• Yang bisa ngehapus data user? API yang Dev bikin.

Baris kode kamu bisa bikin perusahaan:

• 📩 Dapet teguran dari “yang berwenang”
• 💸 Bayar denda administratif sampai miliaran
• ⚖️ Kena jeratan pasal, bahkan pidana (kalau berat)

Dan semua itu bisa berawal dari satu log file, satu checkbox consent yang cuma formalitas, atau satu bucket yang nggak dikunci.

🧠 Kenapa Ini Penting Buat Developer?

Karena... pelanggaran UU PDP itu sering terjadi bukan karena niat jahat, tapi karena keputusan teknis yang salah.

Dan siapa yang ngambil keputusan teknis setiap hari? Ya kamu. Si developer.

Contohnya:

• Log sembarangan ke file tanpa filter
• Simpen data user di storage yang gak dienkripsi
• Gak pakai checkbox consent, atau cuma buat gaya-gayaan
• Hardcoded token/API key di repo
• Gak ada proses hapus data user saat dia minta “delete akun”

Semua itu keliatannya sepele pas ngerjain. Tapi kalau bocor, bisa jadi:

• Barang bukti pelanggaran
• Alasan dipanggil waktu audit
• Sumber denda miliaran karena salah log

Bukan berarti kamu harus hafal semua pasal. Tapi kamu harus tau mana keputusan coding yang bisa nyeret tim kamu ke masalah.

🧨 Problems: What & Why

Sebagian besar pelanggaran compliance itu bukan karena niat jahat. Tapi karena keputusan teknis yang dianggap “biasa aja.”

Contohnya?

1. Log Semua Data Request ke File

Tapi di dalamnya ternyata ada:

• Email user
• NIK
• IP address
• Kadang token otentikasi

Masalahnya:

• Log sering diakses banyak pihak
• Gak pernah dibersihin
• Bahkan masuk backup otomatis

Log jadi ladang PII bocor.

2. Simpen PII di Database Tanpa Enkripsi

Tapi ketika:

• Backup dikopi ke vendor
• Dev lain punya akses bebas
• DB kebuka gara-gara exposable port

... semua data disimpan apa adanya. Kalau bocor? Gak ada mitigasi. Bisa kena pasal berat soal keamanan data.

3. Checkbox Consent Cuma Formalitas

Kalau user gak pernah setuju tapi datanya tetap dikumpulin → pelanggaran Pasal 15 UU PDP. Yang repot siapa? --> Yang bikin sistem. 😬

4. Share Data Production Lewat Email/Chat

Tapi datanya ngambang ke luar sistem. Begitu keluar, udah gak bisa dilindungi. Dan kalau bocor, gak ada trace siapa yang pegang terakhir. Sudah pelanggaran. Gak bisa ditarik balik.

5. Validasi Akses Cuma di Frontend

Ya, tapi fetch('/admin') tetap jalan. Si user biasa bisa akses API admin. Gak ada kontrol beneran di backend. Dan pas audit? Semua akses ilegal terekam.

🛡 Secure Practices️: How & Why

Gak cukup cuma ngerti compliance itu penting. Yang lebih penting: tahu apa yang bisa kamu lakuin biar coding kamu comply.

✅ Jangan Log Sembarangan

• Hindari log data sensitif: NIK, email, token
• Gunakan masking atau hashing
• Set log_level dengan bijak (debug/info/error)
• Bersihkan log secara berkala (log retention policy)

Kenapa penting? Karena log itu bukan file pribadi kamu. Bisa dibaca sistem lain, bahkan dev lain.

✅ Simpan PII dengan Enkripsi

• Minimal Pake AES-256 untuk enkripsi data at rest
• Jangan simpan password, simpan hash (bcrypt, argon2)
• Enkripsi backup juga — bukan cuma database utama

Ini bukan paranoid. Ini jaring pengaman. Kalau data bocor, minimal gak bisa langsung dibaca.

✅ Implementasi Consent Beneran

• Checkbox bukan pajangan
• Store status consent di database
• Include dalam audit trail (siapa, kapan, consent apa)

Pasal 15 UU PDP bilang:

✅ Gunakan ENV, Bukan Hardcoded Credential

• Semua secret, token, API key simpan di ENV
• Jangan pernah commit ke repo
• Audit ENV file secara rutin

Hardcoded secret = open invitation buat bocor.

✅ Validasi Akses Selalu di Backend

• Role check + permission logic wajib di backend
• Jangan percaya frontend
• Log semua access attempt untuk audit

✅ Gunakan Signed URL untuk File Akses

• Hindari file public tanpa proteksi
• Signed URL = akses sementara & terkendali
• Tambahkan TTL (time to live)

✅ Jangan Share Data Sembarangan

• Gunakan masking kalau memang harus share
• Lebih baik pakai dummy data
• Kalau harus real, simpan access log-nya

📚 Kaitan dengan UU PDP & Standar

Pasal/Standar	Relevansi
Pasal 15 UU PDP	Pengumpulan data wajib dengan persetujuan (consent)
Pasal 35 UU PDP	Wajib lindungi kerahasiaan & keamanan data pribadi
Pasal 57 UU PDP	Pelanggaran bisa kena pidana & denda
OWASP A09	Security Logging and Monitoring Failures
ISO 27001 A.10	Kewajiban proteksi kriptografi
NIST SP 800-53 AC-3	Access control wajib diterapkan

🧾 Developer Compliance Checklist

Checklist	Kenapa Ini Penting?
✔ Jangan log data sensitif (PII, token, password)	Log bisa diakses banyak pihak & masuk backup
✔ Enkripsi data saat disimpan	Lindungi data at rest dari kebocoran
✔ Gunakan ENV untuk semua secret	Hindari risiko hardcoded credential bocor
✔ Tambahkan dan validasi checkbox *consent*	Syarat sah pengumpulan data (UU PDP)
✔ Validasi semua akses di backend	Frontend gak bisa dipercaya untuk enforce access control
✔ Jangan share data production sembarangan	Begitu keluar, data gak bisa dikendalikan
✔ Simpan jejak consent dan perubahan data	Berguna saat audit atau tuntutan user
✔ Audit file log, akses, dan backup secara berkala	Biar gak jadi ladang pelanggaran yang ngendap

🧨 Penutup