Belajar LDAP - Compliance & Security Auditing

#Pendahuluan

Di episode 28 kalian merancang schema yang sehat. Episode 29 ini membahas apa yang dituntut dari identity store di lingkungan yang diaudit: compliance dan security auditing. Directory LDAP menyimpan identitas, kredensial, dan data pribadi — persis data yang paling disorot oleh kontrol keamanan dan regulasi. Kalian akan belajar kebutuhan audit (siapa mengakses apa dan kapan), pertimbangan regulasi untuk data identitas, hardening, audit berkala, dan bagaimana menyalurkan log ke SIEM agar anomali terdeteksi.

#Pertimbangan Compliance

Compliance bukan tentang sertifikat, tetapi tentang kemampuan membuktikan kontrol berjalan. Untuk identity store, area yang disorot regulasi umumnya serupa:

Pola yang berulang: siapa yang bisa mengakses data, apa yang mereka lakukan, dan bukti berupa log. Karena itu pekerjaan utama kalian bukan menyiapkan dokumen, tetapi membuat directory bisa menjawab tiga pertanyaan itu secara otomatis. Jangan mengklaim kepatuhan penuh terhadap standar tertentu tanpa menjalani asesmen resmi — fokuslah membangun kontrol yang nantinya bisa diverifikasi auditor.

#Kebutuhan Audit

Empat jenis log yang harus ada:

• Access logging — siapa membaca apa. Gunakan level stats untuk mencatat operasi dasar, dan acl untuk menangkap keputusan izin. Atur levelnya lewat olcLogLevel di cn=config, dan pastikan file log dirotasi serta berhak diakses hanya oleh admin.
• Change tracking — jejak perubahan entry. Overlay auditlog mencatat semua modifikasi ke satu file log:

Aktifkan overlay auditlog

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: auditlog
 
dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/log/ldap-audit.log

• Authentication logs — siapa berhasil dan gagal login. Event bind dengan hasil sukses atau Invalid credentials sudah tercatat lewat loglevel stats.
• Authorization logs — keputusan ACL. Level acl mencatat apakah suatu operasi diizinkan atau ditolak beserta alurnya.

Jangan hanya menulis log — tetapkan masa retensi, rotasi (misalnya via logrotate), dan pastikan log tidak bisa diubah oleh pengguna biasa. Log audit yang bisa dihapus attacker sama saja tidak ada.

#Security Hardening

Log yang baik tidak menghilangkan kebutuhan mencegah. Beberapa langkah hardening inti:

• Nonaktifkan fitur yang tidak dipakai — jangan load backend atau overlay yang tidak diperlukan; setiap modul adalah permukaan serangan.
• Terapkan password policy — mulai dari overlay ppolicy (episode 12) untuk panjang, kompleksitas, dan penguncian akun.
• Segmen jaringan — batasi slapd hanya mendengarkan di antarmuka internal, bukan publik. Perubahan listen address dilakukan lewat konfigurasi -h atau URI olcDatabase tingkat slapd.
• Atur firewall — hanya buka port 389 atau 636 dari jaringan yang membutuhkan. Blokir akses anonim ke atribut sensitif sejak ACL:

ACL pembatas akses anonim

olcAccess: to attrs=userPassword
  by self write by anonymous auth by * none
olcAccess: to * by users read by * none

• Patch rutin — update paket slapd secara terjadwal; celah di OpenLDAP yang diketahui memengaruhi instalasi lama.

#Audit Berkala

Compliance adalah aktivitas berulang, bukan proyek sekali jadi. Jadwalkan audit rutin untuk:

• Review ACL — bandingkan slapcat -o ldif-wrap=no -n 0 dengan versi sebelumnya; pastikan tidak ada rule yang makin longgar diam-diam.
• Review akun — cari akun yang tidak aktif atau terkunci, misalnya akun dengan pwdAccountLockedTime yang sudah lama:

ldapsearch -x -b "ou=people,dc=example,dc=com" \
  "(pwdAccountLockedTime=*)" uid pwdAccountLockedTime

• Review privilege — verifikasi siapa yang bisa mengubah atribut sensitif dan siapa yang memegang olcRootDN. Hak write pada userPassword dan shadow harus seminimal mungkin.
• Review schema — pastikan tidak ada attribute kustom yang tumbuh liar tanpa dokumentasi (melanjutkan episode 28).
• Review konfigurasi — cek TLS masih aktif, log level masih sesuai, dan tidak ada debug level yang tersisa di production.

#Reporting dan SIEM

Log baru berguna saat dikonsumsi. Bangun laporan berkala — jumlah bind sukses, kegagalan autentikasi, dan perubahan entry — dan alirkan log ke SIEM agar anomali terdeteksi otomatis:

grep "Invalid credentials" /var/log/ldap.log | wc -l

Untuk integrasi SIEM, teruskan log slapd ke host pengumpul lewat syslog. Contoh pada rsyslog:

Teruskan log LDAP ke SIEM via rsyslog

auth,authpriv.* -/var/log/ldap.log
auth,authpriv.* @siem.internal:514

Dengan aliran ini, lonjakan tiba-tiba pada Invalid credentials atau pola bind yang tidak wajar muncul sebagai sinyal anomaly detection di SIEM. Beberapa hal yang patut dijadikan aturan deteksi: kegagalan bind beruntun (brute force), bind dari sumber yang tidak dikenal, dan modifikasi pada akun privilege di luar jam kerja.

#Penutup

Pada episode 29 ini, kalian memahami area yang disorot regulasi untuk data identitas, menyusun empat jenis log audit dengan bantuan overlay auditlog, melakukan hardening dengan ACL dan jaringan, menjalankan audit berkala terhadap akun dan konfigurasi, serta menyalurkan log ke SIEM untuk deteksi anomali.

Inti yang harus dibawa pulang:

• Log yang bisa dibuktikan adalah jantung compliance — retensi, rotasi, dan integritas log tidak bisa ditawar.
• auditlog overlay memberi jejak perubahan yang permanen dan mudah diaudit.
• Hardening mencegah, logging mendeteksi — keduanya wajib.
• Alirkan log ke SIEM dan jadwalkan review berkala, bukan menunggu audit eksternal.

Di episode 30 — episode terakhir series ini — kita menyatukan semuanya: production checklist dan masa depan LDAP. Kalian akan mendapatkan daftar siap-produksi, jebakan umum yang harus dihindari, dan pandangan ke arah mana teknologi directory bergerak.