De (on)beheersbaarheid. van toegangsbeveiliging. * de controleur: internecontrolemedewerker of auditor. Ing. P. Mienes RE en B.

Maat: px
Weergave met pagina beginnen:

Download "De (on)beheersbaarheid. van toegangsbeveiliging. * de controleur: internecontrolemedewerker of auditor. Ing. P. Mienes RE en B."

Transcriptie

1 42 De (on)beheersbaarheid van toegangsbeveiliging Ing. P. Mienes RE en B. Bokhorst RE RA Waarom wil het nog steeds maar niet lukken om op een efficiënte, effectieve en voor allen goed controleerbare manier te regelen dat toegang wordt verleend op basis van het need to access -principe? Hoe komt het dat ondanks de vele medewerkers die bij dit proces betrokken zijn, auditors nog altijd tot te veel negatieve bevindingen op dit vlak komen? Wanneer komt de tijd dat de organisatie het bijzonder belangrijke proces van logische toegangsbeveiliging adequaat beheerst? Maar vooral: op welke manier kan aan de onbeheersbaarheid een einde worden gemaakt? Inleiding Onbeheersbaarheid van toegangsbeveiliging? Jawel, want het is alleszins gerechtvaardigd om te twijfelen aan het in control zijn van deze beheertaak. En dat is niet verwonderlijk: met de klassieke autorisatiearchitecturen is het in de IT-infrastructuur van vandaag nagenoeg onmogelijk om te waarborgen dat autorisaties zijn verleend niet anders dan op basis van het need to access - principe. Security administrators zijn zich bewust van de tekortkomingen, lijnmanagers weten ook dat het proces niet adequaat functioneert, IC-medewerkers raken hun werk moede, en auditors signaleren andermaal dat er ruimte is voor verbetering. Hoe is dit na bijna dertig jaar bouwen aan automatisering mogelijk, en hoe zijn de te ruime autorisaties te verantwoorden tegenover de weten/of regelgever en de klanten van de organisatie? Een veelgehoorde verklaring is dat het historisch zo is gegroeid. Dat is een onmiskenbaar feit, maar geen reden om ons neer te leggen bij het gebrek aan beheersing van de (met name logische) toegangsbeveiliging. Vanwege een nog steeds toenemende graad van automatisering, en een daarmee steeds grotere afhankelijkheid van automatisering, toegenomen maatschappelijke aandacht voor privacy en fraude, toegenomen bedreigingen van buiten af, en de niet afgenomen verantwoordelijkheid van het management van een organisatie om adequate maatregelen te treffen voor de interne en externe bedreigingen, is het meer dan ooit tevoren van belang dat organisaties hun toegangsbeveiliging daadwerkelijk en voor derden aantoonbaar op orde hebben. Een relevante vraag hierbij is, in welke omgevingen van het OTAP-model (Ontwikkeling, Test, Acceptatie, Productie) sprake dient te zijn van een adequate toegangsbeveiliging. Doorgaans richt de grootste beveiligingsinspanning zich op het productiesysteem, en vertrouwt men erop dat het change-managementproces waarborgt dat uitsluitend integere applicaties op het productiesysteem worden geïmplementeerd. Als we echter bedenken dat business rules op het ontwikkelsysteem in de applicaties worden geprogrammeerd, dan zal duidelijk zijn dat elk van de omgevingen in het OTAP-model een zodanig niveau van beveiliging verdient dat de integriteit van de applicatie steeds gewaarborgd is. Tenzij in het acceptatietraject een volledige source code review plaatsvindt, begint adequate beveiliging dus al op het ontwikkelsysteem. Dit artikel richt zich op de tactische en operationele beheersbaarheid van toegangsbeveiliging met name het beheer van autorisaties zodanig dat een adequaat beveiligingsniveau wordt bereikt en in stand gehouden op alle systemen en in alle omgevingen die goede beveiliging verdienen. Achtereenvolgens komen de volgende vragen aan de orde: Wat is de problematiek van het huidige beheer van toegangsbeveiliging? Welke beveiligingsmodellen kunnen worden onderscheiden, en wat zijn de voor- en nadelen van de ver- schillende modellen? Welke voordelen biedt RBAC (Role Based Access Control) boven de andere modellen, en waarom zou dit de oplossing voor de geschetste problemen zijn? Welke lessen zijn geleerd uit eerdere RBAC-implementaties? Hoe wordt RBAC procedureel ingebed in het proces van toegangsbeveiliging? De praktische onbeheersbaarheid van toegangsbeveiliging Bij de beheersing van de toegangsbeveiliging zijn ten minste de volgende partijen betrokken: de eigenaar van het object waar de autorisatie betrekking op heeft; de aanvrager van autorisaties, veelal de manager van de betrokkene; de uitvoerende, deze implementeert de autorisatie; de controleur: internecontrolemedewerker of auditor.

2 De (on)beheersbaarheid van toegangsbeveiliging 43 Alle partijen stuiten in de praktijk op voor hen soms onoverkomelijke problemen bij de beheersing van de toegangsbeveiliging, omdat het autorisatiemodel en/of de toegepaste hulpmiddelen binnen het beheerproces de taken van deze partijen niet op een effectieve en efficiënte manier ondersteunen. Probleem van sommige objecteigenaren Als ze zich al bewust bezighouden met de beveiliging van hun objecten (er zijn positieve uitzonderingen!), dan is er een groep objecteigenaren die geen winst lijkt te behalen met het verbeteren van de opzet van de beveiliging, namelijk de eigenaren van applicaties. Vaak is het bijvoorbeeld in applicaties al zo geregeld dat gebruikers aan een autorisatieprofiel ( rol) worden gekoppeld, waarmee een voor de objecteigenaar redelijk beheersbare situatie bestaat. De koppeling van functionele rechten (autorisaties) aan de autorisatieprofielen is vastgelegd in de applicatie en vergt dus op het moment van een autorisatieaanvraag voor een gebruiker geen specifieke aandacht. De koppeling van gebruikers (user-id s) aan autorisatieprofielen vindt veelal plaats op aanvraag van de manager van de gebruiker en met goedkeuring van de objecteigenaar. Voor de eigenaar van dit type objecten werkt dit redelijk goed. Deze vertrouwt op de juiste beoordeling door de manager, en mag hopen dat deze te zijner tijd ook het vervallen van de noodzaak voor de autorisatie meldt... Terwijl de eigenaar van een applicatie het begrip rol doorgaans heeft kunnen implementeren in de applicatie, ziet de eigenaar van objecten op het niveau van het operating system en systeembeheerpakketten (systeembestanden, systeemcommando s, utilities, etc.) zich geconfronteerd met het volgende. Op dit niveau is het begrip rol veelal onbekend en niet zonder meer te implementeren. Als we daarbij bedenken dat het op mainframes niet ongebruikelijk is dat ongeveer tien objecteigenaren de verantwoordelijkheid hebben voor de beveiliging van vijftig- tot honderdduizend objecten, dan is duidelijk dat deze objecteigenaren een probleem hebben! Probleem van de aanvrager De manager van de gebruiker is de klos: deze moet vaak voor vele tientallen applicaties en voor tientallen servers autorisaties aanvragen, en daarnaast ook netwerkbevoegdheden en fysieke autorisaties. Het is dan aantrekkelijk om de uitvoerende organisatie te vragen de nieuwe medewerker van dezelfde autorisaties te voorzien als een bestaande user-id, van een collega die hetzelfde werk uitvoert. Deze manier van klonen is voor het moment wel effectief, maar op de lange duur niet: vaak heeft de bestaande user-id nog autorisaties vanuit een vorige functie, waardoor de nieuwe medewerker al direct met een te ruime set autorisaties begint. Voor medewerkers van de exploitatieafdeling van het rekencentrum (systeemprogrammeurs, database administrators, applicatiebeheerders, operators, etc.) is de situatie voor de autorisatieaanvragers vaak nog lastiger te overzien. In die omgeving hebben de medewerkers veelal zelf een sterk sturende rol bij het aanvragen van de user X User User X autorisaties en periodieke controle op toegang tot belangrijke systeembestanden vindt zelden plaats (het valt ook bijna niet te controleren: een exploitatiemedewerker in een mainframe-omgeving heeft vaak duizenden autorisaties, die toegang geven tot tienduizenden objecten). Probleem in de uitvoering Autorisatieprofiel Senior kredietbehandelaar Autorisatieprofiel Senior kredietbehandelaar Junior kredietbehandelaar... Het is niet ongebruikelijk dat in een grote organisatie (enkele duizenden medewerkers) tien of meer personen betrokken zijn bij het effectueren van de autorisatieaanvragen voor één nieuwe medewerker of één medewerker die van functie verandert. De applicaties en platforms waar autorisaties moeten worden geregeld, hebben immers verschillende beheerders of security administrators. De coördinatie van al deze aanvragen en gereedmeldingen is bij grote organisaties in een aparte functie belegd. Deze medewerker beoordeelt de aanvragen op juistheid en volledigheid en distribueert de aanvragen naar de verschillende uitvoerders. Na terugkoppeling door de uitvoerders meldt de coördinator de aanvraag als gereed terug bij de manager die de aanvraag indiende. Hoe zijn de te ruime autorisaties te verantwoorden tegenover de wet- en/of regelgever en de klanten van de organisatie? Door de betrokkenheid van het grote aantal partijen duurt de succesvolle verwerking van de aanvraag soms wel een week tot enkele weken! Dit geldt vooral voor aanvragen die bij nader inzien toch incompleet waren door het niet vermelden van enkele benodigde autorisaties. Het operationeel beveiligingsbeheer wordt in de uitvoering geconfronteerd met een nieuw probleem: het zijn niet langer alleen de eigen medewerkers die toegang hebben tot de IT-infrastructuur, maar in toenemende mate ook externe partijen, zowel ingehuurd personeel als gebruikers via externe koppelingen. De hiervoor benodigde autorisaties zijn dynamischer dan de autorisaties voor het vaste personeel. Dergelijke autorisaties kunnen uit efficiency- en tijdigheidsoverwegingen niet meer op de traditionele manier worden beheerd. Andere oorzaken van de dynamiek in de beveiliging zijn reorganisaties en fusies, die beide veel frequenter voorkomen dan Applicatie Autorisatie Menukeuzen 1, 3, 4, 7 Schermen 1.A, 1.C,... Commando s P, Q, R Klantgegevens Regio 8 Autorisatielimiet 100K Figuur 1. Voorbeeld van autorisatietabellen in een applicatie.

