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

Обеспечение безопасности служб

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

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

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

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

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

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

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

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

Режим транспорта

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

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

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

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

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

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

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

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

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

Если вы создаете службу, требующую проверки подлинности клиента, выбор типа учетных данных клиента зависит от выбранного транспорта и режима. Например, при использовании транспорта HTTP и выбора режима транспорта можно выбрать несколько вариантов, таких как "Базовый", "Дайджест" и "Другие". (Дополнительные сведения об этих типах учетных данных см. в разделе "Общие сведения о проверке подлинности HTTP".)

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

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

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

Идентичность

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

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

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

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

См. также

  • Last updated on