Cegah penyalahgunaan dan kebocoran data

Pertanyaan

Siapa yang bisa melakukan apa pada data siapa, dan di mana batas itu paling gampang bocor?

Setelah baca ini, kamu bisa membuat threat model ringan untuk satu layanan multi-tenant, menemukan tempat otorisasi biasanya terlewat, dan memilih kontrol yang sepadan dengan risikonya.

Prasyarat dan contoh

Kamu sudah paham layanan, basis data, dan batas antar-komponen dari modul sebelumnya, serta proteksi overload di M16.02. Lesson ini bukan kursus keamanan lengkap. Ini kerangka berpikir buat rancangan sistem.

Contoh: API faktur multi-tenant punya endpoint GET /faktur/8841. Autentikasi memastikan pemanggil sudah login. Tapi handler mengambil faktur berdasarkan id saja, tanpa mengecek bahwa faktur itu milik tenant pemanggil. Pelanggan A mengganti id jadi 8842 dan membaca faktur pelanggan B. Autentikasi benar, otorisasi hilang. Ini disebut IDOR (insecure direct object reference), salah satu kelas bug paling umum.

Mekanisme

Threat model menjawab empat pertanyaan: apa yang kita lindungi (aset), dari siapa (penyerang), lewat jalur apa (permukaan serangan), dan apa kontrolnya. Mulai dari diagram aliran data: tandai batas kepercayaan (internet ke API, API ke database, layanan ke layanan, tenant ke tenant) dan tanya per batas "apa yang terjadi kalau pihak di seberang berbohong atau disusupi".

Kerangka STRIDE membantu daftar ancaman: pemalsuan identitas, perusakan data, penyangkalan, pengungkapan informasi, kehabisan layanan (DoS), dan eskalasi hak akses.

Otorisasi per objek, di sisi server, di setiap akses. Cek tenant_id dan hak pengguna di setiap query, bukan di UI. Cara yang kuat: jadikan tenant_id bagian dari kunci dan wajib di setiap query lewat lapisan data bersama, atau pakai row-level security di database sehingga query tanpa konteks tenant nggak mengembalikan apa-apa. Prinsip hak minimum berlaku juga buat layanan: kredensial layanan laporan cukup bisa baca, bukan tulis.

Isolasi tenant punya spektrum. Skema bersama dengan kolom tenant_id itu murah tapi satu bug query bisa membocorkan lintas tenant. Skema atau database per tenant mengurangi radius kerusakan tapi menambah biaya operasi (migrasi 5.000 database). Tenant besar atau teregulasi sering mendapat isolasi lebih kuat. Isolasi juga mencakup sumber daya: satu tenant yang menghabiskan koneksi atau CPU nggak boleh menjatuhkan yang lain (kuota per tenant, lihat M16.02).

Secret. Kredensial, token API, dan kunci enkripsi nggak masuk repositori atau gambar kontainer. Simpan di secret manager, ambil saat runtime, beri masa berlaku pendek jika bisa, dan rancang rotasi dari awal: kalau rotasi satu secret butuh deploy dan menggantikan di 14 tempat, kamu akan menundanya sampai bocor. Pisahkan secret per lingkungan.

Data sensitif di log dan telemetri. Log yang berisi token, password, nomor kartu, atau isi dokumen menjadi salinan data sensitif dengan kontrol akses yang jauh lebih longgar dan retensi lebih panjang. Sanitasi di sumber (daftar field yang disamarkan), jangan log body request mentah, dan batasi akses ke sistem log. Metrik dan trace juga bisa membawa PII lewat label atau atribut.

Penghapusan. "Hapus" berarti beberapa hal: baris di basis data, salinan di replika, cache, indeks pencarian, backup, dan ekspor analitik. Putuskan kebijakan: hapus langsung atau tandai lalu hapus fisik setelah 30 hari; backup yang tak bisa diubah dibiarkan kedaluwarsa sesuai retensi dan pemulihan wajib menerapkan ulang daftar penghapusan. Catat dan uji, karena penghapusan yang tak terverifikasi cuma niat.

Kehabisan sumber daya sebagai penyalahgunaan. Unggahan 5 GB, query yang mengembalikan 10 juta baris, regex yang eksplosif, dan "zip bomb" bisa menjatuhkan layanan tanpa membobol apa pun. Kontrol: batas ukuran dan waktu, paginasi wajib, kuota per tenant, dan batas kedalaman/ukuran pada input berstruktur.

