Web Services Security

ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА

ЦЕНТЪР МАГИСТЪРСКО ОБУЧЕНИЕ

Реферат по дисциплината

“Безопасност и защита”

на тема

“Сигурност и защита при уеб услугите”

Изготвил: Проверили:

Невена Георгиева Господинова,

спец: Информатика, курс: 5,

ФН:11578, гр.61

доц. д-р С. Дражев

ас. Р. Начева

Варна, 2014

Сигурност и защита при уеб услугите

2

Невена Господинова, ФН: 11578

Съдържание

1. Въведение .................................................................................................. 3

2. Същност на уеб услугите ........................................................................ 4

Архитектура на уеб услугите ................................................................... 5

Протоколен стек на уеб услугите ............................................................ 7

3. Стандарти и технологии за защита на уеб услуги ............................ 8

Основни принципи .................................................................................... 8

Модели за защита .................................................................................... 10

Прокси услуги.......................................................................................... 14

4. Заключение ............................................................................................. 17

5. Използвана литература ........................................................................ 18


3


1. Въведение

В днешно време за всяка организация е важно осигуряването на

възможност за безпроблемна обмяна на информация между вътрешни

бизнес единици, клиенти и партньори. За целта се използват редица

разнообразни приложения, съхраняващи данни по различни начини, в

резултат на което комуникацията помежду им не е продуктивна. Поради

това все повече организации разработват и внедряват уеб услуги за

реализиране на своите бизнес модели. По този начин се решават голяма

част от проблемите, свързани със зависимостта на приложенията от

платформите, на които се изпълняват. Ясно е, че при комуникацията

между различните организации e от особена важност гарантирането на

сигурността и защитата на предаваните данни.

Целта на настоящия реферат е да се изследват и сравнят някои

стандарти и технологии за защита при уеб услугите. За постигане на целта

е необходимо да се решат следните задачи:

Да се разгледат основните същностни аспекти на уеб услугите и

тяхната архитектура;

Да се представят най-често използваните методи за защита,

приложими към уеб услуги, респективно техните особености,

силни и слаби страни.

Преди да пристъпим към разглеждане на някои специфични аспекти

на сигурността при уеб услугите, е необходимо да изясним какво точно

представляват самите уеб услуги по своята същност.


4


2. Същност на уеб услугите

Уеб услугите представляват концепция, възникнала в края на

миналия век. В контекста на информационните технологии понятието „уеб

услуга” и „услуга” често се използва като синоними1. Разглеждайки някои

от съществуващите дефиниции за уеб услугите, можем да забележим, че те

варират от общи до много детайлни.

Често под „уеб услуга” се има предвид приложение, до което може

да се осъществи достъп от други приложения в мрежата2. По-детайлно е

определението, дадено от World Wide Web консорциума W3C, според

което уеб услугата е софтуерно приложение, идентифицирано с URI3,

чиито публични интерфейси и връзки могат да бъдат дефинирани и

описвани като се използва XML. Нейната дефиниция може да бъде

откривана от други софтуерни системи. Тези системи могат при това да

взаимодействат с уеб услугата по начин, зависещ от нейната дефиниция,

като се използват XML-базирани съобщения, пренасяни чрез Интернет-

базирани протоколи4. В това определение се подчертава, че услугите

трябва да могат да бъдат дефинирани и описвани, за да могат да бъдат

използвани от други системи. Обръща се внимание и на важната роля на

стандарта XML при обмяната на съобщения между приложенията.

Може да се обобщи, че уеб услугите играят ролята на стандартни

интерфейси между приложенията. Те представляват ефективно откъм

разходи решение за обединяване на информация, разпределена между

различни приложения.

Всяка уеб услуга се идентифицира с URI и има интерфейс, който

описва начина за взаимодействие с нея. Характерно е, че уеб услугите

1 Филипов, Ф. Някои въпроси на представянето чрез UML на механизмите за обмен на данни при уеб

