Bagaimana Databasus menerapkan keamanan?

Databasus bertanggung jawab atas data sensitif:

  • mengakses database kamu;
  • membuat backup database (artinya menyalin data);
  • menyimpan kredensial agar bisa mengakses database secara berkala;
  • menyimpan backup di S3 atau penyimpanan cloud lain milik kamu (jika diaktifkan);

Karena itu, keamanan dan keandalan tingkat enterprise menjadi prioritas utama Databasus.

Tujuannya untuk memastikan:

  • data sensitif tidak pernah terekspos dan selalu dienkripsi;
  • backup terenkripsi dan tidak berguna bagi orang yang menemukannya di penyimpanan cloud;
  • Databasus bahkan tidak mendapat akses database dengan izin menulis atau memperbarui data;
  • semua tindakan dicatat dan bisa diaudit;

Semua langkah ini melindungi data kamu. Tidak ada sistem yang 100% aman, tetapi kami berusaha membuatnya seaman mungkin. Bahkan jika terjadi peretasan, tidak ada yang bisa merusak data kamu.

Databasus menerapkan keamanan pada tiga lapisan:

  1. Enkripsi data sensitif;
  2. Enkripsi backup;
  3. Akses database hanya-baca.

Lapisan 1: enkripsi data sensitif

Secara internal, Databasus memakai database PostgreSQL untuk menyimpan detail koneksi, konfigurasi, serta pengaturan kanal notifikasi dan penyimpanan (S3, Azure Blob Storage, FTP, dll.).

Semua data sensitif dienkripsi. Contohnya:

  • kata sandi
  • token
  • webhook yang berisi secret

Jadi, di database, Databasus hanya menyimpan hash atau nilai yang sudah dikodekan. Enkripsi memakai algoritma AES-256-GCM. Selain dienkripsi, nilai-nilai ini juga tidak pernah ditampilkan lewat API atau antarmuka.

Kunci rahasia untuk enkripsi disimpan di penyimpanan lokal (secara default ./databasus-data/secret.key), bukan di dalam database. Jadi, database yang disusupi tidak memberikan akses ke data sensitif.

Lapisan 2: enkripsi backup

Setiap file backup langsung dienkripsi selama proses pembuatannya. Databasus memakai algoritma enkripsi AES-256-GCM, sehingga data backup tidak bisa dibaca tanpa kunci enkripsi dan setiap manipulasi terdeteksi saat dekripsi.

Backup melewati alur berikut:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Setiap backup mendapat kunci enkripsi unik yang diturunkan dari:

  • Kunci utama (disimpan di ./databasus-data/secret.key)
  • ID backup
  • Salt acak (unik untuk setiap backup)

Hasilnya: Sekalipun seseorang mendapat akses ke penyimpanan cloud kamu (S3, Azure Blob Storage, dll.), mereka tidak bisa membaca backup tanpa kunci utama.

Lapisan 3: akses database hanya-baca

Databasus menerapkan prinsip hak akses minimum. Untuk membuat backup, Databasus hanya memerlukan akses baca, tidak pernah akses tulis. Ini melindungi database dari kerusakan data yang disengaja maupun tidak disengaja melalui alat backup.

Sebelum menerima kredensial database, Databasus melakukan pemeriksaan pada tiga tingkat:

  1. Tingkat role: Memastikan pengguna BUKAN superuser dan tidak bisa membuat role atau database
  2. Tingkat database: Memastikan tidak ada hak akses CREATE atau TEMP
  3. Tingkat tabel: Memastikan tidak ada izin tulis (INSERT, UPDATE, DELETE, TRUNCATE, dll.)

Pengguna database harus lolos ketiga pemeriksaan agar dianggap hanya-baca. Jika izin tulis terdeteksi, Databasus akan memberi peringatan.

Databasus menawarkan pembuatan pengguna hanya-baca dengan izin yang sesuai:

  • Memberikan SELECT pada semua tabel yang sudah ada maupun yang akan dibuat
  • Memberikan USAGE pada schema (tetapi bukan CREATE)
  • Secara eksplisit mencabut semua hak akses tulis

Hasilnya: Sekalipun Databasus disusupi, server diretas, kunci rahasia dicuri, dan kredensial didekripsi, penyerang tidak bisa merusak database kamu.

Autentikasi dua faktor saat masuk

Kata sandi saja membuka akses ke semua kredensial database, kunci penyimpanan, dan backup yang disimpan instance. Karena itu, administrator bisa mewajibkan faktor kedua saat masuk dengan kata sandi. Jika aktif, memasukkan kata sandi yang benar akan mengirim kode enam digit ke alamat email akun. Proses masuk baru selesai setelah kode dimasukkan. Kode kedaluwarsa sepuluh menit setelah dikirim, dibuang setelah lima tebakan salah, dan diganti jika kode baru diminta. Mengaktifkan pengaturan ini melindungi proses masuk berikutnya tanpa menghentikan sesi yang sudah terbuka.

Pengaturan ini berlaku untuk proses masuk dengan kata sandi. Masuk lewat Google atau GitHub tetap langsung menerbitkan token karena penyedia tersebut menjalankan pemeriksaan multi-faktor sendiri. Instance yang ingin faktor kedua berlaku bagi semua pengguna tidak mengonfigurasi kedua penyedia itu.

