Webservices gateways
Op dit moment is de focus van Webservices security sterk gericht op de functionele kant, zoals deze is beschreven in voorgaande paragrafen. Er is veel aandacht in de markt voor de nieuwe protocollen waarmee vertrouwensrelaties kunnen worden opgezet. Veel minder aandacht gaat echter uit naar het managen van nieuwe gevaren en bekende bedreigingen, zoals denial of service aanvallen, buffer overflows, spoofing, replay aanvallen, virussen en wormen. Wat dit betreft is er niets nieuws onder de zon. Webservices zijn, net zoals andere technologieën, ook kwetsbaar voor dit soort aanvallen. Daar komt nog bij dat traditionele beveiligingsmaatregelen in veel gevallen niet voldoende bescherming bieden tegen kwaadaardige SOAP/XML berichten, gezien het tunnelende karakter van SOAP.

Indien HTTP als transportprotocol wordt ingezet, is een SOAP endpoint toegankelijk via een enkelvoudige unieke URL. Een dergelijk endpoint kan meer functies leveren via dezelfde URL. Het filteren op alleen URL’s ten behoeve van toegangscontrole heeft weinig zin omdat de parameteroverdracht in de HTTP namespace plaatsvindt via HTTP POST en niet via de URL. Een conventionele firewall, die op laag 2 of 3 opereert, is niet voldoende om afdoende bescherming te bieden. Er is behoefte aan contentinspectie en toegangscontrole op OSI-laag 7 (applicatielaag). Moderne firewalls kunnen tot en met de applicatielaag filteren, maar alleen het detecteren van XML berichten is niet genoeg. Men moet in staat zijn om op basis van de inhoud van individuele SOAP/XML berichten en de WSDL definities, een beslissing te nemen of het geautoriseerd verkeer betreft die valide functies benadert met geldige parameters.

Met andere woorden, welke functieaanroepen worden er gedaan naar welke Webservices, met welke parameters en door wie of wat? Daarnaast is er een groeiende intentie om de versleuteling van SOAP berichten niet door de Webservice of applicatie te laten verrichten, maar apart te beleggen in een zogenaamde Webservices gateway (zie figuur 14 hierna). Op deze manier ontlast je applicatieontwikkelaars en kan je deze cryptografische toepassingen beleggen in een andere laag en door specialisten laten inrichten en beheren.

Figuur 14. Webservices security gateway

Sommige organisaties geven echter de voorkeur aan het implementeren van het toegangscontrolemechanisme in de SOAP service zelf. Dit kent een aantal nadelen. Ten eerste wordt verwacht dat je de totale controle hebt over de SOAP service, hetgeen lastig wordt met componenten van derden die zijn aangekocht en waarvan je geen broncode hebt. Daarnaast vereist het vaak fundamentele wijzigingen in de SOAP service logica, ondersteuning voor XML authenticatieschema’s en stelt het speciale eisen aan de kennis en kunde van je ontwikkelaars. Er is afgelopen jaren een nichemarkt ontstaan voor een speciaal soort oplossingen. Een handvol fabrikanten, veelal onbekend, leveren speciale Webservices gateway oplossingen die in staat zijn om in- en uitgaande SOAP berichten te interpreteren, te inspecteren, te valideren, te authenticeren, te autoriseren en te routeren (figuur 14). Daarnaast moeten deze gateways in staat zijn om XML elementen te versleutelen of digitaal te ondertekenen.

Om dit alles te kunnen realiseren is XML contentinspectie en XML schema validatie noodzakelijk. Ook moet er ondersteuning zijn voor WSDL en UDDI, alsmede andere infrastructurele componenten zoals PKI voor sleutelmanagement en LDAP als identiteitendatabase. Tenslotte moeten deze oplossingen ook de nieuwe XML en Webservices security initiatieven ondersteunen, zoals XML Encryption, XML Signature, WS-Security en SAML. Al deze vereisten zorgen er voor dat een Webservices gateway uitgroeit tot een zeer complexe firewalloplossing. Veelal worden Webservices gateways geïmplementeerd in speciale hardware, zogenaamde appliances, waarbij andere zaken zoals performance ook een grote rol spelen.,Conclusies
Webservices security is een nieuw security paradigma. De verandering is fundamenteel. Er zal steeds meer machine-naar-machine interactie ontstaan. Denk hierbij aan Grid toepassingen, waarbij Webservices technologie een grote rol speelt. De bedreigingen en uitdagingen op beveiligingsgebied zijn echter precies dezelfde als die we enkele jaren geleden hadden met andere technologieën. Webservices is een belangrijke evolutie en organisaties zouden tijd moeten gaan besteden aan het begrijpen van deze nieuwe technologie als onderdeel van hun ontwikkelactiviteiten en hun strategische productselectieproces.

Figuur 15. Overzicht Webservices security volwassenheid

Webservices security is momenteel nog een bewegend doel. De meeste initiatieven zijn nog volop in ontwikkeling en fabrikanten en diverse consortiums werken hard aan standaardisatie (figuur 15). Onafhankelijke instituten spelen een cruciale rol in het standaardisatieproces van deze nieuwe protocollen met als algemeen belang een brede acceptatie door de markt. De huidige inspanningen zijn pas de eerste stappen naar het beveiligingen van individuele (XML) berichten. Het belangrijkste Webservices security raamwerk WS-Security is nu officieel overgedragen aan OASIS. Het raamwerk is echter nog niet helemaal gereed en het is wachten op de laatste specificaties.

