De veranderingen die SOA brengt toegespitst op IAM

Transcriptie

1 De veranderingen die SOA brengt toegespitst op IAM Scriptie ter afsluiting van de postgraduate IT Audit Opleiding aan de Vrije Universiteit Amsterdam Auteur: Student nr.: Scriptiebegeleider VU Scriptiebegeleider KPMG Bram van Zeist Evert Koning Erwin Hansen De scriptie heeft 37 pagina s 834_scriptie_SOA en IAM

2 Voorwoord Voor u ligt de scriptie geschreven ter afsluiting van de studie IT-audit aan de Vrije Universiteit Amsterdam. Met veel plezier heb ik mij in dit onderwerp verdiept. Het opschrijven van de bevindingen daarentegen was niet altijd even gemakkelijk. Vooral de balans tussen studie, werk en privé-leven was deze laatste periode soms zoek. Uiteindelijk wel voor een goed doel namelijk, het afronden van de opleiding met uiteindelijk een RE titel in het vooruitzicht. Graag wil ik Evert Koning (VU) bedanken voor zijn begeleiding. Daarnaast ook dank aan Erwin Hansen (KPMG) voor de overlegmomenten en zijn motiverende woorden. Bram van Zeist Haarlem, i

3 Inhoudsopgave 1 Inleiding Achtergrond Doelstelling Onderzoeksvraag Deelvragen Structuur van de scriptie 2 2 Service Oriented Architecture Wat is een Service Oriented Archtecture? Presentatielaag Logicalaag Datalaag Voordelen SOA Wat zijn de verschillen tussen een Service Oriented Architecture en traditionele IT-architectuur? 6 3 Identity and Access Management Wat is Identity and Access Management? IAM-omgeving Welke wet en regelgeving is van toepassing op het gebied van IAM? Good practises Conclusie 16 4 SOA en IAM Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van IAM? De beheerders De gebruikers Welke risico s brengen deze veranderingen met zich mee? Welke kansen brengen deze veranderingen met zich mee? Centralisatie Rapportage Single Sign On Bepalen autorisaties 25 5 Samenvatting, Conclusie en Aanbevelingen De belangrijkste veranderingen die SOA behelst, die de aantoonbare beheersing van informatie bemoeilijkt op het gebied van IAM Deelvraag 1: Wat is een Service Oriented Architecture? Deelvraag 2: Wat zijn de verschillen tussen een Service Oriented Arhcitecture en huidige IT-architectuur? 27 ii

4 5.1.3 Deelvraag 3: Welke wet en regelgeving is van toepassing op het gebied van IAM? Deelvraag 4: Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van identity and access management en welke risico s brengen deze veranderingen met zich mee? Aanbevelingen om de veranderingen die SOA behelst het hoofd te bieden Deelvraag 5: Welke maatregelen kunnen worden getroffen om de geïdentificeerde risico s te beperken? 29 A Reflectie 32 B Literatuurlijst 33 iii

5 1 Inleiding 1.1 Achtergrond Momenteel zijn er binnen de IT op het gebied van de IT-infrastructuur grote veranderingen gaande met de opkomst van de Service Oriented Architecture 1 (SOA, [SO-uh]). Waar jarenlang een architectuur in gebruik was, en is, waarbij gebruikers door middel van een computer of terminal via het netwerk gebruik maakt van diensten, applicaties of informatiebronnen zal dit door gebruik van SOA veranderen. Gebruikers zullen nog steeds toegang hebben tot diensten, applicaties en informatiebronnen. Echter de manier waarop deze beschikbaar worden gemaakt en hoe de informatiestromen door het netwerk lopen zullen sterk veranderen. Tijdens mijn werkzaamheden bij KPMG IT Advisory wordt ik geconfronteerd met cliënten die bezig zijn SOA te implementeren of hier over na denken. Deze klanten zijn voornamelijk bezig om de gewenste functionaliteit te realiseren. Over informatiebeveiliging wordt nauwelijks of niet nagedacht. In het kader van compliance moeten organisaties inzichtelijk en controleerbaar maken welke informatie is benaderd en door wie. Wat deze klanten zich vaak niet realiseren is dat SOA op het gebied van identity and access management de boel mogelijk op zijn kop zet. De EDP-auditor is in de afgelopen jaren gewend geraakt aan de huidige en bestaande ITinfrastructuur. Werkprogramma s zijn ontwikkeld om delen of al dan niet de gehele ITinfratructuur te beoordelen. De opkomst van SOA zal de EDP-auditor dwingen om zijn aanpak tegen het licht te houden en daar waar nodig ter herzien Doelstelling De scriptie heeft als doel het inzichtelijk maken van de grote veranderingen die SOA behelst ten opzichte van de huidige traditionele IT-infrastructuur. Met daarbij de focus op identity and access management. Uit de analyse volgen onderwerpen waaraan cliënten moeten denken bij het implementeren van SOA om na implementatie te voldoen aan wet en regelgeving. Zodat de kans groter wordt dat eventuele toekomstige IT-audits met goed gevolg worden afgesloten. Wat aandachtspunten zijn voor bedrijven zijn veelal aandachtspunten voor de EDP-auditor. Wanneer de EDP-auditor weet wat de belangrijkste veranderingen en daarbij horende risico s zijn is hij ook beter instaat om in de praktijk een SOA te beoordelen, bijvoorbeeld op het gebied van identity and access management. 1.2 Onderzoeksvraag De bovenstaande aanleiding en doelstelling leiden tot de volgende onderzoeksvraag: 1 1

6 Wat zijn de belangrijkste veranderingen die SOA behelst, die de aantoonbare beheersing van informatie bemoeilijkt op het gebied van identity and access management en welke aanbevelingen kunnen worden gedaan om deze veranderingen het hoofd te bieden? Deelvragen Om tot een beantwoording van de onderzoeksvraag te komen, zullen onderstaande deelvragen moeten worden beantwoord: 1 Wat is een Service Oriented Architecture? 2 Wat zijn de verschillen tussen een Service Oriented Arhcitecture en huidige ITarchitectuur? 3 Welke wet en regelgeving is van toepassing op het gebied van IAM? 4 Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van identity and access management en welke risico s brengen deze veranderingen met zich mee? 5 Welke maatregelen kunnen worden getroffen om de geïdentificeerde risico s te beperken? 1.3 Structuur van de scriptie Dit hoofdstuk, hoofdstuk 1, beschrijft de aanleiding en achtergrond voor het schrijven van de scriptie. Daarnaast wordt in hoofdstuk 1 de onderzoeksvraag inclusief deelvragen gepresenteerd. Vervolgens geeft hoofdstuk 2 uitleg over SOA, alsmede de verschillen tussen SOA en de traditionele IT-infrastructuur. Hoofdstuk 3 beschrijft IAM waarbij ook wordt ingegaan op de voorschriften vanuit wet en regelgeving met betrekking tot IAM. De veranderingen op het gebied van IAM en de daarmee samenhangende risico s zijn beschreven in hoofdstuk 4. Tenslotte worden in hoofdstuk 5 de samenvatting, conclusies en aanbevelingen gegeven, waarmee antwoord wordt gegeven op de centrale onderzoeksvraag. 2

7 2 Service Oriented Architecture Hoofdstuk 2 beschrijft de Service Oriented Architecture. De deelvragen Wat is een Service Oriented Architecture? en Wat zijn de verschillen tussen een Serivice Oriented Architecture en traditionele IT-architectuur? worden in hoofdstuk 2 beantwoord. 2.1 Wat is een Service Oriented Archtecture? Service Oriented Architecture behelst een nieuwe architectuur waarop diensten aan gebruikers worden aangeboden. Binnen deze architectuur zijn drie lagen te onderkennen. 1 De presentatielaag, in de presentatielaag wordt er zorg voor gedragen dat de benodigde functionaliteit aan de gebruiker wordt aangeboden. 2 De logicalaag, in deze laag wordt zorggedragen voor de communicatie tussen de gebruiker (presentatielaag) en de datalaag. 3 De datalaag, in de datalaag worden alle systemen, diensten en applicaties beschikbaar gesteld. De verzameling van systemen, diensten en applicaties worden samengevat onder de noemer doelsystemen. Het gebruik van de presentatielaag, de logicalaag en de datalaag resulteert in een drie lagen architectuur zoals weergegeven in figuur 1. De presentatie-, logica- en datalaag samen vormen een Service Oriented Architecture. De drie onderkende lagen worden in de volgende paragrafen nader beschreven Presentatielaag Gebruikers hebben toegang tot een presentatielaag waar de voor hen beschikbare functionaliteit wordt aangeboden. De functionaliteit wordt aangeboden in de vorm van services. Een service kan bestaan uit een handeling uit te voeren op een doelsysteem, bijvoorbeeld het opvragen van een document. Echter een service kan ook bestaan uit meerdere andere services, die samen de gewenste functionaliteit verzorgen. Hierbij worden services beschouwd als uniforme berichten waarin een specifieke activiteit wordt gedefinieerd. Door het combineren van meerdere van deze uniforme berichten (services) ontstaat een nieuwe service met de gecombineerde functionaliteit van de gebruikte uniforme berichten. Services kunnen aan de gebruiker worden aangeboden door middel van een website. Wanneer services worden aangeboden via webtechnologie spreekt men in het algemeen over webservices. De presentatielaag is verantwoordelijk voor de technologie die het mogelijk maakt om de services aan de gebruikers aan te bieden. In het voorbeeld van webservices gaat het om het beschikbaar stellen van een webomgeving waarop de gebruiker eventueel door inloggen de voor de gebruiker benodigde functionaliteit in de vorm van (web)services wordt aangeboden. 3