Pengaturan ini hanya bisa diaktifkan jika instance memiliki server email dan setiap administrator aktif memiliki alamat email asli, agar tidak ada yang mengaktifkannya lalu membuat instance tidak bisa diakses. Jika server email kemudian berhenti mengirimkan email, tidak ada yang bisa masuk dengan kata sandi. Ini disengaja: kegagalan server email tidak boleh diam-diam menurunkan autentikasi menjadi satu faktor. Operator dengan akses shell di server bisa menonaktifkannya kembali:

docker exec -it databasus ./main --disable-2fa

Perintah melaporkan perubahan dan mencatatnya di log audit, sehingga alasan instance berhenti meminta kode tetap tercatat. Perintah ini didokumentasikan bersama pemulihan kata sandi di halaman kata sandi.

🛡️ Rekayasa keamanan dan keandalan

Databasus menangani data sensitif. Sebelum setiap rilis, pemeriksaan otomatis mencari masalah keamanan dan memastikan backup bisa di-restore. Pemeriksaan ini mengurangi risiko, tetapi tidak menjamin perangkat lunak bebas kerentanan.

Analisis statis

CodeQL memeriksa Go, JavaScript/TypeScript, dan workflow GitHub Actions. gitleaks mencari secret yang bocor dalam riwayat Git untuk rilis tersebut. semgrep memeriksa kode sumber, Dockerfile, dan workflow CI berdasarkan aturan keamanan. Pemindaian ini berjalan sebelum setiap rilis dan setiap minggu.

Temuan CodeQL tingkat CRITICAL yang masih terbuka pada analisis rilis memblokir publikasi. Temuan HIGH menghasilkan peringatan.

Codex Security dari OpenAI juga melakukan audit berkala yang lebih mendalam. Audit ini dapat menemukan masalah arsitektur yang terlewat oleh pemindaian yang lebih khusus. Audit dilakukan terpisah dari pemeriksaan rilis otomatis.

Pengelolaan dependency

Pembaruan biasa menunggu tujuh hari penuh untuk paket, alat pengembangan, dan GitHub Actions. Image, klien database, dan ekstensi verifikasi mandiri menunggu empat belas hari. Pengelola memeriksa tanggal publikasi dan kompatibilitas, termasuk versi yang ditetapkan secara pasti dan pembaruan keamanan yang bisa melewati filter umur rilis. Setiap pengecualian dilaporkan beserta alasannya.

Dependency Review Action membandingkan calon rilis dengan rilis sebelumnya dan memblokir kerentanan baru tingkat HIGH atau CRITICAL. govulncheck menggagalkan pemeriksaan Go jika kode kami dapat memanggil fungsi dengan kerentanan yang diketahui. Perintah go mod verify membandingkan modul Go yang diunduh dengan checksum yang tercatat.

Sebelum publikasi rilis dan image pengembangan, mise run verify-deps memeriksa versi tetap alat, image, dan GitHub Actions. Perintah ini juga memeriksa kecocokan versi lingkungan runtime yang terkait, serta hash dan izin eksekusi klien database dalam repositori. Pemeriksaan ini mencakup daftar deklarasi dan file lokal yang telah ditentukan. Pengelola paket secara terpisah memeriksa versi dalam lock file dan checksum paket yang diunduh.

Pemeriksaan dependency lokal tidak menjamin keamanan kode pihak ketiga atau menerapkan batas umur publikasi untuk setiap dependency. Pemilihan dan peninjauan rilis tetap menjadi tanggung jawab pengelola.

Keamanan container dan CI

  • Trivy memindai image aplikasi pada amd64 dan arm64. Kerentanan CRITICAL dengan perbaikan yang tersedia menggagalkan pemeriksaan. Kerentanan HIGH dengan perbaikan dilaporkan tanpa memblokirnya. Kerentanan yang belum memiliki perbaikan dikecualikan dari pemeriksaan ini.
  • Pemindaian konfigurasi Trivy yang terpisah memblokir temuan HIGH dan CRITICAL pada Dockerfile aplikasi, agen verifikasi, dan image pengujian tertentu.
  • GitHub Actions pihak ketiga dipatok ke SHA commit lengkap. Perubahan tag tidak dapat diam-diam mengganti kode action yang dijalankan.
  • Workflow secara default hanya memiliki akses baca ke repositori. Setiap job mendapat izin tambahan hanya saat diperlukan.

Pengujian dan verifikasi

Unit test dan integration test mencakup perilaku kritis. Sebelum setiap rilis, siklus backup dan restore lengkap berjalan pada container database sungguhan untuk setiap engine dan versi mayor yang didukung. Pengujian memastikan data bisa di-restore, bukan sekadar file backup berhasil dibuat.

Pemeriksaan rilis juga mencakup lint, pemeriksaan tipe, pengujian browser, smoke test image, serta build dan pengujian native pada amd64 dan arm64. Publikasi menunggu semua job wajib lolos, termasuk pemeriksaan keamanan di atas.

Melaporkan kerentanan

Laporkan kerentanan secara privat melalui pilihan kontak dalam SECURITY.md. Jangan membuka issue publik. Laporan keamanan ditangani lebih dahulu.