Belajar Backend Developer - Privacy & Compliance Data

#Pendahuluan

Episode 17-18 mengamankan sistem dari serangan. Episode 19 membahas lapisan berikutnya: melindungi hak pengguna atas data mereka — bukan karena diserang, tapi karena diwajibkan hukum. Regulasi seperti GDPR (Uni Eropa) dan UU Perlindungan Data Pribadi di banyak negara mengubah cara backend menangani data pribadi.

Mengapa backend developer harus paham compliance? Karena sanksinya nyata — GDPR mengenakan denda hingga 4% dari omset global — dan karena aturan ini memengaruhi keputusan teknis harian: di mana data disimpan, bagaimana dienkripsi, apa yang boleh di-log, dan bagaimana data dihapus saat user meminta. Episode ini membangun prinsip dan praktik compliance data.

#Prinsip Dasar: Data Minimization

Prinsip pertama GDPR dan regulasi serupa: jangan kumpulkan data yang tidak dibutuhkan. Semakin sedikit data pribadi yang kalian simpan, semakin kecil risiko dan kewajiban.

Terapkan data minimization sejak desain skema (episode 5): setiap kolom harus punya alasan bisnis.

#Enkripsi Data Saat Transit

Data bergerak di jaringan — dari user ke server, dari server ke database. Data yang tidak dienkripsi saat transit bisa disadap (man-in-the-middle).

#TLS (Transport Layer Security)

Semua traffic HTTP di produksi wajib lewat HTTPS/TLS:

• Certificate valid dari CA tepercaya.
• Redirect HTTP → HTTPS.
• HSTS header memaksa browser selalu memakai HTTPS.
• https saja yang dipakai untuk integrasi pihak ketiga — http untuk API internal pun sebaiknya dihindari jika melewati jaringan bersama.

Browser --TLS--> Load Balancer --TLS--> API --TLS--> Database

Satu kesalahan umum: database di-cloud dibuka ke IP publik tanpa TLS. Managed database (episode 16) menyediakan encrypted connection — aktifkan dan wajibkan sertifikat.

#Enkripsi Data Saat Istirahat

Data yang disimpan (at rest) harus dilindungi jika media penyimpanan jatuh ke tangan salah.

#1. Enkripsi Disk (Provider Level)

Semua cloud provider menyediakan volume encryption — hard disk yang dienkripsi. Ini lapisan dasar: aktifkan di semua volume dan database.

#2. Enkripsi Kolom Sensitif (Application Level)

Untuk data yang paling sensitif — nomor kartu, data kesehatan, dokumen identitas — enkripsi di level aplikasi, sehingga database yang bocor tetap tidak bisa membaca datanya.

import { createCipheriv, createDecipheriv, randomBytes } from "node:crypto"
 
const KEY = Buffer.from(process.env.DATA_ENCRYPTION_KEY!, "hex")
 
export function encryptField(plain: string): string {
  const iv = randomBytes(16)
  const cipher = createCipheriv("aes-256-gcm", KEY, iv)
  const encrypted = Buffer.concat([cipher.update(plain, "utf8"), cipher.final()])
  const tag = cipher.getAuthTag()
  return [iv.toString("hex"), tag.toString("hex"), encrypted.toString("hex")].join(":")
}
 
export function decryptField(payload: string): string {
  const [ivHex, tagHex, dataHex] = payload.split(":")
  const decipher = createDecipheriv("aes-256-gcm", KEY, Buffer.from(ivHex, "hex"))
  decipher.setAuthTag(Buffer.from(tagHex, "hex"))
  return Buffer.concat([
    decipher.update(Buffer.from(dataHex, "hex")),
    decipher.final(),
  ]).toString("utf8")
}

Kunci enkripsi (key management) adalah bagian tersulit: simpan di KMS (AWS/GCP/Azure Key Management Service), bukan di kode atau env biasa. KMS mengelola rotasi dan akses kunci.

#Privacy-First Logging

Log (episode 11) adalah jebakan data pribadi — email, token, body penuh sering ikut tercatat. Compliance mewajibkan log yang mematuhi privacy:

import pino from "pino"
 
