• Patterns And Practices Index
• .NET Architecture Center
• Application Architecture for .NET: Designing Applications and Services

Автор: Джеф Керчер (Jeff Kercher)
Менеджер программы: Эдвард Джезирски (Edward Jezierski)
Microsoft Corporation

Август 2001 г.

Аннотация: В статье показывается, насколько важно учитывать вопросы безопасности при разработке серверных приложений. Как Microsoft Internet Information Services (IIS), так и ASP.NET предоставляют модели защиты, позволяющие при необходимости аутентифицировать пользователей и получать правильный контекст защиты в приложении.

Содержание

• Введение
• Рекомендации по защите
• Взаимосвязь между IIS и ASP.NET
• Способы аутентификации
• Защита в Web-сервисах
• Защита по правам доступа кода
• Защита на уровне каналов
• Дополнительные сведения
• Приложение A

Введение

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

Рекомендации по защите

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

• Задачи защиты. Вы должны понять, что защищаете, и убедитесь, можете ли вы описать это на бумаге.
• Риски. Оцените уязвимые места приложения. Кроме того, проанализируйте значимость потенциальных угроз по отношению к бизнесу.
• Аутентификация. Это прием удостоверений (credentials) от пользователя и их проверка выбранными средствами. Пользователь (или приложение/компьютер) рассматривается как участник безопасности (security principal). Клиент должен предоставить удостоверения, позволяющие серверу проверить идентификацию участника. Определив идентификацию, приложение может авторизовать участника для доступа к ресурсам системы. (Критерии выбора механизма аутентификации рассматриваются в следующем разделе этого документа.)
• Авторизация. Это процесс, в ходе которого выясняется, разрешен ли доступ к конкретному ресурсу по подтвержденной идентификации.
• Защита передачи данных. Шифрование данных гарантирует невозможность их прочтения или подмены при передаче по сети. Вы должны принять решение о требуемом уровне защиты данных при передаче.
• Олицетворение (impersonation). Механизм, позволяющий серверному процессу работать с удостоверениями защиты клиента. В этом случае все выполняемые сервером операции выполняются с использованием удостоверений клиента. Олицетворение не позволяет серверу обращаться к удаленным ресурсам от имени клиента. Подобный процесс требует делегирования.
• Делегирование. Как и олицетворение, делегирование обеспечивает работу серверного процесса с использованием удостоверений защиты клиента. Однако делегирование - более мощный механизм, оно дает возможность серверному процессу обращаться к другим компьютерам, выдавая себя за клиента.
• Защита средствами операционной системы. В этой части следует создать соответствующие списки управления доступом (Access Control Lists, ACL) и продумать сетевую защиту, чтобы предотвратить несанционированный доступ к защищенным ресурсам. Назначьте подходящие ACL соответствующим ресурсам, разрешая доступ только выбранным участникам безопасности.
• Физическая защита. Размещение серверного компьютера в защищенном помещении. Не упускайте из виду этот базисный принцип.
• Защита по правам доступа кода (code access security). Уровень доверия к коду зависит от его источника и других характеристик. Вы должны знать, как создать собственные разрешения на доступ.

Взаимосвязь IIS и ASP.NET

Проектируя приложение, вы должны понимать связь между аутентификацией Internet Information Services (IIS) и архитектурой защиты Microsoft^® ASP.NET. Тогда вы сможете правильно аутентифицировать пользователей и получать корректный контекст защиты в приложении. Обратите внимание, что параметры защиты ASP.NET-приложения и IIS никак не связаны между собой и могут использоваться как независимо друг от друга, так и в сочетании.

IIS хранит параметры конфигурации, связанные с защитой, в метабазе. В свою очередь ASP.NET хранит параметры защиты (как и все остальные) в конфигурационных XML-файлах. Хотя обычно это облегчает развертывание приложений с точки зрения безопасности, выбранная в приложении модель защиты потребует правильной настройки как метабазы IIS, так и вашего ASP.NET-приложения (через его конфигурационный файл Web.config).

Взаимосвязь между IIS и ASP.NET показана на рис. 1.

{Рисунок:
Web Clients - Web-клиенты
IP address and domain permitted? - IP-адрес и домен разрешены?
Yes - Да
No - Нет
Access Denied - Доступ запрещен
User Authenticated? - Пользователь аутентифицирован?
Launch ASP.NET Application - Запустить ASP.NET-приложение
Is ASP.NET impersonation enabled? - Включен ли механизм олицетворения в ASP.NET?
ASP.NET Application runs with local machine identity - ASP.NET-приложение выполняется под идентификацией локального компьютера
ASP.NET Application assumes client identity - ASP.NET-приложение предполагает использование идентификации клиента
Access Check OK? (eg NTFS) - Успешна ли проверка доступа? (например NTFS)
Access Granted - Доступ разрешен
}

Рис. 1. Взаимосвязь средств защиты IIS и ASP.NET

Провайдеры аутентификации ASP.NET и защита IIS

В ASP.NET аутентификация осуществляется на основе провайдеров аутентификации, которые представляют собой модули кода, проверяющие удостоверения и реализующие прочие функции защиты, например генерацию cookie. ASP.NET поддерживает следующие провайдеры аутентификации.

• Forms Authentication (аутентификация на основе форм). При применении этого провайдера все неаутентифицированные запросы перенаправляются на указанную HTML-форму путем клиентской переадресации. После этого пользователь может ввести свои учетные данные (удостоверения защиты) и отправить форму обратно на сервер. Если приложение аутентифицирует запрос (логика проверки специфична для конкретного приложения), ASP.NET генерирует cookie, содержащий удостоверения или ключ для повторного получения идентификации клиента. Последующие запросы содержат этот cookie в своем заголовке, поэтому никакая аутентификация больше не требуется.
• Passport Authentication (аутентификация через Passport). Это централизованная служба аутентификации, предоставляемая Microsoft и предлагающая участвующим сайтам механизмы единой Michael Howard регистрации и подписки на сервисы. ASP.NET в сочетании с Microsoft Passport SDK предлагает пользователям Passport функциональность, аналогичную Forms Authentication.
• Windows Authentication (аутентификация через Windows). Этот провайдер пользуется возможностями IIS. После того как IIS проводит аутентификацию, ASP.NET использует маркер аутентифицированной идентификации для авторизации доступа.

// Файл web.config
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>

Помимо аутентификации, ASP.NET предоставляет механизм олицетворения, позволяющий настроить маркер защиты (security token) для потока приложения. Чтобы получить корректный маркер, нужно соответственно настроить аутентификацию IIS, провайдеры аутентификации ASP.NET и параметры олицетворения в ASP.NET. На рис. 2 показаны наиболее распространенные сочетания аутентификации IIS и провайдеров ASP.NET.

Рис. 2. Взаимосвязь настроек защиты ASP.NET и IIS

{Рисунок:
If you are this ASP.NET authentication provider… - Если вы применяете этот провайдер аутентификации ASP.NET…
You will likely use the following IIS authentication method - Вы скорее всего воспользуетесь следующим способом IIS-аутентификации
Forms - Формы
Basic - Базовый
Integrated (NTLM/Kerb) - Интегрированный (NTLM/Kerb)
Digest - Хэш
Passport - Passport
Certificate Mapping - Сопоставление сертификатов
None (Custom Authentication) - Нет (нестандартная аутентификация)
Anonymous - Анонимный
}

