Manajemen Pengguna dan Akses Tingkat Lanjut

Selama tiga Bab pertama, server yang kita kelola masih terasa seperti mesin pribadi. Satu akun, satu sudo, satu orang yang memegang kendali penuh. Begitu server mulai dipakai oleh tim yang lebih besar, situasinya berubah drastis. Developer butuh akses untuk deploy aplikasi, tim yang mengurus database butuh akses langsung tanpa perlu tahu detail konfigurasi jaringan, dan kontraktor lepas butuh akses sementara yang harus otomatis mati begitu masa kerjanya selesai. Mengelola semua ini satu per satu lewat baris sudo yang ditambal manual, cepat atau lambat bikin berantakan dan membuka celah keamanan yang tidak kita sadari.

Bab ini membawa manajemen pengguna dan akses ke tingkat yang lebih matang. Kita mulai dengan ulasan singkat mengenai fondasi user, group, dan permission, lalu masuk ke sudo-rs yang kini menjadi default di Ubuntu Server 26.04 LTS serta bagaimana perbandingannya dengan sudo klasik. Setelah itu, kita membahas strategi mengelola banyak akun sekaligus lewat group berbasis peran dan kebijakan password, lalu ditutup dengan pengenalan konsep autentikasi terpusat lewat PAM dan LDAP.

4.1 Review Singkat User, Group, dan Permission

Setiap proses dan file di Linux selalu terikat pada identitas pemiliknya. Konsep ini seharusnya sudah kita kenal dari materi Linux 101, tetapi ada baiknya kita segarkan kembali sebelum melangkah ke topik yang lebih kompleks, seBab seluruh strategi akses tingkat lanjut pada Bab ini dibangun di atas fondasi yang sama.

Tiga elemen dasarnya adalah user (identitas individu yang login ke sistem), group (kumpulan user yang dikelola bersama), dan permission (hak baca, tulis, dan eksekusi yang menempel pada setiap file dan direktori). Kombinasi ketiganya menentukan siapa yang boleh melakukan apa terhadap resource mana di server.

Verifikasi Cepat

Sebelum melanjutkan, pastikan kita masih ingat cara memeriksa identitas dan keanggotaan group sebuah akun.

id username
groups username

Perintah id menampilkan UID, GID utama, dan seluruh group tambahan yang dimiliki user tersebut, sedangkan groups menampilkan daftar nama group saja. Kedua perintah ini akan sering kita gunakan di sepanjang Bab ini untuk memverifikasi hasil konfigurasi.

4.2 sudo-rs vs sudo Klasik (sudo.ws)

Bab 1 sempat menyinggung bahwa Ubuntu Server 26.04 LTS menggunakan sudo-rs sebagai default, yaitu implementasi sudo yang ditulis ulang dalam bahasa Rust demi keamanan memori. Sekarang saatnya kita membongkar lebih dalam arti hal ini secara praktis bagi pekerjaan Sysadmin sehari-hari, terutama saat kita menemukan skrip otomasi lama yang tiba-tiba berperilaku aneh setelah pindah ke server baru.

sudo-rs awalnya digagas lewat inisiatif Prossimo milik ISRG, organisasi nirlaba yang sama di balik Let's Encrypt, dan dikerjakan oleh insinyur dari Tweede golf serta Ferrous Systems sebelum pengelolaan jangka panjangnya diserahkan ke Trifecta Tech Foundation pada 2024. Proyek ini mulai menjadi default di Ubuntu 25.10 (Questing Quokka) sebelum akhirnya dibawa masuk ke Ubuntu 26.04 LTS. Agar transisi ini tidak merepotkan pengguna lama, Canonical tetap menyertakan sudo klasik di dalam sistem, hanya saja memakai nama binari yang berbeda: sudo.ws (merujuk pada domain proyek resminya, sudo.ws, milik Todd Miller). Kedua implementasi ini hidup berdampingan lewat alternatives system milik Debian/Ubuntu, dengan sudo-rs mendapatkan prioritas lebih tinggi (50) dibandingkan sudo klasik (40), sehingga otomatis terpilih pada instalasi baru.

