Trzy poziomy zabezpieczeń usług sieciowych

Bezpieczeństwo usług sieciowych Web services może być zapewnione na trzech poziomach [13]: transportowym (platformy), aplikacji, oraz wiadomości.

Każde z rozwiązań ma pewne charakterystyczne cechy.

Zabezpieczenia poziomu transportu chronią kanał transportu łączący dwa punkty końcowe usługi (ang. point-to-point security).Brak tu zatem możliwości routingu komunikatów. Jednak użycie tego typu zabezpieczeń ogranicza działanie systemu do jednej platformy, na przykład Microsoft Windows. Powodem jest to, że mechanizmy autoryzacji i uwierzytelniania dostarczane są przez konkretne serwery aplikacji lub W W W , w tym przypadku przez serwer Microsoft IIS. Poufność i integralność danych zapewniana jest przez SSL (ang. Secure Sockets Layer) lub IPSec - dwa najpopularniejsze protokoły służące implementacji bezpiecznych połączeń pomiędzy komputerami.

W zabezpieczenia poziomu aplikacji to aplikacja przejmuje odpowiedzialność za

85

bezpieczeństwo. Używa się w tym celu różnych mechanizmów wbudowanych w aplikację przez jej twórców. Przykładowo, dla zapewnienia poufności i integralności danych można użyć SSL, a dane uwierzytelniające przysyłać z każdym wywołaniem usługi sieciowej w nagłówkach SOAP. Innym przykładem może być ograniczenie szyfrowania jedynie do danych, które tego wymagają, jednak wymusza to na projektantach wiedzę o odpowiednich mechanizmów

bezpieczeństwa.

Zabezpieczenia poziomu wiadomości - zabezpieczenia wyższego poziomu, nazywane zabezpieczeniami komunikacji od końca do końca (ang. end-to-end message security). Jest to podejście, w którym wszystkie informacje związane z bezpieczeństwem zawarte są w samej wiadomości. Bezpieczna komunikacja opiera się szyfrowaniu (ang. XML Encryption) oraz cyfrowym podpisywaniu (ang. XML Signature) wiadomości przesyłanych w formacie XML w celu zapewnienia ich integralności i poufności, a także na wykorzystaniu żetonów zabezpieczeń w celu uwierzytelniania użytkowników.

W praktyce najczęściej stosowane jest podejście zabezpieczania usług sieciowych na poziomie transportowym oraz zabezpieczanie wiadomości. To ostatnie uważane jest za najlepsze, ponieważ: można zabezpieczać jedynie wybrane fragmenty wiadomości, zapewnia interoperatywność, umożliwia routowanie wiadomości przez pośrednie węzły sieci, można stosować wiele różnych technologii szyfrowania danych, oraz nadaje się do zastosowania do wielu różnych protokołów (SMTP, FTP, TCP).

3.2 W S-Security

WS-Security [25] jest zatwierdzoną przez organizację OASIS rodziną specyfikacji definiujących rozszerzenia standardu SOAP dotyczące przede wszystkim integralności i poufności komunikatów, wymiany żetonów zabezpieczeń, uwierzytelniania klientów, bezpieczeństwa sesji komunikacyjnej,, oraz wyrażeń zasad zabezpieczeń [1],

Rodzina specyfikacji WS-Security przedstawiona jest na rysunku 2. Należy zaznaczyć, że nie ujęto tu wszystkich specyfikacji dotyczących WS-Security. Na przykład z WS-Policy wiążą się także specyfikacje WS-PolicyAssertions oraz WS- Pol icyA ttachment.

Mechanizmy zapewniające integralność i poufność komunikatów, czyli szyfrowanie oraz cyfrowy podpis w specyfikacji WS-Security bazują na rekomendacjach organizacji W3C [16]. Są to odpowiednio XML Encryption oraz XML Signature i są ważną częścią rodziny WS-Security.

WS-SecurityPolicy WS-Federation W S -Authorization

WS-Policy WS-Trust W S

-SecureConversation

WS-Security

Standard SOAP

Rys. 3 Rodzina specyfikacji WS-Security Żetony zabezpieczeń

