Belajar Kerberos - Checklist Produksi & Best Practices

#Pendahuluan

Selamat — kalian sudah menempuh perjalanan panjang. Dari episode 0 yang memperkenalkan dasar autentikasi dan mitos seputar Kerberos, kalian mempelajari arsitektur KDC, AS, dan TGS; alur lengkap pertukaran ticket; keytab dan principal; kebijakan realm seperti lifetime dan renewable; cross-realm trust; skala besar dan replikasi di episode 26; Kerberos di cloud di episode 27; alternatif modern di episode 28; serta kepatuhan dan audit di episode 29. Episode 30 ini adalah puncaknya: menyatukan semuanya ke dalam checklist produksi dan best practices yang bisa kalian pakai besok pagi. Ini bukan materi baru — ini daftar periksa yang menyaring seluruh seri.

#Checklist Pra-Produksi

Sebelum realm menyentuh produksi, pastikan delapan hal berikut benar:

Di bawah ini setiap item diuraikan.

#DNS yang Benar

Kerberos bergantung pada DNS untuk menemukan KDC dan menentukan realm. Pastikan record A dan SRV _kerberos._udp serta _kerberos._tcp benar, lalu uji dari sudut pandang klien:

host -t SRV _kerberos._udp.prod.example.com
kinit budi
klist

Jika kinit berhasil dan klist menampilkan TGT, DNS sudah cukup sehat untuk produksi. Konfigurasi krb5.conf yang benar di klien tidak akan menolong jika SRV-nya salah.

#Sinkronisasi Waktu

Kerberos memakai timestamp untuk melawan replay attack. Clock skew maksimal biasanya sekitar 5 menit, tetapi produksi yang sehat menjaga jauh di bawah itu. Gunakan NTP atau chrony di semua host, dan pastikan KDC itu sendiri memakai sumber waktu yang terpercaya:

timedatectl status
chronyc tracking

Selisih dalam hitungan detik, bukan menit, adalah target yang sehat.

#Enkripsi yang Dikeraskan

Di produksi, hanya enctype modern yang boleh hidup. Nonaktifkan DES dan RC4, aktifkan AES, dan tolak kriptografi lemah:

Enctypes dikeraskan di krb5.conf

[libdefaults]
    default_realm = PROD.EXAMPLE.COM
    allow_weak_crypto = false
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

Enctype yang dipilih harus dipahami oleh seluruh anggota realm — KDC, klien, dan layanan. Perubahan enctype adalah salah satu perubahan paling sensitif, jadi uji di staging lebih dulu.

#Replica KDC dan High Availability

Satu KDC adalah titik tunggal kegagalan. Setidaknya satu replica diperlukan; database direplikasi dari master. Klien memakai DNS SRV yang mencakup semua KDC, sehingga kegagalan satu master tidak menggagalkan autentikasi. Uji failover secara berkala — matikan master dan pastikan klien tetap bisa mendapatkan ticket.

#Monitoring

KDC yang tidak terpantau adalah bom waktu. Hal yang wajib dipantau:

• Proses krb5kdc hidup atau mati
• Tingkat kegagalan AS-REQ — lonjakan menandakan brute-force atau masalah kunci
• Volume request terhadap kapasitas
• Latensi respon KDC

alerts:
  - name: kdc-down
    expr: up{job="krb5kdc"} == 0
  - name: auth-fail-spike
    expr: rate(kdc_as_req_failed_total[5m]) > 10

Monitoring mencegah outage — bukan karena menghindarkan kegagalan, tetapi karena membuat kegagalan terlihat lebih awal.

#Backup yang Teruji

Backup KDC adalah file database principal di /var/lib/krb5kdc/principal* plus kadm5.acl dan konfigurasi. Backup yang baik adalah backup yang pernah dipulihkan — jadwalkan uji restore sebelum produksi, bukan setelah bencana. Database yang tidak bisa direstore sama nilainya dengan tidak punya backup.

#Dokumentasi

Realm produksi yang hanya ada di kepala adminnya adalah risiko. Dokumentasikan topologi realm, daftar KDC, prosedur penambahan principal, jadwal rotasi keytab, dan runbook untuk insiden umum. Dokumentasi menyelamatkan kalian di tengah malam ketika insiden terjadi — dan dokumen yang bagus dibangun sebelum insiden, bukan sesudahnya.

#Audit Keamanan Terakhir

Sebelum go-live, jalankan audit: review kadm5.acl, pastikan tidak ada principal tanpa pemilik, verifikasi enctype di seluruh realm, dan periksa apakah kadmin hanya bisa diakses dari host yang tepat. Anggap audit terakhir ini sebagai sinyal lampu hijau.

#Best Practices Operasional

