Аутентификация Windows и учетная запись сетевой службы как владелец db_owner

Question

Существует ряд коммерческих продуктов, которые предоставляют вам установщики на основе Windows для настройки вашего приложения и внутренней базы данных SQL Server. Обычно он спрашивает, хотите ли вы подключиться к БД с аутентификацией Windows или SQL Server. В большинстве из них рекомендуется использовать проверку подлинности Windows, а затем настроить свою БД с учетной записью сетевой службы, назначенной роли базы данных db_owner. Я понимаю, что аутентификация Windows более безопасна, потому что вам не нужно хранить учетные данные в web.config и отправлять их по проводам при аутентификации на SQL Server, но это безопасная конфигурация для производственных сред, где учетная запись сетевой службы является db_owner? Какие конкретные риски мы должны знать?

---

Спасибо StingyJack,

Я слышу, что вы говорите, хотя сначала они должны войти в БД как пользователь сетевой службы. Есть ли простой способ сделать это?

Что я действительно пытаюсь выяснить, так это то, существуют ли какие-либо риски, связанные с тем, что учетной записи сетевой службы по умолчанию назначена роль db_owner.

Answer 1

Использование NETWORK SERVICE в качестве db_owner, вероятно, подходит для многих сред.

Если вы хотите обеспечить более высокий уровень безопасности, просто создайте отдельную учетную запись Windows, предоставьте ей минимальный доступ к SQL Server, а затем измените приложение для запуска в контексте этой новой учетной записи.

Конкретные риски будут:

• Одно плохо написанное приложение, запущенное в контексте NETWORK SERVICE, может разрешить несанкционированный доступ ко всем другим данным, к которым имеет доступ NETWORK SERVICE. Вы снижаете этот риск, создавая отдельные учетные записи для всех приложений.
• db_owner, вероятно, имеет больший доступ, чем на самом деле требуется приложению, что означает больше возможностей для злоупотреблений / эксплуатации, если вы подвергаетесь риску. Вы можете немного уменьшить это, выбирая привилегии здравого смысла для предоставления. Займите это слишком далеко, и у вас будет уменьшающаяся отдача и больше головной боли поддержки, однако.

Answer 2

Вход в БД в качестве сетевой службы (домен \ машина $) будет очень трудным (я понятия не имею, но, возможно, какой-нибудь хакзор l33t), если вы не являетесь службой в веб-окне.

Нет пароля, он не интерактивен и имеет очень ограниченные права (кроме «локальной системы»).

Основная проблема - атаки с использованием SQL-инъекций. Это относится к любому соединению, хотя и к серверу базы данных.

Дополнительный риск наличия db_owner - это DROP TABLE, даже атаки типа DROP DATABASE. Без db_owner это все еще опасно, например, "SELECT * FROM usertable WHERE 1 = 1" атаки.

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

Возможно, вы сможете уменьшить права после установки.

Answer 3

Да, приложение (и любой его пользователь) может потенциально выполнить все, что dbo может выполнить с базой данных. DROP TABLE, ВЫБРАТЬ * ИЗ ПАРОЛЕЙ и т. Д.

Если вы настроили превентивные меры против SQL-инъекций и написали ваше приложение с соответствующим уровнем безопасности приложения, то это с использованием Windows Auth с dbo, вероятно, будет в порядке.

Если вы работаете с очень конфиденциальными данными, не доверяете приложению (пока) или хотите быть максимально безопасными, то вам придется реализовать защиту на уровне базы данных.

Например, пользователь x имеет доступ к представлениям таблиц a и b и представлению c, а пользователь y имеет доступ только к представлению c. Ваше приложение должно будет подключиться как соответствующий пользователь для доступа к нужному объекту.