Этап планирования 4. Планирование безопасности приложений

Кит Ньюман и Роберт Мак-Мюррей

На этом этапе создания веб-сайта необходимо рассмотреть требования к безопасности вашего приложения ASP.NET. В следующих разделах описаны параметры безопасности приложений, доступные в IIS 8.

4.1. Изоляция веб-приложений

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

Изоляция веб-приложений включает следующее.

• Изоляция сайта. Разделите различные приложения по разным сайтам с разными пулами приложений.
• Понижение привилегий. Запустите рабочий процесс как объект с низкими полномочиями (виртуальный объект пула приложений), уникальный для каждого сайта.
• Временная изоляция. Настройте отдельную ASP.NET временную папку для каждого сайта и предоставьте доступ только к соответствующему удостоверению процесса.
• Изоляция контента. Обязательно установите ACL (список управления доступом) в корневом каталоге каждого сайта, чтобы разрешить доступ только соответствующему процессу.

Совет

Рекомендуется разместить содержимое веб-сайта и веб-приложения на диске, отличном от системного диска (C:).

4.2. Уровни доверия .NET

Уровень доверия приложения определяет разрешения, которые предоставляет политика управления доступом для кода (CAS) ASP.NET. Управление доступом для кода определяет две категории доверия: полное доверие и частичное доверие. Приложение, имеющее разрешения полного доверия, может получать доступ ко всем типам ресурсов на сервере и выполнять привилегированные операции. На приложения с полным доверием воздействуют только параметры безопасности операционной системы.

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

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

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

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

4.3. Проверка подлинности .NET

Проверка подлинности помогает подтвердить удостоверение клиентов, требующих доступ к вашим сайтам и приложениям. Если включена проверка подлинности, СЛУЖБЫ IIS 8 используют учетные данные учетной записи, предоставленные пользователем, чтобы определить, какие разрешения были предоставлены пользователю и к каким ресурсам пользователь может получить доступ.

В этом разделе рассматриваются режимы проверки подлинности, применяющиеся в приложениях ASP.NET.

1. Проверка подлинности с помощью форм ASP.NET
2. Проверка подлинности с помощью олицетворения ASP.NET

Проверка подлинности с помощью форм ASP.NET

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

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

1. Основные принципы проверки подлинности с помощью форм
2. Файлы cookie проверки подлинности

Основные принципы проверки подлинности с помощью форм

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

Важно!

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

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

Проверка подлинности с помощью форм имеет следующие преимущества:

• позволяет использовать для проверки подлинности либо настраиваемое хранилище данных, например базу данных SQL Server, либо Active Directory;
• легко интегрируется с пользовательским веб-интерфейсом;
• клиенты могут использовать любой браузер.

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

Важно!

При выборе проверки подлинности с помощью форм нельзя в то же время использовать какой-либо из способов проверки подлинности на основе запросов.

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

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

Файлы cookie проверки подлинности

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

Важно! Так как файлы cookie проверки подлинности передаются между клиентом и сервером вместе с каждым запросом, всегда обеспечьте безопасность файлов cookie проверки подлинности с помощью протокола SSL. Сведения о SSL см. в статье 4.5. Обмен данными по протоколу TLS/SSL.

Файлы cookie являются более эффективным способом отслеживания посетителей, чем строки запросов, так как они не требуют перенаправления. Однако они зависят от браузера, а некоторые браузеры не поддерживают использование файлов cookie. Кроме того, применение проверки подлинности на основе файлов cookie не всегда эффективно, поскольку некоторые пользователи отключают поддержку файлов cookie в своих браузерах.

По умолчанию имя файла cookie для приложений ASP.NET — .ASPXAUTH. Однако вместо него можно использовать уникальное имя и путь файла cookie для каждого приложения. В этом случае пользователи, прошедшие проверку подлинности для одного приложения, не станут проверенными для других приложений на веб-сервере.

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

Режим	Описание
Использовать файлы cookie	Файлы cookie используются всегда, независимо от устройства.
Не использовать файлы cookie	Файлы cookie не используются.
Автоматическое обнаружение	Файлы cookie используются в том случае, если профиль устройства поддерживает файлы cookie. В противном случае файлы cookie не используются. Для браузеров настольных компьютеров, которые заведомо поддерживают файлы cookie, ASP.NET проверяет, включены ли файлы cookie. Это значение по умолчанию.
Использовать профиль устройства	Файлы cookie используются в том случае, если профиль устройства поддерживает файлы cookie. В противном случае файлы cookie не используются. ASP.NET не проверяет, включены ли файлы cookie на устройствах, которые поддерживают файлы cookie. Этот параметр используется по умолчанию для IIS 8.

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

Режим	Описание
Шифрование и проверка	Указывает, что для защиты файлов cookie приложение применяет как проверку данных, так и шифрование. В этом случае используется настроенный алгоритм проверки данных (на основе машинного ключа). Если доступен алгоритм Triple-DES (3DES), и ключ достаточно длинный (не менее 48 байт), то для шифрования используется 3DES. Этот параметр используется по умолчанию (и рекомендуется).
Нет	Указывает, что и шифрование, и проверка отключены для сайтов, использующих файлы cookie только для персонализации и имеющих более слабые требования к безопасности. Использование файлов cookie таким образом не рекомендуется, однако это наименее ресурсоемкий способ включения персонализации с помощью .NET Framework.
Шифрование	Указывает, что файл cookie шифруется с помощью алгоритма Triple-DES или DES, но проверка данных в этом файле cookie не выполняется. Используемые таким образом файлы cookie могут подвергнуться атакам с открытым текстом.
Проверка	Указывает, что схема проверки оценивает, не было ли изменено содержимое зашифрованного файла cookie во время передачи.

