Подтвердить что ты не робот

Идентификатор пула приложений или олицетворение

(Вопрос аналогичной вены задан до, но как вопрос, так и принятый ответ не содержат детали, которые я ищу)

С целью запуска веб-службы asmx под специальной учетной записью домена, какие сценарии использования и/или профи и недостатки используют пул приложений с идентификатором учетной записи домена против олицетворения?

У нас есть 3 небольших внутренних веб-сервиса, которые работают с относительно низкой нагрузкой, и мы хотели бы переключить их на работу под своими собственными учетными записями домена (с целью интегрированной безопасности с SQL Server и т.д.). Кажется, у меня есть выбор создания выделенных пулов приложений для каждого приложения или наличия единого пула приложений для всех приложений и использования олицетворения в каждом из них.

Я понимаю, что пулы приложений обеспечивают изоляцию рабочего процесса, и есть соображения для производительности при использовании олицетворения, однако те, кто в стороне, что еще диктует правильный вариант?

4b9b3361

ОТВЕТЫ

Ответ 1

Как правило, вы выбираете различную идентификацию для рабочего процесса (или выполняете олицетворение ASP.NET), потому что необходимо получить доступ к локальным/сетевым ресурсам, требующим определенных разрешений. Очевидным недостатком является то, что ваш код приложения может выполняться с большим количеством разрешений, чем это может потребоваться, и тем самым увеличивать уязвимость от вредоносных атак.

У олицетворения ASP.NET будет больше накладных расходов, потому что для каждого запроса необходимо переключить контекст пользователя. Я предлагаю пойти с отдельным подходом к пулу приложений - только недостаток подхода подхода к пулу приложений заключается в том, что у вас есть процесс для каждого из них, и поэтому для каждого процесса будут накладные расходы (с точки зрения ОС). Если ваши приложения меньше и не имеют сильных требований к памяти, это не должно быть проблемой,

Ответ 2

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

Если вы идете по маршруту олицетворения, вам нужно будет учесть проблему с "двумя прыжками". Когда пользователь вызывает веб-службу, использующую олицетворение, веб-служба может обращаться к локальным ресурсам в качестве этого пользователя. Однако, если веб-служба пытается подключиться к нелокальному ресурсу (например, базе данных, работающей на отдельном сервере), результатом будет ошибка проверки подлинности. Причина в том, что NTLM запрещает вашим учетным данным создавать более одного "хопа". Чтобы обойти это, вам нужно будет использовать делегирование Kerberos. Делегирование не сложно настроить, но для этого требуются привилегии администратора домена, что может затруднить работу в некоторых корпоративных средах.

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

Ответ 3

Олицетворение полезно, когда вам нужно общее взаимодействие с другими службами Windows, основанными на безопасности Windows.

Например, серверы Microsoft SharePoint используют олицетворение, поскольку вы можете получить доступ к библиотекам документов SharePoint с веб-браузерами и с помощью стандартного пользовательского интерфейса Windows (подключиться/отключиться от общего сетевого ресурса на основе протокол SMB). Для обеспечения безопасности между этими двумя, в этом случае вы нуждаетесь.

Помимо такого сценария, олицетворение в большинстве случаев не полезно (но может стоить много с точки зрения масштабируемости)

Ответ 4

Преимущества пула приложений:

Вам не обязательно быть программистом. Net, чтобы понять, что происходит.

Аспект безопасности оставляет домен программиста и подпадает под компетенцию инфраструктуры

Легко изменить через IIS с надлежащими проверками безопасности, чтобы имя пользователя было правильным при настройке пула приложений. То есть Это не позволит вам ввести неправильное имя пользователя.

Преимущества олицетворения:

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

Олицетворение:

  • Чтобы изменить пользователя, вам нужно быть знакомым с конфигурацией .Net, а не просто с настройкой веб-сайта.

Не уверен, что я могу думать о многом.

Моя кишка говорит, чтобы идти с разными пулами приложений для каждого из сайтов, но это ваша сторона.