Защита служб

безопасность службы 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, обращаться к которой имеют право только определенные пользователи. Дополнительные сведения об использовании олицетворения см. в разделе как олицетворять клиента в службе , а Делегирование и олицетворение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также раздел