Enkripsi TLS pada chapter sebelumnya menjaga data selama perjalanan di jaringan, tetapi di ujung perjalanan data menetap sebagai file di disk. Seluruh isi collection, index, dan journal server latihan kita hidup sebagai file WiredTiger di dalam direktori dbPath — dan tanpa perlakuan khusus, file-file itu terbaca oleh siapa pun yang memegang medianya: laptop yang hilang, harddisk bekas yang dijual, snapshot cloud yang bocor, atau arsip backup yang tertinggal di lokasi terbuka. Chapter ini membahas cara menutup celah tersebut, dari fitur enkripsi storage engine MongoDB Enterprise hingga alternatif level sistem operasi dan cloud provider.

Peta materi Chapter ini:

  • Membuktikan sendiri bahwa data tersimpan sebagai teks yang bisa dicari di dalam file WiredTiger.
  • security.enableEncryption: fitur encrypted storage engine MongoDB Enterprise, master key, dan KMIP.
  • Alternatif untuk Community Edition: LUKS/dm-crypt, BitLocker, enkripsi volume cloud, dan Atlas.
  • Batas perlindungan encryption at rest dalam pola defense in depth.

File-File WiredTiger di dbPath #

Setiap collection dan index di MongoDB disimpan sebagai file terpisah berakhiran .wt di dalam direktori storage.dbPath. Dua perintah berikut menunjukkan lokasi penyimpanan dan mesin yang mengelolanya pada server latihan:

js
printjson(db.adminCommand({ getCmdLineOpts: 1 }).parsed.storage)

Output yang Dihasilkan:

text
{
  dbPath: '/home/z/my-project/mongo-data',
  wiredTiger: {
    engineConfig: {
      cacheSizeGB: 0.25
    }
  }
}
js
const se = db.serverStatus().storageEngine
printjson({ name: se.name, persistent: se.persistent, readOnly: se.readOnly })

Output yang Dihasilkan:

text
{
  name: 'wiredTiger',
  persistent: true,
  readOnly: false
}

Nilai dbPath di mesin Anda mungkin berbeda — instalasi apt di Ubuntu lazimnya memakai /var/lib/mongodb. Di dalam direktori itu juga hidup file metadata WiredTiger*, pemetaan collection ke nama file (_mdb_catalog.wt), dan subdirektori journal. Sejak versi 8.0, nama file memakai UUID, bukan namaDatabase.namaCollection.

Membuktikan Data Terbaca Polos #

Agar hasil bebas dari riwayat latihan, kita jalankan satu mongod lab dengan dbPath kosong di port 28019 — pola yang sama dengan lab TLS sebelumnya. Server bersama di port 27017 tidak kita sentuh:

bash
rm -rf /tmp/ear-lab && mkdir -p /tmp/ear-lab/data
mongod --dbpath /tmp/ear-lab/data --port 28019 --bind_ip 127.0.0.1 \
  --fork --logpath /tmp/ear-lab/mongod.log --pidfilepath /tmp/ear-lab/mongod.pid

Output yang Dihasilkan (satu baris log JSON awal diringkas):

text
about to fork child process, waiting until server is ready for connections.
forked process: 23280
child process started successfully, parent exiting

Selanjutnya kita sisipkan satu document pelanggan yang memuat token rahasia, lalu memaksa pembilasan ke disk dengan perintah fsync — journal menerima data nyaris seketika, sedangkan file collection baru terisi penuh saat checkpoint berkala:

bash
mongosh "mongodb://127.0.0.1:28019/?directConnection=true" --quiet --eval '
db = db.getSiblingDB("latihan_ear")
printjson(db.pelanggan.insertOne({ _id: 1, nama: "Budi", email: "[email protected]", token: "RAHASIA-XYZ987" }))
printjson(db.adminCommand({ fsync: 1 }))'

Output yang Dihasilkan:

text
{
  acknowledged: true,
  insertedId: 1
}
{
  numFiles: 1,
  ok: 1
}

Sekarang saatnya membuktikannya: kita cari string token itu langsung di dalam file-file dbPath:

bash
grep -rl "RAHASIA-XYZ987" /tmp/ear-lab/data

Output yang Dihasilkan:

text
/tmp/ear-lab/data/journal/WiredTigerLog.0000000001
/tmp/ear-lab/data/collection-1ebce463-1d41-4119-a2bb-5550400e8477.wt

Token ditemukan sebagai teks polos di dua tempat: file journal dan file collection-nya (UUID berbeda pada tiap instalasi). Email [email protected] sama mudahnya ditemukan — grep -rl "[email protected]" /tmp/ear-lab/data menghasilkan pasangan file yang sama. Setelah selesai, hentikan instance lab milik Anda sendiri:

bash
kill $(cat /tmp/ear-lab/mongod.pid)