Аутентификация с помощью учетных записей Windows

Если вы планируете аутентифицировать пользователей по учетным записям, хранящимся на контроллере домена Microsoft Windows NT или в службе каталогов Microsoft Windows^® 2000 Active Directory™, то должны использовать аутентификацию IIS в сочетании с провайдером Windows Authentication для ASP.NET, как показано на рис. 2. Тогда вам не придется писать никакого специфического кода для аутентификации. Когда аутентификация осуществляется этим способом, ASP.NET создает объект Windows Principal и связывает его с контекстом приложения для аутентифицированного пользователя. В результате ASP.NET-поток выполняется от имени аутентифицированного пользователя и может получить членство в его группе.

В некоторых случаях нужно обходить аутентификацию IIS и реализовать собственный способ. В ASP.NET это допустимо. Например, вы можете создать свой ISAPI-фильтр, проверяющий удостоверения пользователя в Active Directory, и самостоятельно создавать объект Windows Principal. Существуют и другие способы, но тогда придется писать больше кода, чем при прямом использовании .NET-провайдера.

Аутентификация без применения учетных записей Windows

Если вы планируете аутентифицировать пользователей на уровне приложения и при этом у пользователей нет учетных записей в Windows, то скорее всего вы настроите IIS на анонимную аутентификацию. В этом случае рассмотрите следующие аутентификационные модули .NET.

• Без аутентификации. Применяйте, когда аутентификация пользователей вообще не проводится или когда она осуществляется специфическим модулем вашей разработки.
• Формы. Применяйте, если хотите предоставить пользователям страницу для входа (logon page).
• Passport. Применяйте при использовании служб Passport.

Олицетворение и делегирование

За счет олицетворения ASP.NET-приложения могут при необходимости выполняться под идентификацией клиента, от имени которого они действуют. Обычно олицетворение реализуется для управления доступом к ресурсам. Тщательно взвесьте, нужно ли оно в вашем случае, так как олицетворение расходуются дополнительные ресурсы сервера. Делегирование - более мощная форма олицетворения, позволяющая серверному процессу обращаться к удаленным ресурсам от имени клиента.

При включенном олицетворении ASP.NET получает соответствующий маркер (token) от IIS. ASP.NET-механизм олицетворения по сравнению с аналогичным механизмом в традиционном ASP позволяет добиться в Web-приложениях более тонкого контроля за олицетворением. Для этого в файле Web.config приложения поддерживается специальный параметр.

Этот параметр может принимать три значения.

• Олицетворение разрешено. ASP.NET подменяет маркер, полученный от IIS и выданный либо аутентифицированному пользователю, либо анонимной учетной записи Интернета.

  <identity impersonate="true"/>
  

• Олицетворение разрешено и задана конкретная идентификация. ASP.NET подменяет маркер, сгенерированный с использованием заданной идентификации. В этом случае маркер клиента не используется, даже если он есть.

  <identity impersonate="true" name="domain\user" password="pwd"/>
  

• Олицетворение запрещено. Это значение предлагается по умолчанию для обратной совместимости с ASP. В данном случае ASP.NET-поток выполняется, используя маркер рабочего процесса приложения, который по умолчанию относится к системной учетной записи IIS независимо от применяемой вами комбинации средств аутентификации IIS и ASP.NET.

  <identity impersonate="false"/>
  

Когда приложение размещено на сетевом UNC-ресурсе, ASP.NET всегда подменяет (олицетворяет) UNC-маркер IIS для доступа к этому ресурсу, если только не используется специфически сконфигурированная учетная запись. В последнем случае ASP.NET использует ее вместо UNC-маркера IIS.

В табл. 1 показан маркер потока, используемый ASP.NET для выполнения запроса в зависимости от трех вариантов настройки Web.config. Заметьте, что учетная запись IUSR_SERVER соответствует учетной записи, настроенной для анонимного доступа по текущему URL, и что такая запись не обязательно должна быть типа IUSR_. Учетная запись процесса - это учетная запись, под которой выполняется рабочий процесс приложения (по умолчанию - System Account).

Табл. 1. Маркер ASP-потока для конфигураций ASP и IIS

Идентификации приложения

Советуем запускать рабочий процесс приложения ASP.NET (aspnet_wp.exe) под специальной учетной записью с меньшими привилегиями, чем у учетной записи System по умолчанию. Это вызвано двумя основными причинами. Во-первых, при взломе защиты злоумышленник не получит доступа с правами администратора. Во-вторых, это позволяет провайдерам программных сервисов (Application Service Providers, ASP) запускать приложения под более "слабыми" учетными записями, благодаря чему эти приложения не смогут нарушить целостность сервера или выполнять действия, требующие административных привилегий.

Чтобы запустить рабочий процесс ASP под определенной учетной записью, добавьте элемент <processModel> в корневой конфигурационный файл (machine.config), находящийся в каталоге \WINNT\Microsoft.NET\Framework\Version\Config, как показано ниже:

<system.web>
  <processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

Кроме того, вы можете присвоить атрибуту username одно из двух специальных значений - SYSTEM или MACHINE. В обоих случаях для атрибута password следует указать AutoGenerate, так как конкретные удостоверения не требуются. Значение SYSTEM (задается по умолчанию) запускает рабочий процесс под учетной записью System, а MACHINE - под особой учетной записью с префиксом ASPNET. Эта учетная запись аналогична учетной записи IWAM_MACHINENAME, используемой IIS для запуска экземпляров dllhost.exe при выполнении обычных ASP-приложений. Учетная запись ASPNET создается при установке .NET.

Если вы используете нестандартную учетную запись, то должны указать для нее права доступа к следующим каталогам.

• Доступ для чтения/записи к каталогу %installroot%\ASP.NET Temporary Files. В его подкаталогах размещаются динамически компилируемые файлы.
• Доступ для чтения/записи к каталогу %temp%. Необходим компиляторам при динамической компиляции.
• Доступ для чтения к каталогу приложения.
• Доступ для чтения к иерархии каталога %installroot%, так как в ней хранятся системные сборки.

Обратите внимание, что ACE, требуемые для учетной записи ASPNET, создаются в процессе установки.

При использовании специально настроенной учетной записи процесса помните об ограничениях, налагаемых в этом случае на применение олицетворения. Хотя подменять идентификацию клиента по-прежнему можно, задействовать расширенную форму олицетворения, при которой в файле приложения Web.config определяется особая учетная запись олицетворения, нельзя. Дело в том, что при таком варианте рабочему процессу нужна привилегия SE_TCB_NAME (разрешающая ему действовать как часть операционной системы), которой обычно нет у процессов с более "слабыми" идентификациями. Олицетворение для индивидуальных запросов по-прежнему действует, так как IIS создает сеанс входа (logon session) и передает маркер олицетворения (impersonation token) непосредственно рабочему процессу. Заметьте, что это ограничение касается только Windows 2000 и Windows NT 4. Расширения, введенные в Microsoft Windows XP, позволяют создавать определенные сеансы входа без этой привилегии.

Дополнительную информацию см. в следующих главах из руководства .NET Framework Developers Guide:

• "How ASP.NET Security Works";
• "ASP.NET Authentication";
• "ASP.NET Configuration Concepts";
• "Using IIS Authentication With ASP.NET Impersonation".

Дополнительные сведения об аутентификации в IIS 5.0 см. в статье Internet Information Services 5.0 Authentication Methods.

Способы аутентификации

