1. Uvod Prispevek obravnava področje integracije informacijskih sistemov s pomočjo spletnih storitev. Osredotoči se na varnostne mehanizme v spletnih storitvah in probleme, ki nastanejo pri njihovem povezovanju. Za razumevanje članka je zaželeno predhodno poznavanje osnov kriptografije. Organizacije se pogosto znajdejo v položaju, ko je treba integrirati obstoječe informacijske sisteme. Informacije so danes zelo pomembne in njihova hitra izmenjava med različnimi aplikacijami je nujna. Spletne storitve so tehnologija za integracijo informacijskih virov v organizacijah in med njimi [1]. V naslednjem poglavju bomo tako pregledali, s katerimi tehnologijami so spletne storitve tesno povezane. V tretjem poglavju bomo predstavili teoretično ozadje varnih spletnih storitev. Opisali bomo standard WSS [2]. Pomembna lastnost spletnih storitev je njihova medsebojna povezljivost. Uporaba spletne storitve mora biti neodvisna od okolja, v katerem ta teče. In varne spletne storitve niso izjema, zato bomo proučili vpliv standarda WSS na njihovo povezljivost. Tako četrto poglavje opisuje izdelavo varne spletne storitve v okolju .NET in njenega odjemalca v okolju Java. Obravnavani so problemi, na katere smo naleteli pri njunem povezovanju. Peto poglavje vsebuje sklepno misel. 2. Spletne storitve Spletne storitve komunicirajo s pomočjo sporočil XML (eXtensible Markup Language), ki jih pošiljajo po internetu. Za njihov prenos se uporablja protokol SOAP, ki si ga lahko predstavljamo kot pisemsko ovojnico, v katero shranimo sporočilo XML pred pošiljanjem. Celotno sporočilo SOAP se nato lahko prenaša po različnih protokolih. Tako aplikacijam ni treba skrbeti, po katerem transportnem protokolu bo sporočilo poslano. Najpogosteje uporabljen protokol je protokol HTTP (Hypertext Transport Protocol). V specifikacijah SOAP do verzije 1.2 je kratica SOAP pomenila Simple Object Access Protocol. Organizacija WC3 (World Wide Web Consortium) je v tej verziji sklenila, da beseda ni več akronim, ampak le ime [3]. Vmesnik spletnih storitev je opisan z jezikom WSDL (Web Services Description Language), ki je prav tako posebna oblika jezika XML. Opisovalni jezik WSDL opiše spletno storitev kot množico operacij, ki so sestavljene iz vhodnih in izhodnih sporočil. Kot imenik vmesnikov za spletne storitve se uporablja tehnologija UDDI (Universal Description, Discovery, and Integration) [1]. Ker spletne storitve uporabljajo internet kot prenosni medij, povezujejo zelo heterogene sisteme. Aplikacije velikokrat tečejo na različnih operacijskih sistemih, razvite so z različnimi programskimi jeziki in orodji, a kljub temu se morajo sporazumeti s pomočjo nekih skupnih procedur poslovne logike in prek istega protokola. Če jim to uspe, pravimo, da so aplikacije dobro povezljive. In ravno to je lastnost spletnih storitev. 3. Varovanje spletnih storitev Varovanje spletnih storitev je težka naloga, saj gre za različne sisteme, ki se medsebojno povezujejo. Tako ne gre le za varovanje enega sistema, ampak več vozlišč v omrežju. Na vsakem sistemu je treba poskrbeti za omejitev dostopa, upravljanje identitet, upravljanje gesel, avtorizacijo itd. Vendar varovanje posameznih sistemov ni dovolj. Treba je poskrbeti tudi za varovanje povezav med sistemi. Ker spletne storitve komunicirajo s sporočili, je treba poskrbeti tudi za varnost le-teh. Sporočila morajo ostati nedotaknjena oziroma nespremenjena, ko potujejo med pošiljateljem in prejemnikom. Prav tako mora prejemnik ob prejetju sporočila poznati identiteto pošiljatelja. Pošiljatelju sporočila pa mora biti omogočeno, da določi pravico branja, saj mora biti neželenim osebam vpogled v vsebino sporočila onemogočen. Obstajati morajo tudi mehanizmi, ki pošiljatelju preprečijo zanikanje poslanega sporočila. Dodatno je treba poskrbeti še za varnost hranjenih sporočil. Če vsebujejo pomembne informacije (npr.: številka kreditne kartice, razne poslovne pogodbe itd.), je pomembno, da so te dobro zaščitene tudi takrat, ko se Vpliv varnostnih mehanizmov na povezljivost spletnih storitev 115 ne pošiljajo. In točno varovanje sporočil SOAP, ne glede na to, kje se nahajajo, je naloga standarda WSS. 3.1 Standard WSS Standard WSS je temeljni standard v okviru varovanja spletnih storitev. Temelji na specifikacijah SOAP in na standardih za digitalno podpisovanje in enkripcijo sporočil XML [5], [6]. Z upoštevanjem smernic v standardu WSS lahko sporočilo SOAP zaščitimo z naslednjimi mehanizmi: � skrivanje informacij s prikrivanjem oziroma enkripcijo, � doseganje verodostojnosti sporočila, preprečitev pošiljateljevega zanikanja in preverjanje celovitosti sporočila z digitalnim podpisom, � dodajanje časovnih informacij v sporočilo s pomočjo časovnih značk. Pred drugimi načini zaščite (npr. protokol Secure Sockets Layer oziroma SSL) ima standard WSS določene prednosti. Predvsem je pomembna njegova lastnost, da zaščitimo sama sporočila. Omenjeni protokol SSL varuje povezavo med pošiljateljem in prejemnikom, kar pomeni, da je sporočilo varno le med prenosom. Standard WSS pa zaščiti sporočilo ne glede na to, kje se nahaja in kako dolgo obstaja. Poleg tega nam specifikacije WSS omogočajo veliko fleksibilnosti: zaščitimo lahko le dele sporočil ali le vhodna sporočila, medtem ko so izhodna nezaščitena ipd. Vsako sporočilo ima svojo strategijo zaščite. Glavna pomanjkljivost standarda WSS je njegova kompleksnost, saj je odvisen od veliko drugih standardov, kot so npr. specifikacije za digitalno podpisovanje in enkripcijo sporočil XML. Slika 1 prikazuje primer varnega sporočila SOAP. Element v zaglavju pove, da ima sporočilo vključene varnostne elemente. Element vsebuje digitalni podpis, s pomočjo elementa se sklicujemo na šifrirane podatke, ki pa jih vsebuje element . Ta primer predstavlja zelo poenostavljeno uporabo standarda WSS. Izpostavljeni so le najpomembnejši elementi, ki jih lahko vsebuje sporočilo. Pomembno je poudariti, da standard WSS ne narekuje katere elemente moramo vključiti v sporočilo. Pove nam le, kako elemente, ki jih želimo vključiti, vstavimo v sporočilo. Varnost posameznega sporočila je tako odvisna od zahtev aplikacije in pravilne uporabe specifikacij WSS ter standardov, ki so z povezani z njimi.
. . .
. . . Slika 1. Primer varnega sporočila SOAP Figure 1. A secure SOAP message sample 3.2 Varnostni žetoni Varnostni žetoni so dodatni varnostni elementi v okviru sporočil SOAP, ki so namenjeni predvsem avtentikaciji ali avtorizaciji. Definiranih je veliko varnostnih žetonov, WSS pa omogoča tudi uvedbo novih. Poznamo tri glavne tipe varnostnih žetonov: žetoni, ki vsebujejo uporabniško ime in geslo, žetoni, ki vsebujejo binarne podatke, in žetoni XML. Žeton z uporabniškim imenom in geslom je identificiran z elementom . Omogoča preprosto vključitev uporabniškega imena in gesla v zaglavje sporočila SOAP. Geslo lahko vključimo na dva načina: prikrito ali neprikrito. Uporaba žetona z uporabniškim imenom in geslom je privlačna predvsem zato, ker je zelo preprosta za uporabnika, saj je geslo najbolj razširjena oblika avtentikacije. Če nad geslom uporabimo še zgoščevalni algoritem, je takšna oblika tudi varna. Problem je pa seveda ta, da morata strežnik in odjemalec poznati isto geslo. Varnostni žeton, ki vsebuje binarne podatke, je označen z elementom . Z njim lahko npr. v zaglavje sporočila vključimo digitalno potrdilo, potrebno za avtentikacijo. V okviru žetonov XML pa poznamo več tipov. Vsem je skupno, da nimajo splošnega elementa, ki jih identificira (kot imajo npr. binarni žetoni element ), ampak ima vsak tip žetona XML svoj element [1]. 3.3 Uporaba prikrivanja v sporočilu SOAP Prikrivanje v XML nam pomaga šifrirati vsebino oziroma dele sporočil SOAP. Elementi ,
ter se ne prikrivajo, saj so potrebni za delovanje protokola SOAP. Prikriti podatki so znotraj elementov , na njih pa se sklicujemo iz zaglavja sporočila s pomočjo elementa 116 Kocbek, Jurič . Za prikrivanje lahko uporabljamo simetrične ali asimetrične algoritme, velikokrat pa se uporablja koncept digitalne ovojnice, saj se prenašajo velike količine podatkov. 3.4 Uporaba digitalnega podpisa v sporočilu SOAP Digitalni podpis ima v WSS dve glavni nalogi [1]. Prva je preverjanje varnostnih žetonov. Kot primer opišimo podpisovanje digitalnih certifikatov. Spomnimo se, da je v WSS mogoča avtentikacija s pomočjo binarnih varnostnih žetonov v obliki certifikatov. A sam certifikat ni dovolj za avtentikacijo uporabnika, saj so ti javno dostopni in tako lahko vsak vključi poljuben certifikat v sporočilo SOAP. Zato lastnik s svojim zasebnim ključem podpiše certifikat, prejemnik sporočila pa uporabi javni ključ iz certifikata, da preveri podpis. Če je postopek uspešen, je pošiljatelj dokazal, da certifikat resnično pripada njemu, saj ima le on dostop do zasebnega ključa. Druga naloga digitalnega podpisa v WSS je dokazovanje celovitosti samega sporočila SOAP. Če pošiljatelj podpiše telo ali katere druge dele sporočila, prejemniku omogoči, da preveri, ali je bilo sporočilo po podpisu spremenjeno. Ker se vsebina sporočila SOAP na poti med pošiljateljem in prejemnikom velikokrat spremeni, je edini tip podpisa, ki ga je smiselno uporabiti, t.i. ločen podpis. To pomeni, da bo podpis v zaglavju sporočila, od koder se bo skliceval na podpisane podatke. Zaglavje sporočila SOAP lahko vsebuje tudi več podpisov. Tako lahko npr. dokument potuje med različnimi osebami, ki imajo možnost podpisovati različne dele dokumenta. 3.5 Časovna značka Časovna značka (angl. Time Stamp) je mehanizem, ki ga definira WSS in omogoča uvedbo časovnih informacij v sporočilo SOAP (slika 2). Tako je mogoče razbrati podatke (kdaj je sporočilo nastalo, kdaj je bilo prejeto in kdaj poteče njegova veljavnost) kar iz samega sporočila. Časovna značka se nahaja v zaglavju sporočila. Zavedati se moramo, da se čas nanaša na uro sistema, na katerem je sporočilo nastalo, in lahko pride do odstopanja med pošiljateljem in prejemnikom. 2002-08 19T16:15:31Z 2002-08-19T16:20:31Z Slika 2: Primer časovne značke v sporočilu SOAP Figure 2: A time stamp sample 4. Analiza povezljivosti varnih spletnih storitev Kot smo povedali, mora biti uporaba spletne storitve neodvisna od okolja, v katerem ta teče. V ta namen smo se odločili, da bomo preučili povezljivost med dvema zelo razširjenima razvojnima okoljema: okoljem .NET in okoljem Java v okviru standarda WSS. Zamislili smo si aplikacijo, ki jo ponudi banka svojim komitentom in je sestavljena iz dveh komponent: spletne storitve ter odjemalca (slika 3). Pregled zadnjih 10 sprememb Spreminjanje osebnih podatkov Pregled stanja Prijava uporabnika Nakazilo denarja Pregled osebnih podatkov <> Komitent <> <> <> <> Slika 3. Diagram primerov uporabe za aplikacijo Figure 3. Use case diagram for the application Komitenti lahko tako spremljajo stanje na svojem računu, spreminjajo svoje osebne podatke ter si medsebojno nakazujejo denarna sredstva. Informacije, ki se pri tem pošiljajo, so zelo občutljive, zato je scenarij primeren za demonstracijo zaščite sporočil SOAP s standardom WSS. Posamezni koraki povezovanja odjemalca s spletno storitvijo so naslednji: � odjemalec zaščiti sporočilo s koraki, ki so opisani niže, � odjemalec pošlje zaščiteno sporočilo, � spletna storitev prejme sporočilo in preveri njegovo veljavnost, � če je sporočilo veljavno, spletna storitev pripravi odgovor, � spletna storitev zaščiti odgovor in ga pošlje odjemalcu, � odjemalec sprejme odgovor in preveri njegovo veljavnost. Varnostne zahteve za vhodna sporočila spletne storitve so naslednje: � za avtentikacijo uporabljajo varnostni žeton tipa UsernameToken z geslom ter uporabniškim imenom komitenta (geslo je v zgoščeni obliki), � vsebovati morajo časovno značko sporočila, Vpliv varnostnih mehanizmov na povezljivost spletnih storitev 117 � z zasebnim delom digitalnega potrdila C1 morajo biti podpisani varnostni žeton tipa UsernameToken, časovna značka in telo, � vsebovati morajo javni del digitalnega potrdila C1 v binarnem varnostnem žetonu, � z javnim delom digitalnega potrdila C2 mora biti prikrito telo sporočila. Za izhodna sporočila pa mora veljati: � vsebovati morajo časovno značko sporočila, � z zasebnim delom digitalnega potrdila C2 morata biti podpisana časovna značka in telo, � vsebovati morajo javni del digitalnega potrdila C2 v binarnem varnostnem žetonu, � z javnim delom digitalnega potrdila C1 mora biti prikrito telo sporočila. Slika 4 prikazuje diagram zaporedja za primer izvedbe nakazila. Pomembna metoda na strani odjemalca je metoda zascitiSporocilo(), ki jo kličemo nad primerkom razreda KOdrezek. Razred KOdrezek je kontrolni odrezek (Stub) v arhitekturi porazdeljenih objektov. Metoda zascitiSporocilo() poskrbi za vključitev varnostnih mehanizmov v zahtevo s pomočjo programskega vmesnika v Javi. Spletna storitev preveri veljavnost te zahteve v okviru definirane varnostne politike v okolju .NET in pošlje odgovor. Odjemalec preveri njegovo veljavnost in obvesti uporabnika o uspešnosti izvedbe nakazila. : KOdrezek: Komitent : Odjemalec : Skelet : Storitev 1: Prijava v sistem, podatki o nakazilu 7: Informacije o izvedbi nakazila 2: izvediNakazilo() 3: zascitiSporocilo() 4: izvediNakazilo() 5: izvediNakazilo() 6: Podatki o nakazilu Slika 4: Diagram zaporedja za nakazilo denarja Figure 4: Sequence diagram for a money order 4.1 Opis tehničnih lastnosti rešitve Za razvoj varnih spletnih storitev v okolju .NET nam podjetje Microsoft ponuja izdelek WSE (Web Services Enhancements) [7]. Zadnja verzija izdelka je 3.0. Gre za knjižnico razredov, ki omogočajo gradnjo spletnih storitev z dodatnimi možnostmi, kot je implementacija standarda WSS v ogrodj .NET s pomočjo orodja Visual Studio 2005. Za razvoj odjemalca smo uporabili Java 5.0 SDK (Software Developer Kit) in razvojno orodje Eclipse z ustreznimi vstavki, med katerimi je najpomembnejši SD (Systinet Developer) 6.0 [8], [9]. Dodatek SD omogoča razvoj varnih spletnih storitev v okolju Java, podobno kot izdelek WSE v okolju .NET. 4.2 Testiranje in analiza povezljivosti Po implementaciji obeh komponent rešitve smo s pošiljanjem testnih sporočil analizirali povezljivost in medsebojno delovanje odjemalca in spletne storitve. Najprej smo testirali aplikacijo brez vključene podpore standardu WSS in ugotovili, da deluje brez težav. Nato smo vključili podporo standardu WSS in pred uspešnim delovanjem aplikacije smo naleteli na nekaj problemov, ki pa smo jih uspešno odpravili. Vir vseh težav so bili različni privzeti algoritmi v obeh okoljih. Ker se pri povezovanju spletnih storitev ponavadi pošiljajo velike količine podatkov, se pogosto uporablja koncept digitalne ovojnice [10]. To pomeni, da se za prikrivanje podatkov uporabi simetrični ključ, katerega nato prikrijemo z asimetričnim ključem. Ker so simetrični ključi kratki, se tako izognemo šifriranju dolgih sporočil. Problem je bil, da izdelek WSE 3.0 privzeto uporablja drugačen algoritem za prikrivanje simetričnega ključa kot dodatek SD 6.0. Oba sicer uporabljata algoritem RSA (Rivest Shamir Adleman), vendar različne variacije. Mogoči sta dve rešitvi problema: ali na strani spletne storitve spremenimo algoritem, ki naj ga pričakuje, ali na strani odjemalca spremenimo algoritem, ki naj ga uporabi za šifriranje. Odločili smo se za prvo možnost. Po odpravi težave smo nadaljevali testiranje. Tokrat je spletna storitev uspešno dešifrirala sporočilo in preverila digitalni podpis, vendar se je zalomilo pri dešifriranju njenega odgovora na strani odjemalca. Razlog je bil v uporabljenem algoritmu za izračun t.i. identifikatorja ključa. Identifikator ključa je določena vrednost, s pomočjo katere identificiramo varnostni žeton in s pomočjo katere se lahko nanj tudi sklicujemo. Natančna oblika vrednosti in algoritem, ki se uporabi za njen izračun, sta odvisna od posameznega tipa varnostnega žetona. Izkazalo se je, da sta WSE in SD spet uporabljala različna privzeta algoritma, kar je na strani odjemalca povzročilo, da algoritma ni našel. Ko smo odpravili to neskladje, je odjemalec znal dešifrirati prikriti simetrični ključ, še vedno pa z njim ni mogel dešifrirati prikritih podatkov. Napaka, ki jo je prožil, je bila v nepravilni velikosti ključa za dešifriranje. Preverili smo sporočilo in ugotovili, da je spletna storitev uporabila algoritem AES (Advanced Encryption Standard) s ključem velikosti 256 bitov za enkripcijo podatkov. Za odjemalca je bil ta ključ očitno prevelik. Kot smo ugotovili, je bil razlog v paketih JCE (Java Cryptography Extension), ki so ogrodje in 118 Kocbek, Jurič implementacija algoritmov za prikrivanje v Javi [11]. Ti paketi so nameščeni skupaj z orodjem Java SDK in ponujajo omejeno podporo algoritmom za prikrivanje. Razlog je njihov nadzor uvoza v nekaterih državah. Zato smo jih morali nadgraditi z neomejeno verzijo, da smo omogočili podporo algoritmom, ki uporabljajo ključe, večje od 128 bitov. Tabela 1 prikazuje algoritme za prikrivanje, ki smo jih stestirali pred nagraditvijo paketa JCE. Tabela 1: Privzeta podpora algoritmom v paketu JCE Table 1: Default supported algorithms in JCE package Algoritem Velikost ključa Podpora AES128 128 bitov Da AES 256 256 bitov Ne AES192 192 bitov Ne Triple-DES (Data Encryption Standard) 168 oziroma 192 bitov Ne Po tej zadnji spremembi, smo končno dosegli uspešno delovanje spletne storitve in njenega odjemalca v okviru standarda WSS. 5. Sklep V prispevku smo obravnavali varnost spletnih storitev. Te pomenijo tehnologijo, ki omogoča učinkovito integracijo sistemov v organizacijah ali med njimi. V prvem delu prispevka smo si ogledali, kaj spletne storitve sploh so in katere tehnologije so povezane z njimi. Nato smo spoznali standard WSS, naloga katerega je definirati uporabo digitalnega podpisa in prikrivanja pri zaščiti sporočil SOAP. Seznanili smo se tudi s pojmi, kot sta varnostni žeton in časovna značka, ki dodatno pripomorejo k varnosti. Drugi del prispevka je bil namenjen analizi povezljivosti varnih spletnih storitev. Izdelali smo spletno storitev v okolju .NET in odjemalca v okolju Java ter v obeh komponentah omogočili podporo standardu WSS. Pri njunem povezovanju smo ugotovili, da specifikacije WSS bistveno ne vplivajo na povezljivost, saj smo dosegli uspešno delovanje obeh komponent iz različnih okolij. Vendar smo pri tem naleteli na nekaj manjših težav, ki smo jih morali odpraviti. Največji problem so bili privzeti algoritmi, ki so se na obeh sistemih razlikovali. Tako smo ugotovili, da čeprav standard WSS ponuja podporo, same platforme privzeto ne podpirajo vseh algoritmov. Zato je pomembno, da se v fazi načrtovanja varnih spletnih storitev osredotočimo tudi na proučitev teh algoritmov in njihovo podporo v razvojnih okoljih. To je pomembno tudi zato, ker se varnost algoritmov, ki se uporabljajo za šifriranje in podpisovanje, z večanjem računske moči strojne opreme manjša, kar pomeni, da moramo spletne storitve prilagajati aktualnim varnostnim mehanizmom. V nasprotnem primeru se lahko zgodi, da nekoč varna in zanesljiva spletna storitev postane nezaščitena. 6. Literatura [1] J. Rosenberg, D. Remy, Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption, Sams Publishing, 2004 [2] OASIS Web Services Security Technical Committee, http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=ws s [3] W3C, SOAP Specifications, http://www.w3.org/TR/soap/ [4] E. Newcomer, Understanding Web Services: XML, WSDL, SOAP and UDDI, Addison Wesley, 2002 [5] W3C, XML Signature Syntax and Processing, Recommendation, http://www.w3.org/TR/xmldsig- core/ [6] W3C, XML Encryption Syntax and Processing, Recommendation, http://www.w3.org/TR/xmlenc- core/ [7] Microsoft, Web Services Enhancements, http://msdn.microsoft.com/webservices/webservice s/building/wse/default.aspx [8] Eclipse, http://www.eclipse.org/ [9] Systinet, Systinet Developer, http://www.systinet.com/products/sd/overview [10] RSA Security, What is a Digital Envelope, http://www.rsasecurity.com/rsalabs/node.asp?id=2 184 [11] Sun Microsystems, Java Cryptography Extension (JCE), http://java.sun.com/products/jce/ Simon Kocbek je diplomiral leta 2006 in je mladi raziskovalec na področju računalništva in informatike na Fakulteti za zdravstvene vede Univerze v Mariboru. Izkušnje si je nabiral tudi v večjem podjetju v javni upravi. Ukvarja se z integracijo informacijskih sistemov in spletnimi aplikacijami, prav tako pa ga zanimajo področja umetne inteligence, podatkovnega rudarjenja, informatike v zdravstvu, bioinformatike in računalniške varnosti. Matjaž B. Jurič je izredni profesor na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Ukvarja se s storitvenimi arhitekturami, kompozicijo poslovnih procesov, integracijo, elektronskim poslovanjem, spletnimi storitvami in optimizacijo zmogljivosti. Je avtor oz. soavtor več knjig, izdanih pri mednarodnih založbah, sodeloval je pri razvoju RMI-IIOP in je član BPEL Advisory Boarda.