Belajar Authentik - Security Hardening

#Pendahuluan

Di episode 26 kalian memastikan bahwa data bisa pulih ketika terjadi bencana. Sekarang saatnya memikirkan pertanyaan yang lebih proaktif: bagaimana mencegah bencana itu terjadi sejak awal? Sebuah identity provider adalah target paling berharga di infrastruktur kalian — jika ia disusupi, penyerang memegang kunci ke semua aplikasi yang terhubung. Satu password lemah pada akun admin jauh lebih mahal daripada seluruh langkah hardening yang akan kita bahas.

Bayangkan keamanan seperti berlapisnya bawang — tidak ada satu lapisan pun yang menyelamatkan sendirian, tetapi gabungan lapisan yang baik membuat penyerang menyerah di tengah jalan. Episode ini adalah peta lapisan-lapisan itu: dari rahasia yang diperkuat, transport yang dienkripsi, hingga kebijakan yang membuat akses tidak penting sulit dijangkau.

#Ganti Secret Default dan Perkuat AUTHENTIK_SECRET_KEY

Langkah pertama yang paling remeh namun paling sering dilupakan: ganti semua nilai default. Akun awal, kredensial database contoh, dan AUTHENTIK_SECRET_KEY dari template instalasi adalah pintu yang sudah terpasang kunci dari pabrik — dan semua orang tahu kuncinya. Kunci default atau yang lemah memungkinkan penyerang menandatangani sesi palsu, dan dalam kasus tertentu bahkan menjadi vektor untuk membaca endpoint metrik.

AUTHENTIK_SECRET_KEY harus acak dan panjang — minimal 50 karakter. Bangkitkan dengan sumber acak kriptografis:

openssl rand -hex 64

Simpan hasilnya di tempat aman (episode 26), jangan pernah di-commit ke Git, dan jangan bagikan. Jika kalian pernah mengekspos kunci ini ke publik, rotasi segera — tetapi ingat bahwa rotasi menandatangani ulang seluruh sesi, jadi rencanakan waktunya di luar jam sibuk dan beri tahu pengguna.

#TLS: Enkripsi di Setiap Titik

Tidak ada alasan Authentik berjalan tanpa HTTPS. Terminasi TLS dilakukan di reverse proxy atau ingress (episode 12, 13, 24), dengan sertifikat yang diperbarui otomatis. Setelah HTTPS aktif, paksakan browser hanya memakai koneksi terenkripsi lewat header HSTS:

server {
    listen 443 ssl http2;
    server_name auth.example.com;
 
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
 
    location / {
        proxy_pass http://authentik:9000;
    }
}

HSTS memberitahu browser "jangan pernah coba HTTP lagi" selama periode yang ditentukan — melindungi pengguna dari serangan downgrade dan sertifikat yang dimalsukan. Pastikan juga tidak ada listener HTTP yang mengekspos data login.

#Rate Limiting: Mengurangi Laju Serangan

Rate limiting membatasi berapa banyak percobaan yang bisa dilakukan penyerang dalam satu rentang waktu — mengubah serangan brute force dari perlombaan kecepatan menjadi perlombaan kesabaran yang tidak pernah menang. Kapabilitas ini bisa dipasang di proxy (NGINX, Traefik, Caddy) dan bekerja sama dengan reputation system Authentik dari episode 19.

limit_req_zone $binary_remote_addr zone=auth:10m rate=10r/m;
 
server {
    listen 443 ssl http2;
    server_name auth.example.com;
 
    location / {
        limit_req zone=auth burst=20 nodelay;
        proxy_pass http://authentik:9000;
    }
}

Batas yang terlalu ketat akan mengganggu pengguna sah (misalnya banyak karyawan dari satu IP NAT). Mulailah dari nilai moderat, pantau dengan alerting di episode 25, lalu sesuaikan.

#Matikan Registrasi yang Tidak Dipakai

Jika kalian tidak membuka pendaftaran publik, nonaktifkan enrollment flow. Flow default enrollment memungkinkan siapa saja membuat akun — dan akun baru adalah permukaan serangan tambahan. Matikan binding enrollment flow pada flow, atau ganti dengan deny stage di dalamnya, dan verifikasi dengan mencoba mendaftar dari mode incognito: jika bisa, kalian belum selesai.

#Kebijakan Password yang Jelas

Kebijakan password disusun lewat password policy pada stage autentikasi: panjang minimum, campuran karakter, dan larangan pemakaian ulang. Kebijakan yang baik menyeimbangkan keamanan dengan kegunaan — kebijakan yang memaksa pergantian setiap 30 hari sering berakhir dengan password yang diulang dengan angka tambahan di belakang, yang justru lebih lemah.

Untuk enforcement, pasang policy yang memaksa pengguna mengubah password lemah sebelum bisa lanjut, dan gabungkan dengan pengecekan password yang bocor jika perlu. Ingat bahwa password hanyalah satu faktor — kombinasi dengan 2FA jauh lebih menentukan.

