Как говорится в рекомендациях по SQL Server , « режим проверки подлинности Windows более безопасен, чем проверка подлинности SQL ». И теперь я хочу знать: есть ли способ защитить SQL Server от пользователя с правами администратора Windows?
Как говорится в рекомендациях по SQL Server , « режим проверки подлинности Windows более безопасен, чем проверка подлинности SQL ». И теперь я хочу знать: есть ли способ защитить SQL Server от пользователя с правами администратора Windows?
Ответы:
Нет.
Если пользователь является администратором Windows для ящика, предположим, что он владеет всем на нем (включая SQL Server). С правами администратора Windows тривиально обойти любую целевую защиту, которую вы применяете (например, триггер входа в систему, который идентифицирует их имя пользователя), выдавая себя за кого-то другого (в том числе NT AUTHORITY\SYSTEM
, который де-факто получает права администратора во всех локальных экземплярах SQL Server ). Аудит тоже не сильно поможет, потому что он может легко отключить это, но вы должны иметь его на всякий случай.
Если вы не доверяете кому-то, не давайте им права администратора Windows, точка.
Нет, невозможно полностью предотвратить sysadmin
доступ локальных администраторов к экземпляру SQL Server.
Если экземпляр перезапускается в однопользовательском режиме , SQL Server жестко запрограммирован для предоставления sysadmin
привилегий локальным администраторам , даже если явный вход в систему может быть невозможен. Причина, по которой это существует, в целях восстановления, потому что можно заблокировать себя из экземпляра.
При этом ограничение доступа во время работы экземпляра в многопользовательском режиме (без прерываний обслуживания) не так сложно. Как упоминал Аарон, локальные администраторы могут выдавать себя за другого NT AUTHORITY\SYSTEM
, для которого по умолчанию sysadmin
в SQL Server 2008 создан логин-уровень. Это можно использовать для восстановления sysadmin
доступа во время работы сервера. (Примечание: в SQL Server 2012 этот логин больше не является sysadmin
.) Я не знаю точно, для чего используется этот логин (обновления / исправления / и т. Д., Предположительно), но я думаю, что его можно отключить только во время эти события. Если нет других безличных имен входа, этого должно быть достаточно, чтобы запретить доступ. Опять же, только если экземпляр работает, непрерывно .
По умолчанию в SQL 2008 и 2012 нет доступа по умолчанию для администраторов Windows к SQL Server. Чтобы администратор Windows (то есть тот, кто является администратором домена или локальным администратором) имел доступ, его логин должен быть явно предоставлен доступ или группа, к которой он принадлежит, предоставил доступ вместе с правами в самом SQL Server. При настройке экземпляра требуется указать один логин или группу Active Directory в качестве администратора, но этот логин / группа может быть любым в вашем домене.
В SQL 2005 была BUILTIN\Administrators
группа с правами доступа sysadmin. Эта группа разрешит локальным администраторам доступ системного администратора к SQL Server. Эта группа может быть удалена из SQL Server, и это считается наилучшей практикой.
При этом нет способа предотвратить влияние Windows (локальной или доменной) на сервер, на котором работает SQL Server. Это означает, что администраторы могут по-прежнему влиять на конфигурации служб и уровня ОС, изменять безопасность каталогов и другие задачи уровня ОС. Это, в конце концов, почему они администраторы Windows.
В общем, вы должны доверять своим администраторам, как SQL Server, так и Windows. Хотя администраторы Windows не могут выполнять задачи или получать доступ к данным (по умолчанию) внутри самого SQL Server, они все же контролируют среду, в которой живет ваш SQL Server. Вы должны позаботиться о том, кого вы назначаете на эти роли.