Belajar 2FA Authentication - Produksi: Deployment, Secrets & Observability

#Pendahuluan

Semua fitur sudah bekerja di localhost. Episode 20 menjawab pertanyaan yang jauh lebih tidak nyaman: apa yang terjadi saat ini berjalan di produksi, selama bertahun-tahun, dengan pengguna sungguhan. Tiga hal yang menentukan: konfigurasi secret yang benar, observability yang aman, dan alerting yang menangkap anomali.

Rahasia 2FA di produksi tidak terletak pada satu teknologi, tapi pada kedisiplinan: kunci enkripsi tidak pernah di source control, log tidak pernah memuat kode, dan peristiwa mencurigakan selalu memicu peringatan. Kalian akan menyusun ketiganya sebagai fondasi operasional.

#Deployment dan Environment

#Variabel Environment yang Wajib

Produksi membutuhkan konfigurasi yang terdokumentasi dan terenkripsi. Daftar minimumnya:

MFA_ENCRYPTION_KEY=9a3c2f4e1d0b7c6a5f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9a0b
SESSION_SECRET=panjangAcakTidakMudahDitebak
JWT_SECRET=panjangAcakBerbedaDariSession
DATABASE_URL=postgresql://devvnull:xxx@db.internal/devvnull
APP_ORIGIN=https://auth.devvnull.dev

Nilai MFA_ENCRYPTION_KEY harus 32 byte hex dan dibuat dengan generator acak, bukan diketik manual:

openssl rand -hex 32

Perintah openssl rand -hex 32 menghasilkan 64 karakter hex — tepat 32 byte entropy. Simpan nilainya di secret manager platform (Vercel, AWS Secrets Manager, atau GitHub Secrets), jangan pernah di file yang ter-commit.

#KMS untuk Kunci Enkripsi

Di skala tertentu, tarik kunci enkripsi dari KMS alih-alih environment. KMS menyediakan envelope encryption: aplikasi memegang data key sementara, sementara master key berada di KMS. Keuntungannya, rotasi dan audit akses kunci terpusat, dan satu kebocoran environment tidak langsung membocorkan kemampuan dekripsi.

#Backup dan Pemulihan

#Backup Terenkripsi

Backup database harus terenkripsi pada tingkat sistem — secret 2FA di dalamnya sudah terenkripsi aplikasi, tapi lapis kedua melindungi saat data dipindahkan dan disimpan. Gunakan enkripsi snapshot yang disediakan platform (EBS encryption, RDS encryption) dan salin ke lokasi terpisah untuk ketahanan bencana.

#Uji Pemulihan yang Nyata

Pulihkan backup berkala ke environment uji dan jalankan login dengan Google Authenticator sungguhan. Uji ini memverifikasi tiga hal sekaligus: backup tidak korup, kunci enkripsi tersimpan benar, dan seluruh alur tetap hidup setelah restore. Tim yang melakukan restore hanya saat darurat selalu menemukan kejutan di momen terburuk.

#Observability yang Aman

#Peristiwa MFA tanpa PII dan Kode

Log MFA harus memberi konteks untuk investigasi tanpa menyimpan data yang membahayakan. Gunakan struktur JSON dengan nama peristiwa yang konsisten:

Log peristiwa MFA yang aman

function logMfa(event, userId) {
  console.log(JSON.stringify({
    event,
    userId,
    ts: new Date().toISOString(),
    source: 'mfa'
  }));
}
 
logMfa('MFA_ENABLED', user.id);
logMfa('MFA_DISABLED', user.id);
logMfa('MFA_FAILED', user.id);

Pola logMfa memisahkan nama peristiwa dari detail respons. Tidak ada kode TOTP, secret, atau URI provisioning yang melewati log — hanya identitas pengguna dan peristiwa.

Tambahkan request id pada setiap baris agar log bisa dikorelasikan dengan trace saat insiden.

#Metrik dan Dashboards

Selain log, kumpulkan metrik: tingkat keberhasilan verifikasi, waktu rata-rata menyelesaikan enrollment, dan distribusi kegagalan per IP. Dashboard yang menampilkan tren ini memberi peringatan dini — lonjakan kegagalan MFA hampir selalu mendahului serangan atau bug.

#Alerting untuk Anomali

#Rate Limit dan Lonjakan Kegagalan

Alerting tidak menunggu manusia melihat dashboard. Aturan sederhana yang berdampak besar:

- rate limit 429 melampaui 50 per 5 menit per IP
- MFA_FAILED bertambah 3 kali lipat dari baseline 1 jam
- MFA_DISABLED 5 akun dalam 10 menit
- Login berhasil dengan recovery code dari IP baru

Pola terakhir — login recovery dari IP baru — adalah sinyal klasik pembajakan akun. Setiap aturan menargetkan skenario yang bisa ditindaklanjuti, bukan sekadar kebisingan.

#Respons yang Terdefinisi

Alert tanpa runbook hanyalah notifikasi. Tulis respons untuk setiap aturan: blokir IP pada rate limit, suspend akun saat pola MFA_DISABLED massal, dan hubungi pengguna saat login recovery mencurigakan. Prosedur yang tertulis membuat on-call tidak panik saat malam hari.

#Penutup

Episode 20 menyiapkan operasi produksi: environment dan KMS untuk kunci enkripsi, backup terenkripsi dengan uji pemulihan, observability yang bebas PII dan kode, serta alerting dengan runbook untuk setiap anomali.

Inti yang harus dibawa pulang:

• Simpan MFA_ENCRYPTION_KEY dan SESSION_SECRET di secret manager.
• Gunakan openssl rand -hex 32 untuk membuat kunci yang benar.
• Tarik kunci dari KMS untuk rotasi dan audit yang terpusat.
• Enkripsi backup dan uji pemulihan secara berkala.
• Log peristiwa MFA dalam JSON tanpa kode dan secret.
• Alerting dengan runbook untuk rate limit dan anomali login.

Di episode 21 selanjutnya kita akan membahas ekosistem 2026: provider dan authenticator apps — kapan memakai Clerk, Auth0, Supabase Auth, atau WorkOS versus membangun sendiri, serta kompatibilitas Google Authenticator, Microsoft Authenticator, Authy, dan 1Password.