Аутентификация Windows и Сетевая служба считают как db_owner

Используя СЕТЕВУЮ СЛУЖБУ, поскольку db_owner, вероятно, хорошо для большого количества сред.

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

Определенные риски были бы:

• Одно плохо записанное выполнение приложения под контекстом СЕТЕВОЙ СЛУЖБЫ может предоставить несанкционированный доступ ко всем другим данным, к которым СЕТЕВАЯ СЛУЖБА имеет доступ. Вы снижаете этот риск путем создания отдельных счетов на все приложения.
• db_owner вероятен больше доступа, чем для приложения действительно нужно, что означает более потенциальный для злоупотребления/эксплуатации, если Вы скомпрометированы. Можно уменьшить это вполне немного путем выбора разумных полномочий предоставить. Возьмите его слишком далеко, и у Вас будут убывающая доходность и больше головных болей поддержки, все же.

При вхождении в DB, поскольку сетевая служба (domain\machine$) будет очень трудной (я понятия не имею, но некоторый l33t haxor, вероятно, мог), если Вы не сервис на веб-поле.

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

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

Дополнительный риск в наличии db_owner является DROP TABLE, даже атаками типа DROP DATABASE. Без db_owner это - все еще опасный, например, "ВЫБОР * ОТ usertable, ГДЕ 1=1" нападает.

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

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

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

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

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

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