4.2.1 Perbedaan dan Konfigurasi Default Provider

Secara fungsi sehari-hari, sudo-rs terasa identik dengan sudo klasik. Namun, ada beberapa perbedaan perilaku yang penting diketahui oleh Sysadmin sebelum menemukannya sendiri secara tidak sengaja di tengah produksi.

Di lapangan, perbedaan yang paling sering membingungkan adalah timestamp per-TTY. Skrip otomasi yang mengandalkan asumsi "sekali autentikasi sudo, berlaku di semua sesi" milik user yang sama, bisa tiba-tiba meminta password lagi di terminal lain setelah server dipindahkan ke sudo-rs. Ini bukan bug, melainkan keputusan desain demi keamanan yang lebih ketat.

Langkah Praktik

1. Periksa provider sudo mana yang sedang aktif di server kita.

   update-alternatives --display sudo

   Baris pertama menunjukkan link yang sedang digunakan, sedangkan baris di bawahnya menampilkan seluruh kandidat beserta nilai prioritasnya.
2. Jika kita perlu berpindah sementara ke sudo klasik, misalnya untuk mengaudit kompatibilitas skrip lama, gunakan mode interaktif.

   sudo update-alternatives --config sudo

3. Untuk kebutuhan otomasi atau provisioning, gunakan mode non-interaktif.

   sudo update-alternatives --set sudo /usr/bin/sudo.ws

4. Kembali ke sudo-rs kapan saja lewat cara yang sama.

   sudo update-alternatives --set sudo /usr/bin/sudo-rs

Verifikasi dan Troubleshooting

• Setelah berpindah provider, jalankan sudo -V untuk memastikan versi dan implementasi yang aktif sudah sesuai.
• Jika skrip berbasis Expect gagal mendeteksi prompt password karena format teksnya berubah (sudo-rs menampilkan [sudo: authenticate], bukan [sudo] password for username seperti versi klasik), gunakan opsi --prompt "" pada pemanggilan sudo agar prompt bersifat kustom dan lebih mudah diprediksi oleh skrip.
• Canonical berencana melepas sepenuhnya sudo klasik di Ubuntu 26.10, sehingga manfaatkan Ubuntu 26.04 LTS sebagai masa transisi untuk mengaudit kompatibilitas sudoers dan skrip otomasi kita sebelum opsi kembali ke sudo.ws benar-benar hilang.

4.2.2 /etc/sudoers dan sudoers.d/

Baik sudo-rs maupun sudo klasik membaca file konfigurasi yang sama, yaitu /etc/sudoers dan seluruh file di dalam direktori /etc/sudoers.d/. Konsep ini sama persis dengan pola yang kita gunakan di sshd_config.d/ pada Bab 3: alih-alih mengedit sudoers utama secara langsung, kita menempatkan aturan kustom pada file terpisah agar lebih mudah dilacak dan tidak mengganggu konfigurasi bawaan sistem.

Satu aturan yang tidak boleh dilanggar: jangan pernah mengedit /etc/sudoers atau isi sudoers.d/ menggunakan editor teks biasa seperti nano secara langsung. Selalu gunakan visudo, karena tool ini mengunci file saat sedang diedit dan otomatis memvalidasi sintaks sebelum menyimpan. Salah satu karakter tanda kurung yang salah tempat di sudoers bisa membuat seluruh sudo di server berhenti berfungsi, termasuk untuk akun kita sendiri.

Langkah Praktik

1. Buat file aturan baru untuk group developer lewat visudo, bukan editor biasa.

   sudo visudo -f /etc/sudoers.d/10-developer

2. Isi dengan aturan yang memberikan akses penuh ke seluruh anggota group developer.

   %developer ALL=(ALL:ALL) ALL

   Tanda % di depan nama menandakan aturan ini berlaku untuk group, bukan user tunggal.
3. Untuk akun dengan kebutuhan lebih terbatas, misalnya akun deploy milik pipeline CI/CD yang hanya boleh me-restart satu service tertentu tanpa diminta password, buat file terpisah.

   sudo visudo -f /etc/sudoers.d/20-deploy-restart

   deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

