настройки PUBLIC по умолчанию
Я настроил решение с DNSMadeEasy. У них есть хороший скринкаст относительно обработки отказа DNS. У них есть разумная оценка. В нашей системе мы реализовали простой сервис, который "проверяет с помощью ping-запросов" различные компоненты в нашей системе (база данных, очередь JMS, соединение S3) и возвращается хорошо, который может использовать DNSMadeEasy. Каждый раз, когда исключение происходит, DNSMadeEasy удалит тот сервер из списка серверов, который отвечает на том поиске DNS.
В 2000 общедоступная роль имеет доступ к намного больше, чем в 2005 вперед - это может быть источником проблем аудитора. Разделение пользователя/схемы должно заботиться о большинстве проблем, но необходимо создать пользователя с минимальными полномочиями и видеть то, что оно видит. Вы захотите попробовать:
master.sys.databases (и что-либо еще, что могло отдать информацию о том, что хранится в экземпляре) master.dbo.syslogins (который содержит хэши пароля - sysxlogins на 2000),
И Вы также хотите изменить весь XPS в ведущем устройстве так, чтобы общедоступная роль не имела, выполняют разрешение на любом из них. Существует статья и часть кода, который сделает это здесь.
Обратите внимание, что НЕ рекомендуется изменить саму общедоступную роль всегда.
Надеюсь, это поможет!
PS при возвращении ПУСТОГО УКАЗАТЕЛЯ для пароля в syslogins таблице это - потому что вход в систему не использует аутентификацию SQL. Используя только для Windows хороший способ удалить этот риск, но у Вас все еще должен быть пароль для (отключенной) учетной записи SA.
-
1спасибо paul, та ссылка является замечательным ресурсом для запуска с – SQLRockstar 26 June 2009 в 18:49
-
2Действительно ли это - тот же Аудитор, который давал Вам дерьмо несколько недель назад? Общественность can' t чтение больше сидят на корточках. Скажите им добираться до скорости на технологии от 4 года назад прежде, чем сказать Вам what' s неправильно с ним. – mrdenny 26 June 2009 в 20:35
-
3" crap" сильное слово, let' s просто говорят, что они задают правильные вопросы. у нас просто была встреча, и я смог разъяснить им относительно Открытого доступа, но я действительно должен проверить несколько дополнительных вещей на своем конце также. – SQLRockstar 26 June 2009 в 22:01
Вот является BOL aritcle объяснением, как общедоступная роль влияет на видимость метаданных для всех пользователей: http://msdn.microsoft.com/en-us/library/ms187113 (SQL.90) .aspx
Существует некоторый материал, который обычно должен быть visble всем, или вещи повредятся (sys.databases, один из примеров, даже если он не перечислен в этом aricle - по исторической причине, все могут получить список всех баз данных по серверу, но можно, конечно, отменить это разрешение). Вещи имеют тенденцию становиться забавными, когда Вы начинаете отклонять открытый доступ к некоторым частям метаданных.
Дать Вам пример: вещи повредят большой успех при отмене общедоступного разрешения выбрать из sys.databases. Надлежащий способ сделать это состоит в том, чтобы ОТМЕНИТЬ, ПРОСМАТРИВАЮТ ЛЮБУЮ БАЗУ ДАННЫХ от общественности - затем sys.databases, будет "фильтрован", и Вы будете только видеть базы данных, для которых у Вас есть полномочия. Но это не дает Вам реальной безопасности, поскольку любой может все еще перечислить все базы данных путем выполнения ИЗБРАННОГО DB_NAME (X) и предоставления произвольных значений для X (это - известная лазейка).
И с точки зрения паролей, в конфигурации по умолчанию для SQL2005 и SQL 2008, через общедоступную роль можно только видеть два логина через sys.syslogins: самостоятельно и sa. И Вы не будете видеть хэша пароля ни для одного. Так получение хешей для взламывания этого пути не является опцией. И взламывание тех хешей требует метода решения "в лоб" так или иначе, таким образом, это только работает на пароли словаря или слабый.
Мой опыт с аудиторами состоит в том, что они имеют тенденцию делать пух о мелочах как общедоступные полномочия, но пропускать большую вещь. YMMV.
HTH