3 44 vroeger, toen de beveiligingsmodellen werden ontwikkeld. Welke grote organisaties zijn in staat binnen een jaar de gevolgen van een reorganisatie of fusie te verwerken in de regels voor logische toegangsbeveiliging? Wij kennen er geen. En vaak staat binnen een jaar de volgende reorganisatie al weer voor de deur... De oncontroleerbaarheid Of het nu de objecteigenaar is, de manager, de IC-medewerker of de IT-auditor, elke schakel in het beveiligingsproces is bijzonder geholpen met het bestaan van autorisatiematrices waarin de Soll-positie van de autorisaties is vastgelegd. Een simpele vergelijking met de Istpositie levert een uitzonderingsrapportage aan de hand waarvan verbeteringen kunnen worden aangebracht. Autorisatiematrices: soms bestaan ze, vaak zijn ze niet actueel (met name niet volledig), en altijd zijn er verschillen in functie- of rolaanduidingen tussen de diverse autorisatiematrices omdat ze specifiek voor één applicatie tot stand zijn gebracht. Als er al autorisatiematrices bestaan van (applicatiespecifieke) rollen en rechten, dan ontbreekt veelal nog de matrix waarin weergegeven is welke medewerkers welke rol(len) hebben. Hierdoor is een automatische controle op de juistheid van verstrekte autorisaties (de Ist-positie) niet mogelijk. Kortom: de problematiek van het beheer van toegangsbeveiliging Het beheer van toegangsbeveiliging is niet gemakkelijk, en het is dus ook helemaal niet verwonderlijk dat er vaak veel mis mee is. Objecteigenaren, aanvragers, uitvoerders en controleurs: ze ervaren allemaal de beheerproblematiek van toegangsbeveiliging. En een oplossing denken ze soms ook gevonden te hebben: rollen. Maar hebben ze werkelijk de oplossing gevonden? Automatische controle op de juistheid van verstrekte autorisaties (de Ist-positie) is meestal niet mogelijk. In het bovenstaande is enkele keren aangegeven dat hier en daar al met rollen wordt gewerkt: inderdaad is dat een beperkte implementatie van Role Based Access Control. Immers, de rechten in de applicatie zijn gekoppeld aan rollen en op hun beurt zijn deze rollen gekoppeld aan user-id s. Op deze manier wordt bepaald welke userid s welke rechten hebben binnen de applicatie. Het is vanzelfsprekend dat applicaties gebruikmaken van profielen of het begrip rol om rechten aan te koppelen: vijfentwintig jaar geleden al had men door dat dit voor de applicatieontwikkelaar en de administrator veel werk scheelt. Ook op een andere plek wordt vaak al met rollen gewerkt: de slimme manager (of gedelegeerde) die een autorisatieaanvraag moet opstellen, heeft doorgaans wel een document of spreadsheet met daarin een opsomming van de benodigde autorisaties voor een bepaald type medewerker (rol) in het team. Omdat het concept van een rol zo vanzelfsprekend is, wordt het eigenlijk overal wel gebruikt, meer of minder bewust, echter zonder de voordelen van het concept ten volle te benutten. Feit is namelijk dat bij audits de volgende bevindingen steevast naar voren komen: te ruime autorisaties; uiteenlopende autorisatieprocessen; onduidelijkheid over aan te vragen en te verstrekken autorisaties; onvoldoende beheersbaarheid (waaronder controleerbaarheid) vanwege: geen volledige vastlegging Soll-situatie rollen versus rechten; geen vastlegging Soll-situatie medewerkers versus rollen; geen adequaat overzicht Ist-situatie. Kennelijk is het zo dat de huidige toepassing van het rolconcept onvoldoende bijdraagt tot een goed beheerste beveiliging. Hoe kan dat? Enkele van de oorzaken daarvoor zijn hierboven weergegeven. Aanvullend kunnen de volgende punten worden onderkend als oorzaken: Er bestaat onvoldoende uniformiteit in rolaanduidingen: per applicatie bestaat een unieke set rollen. Het toepassingsgebied van de rolaanduidingen is te beperkt: bijvoorbeeld alleen binnen of vlak rond de applicatie; HRM (Human Resource Management) hanteert weer andere functie/rolaanduidingen. De diverse autorisatiematrices zijn op vele plaatsen vastgelegd: indien er n verschillende autorisatiematrices zijn, dan zijn er >n vastleggingen. Op het niveau van het operating system (OS/390, Unix, NT, OS/400) bestaat het concept van een rol niet of zeer beperkt. Door de wijze waarop de autorisatiematrices zijn vastgelegd (als ze al bestaan), is het veelal niet haalbaar om een automatische confrontatie met de Ist-situatie uit te voeren, laat staan dat het mogelijk is om de Ist-situatie automatisch (bij) te sturen op basis van de autorisatiematrices. Organisatie en implementatie van de beveiliging volgens de methode van Role Based Access Control lost afhankelijk van de reikwijdte en diepgang van de implementatie de genoemde problemen voor een belangrijk deel op. Als aanloop naar RBAC worden onderstaand de verschillende in de praktijk gehanteerde autorisatiemodellen belicht. Autorisatiemodellen Autorisatiemodel-0 In dit model is een gebruiker (geïdentificeerd door een user-id) rechtstreeks geautoriseerd voor toegang tot een object, meestal via de Access Control List (ACL) van het object. Op de ACL van het object is dan gespecificeerd welke toegang (bijvoorbeeld lezen, schrijven, uitvoeren, verwijderen) de user-id heeft tot het object. Het object kan een bestand zijn, commando, utility, directory, een applicatie, maar ook een autorisatieprofiel of transactie binnen een applicatie of een scherm binnen een systeembeheertool.

4 De (on)beheersbaarheid van toegangsbeveiliging 45 Opmerking: De lijn met kraaienpoten representeert een n:m (veel-op-veel) relatie tussen de entiteiten. In dit geval betekent het dat een gebruiker aan meer dan één object kan zijn gekoppeld, en dat anderzijds een object aan meer dan één gebruiker kan zijn gekoppeld. In figuur 3 is in een voorbeeld een tiental van de honderden tot duizenden autorisaties weergegeven die een gebruiker user X heeft. Dit model bestaat op vrijwel elk platform (OS/390, Unix, NT, OS/400), en wordt ook wel gehanteerd in applicaties en systeembeheertools. Een voordeel van dit model is de eenvoud waarmee een enkele autorisatie kan worden toegekend aan de gebruiker. Een groot nadeel is dat het onderhoud veel inspanning kost: elke nieuwe medewerker moet steeds aan alle benodigde objecten worden gekoppeld dat zou in theorie duizenden commando s kunnen vergen. Als de medewerker een andere functie krijgt, moeten de verbindingen met de niet meer benodigde objecten stuk voor stuk worden verbroken. Autorisatiemodel-1 (groepen) In dit model is een gebruiker geautoriseerd voor toegang tot een object via een autorisatiegroep. Dit houdt in dat de group-id, als identificerend kenmerk van de autorisatiegroep, op de ACL van het object staat, en dat de gebruiker lid is van (gekoppeld is aan) de groep. Dit model bestaat op de meeste platforms, en wordt vaak toegepast in applicaties voor het groeperen van bevoegdheden. De voordelen van autorisatiemodel-1 in vergelijking met autorisatiemodel-0 worden in het algemeen onderkend, hetgeen de reden is dat autorisatiemodel-1 vandaag de dag het meest toegepaste model is. De autorisatiegroep in dit model kan worden opgevat als een groepering van gebruikers, maar ook als een groepering van autorisaties. Beide zienswijzen zijn correct, en in de praktijk zijn dit de twee benaderingen bij het ontwerpen van groepen: Rolgebaseerde autorisatiegroepen (figuur 5). s zijn gekoppeld aan een groep (of groepen) die de rol(len) representeert die de gebruikers hebben binnen de organisatie. Deze benadering leidt gewoonlijk tot een situatie waarbij de gebruiker gekoppeld is aan een beperkt aantal autorisatiegroepen, en de autorisatiegroepen op de ACL s van vele objecten staan. Kenmerkend is ook dat op de ACL s vele autorisatiegroepen staan. In een poging de lengte van de ACL (het aantal group-id s op de ACL) te beperken worden ook wel basis autorisatiegroepen gecreëerd. Dit zijn groepen die de gemeenschappelijk benodigde autorisaties realiseren voor bijvoorbeeld: rollen binnen een afdeling; medewerkers op een bepaalde locatie; vaste medewerkers (versus ingehuurd personeel). Taakgebaseerde autorisatiegroepen (figuur 6). s zijn gekoppeld aan groepen die taken representeren die de gebruikers moeten kunnen uitvoeren vanwege hun user X Applicatie A Applicatie B Applicatie C Applicatieautorisatieprofieautorisatie- AA Applicatieprofiel BA Directory m lezen directory m schrijven Utility P Utility Q Utility R Figuur 3. Voorbeeld van autorisaties volgens autorisatiemodel-0. Autorisatiegroep rol(len) binnen de organisatie. Deze benadering leidt tot een situatie waarbij de gebruiker gekoppeld is aan veel autorisatiegroepen, en de autorisatiegroepen op de ACL s van een beperkt aantal objecten staan. Op de ACL s staat slechts een gering aantal autorisatiegroepen. De figuren 5 en 6 geven voorbeelden van de beide benaderingen. Het is van belang om te bedenken dat deze voorbeelden simplificaties van de werkelijkheid zijn. De pijlen onderaan in de figuren geven aan waar de realiteit uitgebreider is. user X user Y user Z Basisgroep Kredietbehandelaren Rolgroep Senior kredietbehandelaar Rolgroep Junior kredietbehandelaar Rolgebaseerde autorisatiegroepen Object Access list (ACL) Figuur 2. Autorisatiemodel-0. Object Figuur 4. Autorisatiemodel-1. Figuur 5. Relaties tussen gebruikers, rolgebaseerde autorisatiegroepen en objecten. Applicatie A Applicatie B Applicatie C Applicatieautorisatieprofieautorisatie- AA Applicatieprofiel BA Directory m lezen directory m schrijven Utility P Utility Q Utility R...andere objecten Objecten

