Belajar Authentik - Events & Auditing

#Pendahuluan

Episode 21 menunjukkan otomatisasi. Semakin banyak yang berjalan otomatis, semakin penting jejak audit — siapa melakukan apa, kapan, dan dari mana. Episode 22 membahas event log dan auditing: membaca event, memeriksa system task, mengekspor lewat API, mengintegrasikan ke SIEM, dan membuat alert pada anomali.

Analoginya seperti kamera dan buku tamu di gedung. Semua orang boleh masuk dan keluar, tetapi harus ada catatan: siapa, kapan, dan ke mana. Saat insiden terjadi, catatan itulah bukti pertama yang kalian buka.

#Sistem Event Log

Setiap aksi penting di Authentik menghasilkan event: catatan JSON berisi informasi seperti action, pengguna terkait, aplikasi, alamat IP, dan metadata konteks. Event tersimpan di database dan bisa dicari serta difilter dari UI.

Karena jumlahnya bisa besar, perhatikan masa retensi dan pembersihan berkala — mempertahankan semua event tanpa batas akan membengkakkan database seiring waktu.

#Jenis-Jenis Event

Beberapa action yang paling berguna untuk diaudit:

Action	Arti
`login`	Autentikasi berhasil
`login_failed`	Autentikasi gagal
`logout`	Pengguna keluar
`user_creation`	Pengguna baru dibuat
`user_update`	Data pengguna diubah
`authorize_application`	Aplikasi mengakses sumber daya
`model_created`, `model_updated`, `model_deleted`	Perubahan konfigurasi
`policy_execution`	Hasil evaluasi kebijakan
`system_task_execution`	Tugas latar dijalankan
`system_exception`	Error internal

Memahami kategori ini membantu kalian tahu ke mana harus mencari saat menyelidiki sebuah masalah — seperti tahu halaman mana dari buku tamu yang harus dibuka.

#Memeriksa Event

Events → Logs di admin menyediakan pencarian dan filter berdasarkan action, pengguna, atau aplikasi.
Klik sebuah event untuk melihat detail JSON, termasuk konteks seperti alamat IP atau alasan penolakan policy.

Kebiasaan yang baik: setiap kali kalian merasa aneh dengan perilaku login, mulai dari sini dulu sebelum menyentuh konfigurasi.

#System Tasks dan Error Logs

Tidak semua hal berjalan di jalur utama. Authentik menjalankan system tasks — tugas latar seperti sinkronisasi source, eksekusi event rule, dan tugas berkala lainnya:

Lihat statusnya di Events → System Tasks: successful, running, atau error.
Kesalahan internal muncul sebagai event system_exception; kombinasi keduanya adalah titik awal troubleshooting yang baik (dibahas lebih dalam di episode 28).

#Ekspor Event via API

Event juga bisa diambil lewat API — misalnya dari endpoint /api/v3/events/events/ — untuk dianalisis di luar Authentik:

Ambil event login gagal via API

curl -s "https://auth.example.com/api/v3/events/events/?action=login_failed" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  | jq '.results[] | {action, user: .user.username, client_ip, created}'

Dengan endpoint core/reputation dari episode 19 dan daftar event ini, kalian punya bahan untuk memetakan pola serangan secara data-driven.

#Event Rules dan Alert

Authentik bisa bereaksi terhadap event secara otomatis lewat Event Rules (menu Events → Rules). Cara kerjanya: aturan berisi kebijakan event matcher untuk memilih event, lalu menjalankan aksi — misalnya mengirim notifikasi email atau webhook. Contoh membuat matcher lewat blueprint:

Event matcher policy — login gagal

version: 1
entries:
  - model: authentik_policies_event_matcher.eventmatcherpolicy
    identifiers:
      name: event-matcher-login-failed
    attrs:
      action: login_failed

Matcher ini lalu diikat ke sebuah event rule di UI bersama transport notifikasi pilihan kalian. Efeknya: setiap login_failed memicu alert tanpa perlu manusia memantau layar.

#Integrasi SIEM

Untuk lingkungan yang menuntut compliance, event perlu mengalir ke sistem sentral:

Pull — script menjadwalkan ekspor dari /api/v3/events/events/ ke pipeline log (misalnya Loki atau ELK).
Push — transport webhook pada event rule mendorong event real-time ke penerima seperti Slack, atau langsung ke SIEM.
Simpan event selama periode yang disyaratkan aturan organisasi kalian, dan rutin verifikasi bahwa alur pengiriman masih berfungsi.

#Alert pada Anomali

Kombinasi yang sering dipakai:

Alert pada login_failed berulang untuk akun istimewa, misalnya akadmin.
Alert saat authorize_application dari aplikasi yang tidak dikenal.
Dashboard yang membandingkan lonjakan login_failed per IP sebagai indikasi serangan brute force.

Ingat: tujuan alert adalah mengurangi kebisingan, bukan menambahkannya. Pilih pola yang benar-benar membutuhkan perhatian manusia.

Tip

Uji event rule kalian: trigger satu login gagal secara sengaja dan pastikan notifikasi tiba. Alert yang tidak pernah diuji nilainya sama dengan tidak ada alert.

#Penutup

Ringkasan episode 22:

Event log mencatat action, pengguna, IP, dan konteks dalam JSON.
System tasks dan system_exception menjadi titik awal troubleshooting.
Event diekspor lewat API, didorong lewat webhook, atau ditarik oleh SIEM.
Event matcher dan event rule membuat alert otomatis atas anomali.

Di episode 23, kita memastikan semua itu tetap menyala: high availability dengan replika server, worker, dan data layer yang berbagi beban. Sampai jumpa!