Setelah produksi berjalan, pekerjaan tidak selesai — justru dimulai. Enam praktik berikut menjaga realm tetap sehat dalam jangka panjang.

#Audit Principal Berkala

Ulangi access review dari episode 29: bandingkan inventaris principal dengan kebutuhan bisnis, hapus yang menganggur, dan konfirmasi pemilik akun privileged. Jadwalkan bulanan atau kuartalan, tergantung kerangka kepatuhan yang berlaku.

#Rotasi Password dan Keytab

Password dan keytab punya masa simpan. Tetapkan jadwal rotasi: password administratif dirotasi berkala, keytab service dirotasi saat ada pergantian personel atau indikasi kompromi, dan pastikan semua host menerima kvno yang baru.

#Patch Management

KDC adalah komponen kritis; celah keamanan di MIT Kerberos atau di kriptografi di bawahnya adalah pintu masuk. Ikuti rilis keamanan vendor dan terapkan patch dengan cepat. Kelalaian patching adalah salah satu cara realm produksi yang dibangun baik tetap bisa ditembus.

#Kapasitas dan Perencanaan

Pantau pertumbuhan jumlah principal dan volume request. Ketika mendekati batas, tambah replica atau besarkan instance. Kapasitas yang tidak terpantau membuat autentikasi lambat di masa ramai — dan lambatnya autentikasi menjalar ke seluruh organisasi.

#Incident Response Plan

Skenario yang harus punya prosedur: KDC down, keytab terkompromi, principal dibajak, atau brute-force terhadap kpasswd. Tuliskan langkah-langkahnya, siapa yang dihubungi, dan bagaimana memulihkannya. Tidak perlu sempurna — perlu ada dan teruji.

#Change Management

Setiap perubahan konfigurasi realm — menambah KDC, mengubah enctype, mengganti master — adalah perubahan berisiko. Ikuti proses change management: rencanakan, uji di staging, jalankan di jendela yang disepakati, dan siapkan rollback.

#Perangkap Umum

Berikut perangkap yang paling sering menjegal tim produksi, beserta pencegahannya:

Tujuh perangkap ini adalah tujuh alasan utama mengapa realm yang dibangun dengan baik tetap bisa runtuh di produksi.

#Kunci-kunci yang Harus Dibawa Pulang

Merangkum seluruh seri dalam sepuluh poin:

• Kerberos memberikan autentikasi yang kuat dan teruji selama puluhan tahun.
• Sinkronisasi waktu benar-benar krusial — tanpa itu, semuanya rusak.
• DNS harus andal.
• Enkripsi AES adalah keharusan.
• High availability dengan replica wajib untuk produksi.
• Monitoring mencegah outage.
• Audit keamanan berkala menjaga kebersihan realm.
• Dokumentasi menghemat waktu di masa sulit.
• Pengujian adalah aktivitas berkelanjutan, bukan sekali jalan.
• Selalu ikuti security advisories.

#Penutup

Dan di sinilah perjalanan berakhir. Dimulai dari episode 0, kalian membangun pemahaman dari nol: apa itu autentikasi dan mengapa ticket menjadi jawabannya; anatomi KDC, AS, dan TGS; alur Kerberos yang lengkap; keytab dan principal; kebijakan realm seperti lifetime dan renewable; cross-realm trust; skala besar dan replikasi; Kerberos di cloud; posisinya di antara OAuth2, OIDC, dan SAML; kepatuhan dan audit; dan kini checklist produksi yang menyatukan semuanya. Tiga puluh episode, satu cerita utuh tentang protokol autentikasi yang menjadi tulang punggung jaringan enterprise selama lebih dari tiga dekade.

Inti yang harus dibawa pulang:

• Kerberos bukan protokol mati — ia terus hidup sebagai mesin autentikasi di balik Active Directory dan banyak jaringan enterprise.
• Disiplin operasional menentukan segalanya — waktu, DNS, enkripsi, dan backup adalah empat pilar produksi.
• Kepatuhan dan keamanan berjalan bersama — log, review, dan audit adalah bagian dari desain, bukan tambahan.
• Sekarang giliran kalian — tidak ada guru yang lebih baik selain realm yang kalian bangun sendiri.

Perjalanan kalian di seri ini berhenti di sini, tetapi belajar tidak berhenti. Jika kalian menikmati dunia identitas, arah berikutnya yang alami adalah Active Directory — karena sebagian besar yang kalian pelajari tentang Kerberos di seri ini adalah fondasi untuk memahami bagaimana Windows mengelola autentikasi di skala ribuan domain. Setelah itu, dunia identity dan access management yang lebih luas — federasi, privileged access management, dan passwordless — menanti untuk dijelajahi. Sampai jumpa di petualangan berikutnya.