Data Personel Tidak Boleh Disimpan Seperti Dokumen Biasa

The Core Update

Pemerintah Amerika Serikat dilaporkan sedang memberi tahu jutaan anggota militer aktif, mantan anggota militer, staf, dan pihak terkait bahwa informasi pribadi mereka dicuri dalam kebocoran data yang berlangsung selama berbulan-bulan.

Menurut pemberitahuan dari Defense Manpower Data Center atau DMDC, beberapa pengguna tidak sah mengeksploitasi celah keamanan pada sistem file-sharing yang tidak disebutkan namanya. Akses itu terjadi antara Oktober 2025 sampai pertengahan Juli 2026.

Data yang terekspos bukan data ringan. Di dalamnya ada informasi identitas pribadi seperti Social Security number, nama, tanggal lahir, jenis kelamin, ras, dan informasi lain terkait layanan militer.

Yang membuat kasus ini lebih serius: catatan personel tersebut disebut tidak terenkripsi.

CNN dan Federal News Network melaporkan bahwa insiden ini berdampak pada sekitar 2,8 juta orang yang masih hidup dan hampir 300.000 orang yang sudah meninggal.

DMDC mungkin bukan nama yang sering terdengar publik. Tetapi perannya besar. Unit ini menyimpan puluhan juta catatan untuk personel militer, staf sipil, kontraktor, dan keluarga mereka. Data itu dipakai untuk menentukan benefit, hak layanan kesehatan, pensiun, serta kebutuhan identitas dan akses.

DMDC juga berperan sebagai penyedia identity management penting untuk militer. Artinya, data yang mereka kelola tidak hanya administratif. Data itu terkait akses ke sistem komputer Pentagon, gedung, pangkalan, smart card, dan password.

Di situsnya, DMDC menyebut bahwa mereka memastikan orang yang tepat mendapat akses dan orang yang salah tidak mendapat akses.

Kalimat itu terdengar benar. Tetapi insiden ini menunjukkan satu hal yang lebih tidak nyaman: sistem identitas tidak cukup hanya benar secara fungsi. Ia juga harus aman secara desain, penyimpanan, akses, audit, dan respons.

The Reality Check

Banyak organisasi masih memperlakukan data personel sebagai dokumen administrasi.

Nama, tanggal lahir, nomor identitas, status pekerjaan, riwayat layanan, akses, dan catatan internal sering dianggap sebagai data kantor biasa. Disimpan di sistem file-sharing. Dipindahkan antar tim. Dibuka untuk kebutuhan operasional. Diekspor untuk laporan. Kadang tidak terenkripsi. Kadang aksesnya terlalu luas. Kadang masa simpannya tidak pernah ditinjau.

Masalahnya, data personel bukan sekadar arsip.

Data personel adalah peta tentang manusia, peran, akses, kebiasaan, dan hubungan organisasi. Jika data itu bocor, risiko tidak berhenti pada pencurian identitas. Risiko bisa melebar ke profiling, penipuan yang lebih meyakinkan, social engineering, tekanan terhadap individu, dan serangan lanjutan ke sistem internal.

Dalam konteks militer atau lembaga negara, risikonya lebih tinggi. Tetapi pelajarannya berlaku untuk bisnis biasa.

Banyak perusahaan punya data karyawan, customer, vendor, lead, dan partner yang tersebar di spreadsheet, folder bersama, CRM, form, chat, dan aplikasi internal. Semua terlihat praktis sampai ada satu celah yang membuat data itu keluar.

Kebocoran seperti ini juga menantang kalimat yang sering muncul setelah insiden: belum ada indikasi data disalahgunakan.

Kalimat itu tidak otomatis salah. Tetapi tidak cukup menenangkan.

Data identitas tidak selalu langsung dipakai. Kadang disimpan. Kadang dijual. Kadang digabungkan dengan data lain. Kadang dipakai berbulan-bulan atau bertahun-tahun kemudian, saat target sudah lupa bahwa datanya pernah bocor.

Karena itu, ukuran risikonya bukan hanya apakah data sudah disalahgunakan hari ini. Ukurannya juga: data apa yang keluar, seberapa lengkap, siapa yang bisa terdampak, dan apakah data itu bisa diganti.

Password bisa diganti. Kartu akses bisa dicabut. Nomor identitas, tanggal lahir, riwayat kerja, dan detail pribadi jauh lebih sulit dipulihkan.

