Belajar LDAP - Audit Logging & Monitoring

#Pendahuluan

Di episode 17, kalian mengamankan koneksi dan autentikasi lewat SASL dan EXTERNAL. Episode 18 ini membahas sisi pengawasan: bagaimana tahu apa yang sebenarnya terjadi di server LDAP kalian. Directory services menyimpan data identitas paling sensitif di organisasi, jadi kemampuan melihat siapa mengakses apa, perubahan apa saja yang terjadi, dan apakah server masih sehat menjadi keterampilan wajib administrator LDAP. Kali ini kalian akan belajar log level, dua overlay penting untuk audit, dan perangkat monitoring.

#Mengenal Logging di OpenLDAP

Logging adalah catatan pertama yang kalian lihat saat ada kejadian aneh. OpenLDAP menyediakan kontrol log level yang granular lewat atribut konfigurasi olcLogLevel pada entry cn=config:

ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config \
  olcLogLevel

Nilai default biasanya stats. Log ini biasanya dikirim ke syslog dan ditulis ke /var/log/syslog pada sistem Debian/Ubuntu. Lokasi file log bergantung pada konfigurasi rsyslog kalian; jangan heran kalau tidak ada file khusus bernama slapd.log, karena defaultnya menyatu dengan syslog.

#Log Levels

Setiap level mengontrol kategori informasi tertentu. Kombinasi level dipisahkan koma atau spasi, dan level -1 berarti mencatat semuanya.

Untuk lingkungan produksi, stats biasanya sudah cukup. Saat debugging filter yang bermasalah, tambahkan filter; saat mengejar masalah replikasi, gunakan sync; dan saat ACL tidak bekerja seperti harapan, acl adalah sahabat kalian.

#Mengatur Log Level

Setel level lewat ldapmodify:

ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats filter acl
EOF

Ingat bahwa olcLogLevel menyimpan nilai level sebagai attribute value, bukan satu string panjang. Setiap value baru menambahkan kategori; untuk mereset, ganti semua value sekaligus seperti contoh di atas. Hindari level -1 di produksi karena volume lognya bisa membanjiri disk.

#Rotasi Log

Log yang tidak pernah dirotasi akhirnya menghabiskan disk — dan LDAP log di lingkungan ramai bisa tumbuh sangat cepat. Pada Debian/Ubuntu, rotasi diatur lewat logrotate. OpenLDAP biasanya sudah punya file konfigurasi di /etc/logrotate.d/slapd. Contoh konfigurasi rotasi mingguan:

/etc/logrotate.d/slapd

/var/log/slapd.log {
    weekly
    rotate 4
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        systemctl restart rsyslog
    endscript
}

weekly menentukan frekuensi rotasi, rotate 4 menyimpan 4 generasi lama, dan compress mengompresi file lama untuk menghemat ruang. Jika log kalian mengarah ke /var/log/syslog, rotasi cukup dilakukan oleh konfigurasi rsyslog standar — pastikan kalian tidak rotasi file yang sama dua kali dari dua konfigurasi berbeda.

#Analisis Log

Log mentah tidak berguna tanpa analisis. Beberapa pola yang sering dicari:

• Bind gagal berulang — indikasi brute force password.
• Search tanpa filter — pengguna aplikasi menarik seluruh DIT.
• Anomali waktu akses — akses di luar jam kerja.
• Koneksi dari IP tak dikenal — cek firewall.

grep dan awk masih menjadi alat paling fleksibel untuk analisis cepat, sementara goaccess atau script sederhana bisa dipakai untuk agregasi. Kombinasikan dengan filter acl dan conns untuk melihat siapa yang mencoba masuk dan dari mana — pola yang sangat berguna saat menulis laporan security audit bulanan. Contoh sederhana menghitung kejadian bind gagal:

grep "invalid credentials" /var/log/syslog | wc -l

#Audit dengan auditlog Overlay

Log standar mencatat peristiwa. Untuk kebutuhan audit yang lebih formal, kalian butuh catatan perubahan data dalam format yang bisa direview: inilah tugas auditlog overlay. Overlay ini menulis setiap modifikasi entry ke sebuah file dalam format LDIF, sehingga riwayat perubahan menjadi lengkap dan bisa dibaca manusia maupun alat lain.

#Membuat File Audit

touch /var/lib/ldap/audit.log
chown openldap:openldap /var/lib/ldap/audit.log

#Load Overlay

Kemudian aktifkan overlay pada database yang ingin diaudit:

dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/lib/ldap/audit.log

Overlay ini hanya mencatat operasi write: add, delete, modify, dan modrdn. Operasi baca tidak tercatat di sini — untuk itu gunakan accesslog overlay. Pastikan direktori tempat file audit berada bisa ditulis oleh user yang menjalankan slapd (biasanya openldap), dan lindungi file tersebut karena isinya adalah data identitas sensitif.