8 2.1.2 Logicalaag Het aanroepen van een service gebeurt door een gebruiker of door een andere service. Het uitvoeren van de service wordt afgehandeld in een apart gedeelte binnen de SOA, de logicalaag. De logicalaag bestaat uit drie delen die samen de functionaliteit van de logicalaag vormen, de repository, Orchestration en de Enterprise Service Bus (ESB). Repository Services worden opgeslagen in de repository. Wanneer de gebruiker bepaalde handelingen wil uitvoeren en daarvoor een service aanroept wordt deze opgevraagd vanuit de repository en uitgevoerd. De repository draagt zorg voor de opslag van de services (uniforme berichten) en stelt deze beschikbaar wanneer deze door de gebruiker worden aangeroepen. Orchestration Als een gebruiker een service aanroept wordt deze opgehaald uit de repository, verstuurt naar de datalaag. Vanuit de datalaag wordt een antwoord ontvangen, het antwoord wordt aan de gebruiker teruggekoppeld. Orchestration draagt zorg voor het workflow management binnen de logicalaag zodat, services in de juiste volgorde worden uitgevoerd en wordt gewaarborgd dat gegevensoverdracht juist gebeurd. Enterprise Service Bus De uniforme berichten die tussen de gebruiker (presentatielaag) en de datalaag worden verstuurd gaan over de Enterprise Service Bus (ESB). De ESB is het communicatiekanaal waarop de doelsystemen zijn aangesloten alsmede de systemen die de presentatielaag vormen. De ESB draagt zorg dat de uniforme berichten kunnen worden getransporteerd en van de presentatielaag naar de datalaag kunnen worden gestuurd en visa versa Datalaag De systemen en applicaties (doelsystemen) waartoe een gebruiker door middel van services gebruik van wil maken zijn gelegen in de datalaag. Wanneer een gebruiker bijvoorbeeld een document wil opvragen uit een fileshare zal dit gebeuren door de juiste service aan te roepen. De betreffende service komt via de ESB bij het systeem met daarop de fileshare terecht. Het systeem zal het uniforme bericht interpreteren, de gewenste handeling uitvoeren en het resultaat versturen over de ESB. Doordat de doelsystemen in de datalaag zijn gesitueerd heeft de gebruiker geen directe toegang tot de doelsystemen. 4

9 Gebruikers Gebruikers Bedrijfsproces Service Service Presentatielaag Service Service Logicalaag (ESB, Repository, Orchestration) Datalaag Doelsystemen Figuur 1: De drie te onderscheiden lagen binnen een SOA, tevens weergeven procesondersteuning Voordelen SOA Deze paragraaf beschrijft de voornaamste voordelen die SOA biedt. Flexibiliteit SOA brengt flexibiliteit, door gebruik te maken van gestandaardiseerde berichten die alleen of samen de gewenste functionaliteit bieden is het mogelijk om deze berichten te hergebruiken. Services kunnen dan ook worden gezien als bouwstenen die gecombineerd kunnen worden om nieuwe functionaliteit te bieden. Dan wel bestaande functionaliteit aan te bieden aan een andere gebruikersgroep. Ten tweede zijn services aangeroepen door de gebruiker niet direct gekoppeld aan de doelsystemen. Immers Orchestration is verantwoordelijk voor het verwerken van de aanroep van de gebruiker en het versturen van een gestandaardiseerd bericht naar het doelsysteem. Waarna Orchestration het antwoord van het doelsysteem verwerkt en doorstuurt naar de presentatielaag. Wijzigingen in de doelsystemen kunnen eenvoudiger worden doorgevoerd zonder dat de geboden functionaliteit aan de gebruiker direct veranderd. Omgekeerd geldt ook, wijzigingen in de presentatielaag hebben geen directe invloed op de doelsystemen. 5

10 Procesondersteuning SOA en daarmee het gebruik van services leent zich goed voor de ondersteuning van bedrijfsprocessen. Per processtap kan een behorende en ondersteunende service worden ontwikkeld. Een inkoopproces kan bijvoorbeeld bestaan uit de volgende stappen, invoer inkooporder, goedkeuren en uitsturen inkooporder. Voor iedere stap wordt een service ontwikkeld om de vastlegging in en ondersteuning door ICT te bewerkstelligen. De ontwikkelde services worden toegekend aan de daartoe geautoriseerde personen binnen het inkoopproces. Doordat SOA het mogelijk maakt om processen goed te ondersteunen blijkt het implementeren van een SOA vaak een katalysator om de huidige bedrijfsprocessen nog eens tegen het licht te houden en te bekijken waar met behulp van services processen geoptimaliseerd kunnen worden. 2.2 Wat zijn de verschillen tussen een Service Oriented Architecture en traditionele IT-architectuur? De belangrijkste verschillen tussen SOA een traditionele IT-infrastructuur zijn in dit hoofdstuk beschreven waarbij, onderscheidt is gemaakt in architectuur, performance en functionaliteit. Gebruiker Gebruiker Service Presentatielaag Werkstation Logicalaag (ESB, Repository, Orchestration) Netwerk Datalaag Datalaag Doelsystemen Servers Figuur 2: SOA vs client-server architectuur Architectuur De traditionele IT-architectuur kenmerkt zich door het client-server principe. De gebruiker maakt gebruik van een werkstation waarop de cliënt (bijvoorbeeld een applicatie) beschikbaar is 6

11 gesteld. Door deze cliënt aan te roepen, al dan niet door in te loggen met authenticatiemiddelen, wordt er rechtstreeks contact gemaakt met de server waarop de informatie is opgeslagen. Een voorbeeld hiervan zijn ERP-systemen. De gebruiker maakt met behulp van een client contact met het ERP-systeem. Waarna vervolgens werkzaamheden kunnen worden uitgevoerd. Alle informatie is opgeslagen in het ERP-systeem. De client stelt de gebruiker instaat om deze informatie te benaderen en bewerkingen uit te voeren. Een van de verschillen tussen de traditionele architectuur en een SOA is de rechtstreekse verbinding tussen werkstation en server. Waarbij in de traditionele architectuur het werkstation van de gebruiker direct een verbinding maakt met de server gebeurt dit bij een SOA niet. Bij een SOA roept de gebruiker een service aan, vervolgens wordt door onder andere Orchestration de service verstuurd naar het betreffende doelsysteem. Binnen een SOA is er geen sprake van een rechtstreekse verbinding tussen gebruiker en doelsysteem. Bij SOA worden berichten verstuurd over de ESB. Vergelijkbaar met , een bericht wordt verstuurd naar de ontvangende partij zonder dat er een directe verbinding met de ontvanger is. De tussenliggende -servers waarborgen dat het bericht bij de ontvanger komt. Orchestration kan in functionaliteit gedeeltelijk worden vergeleken met de -servers. Orchestration waarborgt immers ook dat de berichten (services) aangeroepen door de gebruiker bij het doelsysteem terecht komen en omgekeerd. Doordat er geen directe verbinding is binnen een SOA tussen het werkstation van de gebruiker en het doelsysteem logt de gebruiker ook niet in op de server. In de traditionele IT-infrastructuur logt een gebruiker vaak door middel van de client in op de server. Hiertoe is op de server een account voor de gebruiker aangemaakt. Bij een SOA wordt gebruik gemaakt van functionele accounts tussen Orchestration en de doelsystemen. Het functionele account wordt gebruikt om de communicatie tussen Orchestration en doelsystemen mogelijk te maken. Functionaliteit Een verschil tussen een traditionele IT-infrastructuur en SOA is dat de geboden functionaliteit beschikbaar wordt gesteld aan de gebruiker via een client-applicatie en bij SOA via services. Een client-applicatie kenmerkt zich vaak door een zeer uitgebreide functionaliteit waarmee veel handelingen kunnen worden verricht. Immers er wordt een applicatie ontwikkeld waarmee gebruikers, met allerlei verschillende taken, moeten kunnen werken. Een service echter is ontwikkeld voor noodzakelijk gebruik. Is er meer functionaliteit nodig dan wordt een tweede service ontwikkeld. De huidige en de nieuwe service vormen samen de uiteindelijke service die de juiste functionaliteit bevat. Organisaties zijn afhankelijk van de geboden functionaliteit in de aangekochte client-server applicatie voor ondersteuning bij de bedrijfsvoering. Echter het ontbreken van functionaliteit kan leiden tot een niet optimale ondersteuning van de bedrijfsprocessen. Aangezien services 7