Существует множество способов аутентификации в Web-приложениях .NET. Например, можно задействовать один из механизмов, поддерживаемых IIS, либо выполнять аутентификацию в коде приложения. При выборе способа аутентификации следует принять во внимание некоторые или все факторы из перечисленных:

• операционные системы на сервере и клиенте;
• тип браузера клиента;
• число пользователей, а также тип и местонахождение базы данных с именами и паролями;
• условия развертывания (где работает приложение - в Интернете или интрасети, находится ли оно за брандмауэром и т. д.);
• тип приложения (например, интерактивный Web-сайт или не интерактивный Web-сервис);
• степень конфиденциальности защищаемых данных;
• факторы, влияющие на производительность и масштабируемость;
• требования к авторизации приложения; например, приложение может быть доступно всем пользователям или же какие-то его части должны быть доступны зарегистрированным пользователям, а остальные - только администраторам.

Выбор способа аутентификации

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

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

Что представляют собой точки выбора на схеме

1. Должны ли пользователи регистрироваться? Требуется ли имя пользователя и пароль для доступа к сайту или сервису?
2. Нужна ли персонализация? Предоставляет ли сайт персонализированный контент без регистрации пользователей?
3. Учетные записи пользователей? Хранятся ли они в домене Windows NT, Active Directory или где-то в другом месте, например в реляционной базе данных, альтернативной службе каталогов LDAP (Lightweight Directory Access Protocol) или в XML-файле?
4. Единый (single sign-on) или автоматический вход (seamless logon)? Вы хотите, чтобы пользователи регистрировались на соответствующей странице, или же вам нужна автоматическая аутентификация? Автоматическая аутентификация может потребоваться, например, для автоматического выполнения B2B-транзакции (Business-to-Business).
5. Нужен ли защищенный вход? Следует ли максимально затруднить злоумышленникам перехват имен и паролей пользователей при их передаче по сети? Обычно решение принимается в зависимости от степени конфиденциальности данных, размещенных на сайте.
6. Будет ли приложение работать в Интернете? Предназначено ли приложение для работы за брандмауэром (firewall) (тогда пользователи не аутентифицируются в домене) или для работы в интрасети (в таком случае пользователи возможно уже аутентифицированы в домене)?
7. Нужно ли делегировать контекст защиты? Надо ли выполнять бизнес-компоненты под идентификацией вызвавшей их программы? Если да, потребуется олицетворение. Более того, если вам нужен доступ к таким системным ресурсам, как очереди сообщений, базы данных или файловые системы на удаленных компьютерах, вам понадобится олицетворение на уровне делегата (delegate-level impersonation).
8. Работают ли серверы и клиенты только под управлением Windows 2000? Состоит ли ваша среда только из компьютеров под управлением Windows 2000, или же в ней есть клиенты, работающие под управлением других операционных систем, например Windows 9x или Windows NT 4.0?

Анонимная аутентификация

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

Типичные сценарии применения

Анонимная аутентификация подходит, если:

• вам не нужно знать имя и/или пароль пользователя для входа или компонентов бизнес-логики;
• информация считается общедоступной.

Анонимная аутентификация не годится, если:

• доступ пользователей ограничен по имени и паролю.

Прочие соображения

Выбирая анонимную аутентификацию, примите во внимание следующие соображения.

Сайты, содержащие только персонализированный контент

Если вы разрабатываете сайт, содержащий только персонализированный контент, анонимная аутентификация может стать неплохим выбором. Пример - новостной сайт, предлагающий местные новости в зависимости от места проживания пользователя, но при этом не требующий явной регистрации. Персонализация может выполняться на основе cookie отдельно от аутентификации. Подробнее о cookie см. раздел Cookie далее в этом документе.

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

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

• встроенной анонимной учетной записью Интернета - IUSR_MACHINENAME;
• учетной записью, настроенной в IIS для анонимного пользователя;
• системной учетной записью IIS.

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

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

Производительность

Анонимный Web-сайт, не использующий олицетворение ASP.NET, обладает самой высокой производительностью, но является наименее защищенным.

Реализация

Чтобы реализовать анонимную аутентификацию, настройте на нее IIS и сконфигурируйте соответствующую анонимную учетную запись. Настройте ASP.NET через файл Web.config на отключение аутентификации.

// Файл web.config
<system.web>
   <authentication mode="None" />
</system.web>

Базовая аутентификация

IIS, настроенный на базовую аутентификацию, требует от браузера передачи удостоверений пользователя по HTTP. При этом пароли и имена пользователей кодируются по основанию Base64. Однако пароль считается небезопасным, так как раскодировать его сравнительно нетрудно. Браузер выводит диалоговое окно для входа, а затем повторно посылает исходный анонимный запрос с указанными удостоверениями, в том числе с именем и паролем пользователя. Всплывающее диалоговое окно входа может как устроить вас, так и не устроить - все зависит от требований вашей реализации UI. Большинство браузеров поддерживает базовую аутентификацию.

Типичные сценарии применения

Подумайте о базовой аутентификации, если:

• у ваших пользователей имеются учетные записи в домене Windows NT или службе каталогов Active Directory;
• нужна поддержка браузеров нескольких типов, в том числе Netscape Navigator и всех версий Internet Explorer (включая версии для платформ Pocket PC и Windows CE);
• требуется поддержка аутентификации через Интернет;
• в коде приложения необходим доступ к паролям в незашифрованном виде;
• нужна поддержка делегирования.

  Базовая аутентификация не годится, когда:

• нужен защищенный вход и при этом не используется защищенный канал вроде Secure Sockets Layer (SSL);
• информация о ваших пользователях хранится в нестандартной базе данных и у них нет учетных записей в Windows;
• в качестве входной страницы применяется адаптируемая под разных пользователей форма.

Прочие соображения

Выбирая базовую аутентификацию, примите во внимание следующие соображения.

Делегирование при базовой аутентификации

При использовании базовой аутентификации можно делегировать полномочия от одного компьютера другому (но не далее). Делегирование происходит, так как сервер IIS локально регистрирует пользователя, вызывая Win32-функцию LogonUser. Поскольку IIS известен пароль пользователя, он может отвечать на вызовы от удаленных компьютеров, что позволяет Web-серверу действовать от лица клиента. Если требуется делегировать контекст защиты другим компьютерам (расположенным за маршрутизаторами), придется локально регистрировать пользователя на всех компьютерах в цепочке вызова. При базовой аутентификации это возможно, потому что у вас есть доступ к имени пользователя и незашифрованному паролю, которые можно передать другим приложениям, работающим, например, на базе ISAPI или CGI.

Защита при базовой аутентификации

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

Базовую аутентификацию можно сделать более безопасной, сочетая ее с SSL. Это предотвратит расшифровку паролей. Сегодня во многих Интернет-приложениях базовая аутентификация сочетается с SSL.

Реализация

Для реализации базовой аутентификации настройте на нее IIS и убедитесь, что у пользователей есть привилегия локальной регистрации на Web-сервере. Если вам нужно запускать приложение ASP.NET от имени аутентифицированного базовым способом пользователя, измените конфигурацию файла Web.config:

// Файл web.config
<system.web>
   <authentication mode="Windows" />
</system.web>

Аутентификация с хэшированием