4. Validasi seluruh file sudoers sekaligus, termasuk yang ada di sudoers.d/.

   sudo visudo -c

Verifikasi dan Troubleshooting

• Periksa hak akses yang benar-benar berlaku untuk seorang user menggunakan perintah berikut, tanpa perlu login sebagai user tersebut.

  sudo -l -U username

• Jika sudo menolak membaca sebuah file di sudoers.d/ dengan pesan permission bermasalah, periksa hak akses dan kepemilikannya. File di direktori ini wajib bermode 0440 dan dimiliki oleh root.

  sudo chmod 0440 /etc/sudoers.d/10-developer
  sudo chown root:root /etc/sudoers.d/10-developer

• Sebelum menutup sesi terminal setelah mengubah aturan sudoers, selalu buka sesi terpisah dan uji terlebih dahulu akses sudo di sana. Kebiasaan ini sama pentingnya dengan yang kita terapkan saat hardening SSH pada Bab 3, seBab kesalahan di sudoers bisa mengunci semua orang, termasuk kita, dari akses administratif.

4.3 Manajemen Akun untuk Banyak Pengguna

Menambahkan baris sudoers satu per satu untuk setiap user baru tergolong memadai ketika timnya masih berjumlah dua atau tiga orang. Begitu jumlah Developer dan staf lain yang butuh akses bertambah menjadi puluhan, pendekatan ini berubah menjadi kendala audit. Siapa saja yang punya akses ke mana? Aturan mana yang masih relevan setelah seorang Developer berpindah tim? Jawabannya ada pada dua kebiasaan: mengelola akses lewat group berbasis peran dan menegakkan kebijakan password yang konsisten.

4.3.1 User Group Berbasis Peran (Role-based)

Role-based access berarti kita memberikan hak akses ke group yang mewakili peran atau fungsi kerja, misalnya developer, dbadmin, atau support, bukan ke masing-masing individu. Saat seseorang bergabung atau berpindah peran, kita cukup mengubah keanggotaan group-nya. Saat seseorang keluar dari tim, cukup keluarkan dari group tersebut, dan seluruh hak aksesnya otomatis hilang tanpa perlu menelusuri satu per satu baris sudoers yang mungkin sudah dibuat bertahun-tahun lalu oleh Sysadmin sebelumnya.

Langkah Praktik

1. Buat group untuk setiap peran yang relevan di lingkungan kita.

   sudo groupadd developer
   sudo groupadd dbadmin

2. Tambahkan user ke group yang sesuai dengan perannya. Opsi -a (append) wajib digunakan agar keanggotaan group yang sudah ada sebelumnya tidak ikut terhapus.

   sudo usermod -aG developer alice
   sudo usermod -aG dbadmin bob

3. Pasangkan group ini dengan aturan sudoers yang sudah kita buat pada bagian 4.2.2, atau buat aturan baru khusus dbadmin yang membatasi akses hanya ke perintah manajemen database.

Verifikasi dan Troubleshooting

• Konfirmasi bahwa keanggotaan group user sudah sesuai.

  groups alice

• Jika perubahan group belum terlihat dampaknya saat user tersebut mencoba sudo, minta user untuk logout dan login ulang. Keanggotaan group baru hanya berlaku pada sesi login baru, bukan sesi yang sedang berjalan.
• Di lapangan, hindari godaan menambahkan user langsung ke group sudo bawaan Ubuntu sebagai jalan pintas. Group sudo bawaan ini memberikan akses penuh tanpa batas, sehingga sulit diaudit siapa yang diperbolehkan melakukan apa, dan satu akun saja yang berhasil dibobol Attacker otomatis berarti kontrol penuh atas server. Group kustom berbasis peran jauh lebih mudah dipertanggungjawabkan saat proses audit keamanan seperti yang akan kita bahas pada Bab 34.

4.3.2 Password Policy dan Expiry (chage)