12 worden ontworpen na waar gelang de vraag vanuit de organisatie is het mogelijk om met services de bedrijfsprocessen beter te ondersteunen. Performance SOA maakt gebruik van uniforme berichten. Services worden aangeroepen waarna de berichten worden verstuurd, ontvangen en verwerkt, vervolgens wordt een bericht ter antwoord verstuurd. Het gebruik van uniforme berichten zorgt voor extra dataverkeer. De berichten, bestaande uit een XML standaard, introduceren extra overhead. In de traditionele IT-infrastructuur wordt een opdracht van de gebruiker direct verstuurd naar de applicatie. Bij SOA wordt de opdracht verpakt in een uniform bericht en verstuurd over het netwerk (ESB). Systemen en applicaties binnen een SOA moeten instaat zijn om de berichten te ontvangen, te interpreteren en een antwoord te versturen. Om deze activiteiten te kunnen uitvoeren dienen systemen en applicaties te worden voorzien van additionele modules die dit mogelijk maken. Het gebruik van deze modules vergt rekenkracht van de systemen waarop de modules worden geïmplementeerd. Concluderend kan worden gesteld dat SOA een negatieve invloed heeft op de performance. Voor het gebruik van uniforme berichten is additionele rekenkracht benodigd, dit kan beteken dat huidige systemen moeten worden uitgebreid met rekenkracht en geheugen. Daarnaast geeft het gebruik van uniforme berichten een extra belasting op het netwerk door de introductie van meer overhead in de communicatie tussen gebruiker en doelsysteem. 8

13 3 Identity and Access Management Om tot een goed inzicht te komen betreffende identity and access management in relatie tot SOA wordt IAM beschreven. Deze beschrijving introduceert begrippen en principes die binnen IAM worden gebruikt. Nadat is beschreven wat er, in deze scriptie, onder IAM wordt verstaan, wordt er ingegaan op diverse wet en regelgeving met betrekking tot IAM. Dit moet leiden tot een overzicht van wettelijke eisen en regelgeving waaraan ondernemingen, afhankelijk van het type onderneming, moeten voldoen. De volgende deelvraag is van toepassing op dit hoofdstuk: Welke wet en regelgeving is van toepassing op het gebied van IAM?. 3.1 Wat is Identity and Access Management? In Nederland wordt ook wel van Identificatie, Authenticatie en Autorisatie (IAA) gesproken als er over IAM wordt gesproken. Echter in deze benaming komt het aspect van beheer (management) niet goed naar voren. Identity Management (IdM) is tevens een afkorting die wordt gebruikt. IdM impliceert echter zich alleen te richten op het management van identiteiten. IAM is echter veel omvattender dan alleen het managen van identiteiten. IAM betreft een verzamelnaam voor al wat komt kijken bij het beheer van gebruikers van en autorisaties binnen informatiesystemen. Veel verschillende definities worden gehanteerd. De verschillende definities zijn het gevolg van de ontwikkelingen binnen IAM. Echter in deze scriptie wordt de volgende definitie gehanteerd: Identity and Access Management richt zich op het effectief en efficiënt beheren van enerzijds betrouwbare digitale identiteiten en anderzijds de toegang tot elektronische toepassingen en informatie (objecten). Bovenstaande definitie geeft duidelijk aan dat IAM zich zowel richt op het beheren van identiteiten als op het beheren van toegang tot objecten. Binnen IAM kan op hoofdlijnen een vijftal hoofdprocessen (zie figuur 3) worden onderscheiden, te weten: Gebruikersbeheer (Usermanagement) Betreffen de activiteiten gericht op het beheer van de gehele cyclus van een persoon (indiensttreding, functiewijziging, ontslag); Authenticatiebeheer (Authenticatiemanagement) Betreffen de activiteiten gericht op het beheer van authenticatiemiddelen (passwords, tokens, etc). Autorisatiebeheer (Autorisatiemanagement) Betreffen de activiteiten gericht op het beheer van autorisaties van gebruikers. Provisioning Betreft het handmatig en/of geautomatiseerd propageren van gebruikers- en 9

14 autorisatiegegevens naar ICT-objecten. Monitoring & audit Betreft logging, auditing en rapportage. Usermanagement Authenticatiemanagement Autorisatiemanagement Audit Provisioning ICT-systemen en -toepassingen Monitoring Gebruikers Figuur 3: IAM hoofdprocessen Gebruikersbeheer Het proces gebruikersbeheer richt zich op het initieel vastleggen van gebruikers. Indien van toepassing worden additionele attributen die van invloed kunnen zijn op de autorisaties in een daartoe bestemde bronregistratie vastgelegd. Onder een bronregistratie wordt bijvoorbeeld verstaan een HR systeem. Naast de initiële vastlegging wordt de gehele levenscyclus van deze digitaal opgeslagen gebruikergegevens onderhouden. In-, door- en uitstroom van medewerkers worden in de bronregistratie beheerd. Gebruikersbeheer richt zich op het bepalen van de autorisaties die aan een gebruiker moeten worden toegekend dan wel van de gebruiker moeten worden ontnomen. Immers, gebruikers moeten over autorisaties binnen objecten beschikken om de objecten te kunnen gebruiken. Onder objecten wordt, zoals in de IAM definitie weergegeven, verstaan informatie, informatiesystemen en of elektronische toepassingen. 10

15 Meestal zal de verantwoordelijke manager van de gebruiker bepalen welke autorisaties de gebruiker dient te bezitten om de werkzaamheden binnen de bedrijfsprocessen te kunnen uitvoeren. Authenticatiebeheer Alvorens gebruikers toegang wordt verschaft tot een object, wordt de gebruiker geauthenticeerd om vast te stellen of de gebruiker is wie hij zegt dat hij is. De gebruiker wordt hiertoe voorzien van een authenticatiemiddel (bijvoorbeeld gebruikersnaam/wachtwoord-combinatie en tokens). Authenticatiebeheer richt zich op het beschikbaar stellen, beheren en innemen/intrekken van de authenticatiemiddelen van gebruikers. Naast het voorzien van gebruikers van authenticatiemiddelen richt authenticatiebeheer zich op het bepalen van de van toepassing zijnde authenticatieregels binnen een object en het vastleggen van deze regels binnen het object. In het voorbeeld van gebruikersnaam en wachtwoord als authenticatiemiddel wordt onder authenticatieregels de lengte, complexiteit en geldigheidsduur verstaan. Autorisatiebeheer Het bepalen en toekennen van autorisaties aan gebruikers in objecten betreft een tijdrovende en kostbare aangelegenheid. Immers, voor elke wijziging, zoals bij de in-, door- en uitstroom van medewerkers, dienen de bijbehorende autorisatiewijzigingen voor deze gebruiker in elk object te worden bijgewerkt. Om dit proces te vereenvoudigen, kan gebruik worden gemaakt van een autorisatiemodel. Autorisatiebeheer is verantwoordelijk voor het opstellen en onderhouden van het autorisatiemodel op basis van het organisatiebeleid en -behoefte. Dit houdt in dat met het beleid en de daaruit voortvloeiende functieprofielen als uitgangspunt een functioneel model wordt opgesteld. In dit functionele model wordt inzichtelijk gemaakt welke handelingen (bijvoorbeeld goedkeuren inkooporder) benodigd zijn voor het uitvoeren van taken die behoren bij het functieprofiel. Voorbeelden van autorisatiemodellen zijn autorisatiematrices of, in een meer geavanceerde IAM-omgeving, rollenmodellen gebaseerd op het Role-Based-Access-Control (RBAC)- principe. Autorisatiebeheer vertaalt en verwerkt tevens de in het autorisatiemodel uiteengezette (functionele) handelingen vervolgens naar daadwerkelijke autorisaties in objecten. Dit gebeurt doorgaans door autorisatiegroepen of -profielen in objecten aan te maken welke een groep autorisaties vertegenwoordigen. Het aanmaken van autorisatiegroepen of profielen kan op één of meerdere objecten binnen een doelsysteem. Afhankelijk wat benodigd is voor het uitvoeren van een (deel)taak binnen het betreffende doelsysteem. 11