5 46 user X user Y user Z Figuur 6. Relaties tussen gebruikers, taakgebaseerde autorisatiegroepen en objecten. Invoeren kredietaanvraag Invoeren kredietadvies Raadplegen kredietaanvraag Raadplegen kredietadvies... andere taken Taakgebaseerde autorisatiegroepen Applicatie A Applicatie B Applicatie C Invoeren kredietbesluit Applicatieautorisatieprofieautorisatie- AA Applicatieprofiel BA Directory m lezen directory m schrijven Utility P Utility Q Utility R... andere objecten Objecten De noodzaak voor een platform- en applicatieoverstijgende en (re)organisatieonafhankelijke invulling van het begrip rol begint zich af te tekenen... Autorisatiemodel-2 (RBAC) In dit model is een gebruiker geautoriseerd voor toegang tot een object via een rol en een autorisatiegroep. Dit houdt in dat net als in autorisatiemodel-1 de group-id van de autorisatiegroep op de ACL van het object staat. Aan de andere kant is de autorisatiegroep nu gerelateerd aan één of meer rollen, en is een gebruiker gerelateerd aan één of meer rollen. Dit is het basis-rbac-model: gebruikers zijn niet langer rechtstreeks gekoppeld aan autorisatiegroepen. In plaats daarvan komt de relatie tot stand via roldefinities. Op hun beurt zijn de rollen gekoppeld aan taakgebaseerde autorisatiegroepen. In de regel wordt dit model niet ondersteund op platformniveau, zodat het begrip rol alleen kan bestaan als administratieve entiteit binnen de grenzen van een RBAC-tool. Opmerking: In het formele RBAC-model wordt niet over autorisatiegroepen gesproken, maar over permissies. Het model is namelijk niet beperkt tot systemen die het begrip (autorisatie)groep kennen: het kan worden toegepast in elk systeem dat al dan niet gegroepeerde rechten/privileges/permissies/autorisaties kent. In dit artikel wordt echter voor de eenvoud het concrete begrip autorisatiegroep gehanteerd. Rol Autorisatiebeheer Autorisatiegroep sbeheer Rolbeheer Objectautorisatiebeheer Figuur 7. Autorisatiemodel-2. Object Autorisatiebeheerders die claimen reeds een RBACimplementatie te hebben refererend aan de rolgebaseerde autorisatiegroepen hebben niet helemaal ongelijk: autorisatiemodel-1 in combinatie met rolgebaseerde autorisatiegroepen is feitelijk een rudimentaire RBACimplementatie: de gehanteerde rolbenamingen beperken zich echter tot een specifiek platform of een specifieke applicatie. In het geval dat ook op andere platforms of in andere applicaties rolgebaseerde autorisatiegroepen worden gehanteerd, worden daar bijna altijd andere namen of een andere detaillering van rollen gebruikt. Bovendien blijken de gedefinieerde rolgebaseerde autorisatiegroepen vaak bij nadere beschouwing feitelijk afdeling- of teamgebaseerde autorisatiegroepen te zijn: dit is dodelijk voor de vlotte aanpassing van autorisaties bij reorganisaties! Afdelingen en teams veranderen, rollen vrijwel niet. Daarnaast is het koppelen van een gebruiker aan een rolgebaseerde autorisatiegroep een technische handeling in een technische omgeving, terwijl het verstrekken van een autorisatie gedreven wordt vanuit de business. Een gebruiker dient niet te worden gekoppeld aan technische dingen, maar aan iets wat kan worden herkend (en gecontroleerd!) vanuit de business: een rol. Autorisatiemodel-2 (RBAC) versus autorisatiemodel-1 In tabel 1 wordt de meest effectieve RBAC-implementatie vergeleken met de meest effectieve niet-rbac-implementatie: autorisatiemodel-2 (RBAC) met taakgebaseerde autorisatiegroepen, en autorisatiemodel-1 met rolgebaseerde autorisatiegroepen, het model dat vandaag de dag vaak wordt gehanteerd. Uit de in tabel 1 gegeven vergelijking van de beide modellen blijkt dat autorisatiemodel-2 (RBAC) op alle fronten leidt tot een betere beheersing van de beveiliging. Voorbeeld: controleerbaarheid Waarom is het controleren van beveiliging op basis van autorisatiemodel-1 inefficiënt en kan het zelfs ineffectief blijken te zijn? Een simpel voorbeeld verduidelijkt dit. Stel, op basis van een risicoanalyse rond de beheersing van kredietaanvragen is de auditor geïnteresseerd in de beveiliging van een twintigtal objecten die te maken hebben met het raadplegen van een kredietaanvraag. Als eerste vraagt de auditor een overzicht van de twintig ACL s. Laten we aannemen dat vijf rollen toegang hebben tot de twintig objecten om een kredietaanvraag te kunnen raadplegen.

6 De (on)beheersbaarheid van toegangsbeveiliging 47 Aspect Objectautorisatiebeheer Rolbeheer sbeheer Functiescheiding Autorisatiemodel-2 (RBAC) met taakgebaseerde groepen (figuur 7) Omdat de groepen taakgerelateerd zijn, is de objecteigenaar goed in staat de juistheid van de toegang tot het object te beoordelen. De betekenis van de taakgroep wordt namelijk inzichtelijk gemaakt door een functionele beschrijving (attribuut van de taakgebaseerde groep). Taakgebaseerde groepen worden gekoppeld aan rollen. Deze koppelingen kunnen worden vastgesteld door een manager/teamleider (die de betekenis van de rol goed kent) in samenspraak met een beveiligingsbeheerder (als gedelegeerde van de verschillende objecteigenaren). Hierbij gebruiken zij de hierboven aangehaalde functionele beschrijving van de taakgebaseerde groepen. Een gebruiker is gerelateerd aan een rol. Het begrip rol sluit uitstekend aan bij organisatorische begrippen als functie en taak(omschrijving), zodat het koppelen van een gebruiker (user-id) aan een rol goed kan worden overgelaten aan een HRMmedewerker, die immers up-to-date informatie heeft over de rol (!) van de betrokken medewerker in de organisatie. De functiescheiding in het beveiligingsbeheer is optimaal, omdat het voor de hand ligt om: gebruikersbeheer, rolbeheer en objectautorisatiebeheer door verschillende medewerkers uit te laten voeren. In een geavanceerde RBAC-implementatie kan ook worden bepaald welke rollen (in de gebruikersorganisatie) uit het oogpunt van functiescheiding niet aan één gebruiker mogen worden toegekend. Autorisatiemodel-1 met rolgebaseerde groepen (figuur 5) De objecteigenaar moet kennis hebben van alle rollen die toegang vragen tot het object, hetgeen vrijwel niet mogelijk is op een betrouwbare en efficiënte manier. Rolbeheer maakt in feite deel uit van het objectautorisatiebeheer. Een gebruiker is gerelateerd aan één of meer rolgebaseerde autorisatiegroepen. Normaliter voert een security administrator deze technische taak uit, of in een ongunstig geval een systeembeheerder. Over het algemeen verre van optimaal, waarbij alle beveiligingsbeheertaken door de security administrator of de systeembeheerder worden uitgevoerd. Het aan één gebruiker toekennen van rolgebaseerde autorisatiegroepen die uit het oogpunt van functiescheiding onverenigbaar zijn, kan in de regel niet automatisch worden verhinderd. Beheersbaarheid Controleerbaarheid Multi-platform ondersteuning Afdwingen beveiligingsbeleid Omdat autorisaties worden bepaald door relaties tussen de entiteiten gebruiker - rol en rol - autorisatiegroep, is er een maximum aan transparantie en een minimum aan complexiteit. Als een medewerker een andere rol krijgt, worden de oude autorisaties op een eenvoudige manier automatisch verwijderd door het RBAC-tool. Dankzij het transparante inzicht in de relaties gebruiker - rol en rol - autorisatiegroep is de controle van beveiliging op basis van RBAC relatief eenvoudig. Het concept van een rol bestaat als entiteit binnen de grenzen van een RBAC-tool, en betreft autorisaties op alle platforms binnen het werkingsgebied van het RBAC-tool. Integriteit (uniformiteit) van rolnamen is gegarandeerd. Een RBAC-tool kan eenvoudig afdwingen dat niemand méér autorisaties heeft dan de autorisaties die gerelateerd zijn aan de rol die men heeft. Het grote aantal rolgebaseerde groepen op de ACL s bemoeilijkt het verkrijgen van een overzicht. Bij het wijzigen van rollen is speciale aandacht nodig voor het (handmatig) verwijderen van oude autorisaties. De controle van autorisaties volgens dit model is in het algemeen inefficiënt of (daardoor) zelfs mogelijk ineffectief (zie voorbeeld in de volgende subparagraaf). Vanwege het grote aantal rolgebaseerde groepen op de ACL kan het voor een objecteigenaar/ auditor moeilijk zijn om de juistheid van de autorisaties te beoordelen. Vanwege het grote aantal ACL s waar de rolgebaseerde groep op is geplaatst, en het technische detailniveau van de betrokken objecten, is het voor een manager/auditor praktisch onmogelijk de juistheid van de autorisaties van de medewerkers te beoordelen. Op de verschillende platforms vindt men in de regel verschillende afzonderlijke implementaties van dit model. Integriteit van rolnamen is niet gegarandeerd, hetgeen de efficiëntie en effectiviteit van het multi-platform beveiligingsbeheer vermindert. Zonder solide procedures kunnen tools die dit model implementeren niet voorkomen dat gebruikers aanvullende autorisaties verkrijgen. Tabel 1. Vergelijking RBAC met niet-rbac.

