Учетная запись проверки подлинности Windows и сетевой службы как db_owner
Существует ряд коммерческих продуктов, которые предоставляют установщики на базе Windows для настройки вашего приложения и серверной базы данных SQL Server. Обычно он спрашивает, хотите ли вы подключиться к БД с аутентификацией Windows или SQL Server. Большинство из них рекомендуют использовать Windows Auth, а затем настроить вашу БД с учетной записью сетевой службы, назначенной роли базы данных db_owner. Я понимаю, что проверка подлинности Windows более безопасна, потому что вам не нужно хранить учетные данные в web.config и отправлять их по сети при проверке подлинности на SQL Server, но это безопасная конфигурация для производственных сред, где учетная запись сетевой службы является db_owner? Есть ли какие-то особые риски, о которых нам следует знать?
Спасибо StingyJack,
Я слышу, что вы говорите, им сначала придется войти в БД как пользователь сетевой службы. Есть простой способ сделать это?
На самом деле я пытаюсь выяснить, существуют ли какие-либо неотъемлемые риски, связанные с тем фактом, что именно учетной записи сетевой службы дефолт назначена роль db_owner.
Ответы 3
Да, приложение (и любой его пользователь) потенциально может выполнять все, что dbo может выполнить с базой данных. УДАЛИТЬ ТАБЛИЦУ, ВЫБРАТЬ * ИЗ ПАРОЛЕЙ и т. д.
Если вы настроили превентивные меры против SQL-инъекции и написали свое приложение с соответствующей безопасностью прикладного уровня, тогда это с использованием Windows Auth с dbo, вероятно, будет в порядке.
Если вы работаете с очень конфиденциальными данными, не доверяете приложению (пока) или хотите быть максимально безопасными, вам придется реализовать безопасность на уровне базы данных.
Например, пользователь x имеет доступ к представлениям таблиц a и b и представлению c, а пользователь y имеет доступ только к представлению c. Ваше приложение должно будет подключиться как соответствующий пользователь, чтобы получить доступ к нужному объекту.
Вход в БД в качестве сетевой службы (домен \ машина $) будет очень трудным (я понятия не имею, но некоторые l33t haxor, вероятно, могли бы), если вы не являетесь службой в веб-ящике.
Нет пароля, он не интерактивен и имеет очень ограниченные права (кроме «локальной системы»).
Основная проблема - это атаки с использованием SQL-инъекций. Они применимы к любому подключению к серверу db.
Дополнительный риск наличия db_owner - это DROP TABLE, даже атаки типа DROP DATABASE. Без db_owner это все еще опасно, например, атаки «SELECT * FROM usertable WHERE 1 = 1».
К сожалению, у вас нет выбора с коммерческими или сторонними приложениями для использования сохраненных процедур, минимального разрешения и т. д.
Однако вы можете уменьшить права после установки.
Использование NETWORK SERVICE в качестве db_owner, вероятно, подходит для многих сред.
Если вы хотите иметь более высокий уровень безопасности, просто создайте отдельную учетную запись Windows, предоставьте ей минимальный доступ, необходимый в SQL Server, а затем измените приложение для запуска в контексте этой новой учетной записи.
Конкретные риски будут следующими:
- Одно плохо написанное приложение, работающее в контексте СЕТЕВОЙ СЛУЖБЫ, может разрешить несанкционированный доступ ко всем другим данным, к которым СЕТЕВАЯ СЛУЖБА имеет доступ. Вы уменьшаете этот риск, создавая отдельные учетные записи для всех приложений.
- db_owner, вероятно, имеет больший доступ, чем действительно нужно приложению, что означает больше возможностей для злоупотреблений / эксплуатации, если вы скомпрометированы. Вы можете немного уменьшить это, выбрав привилегии здравого смысла для предоставления. Однако если вы зайдете слишком далеко, то получите уменьшающуюся отдачу и больше головных болей, связанных с поддержкой.