Один из плохо документированных, но довольно важных фактов из жизни при работе с приложениями .NET заключается в том, что часто используется аутентификация Windows для взаимодействия с базами данных Sql Server. К сожалению, какая именно личность используется по умолчанию, в лучшем случае плохо документирована. Итак, я сделал вам эту удобную таблицу для справки:
| Версия для Windows | Веб сервер | Контекст Windows по умолчанию |
|---|---|---|
| Любые | Кассини (встроенный веб-сервер VS.NET 2005) | Интерактивный пользовательский контекст * |
| 2000 (Pro или сервер) | IIS | ASPNET |
| XP | IIS | ASPNET |
| 2003 Server | IIS | NT AUTHORITYNETWORK SERVICE ** |
Примечания:
*: Это означает вас, контекст разработчика. Что обычно означает член группы «Администратор», что означает, что ваше приложение работает с полными разрешениями базы данных. Это означает, что ситуация тестирования плохая, потому что веб-приложение никогда не должно иметь таких привилегий.
**: это идентификатор по умолчанию для пула приложений по умолчанию в IIS6. В любом случае, веб-приложение принимает контекст пула приложений хостинга.
Что касается успешной передачи защиты от разработки к производству, самый большой совет, который я могу дать, — это создание ролей базы данных в вашей базе данных и назначение разрешений этим ролям. Основная проблема здесь заключается в том, что перенос пользователей Sql Server может быть затруднен, в то время как роль базы данных целиком содержится в базе данных и намного легче переносится. И вы всегда можете создать нового пользователя с соответствующими ролями при переходе в производство. Действовать гораздо проще, чем вручную назначать соответствующие разрешения новому пользователю. И гораздо безопаснее, чем просто предоставить обычному пользователю общие разрешения db_owner для веб-пользователя.
Наслаждайтесь и приручайте их Sql Dbs.