Последствия «Просмотр состояния сервера» для безопасности и производительности

Этот вопрос указывает на то, что разрешение «Просмотр состояния сервера» требуется для различных DMV (динамические административные представления), но я не могу ничего узнать о том, кем вы занимаетесь, и не хотите предоставлять разрешение.

Теперь, конечно, я понимаю «наименьшее количество разрешений», и почему вы не хотите просто предоставлять его кому-либо, но я не могу найти никакого руководства о том, как оценить, ДОЛЖНО ли оно быть предоставлено или нет.

Итак, мой вопрос: каковы последствия для безопасности и производительности предоставления пользователю разрешения «Просмотр состояния сервера». Что они могут сделать, что им, возможно, не следует позволять делать ...

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

Нет никаких существенных проблем с производительностью, о которых я могу думать после предоставления этого разрешения. С точки зрения безопасности вы рискуете позволить пользователю увидеть, что вы больше всего знаете о своих слабых местах, так что, например, злоумышленник может просмотреть ваши самые распространенные статистические данные ожидания, которые могут помочь им нацелить DoS-атаку на ваш сервер. ,

Это возможно? Определенно. Это вероятно? Я вынужден сказать «Нет», но помните, что, по оценкам, 90 процентов атак на компании осуществляются внутренними злоумышленниками.

Как администратор, вы бы рассматривали эту информацию как находящуюся в вашем домене (производительность / использование индекса / и т. Д.), Но есть потенциально убедительные причины, по которым организация-разработчик хотела бы получить эту информацию для большой устаревшей системы, которую они поддерживают, - идентифицируя таблицы зомби, к которым только прикоснулись например, процессами обслуживания.

В конце концов, это всегда заканчивается вопросом «удачи и щедрости», поскольку призыв к обоснованности какого-либо конкретного запроса оказывается мягким выбором, а не четкой формулой. Использование шаблонов наилучшей практики без учета контекста само по себе является довольно неприятным анти-шаблоном, и реальность такова, что многие подходят к своим позициям с «разговором с рукой» в качестве отправной точки.

Что касается влияния на производительность, я не знаю ни одного для этого или любого другого разрешения.

Что касается:

Что они могут сделать, что им может быть запрещено

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

Я не могу найти какое-либо руководство о том, как оценить, ДОЛЖНО ли это быть предоставлено или нет.

Поскольку вы уже упоминали о предоставлении людям минимальных необходимых разрешений, на самом деле все сводится к следующему: нужно ли кому-то это разрешение для специального использования? То есть кому-то нужна гибкость, чтобы придумывать свои собственные запросы? Будет ли работать создание одной или нескольких хранимых процедур и / или TVF с несколькими операторами? Если это так, то вам не нужно предоставлять разрешения какому-либо пользователю (который затем свободен от всего, что разрешено этим разрешением), и вместо этого вы предоставляете разрешения для кода (который выполняет только то, для чего он предназначен). Подписание модуля - это то, как вы выполняете это. Общая концепция:

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

Для некоторых примеров, пожалуйста, смотрите:

• Как сохранить право собственности на базу данных между доменами?

• Безопасно и легко используйте высокоуровневые разрешения, не предоставляя их никому: на уровне сервера

Это проблема безопасности. Вы никогда не ошибетесь, если будете следовать принципу наименее привилегированных . Другими словами, если аутентификационный принципал не нуждается в определенном разрешении, не предоставляйте его им. Вы даете информацию о типе замков на вашей двери другим людям, которым не нужно знать это о вашем доме? Я надеюсь, что нет. Скорее всего, они бы ничего не сделали, но это все же не разумно.

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