1 IDM bij Achmea PVIB – presentatie rollenbeheer in praktijk.

Presentatie over: "1 IDM bij Achmea PVIB – presentatie rollenbeheer in praktijk."— Transcript van de presentatie:

1 1 IDM bij Achmea PVIB – presentatie rollenbeheer in praktijk

2 2 Agenda 1.Welke zaken komen er kijken bij rollen 2.Functiescheiding in rollen 3.Beheer van rollen

3 3 Medewerker Procesrol OU-rol: -Achmea -Divisie -Afdeling Projectrol Act Aut Act Aut Specialrol Autorisatie groepen OU Act Aut Act Aut Act Aut Act Aut Act Aut Act Aut Proc Proj Spec Activiteiten

4 4 Architectuur en ontwerp principes Architectuurprincipes EnterpriseArchitectuur Ontwerpprincipes Ontwerp

5 5 Beveiliging beveiliging integriteit, vertrouwelijkheid Processen beheren van integratieprocessen en bedrijfsprocessen Systeem management beheer van applicaties Integratie integratie tussen applicaties Presentatie interactie met gebruikers Management Informatie datawarehousing en analyse Domein beheer van bedrijfslogica en gegevens

6 6 Autorisaties zijn gebaseerd op rollen Motivatie  Een rolgebaseerd autorisatiemodel is beter bestand tegen organisatie- wijzigingen  Gebruikers met dezelfde rol hebben doorgaans dezelfde autorisaties, daarom zijn autorisaties efficiënter te beheren  Rolgebaseerde autorisaties spreken meer tot de verbeelding van eindgebruikers en het management Implicaties  Decentrale autorisatiegegevens worden gesynchoniseerd met een op RBAC gebaseerde centrale rollenadminstratie  Pakketapplicaties moeten ook gebruik kunnen maken van deze centrale rollenadministratie  Ieder organisatie-onderdeel brengt zijn autorisatielandschap in kaart gebaseerd op rollen  Rollen ziin gerelateerd aan werkzaamheden en niet aan het gebruik van specifieke applicaties:  Fout is: Visio_gebruiker  Goed is: Business_architect Beveiliging/Richtlijnen SRA 3.0 Architectuurprincipes

7 7 Inrichtingsprincipes OU rollen Achmea ou-rol zo breed mogelijk inzetten. Rollen zijn applicatie onafhankelijk Rollen zijn onafhankelijk van de organisatie Directory - structuur is zo eenvoudig mogelijk Ontwerpprincipes

8 8 Inrichtingsprincipes Procesrollen Procesrollen zijn gebaseerd op taken van bedrijfsprocessen Rollen zijn zoveel mogelijk gebaseerd op businesstaken Toepassen van informatiescheiding naar deelgebieden Functiescheiding is geborgd in procesrollen Procuratierollen zijn proces rollen Aan procesrollen worden waar nodig opleidingseisen verbonden De eigenaar bepaalt toegang tot de applicatie Ongestructureerde rollen zijn niet toegestaan in productie Aantal rollen minimaliseren Ontwerpprincipes

9 9 Rollen zijn gebaseerd op business activiteiten niet op HR - functies Activiteiten Rollen Schade afhandeling Claim behandelaar Schade afhandeling Schade afhandeling AutoverzekeringInboedelverzekeringReisverzekering

10 10 Schade behandelaar Schade fiatteur Raadplegen Polis Gegevens Muteren schade gegevens Vaststellen Schadebedrag Fiatteren Schadebedrag ActiviteitenProces - Rol Functie/ Bevoegdheid Schade- behandelaar Schade-fiatteur Mutatie-bevoegdJaNee Controle bevoegdNeeJa AuditNee Type / ActiviteitUitvoerendControlerend Muteren schadegegevens JaNee Vaststellen schadebedrag JaNee Raadplegen polisgegevens Nee Fiatteren schadebedragNeeJa Vastleggingen Deze scheiding is alleen van toepassing op het muteren en controleren van hetzelfde dossier. Kruislings muteren en controleren is toegestaan, mits de applicatie dat middels application controls afdwingt.

11 11 Agendapunt 2 Functiescheiding in rollen ROL

12 12

13 13 Business processen Regelset Competentie matrix Functie/ Taken matrix Opleidings eisen Rol- gebaseerde functies Taken Procuratie eisen Procuratie Profielen Activiteiten Finance Functiescheidingscriteria + Rollen Taken

14 14 Discussiepunten Procuratie Als rol of als tabel eigenschap Finance kolom verantwoordelijk of DIM? Als principe voor IDM voorlopig achterwege laten maar later toevoegen mogelijk beginnen met registratieve werkelijkheid