Bezpieczeństwo usług sieciowych jest oparte na założeniu, że nadchodzące komunikaty zawierają zestaw potwierdzeń dotyczących nadawcy, usługi lub jakichś innych zasobów. Do potwierdzeń tych zaliczyć możemy tożsamości (ang.

identity), atrybuty, uprawnienia (ang. permission) oraz możliwości (ang.

capability).Wszystkie takie potwierdzenia zabezpieczeń zakodowane są w żetonach zabezpieczeń (ang. security token). Służą one zarówno do uwierzytelniania oraz autoryzacji, jak i do podpisywania i szyfrowania komunikatów [2],

Konstruując żetony zabezpieczeń stosuje się różne podejścia. System może budować własny żeton na podstawie informacji lokalnych takich jak nazwa użytkownika i hasło [19]. Żeton może być też pobrany z innych źródeł, takich jak jednostka certyfikująca X.509 [28], kontroler domeny Kerberos (ang. Key Distibution Center - KDC) [17], czy też specjalistyczna usługa sieciowa wydająca żetony zabezpieczeń zwana Usługą żetonu zabezpieczeń (ang. Security Token Service - STS). Specyfikacja WS-Security definiuje zbiór zasad dotyczących wymiany żetonów zabezpieczeń, a żetony wydawane przez trzy wymienione wyżej usługi i wspierane są przez Web Services Enhancements 3.0.

Na listingu 5 widoczny jest przykład najprostszego rodzaju żetonu:

UsernameToken.

< w 3 s e :U s e r n a m e T o k e n u s u : I d = " H o j Ż e t o n " »

< w s s e : U s e r n a m e » K I i e n t H u r t o w n i < / w 3 s e : Us er na m e»

< w s s e :P a s s w o r d T y p e = " # P a s s w o r d D i g e s t " » u e Y I 3 n X d 8 L j M N V k s C K F V 8 t 3 r g H h 3 R w = = "

< / w s s e :P a s s w or d»

< w s s e : N o n c e » ¥ S c q a n j C E A C 4 m Q o B E 0 ? s A Q = = < / w s s e : N o n c e »

< w s u : C r e a t e d > 2 0 0 4 - 0 9 - 2 0 T 0 1 : 3 4 :44 Z</trsu: C r e a te d»

< / w s s e :U s e r n a m e T o k e n »

Listing 5. Żeton Usemame

87

X M L Signature i X M L Encryption w usługach W eb service

Specyfikacja XML Signature ioraz XML Encryption dotyczą dowolnych dokumentów w formacie X M L , jednak najszersze zastosowanie mechanizmy te znajdują właśnie w obszarze usług sieciowych Web services do przesyłanych przez usługi sieciowe komunikatów SO A P będących w istocie zwykłymi dokumentami X M L . Oprócz stosowania cyfrowych podpisów w komunikatach SO AP, można je dodatkowo zabezpieczać poprzez szyfrowanie. Przykład użycia do tego celu XML Encryption z zastosowaniem żetonu certyfikatu X. 509 widoczny jest na listingu 6.

Element EncryptionMethod specyfikuje algorytm szyfrowania. Z kolei element SecurityTokenReference określa wydawcę certyfikatu X.509 odbiorcy, za pomocą którego będzie on w stanie odszyfrować wiadomość. Atrybut elementu DataReference wskazuje fragment dokumentu, który ma zostać zaszyfrowany - w tym przypadku jest to cała część Body dokumentu. Element EncryptedData zawiera zaszyfrowane elemencie CipherData dane. Element EncryptedData może pojawić się w dowolnym miejscu dokumentu, w zależności od tego, gdzie znajdują się szyfrowane dane.

c ws se :Secur ityTokenReference>

< d s :XS09IssuerSer ial>

< d s : X509IssuerName>CN“CertGenCAB, C= US</ds: X509IssuerName>

<ds:X509SerialNuitiber>9937482243110</ds:X509SerialNuinber>

W przypadku, gdy szyfrowany jest cały dokument, EncryptedData będzie najbardziej zewnętrznym elementem dokumentu (ang. root element). Można też stsować tak zwane superszyfrowanie (ang. super-encryptioń). WS-Security zezwala

