Implikasi Keamanan dan Kinerja dari "View Server State"

Pertanyaan ini menunjukkan bahwa izin "Lihat Status Server" diperlukan untuk berbagai DMV (tampilan manajemen dinamis), tetapi saya tidak dapat menemukan apa pun tentang siapa yang Anda lakukan dan tidak ingin memberikan izin kepada.

Sekarang tentu saja saya mengerti "izin paling tidak", dan mengapa Anda tidak ingin hanya memberikannya kepada siapa pun, tetapi saya tidak dapat menemukan panduan tentang cara mengevaluasi apakah itu HARUS diberikan atau tidak.

Jadi, pertanyaan saya: Apa implikasi keamanan dan kinerja dari pemberian izin "View Server State" pengguna. Apa yang bisa mereka lakukan yang seharusnya tidak boleh mereka lakukan ...

Pembaruan : salah satu implikasinya adalah bahwa pengguna akan dapat menggunakan DMV untuk melihat kueri. Jika parameter kueri atau kueri dapat berisi informasi rahasia yang tidak dapat dilihat oleh pengguna, jika memungkinkan, LIHAT SERVER STATE memungkinkan mereka melakukannya (mis. Dob = atau ssn =).

Tidak ada masalah kinerja signifikan yang dapat saya pikirkan dari pemberian izin ini. Dari sudut pandang keamanan, Anda berisiko membiarkan pengguna melihat apa yang paling detail tentang titik lemah Anda, jadi misalnya, pengguna jahat dapat melihat statistik penantian Anda yang paling umum, yang dapat membantu mereka menargetkan serangan DoS terhadap server Anda .

Apakah ini mungkin? Pastinya. Apakah ini mungkin? Saya terpaksa mengatakan Tidak, tetapi ingat bahwa diperkirakan 90 persen serangan terhadap perusahaan berasal dari penyerang internal.

Sebagai administrator Anda akan melihat informasi ini berada di domain Anda (kinerja / penggunaan indeks / dll) tetapi ada alasan kuat yang berpotensi bahwa organisasi pengembangan menginginkan informasi ini untuk sistem warisan besar yang mereka dukung - mengidentifikasi tabel zombie yang hanya disentuh dengan proses pemeliharaan misalnya.

Pada akhirnya itu selalu berakhir menjadi masalah "keberuntungan dan kemurahan hati" karena panggilan apakah permintaan tertentu dibenarkan akhirnya menjadi pilihan yang lembut dan bukan formula yang segar. Penggunaan pola praktik terbaik tanpa melihat konteks itu sendiri merupakan anti-pola yang cukup buruk dan kenyataan adalah bahwa banyak orang mendekati posisi mereka dengan "berbicara dengan tangan" sebagai titik awal.

Mengenai implikasi kinerja, saya tidak mengetahui adanya hal ini atau izin lainnya.

Mengenai:

Apa yang bisa mereka lakukan yang seharusnya tidak boleh mereka lakukan

Sederhananya, mereka dapat melihat hal-hal yang mungkin tidak seharusnya mereka lihat. Dan jangan pikirkan ini hanya dalam hal SQL Server. Izin khusus ini juga mengatur DMV seperti sys.dm_os_sys_info dan beberapa lainnya yang memberikan wawasan tentang mesin host (perangkat keras, layanan, dll). Anda tidak selalu tahu info apa yang dapat digunakan untuk melawan Anda. Dan, bahkan jika Anda setuju dengan seseorang yang melihat segala sesuatu diizinkan oleh izin ini sekarang, kadang-kadang DMV ditambahkan dalam Paket Layanan / Pembaruan Kumulatif, dan jadi mungkin sepotong informasi baru terekspos yang tidak Anda sadari.

Saya tidak dapat menemukan panduan tentang cara mengevaluasi apakah itu HARUS diberikan atau tidak.

Karena Anda telah menyebutkan memberi orang izin minimum yang diperlukan, apa yang sebenarnya terjadi adalah: apakah seseorang memerlukan izin ini untuk penggunaan ad hoc ? Artinya, apakah seseorang membutuhkan fleksibilitas untuk mengajukan pertanyaan mereka sendiri? Apakah membuat satu atau lebih prosedur tersimpan dan / atau TVF multi-pernyataan berfungsi? Jika demikian, maka Anda tidak perlu memberikan izin kepada pengguna mana pun (yang kemudian bebas untuk apa pun yang diizinkan oleh izin itu), dan sebaliknya Anda memberikan izin pada kode (yang hanya melakukan apa yang dikodekan untuk dikerjakan). Penandatanganan Modul adalah bagaimana Anda mencapai ini. Konsep umum adalah:

1. Buat prosedur tersimpan dan / atau TVF multi-pernyataan untuk melakukan tindakan yang diinginkan.
2. Berikan EXECUTEmodul-modul ini kepada pengguna dan / atau peran apa pun yang diperlukan untuk melakukan tindakan ini
3. Buat sertifikat
4. Tanda tangani modul menggunakan sertifikat itu (menggunakan ADD SIGNATURE)
5. Salin sertifikat ke [master]database (mis. Buat sertifikat [master]menggunakan kunci publik dari sertifikat yang digunakan untuk menandatangani modul).
6. Buat login dari sertifikat yang disalin [master]
7. Berikan izin tingkat instance apa pun yang diperlukan untuk login berbasis sertifikat itu (yang dapat mencakup menambahkannya ke peran tingkat instance).

Untuk beberapa contoh, silakan lihat:

• Bagaimana cara mempertahankan kepemilikan database yang dipulihkan di seluruh domain?

• Aman dan Mudah Menggunakan Izin Tingkat Tinggi Tanpa Memberi Mereka Kepada Siapa pun: Tingkat server

Ini masalah keamanan. Anda tidak akan pernah salah jika Anda mengikuti Prinsip Least Privileged . Dengan kata lain, jika kepala sekolah yang otentik tidak memerlukan izin khusus, maka jangan berikan kepada mereka. Apakah Anda memberikan informasi mengenai jenis kunci di pintu Anda kepada orang lain yang tidak perlu mengetahuinya tentang rumah Anda? Saya harap tidak. Mereka mungkin tidak akan melakukan apa-apa, tetapi itu masih tidak bijaksana.

Jika kita mendasarkan prinsip data dari keberuntungan dan kemurahan hati, kita akan berada dalam masalah yang lebih besar sedikit lebih sering. Keamanan adalah aspek di mana Anda hanya harus memberikan ketika Anda bisa membela mengapa Anda memberikannya. Anda hanya memberi seseorang lebih banyak informasi daripada yang perlu mereka ketahui . Jangan lakukan itu. Status server masih sensitif.