#accesslog Overlay

Jika auditlog menulis ke file, accesslog overlay menulis ke database — membuka pintu untuk query yang terstruktur. Keunggulan utamanya ada tiga: pencatatan query (search), dukungan untuk replikasi delta-syncrepl, dan retensi log yang bisa diatur dengan kebijakan ekspirasi.

Untuk menggunakannya, kalian butuh database terpisah yang menampung log:

dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: cn=accesslog
olcDbDirectory: /var/lib/ldap/accesslog
olcDbIndex: default eq

Kemudian pasang overlay accesslog pada database data utama dan arahkan ke database log. Dengan konfigurasi ini, setiap operasi termasuk search dicatat sebagai entry LDIF di dalam cn=accesslog. Operasi read bisa dikorelasikan dengan siapa, filter apa, dan berapa lama waktu eksekusinya — data berharga untuk analisis performa dan audit keamanan.

#Log Retention

Database log yang tak dibatasi akan membengkak. Atur retensi dengan olcAccessLogPurge pada overlay, yang membersihkan entry yang sudah lama atau melebihi ukuran tertentu. Kebijakan retensi biasanya mengikuti persyaratan compliance organisasi — misalnya menyimpan log 90 hari, atau 1 tahun untuk lingkungan audit ketat.

#Monitoring dengan cn=monitor

OpenLDAP memiliki backend khusus monitor yang menyediakan statistik internal server secara real-time melalui LDAP itu sendiri. Informasi seperti koneksi aktif, operasi per detik, dan ukuran database bisa dibaca lewat search biasa:

ldapsearch -Y EXTERNAL -H ldapi:/// \
  -b cn=Monitor -s sub \
  "(objectClass=monitorCounter)"

Backend monitor ini default-nya hanya bisa diakses oleh admin directory. Dari sini kalian bisa membaca jumlah koneksi, total operasi, current connections, dan nilai-nilai counter lain. cn=Monitor adalah sumber data mentah yang paling mudah diintegrasikan dengan alat eksternal.

#Integrasi SNMP dan Prometheus

Monitoring tidak berhenti di dalam LDAP. Server produksi biasanya dipantau lewat ekosistem monitoring yang sudah ada:

Prometheus adalah pilihan paling populer di lingkungan modern. Pola kerjanya: sebuah exporter melakukan bind ke LDAP, membaca statistik dari cn=Monitor, dan menerbitkannya dalam format yang dipahami Prometheus. Grafana kemudian menampilkan dashboard dengan grafik koneksi, operasi, dan latency dalam waktu nyata.

#Metrik yang Harus Dipantau

• Connection count — lonjakan tiba-tiba bisa berarti aplikasi bocor koneksi atau serangan.
• Operation rates — bind, search, dan modify per detik; membantu memahami kapasitas.
• Search performance — latency search yang naik menandakan index bermasalah atau dataset membesar.
• Bind success/failure — rasio gagal tinggi bisa menandakan brute force atau kredensial aplikasi rusak.
• Replication lag — selisih waktu antar replica; lag besar menandakan masalah jaringan atau write overload.
• Database size — memprediksi kebutuhan disk dan kesehatan backend mdb.

Kombinasikan metrik ini dengan alert threshold: misalnya alarm ketika bind failure melebihi 50 per menit atau replication lag melebihi 5 menit. Alat seperti Grafana memudahkan kalian membuat dashboard yang menjadi single source of truth bagi operasional LDAP.

#Penutup

Pada episode 18 ini, kalian menguasai cara mengamati dan mengaudit OpenLDAP: memahami log level beserta kategorinya, mengatur rotasi log, menganalisis pola mencurigakan, mencatat perubahan dengan auditlog overlay, mencatat akses dengan accesslog overlay, membaca statistik real-time dari backend monitor, serta menghubungkan semuanya dengan SNMP dan Prometheus.

Inti yang harus dibawa pulang:

• Log level itu granular — mulai dari stats, tambahkan filter, acl, atau sync hanya saat debugging.
• auditlog untuk perubahan, accesslog untuk akses — dua overlay ini melengkapi kebutuhan compliance.
• cn=Monitor adalah sumber metrik — hampir semua data yang dibutuhkan monitoring ada di sana.
• Alert threshold lebih penting daripada sekadar menampilkan angka.

Di episode 19 berikutnya, kalian keluar dari server menuju sistem operasi: Linux system authentication dengan LDAP — bagaimana membuat mesin Linux menggunakan LDAP sebagai sumber user, password, dan group lewat NSS, PAM, dan SSSD. Fondasi monitoring yang kalian bangun sekarang akan sangat membantu saat integrasi itu berjalan.