услугите. Известия, ИУ-Варна, 1-2013. 2 Alonso, G and Others. Web Services: Concepts, Architectures and Applications, Springer, Heidelberg, 2004.

3 Uniform Resource Identifier – символен низ, използван за идентифициране на уеб ресурс.

4 Изисквания при уеб услугите. http://www.w3.org/tr/wsa-reqs/ (февруари, 2014).


5


нямат графичен потребителски интерфейс. Основната тяхна идея е да

предоставят данни, функции и бизнес логика по платформено независим

начин, което се постига посредством използването на стандарта XML.

Следва да се запознаем с архитектурата на уеб услугите и по-специално с

основните ѝ компоненти и взаимодействия между тях.

Архитектура на уеб услугите

За всяка уеб услуга е характерно, че има имплементация и описание.

Описанието съдържа детайли за интерфейса и имплементацията на уеб

услугата. Предназначението на описанието е да укаже форматите на

съобщенията, типовете данни и транспортните протоколи, които трябва да

бъдат използвани от доставчика и клиента. Описанието на уеб услугата е

написано на езика WSDL5 и може да съдържа метаданни, за да стане по-

лесно нейното откриване, респективно използване. В описанието се

дефинират местата в мрежата, където доставчикът може да бъде „извикан”,

както и начинът, по който ще се обменят съобщения. Можем да обобщим,

че описанието указва начина, по който трябва да се взаимодейства с уеб

услугата.

Архитектурата на уеб услугите (фиг. 1) се състои от следните три

компонента6:

Доставчик. Този компонент представлява платформата, която

осигурява достъп до услугата, или средата, в която се изпълнява

услугата.

Клиент. Това е приложение, което търси дадена услуга и

инициира взаимодействие с нея. Ролята на клиент може да се

изпълнява от браузър или от друга уеб услуга.

5 Web Services Description Language.

6 Архитектура на уеб услугите. http://www.w3.org/TR/ws-arch/ (февруари, 2014).


6


Регистър. Този компонент представлява мястото, където

доставчиците на уеб услуги публикуват описанията на услугите.

Тук търсещите приложения намират услугите.

Фиг. 1. Архитектура на уеб услугите - компоненти и взаимодействия7

За взаимодействие между компонентите на архитектурата се

използват три типа оператори – свързване (Bind), публикуване (Publish) и

намиране (Find).

Свързването е отношение между клиент и доставчик на услуги.

Желаещият да взаимодейства с услугата използва нейното описание, за да

я открие, съответно да се свърже с нея. За свързване се използват

протоколите XML и SOAP.

Ясно е, че за да бъде достъпна една уеб услуга, тя трябва да може да

бъде безпроблемно намирана от търсещите системи. Публикуването е

оператор, чрез който доставчикът публикува описанието на услугата в

предназначения за това регистър. То се извършва посредством езиците

WSDL и UDDI.

Чрез оператора за намиране клиентът взаимодейства с UDDI

регистъра, за да намери описанието на търсената услуга. Тук отново се

използват WSDL и UDDI.

7 Роли и взаимодействия в WSA. http://www.ibm.com/developerworks/library/w-ovr/ (март, 2014).


7


Протоколен стек на уеб услугите

Както вече споменахме, концепцията за уеб услугите се свързва с

набор от Интернет протоколи и стандарти за обмен на съобщения, които

участват в изграждането на услугите. Протоколният стек (фиг. 2) описва

различните слоеве или правила, използвани за проектиране, откриване и

имплементация на уеб услугите. Основните подсистеми8 на протоколния

стек са транспортен слой, слой за XML съобщения, слой за описание и

слой за откриване.

Фиг. 2. Протоколен стек на уеб услугите 9

Транспортният слой служи за транспортиране на XML съобщения

между различните приложения. Най-често използван на това ниво е

протоколът HTTP, като понякога се използват SMTP и FTP.

Слоят за XML съобщения се базира на XML и SOAP – стандарти,

широко използвани при уеб услугите. Предназначението на втория слой е

