Beveiligen van Infrastructuren en Web Services Theodoor Scholte University of Twente faculty of EEMCS SAMENVATTING Het uitwisselen van informatie op het Internet kan op heel veel verschillende manieren plaatsvinden. Het beveiligen ervan kan op nog heel veel meer manieren gebeuren. Organisaties weten daarom vaak niet wat voor beveiliging ze moeten kiezen wanneer zij een Web service uit gaan rollen. Dit artikel beoogt organisaties te helpen bij het kiezen van een geschikte beveiliging. Eerst wordt uitgelegd waarom organisaties informatiebeveiliging nodig hebben. Deze doelen zijn het garanderen van de beschikbaarheid, betrouwbaarheid en vertrouwelijkheid van informatie. Deze doelen kunnen bereikt worden door toepassing van identificatie, authenticatie, autorisatie en encryptie. Vervolgens worden de technologieën besproken die bovenstaande functies kunnen vervullen. Daarbij wordt onderscheid gemaakt tussen infrastructurele beveiliging (zoals IPsec en Firewalls) en beveiliging van Web services (XML Access Control en XML Encryptie). De voor- en nadelen van elke beveiligingstechnologie worden ook besproken. Tot slot wordt verteld hoe organisaties een keuze voor een bepaalde technologie kunnen maken. Vaak blijkt dat de keuze heel eenvoudig is, maar in sommige gevallen is het keuzeproces wat lastiger. Sleutelwoorden Authenticatie, autorisatie, beveiliging, encryptie, firewall, infrastructuur, HTTP, IPsec, SAML, TLS, XACML, XML, Web services. 1. INLEIDING Het Internet is een belangrijk communicatiemedium geworden. In het verleden werd Internet vooral gebruikt om informatie te publiceren en voor communicatie via e-mail. Nu en in de toekomst wordt het Internet meer en meer gebruikt voor e- commerce en e-business toepassingen [21]. Voorbeelden van deze toepassingen zijn het boeken van een vlucht, supply-chain management en webshops. Deze toepassingen kunnen uit heel veel verschillende informatiesystemen bestaan. Om deze informatiesystemen met elkaar en met client-computers op een eenvoudige manier te laten communiceren, zijn Web services ontwikkeld. Web services werken op de bestaande infrastructuren van het Internet. Organisaties willen Web services om verschillende redenen beveiligen. In de afgelopen jaren is technologie ontwikkeld om Web services zelf te beveiligen, maar er is ook technologie ontwikkeld om de infrastructuur van het Internet te beveiligen. Er zijn zoveel beveiligingstechnologieën waardoor organisaties mogelijk door Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission. 1st Twente Student Conference on IT, Enschede 14 June 2004 Copyright 2004, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science de bomen het bos niet meer zien. Dit artikel probeert een handreiking te doen door de verschillende technologieën te beschrijven, de eigenschappen en de voor- en nadelen te noemen. Daarbij wordt onderscheid gemaakt tussen infrastructurele beveiliging, waarmee zowel webapplicaties als Web services beveiligd kunnen worden, en beveiliging van de Web services zelf. Wat betreft infrastructurele beveiliging, wordt er in dit artikel beschreven hoe webapplicaties met infrastructurele oplossingen te beveiligen zijn. De reden hiervoor is dat webapplicaties grote overeenkomsten met Web services vertonen en er veel meer bekend is over infrastructurele beveiliging van websites en webapplicaties. Op basis van de eigenschappen, de voor- en nadelen van beveiligingstechnologieën zijn criteria voor organisaties te bepalen. In veel gevallen wordt meteen duidelijk welke technologie een organisatie moet kiezen, maar in enkele gevallen niet. Dit artikel stelt een methode voor waardoor het keuzeproces vereenvoudigd wordt. In het volgende hoofdstuk wordt ingegaan op wat informatiebeveiliging precies inhoudt. Informatiebeveiliging is namelijk zo breed dat als alle aspecten besproken worden, het artikel veel te lang zou worden. In het hoofdstuk wordt ingegaan op waarom informatiebeveiliging toegepast wordt en met wat voor maatregelen deze doelen bereikt kunnen worden. De twee daarop volgende hoofdstukken beschrijven technische oplossingen om beveiligingsdoelen te bereiken, respectievelijk oplossingen die in de infrastructuur en in Web services toegepast worden. Hoofdstukken 5 en 6 beschrijven de voor- en nadelen van deze oplossingen. In hoofdstuk 7 wordt geprobeerd uit een te zetten hoe organisaties een technische oplossing kunnen kiezen. 2. WAT HOUDT INFORMATIEBEVEILIGING IN? Computerbeveiliging kan op verschillende niveau s toegepast worden [9]. Deze niveau s kunnen als volgt gedefinieerd worden: - fysieke beveiliging Dit omvat onder andere de beveiliging van de ruimtes waar de informatiesystemen fysiek staan opgesteld. - communicatie beveiliging Hiermee wordt de beveiliging van het uitwisselen van gegevens bedoeld. - Systeembeveiliging Dit omvat de beveiliging van de informatiesystemen zelf. Met beveiliging zal in dit artikel vooral de laatste twee genoemde niveau s bedoeld worden. Informatiebeveiliging beoogt verschillende doelen. Deze doelen zijn in de paragraaf hieronder beschreven.
2.1 Doelen van informatiebeveiliging Tijdens het ontwikkelen van informatiesystemen hebben ontwikkelaars altijd een idee voor wie de informatie beschikbaar is en voor wie niet. Ze zijn zich er ook van bewust waarom de informatie en de informatiesystemen voor een beperkte groep gebruikers beschikbaar moet zijn. Dit zijn de doelen van de informatiebeveiliging. Deze doelen zullen hieronder afzonderlijk besproken worden: 2.1.1 Beschikbaarheid & continuïteit Het bewaren van de continuïteit van een informatiesysteem is ervoor zorgen dat het informatiesysteem met al haar applicaties blijft werken. Indien mensen op het informatiesysteem actief zijn zonder dat zij weten hoe het informatiesysteem werkt, dan kan het gebeuren dat applicaties of processen binnen applicaties crashen of stop worden gezet. De continuïteit van het informatiesysteem is dan in gevaar [29] [9]. Dit kan voorkomen worden door deze mensen toegang tot het systeem te weigeren. Vooral in de financiële- en economische sector is het van belang dat informatiesystemen 24 uur per dag, 7 dagen in de week en 365 dagen per jaar on-line zijn. Maar ook voor sommige informatiesystemen in de gezondheidszorg en aanbieders van (inter-)nationale infrastructuur (telefonie, Internet etc.) is dit van belang. 2.1.2 Betrouwbaarheid Betrouwbaarheid is onder te verdelen in drie aspecten: Integriteit, Authenticiteit, Controleerbaarheid. Integriteit Het bewaken van de integriteit van gegevens is ervoor zorgen dat de gegevens ook correct zijn en correct blijven. Informatie is alleen optimaal als zij correct is. Gegevensbanken en bestanden moeten daarom altijd actueel zijn en beschermd zijn tegen ongeoorloofde mutaties [23]. Een situatie waar integriteit van informatie van cruciaal belang is, is de bankwereld. Als een rekeninghouder een bepaald bedrag naar een andere rekening overmaakt, dan wil de rekeninghouder niet dat er van zijn rekening een groter bedrag wordt afgeboekt dan dat er op de andere rekening bijgeschreven wordt. Als dit wel het geval zou zijn, dan zou de integriteit van de informatiesystemen, die voor het overboeken verantwoordelijk zijn, niet in orde zijn. Authenticiteit Bij authenticiteit speelt de vraag, of de informatie wel echt is, een grote rol. Het bewaken van de authenticiteit is er ook voor zorgen dat de informatie daadwerkelijk afkomstig is van personen die zeggen dat de informatie van hun afkomstig is. Controleerbaarheid Om de betrouwbaarheid van een informatiesysteem te waarborgen zal het één en ander gecontroleerd moeten worden. Zoals wie er op het systeem gedurende een bepaalde periode actief was en welke acties deze persoon uitvoerde. [9] 2.1.3 Vertrouwelijkheid & exclusiviteit Vertrouwelijkheid & exclusiviteit omvat het beschermen van gegevens tegen inzage door derden. Het aspect privacy is hierbij ook heel belangrijk. Een voorbeeld zijn de informatiesystemen die door de overheid gebruikt worden. Deze systemen bevatten vaak sofi-nummers waaraan namen en adressen zijn gekoppeld. Om de privacy van de mensen, die in deze systemen voorkomen te waarborgen, is het noodzakelijk dat alleen bepaalde mensen bij deze gegevens mogen. Alleen zo kan voorkomen worden dat de gegevens, door bijvoorbeeld commerciële partijen, misbruikt worden. 2.2 Functies van informatiebeveiliging Bovenstaande doelen kunnen op verschillende manieren bereikt worden, dit zijn de functies van informatiebeveiliging [19] [23]. Deze functies zullen hieronder afzonderlijk besproken worden. 2.2.1 Identificatie Bij identificatie gaat het erom dat de gebruiker zegt wie hij is. Het informatiesysteem en de beheerders weten dan wie het systeem gebruikt [11]. Er wordt echter niet gecontroleerd of de gebruiker daadwerkelijk de persoon is van wie hij zegt dat hij dat is! 2.2.2 Authenticatie Authenticatie is het proces waarbij er gecontroleerd wat de identiteit van de gebruiker van het informatiesysteem is. Er wordt dus gecontroleerd of de gebruiker de persoon is van wie hij zegt dat hij dat is. Normale mensen authenticeren elkaar op vele manieren, door uiterlijk, stemmen of het paspoort [19]. In de informatiebeveiliging gebeurt het vrijwel altijd op basis van een combinatie van een gebruikersnaam en wachtwoord. Maar bij bijvoorbeeld geld- en betaalautomaten vindt de controle plaats op basis van een bankpasje (rekeningnummer) en een pincode [23]. Tegenwoordig worden steeds nieuwere manieren ontwikkeld en toegepast zoals biometrie. Authenticatie komt de beschikbaarheid en continuïteit van informatiesystemen ten goede: de beheerders weten namelijk wie er op het informatiesysteem actief zijn en kunnen ingrijpen als de gebruiker ongewenste handelingen verricht. Ook de betrouwbaarheid van het informatiesysteem en vertrouwelijkheid van de gegevens worden verhoogd als authenticatie toegepast wordt. 2.2.3 Toegangsbeveiliging en autorisatie Autorisatie is het proces wat bepaald in hoeverre een bepaalde gebruiker toegang heeft tot het informatiesysteem, tot de gegevensbronnen. Dit proces wordt door een server afgehandeld. Autorisatie kan per gebruiker of per groep gebruikers geschieden. Omdat bij dit proces het heel belangrijk is om te weten wie de gebruiker is waarvoor de toegang bepaald wordt, moet de gebruiker zich eerst authenticeren. Door het toepassen van autorisatie wordt de betrouwbaarheid en continuïteit van informatiesystemen beter, beheerders van deze systemen kunnen namelijk door autorisatie gebruikers het onmogelijk maken om bepaalde acties uit te voeren. Ook worden de vertrouwelijkheid en exclusiviteit van gegevens, die op het informatiesysteem aanwezig zijn, verhoogd omdat gebruikers alleen toegang kunnen krijgen tot de informatie die voor hen relevant is. 2.2.4 Encryptie/cryptografie & digitale handtekeningen Encryptie wordt gebruikt om informatie te beschermen tegen ongeautoriseerde gebruikers. De informatie kan op een bepaalde plaats versleuteld zijn opgeslagen, maar kan ook tussen twee partijen verstuurd worden. In het laatste geval worden gegevens, die over de verbinding verzonden worden, versleuteld. Het is dan niet meer mogelijk dat ongeautoriseerde gebruikers de verbinding afluisteren om zo informatie te vergaren of dat ongeautoriseerde gebruikers de gegevens, die verzonden worden, veranderen. Er bestaat een verscheidenheid aan algoritmes om gegevens te versleutelen. Encryptie speelt een belangrijke rol bij autorisatie en toegangsbeveiliging. Een digitale handtekening is gebaseerd op encryptietechnieken. Door zo n handtekening is het mogelijk dat de ontvangende partij van informatie weet dat de informatie afkomstig is van de persoon van wie hij zegt dat hij dat is. Een digitale
handtekening is dus een soort van authenticatie! Het komt de betrouwbaarheid van informatie ten goede. Encryptie komt alle doelen van informatiebeveiliging ten goede. 2.2.5 Monitoren/loggen Monitoren of loggen betekent het vastleggen van de handelingen die op het informatiesysteem worden uitgevoerd. Hierdoor kan heel snel nagegaan worden of er handelingen zijn verricht of worden verricht die de gegevens of het gehele informatiesysteem in gevaar brengen [JMC87]. Door monitoren kunnen beschadigingen aan hardware en software op tijd worden ontdekt zodat reparaties kunnen worden uitgevoerd zonder dat het informatiesysteem off-line hoeft te worden gehaald. Door monitoring wordt vooral de betrouwbaarheid en de continuïteit van het informatiesysteem beter. 3. BEVEILIGING VAN INFRASTRUCTUREN TEN BEHOEVE VAN WEBAPPLICATIES Webapplicaties bestaan uit HTML- en/of XML-pagina s, afbeeldingen en scripts. Bijna elke laag van het OSI model bevat mogelijkheden om de infrastructuur, waarop webapplicaties functioneren, te beveiligen. De verschillende lagen van het OSI model kenmerken zich door de verschillende protocollen die het bevat. Voor wat betreft het Internet zijn de protocolstacks op de volgende manier aan het OSI model gerelateerd: OSI laag Applicatie (laag 7) Presentatie (laag 6) Sessie (laag 5) Transport (laag 4) Netwerk (laag 3) Data Link (laag 2) Fysiek (laag 1) Protocol http, Telnet, smtp, FTP SSL, TLS TCP, UDP, ICMP IP, IPv6, IPSEC Ethernet, Token ring, FDDI, ATM UTP, glasvezel In dit artikel zullen alleen de beveiligingsmogelijkheden vanaf laag 3 en hoger besproken worden. De reden hiervoor is, is dat actieve apparatuur die in laag 1 en laag 2 geïmplementeerd wordt, transparant is het voor het Internet en haar applicaties. In dit hoofdstuk zullen de beveiligingsmogelijkheden van de protocollen in het OSI model per laag en per applicatie worden besproken. 3.1 Firewalls Een firewall is software of hardware dat fysiek tussen de web server en de clients worden geplaatst. Het kan bepaalde vormen van IP-verkeer uitselecteren en verbieden of toestaan. Deze vormen van IP-verkeer worden gedefinieerd in een beveiligingsbeleid. Het selecteren van verkeer en het toepassen van het beveiligingsbeleid heet filteren. Firewalls opereren op de applicatielaag, de transportlaag of de netwerklaag van het OSI model. Een op de applicatielaag werkzame firewall is in staat om de elementen van applicatieverkeer (datapakketten) van en naar bepaalde applicaties toe te laten of te blokkeren. Voorbeelden van verkeer wat ze kunnen blokkeren: HTTP, Telnet, FTP etc. Dit gebeurt op basis van de bestemmingsadressen, afzenderadressen en het type applicatie die het datapakket vermeld staan. Ook filteren firewalls vaak op basis van de informatie die bestemd is voor de doelapplicatie. Vaak kunnen application layer firewalls hierdoor aanvallen door virussen voorkomen. Maar ook kunnen ze aanvallen, waarbij ongeldige commando s gebruikt worden, voorkomen. Een firewall die op de transportlaag opereert, kan TCP-, UDPen ICMP-verkeer toestaan of blokkeren op basis van het afzender- en bestemmingsadres of het type protocol (TCP, UDP of ICMP). Op een zelfde manier werkt een firewall die op de netwerklaag opereert, deze kan al dan niet IP, IPv6 en IPsec toestaan op basis van het bron- en doeladres en het protocol. Verder onderscheiden firewalls zich doordat ze statefull of stateless zijn. Een statefull firewall is in staat om van elke verbinding de eigenschappen te onthouden, hele sessies kunnen dus in het geheugen worden bijgehouden. Er kan gedefinieerd worden of een reeks acties wel of niet toegestaan zijn. De voordelen zijn dat zo n firewall veel veiliger en veel meer mogelijkheden biedt. Een stateless firewall houdt de eigenschappen van een verbinding niet bij en controleert per pakket of deze toegestaan is of niet. Verder bieden veel firewalls mogelijkheden om per gebruiker in plaats van per IP-adres toegang te verlenen. Om dit mogelijk te maken wordt de firewall aan een gegevensbank gekoppeld waar gebruikersnamen en wachtwoorden in staan. Voor webapplicaties betekent de inzet van firewalls een verhoogde beschikbaarheid. De webapplicatie wordt door de firewall beschermd tegen virussen en Denial of Service (DoS) aanvallen. Ook wordt de betrouwbaarheid en vertrouwelijkheid verhoogd omdat het mogelijk is alleen bepaalde groepen gebruikers toegang tot de webapplicatie te verlenen. 3.2 Proxies Een proxy server is een dienst die ervoor zorgt dat clients een indirecte netwerkverbinding opzetten met de doelhost waar webapplicaties op draaien. Het grote verschil tussen een firewall en een proxy is dat een proxy server een applicatie server (bijvoorbeeld http, smtp, ftp) maskeert door aanvragen op te vangen en deze door te sturen naar de applicatie server. Het doel van proxies en firewalls is hetzelfde: het afschermen van de web server waar een webapplicatie op draait. HTTPproxies hebben mogelijkheden om veel opgevraagde Internetpagina s op te slaan, te cachen. Een proxy biedt vaak ook mogelijkheden om gebruikers te authenticeren. De proxy server wordt in dat geval aan een gegevensbank met gebruikers gekoppeld. Proxies verhogen de betrouwbaarheid van webapplicaties. Doordat proxies web servers kunnen beschermen tegen aanvallen, is de kans dat een web server tijdens een aanval onbereikbaar wordt, veel kleiner. De mogelijkheden om gebruikers te authenticeren bevordert de vertrouwelijkheid en de betrouwbaarheid van de webapplicatie.
Fysieke plaatsing van een firewall of proxy server 3.3 beveiliging van de verbinding IP security protocol (IPsec) De IP security protocol suite is een verzameling van protocollen wat beveiliging op de netwerklaag kan aanbieden. IPsec biedt een aantal beveiligingsdiensten, zoals: toegangsbeveiliging, authenticiteit op ontvangen data, integriteit op pakketniveau ( connectionless integrity ) en encryptie van data [4]. Deze diensten kunnen worden aangeboden door de twee verschillende beveiligingsprotocollen Authentication Header (AH) en Encapsulating Security Payload (ESP) en door toepassing van speciale sleutel management protocollen. Een IPsec verbinding is geheel transparant voor alle lagen die boven de netwerklaag in het OSI-model staan. Dat komt omdat een IPsec-verbinding eigenlijk een point-to-point verbinding is waarbij IP-pakketten in IPsec-pakketten worden verpakt. Niet alleen hierom is IPsec flexibel, het is ook flexibel omdat een IPsec in transportmodus maar ook in tunnelmodus kan werken. Transportmodus betekent dat aan beide kanten van de IPsecverbinding staat. Tunnelmodus betekent dat aan beide kanten of aan één van beide kanten van de verbinding een security gateway staat. Achter de security gateway is dan een netwerk aanwezig, dit gehele netwerk kan van de IPsec-verbinding gebruik maken. In deze paragraaf werden eerder de twee beveiligingsprotocollen Authentication Header en Encapsulating Security Payload genoemd. Het AH protocol en het ESP protocol bieden beiden authenticatie van de versturende partij en data integriteit. Het belangrijkste verschil tussen het AH protocol en het ESP protocol is dat het ESP protocol wél mogelijkheden heeft om datapakketten te versleutelen en het AH protocol niet [4] [2] [3]. Een groot nadeel van IPsec is dat het niet in staat is om een beveiligingsbeleid toe te passen op het verkeer wat een host binnenkomt en weer uitgaat. Het IPsec protocol kan wel IPverkeer versleutelen en daardoor beschermen tegen het knoeien van data tijdens transport en het kan beschermen tegen het publiek beschikbaar zijn van de gegevens. Maar het kan niet dynamisch controleren welke hosts wel of niet toegang hebben tot sessies of controle uitoefenen op de uitwisseling van bepaalde typen verkeer. Het werkt namelijk via voor geconfigureerde point-to-point verbindingen. Overigens wordt veel onderzoek gedaan om deze problemen op te lossen [7]. Wanneer veel gebruikers elk een beveiligde verbinding naar een webapplicatie moet krijgen, dan moeten heel veel IPsecverbindingen aan de kant van de web server geconfigureerd worden. Dat is niet efficiënt. Als alle gebruikers op een vertrouwd netwerk zitten, de web server op een ander vertrouwd netwerk en tussen de twee netwerken bevindt zich een onbetrouwbaar netwerk, dan is het rendabel om een security gateway ten behoeve van de beveiliging neer te zetten. Wellicht zal in de toekomst de mogelijkheden van IPsec veel breder toegepast kunnen worden als IPv6 grootschalig gebruikt zal worden. In IPv6 is namelijk standaard ondersteuning voor een aantal mogelijkheden welke IPsec biedt, zoals ESP en authenticiteit van data [12]. 3.4 Beveiliging en HTTP Het Hyptertext Transfer Protocol (http) is hét applicatielaag protocol voor het World Wide Web. Het protocol werkt bovenop TCP. Het HTTP-protocol is in twee soorten programma s geïmplementeerd: een client (zoals een web browser) en een server (zoals een web server). HTTP handelt de aanvraag voor een internetpagina af. Met een URL wordt door de client een internetpagina via HTTP bij de web server opgevraagd, een HTTP Request Message. De web server retourneert vervolgens de internetpagina via HTTP aan de client, een HTTP Response Message [6] [19]. In het HTTP protocol zijn mogelijkheden ingebouwd om gebruikers te laten authenticeren voordat de web server de gevraagde gegevens verstuurd [15]. Ook is het mogelijk om HTTP over SSL/TLS te gebruiken. Hieronder zullen beide concepten worden besproken. 3.4.1 HTTP authenticatie Webapplicaties en websites bestaan uit documenten in de vorm van onder andere HTML/XML-pagina s, uitvoerbare scripts en afbeeldingen. Veel webapplicaties en websites vereisen dat de gebruiker een gebruikersnaam en wachtwoord opgeeft voordat de gebruiker toegang krijgt tot de documenten. Het HTTP protocol bevat speciale headers en codes voor authenticatie [19]. Een web server kan per document en per directory gebruikers authenticeren, elk met een eigen authenticatie schema en authenticatie database [15]. Als het eerste document, na authenticatie, is ontvangen, wordt bij elke nieuwe aanvraag voor documenten op de web server de gebruikersnaam en wachtwoord steeds opnieuw verzonden. De gebruikersnaam en wachtwoord kunnen onversleuteld naar de web server worden verstuurd, dit wordt Basic Access Authentication scheme genoemd. Er kan door de beheerders van de web server ook gekozen worden om authenticatie via het Digest Access Authentication scheme te laten plaats vinden. Gebruikersnaam en wachtwoord worden dan eerst via een MD5 algoritme versleuteld. 3.4.2 TLS/SSL TLS is de afkorting voor Transport Layer Security. SSL (Secure Socket Layer) is ontwikkeld door Netscape Communications Corporation en diende als basis voor de ontwikkeling van TLS. Transport Layer Security levert beveiliging bovenop de transportlaag (laag 4 van het OSI model). Het doel van het TLS protocol is het bewaren van privacy en data integriteit wanneer twee partijen met elkaar communiceren [1]. Het TLS protocol bestaat uit twee protocollen. Het TLS Record Protocol is een protocol wat bovenop een transportprotocol werkt. De data wordt met behulp van symmetrische sleutels versleuteld (encryptie). Deze sleutels zijn voor elke verbinding uniek. Uitwisseling van sleutels gebeurd door het TLS Handshake Protocol. De betrouwbaarheid van de data wordt gegarandeerd door gebruik te maken van hash functies. Het TLS Record protocol wordt gebruikt om protocollen op de applicatielaag van het OSI model, zoals HTTP, te beveiligen. Om een beveiligde verbinding te initiëren, moet zowel de client (bijvoorbeeld een web browser) als ook de web server TLS ondersteunen [26].
3.4.3 S-HTTP Het Secure Hypertext Transfer Protocol is een experimenteel protocol. Het biedt verschillende mogelijkheden voor beveiliging van HTTP clients en servers. S-HTTP ondersteunt veilige transacties van begin- tot eindpunt [27]. Het maakt daarvoor gebruik van symmetrische sleutels. S-HTTP biedt zeer veel flexibiliteit voor cryptografie-algoritmen: als de client en de server er maar over eens worden. Het doel van S-http is het beveiligen van http berichten op drie fronten: authenticiteit, data integriteit en geheimhouding (bewaren van privacy over de data door toepassing van encryptie). Een bericht kan ondertekend worden, op authenticiteit gecontroleerd worden of versleuteld worden. 3.4.4 HTTP beveiliging en webapplicaties Webapplicaties en Web services kunnen dus beveiligd worden door toepassing van HTTP authenticatie en/of Transport Layer Security. In het eerste geval kan de beheerder van de webapplicatie regelen dat bepaalde gebruikers alleen maar toegang hebben tot bepaalde scripts, HTML-pagina s en afbeeldingen. Door de webapplicatie zo te ontwikkelen dat elk script een bepaalde functie van de webapplicatie afhandelt, is het mogelijk dat ontwikkelaars en beheerders op die manier gebruikersrechten van gebruikers regelen. Door toepassing van Transport Layer Security in client en web server is de verbinding tussen gebruiker en webapplicatie te beveiligen tegen afluisteren en ongewenst veranderen van gegevens tijdens verzending. Beveiliging op netwerklaag en op transportlaag. 4. BEVEILIGING VAN WEB SERVICES Web services bieden mogelijkheden om functies van andere applicaties via het World Wide Web beschikbaar te stellen [14]. De interface tot functies van applicaties zijn op XML gebaseerd. Een programma zendt een bericht in de vorm van een XML document voor een aanvraag naar de Web service. Eventueel kan de Web Service antwoorden door een XML document terug te sturen [25]. De Web services technologie kent in heel veel verschillende situaties een toepassing. Zo kunnen onderdelen van Web services op desktopsystemen en PDA s draaien om toegang te krijgen tot Internet applicaties als reserveringssystemen en Internetshops. Maar het is ook mogelijk om Web services toe te passen om bedrijfssystemen aan elkaar te koppelen of te integreren waardoor Electronic Data Interchange (EDI) eenvoudiger wordt en daarmee business-to-business commerce en supply chain management bevorderd wordt [21]. Maar Web services kunnen ook grotere en bredere problemen oplossen. Bijvoorbeeld Enterprise Application Integration, die vele verschillende applicaties van de ene organisatie met applicaties van een andere organisatie verbindt of ze zelfs integreert. In de volgende paragraaf over Web services wordt daar verder op in gegaan. Ook zal er worden uitgelegd op welke technologieën Web services gebaseerd zijn. Vanaf de tweede paragraaf van dit hoofdstuk zal beschreven worden welke mechanismen er zijn om XML documenten te beveiligen. 4.1 Techniek van Web services Web services overkoepelen applicaties en systemen ze vormen een wrap. Vele back-end systemen zoals database management systems,.net, J2EE, CORBA, objecten, adapters van Enterprise Resource Planning pakketten (Peoplesoft, SAP) en anderen worden naar de buitenwereld gepresenteerd als één geheel. Web services kunnen in veel verschillende programmeertalen worden ontwikkeld en ze kunnen op elk type hardware, besturingssystemen en middleware systemen worden uitgevoerd. Web services combineren dus de eigenschappen van het Internet qua abstractie met de eigenschappen van traditionele applicaties. Web services zijn gebaseerd op bestaande Internetinfrastructuren. De communicatie binnen Web services gaat via HTTP of een ander applicatieprotocol bovenop TCP en er wordt gebruik gemaakt van web servers waaraan speciale applicatie servers zijn gekoppeld die de binnenkomende data verwerken. Onderdelen van Web services worden, net als traditionele Internetpagina s ook aangeroepen met URL s. Ze worden ook op dezelfde manier verkregen door middel van een HTTP commando en een URL. Het verschil tussen het Web services en traditionele Internetpagina s en webapplicaties is dat Web services gebruik maken van XML documenten in plaats van HTML documenten. Web services zijn afhankelijk van verschillende (beschrijvings-) talen en protocollen. Zoals SOAP voor het uitwisselen van XML berichten over HTTP, WSDL voor het beschrijven van de interfaces van Web services en UDDI is een mechanisme om ervoor te zorgen dat gebruikers een Web service op het Internet kunnen vinden. Hieronder volgt een uitgebreidere uitleg over SOAP: De SOAP 1.2 standaard bestaat uit twee delen. Deel 1 specificeert een framework voor XML gebaseerde communicatie. SOAP berichten kunnen volgens deze specificatie uitgewisseld worden over HTTP, SMTP, FTP, RMI/IIOP of een proprietary applicatieprotocol. Deel 2 specificeert enkele optionele componenten, zoals regels om datatypen, die door applicaties gedefinieerd worden, te verwerken in een bericht. Ook specificeert het aanvragen en antwoorden voor RPC [8] [16]. SOAP dient dus als een soort envelop van XML berichten die via een applicatieprotocol als HTTP, SMTP en FTP worden verstuurd. Voorbeeld: SOAP verzendt via een HTTP aanvraag een XML bericht naar de web server. De web server, bijvoorbeeld Apache of Microsoft Internet Information Server, antwoordt met een HTTP bericht met daarin eventueel een XML bericht. De betreffende web server moet zijn uitgerust met een SOAP processor om de XML berichten te kunnen valideren, te interpreteren en ook om SOAP berichten te genereren waarna ze door de web server verstuurd kunnen worden. 4.2 XML Document Access Control Damiani et al. hebben in 2002 een voorstel gedaan voor een toegangscontrolesysteem voor XML documenten [10]. Het
model gaat er vanuit dat een gebruiker een XML document van een web server wil ophalen. Als de gebruiker zich geauthenticeerd heeft en de aanvraag voor het XML document heeft verstuurd, dan gaat de Access Control Processor (ACP) op de web server na tot welk deel van het betreffende XML document de gebruiker geautoriseerd is. Het model maakt onderscheidt tussen subjecten, objecten, acties, signs en het domein waar de rechten op objecten werkzaam zijn. Subjecten zijn groepen gebruikers, individuele gebruikers of computers die door een IP adres of een domeinnaam gekenmerkt worden. Het gedeelte van een document waar een gebruiker toegang tot heeft (het object) wordt gespecificeerd door een XPath expressie. De acties definiëren wat een gebruiker met het XML document mag doen. Schematisch overzicht Web service De acties kunnen zijn: lezen, invoegen, verwijderen en bijwerken van een node. De signs zeggen of de gebruiker wel geautoriseerd moet worden of dat juist autorisatie geweigerd moet worden. Verder geeft het domein de scoop van documenten en elementen aan waarover de rechten gelden. De toegangsrechten kunnen gelden voor een individueel document of het kan gelden voor documenten die een instantie van een Document Type Definition (DTD) zijn. Ook kunnen de rechten over een node lokaal werken (lokale autorisatie) of ze kunnen recursief over een boom van nodes werken (recursieve autorisatie). Het bovenstaande is een model. Kudu en Hada hebben een access control language ontwikkeld om een beveiligingsbeleid te kunnen specificeren. Bovendien breidden Kudu en Hada het model uit met mogelijkheden voor voorwaardelijke autorisatie [18]. Een voorbeeld van voorwaardelijke autorisatie is: U krijgt toegang tot deze gevoelige informatie mits u de volgende verklaring ondertekend. Het ontwerp van Damiani et al. gaat uit van het op de server transformeren van het XML document tot een document waar de gebruiker toegangsrechten heeft. Dit transformeren gebeurt server-side door een ACP. Deze ACP maakt gebruik van de Document Object Model API. Van het ontwerp is een Java implementatie gemaakt, op een Apache web server draaien een aantal servlets die de transformatie verzorgen. Voor Web services betekent toepassing van XML Document Access Control dat XML berichten in de SOAP berichten beveiligd kunnen worden. Op de XML berichten in SOAP berichten kan toegangscontrole toegepast worden. 4.3 SAML en XACML SAML is een framework om informatie over authenticatie, autorisatie en andere eigenschappen van de eindgebruiker te kunnen specificeren [30]. Door deze drie mogelijkheden te combineren ontstaat er een beperkt model voor toegangscontrole. SAML staat voor Security Assertions Markup Language. SAML biedt zelf geen authenticatie aan, wel houdt het informatie over succesvolle authenticaties uit het verleden bij. Daardoor zijn Web services in staat om single sign-on te ondersteunen [28]. SAML kan deze succesvolle authenticaties uitdrukken en deze kunnen via SOAP doorgestuurd worden naar andere onderdelen van de Web service waardoor de gebruiker bij deze onderdelen zich niet meer hoeft te authenticeren. XACML is ontworpen om autorisatiesystemen te ondersteunen. Het is gebaseerd op het werk van Damiani en Kudo. De syntax van XACML kan een toegangsbeleid uitdrukken. XACML is de afkorting voor extensible Access Control Markup Language. Een XACML beleid bestaat uit een boom met een doel die uit verschillende subbeleidsregels bestaat, de bladeren definiëren de regels [22]. Door deze opzet is men met XACML in staat om een heel gedetailleerd beveiligingsbeleid, met hele verschillende ingewikkelde regels, te definiëren. Verder specificeert de XACML syntax een vraag/antwoord model voor toegangsaanvragen. XACML is ontworpen om krachtige bescherming te bieden, flexibel te zijn en met veel verschillende vertrouwensdomeinen om te kunnen gaan. Maar het is zeker geen compleet autorisatie oplossing. Het is bijvoorbeeld niet in staat om beleidsregels in een gegevensbank om te zetten naar specifieke toegangsregels en deze toe te passen op een informatiesysteem of een XML document. Een ACP is in staat om dit wel te doen, maar kan niet met een gedistribueerde omgeving overweg. XACML ondersteunt daarin het model van Kudo en Damiani e.a. Er bestonden geen beleidstalen zoals XACML die leverancieronafhankelijk waren én autorisatie voor gedistribueerde systemen in verschillende administratieve domeinen konden bieden. SAML kan in combinatie met XACML worden gebruikt, een autorisatiebeslissing in SAML kan gebaseerd zijn op een XACML beleid.
4.4 XML Encryptie XML Encryptie is een specificatie van W3C en het specificeert een manier om elke vorm van data (element) binnen een XML document te versleutelen [17]. Voor de operaties van encryptie en decryptie zijn de applicaties verantwoordelijk. Wanneer elementen in een XML document versleuteld worden, wordt het element vervangen door een EncryptedData element. XML encryptie maakt gebruik van bestaande cryptografietechnieken. XML Encryptie is geen vervanging voor HTTP over TLS/SSL [28]. Als de gegevens die verstuurd worden niet alleen over een enkele HTTP verbinding verstuurd worden, maar over veel verschillende verbinding, dan is XML encryptie ideaal voor de vertrouwelijkheid en betrouwbaarheid van de gegevens. 4.5 XML Signature XML Signature is een technologie die niet alleen toegepast kan worden op XML documenten, het kan ook gebruikt worden om andere vormen van data te ondertekenen. Voor Web services biedt XML Signature vele voordelen: ze verzekeren gebruikers ervan dat data niet is gewijzigd, vernietigd of op een andere manier verloren is gegaan. Ook biedt XML Signature authenticatie aan: de ontvanger kan zien wie het document versleuteld heeft en daarmee van wie het XML document afkomstig is. XML Signature is zowel een draft standard van de IETF [13] als ook een specificatie van W3C [5]. De kracht van XML Signature is dat het in staat is om, net als bij XML Encryptie, alleen bepaalde delen van XML documenten of gehele XML documenten te ondertekenen. Digitale handtekeningen voor XML documenten worden door het Signature element aangegeven. Net als bij XML Encryptie, maakt XML Signature gebruik van bestaande cryptografie technieken als SHA-1 en HMAC. Als XML Signatures in SOAP berichten toegepast worden, is de integriteit van berichten hierdoor van beginpunt tot eindpunt in een Web service gegarandeerd. XML Encryptie en XML Signature gebruiken beide sleutels. De publieke sleutels moeten over verschillende systemen gedistribueerd worden. Hiervoor wordt XML Key Management Specification (XKMS) ingezet. 4.6 XML Firewalls XML Firewalls gaan een stap verder dan firewalls die op de applicatielaag van het OSI model opereren. XML Firewalls zijn in staat om XML-verkeer filteren. XML Firewalls kunnen worden ingezet om Web services, operaties, gebruikers (service aanvragers), XML/SOAP berichten en URL s te controleren [31]. In plaats van dat traditionele firewalls applicatieverkeer als HTTP filteren, filteren XML Firewalls complete SOAP verkeersstromen. Ze controleren of een XML bericht wel toegang tot een specifieke operatie van een Web service mag krijgen. Regels voor XML Firewalls worden in een XML schema gedefinieerd [28]. Een schema voor een XML Firewall geeft de opbouw van een XML document, die wel of geen toegang krijgt, weer. 5. VOOR- EN NADELEN BEVEILIGING INFRASTRUCTUUR In de volgende paragrafen zullen de voor- en nadelen van het beveiligen van Internetinfrastructuren uiteengezet worden. 5.1 Firewalls en proxies Ze bieden een goede beveiliging qua beschikbaarheid en continuïteit door beveiliging vanaf laag 3 tot en met laag 7 van het OSI model. Firewalls en proxies zijn transparant voor verkeer boven de applicatielaag (XML documenten / HTML documenten) Firewalls en proxies kunnen niet op inhoud van applicatieverkeer (XML / HTML) filteren. Verkeer wat applicatieprotocol overschrijdend is, kan niet gefilterd worden. Firewalls / proxies zijn niet flexibel qua configuratie van regels. Bij veel netwerken en verschillende typen verkeer moeten al snel veel regels gedefinieerd worden. Dat is niet te beheren. Om deze twee redenen zijn firewalls minder geschikt voor Web services. 5.2 IPsec IPsec is transparant voor verkeer boven de netwerklaag. Daardoor ideaal voor Web services wanneer er meerdere applicatieprotocollen worden gebruikt. Verder is IPsec verkeer snel te verwerken daardoor grote bandbreedte. Aanschaf van aparte security gateways kost geld. Of de performance gaat achteruit als IPsec op het informatiesysteem zelf wordt toegepast. Bij veel point-to-point verbindingen met clients en informatiesystemen is er veel configuratiewerk, daardoor minder geschikt voor Web services 5.3 HTTP authenticatie Het biedt veilige authenticatie en autorisatie voor bestanden en directories op bestandssysteemniveau. De configuratie biedt zeer beperkte mogelijkheden en is inflexibel. Daardoor minder geschikt voor grote omgevingen. Verder is autorisatie niet mogelijk op delen van bestanden. 5.4 HTTP TLS/SSL/S-http Het biedt veilige cryptografie voor HTTP verbindingen. Het verhoogt de betrouwbaarheid en vertrouwelijkheid. Verder is de beveiliging transparant voor verkeer van boven de applicatielaag (XML- en HTML documenten). Het is daardoor een efficiënte manier van beveiliging als gehele documenten verstuurd worden. Het biedt alleen integriteit en privacy van gegevens die via HTTP verstuurd worden en niet voor gegevens die via een ander applicatieprotocol (SMTP) verstuurd worden. Web services maken niet alleen gebruik van HTTP. 6. VOOR EN NADELEN BEVEILIGING WEB SERVICES In de volgende paragrafen zullen de voor- en nadelen van het beveiligen van XML gebaseerde Web services uiteengezet worden. 6.1 SAML en XACML
XACML maakt gedetailleerde autorisatie voor veel verschillende informatiesystemen (gedistribueerde omgeving) eenvoudiger door een standaard beleidstaal en een vraag/antwoord model. Dit maakt beveiliging van XACML meer schaalbaar en flexibel. Het voordeel van SAML is, is dat het de implementatie van single sign-on vereenvoudigt. Er wordt niet gespecificeerd hoe beleidsregels toegepast moeten worden, het is dus geen totaaloplossing. Een tweede nadeel is dat de flexibiliteit van XACML het de beveiligingsarchitectuur complex maakt. Door de complexiteit is het veel werk om het te implementeren en te beheren. 6.2 XML Document Access Control XML Document Access Control kan exclusieve toegang tot elementen van XML documenten mogelijk maken (autorisatie). Aan autorisatie kunnen ook nog eens extra voorwaarden worden gekoppeld. Een tweede voordeel is dat de technologie tijdens het gehele bestaan van een XML document, en dus ook de informatie, beschermt. Het laatste voordeel is dat de technologie zeer schaalbaar is, het kan zeer snel op andere informatiesystemen geïmplementeerd worden. De toegangstijd voor het opvragen van een document neemt door de extra controles en het genereren van een document, met gegevens waar de gebruiker toegang tot heeft, merkbaar toe [24]. Een groot nadeel is dat het implementeren en beheren zeer complex is en het veel tijd kost, zeker in combinatie met XACML en SAML. 6.3 XML Encryptie XML Encryptie biedt selectieve bescherming van gegevens in documenten. Alleen bepaalde delen van een document kunnen versleuteld worden terwijl andere delen gewoon leesbaar zijn. Een tweede voordeel is dat de technologie tijdens het gehele bestaan van een XML document, en dus ook de informatie, beschermt. Een ander voordeel is de schaalbaarheid: XML Encryptie legt geen beperkingen op als extra informatiesystemen aan een Web service worden toegevoegd. Er is overhead qua opslag en verwerking van het XML document. Opslag, omdat er aan elke node die versleuteld wordt er informatie aan toe wordt gevoegd. Het document wordt daardoor groter. Verwerking, omdat elke node met een ander algoritme versleuteld kan worden. Al deze algoritmen moeten apart geladen en toegepast worden. 6.4 XML Signature Alleen bepaalde delen van documenten kunnen ondertekend worden. Hierdoor kunnen delen van het document van een andere afzender afkomstig zijn. In sommige situaties is dit zeer wenselijk, bijvoorbeeld een document waarvan meerdere bedrijven de auteur zijn. Een ander voordeel is dat het beveiliging biedt tijdens het bestaan van het XML document. Het laatste voordeel van XML Signature is schaalbaarheid. Het nadeel van XML Signature is dat er extra overhead is qua verwerking en opslag van het document, zie XML Encryptie. 6.5 XML Firewalls Een groot voordeel van XML Firewalls is de flexibiliteit, zowel qua fysieke plaatsing als het bepalen welke gegevens van en naar een Web service gestuurd mogen worden. Een ander voordeel is de schaalbaarheid: XML Encryptie legt geen beperkingen op als extra informatiesystemen aan een Web service worden toegevoegd. Het nadeel is dat de aanschafkosten van XML Firewalls erg hoog zijn. 7. CRITERIA VOOR EEN ORGANISATIE In eerste instantie moet een organisatie zich afvragen waarom en tegen welke risico s ze haar Web services wil beveiligen, er moeten dus doelen worden opgesteld. Vervolgens moet bepaald worden via welke mechanismen, functies van informatiebeveiliging, deze doelen bereikt kunnen worden. Nadat deze twee stappen zijn ondernomen, kan er naar een technische oplossing gezocht worden. Een technische oplossing is soms direct te kiezen op basis van bepaalde voordelen of nadelen van beveiligingstechnologieën. In dit soort situaties is de keuze voor een bepaalde technologie eenvoudig. Voorbeeld: een bedrijf heeft een Web service in huis waar talloze informatiesystemen (ook van andere organisaties) aan zijn gekoppeld. De gegevens die uitgewisseld worden moeten openbaar zijn en gedeelten moeten geheim blijven. XML Encryptie is hier de oplossing: het kan gegevens selectief versleutelen en het gaat flexibel om met grote hoeveelheden systemen. In sommige situaties is de keus moeilijker en moet er een afweging tussen voordelen en nadelen worden gemaakt. Uit de voor- en nadelen uit de vorige twee hoofdstukken onderscheiden zich hoofdzakelijk op de onderstaande criteria. Bij deze criteria wordt heel globaal aangegeven of XML beveiliging of beveiliging van infrastructuur de voorkeur heeft. Deze voorkeuren worden heel globaal aangegeven omdat ze afhankelijk zijn van de implementatie van de Web service (.Net, J2EE etcetera). - Schaalbaarheid / samenwerking met andere systemen Beveiliging van XML documenten is meer schaalbaar dan beveiliging van infrastructuur. De beveiliging van infrastructuur werkt altijd tussen informatiesystemen, terwijl XML documenten informatiesystemen overschrijdend zijn (en dus ook de beveiliging ervan). Verder is XML een standaard waar veel systemen compatible mee zijn. Voor infrastructurele beveiligingen zijn veel meer standaarden en lang niet elk type systeem is er compatible mee. - Flexibiliteit wat betreft instellen en definiëren van beveiligingsobjecten / subjecten. Bij op XML gebaseerde beveiliging is over het algemeen het beveiligingsobject veel specifieker te specificeren dan bij infrastructurele beveiliging. - Flexibiliteit qua beveiliging van meerdere applicatieprotocollen tegelijk. Infrastructurele beveiliging geniet nu de voorkeur. IPsec kan bijvoorbeeld alle applicatieprotocollen beveiligen. - Performance van informatiesystemen (responstijd)
De verwerkingstijd voor een beveiligd XML document is hoog. Infrastructurele beveiliging is relatief snel (ook door specifieke hardware). - Bandbreedteverbruik XML documenten worden groter als beveiligingsgerelateerde tags ingevoegd worden. Bij infrastructurele beveiliging zijn deze tags niet nodig. - Complexiteit / Implementatietijd Een web server uitrusten met TLS of het plaatsen van een security gateway is veel sneller uitgevoerd dan het implementeren van XML beveiliging in applicaties. - Kosten Door de complexiteit zijn de kosten voor Web services met een XML beveiliging hoger dan de kosten voor infrastructurele beveiliging. De criteria zijn objectief / meetbaar voor elke implementatie of vergelijkbare implementatie van een Web service. Als alleen deze criteria bij het afwegingsproces betrokken worden, dan moeten ook alleen beveiligingstechnologieën tegen elkaar afgewogen worden die hetzelfde doel van informatiebeveiliging hebben, bijvoorbeeld XML Encryptie en HTTP/TLS. Als bij het keuzeproces beveiligingstechnologieën betrokken worden die een ander doel nastreven, dan moeten ook de doelen van informatiebeveiliging als criteria bij het keuzeproces worden beschouwd. Vervolgens kan er voor de toekomstige Web service een tabel opgesteld worden. In deze tabel staan de criteria en beveiligingsalternatieven tegenover elkaar. Op basis van soortgelijke implementaties van andere Web services krijgt een combinatie van criterium en beveiligingsalternatief een (meetbare) waarde ingevuld [20]. Om tot een keuze te komen, moeten organisaties aan de criteria prioriteiten toekennen. De definitieve keuze wordt bepaald door elk criterium te vermenigvuldigen met elke prioriteit en vervolgens de producten te sommeren. De technologie met de hoogste uitkomst is dan de beste keus. Voorbeeld: In onderstaand voorbeeld is XML Encryptie de beste keus. Schaalbaarheid Flexibiliteit Performance Bandbreedte Complexiteit Kosten Totaal criterium * prioriteit HTTP/TLS 1 5 10 10 1 10 261 XML Encryptie 10 5 5 1 15 30 432 prioriteit 10 9 8 7 6 5 8. CONCLUSIE Er bestaan veel mogelijkheden voor de beveiliging van informatie binnen Web services. Traditionele standaarden en protocollen kunnen worden ingezet om Web services te beveiligen, maar ook nieuwe technologieën kunnen worden ingezet om XML documenten te beveiligen. De verschillende alternatieven hebben allemaal voor- en nadelen. De hoofdvraag is welke beveiligingstechnologie moet in een bepaalde situatie gekozen worden. En is dat het aanbrengen van beveiliging in Internet-infrastructuren of toch in XML documenten? Het blijkt dat in veel situaties deze beslissing toch vrij eenvoudig is. Vaak geeft een bepaald voordeel, nadeel of een eigenschap van een technologie de doorslag om een beveiligingstechnologie toe te passen. Door voordelen en nadelen van de verschillende technologieën goed naast elkaar te leggen, blijkt ook dat beveiliging in de Internet-infrastructuren en beveiliging van XML documenten elkaar kunnen aanvullen. Echter in situaties waar voordelen de nadelen neutraliseren, is de keuze voor het toepassen van een (combinatie van) beveiligingstechnologieën niet direct duidelijk. Dan moet er gekozen worden uit van één of meer verschillende beveiligingstechnologieën. Door objectieve criteria te definiëren en aan de criteria prioriteiten te koppelen voor een bepaalde implementatie, wordt duidelijk voor welke beveiligingstechnologie een organisatie moet kiezen. Dit onderzoek heeft helaas niet kunnen aantonen of deze methode ook haalbaar en/of zinvol is door middel van een survey onder bedrijven. Gezien de opkomst van Web services, de ontwikkelingen van XML beveiliging en de toename van zeer snelle hoogwaardige Internetverbindingen, zal in de toekomst alleen de complexiteit van XML beveiliging een bezwaar voor toepassing in Web services kunnen vormen. Door meer onderzoek naar toepassingen van XML beveiliging en als XML beveiliging vaker toegepast wordt, zal wellicht de complexiteit ervan doen afnemen en zal XML beveiliging op den duur dé manier van beveiligen van Web services zijn. LITERATUURLIJST [1] Allen, C. en Dierks, T. The TLS Protocol. The Internet Society, 1999, http://www.rfc.net/rfc2246.txt [2] Atkinson, R. en Kent S. IP Authentication Header. The Internet Society, 1998, http://www.rfc.net/rfc2402.txt [3] Atkinson, R. en Kent S. IP Encapsulating Security Payload (ESP). The Internet Society, 1998, http://www.rfc.net/rfc2406.txt [4] Atkinson, R. en Kent S. Security Architecture for the Internet Protocol. The Internet Society, 1998, http://www.rfc.net/rfc2401.txt [5] Bartel, M. e.a. (Red.) XML-Signature Syntax and Processing W3C Recommendation, World Wide Web Consortium, 2002, http://www.w3.org/tr/xmldsig-core/
[6] Berners-Lee, T. e.a. Hypertext Transfer Protocol -- HTTP/1.1. The Internet Society, 1999, http://www.rfc.net/rfc2616.txt [7] Blaze, M. e.a. Trust Management for IPsec. In ACM Transactions on Information and System Security, Vol. 5, No. 2. ACM Press, New York, NY, 2002, 95-118. [8] Booth, D. e.a. (Red.). Web Services Architecture. World Wide Web Consortium, 2004, http://www.w3.org/tr/ws-arch/ [9] Carroll, J.M. Computer Security second edition. Butterworths Publishers, Stoneham, MA, 1987, 12-13. [10] Damiani, E. e.a. A Fine-Grained Access Control System for XML Documents. In ACM Transactions on Information and System Security, Vol. 5, No. 2, ACM Press, New York, May 2002, 169-202. [11] Davies, D.W. en Price, W.L. Security for Computer Networks. John Wiley & Sons, 1989, 169-170. [12] Deering, S. en Hinden, R. Internet Protocol, Version 6 (IPv6) Specification. The Internet Society, 1998, http://www.rfc.net/rfc2460.txt [13] Eastlake 3rd, D., Reagle, J. en Solo D. (Extensible Markup Language) XML-Signature Syntax and Processing. The Internet Society, 2002, http://www.rfc.net/rfc3275.txt [14] Eck, P. Architecture of Information Systems Lecture 7: Web services (hoorcollegesheets). University of Twente, [15] Franks J. e.a. HTTP Authentication: Basic and Digest Access Authentication. The Internet Society, 1999, http://www.rfc.net/rfc2617.txt [16] Gudgin, M. e.a. (Red.), SOAP Version 1.2 Part 2: Adjuncts. World Wide Web Consortium, 2003, http://www.w3.org/tr/2003/rec-soap12-part2-20030624 [17] Imamura, T. e.a. (Red.) XML Encryption Syntax and Processing W3C Recommendation, 2002, http://www.w3.org/tr/xmlenc-core/ [18] Kudo, M. en Hada, S. XML Document Security based on Provisional Authorization. In Proceedings of the 7th ACM conference on Computer and communications security (Athens, Greece), ACM Press, New York, NY, USA, 2000, 87 96. [19] Kurose, J.F en Ross, K.W. Computer Networking: A top-down appraoach featuring the internet. Addison-Wesley, 2001, 84-95 and 565-621. [20] Laganière R. en Lethbridge T., Object-Oriented Software Engineering, McGraw-Hill, Berkshire, United Kingdom, 2001, 293-346. [21] Laudon, K.C. and Laudon J.P., Management Information Systems sixth edition. Prentice Hall, New Jersey, 2000, 281-282. [22] Lepro, M. e.a. First Experiences Using XACML for Access Control in Distributed Systems. In Proceedings of the ACM Workshop on XML Security (Fairfax, VA, USA, October 31, 2003). ACM Press, New York, NY, 2003, 25-37. [23] Lewis, P.M., Bernstein, A. Kifer, M. Databases and Transaction Processing An application-oriented approach. Addison-Wesley, 2002, 915-947. [24] Lim, C. H. en Son, S. H. Access Control of XML Documents Considering Update Operations. In Proceedings of the ACM Workshop on XML Security (Fairfax, VA, USA, October 31, 2003). ACM Press, New York, NY, 2003, 49-59. [25] Newcomers, E. Understanding Web Services. Addison-Wesley, 2002, 1 80. [26] Rescorla, E. HTTP Over TLS. The Internet Society, 2000, http://www.rfc.net/rfc2818.txt [27] Rescorla, E. en Schiffman, A. The Secure HyperText Transfer Protocol. The Internet Society, 1999, http://www.rfc.net/rfc2660.txt [28] O Neill, M. e.a. Web Services Security. McGraw-Hill Osborne Media, 2003, 42-60. [29] Thiadens, T. Beheer van ICT-voorzieningen derde herziene uitgave. Academic Service, 2000, 224-240. [30] VeriSign Inc. VeriSign Digital Trust Services: Enabling Trusted Web Services. 2003. http://www.verisign.com/resources/wp/webservices/enable/ena ble.pdf [31] Westbridge Technology Inc. XML Firewall (whitepaper), Westbridge Technology, 2004, http://www.westbridgetech.com/downloads/westbridgexmla pplicationfirewall.pdf