РБ прав на риск

Question

Я советую другу, который управляет коробкой SQL 2k5, у которой есть несколько пользователей, которые имеют доступ dbo к нескольким базам данных. Проблема:

1. Эти пользователи не меняли свои пароли в течение нескольких месяцев,
2. Эти пользователи помещают свои идентификаторы в приложения, а приложения запускаются как DBO.

Итак, помимо очевидных прав dbo на добавление / обновление / удаление таблиц и процедур, какие опасности я могу привести для злонамеренного пользователя, имеющего dbo для базы данных SQL 2005?

Я хотел бы предоставить конкретные сценарии, которые наносят ущерб базе данных и другим пользователям. Может ли dbo изменить распределение файлов на сервере? Может ли DBO влиять на другие ресурсы, не связанные напрямую с этой базой данных?

---

Как пояснение, это был SQL Server 2005, и по умолчанию xp_cmdShell не был авторизован для пользователей DBO. Мне все еще интересно, есть ли риски помимо очевидного CRUD. Что можно сделать с DBO?

Answer 1

Я понимаю, что это 5-летнее сообщение, но на него никогда не отвечали правильно, и была опубликована действительно плохая информация.

Сначала давайте посмотрим, что Books Online говорит о роли "DBO" (priv). Акцент мой.

Члены предопределенной роли базы данных db_owner могут выполнять все операции по настройке и обслуживанию базы данных .

Подводя итог, это означает, что человек с привилегиями "DBO" может делать практически все, что он хочет, с любой базой данных, где у него есть эта привилегия. С 2005 года это также означает, что они могут удалить базу данных.

Также обратите внимание, что в нем не говорится о возможности проконтролировать сервер. Насколько я помню, для выполнения xp_CmdShell вам понадобились привилегии "SA" или (совсем недавно) "Control Server". DBO не поставляется с priv, поэтому он не может запустить xp_CmdShell или множество других вещей, которые начинаются с "xp_" или даже с "sp _".

Переключение передач и, как кажется, ФП уже немного осведомлен, привилегии DBO считаются "привилегированными привилегиями". Я бы посоветовал вам никогда не предоставлять привилегию DBO приложению (или другому внешнему интерфейсу), и я предоставляю его только людям, которые должны быть ответственными администраторами базы данных. Этих людей нужно выбирать так же мудро, как и тех, кого вы бы выбрали в качестве администраторов баз данных.

Чтобы ответить на другие вопросы, касающиеся CRUD ... в большинстве случаев, когда CRUD выполняется ORM, наиболее необходимыми привилегированными привилегиями являются db_DataReader и db_DataWriter. Если честно, я предпочитаю даже не позволять логинам иметь эти привилегии. Я знаю, что каждый разработчик внешнего интерфейса будет кричать на меня, но правда в том, что даже CRUD должен выполняться хранимой процедурой, чтобы не дать злоумышленнику получить доступ к db_DataWriter, который позволяет кому-либо удалять из таблиц. Насколько я понимаю, приложения (и другие внешние интерфейсы) должны иметь только неизмененные привилегии PUBLIC и привилегии для выполнения определенных хранимых процедур ... точка.

Answer 2

да. dbo имеет право делать с базой все, что захочет. даже запустить xp_cmdshell. и как только вы сможете запустить xp_cmdshell, вы можете делать практически все в системе. это все возможно, если у dbo есть права sysadmin, которые по умолчанию у него есть.