Saat rancangan ini gagal

• Hanya autentikasi, tanpa otorisasi objek. Seperti contoh IDOR di atas. Id berurutan memudahkan penebakan, tapi id acak bukan kontrol akses. Itu cuma menyulitkan.
• Cek hak akses di klien. Tombol disembunyikan, tapi API tetap menerima permintaan.
• Otorisasi tersebar. Setiap handler mengecek sendiri-sendiri, dan satu endpoint baru lupa. Pusatkan di lapisan bersama dan uji dengan tes yang mencoba akses lintas tenant.
• Layanan internal dipercaya penuh. Satu layanan yang disusupi lalu bebas membaca semua. Autentikasikan antar-layanan dan batasi hak per layanan.
• Secret di log, repositori, atau variabel yang tercetak di halaman error.
• Penghapusan setengah jalan. Pengguna dihapus dari basis data utama, tapi masih di indeks pencarian dan ekspor mingguan.
• Kontrol yang melebihi risiko. Enkripsi per-field dan HSM untuk data yang tidak sensitif menambah kompleksitas tanpa mengurangi risiko nyata.

Contoh tandingan: row-level security bagus buat isolasi, tapi tidak melindungi dari bug di layanan yang menjalankan query sebagai superuser (yang melewati RLS). Kontrolnya hanya sekuat konteks yang membawanya.

Latihan

Layanan unggah dokumen multi-tenant: POST /dokumen (unggah ke object storage), GET /dokumen/{id} (mengembalikan URL unduh bertanda tangan), dan DELETE /dokumen/{id}. Log aplikasi mencatat seluruh header dan body request. Satu tenant mengunggah 50 GB dalam satu jam.

1. Temukan tiga ancaman beserta kontrolnya.
2. Bagaimana kamu menguji bahwa isolasi tenant benar?
3. Apa yang perlu diputuskan soal DELETE?

Lihat pembahasan+

1. Tiga ancaman:
   • IDOR pada GET dan DELETE. Kontrol: query selalu menyertakan tenant_id dari token yang sudah terautentikasi, bukan dari parameter klien. Respons 404 buat objek tenant lain, supaya keberadaannya tidak bocor. URL unduh bertanda tangan berumur pendek (mis. 5 menit) dan terikat ke objek itu.
   • Kebocoran lewat log. Header Authorization dan isi dokumen tercatat. Kontrol: jangan log body, samarkan header sensitif, batasi akses dan retensi log.
   • Kehabisan sumber daya. 50 GB per jam dari satu tenant menghabiskan penyimpanan dan bandwidth. Kontrol: batas ukuran per file, kuota harian per tenant, rate limit per tenant, dan alert saat kuota terpakai 80%.
2. Tes otomatis lintas tenant: buat dua tenant, dengan A membuat dokumen, lalu B mencoba GET dan DELETE memakai id A dan harus mendapat 404. Jalankan di CI untuk setiap endpoint baru. Tambahkan tes bahwa query tanpa konteks tenant gagal atau kosong.
3. Putuskan: hapus langsung atau tunda (mis. tandai dan hapus fisik setelah 30 hari agar bisa dibatalkan), bagaimana objek di object storage, cache, dan indeks ikut terhapus, bagaimana backup menangani dokumen terhapus (kedaluwarsa sesuai retensi, dan daftar penghapusan diterapkan ulang saat restore), serta catatan audit siapa yang menghapus apa.

Kontrol paling murah di sini: tenant_id dari token, bukan dari request.

Terkait

• M16.02 Batasi overload membahas kuota dan rate limit per tenant.
• M16.04 Lakukan pemulihan, bukan sekadar berasumsi menyangkut backup dan penghapusan.
• M16.06 Tangani insiden dan tinjau rancangan menjelaskan respons kalau kebocoran terjadi.

Catatan

• Asumsi: aplikasi web atau API multi-tenant dengan identitas pengguna yang sudah ada.
• Ini panduan rancangan, bukan nasihat hukum. Kewajiban retensi dan penghapusan (mis. peraturan perlindungan data) berbeda per yurisdiksi dan industri.
• Yang nggak dibahas: kriptografi terperinci, pengelolaan identitas (OAuth/OIDC), keamanan rantai pasok, dan pengujian penetrasi.
• Terakhir ditinjau: 26 Oktober 2026.