Secara bawaan, Ubuntu Server tidak memaksa password kedaluwarsa. Nilai default di /etc/login.defs menetapkan PASS_MAX_DAYS sebesar 99999 hari (praktis tidak pernah kedaluwarsa), PASS_MIN_DAYS 0 hari, dan PASS_WARN_AGE 7 hari. Nilai-nilai ini hanya berlaku untuk akun baru yang dibuat setelah file diubah, tidak berlaku surut ke akun yang sudah ada. Untuk lingkungan dengan kebijakan keamanan yang lebih ketat, seperti server yang menyimpan data Client sensitif, kita perlu menegakkan kebijakan kedaluwarsa password secara eksplisit lewat chage.

Langkah Praktik

1. Lihat kebijakan password yang sedang berlaku untuk sebuah akun.

   sudo chage -l alice

2. Tetapkan password wajib diganti setiap 90 hari, dengan jeda minimal 7 hari sebelum bisa diganti lagi, dan peringatan 14 hari sebelum kedaluwarsa.

   sudo chage -M 90 -m 7 -W 14 alice

3. Untuk akun kontraktor lepas yang hanya bekerja sampai tanggal tertentu, tetapkan tanggal kedaluwarsa akun secara langsung.

   sudo chage -E 2026-12-31 alice

4. Jika kita baru saja membuat akun dan ingin memaksa user mengganti password bawaan saat login pertama, gunakan opsi berikut.

   sudo chage -d 0 alice

Verifikasi dan Troubleshooting

• Jalankan kembali sudo chage -l alice untuk memastikan seluruh nilai sudah tersimpan sesuai rencana.
• chage membatasi hampir semua opsinya khusus untuk root, kecuali -l yang boleh dijalankan oleh user biasa untuk melihat kebijakan password miliknya sendiri tanpa sudo.
• Jika user tiba-tiba tidak bisa login dan mendapat pesan bahwa password sudah kedaluwarsa, artinya PASS_MAX_DAYS sudah terlewati. Lakukan reset lewat chage -d 0 untuk memaksa penggantian password pada login berikutnya, atau perpanjang batas waktu lewat -M jika kebijakannya memang perlu direvisi.
• Kebijakan kompleksitas password itu sendiri, seperti panjang minimum dan kombinasi karakter, bukan ranah chage. Aturan itu ditegakkan lewat modul pam_pwquality yang akan kita singgung pada bagian PAM berikutnya.

4.4 Pengenalan Autentikasi Terpusat

Semua hal yang kita bahas sejauh ini masih berpusat pada satu server. Begitu Sysadmin harus mengelola puluhan atau ratusan server sekaligus, membuat akun yang sama secara manual di setiap mesin jelas tidak realistis. Di sinilah konsep autentikasi terpusat berperan, yaitu tempat identitas user disimpan di satu lokasi dan digunakan bersama oleh banyak server. Bagian ini murni pengenalan konsep, karena pembahasan implementasi penuh sebuah directory service berada di luar cakupan buku ini.

4.4.1 PAM: Konsep Dasar

PAM (Pluggable Authentication Modules) adalah kerangka kerja yang memisahkan logika autentikasi dari aplikasi yang menggunakannya. Berkat PAM, aplikasi seperti sudo, sshd, atau proses login tidak perlu mengetahui detail cara memverifikasi password. Aplikasi tersebut cukup memanggil PAM, dan PAM yang menentukan modul mana yang digunakan untuk memverifikasi identitas, baik itu password lokal, LDAP, maupun metode lainnya.

Konfigurasi PAM di Ubuntu Server tersimpan di direktori /etc/pam.d/, dengan empat file umum yang menjadi rujukan bersama oleh banyak aplikasi: common-auth (autentikasi), common-account (validasi status akun, misalnya status kedaluwarsa), common-password (aturan penggantian password), dan common-session (tindakan yang dijalankan saat sesi dibuka atau ditutup, misalnya membuat direktori home secara otomatis).

Langkah Praktik: Melihat Stack PAM

1. Lihat isi stack autentikasi yang berlaku untuk hampir semua aplikasi di server.

   cat /etc/pam.d/common-auth