Аутентификация с хэшированием (digest authentication) появилась только в Windows 2000 и IIS 5.0. В этом случае пароль пользователя шифруется и предоставляется механизм, предотвращающий некоторые распространенные типы атак на серверы, например атаки с повторением пакетов (replay attacks). В отличие от базовой аутентификации учетные данные не посылаются по сети открытым текстом. Вместо этого применяется механизм хэширования MD5, разработанный RSA (см. "The MD5 Message-Digest Algorithm" по ссылке http://www.ietf.org/rfc/rfc1321.txt). Хотя это вполне жизнеспособный вариант для Интернет-приложений, его широкое применение ограничено требованиями к серверу и клиенту. В отличие от базовой аутентификации и по аналогии с NTLM и Kerberos при аутентификации с хэшированием IIS не регистрирует пользователя локально на Web-сервере, что исключает возможность делегирования.

Типичные сценарии применения

Подумайте об аутентификации с хэшированием, если:

• ваш Web-сервер работает под управлением Windows 2000 и пользователей есть учетные записи Windows, которые хранятся в Active Directory;
• все клиенты используют либо .NET, либо Internet Explorer 5.x;
• вам требуется более стойкое шифрование пароля, чем это возможно при базовой аутентификации;
• нужна поддержка аутентификации через Интернет.

Базовая аутентификация не годится, если:

• клиенты не используют ни .NET, ни Internet Explorer 5.0 (или выше);
• у пользователей нет учетных записей Windows, хранящихся в Active Directory;
• требуется делегирование.

Прочие соображения

Выбирая аутентификацию с хэшированием, примите во внимание следующие соображения.

Более безопасная аутентификация с хэшированием

Цель аутентификации с хэшированием - предоставить механизмы входа, более защищенные по сравнению с базовой аутентификацией. Однако, она не столь безопасна, как базовая аутентификация в сочетании с SSL, NTLM, Kerberos или аутентификацией с сертификатами.

Безопасное решение - комбинировать аутентификацию с хэшированием и SSL, однако применение такого способа в настоящее время ограничено требованиями к развертыванию.

Требования к платформе, налагаемые аутентификацией с хэшированием

Аутентификация с хэшированием требует, чтобы клиенты использовали .NET или Internet Explorer 5.x. Учетные записи пользователей должны храниться в Active Directory, которая должна быть сконфигурирована на поддержку аутентификации с хэшированием.

Реализация

Настройте IIS на аутентификацию с хэшированием. Детали см. в статье Q222028 из Microsoft Knowledge Base Setting Up Digest Authentication for Use with Internet Information Services 5.0.

Если вам нужно запускать приложение ASP.NET под учетной записью, аутентифицированной данным способом, измените конфигурацию файла Web.config:

// Файл web.config
<system.web>
<authentication mode="Windows" />
</system.web>

Чтобы задействовать аутентификацию с хэшированием в Windows 2000, серверу должен получить доступ к серверу Active Directory, настроенному на аутентификацию с хэшированием.

Более подробную информацию об аутентификации с хэшированием см. в RFC 2069 (http://www.ietf.org/rfc/rfc2069.txt).

Интегрированная Windows-аутентификация

Интегрированная Windows-аутентификация (использующая либо запрос-ответ NTLM, либо Kerberos) подразумевает аутентификацию пользователя в домене Windows NT или в Active Directory. В отличие от базовой аутентификации и аутентификации с хэшированием зашифрованный пароль по сети не передается, что делает этот способ весьма безопасным. Если на сервере установлена Active Directory, а браузер совместим с протоколом Kerberos V5, применяются и этот протокол, и протокол запроса-ответа (challenge/response); в ином случае используется только последний вариант. Такая аутентификация лучше всего подходит для интрасети, где клиентские и серверный компьютеры находятся в одном домене, а администраторы могут гарантировать, что на каждом компьютере установлен браузер Microsoft Internet Explorer версии не ниже 3.01.

Типичные сценарии применения

Подумайте об интегрированной Windows-аутентификации, если:

• у ваших пользователей есть учетные записи в домене Windows NT или в Active Directory;
• приложение работает в интрасети (за брандмауэром);
• все клиенты используют браузер Internet Explorer версии не ниже 3.01;
• требуется делегирование (для этого нужен Kerberos);
• вы должны обеспечить автоматический вход для пользователей домена (например, без всплывающих диалоговых окон входа).

Интегрированная Windows-аутентификация не годится, когда:

• учетные записи пользователей хранятся во внешней базе данных, а не в базе данных домена Windows NT или в Active Directory;
• требуется поддержка аутентификации через Интернет;
• клиенты используют Netscape Navigator или другие сторонние браузеры (не от Microsoft);
• вам нужно получать клиентский пароль в незашифрованном виде.

Прочие соображения

Выбирая интегрированную Windows-аутентификацию, примите во внимание следующие соображения.

Уровень защиты NTLM и Kerberos

Оба этих протокола считаются высокозащищенными. В случае их применения пароль по сети не передается. В NTLM используется механизм запроса-ответа. Протокол Kerberos считается еще более защищенным, так как поддерживает взаимную аутентификацию (mutual authentication), т. е позволяет клиентам проверять сервер, с которым они взаимодействуют.

Проблемы делегирования

Протокол NTLM не поддерживает делегирование. После того как удостоверения клиента переданы серверу IIS, их нельзя передать какому-то другому серверу для аутентификации. Однако Kerberos поддерживает делегирование, что позволяет передавать удостоверения клиента другим процессам или компьютерам. Например, используя Kerberos, можно передавать удостоверения Web-пользователя на промежуточный уровень COM+, а через него базе данных Microsoft SQL Server, настроенную на использование интегрированной Windows-аутентификации. В Active Directory аутентификация Kerberos по умолчанию выключена. Прежде чем использовать Kerberos в качестве механизма делегирования, убедитесь, что ваша среда поддерживает этот протокол.

Применение в Интернете

Как NTLM, так и Kerberos редко применяются в Интернете. Главная проблема с использованием Kerberos в Интернете в том, что служба защиты должна быть централизована и доступна всем пользователям. А для этого нужна соответствующая инфраструктура. Кроме того, эти протоколы поддерживают только браузеры от Microsoft, что может стать ограничивающим фактором в зависимости от вашей клиентской базы.

Производительность и масштабируемость

Kerberos быстрее NTLM. Однако оба эти протокола медленнее базовой аутентификации и некоторых нестандартных способов аутентификации. Если вы рассчитываете, что множество пользователей будут регистрироваться одновременно, тщательно спроектируете конфигурацию Active Directory. Когда число потенциальных пользователей приближается к миллиону, для хранения имен пользователей и паролей может потребоваться высокопроизводительная база данных, например SQL Server. При делегировании контекста защиты в многоуровневом приложении вы, вероятно, столкнетесь с проблемами масштабирования. А точнее, вам не удастся воспользоваться такими решениями промежуточного уровня (middle-tier solutions), как пул соединений с базой данных.

Реализация

Для реализации Kerberos или NTLM настройте IIS на интегрированную Windows-аутентификацию. Если вам нужна поддержка клиентов, отличных от Internet Explorer, то, вероятно, придется использовать базовую аутентификацию в сочетании с NTLM или Kerberos.

При настройке Kerberos обратите внимание на то, что:

• клиентские и серверный компьютеры должны работать под управлением Windows 2000 в домене Windows 2000;
• для пользовательской учетной записи клиента должно быть разрешено делегирование;
• для учетной записи сервиса должно быть разрешено делегирование.

Если приложение ASP.NET должно выполняться под учетной записью пользователя, проверяемого IIS через интегрированную Windows-аутентификацию, измените конфигурацию Web.config:

// Файл web.config
<system.web>
   <authentication mode="Windows" />
</system.web>

Подробнее о Kerberos см. по ссылкам:

• Kerberos Components in Windows 2000;
• Kerberos Explained.

Аутентификация с сертификатами

Сертификат - это цифровой "ключ", установленный на компьютере. Когда компьютер пытается обратиться к серверу, этот ключ автоматически передается серверу; по нему и аутентифицируется пользователь. Клиентские сертификаты можно сопоставлять с учетными записями Windows в домене или в Active Directory. При использовании Windows Authentication Provider в ASP.NET поток приложения выполняется от имени пользователя, с учетной записью которого сопоставлен сертификат. Кроме того, в ASP.NET можно реализовать нестандартную аутентификацию, при которой вы, например, используете адрес электронной почты (или аналогичное уникальное поле), содержащийся в сертификате. Для клиента аутентификация проходит незаметно, так как регистрации на странице ввода не требуется. Благодаря этому сертификаты - довольно привлекательный вариант аутентификации для автоматизированных бизнес-процессов.

Типичные сценарии применения

Аутентификация с сертификатами подходит, если:

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

Аутентификация сертификатами не годится, когда:

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

Прочие соображения

Выбирая аутентификацию с сертификатами, примите во внимание следующие соображения.

Развертывание

Вы должны установить клиентские сертификаты на клиентские компьютеры. Для этого существуют различные способы - от Web-развертывания до установки с компакт-диска. Именно проблемы развертывания в основном и являются причиной того, сертификаты не так распространены, как другие способы аутентификации, применяемые в сочетании с SSL.

Сопоставление с учетными записями Windows

Сертификаты можно сопоставлять с учетными записями в домене или Active Directory. Если требуется аутентификация на индивидуальной основе, можно применить сопоставление типа "один к одному", при котором сертификат сопоставляется с конкретной учетной записью. Ограничений на такое сопоставление при использовании Active Directory нет.

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

Для примера рассмотрим следующий B2B-сценарий.

• Компания A разрешает сотрудникам партнерской компании B просматривать определенные разделы своего внутреннего Web-сайта.
• На компьютерах компании B установлен сертификат.
• Сопоставление "многие к одному" приводит к тому, что ASP.NET-приложение выполняется под универсальной учетной записью Windows "CompanyB".

Более подробные сведения о сертификатах см. в книге Майкла Говарда (Michael Howard) Designing Secure Web-Based Applications for Microsoft Windows 2000.

Реализация

Настройте IIS на аутентификацию с сертификатами. Подробнее о сопоставлении сертификатов открытых ключей с учетными записями Windows 2000 см. в Step-by-Step Guide to Mapping Certificates to User Accounts.

Аутентификация через Passport

Аутентификация через Passport - централизованный служба аутентификации, предоставляемая Microsoft. При ее использовании вам не придется реализовать собственный аутентифицирующий код, входную страницу, а иногда и таблицу пользователей (user table). Passport основан на механизме поддержки cookie. Если клиент уже аутентифицирован в Passport, ему разрешается доступ к вашему сайту. Иначе он автоматически переадресуется на сайт Passport для аутентификации.

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

На платформе Windows 2000 нельзя напрямую интегрировать Passport с каким бы то ни было встроенным механизмом аутентификации и авторизации. Хотя .NET Framework проверяет cookie, создаваемые при этой авторизации, поддержка собственной базы данных пользователей потребует от вас написания кода, определяющего, какому из ваших пользователей соответствует пользователь Passport, а также реализации своего механизма аутентификации.

Типичные сценарии применения

Подумайте об аутентификации Passport, если:

• ваш сайт используется совместно с другими сайтами, поддерживающими Passport, и вы хотите предоставить единый вход на все эти сайты;
• вы не хотите поддерживать базу данных с именами и паролями пользователей.

Аутентификация Passport не годится, когда:

• вы хотите задействовать имена и пароли, уже хранящиеся в вашей базе данных или Active Directory (хотя, написав дополнительный код, вы могли бы сопоставлять идентификаторы Passport с учетными записями);
• клиентами являются другие компьютеры, программно обращающиеся к сайту.

Прочие соображения

Выбирая аутентификацию через Passport, примите во внимание следующие соображения.

Поддержка Passport

Применение аутентификации через Passport требует регистрации сайта в службе Passport и установки Passport SDK на вашем сервере.

Делегирование

В Windows 2000 нельзя делегировать другому серверу удостоверения защиты, полученные от Passport.

Сопоставление с учетными записями пользователей

Идентификатор пользователя Passport (Passport User ID, PUID) - всего лишь идентификация. Если учетные записи ваших пользователей определены в Active Directory или другой базе данных и нужно сопоставлять PUID с учетными записями, вам придется написать для этого собственный код. Поддержка такого сопоставления может быть встроена в будущие версии Windows.

Защита Passport

Зашифрованные cookie делают службу Passport безопасной, когда она используется как отдельный механизм аутентификации. Однако, чтобы предотвратить атаки с повторением пакетов и обеспечить высший уровень безопасности, применяйте Passport в сочетании с SSL.

Реализация

Для реализации Passport установите на сервере Passport SDK. Кроме того, зарегистрируйтесь на использование службы Passport. При этом файл web.config следует настроить так:

// Файл web.config
<system.web>
   <authentication mode="Passport" />
</system.web>

Дополнительные сведения о службе Passport см. по ссылкам:

• The Passport Authentication Provider;
• спецификацию Passport;
• информацию для разработчиков Passport.

Аутентификация на основе форм

Аутентификация на основе форм (forms authentication) подразумевает создание собственного UI-компонента, принимающего удостоверения пользователя, например его имя и пароль. Сейчас многие Интернет-приложения предлагают пользователям регистрироваться в таких формах. Имейте в виду, что форма сама по себе не выполняет аутентификацию и предназначена исключительно для получения учетных данных. Аутентификация выполняется кодом, который обращается к базе данных с именами и паролями.

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

• Cookie. Небольшой блок данных, изначально передаваемый сервером клиенту. Затем в каждом HTTP-запросе эта строка передается обратно на сервер. Наличие такого блока может указывать, что клиент уже аутентифицирован. ASP.NET предоставляет в модуле CookieAuthenticationProvider механизм, позволяющий использовать cookie при аутентификации на основе форм. Cookie поддерживаются большинством Web-браузеров, в том числе Internet Explorer и Netscape Navigator.
• Собственный способ. Вы можете реализовать свой механизм идентификации клиента перед сервером. Так, если у клиентов отключены cookie, вы можете хранить уникальные идентификаторы в каждой строке URL-запроса. Или использовать скрытые поля формы, которые хранятся в постоянном невидимом фрейме или во фрейме верхнего уровня. В любом случае вам придется убедиться, что хакер не сумеет программно выдать себя за аутентифицированного пользователя.

Cookie широко применяются на сайтах, реализующих аутентификацию на основе форм. Первая версия .NET поддерживает аутентификацию на основе форм только через cookie.

Типичные сценарии применения

Аутентификация на основе форм подходит, если:

• имена пользователей и пароли не хранятся в учетных записях Windows (но аутентификация на основе форм не запрещает применение учетных записей Windows);
• вы развертываете приложение через Интернет;
• требуется поддержка всех браузеров и клиентских операционных систем;
• нужна собственная UI-форма в качестве входной страницы.

Аутентификация формами не годится, когда:

• вы развертываете приложение в корпоративной интрасети и хотите использовать преимущества интегрированной Windows-аутентификации;
• нет возможности программно проверить имя пользователя и пароль.

Прочие соображения

Выбирая аутентификацию на основе форм, примите во внимание следующие соображения.

Защита при аутентификации на основе форм

Пароли, посылаемые с входной страницы, можно защитить от перехвата с помощью SSL. Учтите, что cookie, хранящие идентификацию пользователя между запросами, можно "похитить" с помощью программы сетевого мониторинга. Единственный способ полностью защитить сайт при использовании cookie - применение SSL. Для большинства коммерческих сайтов это непрактично, так как связано со значительным падением производительности. В ASP.NET можно заставить сервер повторно генерировать cookie по истечении некоего времени. Такая политика предотвращает ситуацию, когда при доступе к сайту предоставляют "краденый" cookie.

Производительность и масштабируемость

При разработке Web-сайта с интенсивным трафиком следует учесть влияние аутентификации пользователей на производительность. Чем больше ожидаемое число одновременно входящих пользователей, тем быстрее должна выполняться проверка удостоверений.

SSL заметно ухудшает производительность из-за дополнительных издержек на шифрование. Возможно, для достижения требуемого уровня производительности придется отделить серверы, отвечающие за защищенный вход, от серверов контента в Web-ферме.

Проверка на наличие cookie

В .NET проверка на наличие cookie выполняется автоматически. Но если вы не используете .NET, то можете выбрать один из двух основных подходов.

• Реализовать ISAPI-фильтр, который подтверждает наличие cookie в запросе, доказывающего, что клиент уже прошел аутентификацию. Если такой файл существует, запрос можно обрабатывать. Нет - клиент следует перенаправить на страницу входа. Пример такого ISAPI-фильтра реализован в Microsoft Commerce Server 2000.
• Добавить в начало каждой Web-страницы код, проверяющий наличие cookie или другой строки, переданной странице. Если ничего такого нет, код перенаправляет пользователя на входную страницу. Такая реализация проста, но позволяет защищать лишь ASP-страницы, а не ресурсы вроде файлов изображений.

В ASP.NET можно задействовать преимущества встроенной функциональности, предоставляемой аутентификацией на основе форм.

Аутентификация на основе форм в сочетании с учетными записями Windows

Если вы развертываете Интернет-приложение и у ваших пользователей есть на сервере учетные записи Windows, то можете задействовать аутентификацию на основе форм (в том числе, в комбинации с SSL) как альтернативу базовой аутентификации или аутентификации с хэшированием.

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

Реализация

Чтобы реализовать аутентификацию на основе форм, создайте собственную входную страницу и перенаправляйте на нее все клиенты, не прошедшие аутентификацию. Вам также понадобится собственная схема просмотра учетных записей. В ASP.NET используйте следующий файл Web.config:

// Файл web.config
<system.web>
   <authentication mode="Forms" />
</system.web>

При самостоятельной реализации аутентификации IIS, как правило, настраивают на анонимный доступ.

Более подробные сведения о реализации SSL см. в следующих статьях:

• Untangling Web Security: Getting the Most from IIS Security;
• "Configuring IIS 5.0 Security" в Internet Information Services 5.0 Resource Guide.

Cookie

Cookie - это небольшой текстовый файл, помещаемый на ваш жесткий диск Web-сервером. Его основное предназначение - дать возможность серверу опознать повторного посетителя. Cookie можно применять как с аутентификацией, так и без нее. Возможны следующие варианты:

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

ASP.NET предоставляет механизм для создания cookie и автоматической проверки их наличия в клиентских запросах. Cookie, созданные ASP.NET, можно шифровать по алгоритму Triple DES, поддерживаемому .NET Framework. Кроме того, вы можете сами реализовать провайдер cookie и использовать его совместно с аутентификацией на основе форм.

Более подробные сведения о cookie см. в Сведения о cookie.

Прочие соображения

Браузеры некоторых типов накладывают ограничения на размеры cookie. В RFC 2019 определено ограничение в 4 Кб. В Internet Explorer 5 ограничений на размер нет. Чтобы браузеры корректно работали с cookie, нужно соответствующим образом настроить параметры безопасности.

Защита в Web-сервисах

Web-сервис - это основанное на инфраструктуре ASP.NET приложение, которое можно программно вызывать через Интернет. Его защита аналогична защите интерактивных Web-сайтов. Для этого служат те же механизмы, что и для других ASP.NET-ресурсов (например, IIS и провайдеры аутентификации ASP.NET). Однако при разработке следует учесть ряд дополнительных факторов.

• Взаимодействие с клиентами. Web-сервис может работать не с интерактивными пользователями, которые указывают свои удостоверения защиты, а с приложениями.
• Защита на уровне методов. Вам может понадобиться авторизация пользователей на уровне отдельных методов, чтобы ограничить доступ к некоторым методам. Для этого применяются те же способы, что и при аналогичной защите в COM+-компонентах.
• Делегирование. Web-сервису может понадобиться обращение к другим сервисам с сохранением контекста защиты исходного вызывающего.

Аутентификация в Web-сервисах

Web-сервисам нужно так или иначе принимать удостоверения пользователей. Если сервис не является интерактивным, он должен либо получать маркер защиты (security token) от вызывающего приложения, либо предоставлять соответствующие методы, позволяющие передавать удостоверения. Следующие способы аутентификации просты в применении и не требуют от пользователя ввода учетных данных (благодаря этому они хорошо подходят для Web-сервисов с программным доступом):

• базовая, с хэшированием и интегрированная Windows-аутентификация;
• аутентификация с сопоставлением сертификатов;
• нестандартная или специфичная для конкретного приложения аутентификация.

В принципе вы могли бы использовать и такие средства, как:

• Internet Protocol Security;
• Passport.

Применение учетных записей Windows и IIS-аутентификации

Изучите материалы, представленные в разделе Способы аутентификации. Такая реализация потребует наименьшего объема кода и, кроме того, позволит контролировать доступ к другим ресурсам с помощью ACL.

Применение сертификатов и их сопоставление

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

Нестандартная аутентификация

Вы можете реализовать собственную аутентификацию. Ее преимущества перед интегрированной Windows-аутентификацией в том, что приложениям не придется поддерживать отдельные учетные записи Windows для каждого пользователя. Вы можете вообще отказаться от IIS-аутентификации и включить в код Web-сервиса собственный метод аутентификации, оптимизированный под конкретные задачи приложения.

К возможным способам собственной аутентификации в Web-сервисах относятся:

• прием имени пользователя и пароля как параметров при вызове метода;
• создание метода входа, который вызывается до любых других методов. Чтобы убедиться, вызывался ли метод входа, можно задействовать функциональность cookie, поддерживаемую Microsoft .NET Framework;
• хранение удостоверений в заголовке или теле SOAP;
• создание собственного HTTP-заголовка или тела для хранения удостоверений.

Internet Protocol Security

Если вам известен IP-адрес клиентского компьютера (например, Web-сервера, который обращается к бизнес-логике, инкапсулированной в Web-сервисах на промежуточном уровне), то Internet Protocol Security (IPSec) может оказаться полезным вариантом. Этот механизм позволяет отфильтровывать компьютеры, соединяющиеся с вашим Web-сервисом, по их IP-адресам.

В Интернет-сценариях такой подход не годится, так как IP-адреса клиентов заранее не известны.

Применение Passport с Web-сервисами

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

Авторизация

После аутентификации пользователей для доступа к Web-сервису может понадобиться их авторизация. Вот несколько вариантов авторизации на основе:

• Windows ACL;
• URL;
• .NET Principal Objects.

Авторизация на основе Windows ACL

В этом случае вы можете создать разрешения файловой системы на доступ к конкретным файлам приложения. Этот подход работает, если ваш Web-сервис аутентифицирует пользователей по учетным записям Windows и применяет олицетворение.

Авторизация на основе URL

Модуль URLAuthorizationModule сопоставляет пользователей и роли с элементами внутри пространства имен URI. В модуле реализованы как разрешительные, так и запретительные утверждения. То есть модуль может как запрещать, так и разрешать отдельным пользователям обращаться к каким-либо элементам пространства имен URI, например, в зависимости от их принадлежности к определенной роли. В следующем примере доступ разрешен нескольким пользователям домена, а всем остальным - запрещен.

<configuration>
   <system.web>
         <authentication mode="Windows" />
          <authorization>
              <allow users="domain1\user, domain2\user2, domain1\user3 />
              <deny users="*" />
          </authorization>
    </system.web>
</configuration>

Объект Windows Principal

Пространство имен System.Security.Principal в библиотеке классов .NET Framework Class Library содержит объект Windows Principal, представляющий контекст защиты, в котором исполняется код. Этот объект создается автоматически при использовании Windows-аутентификации в IIS. С его помощью можно проверять членство пользователя в группах Windows и соответственно ограничивать доступ.

Универсальный объект Principal

На основе ролей, определенных вами, можно создать универсальный объект Principal. Он применяется, когда у вас есть собственная база данных пользователей и ролей. Данные в него записываются при событии OnAuthenticate. В обработчике этого события вы можете сопоставить собственную таблицу с учетными записями Windows. В любом случае для каждого пользователя можно создать свой объект Principal.

Для уже аутентифицированного пользователя объект Principal можно воссоздать на основе cookie.

Роли и защита уровня методов

Защита уровня методов нужна, чтобы ограничить вызов некоторых методов только определенными участниками безопасности (principals). Такая защита реализуется несколькими способами.

При наличии учетных записей Windows определите для своих пользователей роли в виде групп Windows. Так как ASP-поток будет олицетворять клиент и вам будет доступен объект Windows Principal:

• создайте ACL-списки для защищаемых ресурсов, к которым обращается ASP.NET-поток;
• вызывайте метод IsInRole объекта Windows Principal из каждого метода, чтобы проверять, есть ли у вызвавшего необходимые разрешения. Кроме того, вы можете написать в коде логическое выражение, вызывающее конкретную подпрограмму в зависимости от группы, к которой относится клиент.

Если вы используете универсальный объект Principal, созданный на основе ролей, которые хранятся в вашей базе данных:

• программно проверяйте принадлежность к роли, вызывая метод IsInRole объекта Principal точно так же, как и для описанного выше объекта Windows Principal.

Если объект Principal вас не устраивает, есть другие варианты.

• Принимать удостоверения пользователя в качестве параметров при вызове метода и выполнять поиск в базе данных.
• Проверять наличие cookie в начале каждого метода.
• Создать метод входа, возвращающий некое ключевое значение. Остальные методы принимают это значение в качестве параметра. Такой подход аналогичен использованию cookie, поддерживаемых браузером, но применим и в тех случаях, когда клиент не поддерживает cookie.

Делегирование

Все, что говорилось о делегировании для Web-сайтов ASP.NET, относится и к Web-сервисам. Чтобы делегировать контекст защиты Web-сервису, понадобится либо аутентификация Kerberos, либо передача удостоверений, чтобы Web-сервисы, выполняемые на других компьютерах, могли вызывать LogonUser, если они работают под управлением Windows, или эквивалентную функцию при наличии другой операционной системы.

Доступ клиентов

Для программного доступа к Web-сервису используйте преимуществами .NET-классов, обеспечивающих клиентам возможность соединений. Клиенты .NET поддерживают следующие протоколы аутентификации:

• Basic (базовую);
• Digest (с хэшированием);
• Windows Integrated (интегрированную в Windows) (NTLM и Kerberos);
• Certificate (с сертификатами);
• Custom (нестандартную).

Защита по правам доступа кода

Code Access Security (CAS) (защита по правам доступа кода) в .NET Framework защищает компьютер от вредоносного кода и обеспечивает безопасное выполнение мобильного кода. Так как CAS - функциональность подсистемы защиты .NET, она применима к любому управляемому коду, в том числе к Web-приложениям ASP.NET. Но в следующих случаях может понадобиться написание специфического кода для поддержки CAS:

• разработка элементов управления, выполняемых в браузере;
• хостинг сторонних приложений;
• хранение сборок от разных поставщиков на общем сервере;
• запрет доступа из определенных сборок к некоторым "родным" функциям, например к API-функциям записи в файл.

CAS устанавливает разные уровни доверия к коду в зависимости от политики безопасности, источника кода и других параметров его идентификации, например строгого имени сборки. CAS уменьшает вероятность того, что вашим кодом воспользуется какой-то другой, вредоносный код. Эта модель защиты позволяет указывать операции, которые разрешается выполнять вашему коду, и операции, для него запрещенные. В частности, CAS поддерживает механизм разрешений; через него код может явно запросить одни разрешения и явно отказаться от других, которые ему никогда не понадобятся.

Полномочия кода

Защита по правам доступа кода основана на концепции разрешений. Каждое разрешение соответствует праву на доступ кода к защищенному ресурсу, например файлу, каталогу или записи в реестре, либо праву на выполнение защищенной операции вроде вызова неуправляемого кода. Код может затребовать определенные разрешения, а политика безопасности исполняющей среды определяет, какие из них можно выдать. Полный список разрешений см. в Code Access Permissions.

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

Так, приложения, выполняемые на UNC-ресурсе (в зоне безопасности Intranet), получают набор разрешений LocalIntranet, а приложения, работающие на локальном компьютере (в зоне безопасности MyComputer), - набор разрешений FullTrust.

Web-приложения ASP.NET можно настраивать еще детальнее, присваивая им уровни доверия. Для этого служат элементы <trust> в конфигурационном файле.

<trust level="Full | High | Low | None" originUrl="url" />

Каждый уровень присваивает приложению разрешения, состав которых определен в XML-файле политики безопасности. Каждый уровень сопоставлен со своим файлом. Сопоставления по умолчанию в ASP.NET таковы.

• High (Высокий) - соответствует web_hightrust.config.
  Разрешения этого уровня предоставляют приложению права на доступ для чтения и записи в каталог приложения (в зависимости от разрешений, определенных в операционной системе) и позволяют ему заменять объект участника аутентификации (authentication principal object). Кроме того, они запрещают приложению вызывать неуправляемый код.
• Low (Низкий) - соответствует web_lowtrust.config.
  Этот уровень позволяет читать каталог приложения и ограничивает сетевые соединения. Приложения могут подключаться к своему хост-сайту при условии правильной настройки атрибута originUrl элемента <trust>.
• None (Нет) - соответствует web_notrust.config.
  Этот уровень предоставляет базовые разрешения на выполнение кода и позволяет приложению использовать изолированное хранилище (механизм, который дает возможность безопасно сопоставлять код с сохраненными данными).

Заметьте, что с уровнем доверия Full не связан какой-либо конфигурационный файл, поскольку этот уровень позволяет приложению использовать все ресурсы (в зависимости от разрешений, определенных в операционной системе), что равносильно его выполнению без CAS (хотя для управляемого кода CAS отключить нельзя). Вы можете переопределить эти сопоставления в элементе <securityPolicy> конфигурационного файла, а также настроить и расширить каждый уровень. Или создать собственные уровни с произвольным набором разрешений. Набор сопоставлений, заданных в <securityPolicy> по умолчанию, показан ниже.

<securityPolicy>
   <trustLevel name="Full" policyFile="internal" />
   <trustLevel name="High" policyFile="web_hightrust.config" />
   <trustLevel name="Low"  policyFile="web_lowtrust.config" />
   <trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>

Блокировка конфигурационных параметров

Конфигурация ASP.NET имеет иерархическую природу, и конфигурационные файлы могут располагаться на уровне компьютера, приложения и субприложения. Конфигурационные файлы нижних уровней могут переопределять параметры конфигурационных файлов верхних уровней и включать дополнительную конфигурационную информацию. Хотя такая структура обеспечивает высокую гибкость, администраторам может потребоваться блокировка конфигурационных параметров и запрет на их изменение конкретными приложениями. Так, администратор Web-сайта может указать уровень защиты по правам доступа кода и запретить его изменение в отдельных приложениях. Для этого служит элемент <location> в сочетании с атрибутом allowOverride.

Например, администратор Web-сайта хочет запретить вызовы неуправляемого кода. Следующий фрагмент конфигурационного файла демонстрирует, как блокировать параметры защиты для всего сайта и ограничить все приложения высоким уровнем доверия (не позволяющим вызывать неуправляемый код):

<location path="somesitepath" allowOverride="false">
  <trust level="high" originUrl="http://somesite.com" />
</location>

Атрибут path может ссылаться на сайт или виртуальный каталог и применяется к указанному каталогу и всем его подкаталогам. В примере, приведенном выше, при атрибуте allowOverride, равном false, приложения на сайте не смогут переопределять конфигурационные параметры, заданные в элементе <location>. Блокировать можно любые параметры - не только параметры защиты вроде уровней доверия.

Более подробные сведения см. по ссылкам:

• Security in .NET: Enforce Code Access Rights with the Common Language Runtime;
• Code Access Security.

Защита на уровне каналов

Каналы передают сообщения через границы удаленно взаимодействующих AppDomain´ов, процессов и компьютеров. В .NET Framework есть два канала: HTTP и TCP.

Чтобы защитить конфиденциальную информацию, передаваемую по этим протоколам, используйте защищенный канал. Иначе с помощью программ сетевого мониторинга незашифрованную информацию легко перехватить и прочесть.

Вот некоторые из основных особенностей канальной защиты.

• HTTP-канал в IIS поддерживает передачу и прием данных, защищенных с помощью SSL. SSL - наиболее распространенный механизм создания защищенного коммуникационного канала и настраивается в IIS.
• Даже при использовании незащищенного канала, например HTTP по порту 80 или TCP, вы можете вручную шифровать данные через Cryptographic API.
• Можно реализовать механизм канальной защиты ниже транспортного уровня. В Windows 2000 для защиты данных при передаче прозрачно для приложения можно за счет Internet Protocol Security (IPSec).
• При использовании ASP.NET совместно с COM- или DCOM-компонентами и применении DCOM в качестве механизма удаленного взаимодействия обратите внимание на уровень аутентификации DCOM Packet Privacy, позволяющий шифровать данные, передаваемые через DCOM.

Более подробные сведения см. по ссылкам:

• "Secure Web Communications" в Microsoft^® Windows^® 2000 Server Resource Kit (Microsoft Press);
• спецификацию удаленного взаимодействия в .NET Framework Developer Specifications;
• разделы MSDN по настройке защиты DCOM и NT.

Дополнительные сведения

Дополнительную информацию по вопросам безопасности, рассмотренным в данном документе, см. в:

• "Understanding Digital Certificates" в Microsoft^® Windows^® 2000 Server Resource Kit (Microsoft Press);
• .NET Framework SDK;
• статью Q158229 в Microsoft Knowledge Base INFO: Security Ramifications for IIS Applications;
• A Blueprint for Building Web Sites Using the Microsoft Windows Platform.

Подробнее о защите Web-сервисов см. по ссылкам:

• Secure Web Services Using the SOAP Toolkit;
• Designing Secure Web-Based Applications for Microsoft^® Windows^® 2000 (Microsoft Press);
• Secure Internet Information Services 5 Checklist;
• статью Q187506 в Microsoft Knowledge Base List of NTFS Permissions Required for IIS Site to Work.

Общие сведения о защите см. в:

• Microsoft Security.

Приложение A

Start - Начало
Do users to have log in - Должны ли пользователи регистрироваться?
No, I do not need to know the user - Нет, информация о пользователе не нужна
Is personalization required? - Требуется ли персонализация?
Yes - Да
Anonymous and cookies Anonymous and passport - Анонимная и cookie Анонимная и Passport
Will interactive users log in? - Будут ли регистрироваться интерактивные пользователи?
Certificates - Сертификаты
Users Login - Пользователи регистрируются
to use services or to access content - для использования сервисов или доступа к контенту
Anonymous - Анонимная
Are the users in Windows Accounts? - Существуют ли для пользователей учетные записи Windows?
The app run on the Internet? - Приложение работает в Интернете?
No, Intranet only - Нет, только в интрасети
Do you need to delegate security context? - Нужно ли делегирование контекста защиты?
Yes - Да
Custom Credential Mapping - Нестандартное сопоставление сертификатов
Basic Kerberos - Базовая с использованием Kerberos
Are users in Passport? - Пользователи зарегистрированы в Passport?
Passport - Passport
Yes, runs over the Internet - Да, работает через Интернет
Are servers and clients W2K Only? - Серверы и клиенты работают только под управлением W2K?
Basic - Базовая
Digest - С хэшированием
NTLM - NTLM
Kerberos - Kerberos
Certificates - Сертификаты
Forms over SSL Certificates - Формы поверх SSL С сертификатами
Do you need secure Login? - Требуется ли защищенный вход?
Basic Forms Digest - Базовая На основе форм С хэшированием
Basic/SSL Digest/SSL Forms/SSL Certificates - Базовая/SSL с хэшированием/На основе форм с SSL/SSL с сертификатами
Basic - Базовая
NTLM - NTLM
Certificates Forms - С сертификатами На основе форм
}

Рис. 3. Схема, помогающая выбрать оптимальный способ аутентификации (щелкните, чтобы увеличить изображение)

Благодарности

Выражаю глубокую признательность всем, кто внес свой вклад в подготовку этого документа, и рецензентам:

Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro (Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward Jezierski, Alex Mackman, Mike Jenne, David Mowers, Amitabh Srivastava, Steve Busby, Kenny Jones.

Чтобы лучше освоить передовой опыт применения .NET, вы можете обратиться к экспертам по технологиям в Центре технологий Microsoft в вашем регионе. За более подробной информацией, пожалуйста, обращайтесь на Web-страницу Microsoft Technology Centers.