MCTL - Managing Computer Technology Library

Transcriptie

1 9. TAAKGEBIED SECURITY Security wordt alom gezien als een gebied dat de nodige aandacht vergt, met name op het operationele vlak. Deze operationele activiteiten worden in dit taakgebied beschreven. Wijzigingen in computertechnologie leiden soms ook tot consequenties op het gebied van beveiliging. Deze consequenties worden bij de wijziging zelf verwerkt en zijn binnen MCTL daarom te vinden binnen het taakcluster Change control. Binnen security als totaal vakgebied dient ook aandacht te zijn voor zaken als het veiligstellen van gegevens via back-ups, mirroring, dubbele locaties etc. Deze aspecten worden echter door de infra en applicatie support en evt. leveranciers voor hun rekening genomen en worden in dit taakgebied daarom verder buiten beschouwing gelaten. ACHTERGROND Vanuit gebruiksoptiek gezien moet iemand precies zoveel autorisaties krijgen als nodig is voor het uit te voeren werk. Tegenwoordig wordt vaak een op rollen gebaseerde manier van werken toegepast, waarbij iemand in een bepaalde functie één of meerdere rollen vervult. Maar ook komt voor dat een medewerker die een nieuwe functie krijgt, via infra, applicatie of functioneel support dezelfde autorisaties krijgt toegewezen als degene die die functie ook al heeft. Die laatste manier van werken kan ertoe leiden dat allerlei extra autorisaties onterecht worden toegekend, en vaak blijven de autorisaties van de vorige functie ook bestaan. Dit is dus niet bepaald een juiste wijze om met security om te gaan. Schematisch is de problematiek samen te vatten in dit schema: Een persoon kan conform dit schema voor meerdere logische componenten, gegevenssets en hardwarecomponenten geautoriseerd zijn, en andersom kunnen logische componenten, gegevenssets en hardwarecomponenten voor meer personen ter beschikking staan. Omdat het aantal personen en het aantal logische componenten, gegevenssets en hardwarecomponenten doorgaans aanzienlijk is, ontstaan al snel heel veel individuele m:n relaties, die zeer moeilijk te beheren zijn. In de praktijk wordt daarom aan beide zijden een bundeling toegepast die schematisch als volgt is weer te geven: V1.0 Pagina 1

2 Of nog verder: Hoe sterker de bundeling aan de linker- en rechterzijde, hoe eenvoudiger het beheer, maar ook hoe groter de kans op uitzonderingen. Dat is ook in de praktijk te zien: een indeling van de autorisaties gebaseerd op RBAC (Role Based Access Control) eindigt in de praktijk nogal eens in geworstel met de uitzonderingen op deze indeling. Ook in een autorisatiematrix is een dergelijk effect te zien: ofwel de matrix heeft een dusdanig abstractieniveau dat niet onbelangrijke details allemaal zijn weggelaten en het praktisch nut dus niet hoog is. Ofwel het detailleringsniveau is wel in orde, maar het is een onhandelbaar geheel geworden. Binnen MCTL wordt security vanzelfsprekend vanuit bedrijfsoptiek aangevlogen. De opbouw van een bedrijf kan schematisch als volgt worden samengevat: V1.0 Pagina 2