16 Provisioning Gebruikersbeheer beschrijft het proces van het vastleggen en beheren van gebruikers en eventuele attributen. De verantwoordelijke manager is verantwoordelijk voor het bepalen van de autorisaties welke de gebruiker dient te bezitten. Nadat deze autorisaties zijn toegekend, zal de verantwoordelijke manager een opdracht aan de beheerorganisatie uitvaardigen, met het verzoek de autorisatiewijzigingen voor de betreffende gebruiker uit te voeren. Het geven van een opdracht om autorisaties aan te maken dan wel in te trekken kan op basis van een formulier (minder geavanceerde IAM-omgeving) of geautomatiseerd met behulp van een technisch hulpmiddel (meer geavanceerde IAM-omgeving) gebeuren. De beheerorganisatie zal ervoor zorgdragen dat het verzoek van de verantwoordelijke manager in de betrokken objecten wordt verwerkt. Deze laatste activiteit wordt aangeduid als het provisioning-proces. Provisioning staat voor het aanmaken dan wel verwijderen van gebruikeraccounts en -autorisaties in de betrokken objecten naar aanleiding van de activiteiten die in het gebruikersbeheer worden uitgevoerd. Monitoring & Audit Monitoring en Audit richt zich op het controleren van de IAM-omgeving zodat, waar nodig, tijdig kan worden bijgestuurd. Het controleproces bepaalt met behulp van het opvragen van informatie uit de objecten de gevolgde procesgang en de huidige status in de objecten (bijvoorbeeld welke autorisaties zijn uitgereikt aan welke gebruikers). De huidige status (IST) wordt binnen het controleproces vervolgens vergeleken met de gewenste situatie (SOLL) welke inherent is aan het organisatiebeleid. Het controleproces kan bestaan uit het actief monitoren en/of op basis van het produceren van rapportages. Het actief monitoren betekent dat constant de gewenste situatie (SOLL) en de daadwerkelijke situatie (IST) worden vergeleken. Wanneer er verschillen optreden, zal dit leiden tot een signaal waarna vervolgens correctieve handelingen worden verricht. Daarnaast kan het controleproces worden uitgevoerd op basis van het periodiek produceren van rapportages. De rapportages geven een weergave van de huidige situatie (IST). De weergave kan vervolgens worden vergeleken met de gewenste situatie (SOLL) IAM-omgeving De vijf hoofdprocessen gedefinieerd binnen IAM, komen samen in de zogenaamde IAMomgeving. De vijf hoofdprocessen kunnen worden ondersteund door technische hulpmiddelen waarbij het IAM-systeem centraal staat. De vijf hoofdprocessen en onderlinge relatie zijn weergeven in onderstaande figuur. 12

17 Figuur 4: IAM-omgeving In de bronregistraties worden onder meer de identiteitsgegevens van de verschillende doelgroepen geadministreerd. Zo zal, wanneer een nieuwe medewerker in dienst treedt, in deze bron de initiële vastlegging geschieden. Ook zullen de andere gebeurtenissen in de levenscyclus van deze gebruiker, zoals wijziging in functie en/of uitdiensttreding, effecten hebben op deze bronregistratie. De gebeurtenissen in de levenscyclus van gebruikers in de bronregistraties resulteren in triggers van de betreffende bronregistratie richting het centrale IAM-systeem. Deze triggers vormen het daadwerkelijke startpunt van de IAM-omgeving. Naar aanleiding van deze triggers, informeert het IAM-systeem de van toepassing zijnde autorisator (bijv. hiërarchisch en/of functioneel management) over de wijziging. De autorisator dient vervolgens actie te ondernemen. Deze acties van de autorisator kunnen bestaan uit het toekennen en/of intrekken van rollen aan gebruikers op basis van een set vooraf vastgelegde rollen die deze autorisator mag toekennen. De rollen die de autorisator mag toekennen en/of intrekken zijn vastgelegd in het autorisatiemodel. Nadat de autorisator de voor de gebruiker relevante rollen heeft toegekend en/of ingetrokken, worden als consequentie hiervan de toegangsrechten binnen de verschillende objecten gezet, gewijzigd en/of verwijderd (provisioning). Om ervoor zorg te dragen dat de door de organisatie gewenste situatie ten aanzien van toegangsrechten, zoals vastgelegd in het autorisatiemodel, in overeenstemming blijft met wat binnen de verschillende objecten is geadministreerd, zal het IAM-concept voorzien in monitoring & auditing-functionaliteiten. Monitoring voor het detecteren van afwijkingen en het starten van een incidentproces. Auditing voor het voorzien in rapportagemogelijkheden (bijv. rapportage IST/SOLL-vergelijking). 13

18 3.2 Welke wet en regelgeving is van toepassing op het gebied van IAM? In de afgelopen jaren zijn een aantal missstanden bij bedrijven aan het licht gekomen, waarbij het Enron schandaal een van de bekendste is. Om misstanden in de toekomst te voorkomen hebben overheden wet en regelgeving ontwikkeld. Bedrijven worden geacht aan deze wet en regelgeving te voldoen, er van uitgaande dat deze bedrijven aan de gestelde voorwaarden voldoen, bijvoorbeeld bij een notering aan de Amerikaanse beurs. Naar aanleiding van onder andere het Enron schandaal is in Amerika de SOx regelgeving ontstaan. In Nederland kennen we de code Tabaksblat. In deze paragraaf wordt beschreven in hoeverre SOx en de code Tabaksblat het gebruik van IAM voorschrijven. Bedrijven zullen alvorens IAM te implementeren een zogenaamde business case opstellen. Hierin wordt onder andere beschreven wat de voordelen of de noodzaak van IAM is. Een van de zogenoemde business drivers die vaak wordt genoemd is compliance aan wet en regelgeving. SOx In de SOx regelgeving wordt nergens gesproken over IAM, sterker nog maatregelen met betrekking tot ICT worden niet benoemd. Echter, wanneer de SOx regelgeving nader wordt bekeken heeft sectie 404 een mogelijke relatie met IAM: Section 404: CEO/CFO en auditors moeten de effectiviteit van interne controles voor de financiële rapportage bevestigen. Section 404 is een belangrijke grondslag voor betrokkenheid van ICT. Het management moet de effectiviteit van de interne controles testen voor het tot stand komen van de financiele rapportage. Algemeen onderkend is het belang dat de gegevens die gebruikt worden om tot de financiële rapportage te komen, net zo goed beschermd moeten zijn door interne controles als de financiële rapportage zelf. Bedrijven kunnen kiezen voor risicobeheersing door het COSO-framework toe te passen. Het gebruik van COSO is mede ingegeven door het feit dat de SEC (Securities and Exchange Commission) het gebruik van COSO adviseert. Tabaksblat De code Tabaksblat is minder concreet dan SOx en tevens vrijblijvender als het gaat om de relatie met ICT. Waar SOx nog verwijst naar algemeen aanvaarde systemen om in control te komen, verwijst de code Tabaksblat alleen in de toelichting naar COSO. De wetgever stelt dus eisen aan risicobeheersing en rapportage ten aanzien van de bedrijfsprocessen, met als focus de financiële verslaglegging. Dit heeft indirect impact op de 14

19 informatiesystemen die door de bedrijfsprocessen worden gebruikt en op basis waarvan de financiële rapportage wordt samengesteld. Het in control zijn van de bedrijfsprocessen komt dan ook in grote mate neer op het in control zijn van de informatiesystemen. Hierbij kan worden gedacht aan: 1 De beveiliging van de informatie; 2 Wie welke informatie mag muteren; 3 Wie toegang heeft tot bepaalde informatie die is opgeslagen in die informatiesystemen (authenticatie & autorisatie); 4 Een financiële rapportage die aangeeft dat de boekhouding juist, volledig en tijdig is; 5 Hoe en waar de data wordt opgeslagen; 6 Wat er met deze data wordt gedaan, inclusief audittrails. Punten 1 en 2 van bovenstaande punten bieden aanknopingspunten voor het gebruik van IAM ter bevordering van het in controle zijn van de bedrijfsprocessen. IAM stelt bedrijven instaat om te bepalen wie toegang heeft tot welke informatie en wie daarbij de rechten heeft om deze informatie te muteren, waarbij functiescheiding wordt afgedwongen. COSO Omdat zowel SOx als code Tabaksblat al dan niet in meerdere of mindere mate naar COSO verwijst wordt COSO kort beschreven. Het COSO-model is ontwikkeld door The Committee of Sponsoring Organizations of the Treadway Commission (COSO). De interne controle van een organisatie wordt door COSO onderverdeeld in vijf controlecomponenten: 1 Controleomgeving, heeft betrekking op de cultuur binnen een organisatie en beïnvloed de bewustwording en bewustmaking van het personeel voor beheersing; 2 Risicobeoordeling, heeft betrekking op de wijze waarop een organisatie omgaat met interne en externe risico's die het bereiken van de organisatiedoelstellingen in de weg staan; 3 Beheersingsactiviteiten, zijn de maatregelen die het management neemt om ervoor te zorgen dat het beleid wordt uitgevoerd en om de gesignaleerde risico's te beheersen; 4 Informatie en communicatie, binnen de interne controle omgeving speelt het verkrijgen van de juiste informatie een belangrijke rol; 5 Monitoring, de werking van de geïmplementeerde procedures en bovenal de controlemaatregelen dient te worden bewaakt. COSO beschrijft geen concrete IT normen (controls) waartegen getoetst kan worden. COBIT daar en tegen beschrijft wel concrete normen. Organisaties maken daarom regelmatig gebruik van een combinatie tussen COSO en COBIT. De combinatie resulteert in een raamwerk voor de beheersing van de financiële rapportage (COSO) met concrete normen om de beheersing gestalte te geven (COBIT) Good practises Het belang van een systeem van interne controle maatregelen om de bedrijfsprocessen en daarmee de IT-omgeving te beheersen worden door steeds meer bedrijven onderkend. Het opstellen en implementeren van interne controle maatregelen met betrekking tot de ITomgeving, kan voor bedrijven een ingewikkelde en tijdrovende bezigheid zijn. 15

