Парадигма сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) порождает новый подход к распределенной обработки информации. Идея заключается в том, чтобы разделить классические монолитные приложения на отдельные компоненты и предложить функциональность приложений в виде бизнес-ориентированных сервисов. Указанные службы основываются на стандартах (WSDL, XML, а также на протоколе SOAP для коммуникации в сети), не зависят от реализации, вызываются по сети и могут использоваться сразу всеми приложениями. В принципах построения SOA подкупает то, что в результате возникает открытая архитектура со слабо связанными сервисами — именно так это называется на профессиональном жаргоне.

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

Как стало ясно, одна только защита периметра при помощи брандмауэров, маршрутизаторов и тому подобных мер не в состоянии удовлетворить потребности сервис-ориентированной парадигмы бизнеса: предприятия должны иметь возможность динамически строить и снова разрывать доверительные отношения — как в пределах компании, так и с партнерами и поставщиками. Это означает, что сервис-ориентированная архитектура нуждается в реализации гибкой модели обеспечения безопасности, где бы не было «жестко закрепленных» правил.

В традиционных архитектурах монолитные приложения создаются по большей части в виде «островков безопасности». Вся информация, необходимая клиенту для аутентификации в защищенной среде, создается внутри приложения, имеет значение для всего приложения и подлежит централизованному управлению. Это означает, что приложения выполняются в собственном контексте обеспечения безопасности. Подобную концепцию нельзя без изменений перенести на сервис-ориентированную архитектуру, где сервисы предоставляются без ограничений любому «потребителю» — пользователю, приложению или службе, так что разработчику не надо указывать, кто будет вызывать службу и пользоваться ею. Но это означает, что сервису по определению нельзя приписать никакой собственный контекст обеспечения безопасности, который действителен в рамках слабой связи.

Взаимодействие в сервис-ориентированной архитектуре производится путем обмена сообщениями. Для их передачи пригодны различные протоколы, например общая архитектура посредника запросов к объектам (Common Object Request Broker Architecture, CORBA), удаленный вызов метода (Remote Method Invocation, RMI) и др., однако в качестве эффективных технологий зарекомендовали себя сервисы Web и простой протокол доступа к объектам (Simple Object Access Protocol, SOAP) на базе HTTP. Большая часть приложений при передаче данных пользуется протоколом HTTPS и возлагает шифрование на транспортный уровень. Самую непритязательную защиту от рисков для HTTP предоставляет протокол безопасных соединений (Secure Sockets Layer, SSL) или его преемник — протокол защиты транспортного уровня (Transport Layer Security, TLS). Обеспечения безопасности такого вида на сетевом уровне вполне достаточно для двухточечных соединений.

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

В этой ситуации на помощь приходит спецификация служб Web для обеспечения безопасности (Web Services Security, WSS), предложенная организацией по продвижению стандартов для структурированной информации (Organization for the Advancement of Structured Information Standards, OASIS). Они обеспечивают снабжение протокола SOAP расширенной информацией о безопасности. В качестве дополнений к заголовкам SOAP в стандарте определяются метки безопасности. Такая метка может содержать пары ключей, информацию об аутентификации, включая подпись, и авторизации, а также метку о времени, и сопровождает сообщение от начала и до конца его маршрута (см. Рисунок 1). Кроме того, возможно использование дополнительных стандартов, в частности инфраструктуры открытых ключей (Public Key Infrastructure, PKI), а также шифрования сервисов Web (Web Service, WS), подписей сервисов Web и языка разметки утверждений безопасности (Security Assertion Markup Language, SAML); они помогают защитить содержание сообщений на всем протяжении маршрута. Компоненты безопасности сервисов Web создают хороший фундамент для этого, однако некоторые из них еще не до конца специфицированы.

Рисунок 1. Заголовок SOAP может быть дополнен меткой безопасности, которая содержит подпись и информацию для проведения аутентификации, авторизации и шифрования.

Так называемые «компонентные службы» должны обращаться к различным серверным системам, каждая из которых пользуется собственными мерами обеспечения безопасности, а также механизмами идентификации и директивами безопасности. Теоретически в сервис-ориентированной архитектуре это означает, что сервис должен проходить отдельную аутентификацию на каждой вовлеченной в процесс серверной системе. Создание и, соответственно, реализация каждый раз новых контекстов обеспечения безопасности, согласование их с другими, уже существующими, практически невозможны. Решением может стать управление доступом и идентификацией по принципу однократной регистрации (Single Sign-On, SSO). Такой подход предполагает, что при регистрации потребителя услуги создается контекст обеспечения безопасности и включается в заголовок SOAP. Тогда контекст становится доступным при аутентификации на разных серверных системах.

Защита сервис-ориентированной архитектуры в рамках предприятия ведет к трансформации всей структуры обеспечения безопасности. Такой компонентный сервис безопасности становится составной частью сервисной шины предприятия (Enterprise Service Bus, ESB), которая в качестве центрального компонента инфраструктуры сервис-ориентированной среды наряду с коммуникацией, маршрутизацией и прочими службами обеспечения взаимодействия базовых задач координирует и функционирование указанного сервиса.