2. Perhatikan kolom kedua pada setiap baris, yang berisi control flag seperti required, requisite, atau sufficient. Flag ini menentukan hal yang terjadi jika sebuah modul gagal, apakah PAM langsung menolak akses atau melanjutkan ke modul berikutnya.
3. Untuk mengaktifkan atau menonaktifkan profil PAM tertentu (misalnya integrasi SSSD yang akan kita singgung pada bagian berikutnya) tanpa mengedit manual setiap file, Ubuntu menyediakan tool interaktif.

   sudo pam-auth-update

Jangan pernah mengedit common-auth, common-account, atau common-password secara manual tanpa perhitungan matang. Satu baris yang salah di sini bisa mengunci seluruh mekanisme login di server, termasuk lewat console, bukan cuma lewat SSH atau sudo seperti risiko yang sudah kita bahas sebelumnya. Gunakan pam-auth-update untuk mengaktifkan atau menonaktifkan modul, dan tetap uji dari sesi terpisah sebelum menutup sesi yang sedang aktif.

Aturan kompleksitas password yang kita singgung pada bagian chage sebelumnya, seperti panjang minimum dan campuran karakter, ditegakkan lewat modul pam_pwquality yang dipasang di common-password. Detail konfigurasinya tersimpan di /etc/security/pwquality.conf.

4.4.2 LDAP sebagai Identity Source

LDAP (Lightweight Directory Access Protocol) adalah protokol untuk mengakses directory service, semacam database terstruktur yang dioptimalkan untuk menyimpan informasi identitas seperti user, group, dan atribut organisasi. Dalam konteks server, LDAP digunakan sebagai identity source terpusat: satu direktori yang menjadi rujukan identitas untuk banyak server sekaligus, sehingga Sysadmin cukup mengelola akun di satu lokasi.

Di Ubuntu Server modern, integrasi ke LDAP tidak lagi memakai package libnss-ldap lama, melainkan lewat SSSD (System Security Services Daemon), yang menjembatani PAM dan NSS (Name Service Switch) ke server LDAP. Di sisi client, integrasi ini datang lewat package sssd, libnss-sss, dan libpam-sss, yang masing-masing menyambungkan resolusi identitas dan autentikasi ke daemon SSSD. Rute pencariannya ditentukan di /etc/nsswitch.conf, misalnya baris berikut yang memberi tahu sistem untuk mencari data user dan group lewat SSSD terlebih dahulu, lalu beralih ke file lokal jika tidak ditemukan.

passwd: sss files systemd
group:  sss files systemd

Satu hal penting yang perlu kita catat sesuai perubahan di Bab 1: package sudo-ldap telah dihapus seiring transisi ke sudo-rs. Artinya, aturan sudoers yang dahulu bisa disimpan langsung di server LDAP (lewat sudoers.ldap) tidak lagi didukung. Praktik yang direkomendasikan saat ini adalah memisahkan dua hal: LDAP/SSSD menangani identitas dan autentikasi (identitas user dan keabsahan password), sedangkan aturan sudoers tetap dikelola secara lokal di setiap server atau didistribusikan lewat tool otomasi seperti Ansible yang akan kita bahas di Bab 36.

Karena implementasi penuh server LDAP berada di luar cakupan buku ini, pahami dulu alur konsepnya. Setelah sssd terpasang dan terhubung ke server LDAP, kita bisa menguji resolusi identitas dengan perintah berikut.

getent passwd nama_user_ldap
getent group nama_group_ldap

Jika hasilnya menampilkan detail user atau group dari direktori LDAP, artinya rantai NSS sampai SSSD telah berjalan dengan benar sebagai identity source terpusat.

Bab ini menutup fondasi manajemen pengguna dan akses tingkat lanjut. Setelah user, group, sudo, dan konsep autentikasi terpusat sudah lebih matang, kita siap melangkah ke Bab 5 untuk membahas systemd tingkat lanjut, mulai dari membuat unit service kustom hingga migrasi dari cgroup v1 ke cgroup v2.