chmod 600 dari chapter sebelumnya menghalangi pengguna lain di mesin yang sama, tetapi tidak menghentikan laptop yang dicuri, berkas backup yang bocor, atau folder cloud yang salah setelan — karena isi berkas SQLite tetap teks biasa. Solusinya adalah enkripsi, dan di sinilah muncul kejutan bagi banyak pengguna baru: SQLite inti tidak memiliki kemampuan enkripsi sama sekali. Chapter ini memetakan opsi yang tersedia dan cara memilihnya berdasarkan model ancaman.

SQLite Inti Tidak Bisa Enkripsi Sendiri #

Ada alasan desain di baliknya. SQLite dikembangkan sebagai library yang tertanam di dalam aplikasi, dengan format berkas yang terbuka dan terdokumentasi penuh untuk umum. Tim pengembangnya sengaja menjaga inti SQLite kecil, bebas biaya lisensi, dan bebas komponen kriptografi — enkripsi diserahkan ke lapisan di sekitarnya.

Lapisan itu bernama VFS (Virtual File System): antarmuka tempat SQLite melakukan semua operasi baca-tulis berkas. Bangunan enkripsi yang baik dipasang sebagai pengganti VFS, sehingga setiap halaman yang hendak ditulis ke disk dienkripsi dulu, dan setiap halaman yang dibaca dari disk didekripsi dulu. Aplikasi tetap melihat data polos; hanya isi berkas di disk yang berupa ciphertext.

Dua Produk: SEE dan SQLCipher #

Ada dua nama besar yang menyediakan enkripsi tingkat halaman tersebut:

AspekSEESQLCipher
PengembangTim SQLite resmi (Hipp, Wyrick)Komunitas open source (Zetetic)
LisensiKomersial, berbayarOpen source, gratis (BSD-style)
AlgoritmaAES-256 dan beberapa skema lainAES-256
KunciDari passphrase yang diberikan aplikasiDari passphrase, dapat di-rekey
Kegunaan khasSistem tertutup dengan dukungan resmiAplikasi mobile dan desktop lintas platform

Keduanya mengubah berkas database menjadi berupa ciphertext, termasuk berkas -wal dan -journal. Perintah sqlite3 yang datang dari distribusi Linux umumnya tidak dikompilasi dengan salah satunya — dan di sinilah letak kejutan yang perlu kita buktikan sendiri.

Menguji CLI Standar #

SQLCipher memperkenalkan PRAGMA cipher_version untuk melaporkan versinya. Pada sqlite3 CLI standar, pragma tak dikenal dijalankan tanpa keluaran apa pun:

bash
sqlite3 toko.db "PRAGMA cipher_version;"

Output yang Dihasilkan:

text

Tidak ada baris keluaran — engine SQLite mengabaikan pragma yang tidak dikenalnya. Ujian kedua lebih berbahaya. SQLCipher memakai klausa KEY pada ATTACH untuk membuka database terenkripsi; SQLite standar menerima klausa itu tanpa galat, lalu mengabaikannya:

bash
sqlite3 toko.db <<'SQL'
ATTACH DATABASE 'rahasia.db' AS enc KEY 'YOUR_PASSPHRASE';
CREATE TABLE enc.catatan (isi TEXT);
INSERT INTO enc.catatan VALUES ('data-paling-rahasia');
DETACH enc;
SQL
grep -ao 'data-paling-rahasia' rahasia.db

Output yang Dihasilkan:

text
data-paling-rahasia

Empat perintah SQL di atas “berhasil” dijalankan, tetapi grep membuktikan rahasia.db menyimpan data secara polos — klausa KEY diabaikan begitu saja oleh build tanpa enkripsi.

Alternatif Tanpa Mengganti SQLite #

Bila mengganti build SQLite tidak memungkinkan, ada tiga jalur enkripsi di luar database:

  • Enkripsi filesystem: LUKS di Linux, FileVault di macOS, BitLocker di Windows. Seluruh disk atau partisi terenkripsi, dan SQLite bekerja di atasnya tanpa perubahan apa pun. Ini melindungi dari pencurian perangkat, tetapi tidak dari proses yang berjalan sebagai pengguna Anda.
  • Backup terenkripsi: kompresi dan enkripsi terjadi setelah database ditutup. Ilustrasinya dengan gpg: perintah gpg -c toko.db meminta YOUR_PASSPHRASE lalu menghasilkan toko.db.gpg yang hanya bisa dibuka dengan passphrase yang sama. Alat modern seperti age menawarkan pola serupa dengan kunci publik.
  • Enkripsi tingkat kolom: aplikasi mengenkripsi nilai sensitif — nomor telepon, alamat, token — sebelum INSERT, lalu menyimpan ciphertext sebagai BLOB. Kunci dibaca dari environment variable YOUR_ENCRYPTION_KEY, bukan disimpan di database yang sama. Harga yang dibayar: kolom ini tidak lagi bisa dfilter dengan WHERE atau diurutkan secara bermakna, karena engine SQLite hanya melihat byte acak.

Memilih Berdasarkan Model Ancaman #

Pilihan enkripsi bergantung pada apa yang ingin dilindungi:

Model ancamanSolusi paling pas
Laptop atau server fisik dicuriEnkripsi filesystem (LUKS, FileVault, BitLocker)
Berkas backup bocor ke pihak lainBackup terenkripsi (gpg, age)
Database ikut terunggah dari webrootSimpan di luar webroot + izin ketat (Chapter Keamanan Berkas Database)
Penyimpanan bersama, banyak pihak satu mesinSQLCipher atau SEE
Beberapa kolom sensitif di sistem multi-penggunaEnkripsi tingkat kolom

Perhatikan bahwa baris pertama dan terakhir tabel tidak saling menggantikan — enkripsi filesystem tidak menolong bila aplikasi sendiri yang membocorkan kolom, dan enkripsi kolom tidak menolong bila seluruh disk disalin. Pendekatan yang realistis justru menggabungkan lapisan sesuai data yang dilindungi, lalu meninjau ulang kombinasinya setiap kali arsitektur aplikasi berubah.