Наслідки безпеки та продуктивності "Переглянути стан сервера"

Це запитання вказує на те, що для різних DMV (динамічних поглядів управління) потрібний дозвіл "Перегляд стану сервера", але я не можу знайти нічого щодо того, ким ви займаєтесь та не хочу надати дозвіл.

Тепер, звичайно, я розумію "найменші дозволи", і чому ви не хочете надавати це нікому, але я не можу знайти жодного керівництва щодо того, як оцінити, чи БУДЬ воно надано чи ні.

Отже, моє питання: Які наслідки для безпеки та продуктивності надання дозволу користувачу "Переглянути стан сервера". Що вони можуть зробити, що їм, можливо, не слід цього робити ...

Оновлення : одне значення полягає в тому, що користувач зможе використовувати DMV для перегляду запитів. Якщо запити або параметри запиту можуть містити конфіденційну інформацію, яку користувач не міг би бачити, дозволяючи VIEW SERVER STATE дозволить їм це робити (тобто dob = або ssn =).

Немає жодних суттєвих проблем, пов'язаних із ефективністю роботи, з яких я можу подумати, не надаючи цього дозволу. З точки зору безпеки, ви ризикуєте дозволити користувачеві побачити, що ви найбільше деталізуєте про ваші слабкі місця, тому, наприклад, зловмисник може переглядати ваші найпоширеніші статистики очікування, які можуть допомогти їм націлитись на атаку DoS проти вашого сервера. .

Чи можливо це? Безумовно. Це ймовірно? Я вимушений сказати «Ні», але пам’ятайте, що за оцінками, 90 відсотків нападів на компанії - це внутрішні зловмисники.

Як адміністратор, ви б розглядали цю інформацію як у вашому домені (продуктивність / використання індексу / тощо), але є потенційно вагомі причини, що організація, яка розробляє, хотіла б цю інформацію для великої застарілої системи, яку вони підтримують, ідентифікуючи таблиці зомбі, які лише торкаються наприклад, процесами технічного обслуговування.

Зрештою, це завжди стає проблемою "удачі та щедрості", оскільки заклик про те, чи є якийсь конкретний запит виправданим, закінчується м'яким вибором, а не чіткою формулою. Використання моделей найкращих практик, не дивлячись на контекст, саме по собі є досить неприємним анти-закономірністю, і реальність полягає в тому, що багато хто підходить до своїх позицій, "розмовляючи рукою" як вихідну точку.

Щодо наслідків щодо продуктивності, я не знаю жодного для цього чи будь-якого іншого дозволу.

Щодо:

Що вони можуть зробити, що їм, можливо, не слід цього робити

Простіше кажучи, вони можуть бачити речі, які, можливо, не повинні бачити. І не думайте про це з точки зору просто SQL Server. Цей конкретний дозвіл також керує DMV, такими як sys.dm_os_sys_info та безліччю інших, що забезпечують розуміння хост-машини (обладнання, послуги тощо). Ви не завжди знаєте, яку інформацію можна використовувати проти вас. І навіть якщо ви не в порядку, коли хтось бачить усе, що дозволено цим дозволом зараз, іноді DMV додаються в пакети послуг / накопичувальні оновлення, і, можливо, нова інформація отримує інформацію, про яку ви не знаєте.

Я не можу знайти вказівки щодо того, як оцінити, чи БУДЬ дозволено це чи ні.

Оскільки ви вже згадали про надання людям мінімальних необхідних дозволів, що насправді зводиться до цього: чи потрібен хтось цей дозвіл для використання спеціальних програм ? Значить, комусь потрібна гнучкість придумувати власні запити? Чи може створити одну чи більше збережених процедур та / або багатовиразових телевізійних програм? Якщо так, то вам не потрібно надавати дозволи будь-якому користувачеві (який тоді вільний від будь-якого дозволеного цим дозволом), а натомість ви надаєте дозволи до коду (який робить лише те, що закодовано). Підписання модуля - це, як ви це зробите. Загальна концепція:

1. Створіть збережені процедури (и) та / або мульти-операторські TVF (и) для виконання потрібних дій.
2. Надайте EXECUTEці модулі будь-якому користувачеві та / або ролям, необхідних для виконання цих дій
3. Створіть сертифікат
4. Підпишіть модуль (и), використовуючи цей сертифікат (використовуючи ADD SIGNATURE)
5. Скопіюйте сертифікат у [master]базу даних (тобто створіть сертифікат, [master]використовуючи відкритий ключ сертифіката, який використовується для підпису модуля (модулів).
6. Створіть логін із сертифіката, скопійованого в [master]
7. Надайте необхідні дозволи на рівні екземпляра для цього входу на основі сертифіката (який може включати додавання його до ролей рівня екземпляра).

Деякі приклади див .:

• Як підтримувати відновлення права власності на базу даних у різних доменах?

• Безпечно та легко використовувати дозволи високого рівня, не надаючи їх нікому: рівень сервера

Це проблема безпеки. Ви ніколи не можете помилитися, якщо слідувати Принципу найменш привілейованих . Іншими словами, якщо автентифікаційний довіритель не потребує певного дозволу, тоді не дайте їм його. Чи роздаєте ви інформацію про тип замків у ваших дверях іншим людям, яким це не потрібно знати про ваш будинок? Я би сподівався, що ні. Вони, мабуть, нічого б не зробили, але це все ще не розсудливо.

Якби ми базувались на принципах даних від удачі та великодушності, ми траплялися б у більшій проблемі трохи частіше. Безпека - це аспект, коли ви повинні надавати лише тоді, коли зможете захистити, чому ви це надали. Ви просто надаєте комусь більше інформації, ніж вони повинні знати . Не робіть цього. Стан сервера ще чутливий.