7 48 Figuur 8. Auditautorisaties voor de taak Raadplegen kredietaanvraag (autorisatiemodel-1). Figuur 9. Auditautorisaties voor de taak Raadplegen kredietaanvraag (autorisatiemodel-2, RBAC). Figuur 10. Mapping van entiteiten tussen het RBAC-tool en de doelomgeving. sbeheer Rol In figuur 8 is de beveiliging ingericht volgens autorisatiemodel-1 met rolgebaseerde autorisatiegroepen. De auditor moet zich een oordeel vormen over de juistheid van de aanwezigheid van de vijf rolgebaseerde autorisatiegroepen op elk van de twintig ACL s. Dit betekent dat honderd ACL-regels (ofwel relaties tussen autorisatiegroepen en objecten) moeten worden beoordeeld. Rol In het geval dat autorisatiemodel-2 wordt gebruikt (met taakgebaseerde autorisatiegroepen), zouden alle twintig autorisaties die nodig zijn voor het uitvoeren van de taak Raadplegen kredietaanvraag gecombineerd zijn in één taakgebaseerde autorisatiegroep, zoals in figuur 9 weergegeven. In deze situatie zou de auditor slechts vijfentwintig relaties hoeven te beoordelen: de toegang die de autorisatiegroep Raadplegen kredietaanvraag heeft tot de twintig objecten, en de relaties van deze groep tot de vijf rollen. Rolgebaseerde autorisatiegroep Rol Dit sterk vereenvoudigde voorbeeld geeft de problematiek aan van de controle van autorisatiemodel-1 (met rolgebaseerde groepen) en illustreert dat het auditen (en dus ook het beheer!) van autorisatiemodel-2 (RBAC) belangrijk eenvoudiger is vergeleken met de andere modellen. Het feit dat controle van autorisatiemodel-1 qua omvang snel uit de hand kan lopen vormt ook een reële bedreiging voor de effectiviteit van de controle. Concrete RBAC-implementatie Kwestie van beperken Raadplegen kredietaanvraag 5 20 Object Bij een inventarisatie van RBAC-initiatieven en een verkenning van de markt van RBAC-producten is de kans groot ondergesneeuwd te raken door termen als identity management, provisioning, single signon (SSO), directo- Rol Rolbeheer 5 1 Taakgebaseerde 1 20 Object autorisatiegroep Objectautorisatiebeheer RBAC-tool Doelomgeving Autorisatiegroep ries, Public Key Infrastructure (PKI), Privilege Management Infrastructure (PMI), Security Assertion Markup Language (SAML), Enterprise Access Management (EAM), etc. Deze veelheid aan concepten kan de RBACsponsor in de organisatie de moed in de schoenen doen zinken. Menig leverancier denkt zoveel mogelijk features en gerelateerde pakketten te moeten noemen in de brochures en white papers, omdat het product het anders mogelijk zal afleggen tegen de andere producten met nog meer features en interfaces. Wat voor elk ander project geldt is ook waar voor een RBAC-implementatie: houd het simpel en beperkt. Een eenvoudige RBAC-implementatie, zelfs al is het een papieren implementatie, is vaak voorwaarde voor of gaat samen met de bovengenoemde concepten. Niet voor niets blijven RBAC-initiatieven veelal steken op de ontwerptafel: de ambities zijn te groot en men wil in één keer tachtig procent, liever nog negentig procent onder RBAC brengen. Het is echter goed mogelijk dat bij specifieke RBAC-implementaties de 80/20-regel opgaat: tachtig procent ROI (Return On Investment) met slechts twintig procent van de oplossing. Mapping van entiteiten Bij de implementatie van RBAC is het van belang onderscheid te maken tussen entiteiten binnen het RBAC-tool en entiteiten in de doelomgevingen (platforms, applicaties, etc.). Zoals eerder aangegeven bestaat de entiteit rol slechts binnen het RBAC-tool zelf. Anderzijds zal het objectautorisatiebeheer veelal buiten het RBAC-tool plaatsvinden: het plaatsen van een groep op de ACL van een Unix-file, het zetten van een RACF PERMIT op een OS/390-dataset, het koppelen van een transactie in een financiële applicatie aan een autorisatieprofiel, etc. Figuur 10 geeft een beeld van de begrippen in praktische RBAC-implementaties. Terwijl de entiteit rol slechts binnen het RBAC-tool bestaat, hebben de entiteiten en Autorisatiegroep een tegenhanger in de doelomgeving: de gebruiker wordt geprojecteerd (gemapt) op een user profile of account, terwijl de autorisatiegroep een representant heeft in de vorm van bijvoorbeeld een RACF-, Unix- of NT-group. sbeheer en rolbeheer vinden dus plaats binnen het RBAC-tool. Vanuit dit tool kunnen (half)automatisch de wijzigingen in de (relaties tussen) user profiles en groups in de doelomgevingen worden doorgevoerd (= provisioning). Objectautorisatiebeheer wordt veelal buiten het RBAC-tool gehouden en in de doelomgeving uitgevoerd, als vanouds. RBAC-tools User profile Group Object Het bieden van een compleet marktoverzicht van RBACtools valt buiten het bestek van dit artikel. Als altijd is de pakkettenmarkt in beweging, en zal een organisatie zelf tot een keuze moeten komen op basis van een zorgvuldig samengesteld pakket van eisen en wensen, en de actuele marktsituatie. Niettemin kunnen, zonder een volledig overzicht te geven, enkele namen worden genoemd

8 De (on)beheersbaarheid van toegangsbeveiliging 49 van bekende producten op dit terrein. Het zijn producten die autorisatiebeheer (op basis van RBAC) op de meest populaire platforms ondersteunen, zoals Windows 2000, HP-UX, AIX, OS/390, en in toenemende mate ook in systemen als Lotus Notes en SAP: AccessMaster (Evidian); AxcessIT (SafeStone); bhold suite (bhold company); Control-SA (BMC); DirXmetaRole (Siemens); etrust Admin (Computer Associates); IBM Tivoli Identity Manager (IBM). Methode Eén van de grootste uitdagingen bij de implementatie van RBAC is het definiëren van de rollen en per rol de benodigde autorisaties. Indien de autorisaties zijn gegroepeerd in rolgebaseerde autorisatiegroepen, dienen deze te worden omgevormd tot taakgebaseerde autorisatiegroepen. Onderstaand worden de methoden belicht om te komen van een situatie waarin autorisatiemodel- 1 wordt gebruikt met voornamelijk rolgebaseerde autorisatiegroepen tot een situatie met autorisatiemodel-2 met voornamelijk taakgebaseerde autorisatiegroepen. Onderscheid kan worden gemaakt tussen twee methoden voor het ontwerpen van rollen: top-down- of groene-weidemethode. Hierbij wordt uitgegaan van de organisatiestructuur, beveiligingsbeleid, functiebeschrijvingen en procesbeschrijvingen om te komen tot een acceptabel detailniveau van roldefinities; een tweede bijzonder lastige stap is het bepalen van de autorisaties die nodig zijn voor de aldus totstandgekomen rollen. bottom-up- of role mining -methode. Hierbij wordt uitgegaan van bestaande autorisaties en aan de hand van interviews met managers vastgesteld welke rollen binnen een afdeling of team bestaan. Een hybride aanpak is ook goed mogelijk: een combinatie van de top-down en bottom-up methoden, waarbij bijvoorbeeld een aantal rollen volgens de ene methode wordt ontwikkeld en een aantal andere volgens de andere metho- de, en/of rollen initieel worden bepaald volgens de bottom-up methode en vervolgens worden aangepast op basis van inzichten die volgen uit de top-down methode. Bij de RBAC-implementaties die KPMG IRM tot nu toe heeft begeleid onder andere bij Belastingdienst/Centrum voor ICT (B/CICT) is steeds bewust gekozen voor de bottom-up methode: zij levert relatief snel resultaat en bij het bepalen van de benodigde autorisaties voor de rollen kan gebruik worden gemaakt van geautomatiseerde hulpmiddelen. Een belangrijke overweging is ook dat het vaak jaren heeft gekost om tot een zodanige set autorisaties te komen dat alles goed functioneert: door geen kennis te nemen van de bestaande autorisaties, met andere woorden door de Ist-situatie te negeren, duurt een RBAC-traject veel langer dan nodig, of worden onnodige beschikbaarheidsrisico s gelopen (omdat bepaalde, toch benodigde autorisaties over het hoofd zijn gezien). KPMG IRM gebruikt MS-Access om inzicht te krijgen in de actuele autorisaties van gebruikers. Na het in Access importeren van gegevens over gebruikers, (rolgebaseerde) autorisatiegroepen en ACL s van de objecten is het mogelijk op een efficiënte manier inzicht te krijgen in de bestaande relaties tussen deze entiteiten. Met behulp van Access worden relaties gevisualiseerd, waardoor het eenvoudig is om patronen vast te stellen in: relaties tussen gebruikers en de in interviews benoemde rollen; taakgerelateerde autorisaties, die worden samengebracht in nieuwe taakgebaseerde autorisatiegroepen. Bij RBAC-implementaties levert de bottom-up methode relatief snel resultaat. Op basis van dit inzicht wordt de bestaande situatie volgens autorisatiemodel-1 omgevormd tot een situatie volgens autorisatiemodel-2. Gegevens over de nieuwe situatie worden ingevoerd in het RBAC-tool, waarna het betreffende deel van de organisatie of van de IT-infrastructuur onder besturing van het RBAC-tool wordt gebracht. Procedurele inbedding Bij het implementeren van het RBAC-beveiligingsmodel dient bovenal ook aandacht te worden geschonken aan de procedurele inbedding van het onderhoud aan entiteiten en relaties. Ten minste de volgende taken dienen te worden belegd: Beheer RBAC-tool: opvoeren, autoriseren en afvoeren van RBAC-gebruikers (zijnde gebruikersbeheerders, rolbeheerders, objectautorisatiebeheerders, auditors, etc.). sbeheer: opvoeren/afvoeren van gebruikers en het koppelen van gebruikers aan rollen. Deze taak kan worden gedecentraliseerd, zodat men gebruikersbeheerder is voor een deel van de gebruikers en/of een deel van de rollen. De bevoegdheden van een decentrale beheerder worden ingesteld door de beheerder van het RBAC-tool. Rolbeheer: opvoeren/afvoeren van rollen, het vastleggen van een functionele beschrijving van de rol en het koppelen van rollen aan autorisatiegroepen. Deze taak kan worden gedecentraliseerd, zodat men rolbeheerder is voor een deel van de rollen en/of een deel van de autorisatiegroepen. De bevoegdheden van een decentrale beheerder worden ingesteld door de beheerder van het RBAC-tool. Objectautorisatiebeheer: In het RBAC-tool: opvoeren/afvoeren van autorisatiegroepen en het vastleggen van een functionele beschrijving van de autorisatiegroep. In de doelomgeving: opvoeren/afvoeren van groups en het koppelen van groups aan objecten. Deze taak kan worden gedecentraliseerd, zodat men objectautorisatiebeheerder is voor een deel van de objecten en/of autorisatiegroepen. De bevoegdheden van een decentrale beheerder worden enerzijds ingesteld door de beheerder