20 Om bedrijven te helpen en tot een uniforme aandachtsgebieden te komen zijn zogenoemde good practices (standaarden) ontwikkeld. Deze standaarden geven voorbeelden en handvatten om tot een stelsel van interne controle maatregelen te komen aangaande de IT-omgeving. Het is mogelijk voor bedrijven om zich tegen deze standaarden te certificeren. Binnen deze standaarden, en dan specifiek BS ISO/IEC17799:2005, is veel aandacht voor toegang tot informatie en informatiesystemen. Deze aandacht voor toegang tot informatie en informatiesystemen blijkt aangaande BS ISO/IEC17799:2005 uit onder andere de volgende hoofdstukken/paragrafen: 8.3 Termination of change of employment Responsibilities should be in place to ensure an employee s, contractor s or third party user s exit from the organization is managed, and that the return of all equipment and the removal of all access rights are completed. Change of responsibilities and employments within an organization should be managed as the termination of the respective responsibility or employment in line with this section, and any new employments should be managed as described in section Removal of access rights The access rights of all employees, contractors and third party users to information and information processing facilities should be removed upon termination of their employment, contract or agreement, or adjusted upon change. 11 Access Control 11.1 Business requirement for access control Access to information, information processing facilities, and business processes should be controlled on the basis of business and security requirements User access management To ensure authorized user access and to prevent unauthorized access to information systems. Formal procedures should be in place to control the allocation of access rights to information systems and services. The procedures should cover all stages in the life-cycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access to information systems and services. Special attention should be given, where appropriate, to the need to control the allocation of privileged access rights, which allow users to override system controls Conclusie Wet en regelgeving zoals SOx en code Tabaksblat schrijven het gebruik van IAM niet expliciet voor. Het bestaansrecht van IAM, gebaseerd op wet en regelgeving, komt voort uit de eis om aantoonbaar in control te zijn over de totstandkoming van de financiële rapportage. 16

21 Omdat de gegevens die gebruikt worden om tot de financiële rapportage te komen, net zo goed beschermd moeten zijn door interne controles als de financiële rapportage zelf is het van belang dat toegang tot en mutatie van informatie en daarbij functiescheiding wordt gewaarborgd. Het waarborgen van de toegang tot, en de mutatie van informatie door alleen bevoegde medewerkers waarbij de functiescheiding niet wordt doorbroken kan worden bewerkstelligd door het toepassen van IAM. 17

22 4 SOA en IAM Hoofdstuk 4 beschrijft de veranderingen op het gebied van IAM die het gebruik van SOA met zich meebrengt. Navolgend op het beschrijven van de belangrijkste veranderingen worden de risico s in kaart gebracht die de beschreven veranderingen met zich mee brengen. De volgende deelvraag zal dan ook in hoofdstuk 4 worden beantwoord: Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van identity and access management en welke risico s brengen deze veranderingen met zich mee?. 4.1 Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van IAM? Om de belangrijkste veranderingen die SOA behelst op het gebied van IAM inzichtelijk te maken wordt er onderscheidt gemaakt in twee groepen gebruikers. De twee groepen worden als volgt gedefinieerd: 1 Beheerders; hieronder wordt verstaan medewerkers, intern dan wel extern, die verantwoordelijk zijn voor het uitvoeren van beheertaken binnen de IT-omgeving. Deze groep medewerkers bestaat uit: netwerk-, systeem- of applicatiebeheerders. 2 Gebruikers; de tweede groep zijn de gebruikers, dit kunnen medewerkers dan wel klanten van een organisatie zijn die gebruik maken van de diensten/applicaties welke beschikbaar zijn gesteld De beheerders De beheerders zijn verantwoordelijk voor het dagelijksbeheer binnen de IT-omgeving. Dit houdt onder andere in dat zij de IT-omgeving monitoren, incidenten oplossen en wijzigingen doorvoeren. In een traditionele IT-omgeving hebben de beheerders toegang tot de verschillende componenten en applicaties binnen de IT-omgeving. Het verkrijgen van toegang gaat door middel van beheeraccounts (administratoraccounts). Het gebruik van deze beheeraccounts met daaraan in de meeste gevallen gekoppeld brede toegangsrechten stelt de beheerders instaat om hun beheertaken uit te voeren. De introductie van SOA laat dit in principe onveranderd. Binnen SOA zijn er nog steeds systemen, applicaties en netwerkcomponenten aanwezig welke moeten worden beheerd. Het gebruik van SOA introduceert zelfs nieuwe systemen/componenten welke tevens moeten worden beheerd. Enkele voorbeelden van deze systemen en of componenten zijn de systemen die samen de ESB vormen, dan wel de repository. 18

23 Presentatielaag Logicalaag (ESB, Repository, Orchestration) Beheerders Datalaag Beheerders Figuur 5: Toegang beheerders binnen SOA Zoals in hoofdstuk 3 is beschreven zijn er binnen IAM vijf hoofdprocessen te onderkennen. Gezien het feit dat binnen SOA er voor de beheerders ten opzichte van de traditionele ITinfrastructuur weinig veranderd zullen de IAM-hoofdprocessen tevens niet veranderen. Ondanks dat er nieuwe te beheren systemen en componenten worden geïntroduceerd. Aan de bewering, dat er niets veranderd ligt wel een belangrijke aanname ten grondslag. Namelijk dat beheeractiviteiten niet door middel van services kunnen worden uitgevoerd. Om beheer via services te kunnen uitvoeren zullen systemen en componenten geschikt moeten worden gemaakt om services te kunnen interpreteren en te verwerken. Dit houdt in dat netwerkcomponenten zoals routers, swichtes moeten worden verzien van extra logica. Daarnaast moet alle functionaliteit die een beheerder moet kunnen uitvoeren op een systeem of component beschikbaar worden gesteld via services. Beheerders moeten regelmatig complexe handelingen uitvoeren om bijvoorbeeld incidenten op te lossen. Het is lastig en kostbaar om al deze nodige functionaliteit beschikbaar te stellen door middel van services. Daarnaast mochten er storingen zijn in bijvoorbeeld de ESB en services niet meer aankomen, dan kan een beheerder de systemen/componenten niet benaderen De gebruikers Ten aanzien van de gebruikers zijn er wel veranderingen met betrekking tot IAM door het gebruik van SOA. In een traditionele IT-architectuur hebben gebruikers toegang tot informatie en informatiesystemen door gebruik te maken van (veel) verschillende accounts. Bijvoorbeeld 19

24 een account om in te loggen op Windows met daarnaast nog andere accounts om in te loggen op specifieke applicaties. Binnen een SOA architectuur bestaan deze verschillende gebruikersaccounts niet meer. Gebruikers hebben toegang tot een presentatielaag waar de voor hen beschikbare services worden gepresenteerd. Binnen de doelsystemen zijn er dus geen gebruikersaccounts meer aanwezig. In plaats daarvan zijn er functionele accounts in de doelsystemen. Door gebruik te maken van deze functionele accounts kunnen de services vanuit de repository verzonden worden naar de doelsystemen en omgekeerd. Gebruikers Services Presentatielaag 1 IAM 2 IAM-systeem Logicalaag (ESB, Repository, Orchestration) Datalaag Provisioning Doelsystemen LDAP 1) Authenticeren 2) Gebruik services waartoe gebruiker geautoriseerd is Figuur 6: Toegang gebruikers binnen SOA Zoals in hoofdstuk 3 is beschreven zijn er binnen IAM vijf hoofdprocessen te onderkennen. Per hoofdproces wordt kort beschreven wat de impact van het gebruik van SOA is op dit proces, vanuit het oogpunt van de gebruikers. Gebruikersbeheer (Usermanagement) De activiteiten gericht op het beheer van de gehele cyclus van een gebruiker (indiensttreding, functiewijziging, ontslag) zullen door het gebruik van SOA niet veranderen. Het gebruik van andere technologie heeft immers geen invloed op de levenscyclus van een gebruiker binnen een organisatie. Authenticatiebeheer (Authenticatiemanagement) De activiteiten gericht op het beheer van authenticatiemiddelen (passwords, tokens, etc) 20

