Удостоверения пула приложений
Независимо от того, работаете ли вы на своем сервере или в облаке, безопасность должна находиться в верхней части списка приоритетов. В этом случае вы будете рады узнать, что в IIS есть функция безопасности, называемая удостоверением пула приложений. Эта функция появилась в Windows Server 2008 и Windows Vista с пакетом обновления 2 (SP2). Удостоверение пула приложений позволяет запускать пул приложений с уникальной учетной записью без необходимости создавать доменные или локальные учетные записи и управлять ими. Имя учетной записи пула приложений соответствует имени пула приложений. На рисунке ниже показан рабочий процесс IIS (W3wp.exe), запущенный в качестве удостоверения DefaultAppPool.
Учетные записи удостоверений пула приложений
Рабочие процессы в IIS 6.0 и IIS 7 по умолчанию выполняются как сетевая служба. Сетевая служба — это встроенное удостоверение Windows. Он не требует пароля и имеет только права пользователя; то есть он является относительно низким уровнем привилегий. Использование в качестве учетной записи с низким уровнем привилегий является хорошей практикой безопасности, так как в этом случае программная ошибка не может быть использована злоумышленником для управления всей системой.
Однако со временем возникла проблема, так как все больше системных служб Windows начали работать как сетевая служба. Это связано с тем, что службы, работающие как сетевая служба, могут подделать другие службы, работающие под тем же удостоверением. Так как рабочие процессы IIS по умолчанию запускают сторонний код (классический ASP, ASP.NET, php-код), пора изолировать рабочие процессы IIS от других системных служб Windows и запускать рабочие процессы IIS с уникальными удостоверениями. Операционная система Windows предоставляет функцию, называемую "виртуальными учетными записями", которая позволяет СЛУЖБАм IIS создавать уникальные удостоверения для каждого пула приложений. Дополнительные сведения о виртуальных учетных записях см. в разделе Пошаговые инструкции по учетным записям служб.
Настройка удостоверений пула приложений IIS
Если вы используете IIS 7.5 в Windows Server 2008 R2 или более поздней версии IIS, вам не нужно ничего делать, чтобы использовать новое удостоверение. Для каждого создаваемого пула приложений свойство Identity нового пула приложений по умолчанию имеет значение ApplicationPoolIdentity . Iis Администратор Process (WAS) создаст виртуальную учетную запись с именем нового пула приложений и запустит рабочие процессы пула приложений под этой учетной записью по умолчанию.
Чтобы использовать эту виртуальную учетную запись при запуске IIS 7.0 в Windows Server 2008, необходимо изменить свойство Identity создаваемого пула приложений на ApplicationPoolIdentity. Вот как это происходит.
Откройте консоль управления IIS (INETMGR. MSC).
Откройте узел Пулы приложений под узлом компьютера. Выберите пул приложений, который нужно изменить для запуска с автоматически созданным удостоверением пула приложений.
Щелкните правой кнопкой мыши пул приложений и выберите Дополнительные параметры.
Выберите элемент списка Удостоверение и нажмите кнопку с многоточием (кнопку с тремя точками).
Появится представленное ниже диалоговое окно.
Нажмите кнопку Встроенная учетная запись, а затем в поле со списком выберите тип удостоверения ApplicationPoolIdentity .
Чтобы выполнить то же действие с помощью командной строки, можно вызвать программу командной строки appcmd следующим образом:
%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity
Защита ресурсов
При создании нового пула приложений процесс управления IIS создает идентификатор безопасности (SID), представляющий имя самого пула приложений. Например, при создании пула приложений с именем MyNewAppPool в системе Безопасность Windows создается идентификатор безопасности с именем MyNewAppPool. С этого момента ресурсы можно защитить с помощью этого удостоверения. Однако удостоверение не является реальной учетной записью пользователя; Он не будет отображаться как пользователь в консоли управления пользователями Windows.
Это можно сделать, выбрав файл в Windows Обозреватель и добавив удостоверение DefaultAppPool в список контроль доступа файла (ACL).
Открытие проводника Windows
Выберите файл или каталог.
Щелкните файл правой кнопкой мыши и выберите Свойства.
Перейдите на вкладку Безопасность.
Нажмите кнопку Изменить , а затем кнопку Добавить .
Нажмите кнопку Расположения и убедитесь, что выбран компьютер.
Введите IIS AppPool\DefaultAppPool в текстовом поле Введите имена объектов для выбора : .
Нажмите кнопку Проверить имена и нажмите кнопку ОК.
При этом выбранный файл или каталог теперь также разрешит доступ к удостоверению DefaultAppPool .
Это можно сделать с помощью командной строки с помощью средства ICACLS. В следующем примере предоставляется полный доступ к удостоверению DefaultAppPool.
ICACLS test.txt /grant "IIS AppPool\DefaultAppPool:F"
Дополнительные сведения см. в разделе ICACLS.
В Windows 7 и Windows Server 2008 R2 и более поздних версиях Windows по умолчанию пулы приложений запускаются в качестве удостоверения пула приложений. Для этого появился новый тип удостоверения с именем AppPoolIdentity. Если выбран тип удостоверения AppPoolIdentity (по умолчанию в Windows 7 и Windows Server 2008 R2 и более поздних версиях), службы IIS будут запускать рабочие процессы в качестве удостоверения пула приложений. При использовании всех остальных типов удостоверений идентификатор безопасности будет внедрен только в маркер доступа процесса. Если идентификатор внедрен, содержимое по-прежнему может быть acLed для ApplicationPoolIdentity, но владелец маркера, вероятно, не уникален. Дополнительные сведения об этой концепции см. в записи блога New in IIS 7 — App Pool Isolation (Изоляция пула приложений ).
Доступ к сети
Использование учетной записи сетевой службы в среде домена дает большое преимущество. Рабочий процесс, выполняемый от имени сетевой службы, обращается к сети в качестве учетной записи компьютера. Учетные записи компьютера создаются при присоединении компьютера к домену. Они выглядят следующим образом:
<domainname>\<machinename>$,
Например:
mydomain\machine1$
Приятно то, что сетевые ресурсы, такие как общие папки или SQL Server базы данных, могут иметь доступ к учетной записи компьютера.
Как насчет удостоверений пула приложений?
Хорошей новостью является то, что удостоверения пула приложений также используют учетную запись компьютера для доступа к сетевым ресурсам. Вносить изменения не нужно.
Проблемы совместимости с удостоверениями пула приложений
Руководство по документации
Самой большой проблемой совместимости с удостоверениями пула приложений, вероятно, являются более ранние руководства, в которых явно рекомендуется использовать ресурсы ACL для сетевой службы, то есть идентификатор defaultAppPool в IIS 6.0 и IIS 7.0. Клиентам придется изменить свои скрипты на ACL для IIS AppPool\DefaultAppPool (или другого имени пула приложений) при запуске в IIS 7.5 или более поздней версии (см. пример выше, как это сделать).
Профиль пользователя
Службы IIS не загружают профиль пользователя Windows, но некоторые приложения могут использовать его в любом случае для хранения временных данных. Sql Express — это пример приложения, которое делает это. Однако необходимо создать профиль пользователя для хранения временных данных в каталоге профиля или в кусте реестра. Профиль пользователя для учетной записи сетевой службы был создан системой и всегда был доступен. Однако при переключении на уникальные удостоверения пула приложений система не создает профиль пользователя. Только стандартные пулы приложений (DefaultAppPool и классический пул приложений .NET) имеют профили пользователей на диске. Профиль пользователя не создается, если администратор создает пул приложений.
Однако при необходимости можно настроить пулы приложений IIS для загрузки профиля пользователя, задав для атрибута LoadUserProfile значение true.
Итоги
Удостоверения пула приложений — это новая мощная функция изоляции, представленная в Windows Server 2008, Windows Vista и более поздних версиях Windows. Это сделает выполнение приложений IIS еще более безопасным и надежным.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по