Советы и рекомендации по web-сервисам, часть 11: Безопасность web-сервисов, часть 1

Спецификация WS-Security

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

Холт Адамс, старший ИТ-архитектор, консультант, IBM jStart

Холт Адамс (Holt Adams) — ведущий ИТ-архитектор в группе перспективных технологий подразделения IBM Software. В настоящее время занимается поддержкой программы IBM jStart Program и группы Customer Innovation Team. Его квалификация позволяет ему выступать одновременно в роли архитектора решений и менеджера по взаимодействию с клиентами, эффективно поддерживая внедрение заказчиками новых интернет-технологий. Он является опытным специалистом-практиком в технических и деловых аспектах сотрудничества с заказчиками — от выявления потенциальных клиентов и оценки бизнес-возможностей до управления требованиями, разработки архитектуры решений, проектирования решений и согласования контрактов. Как ИТ-архитектор, Холт преобразует бизнес-потребности клиентов в ИТ-требования, которые можно реализовать с помощью новейших информационных технологий в форме самых современных решений. В рамках программы jStart и других связанных с сервисами проектов он работал с беспроводными и мобильными компьютерными технологиями, интернет-инфраструктурой, Java/J2EE, XML, Web-сервисами и SOA, ПО с открытым исходным кодом, Web 2.0, социальными сетями и корпоративными mashup-технологиями.



26.03.2004

Эта статья разбита на две части. Первая посвящена функциям WS-Security, взаимосвязи между бизнес-участниками и механизмам реализации возможностей WS-Security. Во второй будут описаны поддержка WS-Security сервером IBM® WebSphere® Application Server, бизнес-требования заказчиков и их опыт использования WS-Security и других технологий безопасности.

Введение

Последствия использования технологий безопасности

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

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

Триада безопасности

Аутентификация призвана гарантировать, что стороны бизнес-транзакции являются теми, кем они себя объявляют, т.е. доказать подлинность сторон. Такое доказательство может быть затребовано различными способами. Простой вариант — предоставление идентификатора пользователя и пароля. Более сложный вариант — использование сертификата X.509, выданного доверенным центром сертификации (например, Verisign). Сертификат содержит идентификационные учетные данные и ассоциированную с ними пару из закрытого и открытого ключей. Доказательство подлинности, предоставляемое стороной, включает в себя сам сертификат и отдельную порцию информации, содержащую цифровую подпись с использованием закрытого ключа сертификата. Проверив подписанную информацию с помощью открытого ключа, ассоциированного с сертификатом другой стороны, принимающая сторона может аутентифицировать отправителя как владельца сертификата, таким образом убедившись в его подлинности. Аутентификация сторонами друг друга называется взаимной аутентификацией; такая аутентификация часто выполняется между потребителем и поставщиком web-сервиса.

Чтобы обеспечить целостность бизнес-информации (которой стороны обмениваются в транзакции) и гарантировать, что содержимое сообщения не будет изменено или повреждено во время его передачи через Интернет, данные подписывают цифровой подписью с использованием ключей безопасности. Это второе требование триады безопасности. Общепринятой практикой является использование закрытого ключа сертификата X.509 отправителя для подписания цифровой подписью SOAP-тела запроса web-сервиса. Аналогичным образом можно подписывать блоки SOAP-заголовка запроса, чтобы гарантировать целостность передаваемой в транзакции информации, выходящей за рамки актуального бизнес-контекста (например, идентификаторы сообщения, маркеры доступа). Кроме того, для обеспечения целостности данных цифровой подписью можно подписывать ответы web-сервисов.

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

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

Эта статья, входящая в серию "Советы и рекомендации по web-сервисам", в основном посвящена различным способам использования WS-Security в ваших решениях и их ожидаемому воздействию на производительность.


Общая модель WS-Security

Спецификация WS-Security находится на завершающей стадии утверждения в качестве стандарта OASIS и предоставляет механизмы для выполнения всех трех требований триады безопасности между конечными точками приложения. С помощью WS-Security можно выборочно выполнять каждое из требований триады безопасности, реализуя их в решении порознь или вместе.

В данной статье приложение, использующее сервисы другого приложения, называется приложением-потребителем (Consuming Application). Приложение, предоставляющее сервисы, называется поставщиком сервисов (Service Provider).Рисунок 1 иллюстрирует эту связь и является основой для значительной части дальнейшего обсуждения.

Рисунок 1. Системная среда
Рисунок 1. Системная среда

