Kenapa Data Kafe Kamu Aman dari Kafe Sebelah: Cara Kami Menjaga Keamanan Multi-Tenant
Di sistem multi-tenant, semua bisnis berbagi infrastruktur yang sama. Tapi data mereka? Harus benar-benar terpisah. Ini cara kami memastikan data kamu nggak pernah bocor ke bisnis lain.
Apa Itu Multi-Tenant dan Kenapa Kami Pakai
Multi-tenant artinya banyak bisnis (tenant) berjalan di satu infrastruktur yang sama — server yang sama, database yang sama, codebase yang sama. Ini model standar untuk SaaS modern, dan ada alasan bagus: lebih efisien, lebih murah untuk di-maintain, dan update bisa di-deploy ke semua pengguna sekaligus.
Tapi model ini menimbulkan pertanyaan yang valid: kalau semua bisnis di infrastruktur yang sama, bagaimana data satu bisnis dilindungi dari bisnis lain?
Lapisan Pertama: Query Scoping Otomatis
Setiap query database yang terjadi di CrescendPOS secara otomatis di-scope ke tenant yang sedang aktif. Ini bukan sesuatu yang developer harus ingat setiap kali nulis kode — ini built into the framework. Setiap query yang berjalan otomatis difilter: "hanya tampilkan data milik tenant ini."
Ini berarti bahkan kalau ada bug di kode kami, query nggak akan pernah return data dari tenant lain — karena filter tenant-nya diterapkan di level yang lebih dalam dari kode aplikasi biasa.
Lapisan Kedua: URL-Based Tenant Resolution
Setiap bisnis punya URL unik: /tenants/nama-bisnis-kamu/*. Tenant ditentukan dari URL ini sebelum kode apapun berjalan. Ini berarti nggak ada cara untuk "masuk" ke tenant lain — kamu hanya bisa mengakses data sesuai tenant yang ada di URL kamu.
Lapisan Ketiga: Authentication Berlapis
Ada empat lapisan autentikasi yang masing-masing melindungi level akses berbeda:
- Devise (email + password): Untuk akses admin dan dashboard
- PIN kasir: Untuk akses POS di level operasional
- 2FA (TOTP): Opsional tapi bisa diwajibkan per tenant — untuk keamanan ekstra
- API Bearer Token: Untuk integrasi — setiap token terikat ke satu tenant
Setiap lapisan didesain untuk konteks penggunaannya masing-masing. Admin pakai password yang kuat. Kasir pakai PIN yang cepat. API pakai token yang bisa di-revoke kapan saja.
Lapisan Keempat: Audit Trail
Setiap perubahan data yang sensitif — update menu, void transaksi, perubahan harga — dicatat di audit log. Log ini mencatat siapa yang melakukan perubahan, kapan, dan apa yang berubah. Audit log ini juga ter-scope per tenant — log bisnis A nggak bisa dilihat oleh bisnis B.
Apa yang Kami Nggak Lakukan
Kami nggak bisa lihat PIN kasir kamu. PIN di-hash dengan bcrypt. Bahkan developer kami nggak bisa membacanya dari database.
Kami nggak bisa akses data bisnis kamu tanpa alasan. Akses ke data tenant hanya terjadi untuk debugging yang terlegitimasi — dan itu pun ter-log.
Kami nggak share data antar tenant. Nggak ada fitur "lihat benchmarking industri" yang menggunakan data tenant lain. Data kamu milik kamu.
Kenapa Ini Penting untuk Kamu
Sebagai pemilik bisnis, data penjualan kamu itu sensitif. Harga menu, volume penjualan, margin — ini informasi yang kompetitor nggak boleh tahu. Dan di sistem multi-tenant, jaminan bahwa data ini terisolasi itu bukan nice-to-have — itu fundamental.
Kami membangun keamanan ini bukan sebagai fitur yang di-market — tapi sebagai fondasi yang nggak bisa ditawar. Karena kepercayaan pengguna itu dasar dari segalanya.