Jukka Sallinen:

Web-palveluiden tietoturva

Johdanto

Web-palvelun (engl. Web Services) voi määritellä ohjelmistojärjestelmäksi, joka tukee koneiden välistä yhteistoimintaa tietoverkon yli[1]. Ydinstandardeiksi Web-palveluiden toteuttamisessa ovat muodostuneet WSDL[2] (Web Services Description Language) ja SOAP[3] (Simple Object Access Protocol). Web Services -konsepti on viime vuosina kehittynyt varteenotettavaksi teknologiaksi yrityksille mm. järjestelmäintegraatioon. Teknologialla voidaan toteuttaa myös verkon yli ja kommunikoivia B2B?-sovelluksia (Business to Business). Tämä on ajanut Web-palvelu -konseptin tilaan, jossa myös tietoturvallisuuden keskeiset käsitteet, kuten luottamuksellisuus, eheys ja saavutettavuus on pystyttvä tarjoamaan.

Web palveluiden tietoturvasta huolehtiminen on monimutkainen tehtävä. Tämä on kenties yksi suurimmista jarruista teknologian yleistymisen tiellä. Perustavin syy tietoturvan monimutkaisuuteen on kenties se, että Web-palvelu -konsepti on vielä melko uusi ja sitä määrittävät standardit saavat vielä uusia versioita kohtalaisen tiuhaan tahtiin. Yhteinen standardijoukko ja näiden standardien noudattaminen toteutuksessa on ainoa keino toteuttaa yhteensopivia Web-palveluita. Web-palveluita määrittelevää standardijoukkoa kutsutaan yleisesti myös WS*-standardeiksi. Tässä tutkielmassa tarkastellaan WS*-standardeihin nojautuen Web-palveluiden tietoturvaa. Koska tutkielman aihepiiri voi olla monelle tuntematon, yritän seuraavassa luvussa avata keskeisiä termejä lukijoille. Tutkielman tarkoitus on muodostaa lukijalleen yleiskuva Web-palveluiden tietoturvaan liittyvästä WS*-standardijoukosta ja toisaalta myös Web-palveluiden ja tietoturvan haasteista.

Web-palvelut yleisellä tasolla - taustatietoa

SOA (Service Oriented Architechture) on nykyään melko tunnettu arkkitehtuurityyli. Sen perusajatus on, että ohjelmistot hyödyntävät toisiaan palveluina mahdollisimman löyhin sidoksin. Ideaalitapauksessa Ohjelmistopalvelun tarjoajan ei tarvitse siis esimerkiksi tuntea lainkaan asiakastaan, eli toista ohjelmistoa. SOA ei itsessään ole teknologia vaan pikemminkin ajatusmalli. Web palvelut sen sijaan ovat yksi tapa toteuttaa tämä SOA:n ajatusmalli. Nykyisin lähes standardin aseman saavuttanut kuvaus määrittelee Web-palvelun XML-pohjaisilla SOAP–kirjeillä viestiväksi verkon yli toteutetuksi palveluksi, joka julkaisee palvelurajapintansa WSDL–kielellä verkossa. Tämä on esimerkiksi WS-I -organisaation[9] esittämä määritelmä.

