Sprekers
Mark van Reijn
Technology Specialist ISM
Novell, Inc.
Gert-Jan de Jong
IT security consultant
Atos Origin
Samenvatting
RBAC kan een grote waarde hebben voor organisaties die een realistische en praktische houding hebben bij de implementatie ervan. De nieuwe Identity Manager Roles Based Provisioning Module integreert het RBAC model met Novell Identity Manager en ondersteunt de toegangsbeheer processen van de organisatie. Deze sessie geeft een visie op RBAC en praktijk ervaringen.
Strekking van de presentatie
Korte inleiding RBAC theorie
Het concept is meer dan 30 jaar oud en heeft zijn achtergrond in het groeperen van systeemtoegangen en functiescheiding. In 1992 is het RBAC model voor het eerst als voorstel ingediend bij NIST om opgenomen te worden als standaard. In 2001 is de huidige standaard geaccepteerd. Het hoofddoel van standaardisatie was het hebben van een referentiemodel en standaard terminologie voor toegangsbeheer.
De basis van RBAC bestaat uit relaties tussen: identiteiten <-> rollen <-> bevoegdheden op objecten. Waarbij een object bepaalde informatie of functionaliteit kan representeren. Hiërarchische RBAC maakt diverse rol <-> rol relaties mogelijk. Een ander belangrijk aspect is de mogelijkheid tot functie scheiding, waarbij 2 soorten te onderscheiden zijn:
- statische functiescheiding
Een identiteit mag niet de bevoegdheden A én B beide toegewezen hebben gekregen.
- dynamische functiescheiding
Een identiteit mag wel de bevoegdheden A en B toegewezen hebben gekregen, maar voor een bepaald soort transactie niet beide gebruiken.
Een aantal veel voorkomende redenen voor het gebruik van RBAC zijn:
- versimpelen van toegangsbeheer
- mogelijkheden voor delegatie van toegangsbeheer
- communicatie tussen business en techniek
De business moet kunnen begrijpen wat toegang op systemen precies inhoudt. Dit kan door bevoegdheden in functionele termen te definiëren en te koppelen aan technische systeemtoegangen.
- rapporteren
Rapportages zijn begrijpelijk voor de business, vanwege de definitie van bevoegdheden in functionele termen.
Novell's referentie model
Novell gebruikt een standaard indeling voor het definiëren en beheren van rollen, bevoegdheden en systeemtoegangen. Dit model ondersteunt de praktische benadering die Novell nastreeft. Het model bestaat uit de volgende onderdelen:
- Business Roles
Rollen in business termen, bijvoorbeeld: administratief medewerker
- IT Roles
Rollen die aansluiten bij de technische architectuur, bijvoorbeeld: financiële applicatie.
- Permission Roles (bevoegdheden)
Specifieke bevoegdheden, bijvoorbeeld: betalingen kunnen doen.
- Entitlements (systeemtoegangen)
Technische benodigdheden, bijvoorbeeld: toegangsrechten op een bepaald bestand, gekoppeld aan een account op het systeem.
RBAC met de Novell's Roles Based Provisioning Module
Het RBAC model is sterk geïntegreerd met identity en access management producten. Deze producten kunnen rollen synchroniseren en bepaalde acties nemen op basis van rollen. In de Designer, Novell's applicatie voor configuratie en ontwikkeling van IAM producten, kunnen de definities van systeemtoegangen (Novell: entitlements) en bevoegdheden (Novell: permission roles) worden gedefinieerd. Een initiële inrichting voor het gehele rollenmodel, inclusief Business Roles is ook te definiëren.
Het toegangsbeheer proces in de organisatie wordt ondersteund door een webapplicatie, de User Application. In deze applicatie zijn mogelijkheden opgenomen voor het toewijzen en intrekken van rollen, het beheren van rollen en het definiëren van functiescheidingsregels. Workflow functionaliteit maakt het mogelijk menselijke interactie op te nemen in het proces, zoals het goedkeuren van aanvragen. Het toewijzen van rollen kan op verschillende manieren, handmatig en automatisch op basis van bepaalde criteria. De mogelijkheden zijn:
- toewijzing van rollen aan (dynamische) groepen
Een identiteit kan automatisch in een groep zijn ingedeeld op basis van een bepaald attribuut of gegeven van de identiteit, denk aan een functienaam of projectgroep. Indien rollen zijn toegewezen aan deze groep, krijgt de identiteit automatisch de rol toegewezen.
- toewijzing van rollen aan containers
Containers volgen vaak een structuur van de organisatie, bijvoorbeeld afdelingen of fysieke locaties. Indien een rol aan een container is toegewezen krijgt iedere identiteit op die locatie of afdeling automatisch de rol toegewezen.
- toewijzing van rollen aan identiteiten
Directe toewijzing aan identiteiten zijn bijvoorbeeld rollen die op aanvraag worden uitgedeeld. Hierdoor worden uitzonderingen op de automatische toewijzingen mogelijk.
Praktijk ervaringen
Vanuit praktijkervaring met toegangsbeheer processen is het volgende driehoek model ontstaan: Roles <-> Rules <-> Approvals
100% Roles
Rollen met bevoegdheden definiëren voor iedere systeemtoegang, geen uitzonderingen.
100% Rules
Als je voldoet aan bepaald criterium, krijg je direct een bepaalde systeemtoegang.
100% Approvals
Alle systeemtoegangen worden uitgedeeld op aanvraag en rechtstreeks toegewezen aan de identiteit.
De ideale situatie ligt in het middelste gebied:
- Maak niet overal rollen voor, houd ze proces gericht.
- Gebruik Rules in het algemeen voor het automatisch toewijzen van rollen, alleen in uitzonderlijke gevallen voor het automatisch toewijzen van systeemtoegangen.
- Alles wat dan niet gedekt is, gaat op aanvraag. Trends in aanvragen kunnen een aanwijzing zijn, dat aanpassing van het rollenmodel benodigd is. Zoals met zoveel zaken is 80/20 regel een acceptabele balans, waarbij 80% van de bevoegdheden automatisch wordt toegewezen en 20% op aanvraag.
Probeer rollen te definiëren in termen van het proces, zodat bij reorganisaties de rollen niet te veel hoeven te wijzigen. Maak een procedure voor uitzonderingen, alles in rollen definiëren is moeilijk te onderhouden. RBAC gaat uit van principle of least privilege, een zeer fijnmazige definitie van rollen, waarbij een identiteit allen toegang heeft tot het noodzakelijke. In praktijk blijkt dat onderscheid nodig is tussen kritische bevoegdheden en niet-kritische bevoegdheden, waarbij de niet-kritische bevoegdheden wat ruimer mogen zijn. De identiteit heeft dan ook toegang tot zaken die niet direct noodzakelijk zijn, maar dit is in het geval van niet-kritische bevoegdheden niet erg. Als laatste dient een organisatie te beseffen dat het beheer van rollen een continu proces is, geen statische inrichting!
Analyse
Het referentiemodel van Novell ziet er logisch uit, maar wat betekent het nu voor het toegangsbeheer proces. Het ziet er nu uit alsof de IT afdeling alle definities maakt en de business alleen maar business roles hoeft te definiëren. In praktijk werkt dit niet, omdat er dan te weinig communicatie tussen business en IT plaatsvindt. De definities van toegang die door IT ter beschikking worden gesteld moeten voldoen aan de behoefte van de business. Morgen zal er nog een sessie plaatsvinden waar het proces besproken zal worden, hopelijk wordt het een en ander dan duidelijker.
Daarnaast lijkt er een vervaging van terminologie te ontstaan. Het NIST model hanteert een duidelijk onderscheid tussen: Role, Permission (bevoegdheid) en Privilege (systeemtoegang). In het Novell referentiemodel wordt Permission als de laagste hiërarchische rol gezien en Privilege zit in een entitlement. Een entitlement is in feite een Rule, waarbij een Privilege wordt toegewezen op basis van een bepaald criterium. Nu wordt entitlement dus ook gebruikt als definitie van Privilege, maar dan zonder criterium voor automatische toewijzing. Volgt u het nog?
Als laatste wil ik ingaan op de fijnmazigheid van het definiëren van rollen en bevoegdheden. Kritisch en niet-kritisch is natuurlijk te simpel gesteld, maar de sprekers zullen bedoelen dat er gekeken moet worden naar het risico behorend bij de betreffende informatie of functionaliteit. Indien het risico hoog is, moeten rollen het principle of least privilege volgen, waarbij nauwkeurige functiescheiding mogelijk wordt. Bij lager risico kunnen definities ruimer worden genomen, wat het beheer en gebruikersgemak ten goede komt. De ondergrens is dus het risico dat de organisatie acceptabel vindt.
17.3.08
Partnering for Successful Identity Management and Security Deployments
Spreker
Mike Neuenschwander
General Manager
Mycroft
Mike Neuenschwander en Nick Nichols hebben rond 1999 het Novell DirXML product, de voorloper op de huidige identity manager, van concept tot implementatie ontwikkeld. Mike was destijds product manager, Nick engineer. Ze zijn later beide naar Burton gegaan en Nick is sinds eind 2006 weer terug bij Novell als product manager voor identity manager.
Samenvatting
Deze sessie voorziet partners en overige partijen van praktijk informatie over de benadering van IDM projecten.
Analyse
Volgens onderzoek dat Mike bij Burton heeft verricht, blijkt dat organisaties gemiddeld 3 keer hun IDM project herzien of opnieuw starten. De meest voorkomende problemen zijn:
- aanname dat IDM een plug-and-play product is, zoals een email systeem
- gebrekkige communicatie met business
IDM wordt voor een technisch doel ingezet, bijvoorbeeld synchronisatie. Later groeit de implementatie, waardoor er impact ontstaat op diverse bedrijfsprocessen, zoals HR of helpdesk. Deze worden niet goed gecommuniceerd met de business, omdat het project vanuit de techniek groeit. De business accepteert de nieuwe werkwijze niet, of er bestaan veel te hoge verwachtingen. Het IDM project is vervolgens gedoemd te mislukken.
- gebrekkige governance structuur in de organisatie
Invoering van IDM in een organisatie is een meer jaren traject wat op veel processen invloed heeft. Als de processen in de organisatie zelf onduidelijk en niet gedocumenteerd zijn, ontbreekt de vaste fundering voor IDM.
Mike geeft in globale termen een mogelijke aanpak. Begin met het vastleggen van de huidige processen. Analyseer de procesinrichting en mogelijke risico's. Wat moet de organisatie veranderen aan de processen om IDM te kunnen invoeren, rekening houdend met de business drivers van de projectsponsor. In feite een stukje governance.
Vervolgens processen stuk voor stuk automatiseren met IDM. Het uitgangspunt moet dus niet het IDM systeem zijn, wat zeer veel functionaliteit heeft dat tegelijk ingrijpt op diverse processen. Als dit het uitgangspunt is, wordt er te adhoc op allerlei processen invloed uitgeoefend.
Een aantal van mijn vragen heeft Mike in de sessie naar mijn idee niet concreet genoeg beantwoord. Het gaat om het volgende.
In principe wordt er een analyse gedaan van de huidige staat van bedrijfsprocessen. Vervolgens wordt op gezond verstand van de analist vertrouwd om de gewenste staat van de bedrijfsprocessen te beschrijven. Maar is het niet veel beter een meetbare en repeteerbare methode te hanteren, waarbij een GAP analyse kan worden gemaakt tussen de huidige staat en de gewenste staat van bepaalde bedrijfsprocessen? Een organisatie kan dan gericht gaan sturen en rapporteren over de inrichting van de governance structuur.
Al met al blijkt het zwaartepunt van IDM niet bij de techniek te liggen. Deze week hoop ik samen met Mike en Nick hier nog eens van gedachten over te wisselen.
Mike Neuenschwander
General Manager
Mycroft
Mike Neuenschwander en Nick Nichols hebben rond 1999 het Novell DirXML product, de voorloper op de huidige identity manager, van concept tot implementatie ontwikkeld. Mike was destijds product manager, Nick engineer. Ze zijn later beide naar Burton gegaan en Nick is sinds eind 2006 weer terug bij Novell als product manager voor identity manager.
Samenvatting
Deze sessie voorziet partners en overige partijen van praktijk informatie over de benadering van IDM projecten.
Analyse
Volgens onderzoek dat Mike bij Burton heeft verricht, blijkt dat organisaties gemiddeld 3 keer hun IDM project herzien of opnieuw starten. De meest voorkomende problemen zijn:
- aanname dat IDM een plug-and-play product is, zoals een email systeem
- gebrekkige communicatie met business
IDM wordt voor een technisch doel ingezet, bijvoorbeeld synchronisatie. Later groeit de implementatie, waardoor er impact ontstaat op diverse bedrijfsprocessen, zoals HR of helpdesk. Deze worden niet goed gecommuniceerd met de business, omdat het project vanuit de techniek groeit. De business accepteert de nieuwe werkwijze niet, of er bestaan veel te hoge verwachtingen. Het IDM project is vervolgens gedoemd te mislukken.
- gebrekkige governance structuur in de organisatie
Invoering van IDM in een organisatie is een meer jaren traject wat op veel processen invloed heeft. Als de processen in de organisatie zelf onduidelijk en niet gedocumenteerd zijn, ontbreekt de vaste fundering voor IDM.
Mike geeft in globale termen een mogelijke aanpak. Begin met het vastleggen van de huidige processen. Analyseer de procesinrichting en mogelijke risico's. Wat moet de organisatie veranderen aan de processen om IDM te kunnen invoeren, rekening houdend met de business drivers van de projectsponsor. In feite een stukje governance.
Vervolgens processen stuk voor stuk automatiseren met IDM. Het uitgangspunt moet dus niet het IDM systeem zijn, wat zeer veel functionaliteit heeft dat tegelijk ingrijpt op diverse processen. Als dit het uitgangspunt is, wordt er te adhoc op allerlei processen invloed uitgeoefend.
Een aantal van mijn vragen heeft Mike in de sessie naar mijn idee niet concreet genoeg beantwoord. Het gaat om het volgende.
In principe wordt er een analyse gedaan van de huidige staat van bedrijfsprocessen. Vervolgens wordt op gezond verstand van de analist vertrouwd om de gewenste staat van de bedrijfsprocessen te beschrijven. Maar is het niet veel beter een meetbare en repeteerbare methode te hanteren, waarbij een GAP analyse kan worden gemaakt tussen de huidige staat en de gewenste staat van bepaalde bedrijfsprocessen? Een organisatie kan dan gericht gaan sturen en rapporteren over de inrichting van de governance structuur.
Al met al blijkt het zwaartepunt van IDM niet bij de techniek te liggen. Deze week hoop ik samen met Mike en Nick hier nog eens van gedachten over te wisselen.
Discussion: Software Asset Management Best Practices
Samenvatting
Deze sessie geeft praktijk oplossingen en bespreekt software asset management in relatie tot de industrie standaarden als ISO 19770-1 en ITIL. Helaas gingen de vragen uit de zaal vooral over de details van de Novell tool, waardoor het proces bijna niet aan bod is gekomen en de industrie standaarden helemaal niet. Toch is er vanuit COBIT en ISO 27002 een interessante link te leggen tussen asset management en informatiebeveiliging, waar de tool nog niet in voorziet...
Spreker
Christina Chamberlain
Technology Sales Specialist
Novell, Inc.
Analyse
Onafhankelijk van de tool, kan het gehele proces software asset management worden samengevat in de volgende deel activiteiten:
aankopen van software
Het verzamelen van alle aankoop gegevens. Uit deze gegevens wordt afgeleid welke software er 'zou moeten' bestaan in de organisatie. Indien het aankopen van software decentraal is georganiseerd, kan het nog wel eens lastig zijn de juiste informatie te krijgen van alle departementen. Ook de verschillende formaten en interpretatie van de aankoopgegevens veroorzaken problemen.
software inventarisatie
Het handmatig of geautomatiseerd inventariseren van geïnstalleerde software op alle hardware systemen. Deze gegevens geven weer welke software er daadwerkelijk geïnstalleerd is.
licentie beheer
Licenties zijn de koppeling tussen aankopen en daadwerkelijke installaties. Uit een aankoop blijkt een bepaalde licentie, die zeer diverse vormen kan aannemen. (per installatie, CPU, gebruiker, enz.) Aan deze licentie zijn de daadwerkelijke installaties te koppelen, waardoor uiteindelijk blijkt welke software zonder toestemming of zelfs illegaal wordt gebruikt.
Ook het intrekken en opnieuw uitdelen van licenties valt hieronder.
aanleveren van software
Het installeren en toegankelijk maken van de software voor de eindgebruiker.
toewijzen/kosten verrekening
Een IT organisatie berekent (intern of extern) de kosten door aan de afnemende organisatie. Kosten bestaan uit software licenties, maar ook begrote kosten voor de helpdesk of technische werkzaamheden.
Kijkend naar de processen uit Cobit en de controls uit ISO/IEC 27002, zijn processen als patch management en configuratie management sterk gerelateerd of zelfs afhankelijk van software asset management. Configuraties behoren bij software assets, dezelfde assets kunnen ook beveiligingslekken bevatten waarvoor patches worden uitgebracht. Het beheer van software assets houd dus veel meer in dan alleen licenties bijhouden. Bijvoorbeeld: wie is systeem eigenaar? Wie is verantwoordelijk voor de veiligheid van de software? Wie controleert of de aankopen van software pakketten voldoen aan de security requirements die door de organisatie gesteld zijn? Deze zaken zijn niet triviaal te ondersteunen met de tools en bijbehorende documentatie. Vaak zijn dit losse producten die delen van de processen ondersteunen. Technisch zal het vast wel aan elkaar te koppelen zijn, wat nog niet betekent dat een organisatie het goed weet in te bedden in alle processen.
Links
www.iaitam.org - International Association of Information Technology Asset Managers
Deze sessie geeft praktijk oplossingen en bespreekt software asset management in relatie tot de industrie standaarden als ISO 19770-1 en ITIL. Helaas gingen de vragen uit de zaal vooral over de details van de Novell tool, waardoor het proces bijna niet aan bod is gekomen en de industrie standaarden helemaal niet. Toch is er vanuit COBIT en ISO 27002 een interessante link te leggen tussen asset management en informatiebeveiliging, waar de tool nog niet in voorziet...
Spreker
Christina Chamberlain
Technology Sales Specialist
Novell, Inc.
Analyse
Onafhankelijk van de tool, kan het gehele proces software asset management worden samengevat in de volgende deel activiteiten:
aankopen van software
Het verzamelen van alle aankoop gegevens. Uit deze gegevens wordt afgeleid welke software er 'zou moeten' bestaan in de organisatie. Indien het aankopen van software decentraal is georganiseerd, kan het nog wel eens lastig zijn de juiste informatie te krijgen van alle departementen. Ook de verschillende formaten en interpretatie van de aankoopgegevens veroorzaken problemen.
software inventarisatie
Het handmatig of geautomatiseerd inventariseren van geïnstalleerde software op alle hardware systemen. Deze gegevens geven weer welke software er daadwerkelijk geïnstalleerd is.
licentie beheer
Licenties zijn de koppeling tussen aankopen en daadwerkelijke installaties. Uit een aankoop blijkt een bepaalde licentie, die zeer diverse vormen kan aannemen. (per installatie, CPU, gebruiker, enz.) Aan deze licentie zijn de daadwerkelijke installaties te koppelen, waardoor uiteindelijk blijkt welke software zonder toestemming of zelfs illegaal wordt gebruikt.
Ook het intrekken en opnieuw uitdelen van licenties valt hieronder.
aanleveren van software
Het installeren en toegankelijk maken van de software voor de eindgebruiker.
toewijzen/kosten verrekening
Een IT organisatie berekent (intern of extern) de kosten door aan de afnemende organisatie. Kosten bestaan uit software licenties, maar ook begrote kosten voor de helpdesk of technische werkzaamheden.
Kijkend naar de processen uit Cobit en de controls uit ISO/IEC 27002, zijn processen als patch management en configuratie management sterk gerelateerd of zelfs afhankelijk van software asset management. Configuraties behoren bij software assets, dezelfde assets kunnen ook beveiligingslekken bevatten waarvoor patches worden uitgebracht. Het beheer van software assets houd dus veel meer in dan alleen licenties bijhouden. Bijvoorbeeld: wie is systeem eigenaar? Wie is verantwoordelijk voor de veiligheid van de software? Wie controleert of de aankopen van software pakketten voldoen aan de security requirements die door de organisatie gesteld zijn? Deze zaken zijn niet triviaal te ondersteunen met de tools en bijbehorende documentatie. Vaak zijn dit losse producten die delen van de processen ondersteunen. Technisch zal het vast wel aan elkaar te koppelen zijn, wat nog niet betekent dat een organisatie het goed weet in te bedden in alle processen.
Links
www.iaitam.org - International Association of Information Technology Asset Managers
16.3.08
Net aangekomen...
Na in het verleden meedere malen met koffers door Schiphol gerend te hebben, ben ik voor deze trip maar eens extra optijd vertrokken. Achteraf maar goed ook, want mijn taxi naar het centraal station heeft zich vannacht frontaal in de zijkant van een Opel Astra geboord. De vrouwelijke bestuurster vloog met een noodgang, zonder te kijken, het kruispunt over en negeerde de haaientanden. De taxibestuurder maakte ondanks een snelle rem-reflex geen schijn van kans. De Opel draaide een volle cirkel met 2 wielen hoog in de lucht en kwam verderop tegen een paal tot stilstand. Gelukkig heeft niemand letsel opgelopen. Maar, als mevrouw een fractie van een seconde later had overgestoken, had ze met volle snelheid in mijn portier gezeten...
Uiteindelijk heb ik met een andere taxi mijn reis kunnen vervolgen. De vlucht was comfortabel en verliep zonder vertragingen; complimenten voor Delta Airlines. Op de vlucht reeds uitgebreid gesproken met Novell medewerkers, ze zijn erg herkenbaar: groene T-shirts, veel gadgets en laptops met linux/openoffice.
Uiteindelijk heb ik met een andere taxi mijn reis kunnen vervolgen. De vlucht was comfortabel en verliep zonder vertragingen; complimenten voor Delta Airlines. Op de vlucht reeds uitgebreid gesproken met Novell medewerkers, ze zijn erg herkenbaar: groene T-shirts, veel gadgets en laptops met linux/openoffice.
Abonneren op:
Posts (Atom)