9 50 Ing. P. Mienes RE is senior IT-consultant/ auditor bij KPMG Information Risk Management en is intensief betrokken bij de logische toegangsbeveiliging en het systeembeheer in grote organisaties. Voor KPMG participeert hij onder andere in het Role Based Access Controlproject van EEMA. B. Bokhorst RE RA is werkzaam als security manager bij de Belastingdienst/Centrum voor ICT. Daarnaast is hij als bestuurslid van het Platform Informatiebeveiliging belast met de begeleiding van werkgroepen op het gebied van beveiligingsnormering. Een korte versie van dit artikel zal worden gepubliceerd in het periodiek Informatiebeveiliging van het GVIB, nummers en Gebeurtenis a. Medewerker in dienst V b. Medewerker uit dienst V c. Medewerker krijgt (andere) rol V d. In organisatie ontstaat nieuwe rol V e. Nieuwe functionaliteit toegevoegd aan bestaande (taakgebaseerde) autorisatiegroep I f1. Nieuwe autorisatiegroep opgericht voor nieuwe functionaliteit f2. Nieuwe taakgroep beschikbaar gesteld aan rol of meerdere rollen V van het RBAC-tool, en zijn voor een ander deel afhankelijk van toegekende autorisaties in het doelsysteem. In tabel 2 is voor een aantal administratiegerelateerde gebeurtenissen aangegeven wie hiervoor verantwoordelijk zijn (V), een adviserende functie hebben (A), of geïnformeerd (I) dienen te worden. De in de tabel genoemde gebeurtenissen hebben naast wijzigingen binnen het RBAC-tool ook wijzigingen tot gevolg in de doelomgeving: a. In de doelomgeving wordt een user profile aangemaakt. b. In de doelomgeving wordt de user profile geblokkeerd, dan wel de user profile wordt verwijderd en de relaties tussen de user profile en de groups worden verbroken. c. In de doelomgeving worden relaties gelegd tussen de user profile en de groups; bij een rolwijziging worden nieuwe relaties gelegd, en de oude relaties met groups worden verbroken voorzover deze niet overlappen met de relaties die nodig zijn voor de nieuwe rol. d. Het begrip rol bestaat alleen binnen het RBAC-tool, dus deze gebeurtenis heeft geen gevolgen voor de doelomgeving. e. De bestaande group in de doelomgeving wordt op de ACL van (nieuwe) objecten geplaatst. f1.een nieuwe group wordt opgericht in de doelomgeving en op de ACL van (nieuwe) objecten geplaatst. f2.in de doelomgeving worden relaties gelegd tussen de nieuwe group en alle user profiles die gekoppeld zijn aan de betrokken rol(len). Bij toepassing van een volwaardig RBAC-tool kunnen de wijzigingen a, b, c, d en f2 (half)automatisch worden doorgevoerd in de doelomgeving. De wijzigingen e en f1 worden in de regel buiten het RBAC-tool om (handmatig) in de doelomgeving uitgevoerd. Praktijkervaringen Betrokkenheid V Verantwoordelijk Rolbeheer A Adviserend I Het NIST (National Institute of Standards & Technology) voert reeds tien jaar onderzoek uit naar RBAC, en komt daarbij tot conclusies die gezien mogen worden. Uit een onderzoek door het NIST bij een verzekeringsmaatschappij kwam naar voren dat tegenover de eenmalige kosten van $78 per medewerker voor de invoe- sbeheer Objectautorisatiebeheer A V V A Geïnformeerd ring van RBAC $43 per medewerker aan jaarlijkse besparingen staat. De besparingen worden vooral gevonden in de sterk vereenvoudigde administratie van de beveiliging en in afname van improductiviteit als gevolg van het niet tijdig of niet goed realiseren van de benodigde autorisaties. Frans Calor, projectleider Security Management bij B/CICT: De belangrijkste voordelen van RBAC die direct na de invoering zichtbaar waren, zijn enerzijds de sterke vereenvoudiging voor de teamleiders die autorisaties aanvragen, en anderzijds de verbeterde controleerbaarheid, onder meer doordat nu een automatische Soll/Ist-controle mogelijk is. Inmiddels zijn OS/390-autorisaties, fysieke rechten en hoge rechten op NT en Novell onder het RBAC-regime gebracht, en zijn we bezig om de doelgroep uit te breiden van vierhonderd naar vierduizend medewerkers. Theo Krens begeleidde vanuit KPMG IRM de implementatie bij een andere organisatie, en memoreert: Het belangrijkste probleem dat RBAC bij deze klant heeft opgelost is de beheersbaarheid van de logische toegangsbeveiliging op VME, Unix en NT. Door de invoering van RBAC is behalve de operationele beheersbaarheid ook de controleerbaarheid sterk verbeterd, en er is transparantie ontstaan in de beveiligingsregels. RBAC was ook een stimulans om de procedures rond logische toegangsbeveiliging te vervolmaken. Conclusie Tabel 2. Verdeling van verantwoordelijkheden. Met een eenvoudig rekenschema kan elke organisatie een betrouwbaar beeld schetsen van de kwantitatieve voordelen van de invoering van RBAC. Daarnaast kunnen ook kwalitatieve aspecten een belangrijke rol spelen bij de beslissing om tot (gedeeltelijke) invoering van RBAC over te gaan. Zelfs een qua scope en tooling beperkte RBAC-implementatie kan reeds significante voordelen bieden voor de administratie en controle van de beveiliging.

Studie Role Based Access Control

Studie Role Based Access Control Platform Informatiebeveiliging Studie Role Based Access Control Versie 1.0 November 2005 PI RBAC versie 1.0 doc Inhoudsopgave Managementsamenvatting 3 1. Inleiding 5 2. Autorisatiebeheer en RBAC 6 2.1

Nadere informatie

De (harde) praktijk van role engineering

De (harde) praktijk van role engineering Compact 2005/3 De (harde) praktijk van role engineering Ing. P. Mienes RE Bij het implementeren van autorisatiebeheer op basis van het RBAC-model worden role engineering en role mining vaak door elkaar

Nadere informatie

Identity Management Gebruikers en Rechten in Beheer (GRiB)

Identity Management Gebruikers en Rechten in Beheer (GRiB) Identity Management Gebruikers en Rechten in Beheer (GRiB) Meer grip op hoe we regelen wie wat mag P.J.M. Poos (Piet) Programma manager SNS REAAL organisatie Raad van Bestuur Groepsstaven SNS Bank REAAL

Nadere informatie

Beveiligingsbeleid Stichting Kennisnet

Beveiligingsbeleid Stichting Kennisnet Beveiligingsbeleid Stichting Kennisnet AAN VAN Jerry van de Leur (Security Officer) DATUM ONDERWERP Disclaimer: Kennisnet geeft geen enkele garantie, met betrekking tot de geschiktheid voor een specifiek

Nadere informatie

AGDLP. ~ maar waarom eigenlijk?

AGDLP. ~ maar waarom eigenlijk? AGDLP ~ maar waarom eigenlijk? Edward Willemsen, [em'bed], 2011 Algemeen Wie ooit beheer heeft gedaan binnen een Microsoft omgeving is bekend met de diverse typen groepen. In de loop der jaren zijn hier

Nadere informatie

Zekerheid in de Cloud. ICT Accountancy praktijk dag: Cloud computing 27 mei 2014

Zekerheid in de Cloud. ICT Accountancy praktijk dag: Cloud computing 27 mei 2014 Zekerheid in de Cloud ICT Accountancy praktijk dag: Cloud computing 27 mei 2014 Agenda - Wat speelt zich af in de Cloud - Cases - Keurmerk Zeker-OnLine - Wat is het belang van de accountant en het administratiekantoor

Nadere informatie

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van e-mail

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van e-mail Beknopte dienstbeschrijving Beveiligen van e-mail m.b.v. digitale certificaten en PKI Document: Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van e-mail Inhoudsopgave 1. Inleiding 2 2. Snel te

Nadere informatie

Op naar IAM 3.0 ISACA round table. drs. André Koot RE CISA CISM 3 juni 2015

Op naar IAM 3.0 ISACA round table. drs. André Koot RE CISA CISM 3 juni 2015 Op naar IAM 3.0 ISACA round table drs. André Koot RE CISA CISM 3 juni 2015 Wie ben ik Wat is I A M Ontwikkeling IAM - RBAC, Federatie - ABAC, mobile Project Mijn identiteit Specialist Informatiebeveiliging

Nadere informatie

Identity Management. Risico s en kansen binnen het kader van de jaarrekeningcontrole. Drs. J. Visser 1667521 Drs. M.P. Hof 1662058

Identity Management. Risico s en kansen binnen het kader van de jaarrekeningcontrole. Drs. J. Visser 1667521 Drs. M.P. Hof 1662058 Identity Management Risico s en kansen binnen het kader van de jaarrekeningcontrole Drs. J. Visser 1667521 Drs. M.P. Hof 1662058 Amsterdam 31 maart 2008 Versie 1.0 [definitief] Afstudeerbegeleiders: Rudi

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden

Nadere informatie

info@zeker-online.nl www.zeker-online.nl Drs L. (Bert) F.G. Tuinsma RA, voorzitter 10 december 2013

info@zeker-online.nl www.zeker-online.nl Drs L. (Bert) F.G. Tuinsma RA, voorzitter 10 december 2013 info@zeker-online.nl www.zeker-online.nl Drs L. (Bert) F.G. Tuinsma RA, voorzitter 10 december 2013 2 Boekhouden in de cloud!! 3 Aanbod te over: 4 5 Hoe betrouwbaar en veilig is online administratieve

Nadere informatie

Auditaspecten binnen autorisaties in SAP R/3

Auditaspecten binnen autorisaties in SAP R/3 Auditaspecten binnen autorisaties in SAP R/3 Vrije Universiteit Amsterdam Postgraduate IT Audit Opleiding Eindscriptie, mei 2007 Ewald Franse Voorwoord Deze scriptie is de afsluiting van de Postgraduate

Nadere informatie

Martiris 2011. Secure Private Data. Gegevensbescherming in Oracle Databases

Martiris 2011. Secure Private Data. Gegevensbescherming in Oracle Databases Martiris 2011 Secure Private Data Gegevensbescherming in Oracle Databases Inhoudsopgave INTRODUCTIE... 3 HISTORIE... 4 SECURE PRIVATE DATA: FUNCTIONEEL... 4 A) ROW LEVEL SECURITY... 4 B) COLUMN MASKING...