na umieszczenie wielu podpisów w jednym komunikacie. Każdy z podpisów może służyć do podpisywania innych elementów komunikatu. To samo dotyczy szyfrowania [2],

W S-Policy

Specyfikacja WS-Policy [22] zapewnia uniwersalny model i składnię do opisu oraz przekazywania zasad, czyli wszelkiego rodzaju możliwości i wymogów usługi sieciowej. Wprowadzono tu prostą i rozszerzalną gramatykę definiowania potwierdzeń zasad (ang. policy assertion) oraz model przetwarzania potrzebny do ich interpretacji. Mechanizmy te dokładnie opisuje specyfikacja WS- PolicyAssertions [23], Spełnienie potwierdzeń zasady zwykle daje w wyniku zachowanie odzwierciedlające tą zasadę. Dlatego też ocena potwierdzeń zasad jest kluczowym elementem identyfikacji zgodnych zachowań. Potwierdzenie zasady, podstawowy element składowy samej zasady, jest spełnione przez żądającego wtedy i tylko wtedy, jeżeli żądający spełnia wymóg (lub zapewnia funkcjonalność) odnoszącą się do potwierdzenia. Pojedyncze potwierdzenia zasad można łączyć w alternatywy logiczne (ang.policy alternative).

Do przekształcenia zasad na konkretną formę współdziałania służą wyrażenia zasad (ang. policy expression) oraz operatory All i Exactly One. W przykładzie na listingu 7 zdefiniowano trzy potwierdzenia zasad dla przykładowego systemu zamawiania produktów przez Internet. Przykładowo, usługa realizuje zamówienia w polskich złotych oraz w euro.

<wsp:Policy

x m l :b a s e = " h t t n ://hurtowniaintern e t o w a .c o m / zasada" W3U: Id“ "ZAHOUIENIE">

<wsp:All>

cmsp:EndpointHaintenanceSchedule>

<msp:Unavailable day="Sunday" start="0000" end="0200 "/>

< / m s p :EndpointMaintenanceSchedule>

< m 3 p :OrderPolicy>

<msp:DeliveryDelay m e s s a g e = " m s p :SkładanieZamówienia" msp:maximum="30"/>

</msp:OrderPolicy>

< w s p :ExactlyOne>

<ni3p: Cur r en cy >P L N< /m 3p : Currency>

C m s p :Cur r en cy >E U R< /m sp :Currency>

< w s p :ExactlyOne>

</w3p:All>

</wsp:Policy>

Listing 7. Zasada WS-Policy

Zasady mogą być łączone z dowolną kombinacją elementów X M L , definicjami W S D L lub wpisami U D D I, co opisuje dokładnie specyfikacja WS- Policy Attachment [24], Zasada przyjmowania zamówień z listingu 8 skojarzona jest z usługą za pomocą definicji W S D L tej usługi. Fragment takiej definicji W SD L można zauważyć na listingu 8. Widać, że zasada jest skojarzona z usługą

89

przyjmowania zamówień identyfikatora U R I w znaczniku PolicyReference.

<service naine="UslugaZaniouien">

<pore name= "Przyjmowanie Zainowien" binding«"m3p:PrzyjmowanieZamowien">

Cnrap: PolicyReference

URI="http://hurtowniainterneCowa.com/za3ada#ZAHOPIENIE" />

<soap:address

location="http://hurcowniainternetowa.com/zamówienia" />

</port>

</service>

Listing 8. Zasada dołączona do W SDL W S-SecurityPolicy

Usługi mogą przedstawiać własne wymogi bezpieczeństwa stosując potwierdzenia zasad zgodnie ze specyfikacją WS-SecurityPolicy [26]. Specyfikacja ta formułuje potwierdzenia zasad zabezpieczeń w języku zgodnym z omówioną powyżej WS-Policy. Jest to sześć potwierdzeń związanych z: żetonami zabezpieczeń, integralnością i poufnością komunikatów, ich widocznością dla pośredników SO AP, ograniczeniami nagłówków zabezpieczeń oraz wiekiem komunikatu. Na przykład, potwierdzenia zasad mogą żądać od wszystkich komunikatów, aby były podpisane przy użyciu kluczy publicznych uzyskanych od określonego organu, lub żądać uwierzytelniania opartego na żetonach Kerberos. Na listingu 9 przedstawiono przykład potwierdzenia dotyczącego poufności.

