Enkripsi Data Sensitif Node.js: Panduan AES-256 & Argon2

Ringkasan

• Strategi Pertahanan Berlapis: Mengapa hashing password saja tidak cukup dan kapan harus menggunakan enkripsi dua arah (AES-256-GCM) untuk data sensitif.
• Implementasi Praktis: Panduan langkah demi langkah menerapkan Argon2id untuk password dan AES-256 untuk NIK, nomor rekening, dan data pribadi lainnya di Node.js.
• Manajemen Key & Database: Tips mengelola encryption keys menggunakan Secrets Manager serta strategi penyimpanan data terenkripsi di MongoDB dan PostgreSQL.
• Best Practices Keamanan: Menghindari kesalahan umum seperti hardcoding keys, penggunaan IV statis, dan kebocoran data melalui logging.

Beberapa tahun lalu, saya terlibat dalam penanganan insiden keamanan di sebuah aplikasi fintech skala kecil. Kejadiannya cukup mengejutkan: sistem tidak diretas melalui celah SQL Injection atau serangan brute force dari luar, melainkan karena file backup database-nya bocor. Saat kami memeriksa dump database tersebut, ditemukan bahwa nomor KTP (NIK), nomor rekening bank, dan alamat lengkap pengguna tersimpan dalam bentuk plain text.

Meskipun tim pengembang saat itu sudah menerapkan hashing untuk password, mereka mengabaikan enkripsi untuk data sensitif lainnya. Akibatnya sangat fatal dan melelahkan: kami harus mengirimkan notifikasi massal kepada pengguna, membuat laporan resmi ke pihak berwenang, dan melakukan perbaikan sistem di bawah tekanan tinggi. Pengalaman pahit ini mengajarkan saya bahwa keamanan data tidak boleh hanya berfokus pada pintu masuk (autentikasi), tetapi juga pada perlindungan data saat diam (data-at-rest).

Sejak saat itu, saya selalu menerapkan enkripsi selektif pada data sensitif di setiap proyek yang menangani informasi pribadi. Artikel ini akan membahas secara mendalam cara praktis mengimplementasikan enkripsi pada REST API Node.js, baik bagi Anda yang menggunakan MongoDB maupun PostgreSQL.

Mengapa Enkripsi Data Sensitif Itu Penting?

Banyak pengembang pemula menganggap bahwa jika password sudah di-hash, maka database sudah aman. Ini adalah miskonsepsi yang berbahaya. Hashing adalah proses satu arah yang memang tepat untuk password, tetapi tidak bisa digunakan untuk data yang perlu ditampilkan kembali kepada pengguna atau dikirim ke pihak ketiga (seperti API bank atau pajak).

Data sensitif yang wajib dienkripsi meliputi:

• Identitas Pribadi: Nomor KTP/NIK, Nomor NPWP, Paspor.
• Informasi Finansial: Nomor rekening bank, detail kartu kredit (sesuai standar PCI-DSS).
• Kontak Pribadi: Nomor telepon pribadi dan alamat rumah lengkap.
• Data Kesehatan: Rekam medis atau informasi diagnosis.

Tujuannya sederhana: menciptakan lapisan pertahanan terakhir. Bahkan jika database atau backup berhasil diakses oleh pihak yang tidak berwenang, data tersebut tetap tidak terbaca tanpa kunci enkripsi yang tepat. Hal ini sejalan dengan prinsip Defense in Depth dalam keamanan siber.

Hashing vs Enkripsi: Kapan Pakai Apa?

Sering terjadi kebingungan antara hashing dan enkripsi. Berikut adalah tabel perbandingannya untuk memudahkan Anda menentukan teknik yang tepat:

Jenis Data	Teknik yang Tepat	Bisa Dibalik?	Contoh Penggunaan
Password	Hashing (One-way)	Tidak	Login & Autentikasi
NIK, No. Rekening, Alamat	Enkripsi (Two-way)	Ya (dengan key)	Menyimpan & menampilkan kembali
Token / Secret Internal	Enkripsi atau Hashing	Tergantung	Session, API key, OAuth Token