Nadere informatie

Secure Application Roles

Secure Application Roles Secure Application Roles Beheer de toegang tot de database 1. Inleiding Het realiseren van geautoriseerde toegang tot een database lijkt eenvoudig. Echter, vaak blijkt dat dezelfde combinatie van gebruikersnaam

Nadere informatie

SOA Security. en de rol van de auditor... ISACA Roundtable 2 juni 2008. Arthur Donkers, 1Secure BV arthur@1secure.nl

SOA Security. en de rol van de auditor... ISACA Roundtable 2 juni 2008. Arthur Donkers, 1Secure BV arthur@1secure.nl SOA Security en de rol van de auditor... ISACA Roundtable 2 juni 2008 Arthur Donkers, 1Secure BV arthur@1secure.nl 1 SOA Web 2.0, web services en service oriented architecture (SOA) is tegenwoordig de

Nadere informatie

Single Sign On. voor. Residentie.net en Denhaag.nl

Single Sign On. voor. Residentie.net en Denhaag.nl Single Sign On voor Residentie.net en Denhaag.nl Omschrijving : -- Opgesteld door : Leon Kuunders Referentie : -- Datum : 30 augustus 2003 Versie : 0.31 (draft) Versiebeheer Versie Datum Auteur Wijziging

Nadere informatie

Samengevoegde reacties op de openbare consultatie voor SAML v2.0 van de volgende partijen: - Kennisnet - Rijkswaterstaat

Samengevoegde reacties op de openbare consultatie voor SAML v2.0 van de volgende partijen: - Kennisnet - Rijkswaterstaat Samengevoegde reacties op de openbare consultatie voor SAML v2.0 van de volgende partijen: - Kennisnet - Rijkswaterstaat KENNISNET 1. Zijn er volgens u in deze toelichting aanvullingen of anderszins wijzigingen

Nadere informatie

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum

Nadere informatie

Identity & Access Management. operational excellence of in control?

Identity & Access Management. operational excellence of in control? Compact 2005/3 Identity & Access Management: operational excellence of in control? Ing. J.A.M. Hermans RE en drs. J. ter Hart Identity & Access Management staat binnen de meeste organisaties volop in de

Nadere informatie

Desktop Single Sign-On Enterprise Single Sign-On

Desktop Single Sign-On Enterprise Single Sign-On Enterprise Single Sign-On 31 Mei 2007 Bob Lannoy Sectie Onderzoek Agenda Problematiek Situering Eigenschappen Marktoverzicht Demo Voordelen / nadelen Alternatieven Besluit 2 Problematiek (1/3) 3 Problematiek

Nadere informatie

Seminar Trends in Business & IT bij woningcorporaties. Informatiebeveiliging

Seminar Trends in Business & IT bij woningcorporaties. Informatiebeveiliging Seminar Trends in Business & IT bij woningcorporaties Informatiebeveiliging Agenda Rondje verwachtingen Even voorstellen.. Informatiebeveiliging waarom? Stand van zaken bij corporaties Informatiebeveiliging

Nadere informatie

Taakcluster Operationeel support

Taakcluster Operationeel support Ideeën en plannen kunnen nog zo mooi zijn, uiteindelijk, aan het eind van de dag, telt alleen wat werkelijk is gedaan. Hoofdstuk 5 Taakcluster Operationeel support V1.1 / 01 september 2015 Hoofdstuk 5...

Nadere informatie

Handleiding uitvoering ICT-beveiligingsassessment

Handleiding uitvoering ICT-beveiligingsassessment Handleiding uitvoering ICT-beveiligingsassessment Versie 2.1 Datum : 1 januari 2013 Status : Definitief Colofon Projectnaam : DigiD Versienummer : 2.0 Contactpersoon : Servicecentrum Logius Postbus 96810

Nadere informatie

Meer Business mogelijk maken met Identity Management

Meer Business mogelijk maken met Identity Management Meer Business mogelijk maken met Identity Management De weg naar een succesvolle Identity & Access Management (IAM) implementatie David Kalff OGh 14 september 2010 't Oude Tolhuys, Utrecht Agenda Herkent

Nadere informatie

Enterprise SSO Manager (E-SSOM) Security Model

Enterprise SSO Manager (E-SSOM) Security Model Enterprise SSO Manager (E-SSOM) Security Model INHOUD Over Tools4ever...3 Enterprise Single Sign On Manager (E-SSOM)...3 Security Architectuur E-SSOM...4 OVER TOOLS4EVER Tools4ever biedt sinds 2004 een

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

Factsheet Penetratietest Informatievoorziening

Factsheet Penetratietest Informatievoorziening Factsheet Penetratietest Informatievoorziening Since the proof of the pudding is in the eating DUIJNBORGH - FORTIVISION Stadionstraat 1a 4815NC Breda +31 (0) 88 16 1780 www.db-fortivision.nl info@db-fortivision.nl

Nadere informatie

Single sign on kan dé oplossing zijn

Single sign on kan dé oplossing zijn Whitepaper Single sign on kan dé oplossing zijn door Martijn Bellaard Martijn Bellaard is lead architect bij TriOpSys en expert op het gebied van security. De doorsnee ICT-omgeving is langzaam gegroeid

Nadere informatie

Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard

Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard Pagina 1 van 6 Inhoudsopgave 1. Aanleiding 3 2. Structureel / incidenteel 3 3. Opdrachtgever 3 4. Opdrachtnemer 3 5. Relevante wet- en regelgeving 3 6.

Nadere informatie

NEN 7510: een ergernis of een hulpmiddel?

NEN 7510: een ergernis of een hulpmiddel? NEN 7510: een ergernis of een hulpmiddel? Tweedaagse van Ineen 17 September 2015 Nijmegen Den Haag SMASH en CIHN in cijfers i. 3 huisartsenposten/1 call center 2 huisartsenposten/ 1 call center ii. 4 visitewagens

Nadere informatie

BEVEILIGINGSARCHITECTUUR

BEVEILIGINGSARCHITECTUUR BEVEILIGINGSARCHITECTUUR Risico s onder controle Versie 1.0 Door: drs. Ir. Maikel J. Mardjan MBM - Architect 2011 cc Organisatieontwerp.nl AGENDA Is een beveiligingsarchitectuur wel nodig? Oorzaken beveiligingsincidenten

Nadere informatie

Logische Toegangsbeveiliging

Logische Toegangsbeveiliging Logische Toegangsbeveiliging Project risico s bij RBAC implementaties Afstudeerscriptie I. Bierman W. van der Valk Begeleiders B. Bokhorst E. van Essen Datum April, 2007 Plaats Amsterdam Voorwoord Deze

Nadere informatie

Business. IT in charge. Met resultaten CIO Survey en 9 CIO s aan het woord. Analytics

Business. IT in charge. Met resultaten CIO Survey en 9 CIO s aan het woord. Analytics Business Analytics IT in charge Met resultaten CIO Survey en 9 CIO s aan het woord Informatie is van en voor mensen CIO speelt belangrijke rol in nieuw spanningsveld Door Guus Pijpers Een van de eerste

Nadere informatie

Applicatierationalisatie? Probeer het eens met BPM

Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Vrijwel iedere CIO streeft naar lagere kosten en een grotere flexibiliteit van de IT-omgeving. Organisaties

Nadere informatie

Whitepaper. Veilig de cloud in. Whitepaper over het gebruik van Cloud-diensten deel 1. www.traxion.com

Whitepaper. Veilig de cloud in. Whitepaper over het gebruik van Cloud-diensten deel 1. www.traxion.com Veilig de cloud in Whitepaper over het gebruik van Cloud-diensten deel 1 www.traxion.com Introductie Deze whitepaper beschrijft de integratie aspecten van clouddiensten. Wat wij merken is dat veel organisaties

Nadere informatie

Procesmanagement. Hoe processen beschrijven. Algra Consult

Procesmanagement. Hoe processen beschrijven. Algra Consult Procesmanagement Hoe processen beschrijven Algra Consult Datum: juli 2009 Inhoudsopgave 1. INLEIDING... 3 2. ORGANISATIE VAN PROCESMANAGEMENT... 3 3. ASPECTEN BIJ HET INRICHTEN VAN PROCESMANAGEMENT...

Nadere informatie

Jacques Herman 21 februari 2013

Jacques Herman 21 februari 2013 KING bijeenkomst Audit- en Pentestpartijen Toelichting op de DigiD Rapportage template en de NOREA Handreiking DigiD ICT-beveiligingsassessments Jacques Herman 21 februari 2013 Samenvatting van de regeling

Nadere informatie

Controleverklaring van de onafhankelijke accountant

Controleverklaring van de onafhankelijke accountant Controleverklaring van de onafhankelijke accountant Aan: de algemene vergadering van Nederlandse Waterschapsbank N.V. Verklaring over de jaarrekening 2014 Ons oordeel Wij hebben de jaarrekening 2014 van

Nadere informatie

Advies informatiebeveiligings analyse HvA

Advies informatiebeveiligings analyse HvA Advies informatiebeveiligings analyse HvA Wouter Borremans - 0461911 - v1.1 1 Juni 2005 1 Inleiding Dit document is geschreven met als doel om de Hogeschool van Amsterdam[5] (HvA) te voorzien van een advies

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

WHITE PAPER. Agile/Scrum

WHITE PAPER. Agile/Scrum WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile

Nadere informatie

Het College van burgemeester en wethouders van de gemeente Winsum, gelet op artikel 14 van de Wet gemeentelijke basisadministratie persoonsgegevens;

Het College van burgemeester en wethouders van de gemeente Winsum, gelet op artikel 14 van de Wet gemeentelijke basisadministratie persoonsgegevens; Het College van burgemeester en wethouders van de gemeente Winsum, gelet op artikel 14 van de Wet gemeentelijke basisadministratie persoonsgegevens; besluit vast te stellen de navolgende Beheerregeling

Nadere informatie

