Keamanan Data

Terakhir diperbarui 28 Agustus 2025

Keamanan yang Praktis dan Transparan

Kami membangun Zatoran dengan prinsip “privasi bawaan, keamanan bawaan”. Dokumen ini menjelaskan detail teknis bagaimana data Anda dilindungi di tingkat penyimpanan, transport, dan aplikasi.

Ringkasan Teknis

  • Enkripsi data tersimpan: AES-256-GCM (nonce||ciphertext) di MongoDB BinData.
  • Enkripsi saat transit: TLS.
  • Hash non-reversibel: BLAKE3 (base64-url) dengan salt untuk pengenal stabil seperti email hash dan kode sekali pakai.
  • Kata sandi: Argon2id, tidak pernah disimpan dalam bentuk plaintext.
  • Skema penyimpanan hemat: kunci BSON pendek, timestamp UTC.
  • Infrastruktur: VPS Vultr (utama) dan VPS DigitalOcean (backup) berlokasi di Singapura.

Catatan: Hash bukan enkripsi. Hash digunakan untuk kecocokan/lookup tanpa menyimpan nilai asli. Obfuscation ID tidak ditujukan melindungi data sensitif.

Enkripsi Data Tersimpan (At Rest)

  • Algoritma: AES-256-GCM (authenticated encryption).
  • Kunci: 32 byte dari variabel lingkungan AESSecretKey.
  • Format penyimpanan: nonce || ciphertext (nonce di depan), disimpan sebagai MongoDB BinData.
  • Area penggunaan: nama legal (n), panggilan (k), email terenkripsi (ee), dan field sensitif lain yang relevan.

GCM memberikan kerahasiaan dan integritas. Nonce unik diperlukan untuk setiap enkripsi. Kami mengenkode payload ke BinData untuk menjaga efisiensi dan konsistensi di MongoDB.

Enkripsi Saat Transit

Semua koneksi ke layanan Zatoran dilindungi oleh TLS untuk mencegah penyadapan dan modifikasi data saat dalam perjalanan.

Infrastruktur & Lokasi Data

  • Server aplikasi dan basis data berjalan di VPS Vultr (utama) dan VPS DigitalOcean (lapis cadangan) yang berlokasi di Singapura.
  • Arsitektur dan penyedia dapat berkembang seiring kebutuhan. Perubahan material akan kami catat dan, bila relevan, diinformasikan kepada pengguna.

Hash dan Identifikasi Stabil

  • Algoritma: BLAKE3, hasil di-encode base64-url, dengan salt.
  • Kegunaan: pengenal stabil yang tidak dapat dibalik seperti EmailHash (eh) dan kode sekali pakai di kredensial (InitSignUp).
  • Sifat: hash bersifat deterministik terhadap kombinasi (nilai + salt); cocok untuk kecocokan/equality lookup, bukan enkripsi.

Konsekuensi keamanan: jika input berentropi rendah (mis. daftar email publik), hash dapat ditebak melalui pencarian kamus. Mitigasi: gunakan salt untuk mengganggu tabel pelangi, jangan mengekspos hash secara publik, gunakan token one-time berentropi kuat, dan batasi percobaan.

Catatan implementasi: skema salt dirancang agar mendukung kebutuhan pencarian (equality lookup) secara deterministik dan dikelola dengan aman.

Kata Sandi

  • Disimpan menggunakan Argon2id (melalui authservice.HashPassword).
  • Tidak pernah disimpan dalam bentuk plaintext.
  • Parameter disetel untuk menyeimbangkan keamanan dan performa sesuai lingkungan produksi.

Skema Penyimpanan dan Kunci BSON Pendek

Untuk efisiensi ukuran dokumen, kami menggunakan kunci BSON pendek di seluruh koleksi. Contoh pada struktur User:

  • _id: MongoDB ObjectID
  • u: Username (plaintext, huruf kecil, unik)
  • n: LegalName (AES-256-GCM)
  • k: Nickname (AES-256-GCM)
  • ee: EmailEnc (AES-256-GCM)
  • eh: EmailHash (BLAKE3 base64-url)
  • p: Profile (subdokumen)
  • s: Status (flag verifikasi/premium)
  • a: Avatar (kode atau URL)
  • c: Credentials (Argon2id password, token pendaftaran)
  • l: Linked (OAuth: Google g, GitHub h)
  • g: Category
  • t: Time (timestamp UTC)
  • r: Nationality (kode ISO 3166-1 alpha-2)

Timestamp disimpan dalam UTC (time.Time), mempermudah audit lintas zona waktu.

Bidang yang Terenkripsi vs. Teks Biasa

  • Terenkripsi (AES-256-GCM): LegalName (n), Nickname (k), EmailEnc (ee), dan bidang sensitif sejenis.
  • Di-hash (BLAKE3): EmailHash (eh), kode sekali pakai (mis. InitSignUp).
  • Teks biasa (plaintext, non-sensitif): Username (u) dan Nationality/country code (r) untuk interoperabilitas dan tampilan publik.

Obfuscation pengenal publik (mis. SQIDs dengan salt) digunakan untuk mencegah pemaparan ID internal dan mengurangi prediktabilitas urutan ID. Saat berinteraksi dengan pihak ketiga (mis. Xendit), pengenal yang dipaparkan adalah bentuk yang sudah di-obfuscate, bukan ID internal. Obfuscation tidak menggantikan enkripsi untuk data sensitif.

Kredensial dan Token

Struktur Credentials menyimpan:

  • p (opsional): hash Argon2id kata sandi.
  • v (opsional): token/verifikasi (aliran bergantung).
  • i (opsional): kode satu-kali yang di-hash (BLAKE3) untuk inisiasi signup.
  • a (opsional): penghitung percobaan (throttling).

Praktik rekomendasi: pembatasan percobaan (rate limit), kedaluwarsa token, dan invalidasi setelah digunakan.

Pengelolaan Kunci (Ringkas)

  • Secret disuntikkan via variabel lingkungan dan hanya dapat diakses oleh proses layanan yang berwenang.
  • Akses ke secret dibatasi menggunakan kontrol peran dan praktik least-privilege.
  • Rotasi kunci dilakukan saat diperlukan; perubahan besar akan diinformasikan dalam catatan rilis internal. (Detail yang lebih dalam dapat dikeluarkan pada dokumen operasional terpisah.)

Backup dan Log

  • Cadangan mengikuti kebijakan enkripsi at-rest platform penyimpanan yang digunakan dan disalin ke infrastruktur cadangan (mis. DigitalOcean) sesuai kebutuhan.
  • Log aplikasi tidak menyimpan data sensitif secara plaintext; konten sensitif dihindari atau disamarkan.

Perubahan Dokumen

Praktik keamanan dapat berkembang seiring peningkatan layanan. Dokumen ini akan diperbarui ketika ada perubahan material pada implementasi teknis.

Kontak

Pertanyaan terkait keamanan? Hubungi kami di support@zatoran.com.