1. Hashing Password dengan Argon2 atau bcrypt

Untuk password, saya sangat merekomendasikan Argon2 (khususnya Argon2id). Argon2 adalah pemenang Password Hashing Competition dan dirancang untuk tahan terhadap serangan menggunakan GPU atau ASIC karena membutuhkan memori yang besar (memory-hard). Namun, bcrypt tetap menjadi pilihan yang sangat solid dan memiliki dukungan library yang lebih luas di berbagai bahasa pemrograman.

Berikut adalah implementasi menggunakan Argon2 di Node.js:

npm install argon2

const argon2 = require('argon2');

async function hashPassword(plainPassword) {
  // Argon2id memberikan perlindungan terbaik terhadap side-channel attacks
  return await argon2.hash(plainPassword, {
    type: argon2.argon2id,
    memoryCost: 65536, // 64 MB
    timeCost: 3,
    parallelism: 4
  });
}

async function verifyPassword(hash, plainPassword) {
  return await argon2.verify(hash, plainPassword);
}

Jika Anda lebih memilih bcrypt, implementasinya adalah sebagai berikut:

const bcrypt = require('bcrypt');
const saltRounds = 12; // Semakin tinggi, semakin lambat (dan lebih aman)

const hash = await bcrypt.hash(plainPassword, saltRounds);
const isMatch = await bcrypt.compare(plainPassword, hash);

2. Enkripsi Kolom Sensitif dengan AES-256-GCM

Untuk data yang perlu didekripsi (seperti NIK), standar industri yang digunakan adalah AES-256. Saya sangat menyarankan menggunakan mode GCM (Galois/Counter Mode) daripada CBC. Mengapa? Karena GCM menyediakan authenticated encryption, yang berarti ia tidak hanya menyembunyikan data, tetapi juga memastikan bahwa data tersebut tidak dimodifikasi oleh pihak ketiga selama penyimpanan (integritas data).

Berikut adalah implementasi lengkap dan aman di Node.js menggunakan modul crypto bawaan:

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const IV_LENGTH = 16; // Initialization Vector
const TAG_LENGTH = 16; // Authentication Tag

// PENTING: Key harus 32 byte. Simpan di environment variable!
const ENCRYPTION_KEY = Buffer.from(process.env.ENCRYPTION_KEY, 'hex');

function encrypt(text) {
  const iv = crypto.randomBytes(IV_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, ENCRYPTION_KEY, iv);
  
  let encrypted = cipher.update(text, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  
  const tag = cipher.getAuthTag();
  
  // Gabungkan iv + tag + encrypted data agar mudah disimpan dalam satu kolom
  return iv.toString('hex') + ':' + tag.toString('hex') + ':' + encrypted;
}

function decrypt(encryptedText) {
  const [ivHex, tagHex, encrypted] = encryptedText.split(':');
  
  const iv = Buffer.from(ivHex, 'hex');
  const tag = Buffer.from(tagHex, 'hex');
  const decipher = crypto.createDecipheriv(ALGORITHM, ENCRYPTION_KEY, iv);
  
  decipher.setAuthTag(tag);
  
  let decrypted = decipher.update(encrypted, 'hex', 'utf8');
  decrypted += decipher.final('utf8');
  
  return decrypted;
}

Cara integrasi pada Service Layer:

// Saat menyimpan data pengguna baru
const encryptedNIK = encrypt(user.nik);
await User.create({ ...userData, nik: encryptedNIK });

// Saat menampilkan profil pengguna
const user = await User.findById(id);
user.nik = decrypt(user.nik);

Penerapan pada Berbagai Database

MongoDB (NoSQL)

Di MongoDB, hasil enkripsi disimpan sebagai string biasa. Namun, ada satu tantangan besar: Indexing. Karena AES-256 menghasilkan output yang acak (non-deterministik), Anda tidak bisa melakukan query db.users.find({ nik: '12345' }) secara langsung.

Jika Anda benar-benar perlu melakukan pencarian berdasarkan data terenkripsi, gunakan teknik Blind Index. Caranya adalah dengan membuat kolom tambahan yang berisi hash (HMAC) dari data asli menggunakan key yang berbeda. Anda mencari berdasarkan hash tersebut, namun tetap menyimpan data aslinya dalam bentuk terenkripsi AES.

PostgreSQL (Relational)

PostgreSQL menawarkan fleksibilitas tinggi. Anda bisa menggunakan tipe data TEXT atau BYTEA untuk menyimpan hasil enkripsi. Meskipun PostgreSQL memiliki ekstensi pgcrypto untuk enkripsi di level database, saya lebih menyarankan enkripsi di application layer (Node.js). Hal ini memastikan bahwa data sudah terenkripsi sebelum menyentuh jaringan database, sehingga admin database sekalipun tidak bisa melihat data asli.

Contoh skema tabel yang aman:

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE,
  password_hash TEXT NOT NULL,
  nik_encrypted TEXT,          -- Hasil AES-256-GCM
  phone_encrypted TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);