Aan uw raad is het volgende toegezegd: Toezeggingen college van B&W in Commissies en Raad (september 2015) TCM 09 21 mei 2015

Aan uw raad is het volgende toegezegd: Toezeggingen college van B&W in Commissies en Raad (september 2015) TCM 09 21 mei 2015 Bedrijfsvoering De gemeenteraad van Bloemendaal Datum : 19 augustus 2015 Uw kenmerk : Ons kenmerk : 2015056815 Behandeld door : J. van der Hulst Doorkiesnummer : 023-522 5592 Onderwerp : Rapportage informatiebeveiliging

Nadere informatie

Virtueel of Fysiek. Uitdagingen bij migratie naar Windows 7

Virtueel of Fysiek. Uitdagingen bij migratie naar Windows 7 Het jaar 2011/2012 staat voor veel organisaties in het teken van Windows 7. De overstap van Windows XP naar Windows 7 lijkt in eerste instantie eenvoudig te zijn maar blijkt in de praktijk toch complex.

Nadere informatie

Business Risk Management? Dan eerst data op orde!

Business Risk Management? Dan eerst data op orde! Business risk management? Dan eerst data op orde! Kwaliteit, leveringsbetrouwbaarheid, klantgerichtheid, kostenbewustzijn en imago zijn kernwaarden in de bedrijfsvoering die door nutsbedrijven hartelijk

Nadere informatie

MKB Cloudpartner Informatie TPM & ISAE 3402 2016

MKB Cloudpartner Informatie TPM & ISAE 3402 2016 Third Party Memorandum (TPM) Een Derde verklaring of Third Party Mededeling (TPM) is een verklaring die afgegeven wordt door een onafhankelijk audit partij over de kwaliteit van een ICT-dienstverlening

Nadere informatie

WHITE PAPER. Business Solutions

WHITE PAPER. Business Solutions WHITE PAPER Business Solutions De keuze van de strategie/aanpak is be-palend voor de complexiteit en doorlooptijd van een implementatie. Introductie Uw organisatie staat op het punt om een standaard software

Nadere informatie

Welkom bij parallellijn 1 On the Move 14.20 15.10 uur

Welkom bij parallellijn 1 On the Move 14.20 15.10 uur Welkom bij parallellijn 1 On the Move 14.20 15.10 uur Stap 4 van de BIG Hoe stel ik vast of de informatiebeveiligingsmaatregelen van mijn gemeente effectief zijn en hoe rapporteer ik hierover? 1 IBD-Praktijkdag

Nadere informatie

Handleiding voor beheerders SesamID

Handleiding voor beheerders SesamID Handleiding voor beheerders SesamID Versie 3.0 Mei 2013 2013 Copyright KPN Lokale Overheid Alle rechten voorbehouden. Zonder voorafgaande schriftelijke toestemming van KPN Lokale overheid mag niets uit

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen

VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen Missie-Visie Het succes van de leerling is de reden van ons bestaan.

Nadere informatie

24/7. Support. smart fms

24/7. Support. smart fms 24/7 Support Smart FMS vindt het van het grootste belang dat haar klanten helder inzicht hebben in de voorwaarden, zekerheid over gemaakte afspraken en het vertrouwen in haar als softwareaanbieder. Het

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE versie 2.0, 14 april 2010 SURFNET BV, R ADBOUDKWARTIER 273, POSTBUS 19035, 3501 DA U TRECHT T +31 302 305 305, F +31 302 305 329, WWW.SURFNET. NL INHOUD 1.

Nadere informatie

Whitepaper M3. Inleiding. M3 Principes in het kort

Whitepaper M3. Inleiding. M3 Principes in het kort Whitepaper M3 Veel transities en bijbehorende migraties blijken uitermate complex. Door het toepassen van een gestructureerde methode kan deze complexiteit natuurlijk wel beheerst worden, zowel qua doorlooptijd

Nadere informatie

BPM voor Sharepoint: het beste van twee werelden

BPM voor Sharepoint: het beste van twee werelden BPM voor Sharepoint: het beste van twee werelden BPM voor Sharepoint: het beste van twee werelden Analisten als Gartner en Forrester voorzien dat Sharepoint dé standaard wordt voor document management

Nadere informatie

Een nieuwe kijk op vastgoedregistratie WOZ en lokale heffingen

Een nieuwe kijk op vastgoedregistratie WOZ en lokale heffingen Een nieuwe kijk op vastgoedregistratie WOZ en lokale heffingen 2 TAX Onze organisatie is inmiddels een decennium geleden begonnen met het ontwikkelen van geautomatiseerde hulpmiddelen in het kader van

Nadere informatie

Informatiebeveiligingsbeleid

Informatiebeveiligingsbeleid Unit : Bedrijfsvoering Auteur : Annemarie Arnaud de Calavon : : Datum : 17-11-2008 vastgesteld door het CvB Bestandsnaam : 20081005 - Informatiebeveiliging beleid v Inhoudsopgave 1 INLEIDING... 3 1.1 AANLEIDING...

Nadere informatie

Rijkspas: veiligheid en flexibiliteit. ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011

Rijkspas: veiligheid en flexibiliteit. ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011 Rijkspas: veiligheid en flexibiliteit ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011 24-11-2011 Profile Consultancy Services State of the art software solutions Project implementation Life-cycle

Nadere informatie

Red Spider Next Generation: Identity Management voor gevorderden. Bert van Daalen René Visser Ronald Zierikzee

Red Spider Next Generation: Identity Management voor gevorderden. Bert van Daalen René Visser Ronald Zierikzee Red Spider Next Generation: Identity Management voor gevorderden Bert van Daalen René Visser Ronald Zierikzee Constateringen rijp en groen Hoge ontwikkelkosten en lange doorlooptijd nieuwe functionaliteit

Nadere informatie

NORA werkdocument. Katern Beveiliging. In 3 klikken naar bouwstenen voor invulling van de eisen. Sessie 6. Bijgewerkt op 23 aug.

NORA werkdocument. Katern Beveiliging. In 3 klikken naar bouwstenen voor invulling van de eisen. Sessie 6. Bijgewerkt op 23 aug. NORA werkdocument Sessie 6 In 3 klikken naar bouwstenen voor invulling van de eisen Katern Beveiliging Bijgewerkt op 23 aug. 2013 katern Beveiliging Jaap van der Veen Essentie Sessie 6 1. Opzet digitaal

Nadere informatie

Curriculum Vitae van Paul Verstraaten

Curriculum Vitae van Paul Verstraaten Personalia Naam Paul Verstraaten Geboortedatum 26-03-1955 Adres Acaciahof 48 Nationaliteit NL Postcode 3355AA Woonplaats Papendrecht Geslacht Man Telefoon 06-29275306 Burgerlijke staat Gehuwd E-mail pd_verstraaten@planet.nl

Nadere informatie

A C C E S S & I D E N T I T Y m A N A G E M E N T

A C C E S S & I D E N T I T Y m A N A G E M E N T Z O R G A C C E S S & I D E N T I T Y m A N A G E M E N T Balans tussen toegankelijkheid en beveiliging "Is het mogelijk dat de medische staf overal en snel over medische gegevens kan beschikken, terwijl

Nadere informatie

Zou het niet iedeaal zijn

Zou het niet iedeaal zijn Zou het niet iedeaal zijn ...als op de eerste werkdag van een nieuwe medewerker alles klaarstaat?! Er zal geen discussie over bestaan. Het zou ideaal zijn wanneer alle voorzieningen op de eerste werkdag

Nadere informatie

Proquro Releasenotes 5.9 detail pagina

Proquro Releasenotes 5.9 detail pagina Proquro Releasenotes 5.9 detail pagina Referentie nr. PRQ-7300 Bij vervangen gebruiker kan contractbeheerder door niet contractbeheerder vervangen worden SMM Bij het vervangen van een gebruiker wordt niet

Nadere informatie

Factsheet Penetratietest Infrastructuur

Factsheet Penetratietest Infrastructuur Factsheet Penetratietest Infrastructuur Since the proof of the pudding is in the eating DUIJNBORGH - FORTIVISION Stadionstraat 1a 4815NC Breda +31 (0) 88 16 1780 www.db-fortivision.nl info@db-fortivision.nl

Nadere informatie

Draaiboek Invoering Basisregistratie Personen l Afnemers

Draaiboek Invoering Basisregistratie Personen l Afnemers Draaiboek Invoering Basisregistratie Personen l Afnemers Hoofdstap 3 Voorbereiden Publicatiedatum: oktober 2014 Inleiding U heeft een vastgesteld plan van aanpak, u weet welke voorbereidende werkzaamheden

Nadere informatie

SQL Plan Management in Oracle11g Harald van Breederode

SQL Plan Management in Oracle11g Harald van Breederode SQL Plan Management in Oracle11g Harald van Breederode Sinds de introductie van de Cost Based Optimizer (CBO) in Oracle7 hebben zowel database beheerders als database ontwikkelaars de wens om deze optimizer

Nadere informatie

Authentication is the key

Authentication is the key inhoud Authentication is the key en Control en IAM - oplossing Een klantvoorbeeld www.thauco.com Versie 5 6-12-2010 The Authentication Company 1 Soorten: Identificatie: Wie ben jij? Verificatie: ben je

Nadere informatie

ACCESS GOVERNANCE PIZZASESSIE. Arnout van der Vorst & Tjeerd Seinen

ACCESS GOVERNANCE PIZZASESSIE. Arnout van der Vorst & Tjeerd Seinen ACCESS GOVERNANCE PIZZASESSIE Arnout van der Vorst & Tjeerd Seinen AGENDA PIZZASESSIE ACCESS GOVERNANCE 17:30 Conceptuele schets Access Governance 18:30 Pizza 19:15 Product demo 20:15 Borrel ACCESS GOVERNANCE

Nadere informatie

Verborgen gebreken in de defence in depth theorie

Verborgen gebreken in de defence in depth theorie Verborgen gebreken in de defence in depth theorie Iedere beveiligingsprofessional kent waarschijnlijk het schillenconcept. Dit staat bekend onder verschillende benamingen zoals defence in depth of layers

Nadere informatie

ICT Accountancy. Praktijkdag Webwinkels en Boekhouden