Важно!

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

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

Рекомендуется подумать об использовании этого параметра в следующих обстоятельствах.

• Для кэширования доступен ограниченный объем памяти.
• Имеется много объектов для кэширования, а этот параметр разрешает оставаться в кэше только наиболее часто запрашиваемым объектам.

Примечание

Число минут задается до истечения срока действия файла cookie проверки подлинности, заданного параметром Время действия файла cookie проверки подлинности (в минутах).

Проверка подлинности с помощью олицетворения ASP.NET

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

Если включить олицетворение для приложения ASP.NET, это приложение может выполняться в одном из двух разных контекстов: как пользователь, прошедший проверку подлинности с помощью IIS 8, или как настроенная вами произвольная учетная запись. Например, если используется анонимный доступ, и приложение ASP.NET должно выполняться как проверенный пользователь, то приложение будет запускаться в учетной записи, настроенной для анонимных пользователей (обычно это IUSR). Аналогично, если вы выбрали запуск приложения под произвольной учетной записью, оно будет выполняться в рамках любого контекста безопасности, настроенного для этой учетной записи.

По умолчанию олицетворение ASP.NET отключено. Если включить олицетворение, приложение ASP.NET выполняется в контексте безопасности пользователя, прошедшего проверку подлинности с помощью IIS 8.

4.4. Параметры машинных ключей

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

• Ключ проверки вычисляет код проверки подлинности сообщения (MAC) для подтверждения целостности данных. Этот ключ добавляется в файл cookie проверки подлинности с помощью форм или в состояние просмотра для конкретной страницы.
• Ключ расшифровки используется для шифрования и расшифровки билета проверки подлинности с помощью форм и для просмотра состояния.

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

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

• Решите, какой метод проверки следует использовать: AES, MD5, SHA1 (по умолчанию), TripleDES, HMACSHA256, HMACSHA384 или HMACSHA512.
• Решите, какой метод шифрования следует использовать: Auto (по умолчанию), AES, TripleDES или DES.
• Решить, должен ли ключ проверки создаваться автоматически во время выполнения.
• Решить, должен ли создаваться уникальный ключ проверки для каждого приложения.
• Решить, должен ли ключ расшифровки создаваться автоматически во время выполнения.
• Решить, должен ли создаваться уникальный ключ расшифровки для каждого приложения.

4.5. Взаимодействие по протоколу TLS/SSL

Протокол TLS и его предшественник протокол SSL — это протоколы, обеспечивающие безопасность взаимодействия с веб-сайтом. С помощью протокола TLS/SSL можно проверять подлинность серверов и клиентов, а затем использовать его для шифрования сообщений между проверенными сторонами.

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

Чтобы настроить TSL/SSL для веб-сайта, выполните следующие действия.

1. Получите сертификат сервера в центре сертификации (ЦС). См. раздел Сертификаты серверов.
2. Добавьте SSL-привязку на сайт. См. раздел SSL-привязка.
3. Настройте IIS для требования SSL на сайте. См. раздел Требование SSL для сайта.
4. Рассмотрите возможность использования для сайта сертификатов клиентов. См. раздел Сертификаты клиентов.

Сертификаты серверов

Сертификат сервера можно получить в центре сертификации (ЦС). Получение сертификата сервера в центре сертификации является первым шагом в настройке протокола SSL или TLS. Можно получить сертификаты сервера в стороннем центре сертификации. Сторонний центр сертификации может затребовать доказательство подлинности, прежде чем выдать сертификат. Можно также выдать свой собственный сертификат, используя сетевой ЦС, например, службы сертификации Майкрософт.

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

Цифровые сертификаты выполняют следующие функции.

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

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

Сертификаты могут выдаваться для нескольких целей. Эти цели включают проверку подлинности веб-пользователя, проверку подлинности веб-сервера, S/MIME, IPsec, TLS и подписывание кода.

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

Привязка SSL

Если контент сайта служит разным целям, или необходимо использовать для сайта другой протокол, можно назначить этому сайту несколько привязок. Например, коммерческий сайт может иметь приложение, требующее, чтобы пользователи входили в учетную запись для покупки товара. Компания размещает сайт с использованием протокола HTTP, но пользователи должны входить в свои учетные записи на странице HTTPS. В этом примере сайт будет иметь две привязки: одну для части HTTP, а вторую для части HTTPS.

По умолчанию с помощью диспетчера IIS можно добавлять только привязки для протоколов HTTP и HTTPS. Если требуется добавить привязку для другого протокола, например, для протокола, поддерживаемого Windows Communication Foundation (WCF), используйте другое средство администрирования. Однако если установить FTP-сервер IIS, то с помощью диспетчера IIS можно будет добавлять привязки FTP. Могут существовать и другие доступные для загрузки модули или сторонние функциональные возможности, способные расширить пользовательский интерфейс.

Требование SSL для сайта

Шифрование Secure Sockets Layer (SSL) защищает конфиденциальные или личные сведения, которые пересылаются между клиентом и сервером. Когда включен протокол SSL, удаленные клиенты получают доступ к сайту, используя URL-адрес, который начинается с https://.

Сначала настройте сертификат сервера и создайте HTTPS-привязку, чтобы включить параметры SSL. Затем потребуйте шифрование Secure Sockets Layer (SSL) в каких-либо из следующих обстоятельств.

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

Сертификаты клиента

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

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

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