<wsse:Confidentiality w s p :U s a g e = " w s p :Required">

<wsse:Algorithm Type="wsse:AlgEncryption"

U R I = ”h t t n : //www. u3 ■ ora/2Q01/04/xrolenc#3de3-cbc"/>

CHessageParts

Dialect="h t t n :/ / s c h e w a s ■x m l s o a p ■or a /200 2/ 12 /W 3 3e #n ar t ">

wsp:GetIn£o 3e t Fo rN od e [w sp :G e tB od y(.))

</HessageParts>

</w s s e :Conf ident iality>

Listing 9. Potwierdzenie zasady WS-SecurityPolicy dotyczące poufności

W przykładzie tym część Body dokumentu, zgodnie z zasadą, ma zostać zaszyfrowana algorytmem 3DES. Element Confidentality wskazuje, że jest to potwierdzenie zasady dotyczące poufności. W znaczniku Algorithm ujęty jest mechanizm szyfrowania wiadomości, natomiast MessageParts umożliwia wskazanie fragmentów wiadomości, jakie mają zostać zaszyfrowane. Realizowane jest to poprzez wyrażenie zapisane w składni zgodnej z dialektem wskazanym w

elemencie Dialect.

WS-Trust

Żetony zabezpieczeń są wykorzystywane do zabezpieczania komunikacji między nadawcą a odbiorcą. Każda ze stron komunikacji musi ponadto określić, czy można zaufać poświadczeniom zamieszczonym w żetonie. Relacja zaufania jest więc oparta na wymianie żetonów zabezpieczeń oraz na zasadach zaufania, ustalonych przez odpowiednie organy.

Specyfikacja WS-Trust [27] uzupełnia specyfikację WS-Security o protokoły żądania, wydawania oraz pośredniczenia w przekazywaniu żetonów zabezpieczeń. W szczególności zdefiniowano operacje: pobierania, wydawania, odnawiania i zatwierdzania tych żetonów. W przypadku odmiennych wymogów bezpieczeństwa można używać, w połączeniu z WS-Trust, innych mechanizmów ochronnych warstwy transportowej, takich jak IPSec czy SSL. Usługa wydająca żeton zabezpieczeń nazywana jest Usługą żetonu zabezpieczeń (ang. Security Token Service - STS). Na listingu 10 widoczny jest podpisany za pomocą zaszyfrowanego żetonu Username komunikat RequestSecurityToken wysyłany przez klienta do zaufanego organu zabezpieczeń.

<env:Header>

<usse:Security>

<xenc:ReferenceList>... </xenc: Ref erenceLiso

<xenc: EncryptedData Id="Mo;)TokenUserNaine">F4 jopScX9s. ..</xenc:EncryptedData>

<ds:Signature>...</ds:Signature>

</usse:Security>

</env:Header>

<env:Body>

<wst:RequestSecurityToken>

<ust:TokenType>

http: //3klepinternetoav.org/ino1Mie3tand9rdoMvToken

</wsc:TokenType>

<wst:RequestType>

http;//schemas ■xipl3Ciap.cnrct/P3/2QQ4/0V security/trust/ Issue

</USC:RequescType>

</wst:Reque3tSecuricyToken>

</env:Body>

Listing 10. Komunikat RequestSecurityToken

Element ReąuestType określa typ żądania: w tym przypadku klient żąda wydania żetonu zabezpieczeń. Typ żądanego żetonu jest określony w elemencie TokenType. W przykładzie zażądano niestandardowego żetonu zabezpieczeń. Po otrzymaniu żetonu klient wykorzystuje go do wywołania usługi sieciowej hurtowni. Ta z kolei po otrzymaniu komunikatu od klienta musi sprawdzić autentyczność załączonego żetonu zabezpieczeń. W tym celu prosi zaufany organ o potwierdzenie autentyczności żetonu, wysyłając doń odpowiedni komunikat typu ReąuestSecurityToken RST (listing 11).