ICT Accountancy. Praktijkdag Webwinkels en Boekhouden ICT Accountancy Praktijkdag Webwinkels en Boekhouden Thema Betrouwbaar Administreren Misbruik Afrekensystemen Misbruik Afrekensystemen Internationaal probleem Veel oplossingsrichtingen Overleg Belastingdienst

Nadere informatie

NetPay Desktop Reporting. Rapportage voor Xafax NetPay

NetPay Desktop Reporting. Rapportage voor Xafax NetPay NetPay Desktop Reporting Rapportage voor Xafax NetPay Inhoud 1.0.0 NetPay Desktop Reporting... 3 1.1.0 Minimumeisen... 3 1.2.0 NetPay instellingen... 3 1.2.1 Access Rights groepen... 3 1.2.2 Gebruikers

Nadere informatie

Bedrijfssystemen vervangen door Slim Software Nabouwen

Bedrijfssystemen vervangen door Slim Software Nabouwen Bedrijfssystemen vervangen door Slim Software Nabouwen Codeless White Paper Roland Worms, Directeur Wouter van der Ven, Lead Software Architect Inhoudsopgave 1. Introductie 2. Het IT dilemma. Als standaard

Nadere informatie

Access Governance: een einde aan de worsteling rondom autorisatiemanagement?

Access Governance: een einde aan de worsteling rondom autorisatiemanagement? 22 Het beheersen van de toegang met betrekking tot applicaties en systemen en het hierover verantwoording kunnen afleggen, is voor veel organisaties een uitdaging. In dit artikel wordt een praktische aanpak

Nadere informatie

Audit: Beveiliging Digitale Examens

Audit: Beveiliging Digitale Examens Audit: Beveiliging Digitale Examens 1 Hoffmann Bedrijfsrecherche bv http://www.youtube.com/watch?v=wq-wn7lykxu 2 Regio met grote ambities Onze regio, Brainport regio Eindhoven, is een van de meest dynamische

Nadere informatie

De toekomst van een IT-auditor in een integrated / financial audit. Robert Johan Tom Koning

De toekomst van een IT-auditor in een integrated / financial audit. Robert Johan Tom Koning De toekomst van een IT-auditor in een integrated / financial audit Robert Johan Tom Koning Probleemanalyse Gebrek aan kennis accountant Niet doorvragen bij termen smijten Moeite toegevoegde waarde te tonen

Nadere informatie

Nieuwe BI-omgeving van ApplicationNet is waardevolle bron van informatie voor facturatie, rapportages, kostenbesparing en marketing

Nieuwe BI-omgeving van ApplicationNet is waardevolle bron van informatie voor facturatie, rapportages, kostenbesparing en marketing Nieuwe BI-omgeving van ApplicationNet is waardevolle bron van informatie voor facturatie, rapportages, kostenbesparing en marketing Organisatie Werkplek Online is de private cloud oplossing van ApplicationNet

Nadere informatie

Seclore FileSecure: beveiliging zonder grenzen!

Seclore FileSecure: beveiliging zonder grenzen! Seclore FileSecure: beveiliging zonder grenzen! Naam auteur : S. Liethoff Type document : Whitepaper Datum versie : 14-02-2013 1. Seclore FileSecure: Beveiliging zonder grenzen! Seclore FileSecure is een

Nadere informatie

Rapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement

Rapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement Rapportage Pizzasessie Functioneel-beheer.com Alle deelnemers hebben hun functienaam opgegeven. De volgende functienamen zijn gemeld: Specialisten o Functioneel beheerder (9x) o Functioneel applicatiebeheerder

Nadere informatie

Voldoende audit evidence?

Voldoende audit evidence? 51 Voldoende audit evidence? Drs. H.G.Th. van Gils RE RA In versterkte mate komt de laatste tijd weer de discussie opzetten over de diepgang van de controlewerkzaamheden van de accountant en IT-auditor.

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

IAM en Cloud Computing

IAM en Cloud Computing IAM en Cloud Computing Cloud café 14 Februari 2013 W: http://www.identitynext.eu T: @identitynext www.everett.nl www.everett.nl Agenda 1. Introductie 2. IAM 3. Cloud 4. IAM en Cloud 5. Uitdagingen 6. Tips

Nadere informatie

Governance, Risk and Compliance (GRC) tools

Governance, Risk and Compliance (GRC) tools Governance, Risk and Compliance (GRC) tools Auteurs: Peter Paul Brouwers en Maurice op het Veld Samenvatting Het voldoen aan de wet- en regelgeving met betrekking tot bijvoorbeeld de Sarbanes Oxley Act

Nadere informatie

De elektronische handtekening en de Dienstenrichtlijn De elektronische handtekening Wat zegt een elektronische handtekening?

De elektronische handtekening en de Dienstenrichtlijn De elektronische handtekening Wat zegt een elektronische handtekening? De en de Dienstenrichtlijn Deze factsheet behandelt de Dit is een middel om te kunnen vertrouwen op berichten en transacties. Op 28 december 2009 moet in alle EU-lidstaten de Dienstenrichtlijn zijn ingevoerd.

Nadere informatie

Op naar een excellente controle

Op naar een excellente controle Op naar een excellente controle Welke controlewerkzaamheden kunnen verder geoptimaliseerd worden om kosten te besparen of om meer toegevoegde waarde te kunnen bieden aan cliënten? Hoe kunnen deze werkzaamheden

Nadere informatie

SURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december 2013. 030-2 305 305 admin@surfnet.nl www.surfnet.

SURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december 2013. 030-2 305 305 admin@surfnet.nl www.surfnet. SURFconext Cookbook Het koppelen van Alfresco aan SURFconext Auteur(s): Frank Niesten Versie: 1.0 Datum: 8 december 2013 Radboudkwartier 273 3511 CK Utrecht Postbus 19035 3501 DA Utrecht 030-2 305 305

Nadere informatie

Rolgebaseerd autoriseren: effectief sturen op ICT-gebruik

Rolgebaseerd autoriseren: effectief sturen op ICT-gebruik Compact 2004/2 Rolgebaseerd autoriseren: effectief sturen op ICT-gebruik Mr. P.R. Heiden, drs. M. Stultjens en ing. J.A.M. Hermans RE Het belang van een effectieve sturing op en beheersing van het gebruik

Nadere informatie

SVHT-IT. Mission statement

SVHT-IT. Mission statement SVHT-IT Mission statement Wij leveren oplossingen en diensten aan het MKB op het gebied van ICT, waarbij service, flexibiliteit en een persoonlijke relatie met de klant voorop staan SVHT-IT is een onderneming

Nadere informatie

Cloud Computing, een inleiding. ICT Accountancy & Financials congres 2013: Cloud computing en efactureren. Jan Pasmooij RA RE RO: jan@pasmooijce.

Cloud Computing, een inleiding. ICT Accountancy & Financials congres 2013: Cloud computing en efactureren. Jan Pasmooij RA RE RO: jan@pasmooijce. Cloud Computing, een inleiding ICT Accountancy & Financials congres 2013: Cloud computing en efactureren 10 december 2013 Jan Pasmooij RA RE RO: jan@pasmooijce.com 10 december 2013 1 Kenmerken van Cloud

Nadere informatie

CEL. Bouwstenen voor een elektronische leeromgeving

CEL. Bouwstenen voor een elektronische leeromgeving CEL Bouwstenen voor een elektronische leeromgeving FACTSHEET CEL VERSIE 1.0 DECEMBER 2001 CEL - Bouwstenen voor een elektronische leeromgeving Inhoudsopgave Wat is CEL? 1 Uitgangspunten 1 De eindgebruiker

Nadere informatie

Beveiligingsbeleid Perflectie. Architectuur & Procedures

Beveiligingsbeleid Perflectie. Architectuur & Procedures Beveiligingsbeleid Perflectie Architectuur & Procedures 30 november 2015 Versiebeheer Naam Functie Datum Versie Dimitri Tholen Software Architect 12 december 2014 0.1 Dimitri Tholen Software Architect

Nadere informatie

OpenIMS 4.2 Portaal Server

OpenIMS 4.2 Portaal Server OpenIMS 4.2 Portaal Server Inhoudsopgave 1 WAT IS EEN ENTERPRISE INFORMATIE PORTAAL?...3 1.1 BESPARINGEN...3 1.2 GERICHT OP EEN SPECIFIEKE DOELGROEP...3 2 OPENIMS PORTAAL SERVER (PS)...4 2.1 CENTRAAL BEHEER...4

Nadere informatie

Beknopte dienstbeschrijving beveiligen van Webapplicaties m.b.v. digitale certificaten en PKI

Beknopte dienstbeschrijving beveiligen van Webapplicaties m.b.v. digitale certificaten en PKI Beknopte dienstbeschrijving beveiligen van Webapplicaties m.b.v. digitale certificaten en PKI Document: Beknopte dienstbeschrijving beveiligen van Webapplicaties Versie: maart 2002 mei 2002 Beknopte dienstbeschrijving

Nadere informatie

Partneren met een Cloud broker

Partneren met een Cloud broker Partneren met een Cloud broker Vijf redenen om als reseller te partneren met een Cloud broker Introductie Cloud broker, een term die je tegenwoordig vaak voorbij hoort komen. Maar wat is dat nu precies?

Nadere informatie

6.6 Management en informatiebeveiliging in synergie

6.6 Management en informatiebeveiliging in synergie 6.6 Management en informatiebeveiliging in synergie In veel organisaties ziet men dat informatiebeveiliging, fysieke beveiliging en fraudemanagement organisatorisch op verschillende afdelingen is belegd.

Nadere informatie

[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen.

[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen. Applicatiebeheer het beheren van applicaties. [functie] De functie die verantwoordelijk is voor het beheren van applicaties. Beheer (beheren) Control Onder de activiteit applicatiebeheer valt de ontwikkeling,

Nadere informatie

NORA Sessie 5. 29 mei 2013 in Amersfoort Agenda en een samenvatting. Jaap van der Veen

NORA Sessie 5. 29 mei 2013 in Amersfoort Agenda en een samenvatting. Jaap van der Veen NORA Sessie 5 29 mei 2013 in Amersfoort Agenda en een samenvatting Jaap van der Veen Agenda 29-5-2013 1. Welkom 2. Presentatie Eric Brouwer en Joris Dirks over Kennismodel NORA-Wiki en hoe we onze informatie

Nadere informatie

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Managers moeten beslissingen nemen over IT, maar

Nadere informatie