Best Practices & Manajemen Kunci (Key Management)

Enkripsi hanya sekuat kunci yang melindunginya. Jika kunci enkripsi Anda bocor, maka seluruh data terenkripsi di database menjadi tidak berguna.

• Jangan Pernah Hardcode Key: Jangan menuliskan key langsung di dalam kode JavaScript. Gunakan .env untuk pengembangan lokal, namun untuk produksi, gunakan Secrets Manager seperti AWS Secrets Manager, HashiCorp Vault, atau Doppler.
• Rotasi Kunci: Terapkan kebijakan rotasi kunci secara berkala. Ini meminimalkan dampak jika salah satu kunci lama ternyata bocor.
• IV (Initialization Vector) Harus Acak: Jangan pernah menggunakan IV yang statis. IV yang berbeda untuk teks yang sama akan menghasilkan ciphertext yang berbeda, mencegah serangan pattern recognition.
• Hindari Over-Encryption: Jangan mengenkripsi semua kolom. Enkripsi hanya data yang benar-benar sensitif. Enkripsi berlebihan akan menurunkan performa aplikasi secara signifikan dan mempersulit proses debugging.
• Keamanan Logging: Pastikan middleware logger Anda (seperti Winston atau Morgan) dikonfigurasi untuk melakukan masking pada field sensitif. Jangan sampai data terenkripsi (atau lebih buruk, plain text) tertulis di log server.

Checklist Implementasi Keamanan Data

Sebelum Anda melakukan deployment ke produksi, pastikan poin-poin berikut sudah terpenuhi:

1. Password menggunakan Argon2id atau bcrypt dengan cost yang memadai.
2. Data sensitif (NIK, Rekening, dll) dienkripsi dengan AES-256-GCM.
3. Encryption key disimpan di Secrets Manager, bukan di Git atau file config.
4. Proses enkripsi dan dekripsi terjadi sepenuhnya di server-side.
5. Tidak ada data sensitif yang bocor ke dalam application logs.
6. Backup database telah diuji dan dipastikan isinya terenkripsi.

Kesimpulan

Enkripsi data sensitif bukan lagi sekadar fitur "tambahan", melainkan standar wajib dalam pengembangan aplikasi modern, terutama yang menangani data pribadi. Dengan mengombinasikan hashing satu arah untuk password dan enkripsi dua arah (AES-256-GCM) untuk informasi pribadi, kita telah menutup celah risiko terbesar saat terjadi kebocoran database.

Kunci utama dari keamanan adalah konsistensi. Terapkan standar ini sejak tahap desain awal arsitektur API Anda. Jangan menunggu sampai terjadi insiden keamanan baru mulai bergerak, karena biaya pemulihan reputasi jauh lebih mahal daripada biaya implementasi enkripsi di awal.