WSDL on keskeinen elementti Web-palveluissa, koska se kuvaa palvelun rajapinnan. se on standardoitu tapa esittää Web-palvelun tarjoamat palvelut asiakkaille. WSDL on XML-pohjainen kuvauskieli, joten se on kohtalaisella vaivalla niin ihmisen kuin koneenkin luettavissa. Esimerkiksi Googlen tarjoamaa WSDL-dokumenttia omaan hakupalveluunsa voi tutkailla seuraavassa osoitteessa: http://api.google.com/GoogleSearch.wsdl. WSDL esittää johdonmukaisesti palvelun rajapinnasta mm. sen kutsumetodit, metodien parametrit sekä protokollan, johon palvelu on sidottu. Yleisin ja vakiintunut tapa Web-palveluiden toteuttamiseen on SOAP over HTTP. SOAP on siis Web-palveluiden siirtoformaatti. Se ei ole sidottu tiettyyn kieleen tai alustaan ja sitä voidaan käyttää monen tiedonsiirtoprokolan päällä, yleensä kuitenkin HTTP:n yllä. Kaikki Web-palvelun ja sen asiakkaan väliset kutsut kootaan SOAP-kirjeiksi, jotka välitetään HTTP-kutsun (HTTP Post) hyötykuormana osapuolten välillä. Myös SOAP on XML-pohjainen. Tästä on runsaasti etua, koska näin SOAP:iin on esimerkiksi helppo lisätä myös XML-Signature ja XML-encryption standardien mukaisia elementtejä ja näin huolehtia viestitason salauksesta ja tietoturvasta palveluissa. SOAP-kirjeessä on kolme keskeistä osaa; Soap:element, Soap:header ja Soap:Body. Element-elementti määrittelee mm. kirjeessä käytettävät skeemat ja nimiavaruudet. Header-elementissä välitetään informaatio kirjeen kohde- ja lähdeosoitteista. Myös tietoturvaelementit, esimerkiksi käytetyt allekirjoitustekniikat tai tiivistefunktion tyyppi lisätään kirjeen header-elementtiin. Body-elementtiin lisätään itse välitettävä data. Data voi olla esimerkiksi jokin dokumentti esimerkiksi base64-enkoodattuna datana. Toisaalta välitettävä data voi myös olla yksinkertaisesti jokin merkkijono.

Web-palveluilla on useita käyttötarkoituksia. Yksi käyttötarkoitus on korvata esimerkiksi vanhoja CORBA:an tai Java RMI -tekniikkaan pohjautuvia RPC-rajapintoja enemmän SOA-pohjaisella Web-palvelu -rajapinnalla. Yritykset voivat myös paketoida vanhoja legacy-ohjelmistojaan web-palveluiden tarjoajiksi tai tarjota osan sovelluksestaan Web-palveluna. Esimerkiksi Google tarjoaa oman hakutoimintonsa myös Web-palveluna. Web-palveluita voidaan hyödyntää myös yritysten (B2B?) ja ohjelmistojen (M2M?) välisessä kommunikoinnissa ja tiedon jakamisessa. Tällöin WSDL tarjoaa standardoidun rajapinnan ja itse toteutusvälineet voidaan päättää tapauskohtaisesti. Web-palvelut voivat siis useissa tapauksissa korvata kokonaan vanhoja ja hajanaisia tekniikoita erilaisten hajautettujen järjestelmien toteuttamiseksi.

Web-palveluiden keskeiset turvallisuusstandardit

Internet verkkona on periaatteessa epäluotettava ja tietoturvaton. Tämän vuoksi kaikissa Internetin päälle rakennetuissa palveluissa (erityisesti tietoturvaa vaativissa) tulee jollain tavalla ottaa kantaa tietoturvan rakentamiseen. Internetissä kommunikoijat voidaan lähes aina jakaa asiakkaan ja palvelijan rooleihin. Kenties yksi yleisimmistä menetelmistä tietoturvallisuuden saavuttamiseksi on asiakkaan ja palvelijan välisen tietoliikenteen salaaminen SSL-protokollan avulla. SSL tulee sanoista Secure Sockets Layer ja se on käytännössä sovellustason kryptoprotokolla[7]. SSL on useimmiten riittävä keino salata liikennöinti asiakkaan ja palvelun välillä.

SSL:n suurin ongelma Web-palveluiden kannalta on kenties se, ettei SSL salaa asiakkaan ja palvelun välistä hyötykuormaa (eli viestejä) vaan koko yhteyden. Web-palvelukutsut saattavat periaatteessa kulkea vain osan matkastaan https:n päällä, jonka jälkeen kutsu välitetään johonkin toiseen järjestelmään. Tällöin kaikilla verkon välittäjäpisteillä on pääsy itse hyötykuormaan. Kaikkien välittäjäpisteiden pitäisi siis olla luotettuja, mikä ei käytännössä useinkaan ole mahdollista. Periaatteessa on myös mahdollista, että ensimmäinen web-palvelu toimii vain välittäjänä tai koostaa oman vastauksensa käyttäen muita web-palveluja (web-palveluiden orkestrointi). SSL-salauksen suurin ongelma on siis se, että se ei salaa yksittäisiä viestejä (Message level security) vaan koko viestintäkanavan ja todellisissa korkean tietoturvan web palveluissa viestitason salaaminen on välttämätöntä. SSL salausta voidaan (ja kannattaakin) tosin käyttää rinnakkain yhdessä viestitason salaustekniikoiden kanssa.