да кодира съобщенията на езика XML, така че да са разбираеми за клиента

и доставчика на услугата.

8 Протоколен стек на уеб услугите. http://www.tutorialspoint.com/webservices/web_services_architecture.htm

(февруари, 2014). 9Основни слоеве на протоколния стек на уеб услугите.

http://docs.embarcadero.com/products/rad_studio/radstudio2007/RS2007_helpupdates/HUpdate4/EN/html/devn

et/webservicesprotocol_xml.html (март, 2014).


8


Чрез слоя за описание се дава възможност да се специфицира

публичният интерфейс на услугата. Този слой съдържа информация както

за наличните функции, типовете данни и адреса на услугата, така и за това

как следва да се осъществява свързването с нея. За описание на услугата се

използва WSDL. Възможно е комбинирането му със SOAP.

Слоят за откриване е последният слой на протоколния стек.

Неговото предназначение е осигуряването на единно място, където да се

публикуват и откриват уеб услуги. За тази цел се използва протоколът

UDDI.

След като се запознахме с основните подсистеми на протоколния

стек на уеб услугите, следва да разгледаме основните стандарти и

технологии, използвани за защита на тези приложения.

3. Стандарти и технологии за защита на уеб услуги

Все повече организации използват уеб услуги за реализиране на

своите бизнес модели10

. Ясно е, че с увеличаване използването на тези

приложения нараства и необходимостта от безопасност и защита на

данните, които се предават чрез тях.

Основни принципи

Както вече стана ясно, уеб услугите са приложения, които могат да

бъдат динамично откривани и извиквани чрез изпращане на XML

съобщения по стандартни транспортни протоколи, например HTTP.

Известно е, че HTTP може да бъде уязвен от множество възможни атаки в

сигурността. По този начин сигурността и защитата на предаваните данни

при използване на уеб услугите също се поставя под въпрос. В този смисъл

10

Иванова, Е. и др. Съвременни информационни решения на web услуги в глобални мрежи в интерес на

сигурността. Научна поддръжка на трансформацията в сектора за сигурност. София, 2006.


9


някои от потенциалните проблеми, които могат да възникнат във връзка

със сигурността на уеб услугите, са:

Опит за извикване на услугата от потребител с неизяснена

автентикация;

Опит за използване на услугата от потребител с неизяснена

автентикация и/или без необходимите права;

Възможно е XML съобщението да бъде модифицирано от хакери,

като по този начин получателят ще го получи във вид, различен от

първоначалния.

Основните принципи, свързани със защитата и сигурността на

информацията, които важат на практика за повечето софтуерни

приложения, са11

:

Конфиденциалност. Често необходимата информация не трябва

да бъде достъпна за външни, а само за оторизирани лица. Това

налага наличието на метод за ограничаване на достъпа12

;

Цялост (интегритет). Позволение за промяна/изтриване на

данните трябва да имат само оторизирани лица. При това при

изпращане/получаване на съобщение трябва да сме сигурни, че

получените данните не са претърпели промяна;

Достъпност. Необходимо е да бъде осигурен достъп до данните

за лицата, за които е предназначена информацията.

Тъй като уеб услугите по своята същност представляват софтуерни

приложения, пред тях се поставят същите цели за защита на

информацията.

Основните принципи за сигурно програмиране могат да се обобщят

по следния начин:

11

Принципи на сигурността. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/security-

principles.html (април, 2014). 12

Access Control.


10


Сигурност на всеки слой. Програмистът трябва да осъзнае

цялостната картина. Необходимо е той да знае как точно

комуникира със слоевете под и над него и да предвиди

сигурността при всяка от тези комуникации, както и ефектите от

нея.

Минимизация на привилегиите. Необходимо е да бъдат

задавани само минималните привилегии, достатъчни на

конкретния потребител за работа с приложението. В противен

случай могат да възникнат множество проблеми, свързани със

сигурността.

Пълна валидация на входните данни. Ако приложението не

