Een veilige implementatie van webservices vraagt om een gedegen afweging van de te nemen beveiligingsmaatregelen waarbij de organisatorische invulling evenveel aandacht vraagt als de technische inrichting. Dankzij de beschikbare toolkits en ontwikkelomgevingen hoeft de technische complexiteit geen struikelblok te zijn voor de inrichting van een goede beveiliging. Twee ict-architecten noemen een aantal maatregelen die genomen kunnen worden ter beveiliging van webservices. De beschreven technologieën zijn alle gebaseerd op open standaarden.
Webservices zijn druk bezig met een opmars vanuit het laboratorium naar de echte wereld. Ze maken het mogelijk applicaties met elkaar te laten samenwerken via een uniform uitwisselingsformaat (soap). Soap staat voor ‘simple object access protocol’ en is een op xml gebaseerde industriestandaard. Het zorgt er voor dat verschillende applicatieomgevingen ongeacht hun besturingssysteem en ontwikkeltaal met elkaar kunnen samenwerken. Op deze wijze kan een applicatie op een IBM AIX-platform die met J2EE (Java 2 Enterprise Edition) is gemaakt, communiceren met een .Net-applicatie, zonder dat de ontwikkelaars kennis hoeven te hebben van elkaars platformspecifieke implementatie. Dit kan het ontwikkeltraject van gedistribueerde applicaties aanmerkelijk versnellen. webservices lenen zich goed voor enterprise application integration projecten en b2b-toepassingen. Steeds meer leveranciers voorzien hun producten van webservicetechnologie. Voorbeelden hiervan zijn Microsoft’s .Net, IBM’s Websphere, Oracle’s 9i Application Server en SAP’s mySAP.
Momenteel wordt meestal nog gebruik gemaakt van http (hét standaard protocol van het web) voor het uitwisselen van informatie.
Omdat webservices een direct koppelvlak vormen met een applicatie, vaak backoffice systemen, is veiligheid een eerste vereiste. De soap-standaard schrijft niet voor hoe de beveiliging voor webservices vormgegeven moet worden. Wel wordt een aantal mogelijkheden beschreven, maar deze zijn niet volledig dekkend. Bij het beveiligen van webservices dienen de volgende aspecten minimaal gedekt te worden:
beschikbaarheid, integriteit, en vertrouwelijkheid
Classificatiesysteem
De hierboven genoemde aspecten worden vaak aangeduid als de biv-classificatie. De Engelstalige variant hiervan is de aic-classificatie (availibility, integrity en confidentiality). De aic-classificatie is beschreven in de ISO-standaard 17799.
Met behulp van het classificatiesysteem kan een organisatie haar informatiemiddelen waarderen. Op basis van de waardering worden vervolgens de te nemen maatregelen gekozen. Een classificatie loopt vaak van 1 (laag) tot 3 (hoog). Een informatiemiddel, bijvoorbeeld een database met klantgegevens, met de classificatie biv = 223 moet sterker beschermd worden dan een lager gewaardeerd informatiemiddel zoals de website waarop de interne ‘Tour de France’-pool wordt bijgehouden. Het doel van een classificatiesysteem is om de juiste balans te vinden tussen bedreigingen en te nemen maatregelen zodat de kosten in evenwicht zijn met de risico’s. De afweging tussen kosten en risico’s is de basis van elke gedegen informatiebeveiliging.
webservices zijn informatiemiddelen en dus zijn ze te classificeren volgens de biv-methode. Zoals aangegeven bevat het biv-classificatiesysteem drie aspecten: beschikbaarheid, integriteit en vertrouwelijkheid.
Met beschikbaarheid wordt het instandhouden van de continuïteit van de webservice bedoeld. Niets is vervelender dan dat een kritische applicatie tot stilstand komt omdat er ergens een webservice niet beschikbaar is. Het is zaak om de beschikbaarheid van alle betrokken webservices mee te nemen bij de beoordeling van de beschikbaarheid van de applicatie. Hier dienen contractuele afspraken of ‘service level agreements’ met de leveranciers van webservices overeen gekomen te worden. Zomaar een gratis webservice die via internet aangeboden wordt gebruiken een kritische rol in een applicatie te geven, is een onverstandige zaak. Met integriteit wordt bedoeld dat het bericht tijdens transport niet aangepast wordt. Het zou buitengewoon kwalijk zijn als een effectenorder plotseling een aankooporder wordt in plaats van de beoogde verkooporder. Integriteitsproblemen kunnen ontstaan door storingen in de communicatie en door opzettelijke inbreuken (hacken). Contractueel dient vastgelegd te worden welke partij de verantwoordelijkheid draagt voor eventuele integriteitproblemen bij het gebruik van webservices. Over het algemeen zal de ontvanger impliciet vertrouwen dat alles wat de verzender aanbiedt via de webservice, integer is.
Vertrouwelijkheid betekent dat het bericht tijdens transport niet te lezen is. De informatie kan wel afgevangen worden maar is niet begrijpelijk. Niemand zal blij zijn als vertrouwelijke medische informatie onderweg van huisarts naar ziekenhuis onderschept en openbaar gemaakt wordt. Contractueel dient vastgelegd te worden welke partij aansprakelijk is, wanneer informatie toch openbaar raakt door het gebruik van een webservice.
Natuurlijk is de beveiliging van een webservice niet alleen afhankelijk van bescherming van de service zelf. Het platform waar de webservices op aangeboden worden, de fysieke omgeving waar het geheel in gehuisvest wordt en de inzet van personeel spelen een minstens zo belangrijke rol. Ook beschikbaarheid is meestal het resultaat van een combinatie van organisatorische maatregelen en platformkeuze. Omdat al deze aspecten niet specifiek zijn voor webservices, worden ze hier buiten beschouwing gelaten.
Als een webservice eenmaal geclassificeerd is, wordt het mogelijk om te bepalen welke maatregelen getroffen moeten worden. Hiervoor wordt het instrument van de risicoanalyse gebruikt. Dit is een gestructureerde methode om vast te stellen welke bedreigingen zijn, en welke maatregelen genomen moeten worden.
Applicatielaag
Om webservices te beschermen, kunnen er op verschillende niveaus maatregelen genomen worden. Daarbij is gebruik te maken van het drielagenmodel. Het lagenmodel is gebaseerd op drie lagen: applicatielaag, transportlaag, netwerklaag.
De applicatielaag is de laag waarin de berichten worden vormgegeven of geïnterpreteerd. Aanpassingen in deze laag betekenen aanpassingen in de gebruikte applicaties. De transportlaag houdt zich bezig met het uitwisselen van berichten. Voorbeelden hiervan zijn http, smtp en leverancierspecifieke oplossingen zoals MQSeries van IBM. De netwerklaag transporteert informatie over fysieke netwerken ongeacht het soort informatie dat overgedragen wordt.
Maatregelen in de applicatielaag zijn onafhankelijk van de gebruikte transportlaag toe te passen. Er kunnen voorzieningen getroffen worden voor integriteit en vertrouwelijkheid. Voor integriteit zijn XML Signature en S/Mime aantrekkelijk. Deze standaarden maken gebruik van digitale handtekeningen voor de bescherming van de integriteit van het bericht. XML Signature is open standaard en biedt bescherming van xml-berichten. XML Signature werkt door het toevoegen van specifieke elementen aan een xml-bericht. De digitale handtekening kan geplaatst worden op een volledig xml-bericht maar ook op individuele elementen uit het bericht. Een xml-bericht met een digitale handtekening ziet er als volgt uit (ingekort):
De toegevoegde elementen bevatten informatie over wie het bericht getekend heeft, welke algoritmes gebruikt zijn voor het tekenen (bijvoorbeeld sha1/rsa) en de digitale handtekening zelf (de SignatureValue in het voorbeeld).
S/Mime is een wat oudere standaard die voortkomt uit de e-mail-wereld. Vrijwel alle moderne e-mail-pakketten ondersteunen S/Mime. Het maakt voor S/Mime niet uit of het te tekenen bericht xml bevat, het mag ook binaire informatie zijn. S/Mime voegt aan het bericht een bijlage toe (body part) waarin de digitale handtekening is opgeslagen.
Zowel XML Signature als S/Mime zijn te gebruiken voor het rechtsgeldig bewijzen van transacties conform de Europese Richtlijn ‘Raamwerk voor digitale handtekeningen’. XML Signature is aantrekkelijk voor grotere berichten waarbij een of enkele elementen beveiligd dienen te zijn. S/Mime is aantrekkelijk bij kleine(re) berichten die in hun geheel beveiligd moeten zijn.
XML Encryptie biedt voorzieningen voor het beschermen van vertrouwelijkheid van berichten in de applicatielaag. Ook S/Mime kan deze bescherming bieden. In het volgende voorbeeld van een xml-bericht met encryptie is alleen het nummer van de kredietkaart versleuteld:
Type=’http://www.w3.org/2001/04/xmlenc#Content’>
Net als XML Signature is XML Encryptie aantrekkelijk voor grotere berichten, waarbij een of enkele elementen beveiligd dienen te zijn. S/Mime is wederom aantrekkelijk bij kleine(re) berichten die in hun geheel beveiligd moeten zijn.
Transportlaag
Onder de applicatielaag bevindt zich de transportlaag. De transportlaag verzorgt de uitwisseling van berichten. Ook in de transportlaag bestaan diverse mogelijkheden om informatie te beschermen. Het voordeel van het treffen van maatregelen in de transportlaag is dat de bovenliggende applicatie niet aangepast hoeft te worden. In het algemeen is het voldoende om alleen de configuratie van het platform aan te passen. Oplossingen op het niveau van de transportlaag bieden meestal maatregelen voor de bescherming van zowel integriteit als vertrouwelijkheid. De bekendste oplossingen op dit niveau zijn ssl/tls, Kerberos en sasl. Ssl/tls is hét beveiligingsprotocol voor het internet. Hoewel ssl/tls voornamelijk bekend is voor het beschermen van http-verkeer (websites), is het ook in te zetten voor een reeks van andere protocollen (smtp, ftp, MQSeries, tcp/ip sockets, enzovoort) die gebruikt kunnen worden als transportprotocol voor webservices. Kerberos is een standaard beveiligingsprotocol dat afkomstig is uit de Unix-wereld, maar is inmiddels ook het standaardprotocol voor de beveiliging van Microsoft-systemen (Windows 2000 en hoger). SASL is een wat minder bekend protocol dat veelvuldig wordt toegepast in e-mail-beveiliging, het is echter niet beperkt tot alleen e-mail.
Een interessante nieuwkomer die speciaal bedoeld is voor het beveiligen van webservices, is het voorstel genaamd Soap Dsig. Dit is een toepassing van XML Signature als onderdeel van het soap-protocol.
Alle genoemde protocollen zijn in staat om authenticatie van afnemer en aanbieder van webservices op een betrouwbare wijze uit te voeren. Bij het implementeren van beveiligingsmaatregelen voor webservices op het niveau van de transportlaag dient men rekening te houden met de prestatie omdat de afhandeling op dit niveau meer capaciteit vraagt dan op applicatieniveau. Daarnaast bieden maatregelen op het niveau van de transportlaag geen eind-tot-eind bescherming. Als een webservice-client via een webserver gebruik maakt van een webservice op een applicatieserver, dan is alleen de verbinding tussen webservice-client en webserver beschermd. Niet die tussen webserver en applicatieserver.
De wijdverbreide beschikbaarheid van alle drie de protocollen maakt ze erg aantrekkelijk voor de beveiliging van webservices. Het meest gebruikte protocol is ssl/tls omdat dit ook in heterogene omgevingen weinig configuratieinspanning vereist.
Netwerklaag
Als laatste van de drie lagen uit het model komt de netwerklaag aan bod. Net zoals bij de transportlaag biedt de netwerklaag ook vaak maatregelen die zowel integriteit als vertrouwelijkheid beschermen. De bekendste maatregel in de netwerklaag is het virtual private network (vpn). Een vpn is een beveiligde tunnel die aangelegd wordt over een netwerk. Twee netwerkrouters kunnen samen een tunnel opzetten. Al het verkeer tussen deze twee routers loopt nu door de tunnel en is daarmee beschermd. Een vpn leent zich uitstekend voor de bescherming van informatie tijdens transport over lan, wan of internet. Het heeft de minste impact op de rest van het netwerk en de betrokken applicaties maar is relatief complex qua inrichting en beheer. Een vpn is over het algemeen niet geschikt voor authenticatie van afnemers op applicatieniveau.
Een vpn is aantrekkelijk onder een of meer van de volgende voorwaarden:
- Bekende partners, die regelmatig met elkaar communiceren;
- Lan-naar-lan koppelingen over een publiek netwerk;
- Grote hoeveelheden data die beschermd getransporteerd dienen te worden;
- Er wordt gebruik gemaakt van een protocol dat niet beschermd kan worden met standaard webtechnologie zoals ssl, Kerberos of sasl. Voorbeelden hiervan zijn sna, ipx/spx of Apple Talk.
Implementatie
Gelukkig hoeft de gemiddelde ontwikkelaar zich niet bezig te houden met de details van de bovengenoemde maatregelen. Er zijn diverse toolkits en ontwikkelomgevingen beschikbaar om de hierboven beschreven maatregelen toe te passen. Het gaat echter om meer dan alleen een technisch kunstje. Belangrijk is dat de organisatie kennis en begrip heeft van de toegepaste technologie. Goede maatregelen die verkeerd toegepast worden, kunnen meer schade aanrichten dan geen maatregelen.
Een veilige implementatie van webservices vraagt om een gedegen afweging van de te nemen beveiligingsmaatregelen waarbij de organisatorische invulling evenveel aandacht vraagt als de technische inrichting. Dankzij de beschikbare toolkits en ontwikkelomgevingen hoeft de technische complexiteit geen struikelblok te zijn voor de inrichting van een goede beveiliging.
Meint Post, Hans Klunder, ict-architecten bij More-Secure