3 Toelichting (van onder naar boven): 1. "De wereld" Ook wel Public niveau genoemd. Op dit niveau is alles te vinden wat voor iedereen altijd toegankelijk is. Een voorbeeld hiervan is een website. Hierbij kan een nuance nog wel zijn dat bijvoorbeeld voor bepaalde gebieden in de wereld bepaalde delen van de website niet of anders moeten worden getoond (andere taal, maar ook i.v.m. wettelijke bepalingen). Of dat wordt geëist dat voor toegang tot bepaalde delen van een website een account nodig is. Dergelijke vereisten zijn echter niet te herleiden tot een specifiek persoon. Op een website zijn voor iedereen bijvoorbeeld een aantal algemene financiële kerncijfers van het bedrijf te vinden. 2. Bedrijf Op bedrijfsniveau is alles te vinden wat iedereen binnen het hele bedrijf mag gebruiken, maar niemand buiten het bedrijf. Voorbeelden hiervan zijn een tijdregistratiesysteem of het intranet. Ook kunnen hier bijvoorbeeld (financiële) gegevens van diverse bedrijfsonderdelen worden geplaatst die alleen voor intern gebruik zijn. 3. Business unit Op business unit niveau is alles te vinden wat binnen deze business unit benodigd is. Er is een directe relatie met de bedrijfsprocessen die binnen deze business unit worden uitgevoerd. Een voorbeeld is de financiële administratie, waarbij alle software en gegevens rondom het verwerken van financiële gegevens alleen toegankelijk zijn voor medewerkers van deze business unit. Het kan voorkomen dat bepaalde functies / data door meerdere business units mogen worden gebruikt. Bijvoorbeeld het inzien van financiële gegevens kan ook mogelijk zijn voor andere business units (en daarbinnen specifiek voor medewerkers met een bepaalde functie / rol). 4. Functie Het vierde niveau is dat van functie. Op basis van een bepaalde functie moeten bepaalde werkzaamheden kunnen worden uitgevoerd en de bijbehorende functionaliteiten toegankelijk zijn. Omdat functies tamelijk statisch zijn, wordt ook wel gebruik gemaakt van rollen. Een rol omvat dan bepaalde taken met de bijbehorende autorisaties. Tussen functies en rollen bestaat een n:m relatie; binnen elke functie kunnen meerdere rollen worden uitgevoerd, en een rol kan bij meerdere functies thuishoren. Binnen een rol kan bijvoorbeeld worden toegestaan dat een factuur wordt goedgekeurd. 5. Persoon Tot slot kunnen activiteiten en autorisaties persoonsafhankelijk zijn. Een voorbeeld is bijv. een persoonlijk adres of een stukje ruimte op een server om gegevens op te slaan. Een ander voorbeeld is dat verkopers gezamenlijk gebruik maken van een klantendatabase, maar een verkoper alleen de gegevens van zijn "eigen" klanten mag aanpassen. Binnen deze systematiek wordt gebruik gemaakt van overerving: indien een persoon een bepaalde functie in een bepaalde business unit in een bepaald bedrijf heeft, dan mag deze persoon alles wat bij V1.0 Pagina 3

4 de persoon hoort, bij de bepaalde functie, bij de bepaalde business unit en bij het bepaalde bedrijf. Aldus ontstaat de rode kolom in het volgende schema: Op basis van een bepaalde positie kan iemand aldus autorisaties toebedeeld krijgen. Deze autorisaties zijn te verdelen over: 1. Toegang tot fysieke apparatuur (Wanneer en waar is bepaalde apparatuur beschikbaar?) Niet alles hoeft op elk apparaat beschikbaar te zijn, en uit beveiligingsoogpunt kan fysieke toegang worden beperkt. De verwachting van gebruikers is langzamerhand dat alles op elke plek op elk moment gedaan kan worden. Uit oogpunt van beveiliging kunnen hier zeker beperkingen aan worden gesteld. Daarnaast kan het ook nog zo zijn, dat vanwege de omvang van gegevensbestanden (denk bijvoorbeeld aan bouwtekeningen, ruwe onderzoeksdata of gedetailleerde weergegevens) deze niet overal ter beschikking kunnen worden gesteld. Hoewel dit laatste niet direct een beveiligingsissue is, kan het de invulling van de beveiligingsmaatregelen wel beïnvloeden 2. Toegang tot logica / functionaliteiten, welke met name door software wordt ingevuld (Wanneer en waar kan iemand met bepaalde logica / functionaliteiten werken) Logica / functionaliteiten die iemand mag gebruiken hoeven niet altijd ter beschikking te staan. Bijvoorbeeld het doen van financiële transacties kan zijn beperkt of afgesloten indien iemand niet in een "vertrouwde" omgeving is, bijv. in de trein 3. Toegang tot bepaalde gegevens (Wanneer en waar staan iemand bepaalde gegevens ter beschikking). Bijv. kan iemand recht hebben op het aanbrengen van mutaties in een klantenbestand. Maar dan alleen van de "eigen" klanten, en niet van de collega's. TERMEN Functie De term functie heeft verschillende betekenissen: 1. Een functie is een toepassing gerealiseerd door computertechnologie (met name software) V1.0 Pagina 4