проверява валидността и безопасността на входните данни, то

това почти сигурно води до проблеми.

За защита на информационни услуги се използват следните три

основни модела: защита на мрежово ниво, защита на транспортно ниво,

защита на ниво съобщения. Следва да разгледаме поотделно всеки един от

тези модели.

Модели за защита

Защитата на мрежово ниво обикновено се прилага с цел да се

осигури сигурен трафик за всички приложения или транспортни протоколи

от по-горните слоеве. При това не трябва да има възможност

приложенията да бъдат модифицирани, тъй като те комуникират с

транспортния слой над тях.

IPSec13

протоколите могат да осигурят контрол, автентикация,

цялост на данните и поверителност за всеки IP пакет между два мрежови

сегмента. IPSec може да се използва между хостове, рутер и хост или два

13

IP Security Protocol.


11


рутера. За използването на IPSec не е необходима промяна нито в

мрежовия хардуер, нито в приложенията или протоколите от горните

слоеве.

Защитата на транспортно ниво се прилага с цел осигуряване на

сигурност при междупроцесорни комуникации между отделни хостове.

Повечето схеми са проектирани така, че да подсигуряват стабилна и

сигурна TCP комуникация. За защита на това ниво е необходима промяна в

самото приложение. В този модел основно място заемат Secure Sockets

Layer (SSL) и Transport Layer Security (TLS).

Протоколът SSL е създаден от Netscape и се прилага за защита на

приложения на транспортно ниво. Той работи като използва криптиране с

частен ключ, при което ключът се предава по „надеждна” SSL връзка.

Протоколът осигурява функционалност за защита на данните, включваща

автентикация, цялост и конфиденциалност.

TLS е стандарт, предложен от IETF и базиран на SSL. Той също

служи за защита на приложенията на транспортно ниво. Характерна

особеност е, че двата протокола не са съвместими.

Защитата на ниво съобщения представлява защита на ниво

приложен слой. Тя е сигурност от вид „point-to-point” и се прилага при

комуникация през мрежата между приложения, работещи на различни

хостове. Тук няма значение какъв е транспортният механизъм на по-

високото ниво. На този слой могат да бъдат осигурени цялост и

конфиденциалност – приложението само контролира същността на

предаването на данни.

Преди да разгледаме конкретните спецификации, които се прилагат

за защита на ниво съобщения, е необходимо да се запознаем със същността

и особеностите на съобщенията, предавани между уеб услугите.


12


Известно е, че услугите комуникират помежду си, използвайки

стандарта SOAP. Предназначението му е обмяна на структурирана

информация в децентрализирана, разпределена среда14

. Данните, които се

предават между уеб услугите, са в XML формат. Това позволява да се

предава както символна, така и двоична информация.

Тъй като SOAP е XML-базиран, то той е на практика платформено

независим и притежава гъвкава структура. Това позволява съвместното му

използване с разнообразни транспортни протоколи, като например HTTP,

SMTP и др. По този начин съобщенията могат да се приспособят към

изискванията на разпределената среда от гледна точка на безопасност и

надеждност. Структурата на SOAP съобщенията (фиг. 3) се състои от три

основни елемента: плик (Envelope), заглавна част (Header) и тяло (Body).

Фиг. 3. Структура на SOAP съобщение

SOAP Envelope е задължителен елемент на всяко SOAP съобщение.

Той изпълнява функцията на плик, защото съдържа в себе си всички други

елементи на съобщението. SOAP Header представлява заглавната част на

съобщението. Този незадължителен елемент може да съдържа дъщерни

елементи – заглавни блокове, които предават метаданни, свързани с

безопасността, маршрутизацията и надеждността на предаваните данни.

14

Tran, K. Introduction to Web Services with Java. 2013, p. 38.


13


SOAP Body е задължителен елемент на всяко съобщение. Това е тялото на

съобщението – в него се намират данните, предназначени за получателя.

Тялото може да съдържа елементи, които имат различни атрибути. Важна

