Bagikan melalui


Mengurangi izin dan aplikasi yang memiliki hak istimewa berlebihan

Sebagai pengembang yang bertujuan untuk merancang dan mengimplementasikan aplikasi yang mengikuti prinsip panduan Zero Trust, Anda ingin meningkatkan keamanan aplikasi dengan hak istimewa paling sedikit. Sangat penting bahwa Anda mengurangi permukaan serangan aplikasi Anda dan efek pelanggaran keamanan.

Dalam artikel ini, Anda mempelajari mengapa aplikasi tidak boleh meminta lebih banyak izin daripada yang mereka butuhkan. Anda memahami istilah hak istimewa yang berlebihan dan menemukan rekomendasi dan praktik terbaik untuk membatasi hak istimewa dalam aplikasi Anda untuk mengelola akses dan meningkatkan keamanan.

Apa itu hak istimewa berlebihan?

Hak istimewa berlebihan terjadi ketika aplikasi meminta atau menerima lebih banyak izin daripada yang dibutuhkan agar berfungsi dengan benar. Tingkatkan pemahaman Anda tentang hak istimewa yang berlebihan dengan contoh izin yang tidak digunakan dan dapat dididik ulang di sisa artikel ini.

Izin yang tidak digunakan

Untuk contoh kunci yang tidak digunakan ini, bayangkan bahwa ada tiga pintu terkunci (biru, kuning, dan hijau) seperti yang ditunjukkan pada diagram berikut.

Diagram memperlihatkan tiga pintu dengan kunci yang sesuai untuk mengilustrasikan izin yang tidak digunakan.

Asetmu ada di belakang pintu. Anda memiliki tiga kunci (biru, kuning, dan hijau) yang memungkinkan Anda membuka pintu yang sesuai. Misalnya, kunci biru dapat membuka pintu biru. Ketika Anda hanya membutuhkan akses ke pintu kuning, Anda hanya membawa kunci kuning.

Untuk melindungi aset Anda dengan sebaik-baiknya, Anda hanya membawa kunci yang Anda butuhkan saat membutuhkannya dan menyimpan kunci yang tidak digunakan di lokasi yang aman.

Izin yang dapat dikurangi

Contoh kunci yang dapat dididik ulang lebih rumit daripada contoh kunci yang tidak digunakan yang sekarang kita tambahkan dua kunci khusus seperti yang ditunjukkan dalam diagram berikut.

Diagram menunjukkan tiga pintu dengan kunci yang sesuai untuk mengilustrasikan izin yang dapat dididik ulang.

Kunci hitam pertama adalah kunci pass yang dapat membuka semua pintu. Kunci hitam kedua dapat membuka pintu kuning dan hijau. Ketika Anda hanya membutuhkan akses ke pintu kuning dan hijau, Anda hanya membawa kunci hitam kedua. Anda menyimpan kunci pass Anda di lokasi yang aman dengan kunci hijau redundan.

Di dunia identitas Microsoft, kuncinya adalah izin akses. Sumber daya Anda dan Anda, pemegang kunci, adalah aplikasi. Jika Anda memahami risiko membawa kunci yang tidak perlu, Anda menyadari risiko aplikasi Anda memiliki izin yang tidak perlu.

Celah dan risiko izin

Bagaimana pintu dan kunci dapat membantu memahami bagaimana hak istimewa berlebihan terjadi? Mengapa aplikasi Anda mungkin memiliki izin yang tepat untuk melakukan tugas, tetapi masih memiliki hak istimewa yang berlebihan? Mari kita lihat celah izin yang dapat menyebabkan perbedaan dalam diagram berikut.

Grafik di sebelah kanan: Sumbu Y - Izin, sumbu X - Waktu; Kurva atas - Izin yang Diberikan, Kurva lebih rendah - Izin yang Digunakan; Statistik di sebelah kanan dijelaskan dalam konten artikel.