5 2. Een functie is een samenhangend pakket van taken, bevoegdheden en verantwoordelijkheden, dat wordt uitgeoefend door een persoon 3. Een functie is een team of groep mensen die een of meer processen of activiteiten uitvoert (definitie conform ITIL), bijvoorbeeld een Service Desk. Binnen MCTL wordt voor de term functie de tweede definitie gebruikt. Account Een account is een persoonlijk profiel met een inlogcode. Elke gebruiker heeft in principe maar één account. Aan dit account zijn persoonlijke zaken gekoppeld zoals toegang tot een eigen box en social media. Het account is ook gekoppeld aan een functie en aan de rol(len) die die persoon vervult. Rol Een rol omvat een aantal samenhangende activiteiten die door een medewerker kunnen worden uitgevoerd. Een rol is niet vast verbonden aan een medewerker of functie: een medewerker kan één rol tegelijkertijd vervullen, maar ook 0 of juist meerdere rollen. In de loop van de tijd kan een medewerker achtereenvolgens meerdere rollen vervullen, terwijl de functie van de medewerker niet wijzigt. Deze manier van omgaan met rollen zorgt ervoor dat medewerkers met redelijk statische functies toch geheel verschillende werkzaamheden kunnen uitvoeren zonder de structuur en samenhang van de security te verliezen. DOEL VAN DIT TAAKGEBIED Het taakgebied security zorgt ervoor dat de beveiliging van alle computertechnologie, inclusief de opgeslagen gegevens, aantoonbaar van voldoende niveau is. Er worden conform het beveiligingsbeleid autorisaties aan medewerkers verleend en indien nodig aanpassingen aan autorisaties van medewerkers uitgevoerd, er vindt bewaking plaats op schendingen van de beveiliging of pogingen daartoe en daarop wordt actie ondernomen. Periodiek wordt de status van de operationele beveiliging gecontroleerd en gerapporteerd. Indien gewenst kan op aanvraag ook een specifieke rapportage op het gebied van security worden samengesteld. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel is bereikt: De security is zodanig dat enerzijds het bedrijfsbeleid is ingevuld en dat anderzijds niemand (sterk) gehinderd wordt in de uitvoering van het werk Security is waar mogelijk onzichtbaar Een aantal indicatoren die hiervoor als basis kunnen dienen: Totaal aantal accounts versus aantal medewerkers Groei / daling aantal accounts versus groei / daling aantal medewerkers (inclusief uitzendkrachten, ZZP'ers) Aantal niet gebruikte accounts (in periode) Uitkomsten externe audits Werkelijk security niveau versus gewenste niveau V1.0 Pagina 5

6 Aantal incidenten van misbruik van gegevens / security schendingen INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn de navolgende: 1. Uitgifte, wijziging en verwijderen van accounts 2. Reset /deblokkering van een password 3. Uitgifte van rollen en wijziging / intrekken van toegekende rollen 4. Aanmaken van periodieke overzichten (security gerelateerd) 5. Aanmaken van ad-hoc overzichten (security gerelateerd) N.B. Het creëren of wijzigen van een rol is een wijziging, en wordt via Change control opgepakt. Een gedetailleerde uitwerking van de activiteiten volgt hieronder in de vorm van diverse flows, zodat direct de verschillende acties en volgorde van die acties zijn te zien. 1. Flow voor de uitgifte, wijziging en verwijderen van accounts De flow waarin de te ondernemen acties zijn opgenomen om een account uit te geven, te wijzigen of verwijderen ziet er als volgt uit: Input De input is een aanvraag voor de uitgifte, wijziging of intrekking van een of meerdere accounts. Activiteiten De activiteiten zijn achtereenvolgens: V1.0 Pagina 6

7 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd. Vervolgens vindt controle plaats: is de aanvraag juist, volledig en toegestaan? Redenen van afwijzing zijn onder andere: een verkeerde indiener, reeds account aanwezig, conflict met andere account of onvolledige informatie. Een aanvraag kan gekoppeld zijn met het HRM-systeem waarbij bij invoer / wijziging / verwijdering van gegevens in het HRM-systeem ook meteen een aanvraag voor het invoeren / wijzigen / verwijderen van een account wordt gedaan. Dit is echter niet geheel dekkend: uitzendkrachten en ZZP'ers worden niet via HRM geregistreerd, maar hebben wel een account nodig. Bovendien hoeft de geldigheidsduur van een account niet gelijk te lopen met het dienstverband. 2. Eventueel verwijderen oude account(s) Wanneer moet een oude account worden verwijderd? Onder andere in de volgende situaties: i. Indien een medewerker zodanig van functie wijzigt dat het oude account niet meer nodig is ii. Indien een medewerker uit dienst treedt iii. Indien een uitzendkracht of ZZP'er het einde van de werkzaamheden heeft bereikt Een account kan vaak niet direct fysiek worden verwijderd omdat er bijvoorbeeld een box aan is gekoppeld, die gedurende zekere tijd wordt geherrouteerd. Of omdat mutaties zijn gekoppeld aan het account, waarbij na verwijdering van het account ook niet meer terug is te vinden wie de mutaties heeft gedaan. Indien fysieke verwijdering niet direct mogelijk is, dan moet het account worden gedisabled, met een datum waarop wel fysieke verwijdering zal plaatsvinden (dit kan soms jaren zijn; gekoppeld aan de maximale bewaartermijn van gegevens en logging). 3. Eventueel toekennen nieuwe account(s), wijzigen account Indien alleen accounts moesten worden beëindigd, dan kan deze stap worden overgeslagen. Anders worden hier een of meer nieuwe accounts aangemaakt of bestaande aangepast (bijv. een naamswijziging). Door de aanvrager en medewerker zelf wordt gecontroleerd of een en ander in orde is. De aanvrager wordt geïnformeerd en indien vereist vindt decharge plaats. 4. Nazorg Check het werkelijk gebruik van het nieuwe account en ook of nog getracht is een oud account te gebruiken. Neem na enige dagen contact op of er nog vragen / wensen / problemen zijn. Output De output wordt gevormd door juiste, nieuwe accounts, juist uitgevoerde wijzigingen in accounts en verwijderde / gedisabelde oude accounts. De flow voor het omgaan met accounts is voor een groot deel te automatiseren; toch blijken in de praktijk handmatige acties nodig vanwege met name systeembeperkingen. Voor sommige software zijn accountinstellingen nodig die niet of alleen tegen heel hoge kosten geautomatiseerd kunnen worden ingesteld vanuit een ander systeem (van waaruit alle accounts worden beheerd). 2. Flow voor de reset /deblokkering van een password Het kan voorkomen dat een gebruiker een password is vergeten of meer dan x maal verkeerd heeft ingetypt. Steeds meer bedrijven hebben dit opgelost door middel van selfservice, waarbij op een veilige manier, inclusief checks, de gebruiker zelf zijn password kan resetten / deblokkeren. Indien dit V1.0 Pagina 7

8 niet mogelijk of niet gewenst is, dan is het mogelijk functioneel support via onderstaande schema ondersteuning te laten verlenen. Input De input is een aanvraag voor resetten van een password Activiteiten De activiteiten zijn achtereenvolgens: 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd en er wordt een check uitgevoerd of het inderdaad de juiste persoon is. Afhankelijk van de organisatie gaat dit wat meer informeel (indien je in persoon verschijnt, is het al goed, het is alleen niet toegestaan voor anderen een password-reset aan te vragen) tot zeer formeel (je moet met paspoort of ander identiteitsbewijs en je personeelspas verschijnen). Ook wordt gecheckt of een password reset / deblokkering al vaker is aangevraagd. Indien reeds buitengewoon veel password resets / deblokkeringen zijn aangevraagd, dan wordt de reden daarvan nagevraagd en eventueel actie ondernomen (via taakgebied Educatie in dit taakcluster, ofwel via een verzoek tot aanpassing van het systeem via taakcluster Change control). 2. Resetten password Het password wordt gereset. Ook bij deblokkering wordt een nieuw wachtwoord gegenereerd. De eenmalige code wordt meegegeven, of ter plaatse moet de medewerker inloggen en zelf direct een nieuw password kiezen. Indien een en ander telefonisch wordt afgehandeld, wordt nadat er is gebeld teruggebeld naar een vooraf in het systeem vastgelegd telefoonnummer. Op deze manier worden onjuiste / ongeoorloofde resets voorkomen. 3. Nazorg Eventueel wordt later nagevraagd of er nog obstakels zijn. Ook kunnen tips worden gegeven hoe een goed password te kiezen, dat toch makkelijk te onthouden is. Output De output wordt gevormd door een gereset password. V1.0 Pagina 8

9 3. Flow voor de uitgifte van rollen en wijziging / intrekken van toegekende rollen NB: het creëren van een nieuwe rol of het inhoudelijk aanpassen van een rol vindt plaats via Change control. Het gaat hier dus uitsluitend om de uitgifte van bestaande rollen, het intrekken van uitgegeven rollen of het wijzigen van de toekenning van een rol (bijv. de termijn waarbinnen deze rol aan een bepaald persoon is toegewezen). Het schema waarin de te ondernemen acties zijn weergegeven ziet er als volgt uit: Input De input is een aanvraag voor het intrekken, een wijziging of intrekking van een of meerdere rollen voor een account. Activiteiten De activiteiten zijn achtereenvolgens: 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd. Vervolgens vindt controle plaats: is de aanvraag juist, volledig en toegestaan? Redenen van afwijzing zijn onder andere: een verkeerde indiener, conflict met andere reeds uitgegeven rol voor het account (i.v.m. vereiste functiescheiding) of onvolledige informatie. 2. Eventueel intrekken toegekende rol(len) Elke keer wanneer om het toekennen van een nieuwe rol wordt gevraagd, is het geen gekke reflex om meteen te checken welke rol(len) tegelijkertijd moet worden ingetrokken. Maar al te vaak worden voortdurend rollen uitgegeven, maar vrijwel geen rollen ingetrokken. Vanuit gebruikers gezien is een en ander begrijpelijk: hoe meer rollen, hoe minder kans op belemmering in de uitvoering van het werk. Maar vanuit het oogpunt van security is dit absoluut een ongewenste gang van zaken. Rollen moeten ook kunnen worden ingetrokken op een bepaalde datum die al eerder in het systeem is gezet. 3. Eventueel uitgifte rol(len), wijzigen rol(len) Indien alleen een uitgegeven rol moet worden ingetrokken, dan kan deze stap worden overgeslagen. Anders worden hier een of meer nieuw rollen uitgegeven (gekoppeld aan een account) of reeds V1.0 Pagina 9

10 bestaande uitgegeven rol(len) gewijzigd. Let op: dit is geen inhoudelijke wijziging van de rol, dat is immers een wijziging die wordt afgehandeld in Change control. De wijziging die hier wordt bedoeld is bijvoorbeeld de verlenging van de termijn waarover de rol is uitgegeven. Door de medewerker zelf wordt gecontroleerd of een en ander in orde is. De aanvrager wordt geïnformeerd en indien vereist vindt decharge plaats. Een rol moet ook tijdelijk kunnen worden toegekend, bijv. ivm vervanging van een collega, functieovergang, tijdelijk geen werk in eigen rol, etc. Daarmee wordt voorkomen dat werknemers elkaars account gaan gebruiken, wat natuurlijk uit den boze is. Bij de uitgifte van een rol kan het zijn dat er aanvullende vereisten gelden, zoals bijvoorbeeld educatie of een aantoonbaar vaardigheidsniveau. 4. Nazorg Check het werkelijk gebruik van de nieuwe rol, en ook of nog getracht is bevoegdheden van een oude rol te gebruiken. Neem na enige dagen contact op of er nog vragen / wensen / problemen zijn. Output De output wordt gevormd door juiste nieuw uitgegeven rollen, juist uitgevoerde wijzigingen in toegekende rollen en ingetrokken rollen. 4. Flow voor het aanmaken van periodieke overzichten (security gerelateerd) In deze flow wordt uitgewerkt hoe periodieke overzichten op het gebied van security tot stand komen: Input Vanwege het periodieke karakter van deze activiteit is er geen externe trigger als input nodig. Activiteiten De activiteiten zijn achtereenvolgens: 1. Initiatie Overzichten moeten worden geïnitieerd. Voorbeelden van overzichten zijn: V1.0 Pagina 10

11 Het wekelijks of maandelijks samenstellen van overzichten met accounts / rollen per systeem / afdeling / business unit, met daarbij de nieuwe en vervallen accounts extra belicht, accounts met meer dan 2 rollen, al langere tijd ongebruikte accounts en rollen, wachtwoorden die al langere tijd niet zijn gewijzigd, etc. Het wekelijks / maandelijks samenstellen van overzichten met security schendingen Het random initiëren van overzichten met het gebruik van accounts, rollen, mogelijk misbruik etc. op dat moment. Bij random kan dan worden gedacht aan het systeem dat ook bij tassencontrole in supermarkten wordt gebruikt. Dagelijks wordt dan via een systeem aangegeven welke controle die dag moet worden uitgevoerd, en welk overzicht daarvoor nodig is. Het random karakter van deze controles is essentieel om te voorkomen dat tussen de vaste periodes van controle toch misbruik kan plaatsvinden. 2. Samenstellen overzicht Het bedoelde overzicht wordt samengesteld. Aangezien dit repeterend werk is kan hiervoor het nodige worden geautomatiseerd. 3. Verrijken overzicht Het overzicht wordt, voordat het wordt verstrekt, eerst beoordeeld en voorzien van commentaar en suggesties. In voorkomende gevallen kunnen ook dwingende aanbevelingen worden gedaan. 4. Verstrekken overzicht Het overzicht wordt verstrekt aan de belanghebbende, doorgaans de systeemeigenaar. Indien in het bedrijf een apart onderdeel (afdeling) is ingericht dat zich specifiek bezighoudt met security, dan wordt het overzicht uiteraard daar aan verstrekt. Output De output wordt gevormd door overzichten op het gebied van security. 5. Flow voor het aanmaken van ad-hoc overzichten (security gerelateerd) In deze flow wordt uitgewerkt hoe ad-hoc overzichten op het gebied van security tot stand komen: V1.0 Pagina 11

12 Input Gespecificeerde aanvraag. Activiteiten De activiteiten zijn achtereenvolgens: 1. Controle aanvraag Niet iedereen mag dergelijke overzichten aanvragen, en de informatie die in deze overzichten is terug te vinden mag ook niet overal terecht komen. Er kunnen security- en privacy-gevoelige gegevens in staan, die ook met de nodige zorg moeten worden behandeld. Met andere woorden: er wordt hier niet alleen gecontroleerd of de aanvrager wel de juiste persoon is, maar ook of de gegevens wel mogen worden geleverd. 2. Samenstellen overzicht Het bedoelde overzicht wordt samengesteld. Aangezien dit repeterend werk is kan hier het nodige aan worden geautomatiseerd. 3. Verrijken overzicht Het overzicht wordt, voordat het wordt verstrekt, eerst beoordeeld en voorzien van commentaar en suggesties. In voorkomende gevallen kunnen ook dwingende aanbevelingen worden gedaan. 4. Verstrekken overzicht Het overzicht wordt verstrekt aan de belanghebbende, doorgaans de systeemeigenaar. Indien in het bedrijf een apart onderdeel (afdeling) is ingericht dat zich specifiek bezighoudt met security, dan wordt het overzicht uiteraard daar aan verstrekt. Output De output wordt gevormd door het gevraagde ad-hoc overzicht. OPMERKINGEN V1.0 Pagina 12

13 De volgende laatste opmerkingen zijn nog te maken over het taakgebied Security. 1. AWARENESS Beveiliging kent talloze aspecten. Natuurlijk gaat het om techniek, procedures en controle, zoals hiervoor beschreven. Maar het gaat ook om awareness, zoals het netjes omgaan met passwords en gegevens niet zomaar naar een USB-stick kopiëren of op Dropbox of een soortgelijke dienst zetten. Wat enorm kan helpen om medewerkers een beter besef bij te brengen van de ernst van beveiliging en het juist gebruiken van computertechnologie, is een consequente, 100% monitoring op het gebruik van de systemen. Uit oogpunt van privacy ligt dit gevoelig, maar op het moment dat alle handelingen van alle medewerkers worden gemonitord, en ook werkelijk actie wordt ondernomen op ongewenst gedrag, kan het beveiligingsbesef sprongen vooruit maken. Alleen al het feit dat iedereen beseft dat alle handelingen later terug zijn te vinden, maakt dat al veel minder ongewenst gedrag zal plaatsvinden. Bijvoorbeeld in een overheidsorganisatie liggen persoonlijke gegevens in een database opgeslagen van bekende Nederlanders. Het is natuurlijk heel verleidelijk om daar als medewerker een kijkje in te nemen, hoewel daar vanuit het werk geen enkele aanleiding voor bestaat. Alleen al het besef dat dergelijke opvraging later is terug te vinden, en dát ze er werkelijk op zullen worden aangesproken, weerhoudt veel medewerkers ervan daadwerkelijk dergelijke gegevens op te vragen. 2. KOPPELING BEVEILIGING MET HRM-SYSTEEM Een koppeling met het HRM-systeem biedt mogelijkheden tot het automatiseren van het aanmaken en verwijderen van accounts en rollen. Hierop zijn de volgende knelpunten te noemen: 1. In een HRM-systeem staan vaak functies en geen rollen. Wordt HRM dan ook opgezadeld met het beheer van de rollen en het koppelen van de juiste functie aan de juiste rol? 2. Soms begint iemand al voor de feitelijke omzetting van de functie in een andere functie. De ingangs- en vervaldata in het HRM-systeem komen dan niet overeen met de werkelijk benodigde bevoegdheden 3. Niet alle personen die met een systeem werken staan in het HRM-systeem. Te denken is bijvoorbeeld aan uitzendkrachten of ZZP'ers, maar ook aan personen die eerder of later in de productieketen (afnemers / leveranciers) werken en bepaalde autorisaties gekoppeld aan een account nodig hebben 4. Tot slot een principieel punt: wie gaat er eigenlijk over bevoegdheden in systemen: HRM of het management van de betreffende business unit / afdeling (de systeemeigenaar met andere woorden)? 3. EXTERNE AUDITS Externe audits kunnen tot gevolg hebben dat extra overzichten worden verstrekt. Deze activiteit is hiervoor al besproken. Maar een externe audit heeft ook functioneel support zelf tot onderwerp, en dan hebben de personen werkzaam op deze afdeling natuurlijk een heel andere positie. Het is een goede zaak dat een audit zich over de gehele organisatie uitstrekt, zodat uiteindelijk niet alleen V1.0 Pagina 13

14 verbeterpunten in de gebruikersorganisatie, maar ook bij functioneel support kunnen worden gedefinieerd. Voorbeeld van het nut van een audit die zich uitstrekt tot functioneel support. In een organisatie, waarin enorm veel geld om gaat, wordt een audit uitgevoerd. Behalve kritische noten over de gebruikersorganisatie is het uiteindelijke rapport ook, tot grote verrassing van de personen werkzaam op functioneel support, bijzonder kritisch over dit organisatieonderdeel. Het grote manco blijkt te zijn dat er in de gebruikersorganisatie functiescheiding keurig is geïmplementeerd, maar dat functioneel specialisten zonder controle in de productiegegevens kunnen wijzigen, en de logging dusdanig is ingericht dat sporen vrij eenvoudig zijn weg te wissen door dezelfde personen. Functioneel specialisten zijn verder bij wijzigingen op zoveel punten betrokken dat het voor hen mogelijk blijkt in software zaken zodanig te configureren dat daardoor ongewenste situaties (lees: geld wegsluizen) kunnen worden gerealiseerd. Na bekomen te zijn van de verrassing worden de nodige verbeteringen aangebracht. Jaren later blijkt hoe nuttig deze aanpassingen zijn: er is namelijk op een zeker moment gefraudeerd. De functioneel specialisten kunnen echter aantonen dat zij dit eenvoudigweg niet gedaan kónden hebben, hoewel de vinger al snel hun kant op wees. Uiteindelijk bleek het lek in de gebruikersorganisatie te zitten waar iemand zich op slinkse wijze meerdere passwords had toegeëigend. V1.0 Pagina 14