25 zullen niet veranderen door het gebruik van SOA. Hoewel de gebruiker geen accounts meer bezit in de ICT-objecten met de daarbij horende authenticatiemiddelen bezit de gebruiker wel over authenticatiemiddelen om zijn/haar identiteit vast te stellen om zo toegang te krijgen tot de voor de gebruiker beschikbaar gestelde services. Autorisatiebeheer (Autorisatiemanagement) De activiteiten gericht op het beheer van autorisaties van gebruikers blijft hetzelfde, de rechten die een gebruiker heeft in een traditionele IT-infrastructuur komt meestal tot uiting tot het bepalen van het al dan niet toegang hebben tot bepaalde ICT-objecten. Waarbij binnen deze ICT-objecten ook de rechten worden bepaald. Bij SOA wordt nog steeds bepaald welke rechten een gebruiker heeft. Het bepalen van deze rechten komt echter niet tot uiting in het bepalen van toegang tot ICT-objecten en de rechten daarbinnen. Het bepalen van rechten komt tot stand door het toekennen van services aan de gebruiker. Provisioning Het handmatig en/of geautomatiseerd propageren van gebruikers - en autorisatiegegevens naar ICT-objecten. Het propageren veranderd, in de traditionele IT-infrastructuur worden de gebruikers- en autorisatiegegevens per ICT-object bepaald en geprovisioned naar het betreffende ICT-object. Bij SOA zijn alle services centraal opgeslagen in de repository. Centraal moet beschikbaar worden gemaakt welke services een gebruiker mag uitvoeren. Vanuit het IAM-systeem worden er dus rechten gepropageerd naar een doelsysteem. In figuur 6 is dit weergeven, waarbij de gegevens vanuit het IAM-systeem worden gepropageerd naar bijvoorbeeld een LDAP. Monitoring & audit Logging, auditing en rapportage blijft niet onveranderd. Voor het opstellen van een audit rapportage worden de gegevens in het bronsysteem, het IAM-systeem (SOLL) en informatie betreffende de aan te roepen services (IST) uit de centrale registratie gebruikt. Informatie over gebruikersrechten in de ICT-objecten (doelsystemen) is immers niet meer voorhanden. Concluderend kan worden gesteld dat de processen in opzet niet veranderen. Alleen de inhoud van de processen verandert. Bij autorisatiebeheer verandert het toekennen van rechten binnen ICT-objecten in het toekennen van uit te voeren services. Provisioning behelst het kenbaar maken van de uit te voeren services in een centrale registratie in plaats van het aanmaken van accounts met de daarbij horende rechten op systemen en applicaties. Tenslotte blijft het maken van audit rapportages mogelijk waarbij in plaats van informatie uit de doelsystemen informatie uit de centrale registratie wordt gebruikt om de IST situatie te bepalen. 4.2 Welke risico s brengen deze veranderingen met zich mee? De veranderingen beschreven in paragraaf 4.1 illustreren dat voor de gedefinieerde groep beheerders er geen veranderingen plaatsvinden bij het gebruik van SOA ten opzichte van de traditionele IT-infrastructuur. 21

26 Voor de gedefinieerde groep gebruikers treden er echter wel veranderingen op. De verandering beschreven bij het IAM hoofdproces Monitoring & audit brengt een risico met zich mee. In traditionele IT-infrastructuur logt een gebruiker in op een systeem of applicatie door middel van een persoonsgebonden account. Er van uitgaande dat IAM goed is ingeregeld. Door het gebruikt van een persoonsgebonden account waarmee toegang wordt verleend tot het doelsysteem is het mogelijk om door middel van logging vast te stellen welke gebruiker op welk moment toegang heeft gehad tot een doelsysteem en welke activiteiten deze gebruiker heeft uitgevoerd. Bij SOA logt een gebruiker in op de presentatielaag, waarna de voor de gebruiker beschikbare services beschikbaar worden gesteld (allemaal tegelijkertijd of een voor een). Wanneer een gebruiker een service aanroept is dit door middel van logging in de presentatielaag vast te stellen. Dit verzoek wordt door Orchestration uitgevoerd. Het uitvoeren van de service door Orchestration en het terugkoppelen van de resultaten aan de gebruiker kan door logging worden vastgesteld in de logicalaag. Orchestration/repository communiceert met de doelsystemen met behulp van functionele accounts. De doelsystemen ontvangen een service en verwerken deze en sturen het resultaat terug via de ESB naar Orchestration. De logging op het doelsysteem laat zien dat een service is ontvangen, uitgevoerd en het resultaat is teruggestuurd. Door het gebruik van functionele accounts tussen de Orchestration/repository en de doelsystemen wordt de relatie die tussen gebruiker en de verrichtte handeling doorbroken. De log informatie op de doelsystemen laat immers niet zien welke gebruiker de service heeft aangeroepen en de bijhorende handeling heeft uitgevoerd. Om als organisatie in control te zijn moet de organisatie kunnen aantonen inzicht te hebben wie op welke moment informatie heeft geraadpleegd, dan wel gemuteerd zonder dat daarbij de functiescheiding is doorbroken. Door het ontbreken van de koppeling tussen gebruiker en uitgevoerde handelingen op het doelsysteem kan niet worden aangetoond wie op welk moment informatie heeft geraadpleegd en of gemuteerd. Daarnaast kan niet worden aangetoond of de gehanteerde functiescheiding al dan niet is doorbroken. Dit betekent dat organisatie die gebruik maken van SOA compenserende maatregelen moeten implementeren om bovenstaand risico te beheersen. 4.3 Welke kansen brengen deze veranderingen met zich mee? Naast de risico s die SOA met zich mee brengt op het gebied van IAM, zoals beschreven in paragraaf 4.2, brengt SOA ook mogelijkheden en kansen ten opzichte van de traditionele ITarchitectuur. Deze paragraaf beschrijft de voordelen die SOA brengt met betrekking tot IAM. 22

27 4.3.1 Centralisatie Het gebruik van SOA draagt zorg dat er voor de gebruikers maar één doelsysteem te onderkennen is waar autorisatiegegevens staan. De autorisatiegegevens zijn de informatie die per gebruiker weergeeft welke services door deze gebruiker mogen worden uitgevoerd. In figuur 6 wordt dit weergegeven en zijn deze gegevens opgeslagen in een centrale LDAP. In de traditionele IT-infrastructuur is deze informatie verspreidt over de verschillende doelsystemen (bijvoorbeeld rechten tot applicaties en fileshares). Doordat de gegevens centraal zijn opgeslagen wordt het provisioning proces vereenvoudigd. Wanneer er voor een gebruiker toegang tot services moet worden verleend, wordt bij SOA bijhorende rechten aangemaakt in bijvoorbeeld de LDAP. Bij de traditionele IT-infrastructuur moet er per doelsysteem rechten worden aangemaakt. Wanneer een gebruiker bijvoorbeeld uit dienst gaat is het tevens eenvoudiger om de autorisaties te verwijderen. De rechten tot services worden uit de LDAP verwijderd. Bij de traditionele ITinfrastructuur moet door middel van het provisioning proces de autorisaties per doelsysteem worden verwijderd. Een uitzondering hierop zijn de autorisaties met betrekking tot de beheerders. Zoals in paragraaf is beschreven zijn er geen veranderingen voor deze groep ten op zichtte van de traditionele IT-infrastructuur, met betrekking tot autorisaties op doelsystemen Rapportage Wanneer IAM binnen een organisatie is geïmplementeerd gebruik makende van een centraal IAM-systeem (zie figuur 4) is het mogelijk om de informatie in het bronsysteem, het IAMsysteem en de gegevens in de doelsystemen de vergelijken. Op deze manier kan de informatie in het IAM-systeem (SOLL) en de informatie uit de doelsystemen (IST) worden vergeleken. Met behulp van deze rapportage kunnen organisaties controleren of het IAM naar behoren functioneert. De informatie uit het bronsysteem en doelsystemen in combinatie met de informatie uit het IAM-systeem stelt een organisatie instaat om verschillen te detecteren. In een traditionele IT-infrastructuur is het voor een SOLL-IST vergelijking noodzakelijk om de autorisatie gegevens uit alle doelsystemen op te vragen en te vergelijken met de in het IAMsysteem toegekende rechten. Bij SOA is er maar één doelsysteem namelijk de centrale LDAP. Doordat er maar een doelsysteem aanwezig is wordt het opvragen en vergelijken van de informatie vereenvoudigd. Opgemerkt dient te worden dat dit alleen voor de gebruikers geldt. Voor de beheerders treden er geen veranderingen op. De groep heeft immers autorisaties op alle doelsystemen welke worden beheerd. Om voor de beheerders een SOLL-IST rapportage te maken zullen uit alle doelsystemen de autorisatie gegevens dienen te worden opgevraagd. 23

