Belajar Kerberos - Compliance & Audit

#Pendahuluan

Episode 28 memperlihatkan Kerberos hidup berdampingan dengan OAuth2, OIDC, dan SAML di organisasi modern. Episode 29 ini menambah satu lapisan yang tidak bisa ditawar: tata kelola. Ketika sistem dipakai untuk mengakses data keuangan, kesehatan, atau data pribadi, regulator dan auditor mulai bertanya — bagaimana kalian membuktikan siapa yang mengakses apa, dan siapa yang berwenang mengubah pengaturan. Jawabannya ada di tiga kata: kebijakan, logging, dan review.

#Mengapa Kepatuhan Menyentuh Kerberos

Kerberos adalah gerbang masuk. Setiap kali pengguna atau layanan masuk ke jaringan, itu melewati KDC. Karena itu KDC berada di titik paling strategis untuk kepatuhan: ia melihat autentikasi, mendukung otorisasi, dan bisa membuktikan siapa yang mengakses layanan apa. Justru karena itu, log KDC dan kebijakan principal menjadi barang bukti utama dalam audit.

#Kerangka Kepatuhan

Empat kerangka yang paling sering ditemui:

Kerangka	Fokus	Dampak pada Kerberos
SOC 2	Kontrol internal dan trust	Dokumentasi kontrol akses, monitoring, review berkala
HIPAA	Data kesehatan yang dilindungi	Autentikasi kuat dan audit akses data medis
PCI-DSS	Data kartu pembayaran	Akses unik per pengguna, logging, batas akses
GDPR	Privasi data warga UE	Kontrol akses, pemetaan pemrosesan, retensi data

Ketentuan detailnya berbeda-beda dan selalu diperbarui; yang perlu kalian pegang adalah pola umumnya: setiap kerangka menuntut bukti bahwa akses dikendalikan, dicatat, dan ditinjau.

#SOC 2

SOC 2 menilai kontrol organisasi terhadap keamanan, ketersediaan, integritas, kerahasiaan, dan privasi. Bagi Kerberos, artinya: kontrol akses harus terdokumentasi, log autentikasi harus ada, dan review akses harus berjalan berkala. Log KDC yang lengkap menjadi bukti bahwa kontrol tersebut benar-benar dijalankan.

#HIPAA

HIPAA mengatur data kesehatan yang dilindungi. Kebutuhan kuncinya adalah memastikan hanya pihak berwenang yang bisa mengakses data tersebut. Kerberos membantu dengan autentikasi kuat dan service ticket yang mencatat akses ke layanan penyimpanan data — selama log-nya disimpan dan bisa direkonstruksi untuk audit.

#PCI-DSS

Untuk lingkungan yang menangani data kartu pembayaran, PCI-DSS menuntut akses unik per pengguna dan pelarangan akun bersama. Ini sejalan dengan prinsip Kerberos: setiap principal adalah identitas unik. Log autentikasi yang gagal juga menjadi masukan untuk mendeteksi percobaan penyusupan.

GDPR bukan tentang keamanan data, melainkan privasi. Kaitannya dengan Kerberos: log yang berisi identitas pengguna adalah data pribadi — penyimpanannya harus proporsional, ada batas retensi, dan akses terhadap log itu sendiri harus dibatasi. Ini mengajarkan satu hal: jangan log lebih dari yang diperlukan, dan hapus sesuai jadwal.

#Audit Logging

Log adalah tulang punggung kepatuhan. Tanpa log, kalian hanya punya klaim. KDC modern mencatat event penting secara default; tugas kalian adalah memastikan log-nya lengkap, aman, dan terpusat.

Kirim log ke server log terpusat (misalnya rsyslog, ELK, atau layanan SIEM) agar tidak bisa dihapus hanya dengan membersihkan disk server KDC.

#Jenis Event yang Harus Dicatat

Jenis Event	Contoh	Alasan Dicatat
Authentication	AS-REQ sukses atau gagal	Bukti identitas, deteksi serangan brute-force
Authorization	TGS-REQ, pemakaian service ticket	Jejak layanan mana yang diakses
Administratif	Perubahan principal via `kadmin`	Jejak siapa yang mengubah hak akses

Autentikasi menjawab siapa yang masuk, otorisasi menjawab apa yang mereka akses, dan administratif menjawab siapa yang mengubah aturan main.

Important

Perlakukan log KDC seperti barang berharga: simpan di sistem append-only atau backup terenkripsi, batasi siapa yang bisa membacanya, dan terapkan batas retensi. grep di server KDC langsung adalah sinyal bahwa kontrol log kalian belum memadai.

#Retensi Log

