Het service oriënted architecture (soa)-concept is ontstaan vanuit de behoefte om processen flexibel te kunnen veranderen. Diezelfde flexibiliteit dreigt echter in het geding te raken doordat organisaties hun nieuwe webservices-applicaties moeten beveiligen. Deze beveiliging moet echter steeds vaker aangepast worden aan de wijzigingen in wet- en regelgeving. Als de beveiligingsmaatregelen in een samenhang van verschillende webservices moeten worden aangepast, gaan de voordelen van het soa-concept verloren. De oplossing vormt een XML-gateway, waarin alle beveiligingslogica op één punt samenkomt.
De centrale vraag van dit artikel is: hoe kun je tegelijkertijd je concurrentievermogen vergroten, kosten verlagen, businessprocessen beter beheersen en identity management in een soa-omgeving optimaliseren? Bedrijven willen enerzijds steeds sneller nieuwe diensten kunnen aanbieden, wat een snellere uitrol van applicaties vereist. Tegelijkertijd worden ze geconfronteerd met grotere uitdagingen op het gebied van privacy doordat ze steeds meer informatie (online) delen met partners en leveranciers. En bovendien wordt de regelgeving, zowel op het gebied van privacy als voor wat betreft governance, steeds strenger. Bedrijven komen in een spagaat.
Flexibel en snel
Een soa biedt hiervoor een oplossing. Door de starre legacy-applicaties te vervangen door een soa-omgeving, waarin een applicatie gevormd wordt door losse functionele componenten die als diensten met elkaar communiceren via XML-berichten, wordt het mogelijk de it-architectuur flexibel en snel aan te passen aan veranderende bedrijfsprocessen. Door hergebruik van componenten kunnen ook de kosten dalen. Veelal wordt er ook gebruik gemaakt van webservices van partners en andere externe relaties. Dit brengt nieuwe uitdagingen met zich mee, met name als het gaat om het beheersen van de complexiteit en beveiliging. Op welk niveau leg je bijvoorbeeld zaken als privacy, integriteit en toegangscontrole neer?
Veel organisaties regelen de vertrouwelijkheid van de webservicescommunicatie op transportniveau via SSL/TLS. Hiermee kan echter geen end-to-end beveiliging worden geboden. De identiteits-, authenticiteits- en vertrouwelijkheidsvraagstukken zullen op berichtniveau moeten worden geregeld. En dat zorgt voor veel rompslomp en vertraging, want op het moment dat de beveiliging als gevolg van veranderde wetgeving moeten worden herzien, dan zullen alle webservices moeten worden herschreven. In plaats van een grotere flexibiliteit leidt dit eerder tot een veel grotere complexiteit, en daarmee tot hogere kosten.
Gateway houdt overzicht
Er is echter een alternatief: ontkoppel de businesslogica van de beveiligingslogica en -policies en breng deze laatste twee onder in een XML-Gateway. Op die manier is hergebruik mogelijk van beveiligingsmechanismen, is er één centraal punt voor controle, aanpassing en auditmogelijkheden. Hiermee neemt de complexiteit af. Dit leidt tot een betere sturing op processen en beveiliging, snellere time-to-market van nieuwe applicaties en lagere kosten.
Een voorbeeld van deze technologie levert Layer7 Technologies. Deze werkt als volgt. Tussen de gebruikers en de service endpoints plaats je een policy enforcement point (PEP). Het PEP ofwel de gateway is verantwoordelijk voor autorisatie, datascreening, virtualisatie, trust management, auditing, service level agreement, monitoring en firewalling. Verandert er een policy of privacy richtlijn dan hoef je dit alleen in het PEP aan te passen. Op deze manier kun je policies ‘on the fly' veranderen, zonder dat services uit de lucht hoeven. Terwijl de samenhang van webservices continu verandert, houdt de gateway het overzicht.
Doordat het makkelijker is om policies aan te passen, is het ook eenvoudiger om met een kleine soa-pilot te beginnen. Het is niet langer nodig om op voorhand alles helemaal uit te denken. Heb je een bepaalde policy over het hoofd gezien, dan doe je eenvoudig een aanpassing. Ontwikkelaars kunnen zich volledig focussen op het schrijven van applicaties die businessprocessen ondersteunen, zonder zich zorgen te hoeven maken over identity management en andere security aangelegenheden.
In de cloud
De beveiliging vindt zoals gezegd niet langer plaats op transportniveau (SSL), maar op het niveau van het bericht (XML). Dit maakt onder meer federated identity management mogelijk. Als twee bedrijven als partners samenwerken in dezelfde soa-omgeving, kan een medewerker van bedrijf A met zijn eigen identiteit en authenticatie toegang krijgen tot de services die in bedrijf B draaien. Voorheen zorgde dit voor een grote administratieve rompslomp met certificaten, nu handelt de gateway de autorisatie af. Nu de reikwijdte van services steeds groter wordt, kan federated identity management voor een aanzienlijke vereenvoudiging van de beveiliging zorgen.
Het is zelfs mogelijk om de gateway in de cloud neer te zetten als virtuele appliance. Kortom, het maakt niet uit waar de webservices actief zijn: in het eigen datacenter, bij een partner of ergens op het internet als SaaS. In alle gevallen is de gateway in staat om webservices te controleren, aan te passen en te monitoren. De gateway is een kant-en-klare oplossing die bedrijven als hardware of als managed service kunnen afnemen en in enkele dagen is te installeren en te configureren.
Alex Heijdenrijk, security consultant ion-ip
De problematiek en de oplossing wordt in dit artikel helder beschreven, maar hier bestaan al jaren oplossingen voor van alle grote leveranciers die producten rondom SOA leveren, die hetzij op de hier beschreven wijze werken (“Gateway”) hetzij via Client of Server “Agents”, hetzij gecombineerd. Beide methodes hebben voor en nadelen afhankelijk van de situatie, waarbij beide nodig zijn.
Is inderdaad weinig ‘nieuws’ aan. Zie o.a. een artikelenreeks in Infosecurity.nl magazine in 2007-2008; dat noemt o.a. gateways zoals van Layer7 maar ook de PKI-componenten en de mogelijkheid om e.e.a. via de netwerklaag ‘dicht te zetten’.