91

< w 3 t :RequestSecurityToken>

<wst. : TokenType>

http://3cheraa3■xrnlsoap.ora/ws/2004/04/sec:ui:itv/trust/RSTR/SCatu3

</wst:TokenType>

< w s t :RequestType>

http :/ / s c h e m a s .x m l s o a p ■ora/ws/2004/O4/security/trust/Validate

< / w s t :RequestType>

< w s t : B a s e > . ..</ust:Base>

< / u 3 t :R e questSecurityToken>

Listing 11. Żądanie sprawdzenia żetonu zabezpieczeń

Element RequestType oznacza, że jest to żądanie sprawdzenia żetonu przez zaufany organ. Element TokenType w tym wypadku oznacza, że od organu wymagane jest podanie informacji o stanie żetonu (czyli jego statusu). Nie ma tu żądań dodatkowych żetonów. W elemencie Base przekazywany jest żeton, który ma zostać sprawdzony. W odpowiedzi na żądanie, zaufany organ zwraca komunikat RSTR z wartością wskazującą, czy podany żeton jest poprawny

WS-SecureConversation

Z punktu widzenia wykorzystania zasobów oraz opóźnień sieciowych, żądanie i wydawanie nowych żetonów zabezpieczeń jest stosunkowo kosztowne.

W iele aplikacji, w krótkim czasie przesyła dużą ilość komunikatów do drugiego punktu końcowego. W takich sytuacjach z pomocą przychodzi specyfikacja WS- SecureConversation pozwalająca uniknąć tworzenia nowych uwierzytelnień przy wysyłaniu kolejnych komunikatów.

Specyfikacja WS-SecureConversation zawiera rozszerzenia specyfikacji WS-Security służące do tworzenia kontekstu zabezpieczeń (ang. security context) oraz udostępniania go uczestnikom komunikacji na czas trwania sesji. W sytuacji wymagającej przedłużenia czasu ważności kontekstu zabezpieczeń może on zostać uzupełniony. Kontekst zabezpieczeń jest reprezentowany w sieci przez specjalny typ żetonu, tak zwany żeton kontekstu zabezpieczeń (ang. Secrity Context Token - SCT). Przykładowym kontekstem mogłoby by być wielokrotne przesyłanie w obu kierunkach przez klienta i usługę sieciową komunikatów „ Złóż zamówienie ” lub

„ Potwierdź przyjęcie zamówienia WS-Federation

Pojęcie „tożsamość sfederowana” ma wiele znaczeń. W przypadku użytkownika indywidualnego oznacza możliwość skojarzenia jego tożsamości pochodzącej z danego systemu z zupełnie innym systemem. W przypadku przedsiębiorstwa, sfederowana tożsamość umożliwia zapewnienie jego usług zaufanym użytkownikom, którymi jednak przedsiębiorstwo nie zarządza bezpośrednio [10],

Specyfikacja WS-Federation definiuje rozwiązania pozwalające na

udostępnianie między domenami ufającymi informacji o tożsamościach, ich liczbie, atrybutach, uwierzytelnianiu i autoryzacji. Dzięki tym mechanizmom wiele domen może tworzyć federacje, a co za tym idzie - tożsamości z domeny jednego przedsiębiorstwa (lub dostawcy tożsamości - ang. identity provider) mają zapewniony dostęp do usług innego przedsiębiorstwa (lub dostawcy tożsamości).

Specyfikacja WS-Federation rozszerza model WS-Trust, pozwalając na włączanie do mechanizmu wydawania żetonów takich elementów, jak atrybuty i pseudonimy.

W ten sposób powstaje mapowanie tożsamości w środowisku wielu domen. WS- Federation jest w istocie rodziną trzech specyfikacji: WS-Federation, WS- Federation: Active Requestor Profile oraz WS-Federation: Passive Requestor Profile.

W dokumencie Bezpieczeństwo systemów informatycznych (Stron 87-95)