#Penegakan 2FA, Khususnya untuk Admin

2FA mengubah aturan main: password yang bocor pun tidak cukup untuk masuk. TOTP dan WebAuthn/FIDO2 (episode 7) adalah metode yang direkomendasikan. Jangan sekadar menawarkan 2FA — wajibkan untuk admin. Ini bisa dilakukan lewat expression policy pada stage autentikasi:

Expression policy — wajib MFA untuk admin

if request.user.groups.filter(name="admins").exists():
    return request.user.ak_is_authenticator_setup_complete
return True

Perhatikan logikanya: untuk anggota grup admins, ia harus sudah menyelesaikan setup authenticator; untuk lainnya, biarkan berlalu (kebijakan MFA menyeluruh bisa ditambahkan terpisah). Lengkapi dengan perencanaan recovery code untuk admin yang kehilangan perangkatnya.

#Least Privilege: Jangan Beri Superuser ke Semua

Akun superuser adalah kartu master — dan seperti kartu master, semakin sedikit yang memegang, semakin aman. Jangan memberikan superuser ke semua orang yang "mengelola" Authentik. Manfaatkan sistem grup dan permission: beri peran yang paling sempit untuk pekerjaan yang dibutuhkan. Siapkan akun break-glass terpisah yang tidak dipakai sehari-hari, dan pantau event audit (episode 22) untuk mendeteksi pemakaian yang tidak wajar.

#Security Headers: Instruksi ke Browser

Header HTTP adalah cara server memberi tahu browser tentang kebijakan. Yang penting untuk Authentik: CSP (Content Security Policy) yang membatasi sumber script dan style yang boleh dimuat, X-Frame-Options untuk mencegah klik-jacking (laman Authentik dibungkus iframe situs penyerang), dan Referrer-Policy untuk membatasi kebocoran URL. Terapkan di proxy, tetapi uji terlebih dahulu — CSP yang terlalu ketat bisa mematahkan halaman login yang memuat aset web Authentik.

#Cadence Update yang Disiplin

Authentik merilis pembaruan secara rutin, dan sebagian besar perbaikan keamanan datang lewat versi baru. Tetapkan ritme: upgrade di staging dulu, lalu produksi, dan baca release notes untuk perubahan yang bisa merusak. Jangan menumpuk keterlambatan beberapa versi — setiap lompatan menambah risiko perbedaan yang sulit diatasi. Pantau pengumuman CVE dan langganan release notes resmi agar kalian tahu ketika versi yang dipakai mengandung kerentanan yang perlu ditambal.

#Peninjauan Keamanan Berkala

Hardening bukanlah proyek sekali jadi — ia proses yang dirawat. Jadwalkan peninjauan rutin dengan daftar pertanyaan tetap: apakah secret yang dipakai masih yang terkuat, apakah akun superuser masih hanya milik orang yang tepat, apakah ada flow registrasi yang tanpa sengaja terbuka, dan apakah cadence update masih berjalan. Verifikasi teknisnya cepat dilakukan: periksa header security yang terpasang dengan curl -I https://auth.example.com dan bandingkan dengan harapan kalian.

Tingkatkan ini menjadi latihan yang teratur: setahun sekali, lakukan audit menyeluruh menggabungkan event audit (episode 22), review permission tiap akun, dan uji prosedur rotasi kunci. Sistem yang pernah di-hardening lima tahun lalu dan tidak pernah disentuh lagi bukanlah sistem yang aman — ia hanya sistem yang belum diserang.

#Penutup

Pada episode 27 ini kalian telah belajar memperkuat Authentik dari dalam ke luar: mengganti secret default dan memperkuat AUTHENTIK_SECRET_KEY, menegakkan TLS beserta HSTS di proxy, memasang rate limiting, menonaktifkan registrasi yang tidak dipakai, menyusun kebijakan password, mewajibkan 2FA khususnya bagi admin, menerapkan least privilege untuk akun superuser, mengatur security headers, dan menjalankan cadence update yang disiplin.

Inti yang harus kalian bawa:

• Kunci default dan AUTHENTIK_SECRET_KEY yang lemah adalah pintu yang kuncinya sudah diketahui semua orang.
• HTTPS tanpa HSTS masih meninggalkan celah downgrade.
• 2FA yang diwajibkan lebih bernilai daripada password yang dipersulit.
• Least privilege: superuser hanya untuk yang benar-benar butuh.
• Update adalah pengaman yang hidup; backlog versi adalah utang keamanan.

Satu pintu yang terkunci dengan baik pun masih bisa membuat penghuni terjebak di luar. Di episode 28 berikutnya kita akan membahas Troubleshooting & Debugging: membaca log server dan worker, menangani error 500, outpost yang gagal terhubung, kesalahan redirect OIDC, ketidakcocokan SAML, masalah koneksi database, isu sesi, serta memanfaatkan flow inspector dan channel dukungan komunitas. Sampai jumpa di episode 28!