Semua artikel
// Artikel

Logging Aman: Mencegah Kebocoran Data Sensitif

Dipublikasikan 3 Juli 2026

Log keamanan yang berguna menjelaskan kejadian penting tanpa menjadi salinan kedua data sensitif. CWE-532 membahas masuknya informasi sensitif ke berkas log. OWASP menyatakan log perlu menyimpan konteks cukup untuk monitoring dan investigasi, tetapi umumnya mengecualikan password, access token, session identifier, connection string, key enkripsi, data pembayaran, serta data pribadi sensitif. NIST SP 800-92 memberi panduan manajemen log tingkat organisasi; dokumen itu bukan bukti bahwa deployment tertentu sudah patuh.

Rancang kontrak event sebelum memanggil logger

Tentukan nama event, field yang diizinkan, klasifikasi, retensi, dan konsumennya. Jauhkan request body, authorization header, cookie, exception mentah, dan objek user penuh dari kontrak. Catat hasil, bukan payload. Interaction ID dapat menghubungkan event tanpa menyalin input pengguna. OWASP menganjurkan pencatatan kapan, di mana, siapa, dan apa, sambil memperlakukan data dari trust zone lain sebagai tidak tepercaya dan mensanitasinya sebelum output.

EventField bukti yang diizinkanPemilikLulus / gagal
auth.failuretimestamp, request ID, route, outcome, rate-limit bucketPemilik identitasLulus: tanpa password, token, atau username mentah
payment.declinedrequest ID, kelas provider, outcomePemilik pembayaranGagal: payload kartu atau body respons provider ada
dependency.errorrequest ID, nama dependency, kelas timeoutPemilik layananGagal: connection string atau stack trace pada log bersama
admin.role_changeactor ID, target ID, aksi, outcomePemilik kontrol aksesLulus: audit trail dapat dicari dan aksesnya dibatasi

Artefak operasional yang selesai adalah register field-event berversi yang ditautkan ke code review dan pengaturan retensi. Isinya nama field, nilai yang diizinkan, kelas data, pemilik, contoh output teredaksi, serta tanggal review terakhir. Jangan pakai secret nyata di contoh.

Pusatkan redaksi

Jangan bergantung pada ingatan setiap developer tentang data yang harus disembunyikan. Bangun event terstruktur, gunakan allowlist field, dan sanitasi nilai tak tepercaya sebelum serialisasi. Contoh TypeScript ini menghapus line break yang dapat memalsukan record dan membuang field sensitif bernama:

const blocked = new Set(["authorization", "cookie", "password", "token"]);
function audit(event: string, fields: Record<string, unknown>) {
  const safe = Object.fromEntries(Object.entries(fields)
    .filter(([key]) => !blocked.has(key.toLowerCase()))
    .map(([key, value]) => [key, String(value).replace(/[\r\n]/g, " ").slice(0, 160)]));
  console.log(JSON.stringify({ event, ...safe }));
}

audit("dependency.error", { requestId, dependency: "mail", errorClass: "timeout" });

Ini contoh, bukan redaksi universal. Objek bertingkat, URL berisi credential, objek error dari SDK, dan request dump framework membutuhkan review khusus. Pilih event builder bertipe daripada console.log(error) atau logger.info({ request }). Simpan penyebab error hanya pada storage diagnostik terlindungi jika kebutuhan operasional dan kontrol akses membenarkannya.

Uji isi dan mode gagal

Unit test perlu menyuntik marker sintetis seperti TEST_SECRET_NEVER_LOG ke header, cookie, request body, dan error yang dilempar. Output test tidak boleh memuat marker. Fuzz karakter newline dan delimiter untuk memastikan satu nilai pengguna tidak dapat membuat record log lain. Simulasikan collector mati, disk penuh, izin tulis ditolak, dan kegagalan serialisasi. OWASP meminta pengujian ketahanan terhadap log injection, kontrol akses, resource exhaustion, dan perilaku aplikasi ketika logging gagal. Kegagalan logging tidak boleh membocorkan detail atau mengubah traffic normal menjadi denial of service.

Akses, retensi, dan alur pengecualian

Pisahkan privilege pembaca log, penulis log, dan penghapus retensi. Kirim log dengan transport terenkripsi dan terautentikasi saat melewati trust boundary. Lindungi record tersimpan dari perubahan atau penghapusan tak sah, lalu monitor aksesnya. Retensi harus dinyatakan per kelas event; jangan simpan data lebih lama dari kebutuhan investigasi dan kebijakan yang disetujui. Review debug sink, console developer, backup, dan berkas ekspor insiden karena jalur itu dapat melewati retensi utama.

Saat tim membutuhkan detail tambahan sementara, pemilik mengajukan pengecualian berisi nama event, field tambahan tepatnya, tujuan, risiko, lokasi penyimpanan, kelompok pembaca, tanggal berakhir, kontrol kompensasi, dan tiket remediasi. Contoh: EXC-LOG-007 mengizinkan upstream request ID yang dipseudonimkan selama tujuh hari saat insiden provider. Pengecualian tidak mengizinkan header mentah atau nilai credential. Saat berakhir, konfigurasi dikembalikan dan pemilik melampirkan bukti penghapusan atau kedaluwarsa.

Penerimaan lulus bila register event ada, scan secret sintetis bersih, log tahan line injection, pembaca dibatasi, retensi dikonfigurasi, dan uji gagal menjaga perilaku aplikasi tetap aman. Gagal berarti hentikan akses yang terlalu luas, hapus field pelanggar, nilai paparan log yang sudah ada, rotasi credential yang tercatat, lalu ulangi uji bukti. Audit kode dapat menelusuri wrapper logging dan call site berisiko tinggi.

Tangkap bukti penutupan

Jalankan uji redaksi dengan marker sintetis unik pada header, cookie, objek bertingkat, URL, dan exception; cari pada collector, ekspor backup, serta console sink. Output yang diharapkan memuat event dan request ID, tetapi tanpa marker atau record newline sisipan. Lampirkan command pencarian, rentang waktu, nama sink, kelas retensi, pemilik, dan hasil lulus/gagal. Jika marker muncul, hentikan akses ekspor, hapus field pada batas builder, nilai salinan tersimpan, lalu ulangi setelah bukti penghapusan.

Review event dan penutupan

Ambil satu request login gagal lalu ikuti melalui edge, aplikasi, queue, dan sink observabilitas. Field event aman ialah waktu, ID korelasi request, kelas rute, outcome, dan kode error terbatas. Field tidak aman mencakup password, session cookie, authorization header, token reset, alamat IP mentah, serta seluruh request body. Di staging, kirim marker sintetis log-marker-7f3c hanya pada field yang wajib disensor, lalu cari di setiap sink log. Hasil diharapkan: event ada untuk traceability, marker tidak ditemukan, dan ID korelasi menghubungkan record tanpa mengungkap orang atau kredensial.

Kasus tepi muncul ketika structured logging menyensor pesan string tetapi nilai objek bertingkat tetap utuh. Uji serialisasi JSON, exception middleware, atribut tracing, dan breadcrumb SDK pihak ketiga secara terpisah. Kasus lain ialah export dukungan dari log tersimpan; kebijakan export harus mempertahankan sensor dan pembatasan akses sama.

Tutup review dengan allowlist field, output pencarian marker, pengaturan retensi, bukti akses berbasis peran, dan pemilik setiap sink. Buka ulang saat middleware, vendor telemetry, exception handler, atau rute pembawa data baru ditambah. Logging membuktikan operasi, bukan database alternatif untuk input sensitif.

Sources

Punya sistem yang perlu diuji?