15 15 Discussiepunten Is functiescheiding nog wel belangrijk? Straight through processing, menselijk handelen verminderd. Steunen op application controls meer dan op functiescheiding. Principe wordt dan, daar waar nog functiescheiding relevant is moet dat correct worden geregeld, maar liefst op hoofdlijnen en niet op uitgebreide Starreveld constructies.

16 16 Agendapunt 3 : Beheer van rollen

17 17 Borgen in veranderingsprocessen Bij Achmea geborgd in Project Start Architectuur Door middel van template En keuze schema (belastingdienst achtige keuze flow)

18 18 Strategie Business Informatie Plannen Business (Divisies)

19 19 Geïdentificeerde rollen Rolinhoud en Activiteiten Activiteiten / technische profielen Producten en Diensten conform ATA. Voor rollenbeheer hoeft Hier niets te worden beschreven Bij aanpassingen van processen en organisatie zijn aanpassingen in de rollen noodzakelijk. Hier dienen de nieuwe rollen dan wel de aangepaste rollen te worden weergegeven. In de applicaties wordt nieuwe / aangepaste functionaliteit Beschikbaar gesteld, dit betekent dat er aanpassingen in de Activiteiten moet worden gemodelleerd. Als er vanuit P&O nieuwe Rollen / aangepaste rollen noodzakelijk zijn, dienen die rollen hier Inhoudelijk te worden beschreven. Dit conform de ATA principes. In de infrastructuur dienen de Functionele activiteiten vertaald te worden naar technische Profielen, In de PSA dient dit punt geadresseerd te worden. In de projectplannen dient dit verder uitgewerkt te worden.

20 20 Als de organisatie of een bedrijfsproces wordt gewijzigd kan dat iets betekenen voor de gedefinieerde rollen. Bijgaand schema geeft aan hoe de roldefinities hierop kunnen worden aangepast. - Sheet stroomschema begeleiding rolaanpassing - Tabel “Rolaanpassingen op basis van wijzigingen in de organisatie of bedrijfsprocessen”. Deze tabel kan worden ingevuld en opgenomen in par. 9.6.

21 21 Zijn er nieuwe rollen geïdentificeerd? Nee Ja Zijn dit rollen conform ATA? Ja Nee Uitzonderingsprocedure Roldefinitie(s) Beschrijf roldefinities conform Ata principes Zijn er rollen geïdentificeerd die aanpassing behoeven? Nee Ja Trigger nieuwe / aangepaste rollen vanuit aanpassingen in de organisatie of bedrijfsprocessen Geen verdere actie

22 22

23 23 Als de applicatie wordt aangepast kan dat op twee manieren iets betekenen voor de gedefinieerde rollen. Bestaande functionaliteit is aangepast, de rollen dienen daarop te worden aangepast. In het eerste schema hierna wordt deze aanpassing begeleidt. Er is nieuwe functionaliteit toegevoegd, ook hierop dienen de rollen daarop te worden aangepast, zij het met een iets ander schema, in het tweede schema hierna wordt deze aanpassing begeleidt. Zie bijgaand: - Begeleidingsschema rolaanpassing bestaande functionaliteit - Begeleidingsschema rolaanpassing nieuwe functionaliteit - Deze tabel kan worden vervolgens worden ingevuld en worden opgenomen in par. 9.7.

24 24 Zijn er nieuwe roldefinities voor kandidaat rollen? Nee Ja Zijn de geleverde roldefinities toereikend?. Nee Ja Vul roltemplate in Beschrijf activiteiten conform rolarchitectuur Ontbreken er activiteiten Nee Ja Ontbreekt er context? Nee Ja Context vanuit Processen en organisatie verduidelijken Herstelactie vanuit Program board Trigger nieuwe / aangepaste roldefinities vanuit aanpassingen in de applicatie Geen verdere actie

25 25 Is er nieuwe functionaliteit toegevoegd? Nee Ja Is er impact op de rollen Nee Ja Vul roltemplate in Beschrijf activiteiten conform rolarchitectuur Ontbreken er activiteiten Nee Ja Ontbreekt er context? Nee Ja Context vanuit Processen en organisatie verduidelijken Herstelactie vanuit Program board Trigger nieuwe functionaliteit in applicaties Geen verdere actie

26 26

27 27

28 28 Rollen zijn opgebouwd uit activiteiten Motivatie  Rollen dienen gemodelleerd te zijn naar logische taken uit bedrijfsprocessen. Implicaties  Activiteiten bevatten applicatie afhankelijke autorisaties  Rollen bevatten geen applicatie afhankelijkheden Beveiliging/Richtlijnen SRA 3.0