De WS-Security productimplementaties van verschillende leveranciers leveren nu alleen nog maar een basisniveau aan beveiliging. Wat ontbreekt is het mechanisme om te onderhandelen over de restricties waaraan aanbieders en afnemers zich conformeren. De basis bouwblokken leveren op het moment alleen maar functies om cryptografie te kunnen gebruiken binnen XML berichten en om op een transparante manier security tokens te transporteren. Dit is ook een van de karakteristieken van Webservices security; het (her)gebruiken van oudere security technologieën, zoals X.509 en Kerberos. De echte uitdaging zit echter in de introductie van protocollen die de businesseisen beschrijven, zoals het managen van vertrouwensrelaties, het uitwisselen van autorisatiegegevens en het afdwingen van (privacy) policies. Op dit moment ontbreekt het aan robuuste interoperabele implementaties van de verschillende protocollen in producten. XKMS en SAML lijken het verst gevorderd te zijn. Veel identity & access management fabrikanten hebben SAML omarmd en XKMS is tegenwoordig in bijna ieder PKI product te vinden.

Ook binnen de Open Source gemeenschap worden een aantal van de in dit artikel besproken nieuwe security protocollen uitgewerkt in bruikbare oplossingen. De WS-Security specificatie en bijbehorende familie waren tot voor kort alleen nog maar in beta- en pre-release versies van producten te vinden. Tegenwoordig zijn deze standaard ingebakken binnen verschillende .NET en J2EE platformen.
Het ziet er naar uit dat de besproken nieuwe security initiatieven industriestandaarden zullen gaan worden en misschien zelfs al zijn.

De nieuwe Webservices security protocollen adresseren echter niet het probleem van kwaadaardige content. Ze concentreren zich uitsluitend op functionele beveiliging, zoals het beschermen van de privacy en het leveren van security voor niet-kwaadaardige Webservices connecties. De verwachting is echter dat veel van de security gevaren op netwerkniveau uit de jaren 90 weer terug zullen keren in de applicatielaag bij het gebruik van Webservices technologieën. Webservices etaleren immers veel meer functionaliteit en er is een grotere variëteit mogelijk aan methodieken om systemen te compromitteren. Het controleren van je Webservices interfaces is daarom essentieel. Een nieuwe generatie gateways (of firewalls/proxies) biedt hiervoor goede oplossingen. De meeste hedendaagse security mechanismen zijn perimeter- of netwerkgebaseerd in plaats van applicatiegebaseerd. Webservices gateways kunnen verankerd zijn in speciale hardware of samenwerken met traditionele firewalls en hebben een hoge mate van “applicatiebewustzijn” (moving up the stack) om boosaardige en ongeldige XML/SOAP berichten te kunnen uitfilteren.

Een andere conclusie die getrokken kan worden is dat zolang er sprake is van eenvoudige point-to-point Webservices, SSL en VPN gebaseerde oplossingen voor de meeste toepassingen vooralsnog afdoende beveiliging bieden.

De toekomst van Webservices is veelbelovend maar ook onzeker. Door het gebrek aan adequate en volwassen security oplossingen zijn grote gedistribueerde Webservices toepassingen in een open marktsituatie op korte termijn niet haalbaar. De meeste organisaties zullen overwegen om Webservices technologie in te zetten voor integratievraagstukken voor interne toepassingen in plaats van voor koppelingen met de (boze) buitenwereld. SOAP leent zich uitstekend als oplossing voor applicatie-integratie.
De verwachting is dat brede ondersteuning voor de nieuwe Webservices security protocollen vanuit de markt snel zal toenemen. De belangrijkste spelers doen allemaal mee: Microsoft, IBM, Sun, HP, BEA, Novell, Oracle, SAP en veel leveranciers van beveiligingsproducten, zoals Entrust, Baltimore, RSA Security, CA, Vordel, etc.

Tot slot vormen de security uitdagingen van Webservices nog maar het topje van de ijsberg. Ook de businesskant is volop in beweging. Hier maken BPM (Business Process Management) en Workflow Management belangrijke ontwikkelingen door. Het valt echter buiten het bestek van dit artikel om hieraan aandacht te besteden.

Referenties
http://www.webservices.org/

De meest complete en uitgebreide leveranciersonafhankelijke website met dagelijks het laatste nieuws, nieuwe artikelen, links, onderzoeksrapporten en whitepapers op het gebied van Webservices van architectuur, ontwerp en beveiliging tot en met productinteroperabiliteit en -vergelijkingen.

Standaardisatie Consortiums
W3C : http://www.w3c.org
OASIS : http://www.oasis-open.org
WS-I : http://www.ws-i.org
IETF : http://www.ietf.org

Webservices Platform Vendors
IBM : http://www.ibm.com/webservices/
Microsoft : http://www.microsoft.com/webservices/
HP : http://www.hp.com/
Sun : http://www.sun.com/
Novell : http://www.novel.com/
BEA : http://www.bea.com/

Webservices Security Vendors
o.a. Vordel, WestBridge Technology, Reactivity, Quadrasys, Datapower Technology, Forum Systems en Xtradyne Technologies.

PKI en Identity & Access Management Vendors
o.a. VeriSign, RSA Security, CA, Entrust, Baltimore, IBM, Netegrity, Oblix en Novell.

XML
http://www.xml.org
http://www.xmltrustcenter.org
http://xmlhack.com
http://web-services.gov
http://www.xwss.org

SOAP
http://soapagent.com
http://www.soaprpc.com
http://www.soapware.org
http://www.soapclient.com
http://www.soaplite.com
http://soap.weblogs.com

UDDI
http://www.uddi.org
http://www.xmethods.net

Onze dank gaat uit naar Vincent Alwicher voor het verstrekken van dit artikel