ИНФОРМАЦИОННАЯ ЗАЩИТА СИСТЕМ НА ОСНОВЕ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ

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

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

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

Одним из основных стандартов на котором базируется взаимодействие сервисов в ESB является протокол обмена сообщениями SOAP. В качестве технологии обеспечения безопасности в протоколе SOAP используется стандарт WS-Security [3]. Этот стандарт предоставляет комплексную безопасность систем на основе SOA за счет используемых стандартов и спецификаций, что освобождает от процесса нахождения полного решения безопасности при применении WS-Security.

Контроль доступа на стороне сервиса поставщика предусматривает процесс аутентификации клиента [4]. Этот процесс необходим для доказательства подлинности сторон. Идентификация сервиса-потребителя обычно осуществляется с помощью сертификатов безопасности. В таком случае отсутствует востребованность в управлении паролями на стороне клиента. Общепринятой практикой является использование сертификата X.509, выданного доверенным центром сертификации. Такой сертификат содержит в себе ассоциированную с собой пару закрытого и открытого ключей и данные, идентифицирующие пользователя. Такой процесс аутентификации представлен на рисунке 1.

Рисунок 1. Двусторонний процесс аутентификации

Серверная сторона, получив подписанную информацию, с помощью открытого ключа может проверить подлинность клиента. В сервисах, подключенных к ESB, выполняется процесс взаимной (двусторонней) аутентификации, где сервис-поставщик должен предоставить свой собственный сертификат X.509, что позволяет клиенту проверить его подлинность и подтверждение подписей, сделанных этим сервисом, после чего, он должен предоставить копию своего договора WSDL (Web Services Description Language), который является стандартным требованием для обращения к веб-службе [2]. Предполагая, что клиент идентифицирует себя с помощью сертификата, клиенту также необходимо предоставить его копию доверенного в службу маркеров безопасности.

Для обеспечения целостности передаваемой информации в процессе транзакций, такой как защита от изменения и повреждения SOAP сообщения, необходимо использовать подписи. Встроенные процедуры подписей позволяют исключить подмену данных из заголовка и тела сообщения, пресекает возможность внедрить поддельный запрос от сервиса для получения данных. Они так же производят процедуру скрепления пространственно разделенных блоков данных одного SOAP-сообщения, что позволяет партнеру проверить на целостность как все сообщение, так и его отдельные блоки. Более того, для повышения безопасности целостности сервис-ориентированных системах так же необходимо подписывать ответы от серверной стороны. Для получения подписи используется криптографический алгоритм хеширования, при помощи которого рассчитываются контрольные суммы блоков данных передаваемых сообщений. Хеш-функция стойка к поиску прообраза, что не позволяет по известному значению хеша восстановить исходные данные. Кроме того, к хеш-функции применимо требования отсутствия коллизий. Для проверки на целостность данных, принимающая сторона еще раз выполняет расчет контрольной суммы, после чего производит сверку с полученным значением. В том случае, если значения совпали, то целостность блоков данных соблюдена, в противном случае данные были изменены. Такой подход предоставляет возможность проверить данные на целостность или несанкционированное изменение, но не позволяет определить то, как они были изменены. Процесс подписей базируется на взаимном формировании контрольных сумм как сервис-потребителем, так и сервис-поставщиком. Процесс подписи ограничивает передачу данных одинаковой формой представления, что влечет за собой такие процессы как нормализация XML-сообщений. Для подтверждения подлинности всего сообщения выполняется процесс хеширования значений хеш-функции блоков данных сообщения. Полученная контрольная  сумма, представляющая собой криптографическую связь между блоками, позволяет проверить на целостность сообщение в не зависимости от расположения самих блоков внутри него. Такая сумма позволяет обнаружить манипуляции с блоками. В процессе передачи данных контрольная сумма дополнительно защищается механизмом криптографического шифрования [1]. Кроме функции контроля целостности и уникальности, подпись предоставляет возможность идентификации отправителя сообщения, который представлен на рисунке 2.

Рисунок 2. Процесс предоставления данных отправителя сообщения

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

Последним требованием триады безопасности является конфиденциальность. Устранить хищение пароля во время передачи сообщения призвано шифрование токена с именем пользователя, которое представлено на рисунке 3.

Рисунок 3. Шифрование токена для имени пользователя в заголовке сообщения

В некоторых случаях достаточно применения криптографического протокола SSL, но необходимо учитывать, что возможность использования промежуточных точек невозможно, в таком случае, если установить связь между двумя конечными точками (сервисами), то использование ESB невозможно.

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

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

Список литературы:

1. Безопасность в сервис-ориентированных архитектурах.  [Электронный ресурс]. – Режим доступа. – URL: https://www.osp.ru/lan/2008/11/5712802/ (дата обращения: 12.04.18)
2. Понимание WS-Security. [Электронный ресурс]. – Режим доступа. – URL: http://www.vbnet.ru/articles/showarticle.aspx?id=144 (дата обращения: 19.04.18)
3. Текущая спецификация SOAP. [Электронный ресурс]. – Режим доступа. – URL: http://www.w3.org/tr/soap (дата обращения: 10.04.18)
4. WCF безопасности.  [Электронный ресурс]. – Режим доступа. – URL: http://www.w3ii.com/ru/wcf/wcf_security.html (дата обращения: 30.04.18)