Perintah ini tidak menghasilkan keluaran — proses lab berhenti dan direktori /tmp/ear-lab boleh dihapus.

Enkripsi Storage Engine (Khusus Enterprise) #

MongoDB Enterprise menyediakan enkripsi native pada WiredTiger sejak versi 3.2, diaktifkan lewat security.enableEncryption. Seluruh file data terenkripsi penuh dari sudut pandang filesystem; data hanya berbentuk polos di memori dan selama transmisi. Prosesnya berjenjang: server membuat kunci per database, mengenkripsi data dengan kunci itu, lalu mengenkripsi kunci-kunci database dengan satu master key yang hidup di luar server.

Master key dikelola lewat dua jalur. Jalur pertama adalah keyfile lokal — buat dengan openssl, batasi izin bacanya, lalu muat di konfigurasi:

bash
openssl rand -base64 32 > mongodb-keyfile
chmod 600 mongodb-keyfile
text
security:
  enableEncryption: true
  encryptionKeyFile: /etc/mongodb/mongodb-keyfile
  encryptionCipherMode: AES256-GCM

Mode cipher yang tersedia adalah AES256-CBC (default) dan AES256-GCM (hanya Linux). Jalur kedua adalah appliance key management eksternal melalui protokol KMIP — jalur yang direkomendasikan dokumentasi resmi karena mendukung rotasi kunci:

text
security:
  enableEncryption: true
  kmip:
    serverName: kmip.example.com
    port: 5696
    serverCAFile: /etc/mongodb/kmip-ca.pem
    clientCertificateFile: /etc/mongodb/kmip-client.pem

Konfigurasi ini tidak bisa kita uji di server latihan: fiturnya eksklusif Enterprise dan penerapannya menuntut restart mongod. Saat sukses diterapkan, log server mencatat baris Encryption key manager initialized with key file: <path> sebagai penanda enkripsi aktif. Satu batasan penting: MongoDB tidak bisa mengenkripsi data yang sudah ada — replica set yang telah berisi data perlu initial sync bergilir per anggota dengan enkripsi dinyalakan.

Alternatif untuk Community Edition #

Pemegang Community Edition tidak kehilangan opsi. Checklist keamanan resmi MongoDB menegaskan: bila tidak memakai enkripsi WiredTiger, data di setiap host tetap wajib dienkripsi di level file system, perangkat, atau fisik (contoh resminya: dm-crypt).

LapisanContohCatatan
Enkripsi disk OSLUKS/dm-crypt (Linux), BitLocker (Windows), FileVault (macOS)Transparan bagi mongod; mengenkripsi satu volume penuh
Enkripsi volume cloudAWS EBS encryption, Azure Disk Encryption, Google Persistent DiskDiaktifkan saat membuat volume; kunci dikelola KMS provider
Enkripsi filesystemZFS native encryption, eCryptfsPer dataset — misalnya hanya dbPath dan direktori backup
Layanan terkelolaMongoDB AtlasEnkripsi at rest selalu aktif; kunci default dikelola Atlas atau milik sendiri via KMS

Lapisan yang dipilih harus menutup semua salinan data, bukan hanya dbPath: hasil mongodump adalah BSON polos, sehingga arsip backup wajib disimpan di media terenkripsi. Untuk kebutuhan yang lebih ketat lagi, MongoDB menyediakan enkripsi di level aplikasi — Client-Side Field Level Encryption dan Queryable Encryption mengenkripsi field sebelum data meninggalkan aplikasi — dengan detail di dokumentasi resmi.

Batas Perlindungan Encryption at Rest #

Enkripsi disk menutup satu kategori ancaman saja. Tabel berikut memetakan siapa penghalang untuk tiap kategori:

AncamanPenghalang utama
Klien tanpa identitas masuk lewat jaringanAuthentication
Penyadapan lalu lintas klien-serverTLS
Disk, file data, atau backup dicuriEncryption at rest
Akses lewat koneksi yang sah (insider)RBAC, least privilege, enkripsi level aplikasi

Rangkuman #

  • Data MongoDB hidup sebagai file .wt di dbPath; tanpa enkripsi, isinya terbaca sebagai teks polos — terbukti lewat grep pada lab dengan dbPath baru.
  • security.enableEncryption (Enterprise) mengenkripsi seluruh file data secara transparan dengan master key dari keyfile lokal atau KMIP.
  • Community Edition memakai enkripsi di lapisan OS (LUKS, BitLocker), volume cloud, atau filesystem — dan Atlas sudah menyala enkripsinya secara bawaan.
  • Salinan backup ikut wajib terenkripsi; mongodump menghasilkan BSON polos.
  • Encryption at rest adalah satu lapisan defense in depth — bukan pengganti authentication, TLS, maupun RBAC.