функция изпълнява незадължителният елемент SOAP Fault, който служи

за съхраняване на информация за грешки, възникващи при обработката на

съобщението.

За защита на уеб услугите на ниво съобщения се прилагат предимно

няколко спецификации – XML Encryption, XML Signature, XKMS, WS-

Security и SAML.

XML Encryption15

е спецификация, дефинирана от W3C. Тя

осигурява изискването за конфиденциалност на данните чрез използване

на техники за криптиране. Криптираните данни се обвиват в определените

от спецификацията XML тагове.

XML Signature16

е технология, дефинирана от W3C и IETF17

. Чрез

нея се гарантира автентикация и цялост на данните.

XML Key Management Specification (XKMS) е спецификация, която

описва разпространението и регистрацията на публичните ключове на

цифровите подписи в XML документите.

WS-Security е спецификация, дефинирана от OASIS18

, която

осигурява набор от SOAP-базирани разширения за осигуряване цялост и

конфиденциалност на съобщенията, участващи в комуникацията с уеб

услугата. Тези разширения служат преди всичко за предодвратяване

четенето и модифицирането на SOAP съобщенията от трети лица в процеса

на предаване19

. Защитата на SOAP съобщенията се осъществява

посредством маркери (security tokens), като например потребителско име,

парола, сертификат за безопасност, цифрови подписи. WS-Security се

15

XML криптиране. http://www.w3.org/Encryption/ (април, 2014). 16

XML подпис. http://www.w3.org/Signature/ (април, 2014). 17

The Internet Engineering Task Force. 18

Организация за развитие на стандартите за структурирана информация. 19

Машнин, Т. Web-сервисы Java. Санкт-Петербург. 2012, с. 108.


14


използва по подобен начин на спецификациите XML Signature и XML

Encryption, определяйки как да се включат маркерите и криптираните

данни в рамките на едно SOAP съобщение. Обикновено маркерите и

цифровите подписи се поставят в заглавната част на съобщението, а тялото

се криптира.

SAML20

е стандарт, дефиниран от OASIS, осигуряващ механизми за

споделяне на информация, свързана с автентикация и оторизация от

партниращи си приложения.

На база на представените същностни характеристики и особености

на трите модела можем да заключим, че за осигуряване максимална защита

на уеб услугите е удачно да се използва най-вече третият модел. Това е

така, защото той осигурява защита на данните на ниво съобщения, а

комуникацията с уеб услугите се осъществява предимно посредством

съобщения.

Прокси услуги

Както вече отбелязахме, моделът за защита на ниво съобщения

представлява много добър механизъм за защита на уеб услуги, тъй като

всички изисквания за сигурност могат да бъдат осигурени от този слой.

Възниква въпросът какво би се случило, ако желаем да осигурим защита на

вече реализирани, тествани и инсталирани уеб услуги. Ясно е, че тяхното

модифициране с цел сигурност и безопасност е трудна задача, защото се

изискват големи промени в тях. Понякога създаването и инсталирането на

нова уеб услуга би отнело по-малко време от модифицирането с цел

безопасност и защита на работеща вече такава. Решение на този проблем

представлява прокси-базираният подход за защита на уеб услугите21

. Той

20

Security Assertion Markup Language. 21

Прокси-базиран подход за осигуряване на защита при уеб услугите.

http://www.developer.com/services/article.php/3320851 (април, 2014).


15


може да се приложи както при защита на разработвани нови услуги, така и

на вече съществуващи.

Основната идея при този подход е използването на прокси уеб

услуга, чието предназначение е да получава заявки вместо истинската

услуга. Прокси услугата извършва функциите по автентикация и

оторизация на клиента, като само при успех той получава достъп до

истинската уеб услуга. Така от една страна всяка нова уеб услуга може да

се защити чрез използване на прокси услуга, а от друга – работещите вече

уеб услуги не е необходимо да се преработват с цел сигурност и

безопасност. Те могат само да бъдат извиквани чрез прокси услугите за