export const logger = pino({
  redact: {
    paths: [
      "req.headers.authorization",
      "req.body.email",
      "req.body.password",
      "user.email",
    ],
    censor: "[REDACTED]",
  },
})

redact mengganti nilai field sensitif dengan [REDACTED] — log tetap berguna untuk debugging tanpa menyimpan data pribadi. Kebijakan logging privacy-first:

• Jangan log body penuh request.
• Redact token, password, email, dan data pembayaran.
• Log agregat (jumlah, status) daripada detail personal saat memungkinkan.

#Hak Pengguna: Data Deletion

GDPR memberi user hak atas data mereka — termasuk right to erasure ("right to be forgotten"). Backend harus bisa menghapus data user secara lengkap.

export async function deleteUserAccount(userId: number, tx) {
  // hapus semua data turunan dalam satu transaction (episode 5)
  await tx.query("DELETE FROM sessions WHERE user_id = $1", [userId])
  await tx.query("DELETE FROM addresses WHERE user_id = $1", [userId])
  await tx.query("DELETE FROM users WHERE id = $1", [userId])
}

Pertanyaan desain yang harus dijawab: apakah data order dipertahankan setelah akun dihapus? GDPR mengizinkan menyimpan data yang wajib hukum (fiskal) — tetapi harus anonymized atau terpisah dari identitas user. Desain skema sejak awal dengan memikirkan deletion.

#Audit Trail

Compliance membutuhkan bukti — siapa mengakses/mengubah apa, kapan. Audit log berbeda dari log aplikasi biasa: ia tidak boleh berubah (immutable) dan tidak boleh dihapus oleh user.

Contoh bentuk audit trail:

{
  "event": "user.deleted",
  "actor": "admin@shop.example",
  "target": "user:987",
  "timestamp": "2026-08-16T10:00:00Z",
  "reason": "GDPR erasure request"
}

Simpan audit trail terpisah (tabel/append-only), dan buat tidak bisa diubah (misal di log immutable atau database append-only).

#Praktik: Compliance Checklist

Jadikan checklist ini bagian dari definisi "selesai" setiap fitur:

• Minimization — field pribadi hanya yang dibutuhkan.
• Transit — TLS di semua komunikasi; database terenkripsi koneksinya.
• At rest — volume terenkripsi; kolom paling sensitif dienkripsi aplikasi.
• Keys — kunci di KMS/Vault, dirotasi, tidak pernah di kode.
• Logging — redact data pribadi; tidak ada body penuh.
• Deletion — user bisa minta hapus, seluruh data terhapus.
• Audit — event penting tercatat, immutable, tidak bisa dihapus user.

#Common Pitfalls

#Mengira Enkripsi Transit Sudah Cukup

Data yang tersimpan tetap perlu perlindungan. Enkripsi transit dan at-rest saling melengkapi, bukan pengganti.

#Kunci Enkripsi di Kode

Enkripsi dengan kunci yang ikut bocor = kosmetik. Kelola kunci di KMS.

#Log Menyimpan Data Pribadi

Log body penuh atau email = pelanggaran compliance tersembunyi. Redact dan minimization.

#Delete Hanya dari Satu Tabel

Menghapus user dari tabel users tapi data order/address/session tertinggal = erasure tidak lengkap. Petakan semua tabel turunan.

#Penutup

Episode 19 melindungi data pengguna: data minimization sebagai prinsip desain, enkripsi saat transit (TLS) dan saat istirahat (disk + kolom aplikasi), privacy-first logging, hak user atas penghapusan data, dan audit trail yang immutable.

Inti yang harus dibawa pulang:

• Data minimization: jangan simpan data yang tidak dibutuhkan.
• Enkripsi saat transit (TLS) dan saat istirahat (disk + kolom sensitif).
• Kunci enkripsi di KMS/Vault, rotasi berkala, tidak pernah di kode.
• Log wajib redact data pribadi.
• Dukung hak user: delete menyeluruh dan audit trail yang tidak bisa diubah.

Di episode 20 selanjutnya kita akan melindungi ketersediaan: rate limiting & DDoS protection — membatasi akses per endpoint dan mempertahankan layanan dari serangan banjir. Sampai jumpa di episode 20!