28 4.3.3 Single Sign On In een traditionele IT-infrastructuur heeft een gebruiker toegang tot meerdere doelsystemen. Dit houdt vaak in dat gebruikers over meerdere gebruikersnamen en wachtwoorden beschikken om toegang te verkrijgen tot deze doelsystemen. Het onthouden van meerdere gebruikersnamen met bijhorende wachtwoorden is gebruiksonvriendelijk en levert potentiële beveiligingsrisico s op. Gebruikers ervaren het als onplezierig wanneer zij veel informatie moeten onthouden. Dit te meer als de gebruikers gedwongen worden om de wachtwoorden meerdere malen per jaar te wijzigen. Het moeten onthouden en wijzigen kan de volgende beveiligingsrisico s met zich mee brengen: 1) Gebruikers gaan gebruikersnamen en/of wachtwoorden opschrijven wanneer zij verwacht worden meerdere gebruikersnamen/wachtwoorden te gebruiken. Door het opschrijven van gebruikersnamen en/of wachtwoorden neemt de kans toe dat onbevoegde kennisnemen van deze informatie en zich mogelijk toegang kunnen verschaffen; 2) Gebruikers maken gebruik van eenvoudige wachtwoorden welke zij makkelijk kunnen onthouden. Deze eenvoudige wachtwoorden zijn makkelijker te raden en te kraken door kwaadwillende. Daarnaast zorgt het gebruik van veel verschillende gebruikersnamen en wachtwoorden ook voor druk bij de helpdesk. De kans dat gebruikers wachtwoorden vergeten neemt toe met de hoeveelheid wachtwoorden de gebruikers worden geacht te onthouden. Om de gebruikersnaam/wachtwoord problemen te verhelpen is het Single Sign On (SSO) principe bedacht. Gebruikers hoeven nog maar een keer in te loggen met een gebruikersnaam en een wachtwoord waarna zij toegang hebben tot alle voor hen beschikbare doelsystemen. In de praktijk blijkt dit lastig te realiseren. Het koppelen van de verschillende doelsystemen waardoor er maar een gebruikersnaam en wachtwoord nodig is blijkt complex. SOA maakt het toepassen van SSO eenvoudiger. Gebruikers maken gebruik van een presentatielaag (bij voorbeeld een webomgeving) waarna inloggen de benodigde functionaliteit wordt geboden in de vorm van services. De informatie die bepaalt tot welke services een gebruiker toegang heeft is centraal opgeslagen in bijvoorbeeld een LDAP. Daarbij heeft de gebruiker geen accounts op de doelsystemen. De combinatie van de informatie die centraal aanwezig is en het ontbreken van autorisaties op de doelsystemen maakt het mogelijk dat de gebruiker maar een keer hoeft in te loggen. De gebruiker logt in op de presentatielaag. Tijdens het inloggen wordt de identiteit van de gebruiker vastgesteld en wordt de gebruiker geauthenticeerd. Vervolgens kunnen alle services waarvoor de gebruiker is geautoriseerd beschikbaar worden gesteld. Bijvoorbeeld, een gebruiker heeft toegang tot een website. Op deze website kan de gebruiker in loggen. Als de gebruiker is ingelogd wordt de voor deze gebruiker specifieke functionaliteit beschikbaar gemaakt door middel van webservices. 24

29 Concluderend kan worden gesteld dat SOA het toepassen van SSO vereenvoudigt. Echter, dit geldt alleen voor de gebruikers. Voor de beheerders is dit ander, zij hebben wel accounts op de verschillende doelsystemen om beheeractiviteiten uit te voeren Bepalen autorisaties Een van de doelstellingen van IAM is dat gebruikers toegang tot informatie krijgen op basis van het need-to-use principe waarbij functiescheiding wordt gewaarborgd. Om het verstrekken van autorisaties op need-to-use basis mogelijk te maken moet per deelsysteem inzichtelijk worden gemaakt hoe een gebruiker toegang wordt verleend tot dit doelsysteem. Daarbij moet ook worden onderzocht of er binnen het doelsysteem verschillende rollen zijn te onderkennen die samenhangen met verschillende rechten. Bijvoorbeeld, gebruikers hebben toegang tot een applicatie. Echter, binnen deze applicatie zijn verschillende rollen te onderkennen, waarbij een gebruiker vanuit het oogpunt van functiescheiding niet over meerdere rollen binnen de applicatie mag beschikken. Het in kaart brengen van de autorisaties op de doelsystemen met binnen ieder doelsysteem objecten welke elk eigen autorisatieparameters bevatten is bewerkelijk. Zeker als bepaald moet worden welke autorisatieparameters niet aan dezelfde gebruiker mogen worden toegekend in het kader van functiescheiding. Bedrijven die beginnen met de implementatie van IAM binnen een traditionele IT-infrastructuur lopen tegen de uitdaging aan van het bepalen van de verschillende autorisatieparameters en de daarbij horende functieprofielen. De autorisatieparameters moeten in kaart worden gebracht waarmee deze gekoppeld moeten worden aan een functie. Dit betekent dat de technische informatie uit de doelsystemen moet worden gehaald, geanalyseerd en gekoppeld aan in het bedrijfsproces erkende rollen. Doordat SOA geen gebruik maakt van autorisatiegegevens op de doelsystemen voor de gebruikers hoeft bovenstaande exercitie niet te worden uitgevoerd. Daarentegen moet bepaald worden welke service door een gebruiker mag worden uitgevoerd. Waarbij functiescheiding wordt gewaarborgd. Het voordeel van SOA is dat rechten kunnen worden toegekend op basis van functionaliteit zonder dat daarvoor de autorisaties per doelsysteem in kaart hoeven te worden gebracht. Het IAM hoofdproces autorisatiebeheer wordt op deze manier vereenvoudigd. In de eerste plaats tijdens de implementatiefase. Waarbij er minder werk betreffende het in kaart brengen van de autorisaties hoeft te worden verricht. Na de implementatie is er eenvoudiger beheer van de autorisaties mogelijk omdat gebruikers geautoriseerd zijn services uit te voeren en daarmee geen autorisatie op doelsystemen gemoeid zijn. Zoals in de eerder is opgemerkt geldt bovenstaande alleen voor de gebruikers en niet voor de beheerders. De beheerders hebben immers wel autorisaties nodig op de doelsystemen om de beheertaken uit te voeren. 25

30 5 Samenvatting, Conclusie en Aanbevelingen Hoofdstuk 5 beschrijft de conclusies en aanbevelingen die volgen op de geïdentificeerde risico s in hoofdstuk 4. Tevens worden de voorliggende hoofdstukken samengevat. Paragraaf 5.1 beschrijft de conclusie die kan worden getrokken naar aanleiding van de uiteenzetting in de voorgaande hoofdstukken en beantwoord daarmee het eerste gedeelte van de onderzoeksvraag: Wat zijn de belangrijkste veranderingen die SOA behelst, die de aantoonbare beheersing van informatie bemoeilijkt op het gebied van identity and access management Tevens zullen in paragraaf 5.1 de voorliggende hoofdstukken kort worden samengevat waarbij de antwoorden op de verschillende deelvragen, zoals beschreven in paragraaf 1.2.1, worden beantwoord. Vervolgens geeft paragraaf 5.2 antwoord op het tweede gedeelte van de onderzoeksvraag: welke aanbevelingen kunnen worden gedaan om deze veranderingen het hoofd te bieden?. Hiertoe wordt een beschrijving gegeven van de mogelijke oplossing om de in paragraaf 5.1 geconcludeerde nadelige veranderingen het hoofd te bieden. 5.1 De belangrijkste veranderingen die SOA behelst, die de aantoonbare beheersing van informatie bemoeilijkt op het gebied van IAM Deelvraag 1: Wat is een Service Oriented Architecture? SOA behelst een architectuur waar met behulp van services een gebruiker de benodigde functionaliteit wordt geboden. De services worden aangeboden in de presentatielaag. Het gebruik van services stelt een organisatie instaat om uniforme bouwblokken (services) te creëren die na gelang de noodzaak samen de gewenste functionaliteit verzorgen. Het gebruik van uniforme bouwblokken geeft een organisatie meer flexibiliteit. De bouwblokken kunnen hergebruikt worden. Daarnaast kan de functionaliteit beter worden afgestemd op de behoefte in de bedrijfsprocessen. Ook wordt het eenvoudiger om wijzigingen in applicaties of systemen door te voeren. Gebruikers hebben niet meer direct toegang tot bijvoorbeeld applicaties. In een SOA is een tussenlaag gecreëerd die zorg draagt voor het versturen en ontvangen van de services die aangeroepen worden door bijvoorbeeld de gebruiker. 26

31 5.1.2 Deelvraag 2: Wat zijn de verschillen tussen een Service Oriented Arhcitecture en huidige IT-architectuur? De verschillen komen voornamelijk door de tussenlaag die in SOA wordt gecreëerd. In een traditionele IT-infrastructuur is (meestal) sprake van het client-server principe. De gebruiker heeft door middel van een lokale applicatie/interface (client) toegang tot de informatie/functionaliteit die centraal beschikbaar is gesteld. De gebruiker heeft met behulp van de lokale client direct contact met de server. Bij SOA is tussen de client en de server een extra laag gecreëerd, hierdoor is er geen direct contact meer tussen client en server. Over deze tussenlaag, bestaande onder andere uit de Enterprise Service Bus (ESB) gaan uniforme berichten heen en weer. Het gebruik van uniforme berichten die worden verstuurd naar aanleiding van het aanroepen van een service zorgt voor extra overhead ten opzichte van de traditionele IT-infrastructuur. Daarnaast moeten de berichten worden geïnterpreteerd door de verschillende systemen. Dit vraagt tevens om extra rekenkracht van deze systemen. Door het ontbreken van de directe link tussen client en server kunnen wijzigingen aan de kant van de client (presentatielaag) of aan de kant van de servers (datalaag) eenvoudiger worden doorgevoerd Deelvraag 3: Welke wet en regelgeving is van toepassing op het gebied van IAM? Concreet gezien is er geen wet en regelgeving die expliciet van toepassing is op het gebied van IAM. Echter, verschillende wet en regelgevingen zoals SOx en code Tabaksblat schrijven voor dat een organisatie in control moet zijn over de totstandkoming van de financiële rapportage. Om in control te komen over de financiële rapportage betekent in de praktijk dat bedrijven ook in control moeten zijn over de gegevens die gebruikt worden voor de totstandkoming van de financiële rapportage. Om in control te zijn over de financiële gegevens is het voor organisaties van belang om inzichtelijk te hebben wie toegang hebben tot de financiële gegevens. Wie gerechtigd zijn om veranderingen in deze gegevens aan te brengen en dat daarbij functiescheiding wordt gewaarborgd. Wanneer IAM op een juiste manier wordt geïmplementeerd binnen een organisatie kan de betreffende organisatie aantonen dat het in control is als het gaat om het verlenen en het controleren van verstrekte toegang tot bijvoorbeeld de financiële informatie. Wet en regelgeving schrijft expliciet het gebruik van IAM niet voor, impliciet is het een gevolg van het voorschrijven dat bedrijven in control moeten zijn Deelvraag 4: Wat zijn de belangrijkste veranderingen die SOA behelst op het gebied van identity and access management en welke risico s brengen deze veranderingen met zich mee? De belangrijkste verandering die SOA behelst op het gebied van IAM ten opzichte van de traditionele IT-infrastructuur is introduceren van een tussenlaag (logicalaag). Door de introductie van deze tussenlaag heeft de gebruiker geen directe link meer met bijvoorbeeld informatie centraal beschikbaar gesteld in een database. In een traditionele IT-infrastructuur heeft de gebruiker een account waarmee de gebruiker via de client kan inloggen op de server en 27