29 29 Rollen zijn onafhankelijk van organisatie en applicaties Motivatie  Wijzigingen in de organisatie kunnen snel worden doorgevoerd.  Taakuitvoering en niet de applicatie ondersteuning is onderscheidend voor een rol Implicaties  Rollen zijn afhankelijk van processen  De algemene Achmea rol geeft recht op alle standaard Achmea voorzieningen  Directory indeling op basis van proces en geen organisatie indeling RFC 5-2009 Beveiliging/Richtlijnen

30 30 Het aantal rollen dient beperkt te blijven Motivatie  Transparant beheer waarborgen  Bedrijfsprocessen kennen een beperkt aantal taken op basis waarvan rollen gemaakt worden.  Complexe taken kunnen beter in meerdere rollen verdeeld worden. Criterium hier is een duidelijk herkenbare eenheid van werk. Implicaties  Aantal speciale rollen moet beperkt zijn  Goed ontworpen bedrijfsprocessen leveren goed herkenbare eenheden van werk. RFC 5-2009 Beveiliging/Richtlijnen

31 31 De domein eigenaar bepaalt de toegang tot de applicatie Motivatie  De domeineigenaar is verantwoordelijk voor het correcte gebruik van de applicatie en de daarmee gerealiseerde gegevensverwerking. Daarmee dient de domeineigenaar ook bepalend te zijn wie welke rol toebedeeld krijgt. Implicaties  Een domeineigenaar mag ervan uit gaan dat een aanvraag vanuit een ander domein correct is.  Bij domeinoverstijgende aanvragen dient goedkeuring te worden gegeven vanuit zowel het aanvragende domein als het eigenaarsdomein. RFC 5-2009 Beveiliging/Richtlijnen De formulering loopt niet helemaal lekker, maar de bedoeling is dat die aansluit op het vorige statement.

32 32 Rollen bevatten geen functiescheidingsconflicten Motivatie  Het realiseren van een heldere functiescheiding is een hoofddoel van autorisatiebeheer. Gebruikers met dezelfde rol hebben doorgaans dezelfde autorisaties, daarom zijn autorisaties efficiënter te beheren  Bij het toewijzen van meerdere rollen aan een persoon wordt door het systeem gecontroleerd of het samenstel van activiteiten geen functiescheidingsconflict oplevert.  Functiescheidingscriteria worden ontleend aan businessprocessen. Implicaties  Een rol is een eenheid van werk die in zichzelf niet conflicterend mag zijn.  Een activiteit is een eenheid van werk die in zichzelf niet conflicterend mag zijn.  Het samenstellen van een rol uit activiteiten bevat de controle op functiescheiding.  Activiteiten bevatten functiescheidingscriteria op basis waarvan geautomatiseerde controle mogelijk is.  Functiecriteria zijn behalve scheiding in opvoerende en controlerende handelingen ook procuratierechten en opleidingseisen Beveiliging/Richtlijnen SRA 3.0

33 33 Rollenbeheer dient ingeregeld te zijn Motivatie  Het up to date houden van rollen en activiteiten is vanuit wet- en regelgeving verplicht  Taakuitvoering door medewerkers kan alleen optimaal plaatsvinden als de rollen en/of activiteiten goed aansluiten bij taken die gedefineerd zijn in de businessprocessen. Implicaties  Verandering van bedrijfsprocessen dienen te resulteren in verandering van rollen  De ISM ziet toe op de naleving van de inrichtingsprincipes  Aanpassen van opleidings-, procuratie- en functiescheidingseisen in de businessprocessen dienen te resulteren in aanpassing van de rollen en/of activiteiten Beveiliging/Richtlijnen SRA 3.0

34 34 Rollen en autorisaties

35 35 Kritische onderdelen in bedrijfsprocessen Bedrijfsprocessen Risico Analyse Organisatie Afdeling in SAP-HCM Medewerker in SAP-HCM Takenpakket Functiescheiding- regels (Business Rules) Functie Organisatorisch autorisatiematrix Autorisaties in IDM systeem Activiteiten in IDM systeem Quality Control HR- Mgr Business Technische profielen in Access control programma’s gelinked aan applicaties Transacties in Applicaties Technish Beheer Informatie- systemen Schema verantwoordelijken LTB en functiescheiding(controle) GISO v. 0.4 21-01-2009 Proces Control Competentie- tabel Opleidingseisen Userid Medewerker Afd. Mgr Rol Procuratie Finance & Control Bedrijfsprocessen Risicoanalyse Procu- ratie Afdeling Controle HRM Rollen beheer Functioneel beheer User Administration Met dank aan Bart Pekel, Syntrus Achmea