Служба обеспечения безопасности состоит из различных отдельных компонентов, предназначенных, например, для аутентификации, шифрования, блока соблюдения правил (Policy Enforcement Point, PEP), а также блока принятия решений о правилах (Policy Decision Point, PDP) для авторизации. Центральная роль отводится службе каталогов упрощенного протокола доступа к каталогам (Lightweight Directory Access Protocol, LDAP), где хранится вся информация о сотрудниках, других подразделах структуры предприятия и данные о безопасности, в частности сертификаты и правила. При помощи правил служба обеспечения безопасности должна быть сконфигурирована таким образом, чтобы она могла взаимодействовать с решениями для управления доступом и идентификацией, службами обеспечения безопасности от третьих сторон и всеми прочими службами. Наконец, саму сервисную шину предприятия, рекомендуется защитить через интерфейс администрирования, который отвечает за мониторинг и регистрацию.

Если необходимо сделать сервисы Web доступными извне, к примеру для воспроизведения бизнес-процессов между предприятиями (Business-To-Business, B2B), то понадобится система так называемого федеративного управления идентификацией, которая дополнительно включает в себя и службу идентификации (см. Рисунок 2). При вызове сервиса Web внешний потребитель должен снова пройти аутентификацию, а это требует дополнительной функциональности в рамках одной службы с тем, чтобы ей был понятен внешний контекст обеспечения безопасности и была доступна возможность сопоставления с внешней инфраструктурой обеспечения безопасности. Однако непротиворечивое доверительное управление в случае длинных цепочек вызовов довольно проблематично, поскольку каждый партнер, как правило, обладает собственной инфраструктурой обеспечения безопасности.

Рисунок 2. Процесс федеративного управления идентификацией можно разбить на отдельные этапы.

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

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

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

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

Мердад Джалали-Сохи — старший консультант и эксперт в области безопасности сервис-ориентированных архитектур из компании Logica CMG. Хауке Крегер — менеджер по теме SOA компании Logica CMG.

© AWi Verlag

Совместное управление идентификацией

Через службу выполнения правил (Policy Enforcement Point, PEP), «охраняющую» доступ к сервису Web, пользователь обращается к службе Web. Для этого он нуждается в подтверждающей его идентичность метке безопасности (Security Token, SCT), которую получает у поставщика системы идентификации. Служба выполнения правил сервиса Web извлекает метку безопасности и передает ее службе принятия решений о правилах (Policy Decision Point, PDP). Та, в свою очередь, проверяет правильность метки и запрашивает у LDAP соответствующие правила. Служба принятия решений динамически формулирует права и отправляет их службе выполнения правил. При наличии метки безопасности можно в течение некоторого периода времени обращаться к нескольким сервисам Web определенного поставщика без необходимости повторной аутентификации. Срок действия метки обычно ограничен, и по окончании его пользователю придется снова затребовать метку безопасности.

Стандарты обеспечения безопасности сервисов Web

  • «Обеспечение безопасности сервисов Web» (Web Services Security, WSS) подразумевает целый ряд спецификаций, которые служат для расширения SOAP и образуют базу для прочих модулей WSS. Для защиты приложения от рисков могут использоваться один или несколько модулей.
  • «Авторизация сервисов Web» определяет, как специфицировать и управлять данными об авторизации. С помощью так называемых «заявок» (claim) в рамках метки безопасности сервис Web проверяет, имеет ли запрос право на вызов требуемой службы.
  • «Объединение сервисов Web» описывает, как управлять доверительными отношениями в гетерогенной среде обеспечения безопасности, базирующейся на сервисах Web. Важнейшим компонентом авляется модуль, получивший название «федеративная идентичность». Это касается, к примеру, клиента, подтверждающего свою идентичность при помощи сертификата Х.509, но нуждающегося в сервисе Web, который в качестве носителя аутентификации принимает метку Kerberos.
  • «Правила сервисов Web» определяют, в каком виде поставщики сервисов Web задают правила обеспечения безопасности для пользования своими службами. Это могут быть метки, алгоритмы шифрования, директивы для защиты сферы личных интересов или цифровая подпись.
  • «Конфиденциальная коммуникация с сервисами Web» регламентирует порядок создания контекста обеспечения безопасности при помощи метки для защиты отдельных сообщений от рисков. В одном контексте обеспечения безопасности можно обмениваться множеством сообщений.
  • «Доверие к сервису Web» описывает защиту от рисков при коммуникации между двумя партнерами путем сравнения атрибутов, связанных с обеспечением безопасности. Это отображается при помощи сервиса Web, который передает метку безопасности от одного партнера по коммуникации к другому.

Предложения по обеспечению безопасности от поставщиков компонентов SOA.