В описанном и проиллюстрированном в следующих разделах сценарии до вызова сервисов поставщика необходимо обменяться с клиентом открытым ключом сертификата X.509 и настроить его использование в среде исполнения клиента. Как приложение-потребитель, так и поставщик сервисов должны импортировать в локальные хранилища корневой сертификат центра сертификации (например, Verisign), который выдал сертификаты сторонам. Приложение-потребитель будет иметь в хранилище ключей корневой сертификат сертификата поставщика сервисов. В свою очередь, хранилище ключей поставщика сервисов будет иметь корневой сертификат сертификата приложения-потребителя. Это обязательное условие, позволяющее проверить цифровые подписи индивидуальных сертификатов, которые передаются в виде двоичных маркеров доступа в SOAP-сообщениях.

В полную реализацию всех трех требований безопасности входят:

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

Информация об XML-шифровании WS-Security

Шифрование данных на основе спецификации WS-Security и спецификации XML-шифрования включает в себя:

  • Двухфазный процесс, использующий как симметричные, так и асимметричные алгоритмы.
  • Общий ключ, который используется для шифрования/дешифрования данных сообщения с помощью симметричного алгоритма, например Triple DES. Симметричные алгоритмы очень эффективны и работают с единым ключом для шифрования и дешифрования. В реализациях WS-Security используется ключ, генерируемый случайным образом. После шифрования данных сообщения ключ вставляется в сообщение. Обратите внимание, что ключ также шифруется, как описано ниже.
  • Передачу в SOAP-сообщении общего ключа, шифруемого и дешифруемого с помощью асимметричных алгоритмов, например RSA-V1.5. Шифрование общего ключа осуществляется иначе, чем шифрование данных сообщения: с помощью алгоритма, который использует пару ключей — закрытый и открытый. Сертификат X.509 имеет два ключа: один является личным (закрытым) ключом владельца сертификата, а второй используется совместно с другими участниками бизнеса. Симметричные алгоритмы более эффективны, чем асимметричные, однако они требуют от сторон умелого обращения с общими ключами, а также имеют внутренние риски безопасности, обусловленные возможностью их попадания в руки лиц, не относящихся к вашей организации или к партнерам по бизнесу. Таким образом, используя только асимметричные алгоритмы для случайного ключа, WS-Security обеспечивает относительно эффективное и простое в управлении решение. Во второй части статьи я расскажу, почему я сделал оговорку относительно.

Дополнительная информация по XML-шифрованию приведена в разделе Ресурсы.


Реальный сценарий WS-Security

Описанный ниже сценарий является одним из многих, которые можно реализовать при помощи WS-Security. Он использует сертификаты X.509, что является распространенной практикой в решениях заказчиков, которые я опишу во второй части статьи.

Обработка запроса web-сервиса приложением-потребителем

Как правило, приложение-потребитель имеет прокси-сервис или компонент-заглушку JAX-RPC, создаваемые в интегрированной среде разработки (например, WebSphere Studio Application Developer) с использованием WSDL поставщика сервиса. После вызова web-сервиса перед отправкой запроса прокси или среда исполнения SOAP на клиентской системе выполняют функции WS-Security.

Сначала SOAP-сообщение подписывается цифровой подписью. Среда исполнения SOAP обращается к хранилищу ключей и по мере необходимости извлекает ключи защиты и сертификаты. В зависимости от предоставляемой вашей средой поддержки WS-Security можно подписывать только тело SOAP-сообщения или отдельные его элементы. Кроме того, можно подписывать блоки SOAP-заголовка. Подписание выполняется с использованием закрытого ключа сертификата X.509 приложения-потребителя. После подписания сообщения сертификат X.509 включается в SOAP-заголовок в виде двоичного маркера доступа. Сообщение шифруется при помощи симметричного алгоритма с общим ключом. Ключ, используемый для шифрования данных, шифруется при помощи асимметричного алгоритма с открытым ключом, ассоциированным с сертификатом X.509 поставщика сервиса. После шифрования сообщения и общего ключа в SOAP-заголовок включается ссылка на сертификат X.509 поставщика сервиса, которому направляется запрос. Это делается в связи с тем, что поставщик сервиса может использовать несколько сертификатов.

Рисунок 2. Обработка запроса приложением-потребителем при помощи WS-Security
Рисунок 2. Обработка запроса приложением-потребителем при помощи WS-Security

Обработка запроса web-сервиса поставщиком сервисов

