Rate limit dan audit log

Mencegah penyalahgunaan dan meninggalkan jejak

Dalam sistem yang mengelola akun dan hak akses, dua pertanyaan keamanan selalu muncul: bagaimana menahan seseorang yang mencoba menebak password ribuan kali, dan bagaimana melacak siapa yang kemarin mengubah izin suatu role? Jawabannya adalah gabungan pembatas laju (rate limiter) dan pencatat jejak audit (audit log).

Rate limiter PostgreSQL dengan cadangan memori

Alih-alih hanya menyimpan hitungan request di variabel memori yang hilang saat server di-restart, pembatas laju utama disimpan di tabel rate_limit_buckets menggunakan transaksi upsert atomik. Namun jika koneksi database kebetulan sedang padat atau terputus, ia otomatis beralih ke penyimpanan memori agar aplikasi tidak ikut lumpuh:

try {
  // Atomic upsert di tabel rate_limit_buckets PostgreSQL
  await checkDatabaseRateLimit(key, limit, windowMs);
} catch (err) {
  if (err instanceof RateLimitError) throw err;
  // Fallback ke memori bila database sedang tidak terjangkau
  assertMemoryRateLimit(key, limit, windowMs);
}

Log audit harus jujur mencatat setiap perubahan penting, tetapi tidak boleh membocorkan rahasia atau menggagalkan transaksi utama.

Prinsip merancang Audit Log yang aman

• Bersifat append-only (hanya tambah): di antarmuka maupun di service, tidak ada fitur untuk mengubah atau menghapus baris audit_logs.
• Menyimpan salinan nama dan email aktor saat kejadian berlangsung, sehingga riwayat tetap terbaca jelas walaupun akun aktor tersebut kelak diubah namanya.
• Tidak pernah mencatat data rahasia seperti password, token sesi, atau secret MFA ke dalam kolom detail.
• Dibungkus blok try/catch tersendiri supaya kegagalan pencatatan log tidak membatalkan perubahan data bisnis yang sudah berhasil disimpan.

Ringkasnya

Rate limiting menghentikan serangan sebelum membebani sistem, sedangkan audit log dan catatan percobaan login memberi visibilitas penuh kepada administrator atas setiap peristiwa penting.