Belajar Authelia - Privacy & Anonymization

#Pendahuluan

Episode 22 menutup lapisan transport dengan HTTPS dan header keamanan. Tapi keamanan dan privasi adalah dua hal yang berbeda: keamanan memastikan data tidak jatuh ke tangan yang salah, sementara privasi memastikan data yang tidak perlu tidak dikumpulkan sejak awal. Episode 23 ini membahas sisi privasi Authelia: bagaimana tetap tahu apa yang terjadi tanpa menimbun data.

Pendekatan Authelia sejak lahir adalah privacy-first: tanpa telemetri, tanpa laporan penggunaan ke server pihak ketiga, dan semua data tetap tinggal di instance kalian. Di episode ini kita menilik cara menjaga janji itu tetap berlaku saat konfigurasi kalian tumbuh.

#Authelia Tanpa Telemetri, Data Lokal

Authelia tidak mengirim telemetri atau statistik penggunaan ke layanan eksternal. Data pengguna — password, MFA, consent, sesi — tersimpan di storage backend lokal yang kalian kendalikan: file, SQLite, PostgreSQL, atau MySQL. Tidak ada API pihak ketiga yang menyentuh data ini, kecuali layanan yang memang kalian konfigurasikan sendiri, seperti Redis untuk sesi atau SMTP untuk notifikasi.

Pertanyaan yang harus selalu diajukan setiap menambah komponen: apakah komponen ini menyimpan data di luar kendali kita? Jika ya, seberapa penting? Ini cara berpikir yang menjaga arsitektur tetap ramah privasi.

#Logging: Data yang Benar-Benar Diperlukan

Log adalah jejak aktivitas, tapi log juga merupakan kumpulan data pribadi — alamat IP, nama pengguna, waktu aktivitas. Semakin banyak yang direkam, semakin besar permukaan privasi yang harus dikelola. Authelia memberi kendali lewat log_level dan log_format:

log:
  level: info
  format: json
  file_path: /config/authelia.log

Level log menentukan seberapa detail:

Aturan praktisnya: di produksi gunakan info ke atas. Level debug atau trace mencatat jauh lebih banyak detail pengguna — aktifkan hanya saat menyelidiki masalah, lalu kembalikan ke semula.

#Retensi Data Minimal

Data yang tersimpan tanpa batas adalah kewajiban yang tidak diinginkan. Beberapa retensi yang perlu diatur:

• Sesi — dibatasi oleh expiration dan inactivity yang sudah dibahas di episode 7; sesi berakhir dan data sesi dibersihkan.
• Token OIDC — refresh token dan access token punya umur terbatas lewat pengaturan lifespans; token yang kedaluwarsa tidak lagi valid.
• Consent — catatan consent disimpan selama tidak dicabut; pengguna bisa menghapusnya lewat portal.
• Log — batasi umur dan ukuran log. Di Docker, set rotasi di docker-compose.yml:

services:
  authelia:
    image: authelia/authelia:4.39
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Dengan ini, log dibatasi sepuluh megabyte per file dan hanya tiga file yang disimpan. Data lama hilang dengan sendirinya tanpa perlu pembersihan manual.

#Cookie Minimalis

Privasi juga tercermin dari cookie. Authelia memakai satu cookie sesi bernama authelia_session — tidak ada cookie pelacak lintas situs. Cookie bertanda HttpOnly dan Secure (dibahas di episode 22), dan SameSite default lax mencegah pengiriman lintas situs. Cookie sesi dihapus ketika pengguna logout, dan tidak ada cookie tambahan yang ditinggalkan di perangkat.

#Anonymisasi Alamat IP

Log Authelia mencatat alamat IP asal untuk keperluan regulation dan audit. Authelia tidak punya fitur anonymisasi IP bawaan, sehingga keputusan ada di tangan kalian:

• Di level proxy, putuskan apakah IP diteruskan ke Authelia atau diganti nilai anonim.
• Di level agregasi log, hash atau samarkan oktet terakhir alamat IP sebelum disimpan lama.
• Untuk deployment yang sangat ketat, pertimbangkan menyembunyikan IP dari log tingkat aplikasi dan mengandalkan log proxy.

Trade-off-nya nyata: tanpa IP, regulation berbasis ip dan audit forensik kehilangan sumbernya. Seimbangkan kebutuhan keamanan dengan komitmen privasi.

#Menghapus Data Pengguna

Jika seorang pengguna keluar dari sistem atau meminta haknya atas data, Authelia menyediakan perintah untuk identifikasi dan penghapusan. Periksa dulu akun yang tersimpan dengan authelia storage user identify, lalu jalankan:

authelia storage user identify
authelia storage user delete arman
authelia storage user totp delete arman

Hapus dahulu data MFA milik pengguna, lalu akunnya. Setelah akun dihapus dari users_database.yml dan catatan storage dibersihkan, pengguna tidak bisa lagi login dan datanya tidak tersisa di Authelia. Pastikan juga mencabut sesi aktifnya di Redis agar session yang masih hidup tidak menimbulkan data sisa.

#Audit Tanpa Menimbun

Privasi bukan berarti tidak ada audit. Catatan audit tetap penting — untuk melihat siapa masuk, kapan, dan dari mana. Kuncinya adalah audit yang seperlunya: catat kejadian yang memang dibutuhkan, simpan selama durasi yang wajar, dan hapus secara otomatis. Authelia memudahkan ini karena semua log berbasis event terstruktur yang bisa disaring sebelum disimpan ke sistem log eksternal.

#Penutup

Di episode ini kalian memahami:

• Authelia tanpa telemetri; data tersimpan lokal dan di bawah kendali kalian.
• log_level dan log_format mengontrol detail serta struktur log.
• Retensi minimal: sesi berakhir, token kedaluwarsa, log dirotasi.
• Cookie minimalis: satu cookie sesi yang aman dan dihapus saat logout.
• Data pengguna bisa diidentifikasi dan dihapus lewat CLI.

Dengan privasi yang terjaga, fondasi Authelia kalian lengkap: autentikasi, otorisasi, keamanan transport, dan kehati-hatian atas data. Tapi satu instance saja masih rapuh. Di episode 24, kita membangun High Availability Setup — menggandakan Authelia, Redis Sentinel, dan database bersama agar layanan tetap hidup. Sampai jumpa!