Sumbu X mewakili Waktu dan sumbu Y mewakili Izin. Pada awal Waktu yang diukur, Anda meminta dan menerima izin untuk aplikasi Anda. Ketika bisnis tumbuh dan berubah dari waktu ke waktu, Anda menambahkan izin baru untuk mendukung kebutuhan Anda dan kelereng Izin yang Diberikan meningkat. Izin yang Digunakan mungkin lebih rendah dari Izin yang Diberikan saat Anda lupa menghapus izin yang tidak perlu (misalnya, jika aplikasi tidak rusak) mengakibatkan Celah Izin.

Berikut adalah pengamatan menarik dalam platform identitas Microsoft.

  • Kami memiliki lebih dari 4.000 API di Microsoft Graph.
  • Lebih dari 200 izin Microsoft Graph tersedia di platform identitas Microsoft.
  • Pengembang memiliki akses ke berbagai data dan kemampuan untuk menerapkan granularitas pada izin yang diminta aplikasi mereka.
  • Dalam penyelidikan kami, kami menemukan bahwa aplikasi hanya memiliki 10% izin yang sepenuhnya digunakan untuk skenarionya.

Pikirkan dengan cermat tentang izin apa yang sebenarnya diperlukan aplikasi Anda. Waspadai kesenjangan izin dan periksa izin aplikasi Anda secara teratur.

Keamanan disusupi karena kelebihan hak istimewa

Mari kita selaraskan lebih dalam risiko yang dihasilkan dari kesenjangan izin dengan contoh. Skenario penyusupan ini terdiri dari dua peran: admin TI dan pengembang.

  • Admin TI: Jeff adalah admin penyewa yang memastikan bahwa aplikasi di ID Microsoft Entra dapat dipercaya dan aman. Bagian dari tugas Jeff adalah memberikan persetujuan untuk izin yang diperlukan pengembang aplikasi.
  • Pengembang: Kelly adalah pengembang aplikasi yang menggunakan platform identitas Microsoft dan memiliki aplikasi. Tugas Kelly adalah memastikan bahwa aplikasi memiliki izin yang tepat untuk melakukan tugas yang diperlukan.

Skenario kompromi keamanan umum berikut untuk overprivileged biasanya memiliki empat tahap.

Diagram yang dijelaskan dalam konten artikel - empat tahap skenario penyusupan keamanan.

  1. Pertama, pengembang mulai mengonfigurasi aplikasi dan menambahkan izin yang diperlukan.
  2. Kedua, admin TI meninjau izin yang diperlukan dan memberikan persetujuan.
  3. Ketiga, aktor jahat mulai memecahkan kredensial pengguna dan berhasil meretas identitas pengguna.
  4. Jika pengguna memiliki beberapa aplikasi, mereka juga memiliki hak istimewa yang berlebihan. Pelaku jahat dapat dengan cepat menggunakan token izin yang diberikan untuk mengambil data sensitif.

Aplikasi-aplikasi dengan hak istimewa berlebihan

Entitas memiliki hak istimewa yang berlebihan ketika meminta atau menerima lebih banyak izin daripada yang dibutuhkan. Definisi aplikasi yang memiliki hak istimewa berlebihan dalam platform identitas Microsoft adalah, "aplikasi apa pun dengan izin yang tidak digunakan atau dapat dikurangi."

Mari kita gunakan Microsoft Graph sebagai bagian dari platform identitas Microsoft dalam contoh dunia nyata untuk lebih memahami izin yang tidak digunakan dan izin yang dapat dikurangi.

Kolom kiri: Tidak digunakan - Diberikan satu atau beberapa izin yang tidak diperlukan sama sekali untuk panggilan API yang dilakukan. Kolom kanan: Reducible - Izin yang memiliki alternatif dengan hak istimewa lebih rendah yang masih akan menyediakan akses untuk tugas yang diperlukan.

Izin yang tidak digunakan terjadi saat aplikasi Anda menerima izin yang tidak diperlukan untuk tugas yang diinginkan. Misalnya, Anda sedang membangun aplikasi kalender. Aplikasi kalender Anda meminta dan menerima Files.ReadWrite.All izin. Aplikasi Anda tidak terintegrasi dengan API file apa pun. Oleh karena itu, aplikasi Anda memiliki izin yang tidak digunakan Files.ReadWrite.All .

