Назад | Перейти на главную страницу

IIS 7.5 ApplicationPoolidentity, когда SQL Server находится на другом сервере

Может ли кто-нибудь посоветовать лучшие практики для настройки удостоверения пула приложений для веб-службы в следующем сценарии

IIS7.5

  1. Веб-службе требуется разрешение на чтение и запись в базу данных SQL.
  2. IIS и SQL находятся на разных серверах, но в одном домене

Если ApplicationPoolIdentity используется \ $, добавляется в качестве пользователя SQL, подвергает ли это наши серверы каким-либо конкретным рискам безопасности, в отличие от добавления нового пользователя домена и назначения этого пользователя в качестве идентификатора пула приложений и предоставления пользователю разрешения в базе данных SQL ?

IIS6

Тот же сценарий, но вместо этого используется встроенный пользователь NetworkService в качестве удостоверения пула приложений. Опять же, подвергает ли это наши серверы каким-либо конкретным рискам безопасности, в отличие от добавления нового пользователя домена?

Спасибо

использование удостоверения пула приложений более безопасно: -

1-Ограничивает возможности пользователя только локальным, а не сетевым или доменом, поэтому любой процесс, запущенный этим пользователем, не может запускаться на любом сетевом ресурсе, поскольку это не домен \ имя пользователя. (Более безопасный домен)

2-Разрешить NTFS-разрешение для этой папки приложения, обеспечивая только большую безопасность для веб-приложения (более локальная безопасность)

3-Я не согласен с Райаном: учетная запись пользователя = компьютер \ учетная запись компьютера = группа - это просто аутентифицированный и авторизованный SID => Компьютеры-члены домена также являются участниками Kerberos в AD, что означает, что контроллеры домена имеют связанный хэш пароля учетной записи, который они могут использовать для аутентифицировать компьютер, когда он подключается к сети. Этот пароль связан с объектом учетной записи компьютера

Microsoft сообщает: проблема возникла со временем, когда все больше и больше системных служб Windows начали работать как сетевые службы. Это связано с тем, что службы, работающие как сетевая служба, могут вмешиваться в работу других служб, работающих под тем же идентификатором. Поскольку рабочие процессы IIS по умолчанию запускают сторонний код (классический код ASP, ASP.NET, PHP), пришло время изолировать рабочие процессы IIS от других системных служб Windows и запустить рабочие процессы IIS с уникальными идентификаторами. Операционная система Windows предоставляет функцию, называемую «виртуальные учетные записи», которая позволяет IIS создавать уникальные удостоверения для каждого из своих пулов приложений.

Использование AppPool Identity для удаленного сервера SQL по существу означает, что вы предоставляете учетной записи компьютера AD для доступа веб-сервера к базе данных SQL. Из-за этого все, что работает на веб-сервере в контексте учетной записи компьютера также имеет доступ к SQL серверу. Вы можете сделать намного хуже с точки зрения безопасности, но явно определенная учетная запись домена определенно лучше, поскольку вы можете быть уверены, что единственный код, использующий ее, - это ваш веб-сайт.

Если управление учетной записью на основе домена (и ее требуемым паролем) слишком сложно, а ваш веб-сервер работает на 2008 R2 или Win7, вы можете использовать Управляемая учетная запись службы что в основном дает вам преимущества управляемости AppPool Identity с безопасностью учетной записи домена.

У меня лично еще не было возможности поиграть с управляемыми учетными записями служб. Поэтому я не уверен, есть ли в документации TechNet какие-либо пробелы или оговорки. Но стоит попробовать, если у вас есть время и ваша среда отвечает всем требованиям. Однако они определенно не будут работать с вашим ящиком IIS6.