Yksittäisten viestien salaaminen tuo luonnollisesti huomattavia monimutkaistuksia välitettäviin SOAP-viesteihin. On esimerkiksi otettava kantaa siihen, miten web-palvelun osapuolet voivat neuvotella keskenään luotettavan viestitason session, mitä elementtejä yksittäisistä viesteistä salataan ja mitä kryptoprotokollia tiivisteiden laskemiseksi, allekirjoittamiseksi ja kryptaamiseksi käytetään. Keskeisessä roolissa tietoturvallisuuden luomisessa ovat siis uusilla elementeillä laajennettavat SOAP–viestit. Sama yhteensopivuus eri toteutuskielien ja toimintaympäristöjen välillä, mikä on saavutettu WSDL:n ja SOAP:in avulla salaamattomissa palveluissa, olisi kyettävä saavuttamaan myös salatuissa palveluissa. Tämän saavuttamiseksi vaaditaan siis uusia yhteisiä sopimuksia, standardeja, siitä miten palveluiden ja asiakkaiden tulisi toimia, jotta hyvä viestitason tietoturva olisi mahdollista. Seuraaviin alilukuihin olen nostanut kolme mielestäni keskeisintä standardia, joita noudattamalla luotettavia, tietoturvallisia ja yhteensopivia web-palveluita voidaan kehittää.

WS-Security

WS-security[4] on web-palveluiden turvallisuusstandardeista keskeisin. Se on luonteeltaan oikeastaan kokoelma standardeja tai ydinosa, jota muut WS*-standardit laajentaa. Standardin on alunperin kehittänyt yhdessä IBM, Microsoft sekä VeriSign?. Nykyisin standardia ylläpitää ja julkaisee Oasis-Open -järjestö. Uusin julkaisu on vuodelta 2006 ja viralliseksi nimeksi on muuttunut WSS[14]. WS-Security -standardi, kuten muutkin WS*-standardit, ei määrittele mitään yksikäsitteistä menetelmää web-palveluiden salaamiseksi. Standardi on pikemminkin viitekehys, joka jättää vielä turvallisuutta toteuttaville ammattilaisille tilaa toimia. Se ei ole turvallisuuden takaava protokolla, vaan WS-Security -standardi (ja osia siitä) voidaan toteuttaa useilla eri protokollilla ja työvälineillä. Tämä tekee standardista kenties vaikeamman ymmärtää ja hieman hankaloittaa eri menetelmillä toteutettujen palveluiden yhteensopivuutta kun tietoturvaa ei voidakaan saavuttaa noudattamalla askel askeleelta jotain valmista algoritmia.

Standardin ydinaines voidaan oikeastaan jakaa kolmeen; se tarjoaa menetelmän Security Tokenien välittämiseen, välitettävien viestien kiistämättömyyden (integrity) ja luottamuksen (confidentality). Standardi määrittelee XML-schemoja, joista löytyy XML-elementtejä lisättäväksi SOAP-kirjeisiin. Eräs tällainen elementti on , jonka alle viestissä (SOAP-header -osioon) turvallisuuselementit kootaan. Alla on esimerkki SOAP-header -elementistä, jonka sisällä on wsse:security – elementti.

 <?xml version="1.0" encoding="utf-8"?>
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..."
xmlns:ds="...">
<S11:Header>
  <wsse:Security>
    <wsse:BinarySecurityToken ValueType="...#X509v3" EncodingType="...#Base64Binary"
        wsu:Id="X509Token">MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
    </wsse:BinarySecurityToken>
    <ds:Signature>
       <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-excc14n#"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#myBody">
           <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
           </ds:Transforms>
           <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
           <ds:DigestValue>EULddytSo1...</ds:DigestValue>
         </ds:Reference>
       </ds:SignedInfo>
       <ds:SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV...</ds:SignatureValue>
       <ds:KeyInfo>
         <wsse:SecurityTokenReference>
           <wsse:Reference URI="#X509Token"/>
         </wsse:SecurityTokenReference>
       </ds:KeyInfo>
    </ds:Signature>
   </wsse:Security>
