Belajar LDAP - Schema Design Best Practices

#Pendahuluan

Di episode 27 kalian menangani masalah setelah terjadi. Episode 28 ini membahas cara menghindari sebagian besar masalah itu sejak desain: schema design best practices. Schema adalah kontrak data directory — sekali entry tersebar di berbagai sistem, mengubah kontrak ini jadi mahal. Karena itu keputusan desain di tahap awal menentukan biaya perawatan bertahun-tahun ke depan: bagaimana bentuk DIT, object class apa yang dipakai, kapan membuat schema kustom, dan bagaimana menormalkan data agar tidak duplikatif.

#Prinsip Desain Schema

Lima prinsip yang menuntun hampir semua keputusan desain:

• Pahami struktur organisasi dulu — petakan unit, peran, dan relasinya sebelum menyentuh schema. Schema mengikuti organisasi, bukan sebaliknya.
• Rencanakan hierarki DIT — struktur dc sebagai root, ou sebagai cabang fungsional, dan entry di bawahnya.
• Pilih object class yang sesuai — mulai dari yang standar: inetOrgPerson dan posixAccount untuk pengguna, organizationalUnit untuk cabang, groupOfNames atau posixGroup untuk grup.
• Tetapkan konvensi nama — misalnya uid untuk login, cn untuk nama tampilan, mail untuk alamat email; konsisten di semua entry.
• Hindari nesting yang dalam — DIT yang terlalu bertingkat memperlambat search dan mempersulit ACL.

#Desain DIT

Pertanyaan pertama yang harus dijawab: flat atau hierarkis?

Pendekatan modern yang direkomendasikan: domain-based structure dengan dc=example,dc=com sebagai root, lalu cabang fungsional yang sedikit: ou=people untuk akun, ou=groups untuk grup, ou=services untuk akun layanan. Ini memakai naming context berbasis domain, bukan gaya lama o=Company yang berakar pada X.500. Batasi jumlah ou — setiap cabang baru harus menjawab pertanyaan "kebijakan apa yang berbeda di sini?". Kalau tidak ada perbedaan kebijakan, tambahkan cabang hanya menambah kompleksitas tanpa manfaat.

#Schema Kustom

Schema kustom adalah keputusan yang harus ditunda sampai benar-benar diperlukan. Tanya dulu: apakah kebutuhan ini sudah dijawab object class standar? employeeNumber, employeeType, departmentNumber sudah ada di schema inetOrgPerson — jangan membuat ulang. Extend schema hanya bila:

• Atribut yang dibutuhkan benar-benar belum ada di schema standar.
• Kebutuhan lintas sistem, bukan hanya satu aplikasi sementara.
• Kalian siap menjaga schema itu selamanya (menghapus atribut yang dipakai entry lama itu sulit).

Bila harus membuat schema kustom, definisikan olcAttributeTypes dan olcObjectClasses sebagai entry schema baru:

dn: cn=company,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: company
olcAttributeTypes: ( 1.3.6.1.4.1.99999.1.1.1 NAME 'employeeID'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcObjectClasses: ( 1.3.6.1.4.1.99999.1.1.2 NAME 'companyEmployee'
  SUP top AUXILIARY
  MUST ( employeeID )
  MAY ( employeeStatus ) )

Contoh di atas memakai OID di bawah 1.3.6.1.4.1.99999 — itu placeholder. Di production, kalian harus mendapatkan OID dari nomor enterprise (PEN) yang didaftarkan ke IANA, dan menyusun sub-OID di bawahnya secara rapi. SINGLE-VALUE menegaskan atribut hanya boleh satu nilai. Simpan definisi ini sebagai file LDIF di repo agar bisa diaudit dan di-versioning.

Untuk object class baru, bedakan dua jenis: STRUCTURAL membentuk hierarki entry (hanya satu per entry), sedangkan AUXILIARY menambah atribut ke entry tanpa mengubah strukturnya. Pola yang direkomendasikan adalah memakai object class standar sebagai structural (misal inetOrgPerson), lalu menempelkan class auxiliary kustom bila perlu.

Contoh pemakaiannya: sebuah entry person biasa menjadi entry yang punya employeeID begitu class auxiliary companyEmployee ditambahkan lewat ldapmodify. Keuntungan pola ini: seluruh struktur tetap standar, hanya atribut tambahan yang kustom. Schema kustom yang ditulis rapi dan dipakai konsisten jauh lebih baik daripada schema yang menyalin definisi setengah jadi dari blog yang tidak jelas sumbernya.

#Normalisasi

Data yang duplikat adalah sumber inkonsistensi yang paling umum di directory. Prinsipnya:

• Hindari menyimpan data yang bisa diturunkan — jangan simpan nama departemen lengkap di tiap user kalau sudah ada entry departemen; cukup simpan referensi.
• Gunakan referensi DN — atribut bertipe DN menghubungkan entry tanpa menyalin isinya:

Pilih member (berbasis DN) saat anggota bisa dari cabang mana pun dan kalian ingin referensi kuat; memberUid lebih sederhana untuk otentikasi POSIX. Jangan mencampur keduanya untuk grup yang sama.

• Multi-valued vs entry terpisah — atribut multi-valued (mail, telephoneNumber) pas untuk data yang melekat pada satu identitas. Kalau datanya punya atribut sendiri yang perlu dicari (misalnya riwayat sertifikasi), buat entry terpisah dan referensikan — bukan menumpuk semuanya di satu entry.

Contoh nyata normalisasi: satu user boleh punya beberapa alamat email. Menyimpannya sebagai mail multi-valued itu tepat; menyimpan "departemen" sebagai teks di setiap user itu tidak tepat kalau sudah ada entry departemen yang bisa direferensikan. Setiap kali kalian tergoda menyalin data, tanya: "kalau nilai sumbernya berubah, siapa yang akan memperbarui salinannya?"

#Pertimbangan Migrasi

Schema akan berkembang, dan perkembangan itu harus aman:

• Evolusi bersifat aditif — menambah attribute type atau object class baru adalah perubahan yang aman; mengubah atau menghapus yang sudah dipakai entry lama berisiko merusak data. Desain dengan asumsi "tambahkan saja".
• Backward compatibility — sebelum menambah schema, pastikan versi klien lama tetap bisa membaca entry yang ada. Menandai atribut sebagai obsolete jauh lebih aman daripada menghapusnya.
• Dokumentasikan setiap perubahan — catat OID yang dipakai, tanggal, alasan, dan konsumennya. Setahun kemudian, dokumen ini adalah satu-satunya cara mengetahui mengapa sebuah attribute kustom ada dan siapa yang memakainya.
• Skrip migrasi — siapkan LDIF transisi yang mengubah entry secara batch, misalnya menambahkan atribut baru ke semua user sekaligus dengan ldapmodify.
• Uji di staging dulu — terapkan schema baru di staging, jalankan search dan auth yang mewakili workload nyata, baru dorong ke production.

#Penutup

Pada episode 28 ini, kalian menerapkan prinsip desain schema, merancang DIT flat atau hierarkis berbasis domain, memutuskan kapan membuat schema kustom beserta alokasi OID, menormalkan data dengan referensi DN, dan merencanakan migrasi schema yang aditif dan teruji.

Inti yang harus dibawa pulang:

• Standar dulu, kustom terakhir — manfaatkan inetOrgPerson, posixAccount, dan object class lain sebelum membuat sendiri.
• DIT yang sehat itu dangkal dan berbasis kebijakan, bukan replika struktur organisasi.
• OID kustom harus berasal dari PEN yang terdaftar, dan schema disimpan sebagai LDIF yang ter-versioning.
• Ubah schema secara aditif dan uji di staging sebelum menyentuh production.

Di episode 29 berikutnya, kita membahas sisi governance: compliance dan security auditing — bagaimana identity store harus dipantau untuk memenuhi kebutuhan audit, memenuhi pertimbangan regulasi, dan dikaitkan dengan SIEM.