Audit Log yang Beneran Kepake (Bukan Pajangan)

Cerita singkat: role berubah, akses chaos, tapi ketolong audit log

Pernah ada kasus akses user tiba-tiba berubah, padahal “gak ada yang ngerasa ngubah”. Dampaknya lumayan ngeselin: beberapa orang kehilangan akses, yang lain malah kebuka akses yang harusnya ketutup.

Ternyata ada perubahan role yang kebawa dari flow admin yang kelihatan innocent. Begitu dicek audit log, kelihatan jelas actor-nya siapa, action-nya apa, target-nya user mana, dan yang paling penting: reason-nya kosong padahal aksi sensitif.

Akhirnya akar masalahnya ketemu: UI admin waktu itu belum maksa reason untuk perubahan role, jadi orang ngubah sambil multitasking dan lupa konteksnya. Sejak itu, perubahan sensitif selalu minta reason dan audit log jadi rujukan utama, bukan tempat “kira-kira”.

Audit Log Minimal yang Kepake

• actor_id: siapa yang melakukan aksi, biar gak ada debat “bukan gue”.

• action: verb yang konsisten (mis. role.update, invite.create), biar filter dan analytics-nya rapih.

• target_type: objek apa yang diubah (mis. user, project, settings), biar konteks kebaca cepat.

• target_id: ID target yang spesifik, biar bisa deep-link ke detail data.

• summary: kalimat pendek yang manusia bisa pahami dalam 2 detik.

• created_at: timestamp dari server, bukan dari client yang bisa “kreatif”.

• reason: wajib untuk aksi sensitif (role, permission, invite revoke), biar “kenapa” gak hilang.

• diff: daftar keys yang berubah (bukan full payload), biar aman dan tetap informatif.

Append-only itu harga mati

Audit log itu harus append-only. Kalau bisa di-update atau di-delete, itu bukan audit log, itu “catatan yang bisa diedit pas panik”.

Kalau ada orang minta fitur “hapus audit log biar bersih”, itu biasanya bukan soal kebersihan, itu soal menghapus jejak. Sistem boleh punya bug, tapi jangan kasih dia kemampuan buat pura-pura gak pernah terjadi.

UI Audit yang enak dipake

• Search: cari by target_id, email, atau keyword summary, karena manusia males scroll.

• Filter actor/action: cepat banget buat narrowing, terutama pas ada banyak admin.

• Time range: “kejadian tadi pagi” itu bukan parameter teknis, jadi UI harus bantu.

• Detail view: klik satu event, lihat reason + diff + link ke target, selesai dalam 10 detik.

Anti-patterns yang bikin audit log useless

• Logging secrets (token, API key, password) itu bunuh diri pelan-pelan.
  Solusinya: blocklist keys sensitif dan simpan cuma diff keys, bukan value rahasia.

• Log terlalu noise sampai yang penting ketutup.
  Solusinya: log yang “decision-grade” untuk aksi penting, bukan setiap render tombol.

• Audit log bisa dihapus atau di-edit.
  Solusinya: enforce append-only di DB + RLS, delete/update dimatiin untuk semua role aplikasi.

• Aksi sensitif tanpa reason, jadi timeline kehilangan konteks.
  Solusinya: wajibkan reason di UI + validasi di API untuk action tertentu.

Kode: Next.js API route POST /api/audit ke Supabase

import { NextResponse } from "next/server";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

const BLOCKED_KEYS = ["password", "token", "secret", "apiKey", "access_token", "refresh_token"];

function sanitizeDiff(diff?: string[]) {
  const safe = (diff ?? []).filter((k) => {
    const lower = k.toLowerCase();
    return !BLOCKED_KEYS.some((b) => lower.includes(b));
  });
  return safe.slice(0, 30); 
}

export async function POST(req: Request) {
  const body = await req.json().catch(() => null);
  if (!body) return NextResponse.json({ ok: false }, { status: 400 });

  const { actor_id, action, target_type, target_id, summary, reason, diff } = body;

  if (!actor_id || !action || !target_type || !target_id || !summary) {
    return NextResponse.json({ ok: false }, { status: 422 });
  }

  const sensitive = ["role.update", "permission.update", "invite.revoke"];
  if (sensitive.includes(action) && (!reason || String(reason).trim().length < 5)) {
    return NextResponse.json({ ok: false }, { status: 422 });
  }

  const payload = {
    actor_id: String(actor_id),
    action: String(action),
    target_type: String(target_type),
    target_id: String(target_id),
    summary: String(summary).slice(0, 140),
    reason: reason ? String(reason).slice(0, 200) : null,
    diff: sanitizeDiff(Array.isArray(diff) ? diff : []),
    created_at: new Date().toISOString(),
  };

  const { error } = await supabase.from("audit_events").insert(payload);
  if (error) return NextResponse.json({ ok: false }, { status: 500 });

  return NextResponse.json({ ok: true });
}

COPY THIS

• Audit event selalu append-only (no update/delete)

• Field wajib ada: actor_id, action, target_type, target_id

• Summary dibuat human-readable dan pendek

• created_at selalu dari server, bukan client

• reason wajib untuk aksi sensitif (role/permission/invite)

• diff hanya keys yang berubah, bukan full payload

• Secrets diblok (token/password/apiKey dkk) sebelum masuk log

• UI punya search yang beneran cepet dipake

• UI punya filter actor/action + time range

• Detail view punya link ke target + tampilkan reason/diff

Audit log yang bagus bikin debugging jadi tenang, bukan sesi saling tuduh. Dan yang lebih penting: keputusan di sistem kamu bisa ditrace tanpa drama.

Kalau kamu care sama maintainability, audit log itu bukan “nice to have”. Itu rem tangan di jalan menurun.