Log yang tanpa batas sama buruknya dengan log yang hilang. Tetapkan berapa lama log disimpan sesuai kebutuhan kepatuhan dan operasional, simpan di lokasi yang tahan terhadap kompromi, dan buat jadwal pemusnahan agar data pribadi tidak mengendap tanpa batas — sejalan dengan prinsip GDPR di atas.

#Access Reviews

Logging membuktikan apa yang terjadi; access review memastikan yang terjadi memang seharusnya terjadi. Review akses adalah pemeriksaan berkala atas siapa yang memegang kredensial dan apakah itu masih tepat.

#Inventaris Principal

Tidak bisa diaudit apa yang tidak diketahui. Mulailah dengan inventaris semua principal:

Mencantumkan semua principal

kadmin.local -q "listprincs" > /audit/principals.txt
kadmin.local -q "getprinc budi"

Daftar ini menjadi baseline: bandingkan dengan kebutuhan bisnis, tandai yang tidak jelas pemiliknya, lalu putuskan untuk dihapus atau dipertahankan.

#Review Akun Privileged dan Service Account

Akun dengan hak istimewa dan service account adalah target utama penyalahgunaan:

Privileged account — principal dengan akses administratif ke KDC atau sistem kunci; wajib ditinjau lebih sering, idealnya dengan izin sesaat.
Service account — identitas untuk layanan lewat keytab; pastikan hanya layanan yang benar yang memegang keytab, dan hapus yang tidak terpakai.

Satu aturan emas: tidak ada akun tanpa pemilik yang jelas. Setiap principal harus bisa ditelusuri ke manusia atau tim yang bertanggung jawab.

#Deteksi Principal Nonaktif

Akun yang lama tidak dipakai adalah risiko yang menganggur. Deteksi lewat log autentikasi: principal yang tidak pernah muncul di AS-REQ selama, misalnya, 90 hari patut dipertanyakan. Tandai, konfirmasi ke pemiliknya, lalu nonaktifkan atau hapus bila memang tidak dibutuhkan lagi.

Melihat riwayat autentikasi sebuah principal

grep "budi" /var/log/kerberos/krb5kdc.log | tail -50

#Reporting

Auditor butuh laporan, bukan akses mentah ke log. Bangun laporan standar yang bisa dihasilkan berkala:

Laporan autentikasi — jumlah login sukses per principal per periode.
Laporan login gagal — konsentrasi kegagalan sebagai indikator brute-force.
Laporan penggunaan layanan — service ticket yang paling sering diminta.
Laporan kepatuhan — ringkasan review akses, retensi log, dan status tindak lanjut.

Laporan yang konsisten dan terjadwal membuat proses audit jauh lebih lancar dibanding menyusunnya panik di menit terakhir.

#Sertifikasi Keamanan

Selain kerangka kepatuhan, ada standar teknis yang melekat pada kriptografi Kerberos:

FIPS 140-2 — standar NIST untuk modul kriptografi. KDC dan klien yang menjalankan operasi kriptografi harus memakai implementasi yang memenuhi standar ini dan hanya mengizinkan cipher yang disetujui, seperti AES.
Common Criteria — standar evaluasi keamanan produk; beberapa distribusi dan produk direktori mengejar sertifikasi ini untuk memperkuat klaim keamanannya.
Encryption standards — dalam praktik berarti menonaktifkan DES dan RC4, hanya mengaktifkan AES-256, dan memaksa enctype modern di seluruh realm.

#Penutup

Episode 29 mengikat sisi teknis dengan sisi tata kelola. Kalian sudah melihat bagaimana SOC 2, HIPAA, PCI-DSS, dan GDPR memengaruhi keputusan konfigurasi Kerberos; bagaimana membangun audit logging yang mencatat autentikasi, otorisasi, dan tindakan administratif; bagaimana menjalankan access review atas principal, akun privileged, service account, dan akun nonaktif; bagaimana menyusun laporan untuk auditor; serta standar seperti FIPS 140-2 dan Common Criteria yang menjaga kriptografi tetap di jalur yang benar.

Inti yang harus dibawa pulang:

Log adalah barang bukti — tanpa log yang lengkap dan terpusat, klaim kepatuhan tidak bernilai.
Review akses berkala itu wajib, bukan opsional.
Jangan log lebih dari perlu — batas retensi juga bagian dari kepatuhan.
Enkripsi modern adalah harga masuk — matikan DES dan RC4.

Di episode 30 berikutnya, episode terakhir dari seri ini, kita merangkum semuanya: checklist produksi dan best practices — langkah-langkah konkret sebelum go-live, cara menjaga kesehatan realm dalam operasi sehari-hari, dan perangkap yang paling sering menjegal.