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:
| Aspek | SEE | SQLCipher |
|---|---|---|
| Pengembang | Tim SQLite resmi (Hipp, Wyrick) | Komunitas open source (Zetetic) |
| Lisensi | Komersial, berbayar | Open source, gratis (BSD-style) |
| Algoritma | AES-256 dan beberapa skema lain | AES-256 |
| Kunci | Dari passphrase yang diberikan aplikasi | Dari passphrase, dapat di-rekey |
| Kegunaan khas | Sistem tertutup dengan dukungan resmi | Aplikasi 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:
sqlite3 toko.db "PRAGMA cipher_version;"Output yang Dihasilkan:
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:
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.dbOutput yang Dihasilkan:
data-paling-rahasiaEmpat 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: perintahgpg -c toko.dbmemintaYOUR_PASSPHRASElalu menghasilkantoko.db.gpgyang hanya bisa dibuka dengan passphrase yang sama. Alat modern sepertiagemenawarkan pola serupa dengan kunci publik. - Enkripsi tingkat kolom: aplikasi mengenkripsi nilai sensitif — nomor telepon, alamat, token — sebelum
INSERT, lalu menyimpan ciphertext sebagaiBLOB. Kunci dibaca dari environment variableYOUR_ENCRYPTION_KEY, bukan disimpan di database yang sama. Harga yang dibayar: kolom ini tidak lagi bisa dfilter denganWHEREatau diurutkan secara bermakna, karena engine SQLite hanya melihat byte acak.
Memilih Berdasarkan Model Ancaman #
Pilihan enkripsi bergantung pada apa yang ingin dilindungi:
| Model ancaman | Solusi paling pas |
|---|---|
| Laptop atau server fisik dicuri | Enkripsi filesystem (LUKS, FileVault, BitLocker) |
| Berkas backup bocor ke pihak lain | Backup terenkripsi (gpg, age) |
| Database ikut terunggah dari webroot | Simpan di luar webroot + izin ketat (Chapter Keamanan Berkas Database) |
| Penyimpanan bersama, banyak pihak satu mesin | SQLCipher atau SEE |
| Beberapa kolom sensitif di sistem multi-pengguna | Enkripsi 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.