Кто-нибудь знает о каких-либо угрозах безопасности с настройками PUBLIC по умолчанию для sql 2005/8?
Я запустил sp_helprotect, и он перечислил гранты PUBLIC, и теперь у меня есть аудитор, говорящий мне, что у меня есть риск для безопасности, потому что PUBLIC имеет доступ к системной информации. Прежде чем я начну излагать свой случай, я хотел узнать, есть ли у кого-нибудь какие-либо ссылки или информация, которую они могут предоставить, в которой подробно описано, как настройки по умолчанию допускают риск для безопасности.
для записи, аудитор упомянул, что эти настройки позволяют взламывать пароли, потому что они могут просматривать хэш пароля. Мне не удалось убедиться, что этот параметр позволяет просматривать эту информацию в представлениях каталога sys.
заранее спасибо
Вот пример BOL, объясняющий, как публичная роль влияет на видимость метаданных для всех пользователей: http://msdn.microsoft.com/en-us/library/ms187113(SQL.90).aspx
Есть некоторые вещи, которые обычно должны быть видны всем, иначе что-то сломается (sys.databases - один из примеров, даже если он не указан в этой статье - по историческим причинам каждый может получить список всех баз данных на сервере, но вы, конечно, можете отозвать это разрешение). Когда вы начинаете отменять публичный доступ к некоторым фрагментам метаданных, все становится забавным.
Приведу пример: что-то сильно сломается, если вы отзовете публичное разрешение на выбор из sys.databases. Правильный способ сделать это - ОТМЕНИТЬ ПРОСМОТР ЛЮБОЙ БАЗЫ ДАННЫХ из общедоступной - тогда sys.databases будет "отфильтрован", и вы будете видеть только те базы данных, для которых у вас есть разрешения. Но это не дает вам никакой реальной безопасности, поскольку любой может перечислить все базы данных, выполнив SELECT DB_NAME (X) и предоставив произвольные значения для X (это известная лазейка).
Что касается паролей, то в конфигурации по умолчанию для SQL2005 и SQL 2008 через роль public вы можете видеть только два входа через sys.syslogins: себя и sa. И вы не увидите хеш пароля ни для одного из них. Таким образом, получение хешей для взлома не вариант. И взлом этих хэшей в любом случае требует подхода грубой силы, поэтому он работает только для слабых паролей или паролей по словарю.
Мой опыт работы с аудиторами показывает, что они, как правило, не обращают внимания на такие мелочи, как публичные разрешения, но упускают из виду главное. YMMV.
HTH
В 2000 г. публичная роль имеет доступ к гораздо большему, чем в 2005 г., и это может быть источником проблем аудитора. Разделение пользователя и схемы должно решить большинство проблем, но вы должны создать пользователя с минимальными разрешениями и посмотреть, что он может видеть. Вы захотите попробовать:
master.sys.databases (и все остальное, что может выдавать информацию о том, что хранится в экземпляре) master.dbo.syslogins (который содержит хэши паролей - sysxlogins в 2000 году)
И вы также хотите изменить все XP в мастере, чтобы публичная роль не имела разрешения на выполнение ни для одного из них. Есть статья и фрагмент кода, которые сделают это Вот.
Обратите внимание, что НЕ рекомендуется каким-либо образом изменять саму публичную роль.
Надеюсь это поможет!
PS Если вы вернете NULL для пароля в таблице syslogins, это потому, что логин не использует аутентификацию SQL. Использование только Windows - хороший способ устранить этот риск, но вам по-прежнему нужен пароль для (отключенной) учетной записи SA.