После получения поставщиком сервисов запроса web-сервиса этот запрос направляется в механизм обработки SOAP (среда исполнения SOAP) на основе URL запроса (опубликованная точка доступа к сервису). Данные сообщения и общий ключ передаются в запросе в зашифрованном виде, поэтому первым шагом является идентификация сертификата X.509, указанного в заголовке SOAP, и извлечение его закрытого ключа из хранилища ключей. После получения закрытого ключа с помощью асимметричного алгоритма дешифруется общий ключ. После дешифрования общего ключа данные сообщения дешифруются с помощью симметричного алгоритма. Теперь, когда все сообщение дешифровано, извлекается открытый ключ сертификата X.509, переданного в SOAP-заголовке. Цифровая подпись сообщения выполнена с использованием открытого ключа приложения-потребителя. Если проверка подписи проходит успешно, среда исполнения SOAP поставщика сервисов подтверждает целостность сообщения и гарантирует, что сообщение действительно подписано приложением-потребителем. Этот процесс также аутентифицирует источник (отправителя) сообщения, так как только отправитель, являясь владельцем сертификата, имеет доступ к закрытому ключу, используемому при подписании сообщения. После дешифрования сообщения и проверки подписи среда исполнения SOAP вызывает реализацию web-сервиса.

Рисунок 3. Обработка запроса поставщиком сервисов при помощи WS-Security
Рисунок 3. Обработка запроса поставщиком сервисов при помощи WS-Security

Обработка ответа web-сервиса поставщиком сервисов

После выполнения бизнес-логики реализации сервиса и получения ответа те же операции WS-Security выполняются для ответного сообщения web-сервиса. Однако роли пар ключей X.509 для цифровой подписи и шифрования меняются местами. Среда исполнения SOAP поставщика сервисов подписывает сообщение цифровой подписью с использованием закрытого ключа своего сертификата X.509. Сертификат включается в SOAP-сообщение, а сообщение шифруется с использованием общего ключа. Ключом, используемым для шифрования данных, может быть тот же ключ, который передается в первоначальном запросе, или иной, сгенерированный случайным образом ключ, что более типично. Шифрование общего ключа осуществляется с использованием открытого ключа сертификата, который был передан в запросе; таким образом, только отправитель запроса, имеющий доступ к закрытому ключу сертификата, может дешифровать сообщение. После подписания и шифрования сообщения среда исполнения SOAP поставщика сервисов отправляет ответ приложению-потребителю.

Рисунок 4. Обработка ответа поставщиком сервисов при помощи WS-Security
Рисунок 4. Обработка ответа поставщиком сервисов при помощи WS-Security

Обработка ответа поставщика сервисов приложением-потребителем

Обработка приложением-потребителем WS-Security ответа web-сервиса очень похожа на обработку запроса поставщиком сервисов.

Приложение-потребитель получает ответ web-сервиса с ответом, направленным в механизм обработки SOAP (среда исполнения SOAP) с учетом первоначального HTTP-сеанса. Данные сообщения и общий ключ передаются в ответ в зашифрованном виде. Таким образом, первым шагом является получение закрытого ключа сертификата, ассоциированного с соответствующим запросом, для дешифрования ключа с использованием асимметричного алгоритма. После дешифрования общего ключа данные сообщения дешифруются с помощью симметричного алгоритма. После дешифрования всего сообщения сертификат X.509, переданный в SOAP-заголовке, используется для извлечения его открытого ключа. Цифровая подпись сообщения ответа создается с использованием открытого ключа поставщика сервисов. Если проверка подписи проходит успешно, среда исполнения SOAP приложения-потребителя подтверждает целостность сообщения и гарантирует, что сообщение действительно подписано поставщиком сервисов. Этот процесс также аутентифицирует источник (отправителя) сообщения, так как только отправитель, являясь владельцем сертификата, имеет доступ к закрытому ключу, используемому при подписании сообщения. После дешифрования сообщения и проверки подписи среда исполнения SOAP передает ответ приложению-потребителю.

Рисунок 5. Обработка ответа приложением-потребителем при помощи WS-Security
Рисунок 5. Обработка ответа приложением-потребителем при помощи WS-Security

Заключение

Спецификация WS-Security очень сложна по внутреннему устройству и может использоваться в самых разных сценариях. Пример, описанный выше, отражает многие аспекты проектов, уже реализованных заказчиками. Этот сценарий, полностью или частично, реализовывался у заказчиков на платформе WebSphere Application Server с учетом политик безопасности, инфраструктуры безопасности и бизнес-требований. Этот вопрос будет обсуждаться во второй части статьи.

Важно отметить, что WebSphere Application Server поддерживает WS-Security в рамках декларативной модели. Это позволяет легко реализовать возможности WS-Security с уже разработанными и протестированными web-сервисами на этапе развертывания. В результате ИТ-архитекторам и ИТ-специалистам не приходится думать о сложностях цифровых подписей или шифрования XML.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=777496
ArticleTitle=Советы и рекомендации по web-сервисам, часть 11: Безопасность web-сервисов, часть 1
publish-date=03262004