защита.

Начинът на взаимодействие с уеб услугата при използване на прокси

услуга е представен на фиг. 4.

Фиг 4. Прокси-базиран подход за защита на уеб услуги

Този подход притежава следните предимства:

Базиран е на защитата на ниво съобщения;

Извършва се не само автетикация, а и проверка целостта на

съобщенията;


16


Прокси услугата работи като plug-in: тя може да бъде премахната

или заменена с всяко друго решение по всяко време;

Прокси услугата скрива истинската услуга, а процесът остава

скрит за клиента.

Можем да заключим, че използването на прокси-базирания подход

може да даде много добри резултати от гледна точка на сигурността. Това

е факт поради неговото основно предимство, а именно – възможността му

за прилагане към уеб услуги в случаите, когато те вече са инсталирани и

работят.


17


4. Заключение

В днешно време все повече организации използват уеб услуги, за да

осигурят продуктивна комуникация между вътрешните бизнес единици,

клиенти и партньори. С все по-масовото прилагане на уеб услугите от

страна на организациите възниква необходимостта информацията да се

предава между приложенията в съответствие с изискванията за сигурност и

безопасност.

За осигуряване конфиденциалност и цялост на данните, предавани

посредством приложенията в Интернет, се използват модели за защита на

ниво транспортен слой, мрежови слой и слой на съобщенията. Най-

подходящ за целите на сигурността при уеб услугите е моделът за защита

на ниво съобщения. На това ниво се използват спецификациите XML

Signature, XML Encryption, XKMS, WS-Security и SAML, осигуряващи

необходимата цялост и конфиденциалност на предаваните SOAP

съобщения. Алтернативен начин за осигуряване на защита е използването

на прокси услуга за автентикация. Прокси-базираният подход

представлява метод за защита както на изграждани в момента уеб услуги,

така и на работещи вече такива.

Разгледаните в реферата методи представляват добро решение на

проблема със сигурността при използването и/или изграждането на уеб

услуги. Кой точно подход или комбинация от подходи ще предпочетем, за

да осигурим защита на своите уеб услуги, зависи от конкретните им

особености и специфика.


18


5. Използвана литература

[1] Машнин, Т. Web-сервисы Java. Санкт-Петербург. 2012.

[2] Tran, K. Introduction to Web Services with Java. 2013.

[3] Иванова, Е. и др. Съвременни информационни решения на web

услуги в глобални мрежи в интерес на сигурността. Научна

поддръжка на трансформацията в сектора за сигурност. София,

2006.

[4] Филипов, Ф. Някои въпроси на представянето чрез UML на

механизмите за обмен на данни при уеб услугите. Известия, ИУ-

Варна, 1-2013.

[5] Alonso, G and Others. Web Services: Concepts, Architectures and

Applications, Springer, Heidelberg, 2004.

[6] Архитектура на уеб услугите. http://www.w3.org/TR/ws-arch/

(февруари, 2014).

[7] Изисквания при уеб услугите. http://www.w3.org/tr/wsa-reqs/

(февруари, 2014).

[8] Принципи на сигурността. http://www.dwheeler.com/secure-

programs/Secure-Programs-HOWTO/security-principles.html (април,

2014).

[9] Прокси-базиран подход за осигуряване на защита при уеб

услугите. http://www.developer.com/services/article.php/3320851

(април, 2014).

[10] Протоколен стек на уеб услугите. http://www.tutorialspoint.com/

webservices/web_services_architecture.htm (февруари, 2014).

[11] Роли и взаимодействия в архитектурата на уеб услугите.

http://www.ibm.com/developerworks/library/w-ovr/ (март, 2014).

[12] XML криптиране. http://www.w3.org/Encryption/ (април, 2014).

[13] XML подпис. http://www.w3.org/Signature/ (април, 2014).

Web Services Security

Software

xml xml soap

soap xml

w3c xml

xml signature xml encryption

xml signature16

xml encryption15

soap soap envelope soap

soap header