Webservices Security – Moving up the stack! - 4
18-05-2005,13:36 door
De opkomst van de Webservices hype zal niemand ontgaan zijn. De afgelopen jaren is er veel geschreven en gesproken over deze nieuwe technologie en velen voorspellen een grote toekomst voor dit concept. Er is echter geregeld onduidelijkheid over wat dit concept nu eigenlijk precies betekent en hoe het technisch werkt en geïmplementeerd wordt. Fabrikanten, analisten en andere belanghebbenden verschillen regelmatig van mening. Daarnaast brengt Webservices nieuwe uitdagingen met zich mee op het gebied van informatiebeveiliging. Dit artikel gaat in op de nieuwe bedreigingen en uitdagingen van Webservices technologie en behandelt van daaruit de lopende beveiligingsinitiatieven.
Deel 1: Webservices Security - Inleiding
Deel 2: Webservices Security - Nieuwe bedreigingen en uitdagingen
Deel 3: Webservice Security - SAML en XACML en WS-Security
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.
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.