32 de benodigde functionaliteit beschikbaar komt. Een gebruiker roept een service aan welke als uniform bericht wordt verstuurd over de logicalaag. De systemen die samen de logicalaag vormen maken gebruik van functionele accounts om de berichten te versturen naar de systemen (servers) in de datalaag. Door het introduceren van de logicalaag en daarmee het gebruik van functionele accounts is de link tussen client en server verbroken. Het verbreken van deze link brengt een risico met zich mee. Door het gebruik van uniforme berichten en functionele accounts is het niet vast te stellen op de doelsystemen welke gebruiker wanneer welke handeling heeft uitgevoerd. Ook het vaststellen of functiescheiding wordt doorbroken is niet te bepalen. Log-informatie op een doelsysteem zal alleen de afhandeling van uniforme berichten laten zien en het tijdstip waarop het is uitgevoerd. Informatie over welke gebruikers de betreffende actie heeft geïnitieerd is niet beschikbaar. Door dat de uniforme berichten geen relatie hebben met de gebruiker is niet vast te stellen of een gebruiker services aanroept waarvoor het niet is geauthenticeerd en functiescheiding wordt doorbroken. Bij de beantwoording van deelvraag 3 is geconcludeerd dat vanuit wet en regelgeving wordt voorgeschreven dat organisatie in control moeten zijn met betrekking het totstandkomen van de financiële rapportage. Om het in control zijn te bewerkstelligen houdt dat in dat organisatie moeten weten, kunnen aantonen en controleren wie toegang heeft tot welke informatie en mutaties mag uitvoren. Zonder dat de beoogde functiescheiding wordt doorbroken. Door de introductie van de tussenlaag en het gebruik van functionele accounts kunnen organisaties niet aantonen dat zij in control zijn op het gebied van IAM. In het ergste geval kan dit resulteren dat een organisatie niet in control is over de totstandkoming van de financiële rapportage. Het niet in control zijn over de totstandkoming van de financiële rapportage betekend dat bedrijven niet voldoen aan wet en regelgeving zoals SOx en code Tabaksblat. 5.2 Aanbevelingen om de veranderingen die SOA behelst het hoofd te bieden Het belangrijkste geïdentificeerde risico is dat door het gebruik van functionele accounts niet is aan te tonen wat de activiteiten van een gebruiker op een doelsysteem is geweest. Daardoor kan niet worden vastgesteld welke gebruiker informatie heeft geraadpleegd, veranderd of heeft verwijderd en aangetoond dat daarbij gehanteerde functiescheiding niet is doorbroken. Om het probleem, veroorzaakt door het gebruik van functionele accounts het hoofd te bieden zullen organisaties compenserende maatregelen moeten nemen. De mogelijke compenserende maatregelen zijn in paragraaf beschreven. Paragraaf is bedoeld als aanbeveling en biedt organisaties mogelijke oplosrichtingen voor het realiseren van de compenserende maatregelen. Daarbij wordt antwoord gegeven op het tweede gedeelte van de centrale probleemstelling. 28

33 5.2.1 Deelvraag 5: Welke maatregelen kunnen worden getroffen om de geïdentificeerde risico s te beperken? Zoals eerder beschreven, onder andere in hoofdstuk 2, kan SOA worden onderverdeeld in drie verschillende lagen, de presentatielaag, de logicalaag en de datalaag. Aangenomen wordt dat in iedere laag informatie met betrekking tot de gebeurtenissen in deze laag aanwezig is. Met andere woorden logging is geactiveerd in de drie onderkende lagen binnen SOA. Per laag wordt beschreven welke informatie logischerwijs wordt gelogd. Presentatielaag Aangenomen wordt dat in deze laag wordt geregistreerd dat een gebruiker aanlogt en services aanroept. In de presentatielaag is de informatie aanwezig om een gebruiker te koppelen aan de services welke door de gebruiker zijn aangeroepen. Het activeren van logging in de presentatielaag maakt het dus mogelijk om vaste te stellen welke gebruiker op een bepaald tijdstip een bepaalde service heeft aangeroepen. Logicalaag Aangenomen wordt dat in de logicalaag wordt bijgehouden welke service is aangeroepen en verstuurt. Tevens wordt bijgehouden welke service vanuit de datalaag is ontvangen en het antwoord wat wordt verstuurd aan de gebruiker. In de logicalaag zal relatief veel informatie kunnen worden vergaard doordat, in de logicalaag, Orchestration verantwoordelijk is voor het workflow management. In de logicalaag is dus informatie aanwezig omtrent aanroep vanuit de presentatielaag, uitvoer en terugkoppelen van het antwoord aan de presentatielaag. Het activeren van logging in de logicalaag maakt het mogelijk om vast te stellen wanneer een service is aangeroepen, wanneer deze is uitgevoerd, wanneer het antwoord vanuit de datalaag is ontvangen en tenslotte wanneer het antwoord is teruggekoppeld aan de presentatielaag. Datalaag Aangenomen wordt dat in de datalaag per doelsysteem wordt bijgehouden wanneer een service is ontvangen, verwerkt en het antwoord is teruggegeven aan de logicalaag. Het bijhouden van deze informatie maakt het mogelijk om per doelsysteem vast te stellen wanneer services zijn ontvangen en verwerkt. Echter, het is niet mogelijk om vast te stellen in de datalaag welke gebruiker de betreffende service heeft uitgevoerd. Bovenstaande alinea s beschrijven dat in elk van de lagen informatie wordt opgeslagen. Deze informatie maakt het mogelijk om per laag relaties te leggen tussen gebeurtenissen die in één van de lagen hebben plaatsgevonden. Om uiteindelijk vast te kunnen stellen welke gebruiker een service heeft aangeroepen, op het niveau van de datalaag, zullen er relaties moeten worden gelegd tussen de aanwezige informatie in de verschillende lagen. Zodat uiteindelijk de informatie aanwezig in de presentatielaag gebruiker aanroepen service wordt gebruikt om onomstotelijk vast te stellen dat de informatie in de datalaag ontvangen service verwerken service relateert aan het aanroepen van de service in de presentatielaag door de gebruiker. 29

34 Figuur 7: Log faciliteiten en centraal monitorsysteem Een mogelijke oplossing voor het leggen van de relaties tussen de beschikbare informatie in de verschillende lagen is het gebruik van zogenaamde sessienummers. Wanneer gebruikers inloggen op de presentatielaag kan dit gezien worden als een sessie. Aan deze sessie wordt een uniek nummer toegekend het sessienummer. Het sessienummer wordt verzonden met iedere handeling die een gebruiker uitvoert. Als een gebruiker een service aanroept zal het sessienummer in het aanroepverzoek worden verstuurd. Het aanroepen van een service resulteert in het versturen van een uniform bericht via de ESB naar het doelsysteem. Het sessienummer wordt toegevoegd aan het uniforme bericht. Bij het verwerken van het bericht op het doelsysteem en het uitvoeren van de handelingen die resulteren uit het ontvangen van het uniforme bericht wordt het sessienummer gekoppeld aan de uitgevoerde activiteiten. Door het consequent toevoegen en meesturen van een sessienummer welke is gekoppeld aan een sessie uitgevoerd door een gebruiker is het mogelijk om in iedere laag van de SOA het sessienummer en de daarbij horende activiteiten te loggen. Activiteiten uitgevoerd op een doelsysteem zijn nog steeds niet terug te herleiden aan een gebruiker maar zijn nu te herleiden tot een sessienummer. Door de log-informatie op alle lagen van SOA te koppelen is het mogelijk om door middel van het unieke sessienummer activiteiten in de verschillende lagen van SOA met elkaar te koppelen, relaties te leggen, en uiteindelijk te herleiden tot een gebruiker (figuur 7). 30