🗂️ Nyimpen File KTP di Public Storage, Entah Lupa, Entah Fiturnya gitu...

Ada developer yang bilang:

Tapi nyatanya…

🪪 File KTP user nyangkut di public bucket 📎 URL-nya dishare via WhatsApp 📦 Gak dienkripsi, gak pakai signed URL, dan gak pernah expired

🚨 Ini Bukan Bug. Ini Bom Waktu.

Masalahnya bukan karena niat jahat. Tapi karena tim nganggep itu “biasa aja”. Dan developernya gak pernah dikasih tahu soal prinsip dasar: Confidentiality.

🔐 Bayangin Kalau Dia Tahu Confidentiality...

Kalau aja dia ngerti prinsip ini lebih awal, mungkin dia bakal mikir:

• “Data pribadi = harus dibatasi aksesnya”
• “Public storage = gak cocok buat data sensitif”
• “Bukan cuma bisa jalan, tapi harus aman juga”

Dan bisa jadi:

✅ Filenya dienkripsi ✅ Akses pakai signed URL ✅ Ada lifecycle policy buat auto-delete ✅ Gak ada KTP nyangkut selamanya di bucket publik

Apa Itu Confidentiality?

Confidentiality itu soal menjaga kerahasiaan informasi. Hanya yang berhak yang boleh mengakses. Kalau sistem lo bisa dibuka siapa aja, berarti gak confidential.

Contoh Kasus Lainnya

Kayanya Udah Gak Ada

• Simpan password dalam bentuk plaintext di database.

Masih Sering Kejadian

• Token JWT muncul di error response.
• Data KTP/email muncul di URL (terekam di log).
• Bucket/file storage publik tanpa proteksi.
• Akses data sensitif cuma dikontrol dari frontend.

Wah Ini Advance

• Side-channel attack buat baca data terenkripsi.
• Logging internal yang gak pernah dibersihkan.

Bonus Lucu

• Nama file: data_user_ktp_FINAL_BENERAN_FIX.xlsx → Dan iya, public link-nya udah disebar ke tim sales.

Risiko Kalau Confidentiality Diabaikan

• Kebocoran data pribadi (PII)
• Exploit: impersonasi, social engineering
• Kena sanksi UU PDP
• Reputasi brand ancur
• Developer panik & disalahkan 😬

❌ 5 Kelakuan Nakal Developer (Jangan Ditiru!)

Kelakuan Nakal	Kenapa Bahaya?
Simpan file KTP user di bucket publik	Siapa pun bisa akses. Data pribadi bocor tanpa ampun.
Log semua header & body request ke production	Token, email, password bisa ikut terekam & diekspos.
Hardcoded credential di source code	Kalau repo bocor atau tim lain akses, selesai sudah.
Validasi akses cuma di frontend	Bypass role atau data user tinggal ubah inspector.
Pakai password dummy kayak 'admin123'	Kalau lupa ganti sebelum live? Fatal banget.

✅ 8 Contoh yang Aman

Praktik Aman	Kenapa Penting (UU PDP)
Gunakan HTTPS minimal TLS 1.2	Mencegah penyadapan data pribadi saat transmisi
Jangan log data sensitif	Log bisa jadi sumber kebocoran internal
Simpan rahasia di ENV, bukan hardcoded	Melindungi data dari akses source code
Validasi akses di backend, bukan cuma frontend	Menjaga prinsip least privilege
Enkripsi data saat disimpan (AES-256)	Memenuhi standar perlindungan data at rest
Audit akses dan permission secara berkala	Mencegah akses ilegal atau lupa revoke
Jangan share data production via tool publik	Risiko distribusi data pribadi ke pihak ketiga
Gunakan signed URL untuk akses file storage	Membatasi akses temporer dan aman untuk file sensitif

Kaitan dengan Standar Keamanan

• OWASP Top 10: Sensitive Data Exposure
• ISO 27001: Annex A.9 (Access Control), A.10 (Cryptography)
• NIST SP 800-53: AC-3, SC-12

Kaitan dengan UU PDP & Perlindungan Data Pribadi

Poin UU PDP	Relevansi Confidentiality
**Pasal 1 & 2**	Informasi seperti email, KTP, lokasi dianggap Data Pribadi
**Pasal 35**	Pengendali data wajib jaga keamanan dan kerahasiaan
**Pasal 5 & 6**	Subjek data punya hak: tahu, akses, koreksi, dll
**Pasal 57 & 58**	Pelanggaran = sanksi pidana & denda administratif

Penutup