Di sinilah banyak organisasi salah membaca prioritas. Mereka membeli tool keamanan, tetapi belum menata pertanyaan dasar:

• data sensitif apa yang disimpan?
• siapa yang benar-benar perlu akses?
• apakah data terenkripsi saat disimpan?
• apakah akses dicatat dan ditinjau?
• apakah file-sharing boleh menyimpan data mentah?
• berapa lama data boleh disimpan?
• apa yang terjadi jika sistem itu ditembus?

Tanpa jawaban yang jelas, tool keamanan hanya menjadi lapisan tambahan di atas kebiasaan kerja yang rapuh.

The Havedev Way

Dari sudut pandang Havedev, kasus seperti ini bukan hanya cerita tentang hacker. Ini cerita tentang desain operasional data.

Sebelum bicara teknologi yang kompleks, bisnis perlu memisahkan data biasa dan data berisiko tinggi.

Data biasa bisa dipakai untuk operasional harian. Data berisiko tinggi harus punya aturan berbeda: akses lebih sempit, penyimpanan lebih aman, audit lebih jelas, dan alasan penggunaan yang lebih tegas.

Untuk banyak bisnis, langkah awal tidak harus rumit.

Mulai dari inventaris data. Tulis data apa saja yang dikumpulkan dari customer, lead, karyawan, vendor, dan partner. Lalu tandai mana yang sensitif: nomor identitas, alamat, dokumen legal, data pembayaran, data kesehatan, kredensial, catatan internal, atau informasi yang bisa dipakai untuk menipu seseorang.

Setelah itu, cek lokasi penyimpanan. Banyak risiko muncul bukan karena database utama lemah, tetapi karena salinan data tersebar di tempat yang lebih longgar: spreadsheet ekspor, folder bersama, lampiran email, backup manual, aplikasi pihak ketiga, atau file lama yang tidak pernah dibersihkan.

Berikutnya, cek akses. Prinsipnya sederhana: tidak semua orang yang bisa membantu proses perlu melihat semua data. Tim sales mungkin butuh konteks lead, tetapi belum tentu butuh seluruh dokumen identitas. Tim support mungkin butuh riwayat masalah, tetapi belum tentu butuh data pembayaran lengkap. Admin mungkin butuh verifikasi, tetapi akses permanen ke seluruh arsip belum tentu sehat.

Keamanan yang baik sering dimulai dari pengurangan akses, bukan penambahan dashboard.

Lalu pastikan data sensitif tidak polos saat disimpan. Enkripsi bukan fitur mewah untuk organisasi besar saja. Untuk data yang jika bocor bisa merugikan orang, enkripsi saat penyimpanan dan pengiriman harus menjadi standar dasar.

Audit juga penting. Jika data sensitif dibuka, diekspor, atau diubah, organisasi perlu tahu siapa yang melakukannya dan kapan. Tanpa log, investigasi setelah insiden sering berubah menjadi tebak-tebakan.

Terakhir, bisnis perlu punya aturan retensi. Banyak data disimpan terlalu lama hanya karena tidak ada yang pernah memutuskan kapan harus dihapus. Padahal data lama tetap membawa risiko baru. Semakin banyak data yang disimpan tanpa alasan jelas, semakin besar dampak jika terjadi kebocoran.

Pelajaran penting dari kasus DMDC adalah ini: sistem identity management tidak boleh hanya mengejar kemudahan akses. Ia harus membatasi dampak saat ada satu bagian yang gagal.

Untuk bisnis, prinsipnya sama. Website, CRM, form, dashboard, dan automation sebaiknya tidak hanya menjawab bagaimana data masuk. Mereka juga harus menjawab bagaimana data dilindungi, siapa yang boleh melihat, berapa lama disimpan, dan apa yang terjadi jika akses disalahgunakan.

Bukan berarti semua bisnis harus membangun sistem keamanan tingkat militer. Tetapi setiap bisnis yang menyimpan data orang lain perlu berhenti memperlakukan data sensitif seperti file biasa.

Karena ketika data sudah keluar, masalahnya tidak lagi sekadar teknis. Masalahnya menjadi kepercayaan.

Dan kepercayaan jauh lebih sulit dipulihkan daripada mengganti tool.

Dapatkan Audit Teknis Gratis untuk meninjau alur website, form, CRM, dan penyimpanan data yang mungkin sudah berjalan, tetapi belum cukup aman dibaca sebagai sistem.

---

Sumber referensi berita: TechCrunch