</S11:Header>
<S11:Body wsu:Id="myBody">
<tru:StockSymbol xmlns:tru="http://www.fabrikam123.com/payloads">QQQ</tru:StockSymbol>
</S11:Body>
</S11:Envelope>
( Lähteesta [4] )

Standardi määrittelee myös joukon Token-tyyppejä, joilla viestin osapuolet voidaan esimerkiksi autentikoida. Yllä olevassa esimerkissä on BinarySecurityToken?. Muita standardin määrittelemiä Token-tyyppejä ovat mm. UserNameToken? ja XMLToken. Tokeneihin voidaan viitata muualta SOAP-kirjeestä standardin määrittelemällä -elementillä.

WS-Security määrittelee myös, miten digitaalisia allekirjoituksia ja kryptaamista tulisi käyttää XML-standardeihin nojautuen. Allekirjoituksella tässä kontekstissa saavutetaan se, että vastapuoli voi luottaa siihen, että esimerkiksi SecurityToken? todella on vastapuolen luoma, eikä sitä ole käsitelty matkalla. Standardi nojautuu siis allekirjoituksessa XML Signature -standardiin[11]. SOAP–kirjeiden kryptaamisessa nojaudutaan XML Encryption -standardiin[12]. Näihin standardeihin tai XML-salauksen perusteisiin ei ole mahdollista uppoutua tämän lyhyen kirjoitelman puitteissa. Esimerkiksi englanninkielisestä Wikipediasta http://en.wikipedia.org/wiki/XML_Signature on mahdollista tutkia kielten perusteita.

WS-Security määrittelee myös Message Security Model:in. Tämä on oikeastaan yksinkertaisesti löyhä ohjeistus siitä, kuinka digitaalisia allerkirjoituksia ja SecurityTokeneja? tulisi käyttää. Lopuksi standardi määrittelee vielä joukon mahdollisia uhkakuvia web-palveluille. Nämä uhkakuvat ovat oikeastaan tuttuja kaikista tietoturvaa vaativista sovellusalueista. Esimerkkeinä mainittakoon Man-in-the-Middle -hyökkäykset, social engineering ja sanakirjahyökkäykset heikkoja salasanoja vastaan.

WS-Trust

WS-Security -standardin ulkopuolelle jää esimerkiksi, kuinka luottamuksellisuus (trust) saavutetaan. WS-Trust -standardi[12] tarjoaa viitekehyksen siihen, kuinka palvelun osapuolet voivat viestiä turvallisesti esittelemällä Web-palveluiden luottamusmallin. Luottamusmallin mukaisesti Web-palvelu vaatii kutsujalta erilaisia vahvennettuja väittämiä (claim), joilla kutsuttava osoittaa esimerkiksi olevansa se kuka väittää ja olevansa oikeutettu palveluun. Ilman vahvennettuja väittämiä lähetetyt viestit voidaan hylätä. Väittämien vahventaminen pohjautuu esimerkiksi julkisen avaimen allekirjoitukseen. WS-Trust -standardin mukainen skenaario voisi olla esimerkiksi seuraavanlainen:

  1. Requestor (palvelun kutsuja) pyytää SecurityTokenService?-palvelulta (joka myös voi olla, ja usein onkin web-palvelu) itselleen SecurityToken?-lippua aikaleimatulla viestillä.
  2. Vastaanottaja asettaa palvelukutsujalle haasteen palauttamalla tälle viestin, johon haaste on upotettu.
  3. Palvelun kutsuja vastaa allekirjoittaa haasteen ja vastaa palvelulle viestillä.
  4. Haasteen vastauksen ollessa hyväksyttävä Vastaanottaja palauttaa viestin, joka sisältää myönnetyn SecurityToken?- lipun.
  5. Tämän jälkeen Requestor voi käyttää lippua ja liittää sen ja julkisen avaimensa osaksi Web-palveluun lähetettävää viestiä muodostaen näin vahvennetun väittämän (proof of claim).
  6. Web-palvelu tämän jälkeen päättää, voiko se luottaa väittämään ja kommunikoida asiakkaan kanssa.