Izin yang dapat dididik lebih sulit ditemukan. Ini terjadi ketika aplikasi Anda menerima beberapa izin tetapi memiliki alternatif dengan hak istimewa yang lebih rendah yang akan memberikan akses yang memadai untuk tugas yang diperlukan. Dalam contoh aplikasi kalender, aplikasi Anda meminta dan menerima Files.ReadWrite.All izin. Namun, hanya perlu membaca file dari OneDrive pengguna yang masuk dan tidak perlu membuat file baru atau memodifikasi file yang sudah ada. Dalam hal ini, aplikasi Anda hanya sebagian menggunakan Files.ReadWrite.All sehingga Anda perlu menurunkan ke Files.Read.All.

Rekomendasi untuk mengurangi skenario berlebih

Keamanan adalah perjalanan, bukan tujuan. Ada tiga fase berbeda dalam siklus hidup keamanan:

  • Pencegahan
  • Audit
  • Remediasi

Diagram berikut mengilustrasikan rekomendasi untuk mengurangi skenario yang terlalu istimewa.

Diagram yang dijelaskan dalam konten artikel - rekomendasi untuk mencegah, mengaudit, dan memulihkan skenario yang terlalu istimewa.

  • Cegah: Saat membangun aplikasi, Anda harus sepenuhnya memahami izin yang diperlukan untuk panggilan API yang perlu dilakukan aplikasi Anda, dan hanya meminta apa yang diperlukan untuk mengaktifkan skenario Anda. Dokumentasi Microsoft Graph memiliki referensi yang jelas untuk izin hak istimewa paling sedikit ke sebagian besar izin istimewa untuk semua titik akhir. Perhatikan skenario yang terlalu istimewa saat Anda menentukan izin mana yang Anda butuhkan.
  • Audit: Anda dan admin TI harus secara teratur meninjau hak istimewa aplikasi yang diberikan sebelumnya.
  • Remediasi: Jika Anda atau admin TI melihat aplikasi yang terlalu istimewa dalam ekosistem, Anda harus berhenti meminta token untuk izin yang terlalu istimewa. Admin TI harus mencabut persetujuan yang diberikan. Langkah ini biasanya memerlukan perubahan kode.

Praktik terbaik untuk mempertahankan izin hak istimewa paling sedikit

Dua insentif utama untuk mempertahankan izin hak istimewa paling sedikit dengan aplikasi Anda mendorong adopsi aplikasi dan menghentikan penyebaran.

Kolom kiri: Adopsi Drive - Bangun aplikasi tepercaya untuk pelanggan dengan menghindari permintaan izin yang berlebihan. Kolom kanan: Hentikan Spread - Attackers tidak dapat menggunakan hak istimewa yang berlebihan untuk mendapatkan akses lebih lanjut.

  • Dorong adopsi dengan membangun aplikasi tepercaya untuk pelanggan yang menghindari permintaan izin yang berlebihan. Batasi izin aplikasi Anda hanya untuk apa yang diperlukan untuk menyelesaikan tugasnya. Praktik ini mengurangi potensi radius serangan ledakan dan meningkatkan adopsi pelanggan aplikasi Anda. Terapkan lebih banyak pengamatan saat meninjau izin yang diminta aplikasi dan memutuskan apakah akan memberikan izin aplikasi.
  • Hentikan penyebaran dengan memastikan penyerang tidak dapat menggunakan hak istimewa yang berlebihan untuk mendapatkan akses lebih lanjut. Saat Anda membuat aplikasi yang meminta izin yang tidak perlu, kemungkinan besar akan menerima persetujuan atau ditolak sama sekali. Cara terbaik untuk mengontrol kerusakan adalah dengan mencegah penyerang mendapatkan hak istimewa yang ditinggikan yang meningkatkan cakupan kompromi. Misalnya, jika aplikasi Anda hanya perlu User.ReadBasic.All membaca informasi dasar pengguna, maka OneDrive, Outlook, Teams, dan data rahasia apa pun aman jika aplikasi disusupi.

Langkah berikutnya