Защита служб

Статья
02/28/2011

Для обеспечения безопасности службы Windows Communication Foundation (WCF) необходимо выполнение двух основных требований — обеспечение безопасности передачи и выполнение авторизации. (Третье требование — аудит событий, связанных с безопасностью, — описывается в разделе Аудит событий безопасности.) Вкратце, для обеспечения безопасности передачи должна быть выполнена проверка подлинности (проверка идентификации как службы, так и клиента) и обеспечены конфиденциальность (шифрование сообщений) и целостность (цифровая подпись для обнаружения подделки). Авторизация — это управление доступом к ресурсам, например разрешение чтение файла только привилегированным пользователям. С помощью функций WCF два основных требования легко реализуются.

За исключением класса BasicHttpBinding (или элемента <basicHttpBinding> в конфигурации), обеспечение безопасности передачи включено по умолчанию для всех предопределенных привязок. В подразделах данного раздела рассматриваются два основных сценария: обеспечение безопасности передачи и авторизации в службе интрасети, размещенной в IIS, а также обеспечение безопасности передачи и авторизации в службе, размещенной в IIS.

Примечание
В Windows XP Home проверка подлинности Windows не поддерживается. Поэтому не следует запускать службу в этой системе.

Общие сведения о безопасности

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

Механизмы безопасности Windows

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

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

Более старый и менее безопасный механизм, используемый в доменах Windows, — NT LAN Manager (NTLM). В случаях, когда использовать Kerberos невозможно (обычно вне домена Windows, например в рабочей группе), в качестве альтернативы можно применять NTLM. Механизм NTLM доступен также в качестве варианта обеспечения безопасности для IIS.

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

На компьютере под управлением Windows можно защитить каждую папку в каталоге, т. е. можно выбрать папку и управлять тем, кто может обращаться к файлам, а также тем, можно ли копировать тот или иной файл или (в наиболее привилегированном случае) изменить файл, удалить файл либо добавить файлы в папку. Это называется управлением доступом, а механизм для такого управления — списком управления доступом (ACL). При создании ACL можно назначить привилегии доступа любой группе или группам, а также отдельным членам домена.

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

Реализация безопасности Windows в службах интрасети

Чтобы защитить приложение, работающее только в домене Windows, можно использовать параметры безопасности по умолчанию привязки WSHttpBinding или NetTcpBinding. По умолчанию любой пользователь одного и того же домена Windows может иметь доступ к службам WCF. Поскольку такие пользователи зарегистрированы в сети, они являются доверенными. Сообщения, передаваемые между службой и клиентом, шифруются для конфиденциальности и подписываются для целостности. Дополнительные сведения создании службы, которая использует систему безопасности Windows, см. в разделе Как защитить службу с использованием учетных данных Windows.

Авторизация с использованием класса PrincipalPermissionAttribute

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

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

Для управления доступом к ресурсам можно также использовать другой механизм, называемый олицетворением. По умолчанию служба, размещенная в IIS, работает под идентификатором учетной записи ASPNET. Учетная запись ASPNET может иметь доступ только к ресурсам, использовать которые она имеет право. Однако для папки можно задать ACL, чтобы исключить учетную запись службы ASPNET, но разрешить доступ к папке некоторым другим идентификаторам. Тогда встает вопрос, как разрешить этим пользователям доступ к папке, если для учетной записи ASPNET такой доступ не разрешен? Ответ — воспользоваться олицетворением, с помощью которого службе разрешается использовать учетные данные клиента для доступа к конкретному ресурсу. Другой пример — доступ к базе данных SQL Server, обращаться к которой имеют право только определенные пользователи. Дополнительные сведения использовании олицетворения см. в разделах Как олицетворять клиент в рамках службы и Делегирование и олицетворение с использованием WCF.

Безопасность в Интернете

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

Использование IIS и ASP.NET

Требования безопасности в Интернете и механизмы устранения связанных с безопасностью проблем не являются новыми. IIS — это веб-сервер корпорации Майкрософт для Интернета, в котором реализовано много функций обеспечения безопасности, устраняющих такие проблемы; кроме того, ASP.NET содержит функции обеспечения безопасности, которые могут использоваться службами WCF. Чтобы воспользоваться преимуществами этих функций обеспечения безопасности, разместите службу WCF в IIS.

Использование поставщиков членства и ролей ASP.NET

ASP.NET содержит поставщик членства и ролей. Поставщик — это база данных пар "имя пользователя – пароль" для проверки подлинности вызывающих, которая также позволяет задавать привилегии доступа каждого вызывающего. С помощью WCF можно легко использовать уже существующий поставщик членства и ролей через конфигурацию. Пример приложения, где демонстрируется такое использование, см. в примере Поставщик членства и ролей.

Учетные данные, используемые IIS