Kuten WS-Security, myös WS-Trust esittelee joukon Schemoja ja XML-elementtejä, joiden avulla standardissa kuvattuja menettelytapoja noudatetaan.

WS-SecureConversation

WS-SecureConversation[13] laajentaa omalta osaltaan WS-Security- ja WS-Trust -standardeja. Se määrittelee oikeastaan, miten palvelun osapuolet voivat laatia yhteisen turvallisuuskontekstin, jossa viestit salataan symmetrisillä salausavaimilla. Standardi myös esittää, kuinka näitä symmetrisiä avaimia johtamalla ("derive"), voidaan paremmin luottaa siihen, ettei yhteinen salaisuus paljastu. WS-SecureConversation oikeastaan myös parantaa web-palveluiden suorituskykyä. Web-palveluitahan voisi kenties moittia hieman raskaaksi konseptiksi, koska jo sinänsä xml:n prosessointi on raskasta melko raskas operaatio. Lisäksi epäsymmetrinen salaaminen vie aikaa. WS-SecureConversation voi parantaa suorituskykyä, koska se mahdollistaa yhteisen symmetrisen salausavaimen käytön. Toisaalta standardi tuo myös oman monimutkaistuksensa kommunikointiin eikä todellisista tehokkuusarvioista suuntaan tai toiseen kannatakaan tehdä kovin jyrkkiä olettamuksia.

Päätelmät

WS*-standardit tarjoavat hyvin määritellyn kokonaisuuden Web-palveluiden tietoturvallisuusriskien minimoimiseksi. Standardit ovat kuitenkin melko haastavia ymmärtää ja hieman monikäsitteisiä, eivätkä suinkaan anna valmiita vastauksia. Tavallinen sovellusohjelmoija tai ohjelmistoarkkitehti joutuu luultavasti melko harvoin käsittelemään ja suunnittelemaan Web-palveluiden tietoturvaa standardien tasolla, koska markkinoilla on paljon hyviä ohjelmistorajapintoja tähän tarkoitukseen. Eräs tällainen on esimerkiksi Microsoftin WSE-kirjasto, ilmainen .NET frameworkin laajennus, joka tarjoaa hyvin korkean tason rajapinnan Web-palvelukutsujen salaamiseen ja allekirjoitukseen.

Standardien ansiosta Web-palvelukonsepti on osittain kehittynyt siihen pisteeseen, että tietoturva on mahdollista määritellä palveluihin täysin irrallisena moduulina. Esimerkiksi WSE-kirjaston avulla Web-palvelu asiakkaan tietoturva on ideaalitapauksessa hoidettavissa määrittelemällä irrallinen XML-tiedosto ja Periyttämällä WSE:n tarjoama SOAP-Proxy-protokolla omalle Proxylle. Yksi suurimmista haasteista on, ettei tietoturvallisuutta palveluissa hoideta aina täsmälleen (tai edes lähellekään) samalla tavalla, vaan palvelukohtaisia variaatioita esiintyy. Valitettavasti nämä pieneltäkin vaikuttavat muutokset usein johtavat siihen, että pelkästään asiakaspäähän tarvitaan satoja ohjelmarivejä palvelukohtaista koodia esimerkiksi digitaalisille allekirjoituksille ja haaste-vaste -proseduurin läpikäymiseksi. Onkin selvää ja valitettavaa, että aiemmin esitelty Web-palveluiden kaunis ajatus löyhästi sidotuista palveluista ja asiakkaista jää ainakin toistaiseksi usein vielä haaveeksi, kun palveluilta vaaditaan myös vahvaa tietoturvallisuutta, kuten osapuolten välistä autentikointia ja viestien allerkijoittamista ja salaamista.

Lähteet

Print version |  PDF  | History: r2 < r1 | 
Topic revision: r2 - 16 Nov 2009 - 20:44:48 - TuomasPeippo?
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback