Защита служб

  • Статья

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

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

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

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

Механизмы безопасности 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 . Дополнительные сведения см. в разделе "Практическое руководство. Изучение контекста безопасности".

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

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

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

См. также