Prinsip Least Privilege, Dijelaskan

Least privilege terdengar jelas sekali ketika diucapkan: berikan akun, proses, atau pengguna hanya akses yang dibutuhkannya untuk menjalankan pekerjaannya, tidak lebih. Celah antara mengatakan itu dan benar-benar menjalankan sistem Anda dengan cara itu adalah tempat sebagian besar pelanggaran berubah dari insiden kecil menjadi kompromi domain penuh.

Apa yang benar-benar artinya

Prinsip least privilege (PoLP) mengatakan setiap subjek dalam sistem — pengguna, akun layanan, aplikasi, kontainer — harus beroperasi dengan set izin minimum yang diperlukan untuk menyelesaikan fungsinya. Bukan izin yang nyaman. Bukan izin yang diberikan seseorang tiga tahun lalu dan lupa untuk dicabut. Minimum.

Ini berlaku di setiap lapisan: izin sistem file, peran basis data, cakupan API, kebijakan IAM cloud, aturan firewall, akses sudo. Proses server web yang membaca file statis tidak perlu akses tulis ke /etc. Skrip pelaporan yang hanya menjalankan kueri SELECT tidak memerlukan peran basis data dengan hak DROP TABLE. Magang marketing tidak memerlukan admin domain hanya karena lebih mudah daripada mencari tahu grup yang tepat.

Mengapa hal ini lebih penting daripada kedengarannya

Ketika penyerang mengompromikan akun atau proses, mereka mewarisi apa pun yang dapat dilakukan akun itu. Jika laptop karyawan yang ter-phishing hanya memiliki akses ke file share yang relevan dengan tim mereka, radius ledak dari phishing itu terbatas. Jika akun yang sama kebetulan memiliki hak admin domain karena IT menyiapkannya dengan cara itu sekali untuk troubleshooting dan tidak pernah mengembalikannya, penyerang sekarang memiliki jaringan.

Ini adalah logika di balik sebagian besar laporan forensik pasca-pelanggaran: akses awal bernilai rendah, tetapi pergerakan lateral melalui akun yang terlalu berhak mengubahnya menjadi ransomware di seluruh lingkungan. Privilege berlebih tidak menyebabkan kompromi awal, tetapi hampir selalu yang membuat kompromi menjadi mahal.

Di mana hal ini muncul dalam praktik

Cloud IAM. AWS, Azure, dan GCP semuanya default pada perilaku permisif jika Anda tidak berhati-hati — kebijakan IAM dengan "Action": "*" dan "Resource": "*" akan lulus validasi dan bekerja dengan baik, sampai kunci akses yang bocor memberikan penyerang kontrol akun penuh. Batasi kebijakan ke tindakan spesifik dan ARN resource alih-alih menggunakan wildcard.

Akun layanan. Ini sering menjadi pelaku terburuk karena tidak ada yang meninjau mereka seperti mereka meninjau akun manusia. Pipeline CI/CD yang digunakan untuk menerapkan ke satu bucket S3 tidak boleh menahan kredensial yang dapat membaca setiap bucket di akun.

Peran basis data. Pisahkan peran pelaporan read-only dari peran aplikasi yang memerlukan INSERT/UPDATE, dan pisahkan mereka dari peran DBA yang dapat mengubah schema. PostgreSQL dan MySQL keduanya mendukung pernyataan GRANT granular — gunakan mereka alih-alih memberikan setiap koneksi aplikasi yang setara dengan root.

Sudo dan admin lokal. Elevasi just-in-time (minta akses, dapatkan untuk jendela terbatas, hilang secara otomatis) selalu mengungguli hak admin yang berdiri. Alat seperti sudo dengan aturan terbatas waktu, atau solusi PAM di lingkungan enterprise, ada khusus untuk ini.

Ketegangan dengan