3) ввести «system.webServer/security/authentication/iisClientCertificateMappingAuthentication» в
раскрывающийся список Section;
4) выбрать поле enabled и измените его значение на True;
5) выбрать в таблице свойств запись oneToOneCertificateMappingsEnabled и
измените ее значение на True;
Рисунок 13 – Редактор конфигураций
6) выбрать в таблице свойств запись oneToOneMappings и
нажать Изменить элементы... на
панели Действия;
7) нажать Добавить в списке задач Редактор
коллекций;
8) скопировать строку blob сертификата
и вставьте ее в поле certificate;
9) установите userName и password, с помощью которых будут аутентифицироваться
клиенты;
10) установить значения поля enabled как true;
Рисунок 14 – Редактор коллекций
11) закрыть Редактор коллекций;
12) нажать Применить на панели Действия.
После того, как описанные выше
действия будут сделаны, сервер будет
сконфигурирован для обработки
Аутентификации с помощью клиентских
сертификатов с одной записью сопоставления
сертификатов «один-к-одному» (Рисунок
15).
Рисунок 15 – Аутентификация с помощью
клиентских сертификатов
Шаг 3: Включение аутентификации сертификатов
клиентов для веб-сайта с помощью
SSL
Как только было создано сопоставление
и была включена функция, сайт должен быть
сконфигурирован для использования сертификатов
клиентов.
1) Из пользовательского интерфейса Диспетчер
служб IIS, нужно выбрать веб-сайт SSL, для
которого нужно использовать сертификаты
клиентов;
2) выбрать модуль пользовательского
интерфейса SSL;
3) в блоке Сертификаты клиента: поставить
переключатель Принимать;
4) нажать Применить на панели Действия.
Теперь веб-сайт сконфигурирован
для принятия и аутентификации клиентов
на основе сертификатов клиентов (рисунок
16).
Рисунок 16 – конфигурация сайта
для принятия SSL
1.3 Защита контента в IIS c помощью
ACL файловой системы
Список управления доступов (ACL) –
это список разрешений, связанных
с объектом. Каждая из этих записей
разрешений называется записью управления
доступом (ACE); ACE содержит разрешения, связанные
с определенным объектом для определенного
удостоверения. Например, для объектов
файловой системы можно установить ACL
на файлы/директории из файловой системы
NTFS.
Существует возможность использования
инструментов с графическим пользовательским
интерфейсом (GUI) (такие как My Computer
или Windows Explorer) для установки или редактирования
ACL. Чтобы увидеть графическое представление
ACL для выбранного ресурса, нужно щелкнуть
правой кнопкой мыши на файле или папке
в одном из этих инструментов, выбрать
Свойства и затем перейти на вкладку Безопасность.
Из этого диалогового окна, представленного
на рисунке 17, можно применить или удалить
разрешения группы или пользователя для
системного ресурса, такого как файл или
папка. Также можно использовать утилиту
командной строки Cacl.exe для отображения
или модификации ACL файлов.
Рисунок
17 – Свойства файла, вкладка Безопасность
Наиболее общие разрешения в ACE
считывают, записывают, выполняют и
перечисляют содержимое папок:
- разрешения на чтение/запись.
Разрешения на чтение и запись предоставляют
доступ чтению и записи объекта файловой
системы соответственно;
- разрешение на перечисление
содержимого папки. Разрешение на перечисление
содержимого папки используется для отображения
содержимого папки и необходимо для регистрации
уведомлений об изменении файла в директории;
- разрешение на выполнение.
Разрешение на выполнение используется
для определения того, должна ли операционная
система выполнять определенное приложение
для указанного пользователя. Сюда не
включены сценарии с динамическими приложениями,
такими как PHP (или Microsoft ASP.NET). Код на выполнение
запускается, когда вызываются файлы .php
или .aspx, но с точки зрения операционной
системы это не так. Вместо установки разрешения
на выполнение, следует обратить внимание
на использование разрешений на выполнение
сценариев;
- полный контроль. Разрешение
на полный контроль дает полный доступ
к объекту файловой системы. Следует избегать
использования полного контроля, вместо
него лучше использовать более гранулированные
разрешения на чтение/запись;
- разрешение на выполнение
сценариев IIS. Файлы с динамическим контентом,
такие как .php (или .aspx), для своего функционирования
требуют наличия разрешения для сценариев.
Однако, хотя ACL файловой системы имеют
флаг выполнения, у них ничего нет для
сценариев. Причина этого состоит в том,
что Internet Information Services 7 (IIS 7) обладает специальной
конфигурацией для обозначения того, есть
ли у определенного файла динамическое
содержимое; эта конфигурации хранится
в конфигурации IIS, вне ACL файловой системы.
Если говорить о разрешениях на выполнение
или о сценарии, то фактически это - конфигурация
IIS, а не разрешение файловой системы на
выполнение;
- наследование объекта. Обычно
ACL файловой системы наследуются. В некоторых
случаях родительские директории могут
иметь очень свободные ACL, которые необходимо
переопределять на дочернем уровне, чтобы
закрыть контент должны образом. Вряд
ли это будет проблемой в размещенном
сценарии, так как в корне есть немного
разрешений.
Чтобы защитить контент, можно либо предоставить,
либо запретить разрешения для определенных
удостоверений через ACL. Есть два типа
удостоверений: удостоверения процесса
(с ними запускаются рабочие процессы
IIS) и удостоверения обработчиков запросов
(получаемые после аутентификации процесса).
Рассмотрим их подробнее:
- удостоверение рабочего процесса (WPI).
Рабочий процесс IIS выполняется как WPI,
который можно сконфигурировать через
настройки конфигурации Application Pool в IIS.
IIS 6.0 на Windows Server 2003 и IIS 7 на Windows Server 2008 в
качестве WPI по умолчанию используют удостоверение
«Сетевые службы». Однако, Windows Server 2008 R2
по умолчанию в качестве WPI использует
удостоверение пула приложений. Если приложение
аутентифицируется и олицетворяется,
то удостоверение обработчика запроса
является удостоверением аутентифицированного
пользователя. Если файл Php.ini имеет параметр
fcgi.impersonate со значением «true» (рекомендовано
для IIS), то процессы PHP выполняются как
аутентифицированный пользователь. Важно
знать, что, в случае анонимной аутентификации,
аутентифицированный пользователь являлся
бы сконфигурированным анонимным пользователем;
- IIS_IUSRS. Это встроенная группа удостоверений,
являющаяся контейнером для всех удостоверений
рабочих процессов (WPI) на сервере. IIS автоматически
включает в эту группу все WPI (нет необходимости
добавлять их туда вручную). В IIS 6.0 на Windows
Server 2003 эта группа называется IIS_WPG. Это
всеохватывающая группа, которая содержит
все WPI, и поэтому она является плохим кандидатом
для изоляции контента. Любое приложение,
выполняющееся в любом пуле приложений,
выполнялось бы как удостоверение из этой
группы, так что предоставление этой группе
прав на чтение означает, что все приложения
могут считывать контент;
- IUSR / Удостоверение анонимного
пользователя. Встроенная учетная запись
IUSR по умолчанию используется для обозначения
удостоверения пользователя с использованием
анонимной аутентификации. Удостоверение
анонимного пользователя является настраиваемым
и может быть установлено наряду с этой
встроенной учетной записью. На практике,
необходимо сконфигурировать настраиваемую
учетную запись для учетной записи анонимного
пользователя и никогда не использовать
встроенную учетную запись. Важно, что
в IIS анонимный пользователь – это не то
же самое, что отсутствие аутентифицированного
пользователя. Анонимные запросы скорее
должны рассматриваться как запросы, в
которых аутентифицированный пользователь
является удостоверением анонимного пользователя;
- удостоверение пула приложений.
Это виртуальное удостоверение, связанное
определенным пулом приложений. Всякий
раз, когда пользователь создает пул приложений,
с ним создается виртуальное удостоверение
(идентификатор безопасности или SID); эти
удостоверения вставлены в рабочий процесс
IIS так, чтобы этот рабочий процесс, запущенный
под этим пулом приложений, имел доступ
к контенту с разрешениями, блокированными
для этого виртуального удостоверения.
В Windows Server 2008 Service Pack 2 (SP2) администратор
может создавать свои рабочие процессы
с этими виртуальными удостоверениями.
Это можно сконфигурировать через настройки
конфигурации пула приложений IIS как тип
«Application Pool Identity», и это является типа удостоверения
WPI по умолчанию для Windows Server 2008 R2. (Удостоверение
уникально для пула приложений, создавшего
его, и поэтому оно может использоваться
для более эффективного изолирования
контента пулов приложений на сервере);
- удостоверение аутентифицированного
пользователя. Если приложение использует
какую-либо форму аутентификации (включая
анонимную аутентификацию), тогда речь
идет об удостоверении для аутентифицированного
пользователя. В случае анонимной аутентификации,
это удостоверение было бы настраиваемым
удостоверением анонимного пользователя.
Чтобы понимать, какие удостоверения
применимы на каких стадиях, полезно
знать и понимать основы конвейера выполнения
IIS. Двумя наиболее применяемыми частями
конвейера являются аутентификация и
сопоставление с обработчиком.
- аутентификация. Перед аутентификацией
контекст аутентифицированного пользователя
неизвестен, и все рабочие процессы IIS выполняются
как WPI. Если у есть запрос PHP, который пытается
обратиться к контенту прежде, чем будет
аутентифицирован, то WPI понадобится доступ
к контенту. Этот сценарий возможен при
использовании глобальных правил для
модуля URL Rewrite, который выполняется в глобальной,
предшествующей запросу фазе конвейера
IIS, которая находится перед аутентификацией.
Модуль URL Rewrite может по-разному обрабатывать
правила, в зависимости от того, является
ли вызываемый ресурс файлом или директорией.
Чтобы правило было применено, необходимо
предоставление доступа файловой системой,
а из-за его расположения в конвейере выполнения,
этот запрос доступа выполняется как WPI.
После аутентификации контекст аутентифицированного
пользователя установлен, но олицетворения
с ним не будет до тех пор, пока запрос
не будет сопоставлен с обработчиком;
- сопоставление с обработчиком.
На этой фазе конвейера выполнения запрос
сопоставляется с обработчиком; например,
запрос к *.php сопоставляется с обработчиком
FastGDI. После того, как это произошло, и произошло
олицетворение с пользователем, удостоверение
обработчика становится Аутентифицированным
пользователем и весь доступ к ресурсам
в этой фазе осуществляется через удостоверение
аутентифицированного пользователя.
Использование правильных учетных
записей для предоставления разрешений
зависит от профиля и критических ресурсов
приложения. Основная задача здесь заключается
в том, чтобы определить, какие разрешения
нужно предоставить и нужно аутентифицироваться
или нет.
- Предоставление необходимых
разрешений. Динамический контент, такой
как приложения PHP и ASP.NET, нуждается в разрешении
на использование сценариев IIS и доступе
для чтения. Если нужно запускать исполняемые
файлы, они должны обладать разрешением
IIS на выполнение, а также они должны быть
должным образом сконфигурированы в CGI
Restriction List. Если они не используют загрузку
данными пользователями, то им нужен только
доступ для чтения в файловой системе.
Контент, который может быть загружен
пользователем, должен находиться в отдельной
папке, для которой у пользователя есть
право на запись. Важно не давать этой
папке разрешения IIS на выполнение или
на запуск сценариев, так что пользователи
не могут загрузить или выполнить вредоносный
код.В целом, для корректной работы приложения
WPI должен обладать правом на чтение для
всего контента.
- Приложения, которые требуют
аутентификации. Для приложений, требующих
аутентификации, следует закрыть все ресурсы
групп, содержащих всех аутентифицированных
пользователей. Если есть различные категории
пользователей (администраторы и не-администраторы),
следует создать отдельные группы, и предоставить
для них права доступа. Например, если
у приложения есть администраторская
директория, содержащая сценарии администраторов,
следует предоставить разрешение на чтение
этой директории только группе администраторов.
Если приложение не олицетворено, то удостоверение
обработчика является аутентифицированным
пользователем; в обратном случае – это
WPI. Если в файле Php.ini параметр fcgi.impersonate
установлен в «true», то удостоверение процессов
fcgi является удостоверением аутентифицированного
пользователя; в обратном случае – это
WPI. С помощью этой информации администратор
может определить правильный набор ACL
для контента.
- Приложения, выполняющиеся
анонимно. Важно отметить, что анонимное
выполнение в IIS означает, что удостоверение
пользователя аутентифицировано как удостоверение
анонимного пользователя. В этом случае
следует закрыть ресурсы либо для удостоверения
пула приложений, либо для настраиваемого
анонимного удостоверения, и предоставить
доступ для удостоверения пула приложений
через анонимное удостоверение. Если предоставляется
доступ к контенту группе IIS_IUSRS, у приложений,
выполняющихся в любом пуле приложений,
будет доступ к контенту. Если анонимным
пользователям будет разрешено загружать
файлы, приложение должно гарантировать
проверку типов контента, которые могут
загрузить пользователи, чтобы не нарушить
безопасность сервера.
Есть несколько способов установить
ACL через оболочку, включая инструменты
командной строки, такие как Icacls.exe. Сосредоточимся
на механизме манифестов (XML) инструмента
для веб-развертывания, который может
использоваться для установки ACL. Он используется
при установке приложений через инструмент
для веб-развертывания или через установщик
веб-платформ.
Чтобы предоставить пользователю Pashchenko
разрешения на чтение, выполнение и запись
для директории файловой системы PashApp,
необходимо добавить в файл Manifest.xml следующую
строчку:
<setAcl path=”PashApp” setAclAccess=”ReadAndExecute, Write”
setAclUser=”Pashchenko” />
Чтобы установить ACL на путь PashApp/Upload с
целью разрешить анонимным пользователям
загружать контент, необходимо добавить
в файл Manifest.xml следующую строчку:
<setAcl path=”PashApp/Upload” setAclAccess=”Write” setAclUser=”anonymousAuthenticationUser”
/>
anonymousAuthenticationUser – это специальный маркер,
который будет обращаться к сконфигурированному
удостоверению анонимной аутентификации.
Чтобы предоставить удостоверению
пула приложений доступ на чтение для
папки PashApp\Data, необходимо добавить
в файл Manifest.xml следующую строчку:
<setAcl path=”PashApp/Data” setAclAccess=”Read” />
setAclUser (значение по умолчанию для этого
удостоверения пула приложений) здесь
не используется.
1.4 Использование проверки
подлинности IIS с олицетворением ASP.NET
IIS предоставляет несколько схем
проверки подлинности, которые
можно применять для защиты
веб-приложения. Наиболее распространенные
сценарии включают использование
встроенной проверки подлинности
Windows (NTLM) в корпоративной интрасети для
определения идентификации пользователей
приложения на основе их имени пользователя
в Windows или указание одной анонимной идентификации
для конкретного приложения. Идентификация
Windows, предлагаемая IIS, может затем использоваться
для определения, имеет ли веб-приложение
доступ к защищенным ресурсам Windows, таким
как файл, защищенный с помощью списка
управления доступом (ACL), или к сетевым
ресурсам, таким как файловый сервер или
сервер баз данных. Можно настроить ASP.NET
для использования идентификации Windows,
предоставляемой IIS, включив олицетворение.
По умолчанию ASP.NET настраивается
для использования режима проверки
подлинности Windows, который применяет идентификацию Windows,
предоставляемую IIS, к свойству User текущего объекта HttpContext. Это позволяет определить идентификацию,
предоставляемую IIS, с помощью свойства User (при
использовании анонимной идентификации
имя Name пользователя оставляется пустым), но
не использовать предлагаемую идентификацию
как WindowsIdentity для текущей страницы. Идентификация WindowsIdentity для
приложения используется во время определения,
имеет ли данное приложение доступ к конкретному
файловому или сетевому ресурсу.