В отличие от домена Windows, поддерживаемого контроллером Kerberos, Интернет — это среда без отдельного контроллера для управления миллионами пользователей, входящими в систему в любое время. Вместо этого учетные данные в Интернете чаще всего представляются в виде сертификатов X.509 (называемых также сертификатами SSL). Эти сертификаты обычно издаются центром сертификации, которым может быть сторонняя компания, гарантирующая подлинность сертификата и лица, для которого он издан. Чтобы представить службу в Интернете, необходимо также предоставить такой доверенный сертификат для проверки подлинности службы.

При этом возникает вопрос, как получить такой сертификат? Один из способов — при готовности развернуть службу и приобрести для нее сертификат следует обратиться в сторонний центр сертификации, например Authenticode или VeriSign. Однако на случай нахождения на этапе развертывания с WCF и неготовности приобрести сертификат предусмотрены средства и методы для создания сертификатов X.509, которые можно использовать для моделирования развертывания в рабочей среде. Дополнительные сведения см. в разделе Работа с сертификатами.

Режимы безопасности

При программировании безопасности WCF встает несколько очень важных вопросов, подлежащих решению. Один из самых главных вопросов — выбор режима безопасности. Два основных режима безопасности — транспортный режим и режим сообщений.

Третий режим, в котором объединяется семантика двух основных режимов, — режим транспорта с учетными данными сообщений.

Режим безопасности определяет способ защиты сообщений, и каждый режим имеет преимущества и недостатки, которые описываются ниже. Дополнительные сведения задании режима безопасности см. в разделе Как задать режим безопасности.

Транспортный режим

Между сетевым и прикладным уровнями находится несколько уровней. Одним из таких уровней является транспортный уровень*,* который управляет передачей сообщений между конечными точками. В данном случае необходимо понимать только то, что WCF использует несколько транспортных протоколов, каждый из которых может защищать передачу сообщений. (Дополнительные сведения типах транспорта см. в разделе Транспорты в Windows Communication Foundation.)

Обычно используемым протоколом является протокол HTTP; другой применяемый протокол — TCP. Каждый из этих протоколов может защищать передачу сообщений с помощью механизма (или механизмов), ориентированного на конкретный протокол. Например, протокол HTTP защищается с помощью протокола SSL поверх HTTP, обычно называемого "HTTPS". Таким образом, если для обеспечения безопасности выбирается транспортный режим, используется механизм, определяемый протоколом. Например, если выбирается класс WSHttpBinding и в качестве его режима безопасности задается Transport, в качестве механизма безопасности выбирается протокол SSL поверх HTTP (HTTPS). Преимущество транспортного режима в том, что он более эффективен, чем режим сообщений, поскольку средства обеспечения безопасности интегрируются на относительно низком уровне. При использовании транспортного режима механизм безопасности должен быть реализован в соответствии со спецификацией транспорта, и, таким образом, сообщения могут безопасно передаваться только от точки к точке по транспортному каналу.

Режим сообщений

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

Транспорт с учетными данными сообщений

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

Задание типа учетных данных клиента и значения учетных данных

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

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

В случае создания службы, которая требует проверки подлинности клиента, выбор типа учетных данных клиента зависит от выбранных транспорта и режима. Например, при использовании транспорта HTTP и выборе транспортного режима возможны несколько вариантов выбора — Basic, Digest и другие. (Дополнительные сведения этих типах учетных данных см. в разделе Основные сведения о проверке подлинности HTTP.)

В случае создания службы в домене Windows, которая будет доступна только другим пользователям сети, проще всего использовать тип учетных данных клиента Windows. Однако может также потребоваться обеспечить службу сертификатом. Это показано в разделе Как задать значения учетных данных клиента.

Значения учетных данных

Значение учетных данных — это фактические учетные данные, используемые службой. После задания типа учетных данных может также потребоваться настроить службу с фактическими учетными данными. Если выбран тип Windows (и служба будет работать в домене Windows), фактическое значение учетных данных не задается.

Идентификация

В WCF термин идентификация имеет разные значения для сервера и клиента. Вкратце, при запуске службы идентификация назначается контексту безопасности после проверки подлинности. Чтобы просмотреть фактическую идентификацию, проверьте свойства WindowsIdentity и PrimaryIdentity класса ServiceSecurityContext. Дополнительные сведения см. в разделе Как анализировать контекст безопасности.

В отличие от этого, на клиенте идентификация используется для проверки службы. Во время разработки разработчик клиента может присвоить элементу <identity> значение, полученное от службы. Во время выполнения клиент проверяет значение элемента, сравнивая его с фактической идентификацией службы. В случае отрицательного результата проверки клиент завершает взаимодействие. Значением может быть имя участника-пользователя, если служба работает под удостоверением конкретного пользователя, или имя участника-службы, если служба работает под учетной записью компьютера. Дополнительные сведения см. в разделе Идентификация и проверка подлинности службы. Учетными данными может быть также сертификат или поле в сертификате, которое идентифицирует этот сертификат.

Уровни защиты

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

См. также

Поделиться через