Belajar Elasticsearch - Audit Logging & Compliance

#Pendahuluan

Autentikasi dan enkripsi membuat akses jadi aman. Tapi keamanan tidak lengkap tanpa akuntabilitas: jika terjadi insiden, kalian harus bisa menjawab "siapa yang mengakses apa, kapan, dan dengan hasil bagaimana?". Itulah peran audit logging — dan jawaban itu juga tuntutan hukum di banyak industri (GDPR, SOC 2, HIPAA).

Episode 17 membahas audit logging di Elasticsearch: mengaktifkannya, jenis-jenis event, format output (file dan index), filtering event agar tidak membebani storage, serta praktik compliance — GDPR, kebijakan retensi, penanganan data pribadi, dan pelacakan akses.

#Mengaktifkan Audit Logging

Audit logging adalah fitur keamanan Elasticsearch yang mencatat aktivitas terkait keamanan dan akses. Aktifkan di elasticsearch.yml:

xpack.security.audit.enabled: true
xpack.security.audit.logfile.events.include:
  - access_denied
  - access_granted
  - authentication_failed
  - connection_denied
  - run_as_granted
  - run_as_denied
  - anonymous_access_denied

Setelah restart, setiap event yang terpilih tercatat di file log audit. Karena fitur ini sensitif terhadap performa dan storage, aktifkan hanya event yang benar-benar kalian butuhkan.

#Audit Event Types

Event audit dikelompokkan dalam beberapa kategori:

#Output: File dan Index

#Output ke File

Default audit logging menulis ke file (logs/<cluster>-audit.log). Formatnya JSON per baris, mudah diparsing:

{"type":"audit","event_type":"authentication_success","principal":"arman","request.method":"POST","request.path":"/_security/user","result.type":"success"}

File cocok untuk pengarsipan offline dan analisis forensik.

#Output ke Index

Audit event juga bisa dikirim ke index audit khusus di dalam Elasticsearch sendiri — memudahkan pencarian dan dashboard. Konfigurasi tambahan:

xpack.security.audit.index.settings.enabled: true
xpack.security.audit.index.events.include: [access_denied, access_granted, authentication_failed]

#Filtering Audit Events

Tidak semua event layak dicatat — misalnya log health check yang muncul setiap detik. Filtering mengurangi noise dan storage:

xpack.security.audit.logfile.events.ignore_filters:
  health_check:
    users: ["system"]
    actions: ["access_granted"]
    paths: ["/_cluster/health", "/_nodes/stats"]

Dengan filter di atas, akses user system ke endpoint health check tidak masuk audit. Aturan praktis: filter selektif dan terdokumentasi — jangan sampai meniadakan manfaat audit. Security team biasanya menetapkan apa yang boleh difilter.

#Compliance: GDPR dan Pelacakan Akses

#Prinsip GDPR

GDPR (dan regulasi lain) menuntut tiga hal dari pengelola data pribadi:

• Kontrol akses — hanya pihak berwenang yang bisa mengakses data pribadi (episode 15: DLS/FLS, RBAC).
• Jejak akses — mampu menunjukkan siapa yang mengakses data siapa, kapan. Audit logging menjawab tuntutan ini.
• Hak penghapusan — kemampuan menghapus data seseorang saat diminta ("right to erasure"). Ini berarti pipeline data harus dirancang agar data pribadi bisa dihapus/tidak diindeks sejak awal.

#Kebijakan Retensi Data

Retensi bukan sekadar "simpan semua selamanya" — menyimpan data pribadi lebih lama dari yang dibutuhkan justru melanggar GDPR. Terapkan kebijakan retensi berlapis:

• Retensi fungsional — log yang dibutuhkan operasional: 30–90 hari.
• Retensi compliance — log audit dan arsip: 1–7 tahun sesuai regulasi.
• Anonimisasi — setelah masa fungsional, hapus atau anonimkan field pribadi (IP, email) alih-alih menghapus seluruh data.

Ini semua bisa diotomasi dengan ILM (episode 10) — fase delete di akhir siklus hidup, plus downsampling/anonimisasi untuk data yang perlu dipertahankan.

#Menangani Data Pribadi di Index

Sebelum data pribadi masuk Elasticsearch, tanyakan: apakah field ini benar-benar perlu diindeks? Gunakan pola berikut:

{
  "mappings": {
    "properties": {
      "email": { "type": "keyword", "index": false },
      "credit_card": { "type": "keyword", "index": false },
      "ip_address": { "type": "ip" }
    }
  }
}

Field index: false tidak bisa dicari — mematikan kemampuan pencarian field pribadi sejak mapping. Untuk data yang bahkan tidak boleh tampil di _source, gunakan ingest pipeline (episode 12) untuk menghapusnya sebelum masuk, atau FLS di episode 15.

#Kesalahan Umum

1. Aktifkan semua event. Storage dan performa jebol — pilih event yang relevan.

2. Audit log di cluster yang sama dengan data. Hilang saat insiden — pisahkan cluster atau archive.

3. Menyimpan data pribadi tanpa batas. Melanggar GDPR — terapkan retensi dengan ILM.

4. Filter yang terlalu agresif. Jejak audit jadi kosong — dokumentasikan dan setujui oleh security.

5. Mengindeks field pribadi yang bisa dicari. Pertimbangkan index: false atau hapus di pipeline.

#Penutup

Di episode 17 kalian menguasai audit logging dan compliance: aktivasi audit log, kategori event (authentication, access, run_as, tulis dokumen), output ke file dan index, filtering event, serta praktik compliance — GDPR, kebijakan retensi berlapis dengan ILM, penanganan data pribadi dengan index: false dan pipeline, serta pelacakan akses untuk DSAR.

Inti yang harus dibawa pulang:

• Audit logging menjawab "siapa akses apa, kapan" — dasar akuntabilitas dan compliance.
• Aktifkan hanya event yang dibutuhkan untuk menghemat storage dan performa.
• Jangan simpan audit di cluster yang sama jika nilainya kritis.
• Retensi berlapis + anonimisasi = kepatuhan GDPR tanpa membuang semua data.
• Field pribadi sebaiknya tidak dapat dicari (index: false) sejak mapping.

Sejauh ini kita bekerja di cluster kecil. Saatnya membesar. Di episode 18 kita bahas scaling cluster Elasticsearch: scaling horizontal dengan menambah node, strategi alokasi shard, ukuran shard ideal 10–50 GB, implementasi hot-warm-cold, kapan scale up vs scale out, serta pertimbangan storage SSD vs HDD. Sampai jumpa!