Tijdens het Computable SOA Seminar 2008 noemde ik in de workshop ‘Succesvolle SOA implementaties in de praktijk’ een aantal kritische succesfactoren. Een ervan was veiligheid.
Uit verschillende onderzoeken (o.a. IDC, Informationweek/Accenture, AMR Research en Data monitor) kwam namelijk naar voren dat juist veiligheid gezien wordt als een van de grootste risico’s die een succesvolle SOA implementatie in de weg kunnen staan:
‘Security was the number 1 SOA ‘show stopper’ for UK and Netherlands respondents who were unable to implement some part of their SOA strategy as a result of security concerns and product shortcomings’. IDC ‘SOA Adoption in UK and Netherlands – Survey Results at IDC SOA Conferences’, April 2006 – May 2006
‘50% of respondents to a global AMR survey ranked security issues as the No. 1 risk they face as they implement SOA. Establishing good governance processes and meeting user service level agreements were also ranked highly’, AMR Research ‘Global SOA Survey: Patterns in Adoption’ – February 08, 2007
Het feit dat SOA een open architectuur bewerkstelligt waar applicaties en processen onbegrensd data met elkaar delen, dat maakt het juist moeilijker een SOA te beveiligen dan traditionele architectuurmodellen. Het gaat niet meer om interacties tussen applicaties en gebruikers (waar klassieke veiligheidssystemen en hardcoding in applicaties voldoende bescherming bieden), maar om interacties, data uitwisseling en businessprocessen tussen applicaties die zich zowel binnen als buiten de bedrijfsgrenzen bevinden.
Daarnaast heeft SOA standaardisatie zich in het verleden vooral op architectuur, systeem en protocol standaardisatie gericht. De basis SOA veiligheidsstandaarden zijn nu wel bekrachtigd, maar op een aantal gebieden is nog steeds verdere uitkristallisatie nog nodig.
Maar een secure SOA is wel mogelijk, mits men de juiste maatregelen neemt. Maar dat is een verhaal op zich die ik graag later zal delen….
Hi Michael,Je maakt me erg nieuwsgierig naar de juiste maatregelen. Security is een erg breed begrip en raakt authenticatie, autorisatie, encryptie, digital signing, denial of service attacks, Data attacks (XML parser kwetsbaarheden, buffer overflow), etc.Het probleem begint al bij de vraag “wie gebruikt de Service”. Je kan ervoor kiezen dat iedereen een Service Provider mag aanroepen of je kan dit beperken tot alleen geregistreerde Service Consumers en dit bijvoorbeeld inregelen doormiddel van Certificaten. Wat zijn jou tips?Stel dat je het probleem tussen Service Consumer en Service Provider heb opgelost dan moet je nog de autorisatie op gebruikersniveau regelen. De meeste grote organisaties kennen Content Based Autorisatie, dit houdt in dat je alleen met een bepaalde rol onder een bepaalde conditie bepaalde data wel of niet mag zien. Zorgt de Service Provider of de Service Consumer voor het filteren van de informatie die de gebruiker niet mag zien? Heb je hier goede tips voor?Dan krijgen we het vraagstuk van single sign-on, encryptie, non-repudiation, digital signing, etc. Ook hiervoor zijn legio standaarden (wie kontroleert ze in de praktijk?). Ik vraag me echt af welke ontwikkelaar in de praktijk deze zaken heeft gebruikt en wat zijn/haar ervaringen hiermee zijn.* SAML Security Assertion Markup Languag SAML is an XML framework for exchanging authentication and authorization information. * WS-Federation Web Services Federation Language This specification defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes, authentication between participating Web services. * WS-Security Describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. * WS-SecureConversation Defines extensions that build on WS-Security to provide secure communication. Specifically, it defines mechanisms for establishing and sharing security contexts, and deriving session keys from security contexts.* WS-SecurityPolicy An addendum to WS-Security. Indicates the policy assertions for WS-Policy which apply to WS-Security. * WS-Trust Defines extensions that build on WS-Security to request and issue security tokens and to manage trust relationships.* XML-Encryption Specifies a process for encrypting data and representing the result in XML. * XML-Signature Specifies XML digital signature processing rules and syntax.En tenslotte zou ik graag tips willen horen hoe we kunnen voorkomen dat doormiddel van een XML bericht onze Service niet correct functioneert. De uitdaging die ik hier namelijk zie is het dat in mijn ogen de Service Provider 100% garantie moet kunnen geven op de Input om de juiste Output te kunnen garanderen. En om dit te kunnen garanderen zal er uitputtend gecontroleerd moeten worden wat uiteindelijk 80% van de kosten zal gaan bedragen (die natuurlijk enorm zijn opgelopen). Kortom, ik ben erg benieuwd naar de ervaringen en tips van Michael en alle anderen natuurlijk. Want dat Security nr.1 Kritische Succesfactor is onderschrijf ik van harte.mvgFreddie van Rijswijk
Michael en Freddie,Het aardige van SOA security is dat het een 2-koppig monster is. Enerzijds kun je je afvragen in hoeverre de inmiddels beschikbare voorzieningen op het gebied van Identity & Access Management (want daar moet je toch wel aan denken als je een structurele oplossing voor security-vraagstukken zoekt) zelf als services in een SOA beschouwd kunnen worden. Anderzijds is het beschermen van het service landschap (samengevat onder de noemer ‘SOA Security’) een belangrijke voorwaarde voor de omvattende invoering van SOA.Het mooiste is natuurlijk deze twee te combineren: dus een verzameling services te hebben om de services mee te beveiligen. Er zijn diverse producten die dit gat deels opvullen, onder andere ‘service management’ producten van bekende SOA suite leveranciers. Die gebruiken soms een aantal standaarden zoals Freddie boven aangeeft. Als geheel genomen is ‘Services for SOA Security’ echter nog in beweging en geen out-of-the-box oplosbaar probleem voor grote omgevingen. Wel kan met enige integratie een bestaande identity & access management oplossing gecombineerd worden met een SOA suite om de bouwstenen voor in ieder geval twee secanrio’s te implementeren die over het algemeen spelen:a) De gebruikersidenteit vanuit de web-presentatie consistent meegeven door de service-laag heen, zodat ook voor ‘back-office’ services de juiste autorisatie kan worden toepgepast.b) Het faciliteren van authenticatie en autorisatie tussen services uit verschillende domeinen (denk aan organisaties of organisatieonderdelen).Voor beide worden in toenemende mate het SAML-protocol en SAML-tokens ingezet; daarnaast is er met WS-Federation een mogelijkheid dit m.n. in Microsoft-centrische omgevingen te faciliteren.Cruciaal is in elk geval dat de identity & access management infrastructuur die veelal al wordt gebruikt voor authenticatie en autorisatie in web-omgevingen, wordt uitgebreid richting het service-landschap.Groet,– Peter Valkenburg CTO | Everett
Hi Michael, Peter en Freddy,Michael, eens met jouw statements omtrent security. En ook sluit ik me ook aan bij de conclusies van Peter omtrent identity.Meer dynamische interactie tussen meerdere partijen (services en gebruikers (intern/extern) leidt per definitie tot meer security-risico’s.De oplossing zal m.i. liggen in doorontwikkeling van bestaande securitymodellen, ondersteund met nieuwe technologieën. Zonder hier nu uitputtend te worden een paar richtingen:- generieke security services verschuiven richting het netwerk en hier komt de vraag wie heeft/krijgt toegang en voor hoe lang en onder welke voorwaarden. Hierbij zullen open (publieke), half open en gesloten delen ontstaan. De DMZ moet opgewaardeerd en heringericht worden.- Er vindt verschuiving plaats van identity-check van IP-adres naar user naar businessevent (service-events).- er komen nieuwe acces en inlogtechnologieën beschikbaar als vingerafdruk en/of irisauthenticatie- er komen intelligente oplossingen die ‘normaal’ gebruikersgedrag van applicaties kunnen onderscheiden van hackergedrag of ander crimineel gedrag- verkeerstromen worden encrypted (versleuteld) o.b.v. steeds geavanceerde certificaten met verschillende categorieën.En de terechte vraag blijft van Freddie, nl. in hoeverre kunnen de security-verantwoordelijken en standaards vertrouwd worden, open…100% veiligheid is een illusie en maatregelen moet altijd bezien worden i.r.t. kosten en consequenties (gevolgschade) en risico’sEn tja, de kosten gaan helaas nog niet omlaag, integendeel, maar het belang groeit ook.Mijn prangende vraag hierbij is wie overziet het security-landschap nog of komt er een standaard referentiearchitectuur met standaardoplossingen?En Michael, ook ik zie belangstellend uit naar je tips.oscar roelofsion-ip