3

Logische toegangsbeveiliging in SAP R/3. Theorie in de praktijk

Vrije Universiteit Amsterdam Postgraduate IT Audit Opleiding Eindscriptie, Oktober 2008 Rob Oldenhof

Voorwoord Toen ik begon aan de VU in Amsterdam was het schrijven van een scriptie verplicht geworden. Dit had ik graag willen vermijden, want ik ben nogal kort en bondig van stof. Daarom ben ik trots op dit resultaat. Logische toegangsbeveiliging in SAP R/3 is een onderwerp die ik in de dagelijkse praktijk tegen kom. Bedrijven vinden het een moeilijk onderwerp. Hopelijk helpt deze scriptie bij een beter inzicht in logische toegangsbeveiliging in SAP R/3. Zonder afstudeerbegeleider Bart Bokhorst en bedrijfscoach Jos de Waal had dit stuk hier zo niet gelegen. Daarom wil ik deze heren bedanken voor alle steun en opbouwende kritiek, gegeven tijdens het schrijven van deze scriptie. Ten slotte wil ik de (gast)docenten bedanken voor de leerzame colleges tijdens mijn studie. Dit alles heeft mij geholpen bij het schrijven van deze scriptie en ook bij het verbreden van mijn vakkennis op het gebied van EDP audit. Rob Oldenhof Hengelo, 2008

2

Inhoudsopgave 1. Inleiding.................................................................................................... 5

1.1 1.2 1.3 1.4

Aanleiding. ........................................................................................................... 5 Probleemstelling................................................................................................. 5 Onderzoeksaanpak. .......................................................................................... 5 Leeswijzer ............................................................................................................. 6

2. Waarom logische toegangsbeveiliging? ........................................................ 7

2.1 Wat is informatiebeveiliging?......................................................................... 7 2.2 Waarom is informatiebeveiliging nodig? .................................................... 7 2.3 De organisatie van de informatiebeveiliging ............................................. 8 2.3.1 Beleid ............................................................................................................. 8 2.3.2 Plan................................................................................................................. 8 2.3.3 Communicatie............................................................................................. 9 2.4 Wat is logische toegangsbeveiliging?......................................................... 10 2.4.1 Functiescheiding...................................................................................... 10 2.4.2 Kritische functionaliteit ......................................................................... 10 3 Hoe is logische toegangsbeveiliging geregeld in SAP R/3? ............................12

3.1 Autorisatieconcept in SAP R/3 ................................................................... 12 3.2 Role Based access ........................................................................................... 15 3.2.1. Gebruikers-ID .......................................................................................... 16 3.2.2. Samengestelde rollen ............................................................................ 16 3.2.3. Rollen en profielen ................................................................................. 17 3.2.4. Transacties ............................................................................................... 17 3.2.5. Autorisatie-objecten............................................................................... 17 3.2.6. Autorisaties............................................................................................... 17 3.3 Systeemparameters......................................................................................... 17 3.4 Systeemlandschap .......................................................................................... 17 3.5 Transportmechanisme ................................................................................... 18 4 Wat is noodzakelijk voor de inrichting van logische toegangsbeveiliging in SAP R/3? ............................................................................................................19

4.1 Autorisatiebeleid .............................................................................................. 19 4.1.1 Doel............................................................................................................... 19 4.1.2 Richtlijnen .................................................................................................. 19 4.1.3 Taken en verantwoordelijkheden............................................................ 20 4.1.4 Koppeling andere processen ................................................................ 21 4.2 Processen autorisatiebeheer ........................................................................ 21 4.2.1 Beheer gebruikers-ID’s .......................................................................... 23 4.2.2 Koppeling autorisaties aan gebruikers-ID’s.................................... 23 4.2.3. Beheer autorisaties ................................................................................ 24 4.2.4 Autorisatie aanvraagprocedure ........................................................... 25 4.2 Rapportage en controle van autorisaties ................................................. 26 5 Hoe richt je met behulp van de techniek het beheer in van logische toegangsbeveiliging in SAP R/3? ...................................................................28

5.1 Een autorisatiestructuur .............................................................................. 28 5.2 Technieken binnen SAP R/3 ....................................................................... 29 3

5.2.1 Profielgenerator ........................................................................................ 30 5.2.2 Autorisatie Infosysteem ......................................................................... 30 5.2.3 Centrale gebruikers registratie............................................................ 30 5.3 Technieken buiten SAP R/3......................................................................... 31 5.3.1 Geautomatiseerd systeem......................................................................... 31 6 Nawoord....................................................................................................32 Bijlage: I Literatuur ......................................................................................34 Bijlage: II Systeemparameter instellingen ......................................................35 Bijlage: III Codificatie formulier .....................................................................36 Bijlage: IV Autorisatiematrix .........................................................................37 Bijlage: V Raamwerk regelgeving ...................................................................38

4

1. Inleiding. 1.1 Aanleiding. Dat veel bedrijven gebruik maken van geïntegreerde Enterprise Resource Planning (ERP)systemen, zoals SAP R/3, mag als bekend worden verondersteld. Dat deze bedrijven voor hun bedrijfsvoering daarmee in hoge mate afhankelijk zijn van een dergelijk systeem, zal ook niet nieuw zijn. Sommige hebben dat ook mogen ondervinden. Naast betrouwbaarheid van het systeem wordt in dit verband ook al snel het begrip logische toegangsbeveiliging in de mond genomen. Hoe komt het dan toch dat beveiliging vaak ‘het kind van de rekening’ is en dat hier (relatief gezien) weinig tijd aan wordt besteed? Bovendien blijkt vaak dat bedrijven zelf geen tot weinig inzicht hebben in de wijze waarop de logische toegangsbeveiliging (al dan niet goed) is ingericht. Daarnaast is logische toegangsbeveiliging in het algemeen en in het bijzonder in SAP R/3 een complexe materie. Het probleem waar organisaties tegenaan lopen is dat de theorie van logische toegangscontrole niet aansluit op de praktijk in SAP R/3. Het ontbreekt aan een best practice voor logische toegangsbeveiliging van SAP R/3. Een die aansluit op de theorie en toepasbaar is in de dagelijkse praktijk van logische toegangsbeveiliging in SAP R/3.

1.2 Probleemstelling. Hoofdvraag Hoe moeten organisaties logische toegangsbeveiliging in SAP R/3 beheren en controleren? Subvragen Waarom logische toegangsbeveiliging? Hoe is logische toegangsbeveiliging geregeld in SAP R/3? Wat is noodzakelijk voor de inrichting van logische toegangsbeveiliging in SAP R/3? Hoe richt je met behulp van de techniek het beheer in van logische toegangsbeveiliging in SAP R/3?

1.3 Onderzoeksaanpak. Er zijn theoretische kaders genoeg voor logische toegangsbeveiliging, maar deze zijn niet gelijk bruikbaar in de praktijk. Deze scriptie wil een dergelijk kader Informatietechnologie - Beveiligingstechnieken - Code voor informatiebeveiliging (ISO/IEC 27002:2OO5, IDT) vertalen naar de praktijk van logische toegangsbeveiliging SAP R/3. De literatuur zal ondersteuning bieden voor de theoretische onderbouwing van de hoofdvraag. SAP R/3 dwingt logische toegangsbeveiliging af volgens een bepaald stramien. Het is niet mogelijk voor andere oplossingen te kiezen.

5

In deze scriptie wordt een best practice voor logische toegangsbeveiliging in SAP R/3 uitgewerkt.

1.4 Leeswijzer Allereerst wordt in hoofdstuk twee de vraag beantwoord wat logische toegangsbeveiliging is. In hoofdstuk drie wordt logische toegangsbeveiliging in SAP R/3 uitgelegd. In de hoofdstukken vier en vijf wordt de best practice toegepast op logische toegangsbeveiliging in SAP R/3. Waarna wordt afgesloten met een nawoord.

6

2. Waarom logische toegangsbeveiliging? Het antwoord op deze vraag wordt gehaald uit de Informatietechnologie Beveiligingstechnieken - Code voor informatiebeveiliging (ISO/IEC 27002:2OO5, IDT). Bij informatiebeveiliging worden de volgende onderwerpen behandeld. Wat is informatiebeveiliging? Waarom is informatiebeveiliging nodig? Organisatie van informatiebeveiliging Daarnaast wordt antwoord gegeven op de vraag wat logische toegangsbeveiliging inhoudt. Logische toegangsbeveiliging is ook een middel om functiescheiding te bewerkstelligen en kritische functionaliteit af te schermen.

2.1 Wat is informatiebeveiliging? Informatie is een bedrijfsmiddel, dat net als andere belangrijke bedrijfsmiddelen waarde heeft voor een organisatie en voortdurend op een geschikte manier moet zijn beschermd. Dit is vooral belangrijk in steeds nauwer verweven organisaties. Door deze toenemende verwevenheid wordt informatie nu blootgesteld aan een toenemend aantal en breder scala bedreigingen en zwakke plekken. Informatie behoort altijd op geschikte wijze te worden beschermd, ongeacht de vorm waarin de informatie bestaat of de wijze waarop deze wordt gedeeld of opgeslagen. Informatiebeveiliging is de bescherming van informatie tegen een breed scala bedreigingen om bedrijfscontinuïteit te waarborgen, bedrijfsrisico's te minimaliseren. Informatiebeveiliging wordt bereikt door een geschikte verzameling beheersmaatregelen in te zetten, waaronder beleid, werkwijzen, procedures, organisatiestructuren en programmatuur- en apparatuurfuncties. Deze beheersmaatregelen moeten worden vastgesteld, gecontroleerd, beoordeeld en waar nodig verbeterd om te waarborgen dat de specifieke beveiligings- en bedrijfsdoelstellingen van de organisatie worden bereikt. Dit behoort te worden gedaan in samenhang met andere bedrijfsbeheer processen.

2.2 Waarom is informatiebeveiliging nodig? Informatie en de ondersteunende processen, systemen en netwerken zijn belangrijke bedrijfsmiddelen. Het definiëren, bereiken, onderhouden en verbeteren van informatiebeveiliging kan van essentieel belang zijn voor het behoud van de concurrentiepositie, kasstroom, winstgevendheid, naleving van de wet en het zakelijke imago van de organisatie. Organisaties en hun informatiesystemen en netwerken worden geconfronteerd met beveiligingsrisico’s uit allerlei bronnen, waar onder menselijk onvermogen of falen, computerfraude, spionage, sabotage, vandalisme, brand en overstromingen. Oorzaken van schade zoals virussen, computer hacking en 'weigeren-vandienst'-aanvallen komen steeds vaker voor en worden steeds ambitieuzer en vernuftiger. Informatiebeveiliging is belangrijk voor ondernemingen en instanties in de publieke en private sector en voor de bescherming van vitale infrastructuur. In beide sectoren zal informatiebeveiliging functioneren als een instrument voor

7

bijvoorbeeld het realiseren van e-overheid (digitale overheid) of e-business (elektronische handel) en voor het vermijden of verminderen van de inherente risico's. De onderlinge verbondenheid van publieke en private netwerken en het delen van informatiemiddelen maken het steeds moeilijker om de toegang te beheersen. Veel informatiesystemen zijn niet ontworpen met het oog op informatiebeveiliging. De beveiliging die met technische middelen kan worden bereikt is niet zalig makend en behoort te worden ondersteund door geschikt beheer en geschikte procedures. Bepalen welke beheersmaatregelen behoren te worden ingesteld, vereist een zorgvuldige planning en aandacht voor detail. Het beheren van informatiebeveiliging vereist ten minste de aandacht van alle werknemers van de organisatie. Bovendien kan deelname van leveranciers, derden, klanten of andere externe partijen vereist zijn. Ook kan er specialistisch advies van buiten de organisatie nodig zijn.

2.3 De organisatie van de informatiebeveiliging 2.3.1 Beleid De organisatie van informatiebeveiliging start bij het opstellen van beleid. Het beleid geeft een kader waarbinnen alle verdere activiteiten voor informatiebeveiliging worden uitgewerkt. Het geeft concreet antwoord op vragen als wat de doelstellingen zijn van informatiebeveiliging, wie er verantwoordelijk is voor informatiebeveiliging, wat er van het management wordt verwacht, en hoe het bewustzijn binnen de organisatie bevorderd moet worden. Tevens wordt stilgestaan bij de evaluatie van het beleid, staat men stil bij algemene betrouwbaarheidseisen van informatie (hoe belangrijk is informatie voor onze organisatie in termen van beschikbaarheid, integriteit en vertrouwelijkheid) en bij de organisatie van de beveiligingsfunctie(s) en -processen. Een belangrijke component bij het opstellen van het beveiligingsbeleid is de analyse van de risico’s. Met een risicoanalyse kan een organisatie vooraf inschatten wat de eventuele gevolgen zijn van een bepaalde dreiging. Men berekent de (gevolg)schade - bijvoorbeeld in financiële termen - van een bepaalde dreiging. De risicoanalyse kent een aantal varianten die uitgaan van bijvoorbeeld een checklist, een quick scan of een normenstelsel. De norm is de gewenste situatie of 'Soll’, de huidige situatie wordt aangeduid met 'Ist’. Door 'Ist’ en 'Soll’ met elkaar te vergelijken komen de verschillen boven water en weet de organisatie exact waar ze risico’s loopt. Vervolgens kan men maatregelen opstellen die de impact van de afzonderlijke risico’s moeten beperken. Andere varianten zijn de kwantitatieve en kwalitatieve risicoanalyse. Bij de kwantitatieve analyse wordt een aantal risico’s onderzocht in termen van hoeveelheden, bijvoorbeeld 'duur uitval’. In de kwalitatieve variant wordt de kans bepaald dat een risico zal optreden, met de classificatie 'hoog’, 'middel’ en 'laag’. Een ander voorbeeld van een kwalitatieve risicoanalysevorm is de kwetsbaarheidsanalyse. 2.3.2 Plan Het beveiligingsbeleid vormt de basis voor een beveiligingsplan, dat in detail ingaat op maatregelen, procedures en benodigde middelen (bijvoorbeeld techniek). Het geeft aan waar de beveiligingsfuncties in de organisatie zijn geplaatst, welke methoden voor risicoanalyses men kan gebruiken, welke

8

beveiligingsprocessen er zijn (bijvoorbeeld incidentmanagement), wat de aandachtspunten zijn voor bijvoorbeeld continuïteit, human resource management en netwerkmanagement. Maar ook zaken als toegangscontrole, monitoring, de back-up-strategie en de fysieke beveiliging komen aan bod. Dit plan moet minimaal eenmaal per jaar worden geëvalueerd. Tevens is een fors beveiligingsincident reden voor evaluatie van het plan. De dagelijkse operatie voor informatiebeveiliging is vastgelegd in werkinstructies, handboeken en draaiboeken, bijvoorbeeld een draaiboek Uitwijk, handboek Bewustwording of een Business Continuity Managementhandboek. Deze informatie moet op een eenvoudige wijze toegankelijk zijn en moet frequent worden gecontroleerd op juistheid. Elke wijziging in de omgeving waarvoor de maatregelen en procedures zijn ontwikkeld moet worden verwerkt. Het opstellen van beveiligingshandboeken is een, maar het oefenen is de volgende stap. Maatregelen en procedures bewijzen hun werking pas echt in de praktijk. Laat niet een calamiteit de eerste test zijn. Na een beveiligingsincident moeten handboeken en maatregelen altijd opnieuw worden bezien en eventueel worden aangepast. Het geheel aan beleid, plannen en procedures kan antwoord geven op een willekeurig beveiligingsvraagstuk of beveiligingsbehoefte van de organisatie. Veelal zal er ook een risicoanalyse moeten plaatsvinden, om er zeker van te zijn dat alle risico’s voldoende onderkend zijn. Het resultaat van deze analyse kan overigens betekenen dat het beveiligingsplan moet worden aangepast omdat het niet in de juiste middelen voorziet. 2.3.3 Communicatie Beleid, plannen en maatregelen voor informatiebeveiliging zijn slechts zinvol als hier voldoende over wordt gecommuniceerd, in heldere bewoordingen, waarbij medewerkers moeten inzien waarom informatiebeveiliging noodzakelijk is. Medewerkers moeten zich bewust zijn van het beleid, hun gedrag bepaalt namelijk in grote mate het succes van informatiebeveiliging. Een mogelijke oplossing is het beschikbaar stellen van de handboeken via het bedrijfsintranet. Wijzigingen zijn op deze manier eenvoudig te verwerken en medewerkers beschikken altijd over de juiste versie. Het is raadzaam gebruik te maken van de aanwezige middelen, omdat deze bekend zijn. Voorkom al te ingewikkeld taalgebruik en spits de communicatie toe op toegevoegde waarde van informatiebeveiliging en het belang voor de organisatie als geheel. Maak duidelijk wat het voordeel is voor de eindgebruiker. Omdat communicatie het sluitstuk is van een implementatietraject voor informatiebeveiliging zou een communicatieplan altijd onderdeel moeten zijn van het beveiligingsplan. In het communicatieplan zouden de organisatiedoelen tot uiting moeten komen, geprojecteerd op informatiebeveiliging. Beveiliging wordt vertaald in maatregelen en procedures; het is goed bij deze vertaling meteen te bedenken hoe hierover te communiceren. Concrete middelen hiervoor zijn projectbulletins, instructievideo’s, self assessments in de vorm van een applicatie op het intranet, rollenspellen en workshops. Beveiliging kan ook worden geïntegreerd binnen HRM en in taakinformatie.

9

2.4 Wat is logische toegangsbeveiliging? Het doel van logische toegangsbeveiliging is ervoor te zorgen dat de gebruikers slechts die bevoegdheden toegewezen krijgen die zij voor de vervulling van hun functie nodig hebben. Dit betekent dat de gebruikers niet te veel, maar ook niet te weinig bevoegdheden moeten krijgen. Hoewel er een groot aantal mogelijkheden is om de toegangsbeveiliging te kunnen implementeren, kan een aantal algemene eisen geformuleerd worden waaraan elk systeem van toegangsbeveiliging moet voldoen. De eisen hebben betrekking op: 1. identificatie: het systeem van toegangsbeveiliging moet kunnen vaststellen wie de gebruiker is; 2. authenticatie: de gebruiker moet kunnen aantonen dat hij ook degene is die de gebruiker via zijn identificatie beweert te zijn; 3. autorisatie: het systeem moet over de mogelijkheid beschikken de gebruiker die bevoegdheden te geven die hij op grond van zijn functie nodig heeft; 4. rapporteren: het systeem moet over faciliteiten beschikken om het gebruik van het systeem te kunnen controleren. Daarnaast zijn er nog twee belangrijke onderwerpen die horen bij logische toegangsbeveiliging, te weten: 1. Functiescheiding 2. Kritische functionaliteit 2.4.1 Functiescheiding Taken en verantwoordelijkheidsgebieden behoren te worden gescheiden om gelegenheid voor onbevoegde of onbedoelde wijziging of misbruik van de bedrijfsmiddelen van de organisatie te verminderen. Functiescheiding is een manier om het risico van onopzettelijk of opzettelijk misbruik van systemen te verminderen. Er behoort op te worden gelet dat geen enkele persoon toegang kan krijgen tot activiteiten die niet samen mogen gaan, zogenaamd functievermenging. Bijvoorbeeld het registreren van facturen en het inboeken van goederen in het magazijn. Voor kleine organisaties is functiescheiding wellicht moeilijk te realiseren, echter het principe zou moeten worden toegepast voor zover dat mogelijk en praktisch is. Waar functiescheiding moeilijk kan worden toegepast, behoren andere beheersmaatregelen zoals het controleren van activiteiten, 'audit trails' en supervisie door de directie te worden overwogen. 2.4.2 Kritische functionaliteit Functionaliteit binnen informatiesystemen kan als kritisch worden gedefinieerd als deze van grote invloed is op de belangrijkste processen binnen de organisatie. Het gaat dan vaak om functionaliteit die kan veroorzaken dat bepaalde processen stil komen te liggen waaruit financiële gevolgen uit voortvloeien. Dit betreft verschillende soorten systeemfunctionaliteit: 1. Functionaliteiten binnen als kritisch geclassificeerde bedrijfsprocessen; • Processen die directe of indirecte invloed hebben op financiële rapportages;

10

Processen die als kritisch zijn gedefinieerd in verband met wetgeving (bijvoorbeeld Sarbanes-Oxley Section 404 en Wet Bescherming Persoonsgegevens); • Alle overige processen die door de organisatie als kritisch zijn geclassificeerd. 2. Functionaliteiten ten behoeve van systeembeheer; • Beheer systeemparameters; • Beheer achtergrondprocessen; • Databasemanagement; • Autorisatiebeheer; • Gebruikersbeheer; 3. Functionaliteiten ten behoeve van systeemontwikkeling. 4. Functionaliteiten ten behoeve van (master)datamanagement. •

11

3 Hoe is logische toegangsbeveiliging geregeld in SAP R/3? 3.1 Autorisatieconcept in SAP R/3 SAP R/3 is een ERP systeem en bevat functionaliteiten ter ondersteuning van bijna alle bedrijfsprocessen. Functionaliteit ter ondersteuning van de volgende processen is binnen ieder SAP R/3 systeem standaard aanwezig: • Financial accounting (onder andere boekhouding, debiteuren/crediteuren administratie) • Controlling • Inkoop • Logistiek • Verkoop • Project management • Human Recources Het is niet zo dat organisaties die SAP R/3 gebruiken, alle functionaliteiten bij deze processen hoeven te gebruiken. Verder is het mogelijk dat er extra bedrijfstakspecifieke SAP R/3 oplossingen worden geïnstalleerd. Om functionaliteit binnen SAP R/3 uit te voeren start de gebruiker een transactie op en/of voert de gebruiker een programma uit. Uiteindelijk voert de gebruiker altijd een programma uit, want achter elke transactiecode zitten één of meerdere programma’s. Elke transactie is gekoppeld aan een unieke transactiecode. Een SAP R/3 systeem bestaat standaard uit tienduizenden transactiecodes en honderdduizenden programma’s. Het is ook mogelijk om binnen een SAP R/3 systeem nieuwe (maatwerk)programma’s en (maatwerk)transacties te ontwikkelen. Ontwikkelaars dienen hierbij altijd rekening te houden met de naamgevingconventie. Dit is onder meer van belang om de nieuwe programma’s en transacties herkenbaar te houden. Binnen SAP R/3 zijn de beginletters Y en Z vrijgehouden voor de technische naam van zelf ontwikkelde programma’s en transacties. Het SAP R/3 autorisatieconcept biedt bescherming tegen onbevoegde toegang. De gebruikers kunnen slechts de transacties en programma's gebruiken die uitdrukkelijk voor hen zijn toegestaan. De Profiel Generator en het Autorisatie Infosysteem zijn beschikbaar als hulpmiddel binnen SAP R/3 bij het werken met het autorisatieconcept. De Profiel Generator verstrekt een topdown benadering van de toewijzing van autorisaties. Het Autorisatie Infosysteem biedt een gemakkelijk toegankelijk overzicht over de autorisaties. Om het autorisatieconcept binnen SAP R/3 af te dwingen worden autorisatiecontroles uitgevoerd wanneer de gebruikers proberen om programma's of transacties uit te voeren. In de autorisatiecontroles wordt geverifieerd of de autorisaties aan het gebruikers-ID gekoppeld zijn, alvorens de gebruiker toe te staan om de betreffende transactie of het programma verder uit te voeren. Er zijn diverse soorten autorisatiecontroles binnen SAP R/3, namelijk: • Transactiestart autorisatie; De gebruiker moet de aangewezen autorisaties hebben om transacties op te starten. Dit is op transacties van toepassing die vanaf het menu kunnen worden opgestart of vanuit het commandoveld. Deze autorisatiecontrole vindt standaard bij elke

12

•

•

•

transactie plaats. De controle hierbij vindt plaats op de transactiecode. De controle vindt ook plaats voor transacties die vanuit een programma of vanuit een andere transactie worden aangeroepen. Het is echter mogelijk om deze controle inactief te maken. Specifieke autorisatie voor een transactie; Naast de autorisatiecontrole bij de transactiestart zijn de transacties beschermd met extra autorisatiecontroles naast de controle op transactiecode. Dit vindt plaats aan de hand van een autorisatie-object. Wanneer er nieuwe transacties worden gecreëerd kunnen ook aanvullende autorisatiecontroles worden toegewezen. Autorisatiecontrole op programmaniveau; Deze controle vindt plaats door middel van het commando AUTHORITY-CHECK in een programma. Hierbij vind er een controle plaats of de gebruiker geautoriseerd is om het programma verder uit te voeren. Het is aan te bevelen om deze bescherming ook in nieuwe en gewijzigde programma’s te gebruiken. Rapportklassen en Tabel autorisatiegroepen; Naast programma- of de transactieautorisatiecontroles, kunnen rapporten aan rapportklassen en autorisatiegroepen aan tabellen worden toegewezen. Hoewel gebruikers de transacties kunnen gebruiken om rapporten of direct tabellen te benaderen, kunnen zij tot die rapporten en tabellen slechts toegang krijgen waarvoor zij de overeenkomstige autorisaties hebben.

Het SAP R/3 autorisatieconcept bestaat altijd uit de volgende componenten: • Gebruikers-ID: Elke gebruiker die aanlogt op een SAP Systeem moet een gebruikers-ID hebben. Het gebruikers-ID bevat alle informatie betreffende de gebruiker inclusief de koppeling met de profielen. Een gebruiker kan de activiteiten uitvoeren die in de autorisaties in het profiel zijn bepaald. • Profielen: Autorisaties in de gebruikers-ID’s worden gekoppeld door middel van autorisatieprofielen. • Autorisaties: Een autorisatie staat een gebruiker toe om een bepaalde activiteit in het SAP Systeem uit te voeren, dat op een reeks waarden wordt gebaseerd, die op basis van het autorisatie-object worden bepaald. Elke autorisatie verwijst naar precies één autorisatieobject en bepaalt de toegelaten waarden voor elk autorisatie-objectveld van dit object. • Autorisatie-objecten: Dit is een template die gebruikt wordt om autorisaties te bepalen. De autorisaties worden opgebouwd op basis van deze objecten. Bijvoorbeeld het autorisatieobject F_AVIK_BUK (Betalingsadvies: autorisatie voor bedrijfcodes) wordt gebruikt om diverse autorisaties in Financiële Boekhouding zoals algemene Financiële weergave autorisaties, debiteuren- en crediteuren-autorisaties tot stand te brengen. Het is mogelijk om voor bepaalde transacties te bepalen dat een autorisatiecontrole op een autorisatie-object inactief is en dus niet wordt uitgevoerd bij het doorlopen van de transactie. Ook het mogelijk voor objecten te bepalen, dat de autorisatiecontrole helemaal niet plaatsvindt bij het uitvoeren van alle programma’s en transacties.

13

•

Autorisatie-objectvelden: Het autorisatieobject bevat maximaal 10 autorisatie-objectvelden. Deze velden zijn verbonden met gegevenselementen die in de programma’s staan vermeld. De toelaatbare waarden vormen een autorisatie. Wanneer een autorisatiecontrole plaatsvindt, verifieert het systeem de waarden waarvoor een gebruiker is geautoriseerd, tegen de waarden die worden vereist om de actie uit te voeren. De gebruiker kan de actie slechts uitvoeren als hij of zij aan de voorwaarden voor elk veld in het object voldoet. De meeste autorisatie-objectvelden komen in meerdere autorisatie-objecten voor. Het meest gebruikte autorisatieobjectveld is het veld ACTVT (activiteit). De waarden in dit veld bepalen welke activiteiten er binnen deze autorisatie mogen worden uitgevoerd. Een veld kan ook een asterisk (*) als waarde bevatten. Dit betekent dat alle waarden (bijvoorbeeld alle activiteiten) worden toegestaan. Ook zijn er diverse velden aanwezig die een organisatorische eenheid vertegenwoordigen,zoals het veld bedrijfscode of magazijn. Hiermee wordt bepaald voor welke organisatorische eenheden men is geautoriseerd.

SAP R/3 hanteert het principe van accumulatie van toegangsrechten. Dit betekent dat bij het optellen van autorisaties in het gebruikers-ID de maximaal mogelijke toegang wordt verleend op basis van het totaal aan autorisaties. Er wordt door het SAP R/3 systeem aan een gebruiker toegang verleend, als de gebruiker alle velden met de betreffende veldwaarden heeft toegekend. Dit wordt per autorisatie-object bepaald. Hieronder staan twee voorbeelden vermeld van een autorisatiecontrole op bedrijfscode bij het creëren van een materiaal, welke gebruikt wordt voor een bestelling.

14

Het SAP R/3 autorisatieconcept is zeer complex, omdat het bestaat uit vele componenten die met elkaar verbonden zijn. Er is daarbij ook sprake van zeer grote aantallen componenten. Binnen een standaard SAP R/3 systeem zijn bijvoorbeeld de volgende voor autorisaties relevante componenten aanwezig: • Meer dan 50.000 transacties; • Meer dan 700.000 programma’s; • Meer dan 1000 autorisatie-objecten. Het SAP R/3 autorisatieconcept vanaf SAP R/3 versie 4.6C is opgebouwd aan de hand van Role Based Access. Rollen bevatten een profiel met de autorisaties en deze rollen worden gekoppeld aan gebruikers-ID´s. In voorgaande versies werd er in plaats van rollen gebruik gemaakt van ´Activity groups´. Aangezien momenteel bijna alle operationele SAP R/3 systemen versie 4.6C of hoger zijn en de operationele systemen van eerdere versies binnen afzienbare tijd geüpgrade zullen worden, zal in onderstaande paragrafen het principe van Role Based Access binnen SAP R- /3 worden uitgewerkt en zal er niet verder worden ingegaan op ´Activity groups´.

3.2 Role Based access Het SAP R/3 Role Based autorisatieconcept is opgebouwd uit verschillende lagen. In het figuur hieronder is de opbouw weergegeven. In deze scriptie wordt voor de naam verzamelrol, de naam samengestelde rol gebruikt.

15

Dit figuur gaat er vanuit dat alle onderdelen binnen het autorisatieconcept worden gebruikt. Dit wordt aanbevolen door SAP en binnen de meeste SAP R/3 systemen is dit het geval. Er kunnen echter ook bepaalde lagen worden weggelaten. Een aantal van deze onderdelen zijn in de voorgaande paragraaf al beschreven. Hieronder zal met name in worden gegaan op de relaties tussen deze onderdelen in het Role Based autorisatieconcept binnen SAP R/3. 3.2.1. Gebruikers-ID Het hoogste niveau is het gebruikers-ID waarmee de gebruiker aanlogt in SAP R/3. Hieraan is het totaal aan autorisaties gekoppeld. Een gebruikers-ID kan worden geblokkeerd zodat de gebruiker er niet meer mee aan kan loggen op het systeem. Dit kan handmatig plaatsvinden maar ook automatisch, na een aantal aanlog-pogingen waarbij het verkeerde wachtwoord is gebruikt. Verder is het mogelijk om voor een gebruikers-ID een geldigheidstermijn op te geven. Buiten deze geldigheidstermijn kan er niet met het gebruikers-ID worden aangelogd. 3.2.2. Samengestelde rollen Aan het gebruikers-ID kunnen één of meerdere rollen zijn gekoppeld. Aan een samengestelde rol zijn één of meerdere rollen gekoppeld. De rollen kunnen echter ook direct aan het gebruikers-ID worden gekoppeld. Voor rollen is het mogelijk om een geldigheidstermijn op te geven bij de koppeling aan het gebruikers-ID. Deze is dan ook van toepassing op alle rollen die door middel van de samengestelde rol aan het gebruikers-ID zijn gekoppeld.

16

3.2.3. Rollen en profielen Een rol is meestal aan een profiel gekoppeld aangezien het profiel uiteindelijk de autorisaties bevat. Als een rol aan een profiel gekoppeld is, dan zijn uiteindelijk zowel het profiel als de rol aan het user-id gekoppeld, al dan niet vanuit een rol. De samengestelde rol bevat echter alleen de rol. Ook is er nog de mogelijkheid om direct rollen en/of profielen aan een gebruikers-ID te koppelen. Ook voor rollen is het mogelijk om een geldigheidstermijn op te geven bij de koppeling aan het gebruikers-ID. Verder kan er nog gebruik gemaakt worden van ‘derived’ rollen met bijbehorende profielen. Dit zijn rollen en profielen die afgeleid zijn van andere rollen en profielen. Het onderscheid zit hierbij in bepaalde organisatorische autorisaties. 3.2.4. Transacties Aan een rol en profiel zijn meestal transacties gekoppeld. In de rol staan de transacties in het rolmenu vermeld. In het profiel staan de transacties vermeld in het S_TCODE autorisatie-object. 3.2.5. Autorisatie-objecten Aan het profiel zijn de autorisatie-objecten gekoppeld met de daarbij behorende velden. Meestal zijn dit de objecten die gecontroleerd worden bij het uitvoeren van de transacties in het S_TCODE autorisatie-object. 3.2.6. Autorisaties Het laagste niveau zijn de autorisaties. Deze zijn gekoppeld aan een autorisatieobject. De autorisaties bevatten de veldwaarden waarvoor autorisatie wordt verleend. Meestal zijn dit de autorisatie-objecten met bijbehorende velden en veldwaarden die gecontroleerd worden bij het uitvoeren van de transacties in het S_TCODE autorisatie-object, waarvoor de betreffende gebruiker geautoriseerd moet zijn. Wanneer transacties worden opgevoerd in het rolmenu zullen de bijbehorende autorisaties namelijk in veel gevallen automatisch worden ingevuld.

3.3 Systeemparameters Naast het autorisatieconcept heeft SAP een tabel waar systeemparameter instellingen zorgen voor strikte beheersmaatregelen aangaande logische toegangscontrole. Te denken valt aan het zetten van minimale wachtwoord lengte, time out van de SAP sessie na een x aantal minuten. In bijlage I zijn deze systeemparameter instellingen te vinden.

3.4 Systeemlandschap SAP R/3 biedt de mogelijkheid om een systeemlandschap op te bouwen waardoor ontwikkeling, test, acceptatie en productie op verschillende systemen plaats kan vinden. Daarbij is het ook mogelijk om de systemen onder te verdelen naar clients. Dit is een deelomgeving op een systeem dat een specifieke rol vervult. Een ontwikkel- en een testomgeving kunnen bijvoorbeeld op één systeem aanwezig zijn, maar elk op een eigen client.

17

3.5 Transportmechanisme Veranderingen of aanpassingen in de ontwikkelomgeving van SAP R/3 worden door middel van transporten verplaatst van de ene omgeving naar de andere omgeving, totdat het is doorgekomen in de productie omgeving. Dit mechanisme moet worden gebruikt voor het aanpassen of veranderen van de autorisaties in SAP R/3.

Afbeelding van systeemlandschap en uitleg van het transportmechanisme.

18

4 Wat is noodzakelijk voor de inrichting van logische toegangsbeveiliging in SAP R/3? In dit hoofdstuk zal ingegaan worden op de inrichting van autorisatiebeheer.

4.1 Autorisatiebeleid Binnen de organisatie dient autorisatiebeleid geformuleerd te zijn. Dit beleid zou periodiek moeten worden gecontroleerd op eventueel noodzakelijke aanpassingen. In het beleid dient het eigenaarschap van het proces Autorisatiebeheer te zijn bepaald. 4.1.1 Doel Om te beginnen zullen de doelen en de uitgangspunten gedefinieerd moeten zijn. Dit is noodzakelijk om de uitwerking van het beleid vorm te geven. In de doelstelling zal aangeven worden wat men met het autorisatiebeleid wil bereiken. De hoofddoelstelling zal meestal het voorkomen van ongeautoriseerde toegang zijn. Daarbij kunnen nog een aantal subdoelstellingen worden geformuleerd ten behoeve van het bereiken van de hoofddoelstelling. Voor het voorkomen van ongeautoriseerde toegang is het bijvoorbeeld noodzakelijk, dat personen alleen toegang hebben tot gegevens die noodzakelijk zijn bij de uitoefening van hun functie. In de uitgangspunten zou onder meer vermeld moeten staan wat de scope is en welke randvoorwaarden er gelden. In de scope dient bijvoorbeeld aangegeven te worden op welke informatiesystemen het beleid betrekking heeft. In de randvoorwaarden dienen zaken uitgesloten te worden waarop het beleid niet ingaat. Het uitgewerkte beleid zou uiteindelijk afgeleid moeten zijn van de geformuleerde doelstelling(en) en uitgangspunten. 4.1.2 Richtlijnen Er dienen in het beleid richtlijnen te zijn opgenomen waarin bepaald wordt welke omgevingen en doelsystemen binnen de scope vallen. Hierbij dienen bepalingen te zijn opgenomen voor de ontwikkeling-, test-, acceptatie- en productie-omgeving. De uitgangspunten voor de autorisaties dienen te zijn gedefinieerd en betreffen: 1. Geen ontwikkelingsactiviteiten op productie-omgevingen; 2. Scheiding van soorten gebruikers en autorisaties op verschillende omgevingen; • Geen eindgebruikers op ontwikkelomgeving; • Geen systeembeheerders en -ontwikkelaars met operationele autorisaties voor eindgebruikersfunctionaliteiten op productieomgeving. In het autorisatiebeleid dienen richtlijnen te zijn opgenomen of er gebruikersID’s mogen bestaan die alle autorisaties hebben. Als dit het geval is dienen hiervoor randvoorwaarden te zijn beschreven. Deze zouden de bepaling moeten bevatten, dat er gespecificeerd dient te zijn welke gebruikers-ID’s het betreft en op welke systemen dit van toepassing is. Hierbij dient ook altijd de reden te worden vermeld waarom de betreffende gebruikers-ID’s alle autorisaties hebben en wat hier de risico’s met bijbehorende compenserende maatregelen zijn.

19

Ook dienen in het autorisatiebeleid richtlijnen te zijn opgenomen met betrekking tot de opbouw van autorisaties. Hierbij dienen de volgende zaken te zijn bepaald: 1. De soorten autorisaties die worden gebruikt: • functie/proces gerelateerd; • taak gerelateerd; • project gerelateerd; • organisatie gerelateerd; • geografisch gerelateerd; 2. De autorisatiestructuur, waarbij minimaal aandacht besteed is aan: • autorisatie hiërarchieën; • het automatisch ‘erven’ van autorisaties; 3. De naamgevingconventies binnen autorisaties; 4. Rekening houden met functiescheiding binnen autorisaties. De wijze van controle op de inrichting en uitvoering van de activiteiten dient ook in het autorisatiebeleid te zijn opgenomen. Er dient hierbij te worden bepaald welke functionaris met welke frequentie bepaalde controles uitvoert. Controlerende activiteiten moeten in functie gescheiden zijn van uitvoerende activiteiten. In het autorisatiebeleid moet rekening worden gehouden met het effect van classificatie van gegevens en systemen. Bij de classificatie “kritisch” kan er bijvoorbeeld sprake zijn van het uitvoeren van extra controles op autorisaties. Het inrichtingsproces van autorisaties moet hiermee rekening houden.

4.1.3 Taken en verantwoordelijkheden Bij het proces voor autorisatiebeheer zijn diverse functionarissen direct of indirect betrokken. De activiteiten die deze functionarissen uitvoeren dienen in het autorisatiebeleid te zijn vastgelegd, waarbij sprake is van een controletechnische functiescheiding tussen de volgende activiteiten en verantwoordelijkheden: • Eigenaarschap van het proces Autorisatiebeheer, verantwoordelijk voor het realiseren van de doelstellingen van het proces en het onderhoud van het gehanteerde autorisatiemodel; • Gebruikersbeheer, verantwoordelijk voor het beheer van de gebruikers-ID’s en de koppeling van gebruikers aan autorisaties; • Security functie, verantwoordelijk voor het goedkeuren en toezicht op de interne autorisaties van het autorisatiebeheer. Daarnaast kunnen zij ook een bredere controlerende functie hebben afhankelijk van de positionering van deze functie binnen de organisatie. Dit betreft dan bijvoorbeeld het goedkeuren en toezicht van autorisaties van andere functionarissen binnen de organisatie; • Autorisatiebeheer, verantwoordelijk voor het beheer van de autorisaties; • Eigenaarschap van objecten, verantwoordelijk voor de toegang tot het object. Deze objecten betreffen applicaties, organisatieprocessen en bedrijfsgegevens; • Functioneel beheer van applicaties, verantwoordelijk voor aansturing van de autorisatiebeheerder betreffende het aanmaken van

20

autorisatiegroepen/applicatierollen, de koppeling daarvan met de objecten en het vastleggen van de gerelateerde permissies; • Aanvrager, verantwoordelijk voor een juiste en tijdige aanvraag van wijzigingen in de implementatie en toewijzing van autorisaties. De aanvrager is in de meeste gevallen een (lijn)manager die autorisaties aanvraagt voor medewerkers waarvoor deze verantwoordelijk is. • Controlefunctie, verantwoordelijk voor de periodieke toetsing op de beheersbaarheid van de geïmplementeerde autorisaties en controle op de effectiviteit ervan. Een combinatie van controlerende en uitvoerende verantwoordelijkheden dient niet bij één persoon te worden belegd, in verband met controletechnische functiescheiding. Verder dient de aanvrager niet te zijn betrokken in de goedkeuring en uitvoering van de betreffende aanvraag. De aanvrager mag zelf geen wijzigingen aanvragen die van invloed zijn op het eigen gebruikers-ID. 4.1.4 Koppeling andere processen In het autorisatiebeleid zal beschreven moeten zijn, hoe de koppeling tussen het gehele incidenten- en wijzigingsproces voor informatiesystemen, en het incidenten- en wijzigingsproces voor autorisaties eruit ziet. Elke wijziging dient te worden gevalideerd door daartoe bevoegde personen. Incidenten met betrekking tot autorisaties dienen te worden vastgelegd en te worden geanalyseerd. Bij veel organisaties maakt men hierbij gebruik van ITIL. Verder bestaan er koppelingen met het personeelsproces, waarbij medewerkers in-, door- en uitstromen. Bij instroom van nieuwe medewerkers zullen de noodzakelijke autorisaties geregeld moeten worden. Wanneer medewerkers doorstromen naar een andere functie binnen de organisatie dienen in veel gevallen de autorisaties te worden aangepast. En wanneer medewerkers niet meer voor de organisatie werkzaam zijn dienen de autorisaties te worden ingetrokken. Al deze personeelsmutaties moeten worden doorgeven vanuit de HR-afdelingen aan de afdelingen die de autorisaties beheren, zodat deze de benodigde aanpassingen kunnen doorvoeren en kunnen controleren of medewerkers wel de juiste autorisaties hebben toegewezen. Vaak zullen aanpassingen, zoals het aanvragen van nieuwe autorisaties en autorisatiewijzigingen, echter specifiek moeten worden aangevraagd via autorisatie-aanvraagprocedures. Er bestaat ook een koppeling met het ontwerpproces van informatiesystemen, waarbij de autorisatie-inrichting moet worden ontworpen. De autorisatieinrichting dient hierbij zowel door de IT-organisatie, als door vertegenwoordigers vanuit de business-organisatie te worden goedgekeurd. Het ontwerpproces is van zeer groot belang, aangezien de gekozen autorisatieinrichting uiteindelijk de beheersbaarheid van autorisaties bepaalt.

4.2 Processen autorisatiebeheer Autorisatiebeheer kan worden onderverdeeld in de volgende deelprocessen: 1. Beheer gebruikers-ID’s; 2. Koppeling van autorisaties aan gebruikers-ID’s; 3. Beheer autorisaties (bijvoorbeeld rollen en autorisatiegroepen). Van het derde proces is sprake wanneer autorisaties inhoudelijk gewijzigd kunnen worden, zoals in het geval van autoriseren door middel van rollen en

21

profielen. Autorisaties die aan gebruikers op de systemen toegekend zijn, kunnen dus zowel veranderen doordat de autorisaties (bijvoorbeeld rollen) inhoudelijk worden aangepast, maar ook door de (ont)koppeling van de autorisaties aan hun gebruikers-ID. Bij het beheer van autorisaties is het belangrijk om onderscheid te maken naar het beheer van gebruikers-ID’s en het koppelen van autorisaties aan gebruikers-ID’s, ofwel het beheer van autorisaties in enge zin. Het maken van dit onderscheid voorkomt dat een autorisatiebeheerder in staat is fictieve (niet als kritisch te onderkennen) gebruikers-ID’s aan te maken en die autorisaties te geven. De beheerder zou in dat geval zelf onbevoegde handelingen kunnen uitvoeren die heel lastig aan hem of haar zijn toe te rekenen. Hij of zij werkt immers dan niet met zijn eigen userid. Het zal in de praktijk niet altijd mogelijk zijn om het beheer van gebruikers-ID’s en het koppelen van autorisaties aan gebruikers-ID’s te scheiden. Dit kan te maken hebben met organisatorische redenen, zoals in het geval dat de organisatie van een zeer kleine omvang is. Ook kan het te maken hebben met technische redenen. Het kan bijvoorbeeld zijn dat het niet mogelijk is om dit onderscheid te maken. In deze gevallen dienen er compenserende maatregelen te worden genomen. Er zal een extra strikte controle plaats moeten vinden op de functionarissen die zich bezighouden met het autorisatiebeheer. Hun activiteiten zouden regelmatig moeten worden gecontroleerd door middel van bijvoorbeeld steekproeven van autorisatiewijzigingen. Los hiervan dient altijd een zo beperkt mogelijke groep personen te zijn geautoriseerd voor het koppelen van autorisaties aan gebruikers-ID’s, om zo het risico te minimaliseren dat er autorisaties toegewezen worden die niet zijn gevalideerd. En aangezien het voor functionarissen die zich bezighouden met het beheer van bijvoorbeeld rollen, niet noodzakelijk is om gebruikers-ID’s te kunnen onderhouden, zouden zij dus deze autorisaties niet mogen hebben. Alle functionarissen die zich bezighouden met het beheer van gebruikers-ID’s en het beheer van de autorisaties zouden gescreend moeten zijn, voordat zij deze activiteiten mogen gaan uitvoeren. Personen die zich in het verleden schuldig hebben gemaakt aan frauduleuze zaken zouden deze activiteiten niet uit mogen voeren, aangezien deze activiteiten gevoelig zijn voor fraude. Zowel het beheer van gebruikers-ID’s als het beheer van autorisaties, zal meestal worden uitgevoerd met behulp van tools. De meeste van de huidige systemen bevatten dergelijke tools. Het beheer van gebruikers-ID’s en het beheer van autorisaties vindt dan in de systemen plaats, waar de autorisaties van toepassing zijn. Daarnaast zijn er ook specifieke autorisatie-tools beschikbaar, die het implementeren, beheren en controleren van gebruikers-ID’s en autorisaties mogelijk maken. Deze maken het implementeren, beheren en controleren vaak ook makkelijker. Dit kan bijvoorbeeld het geval zijn wanneer gebruikers-ID’s en autorisaties van verschillende systemen binnen één tool beheerd kunnen worden. Alle wijzigingen met betrekking tot autorisaties dienen te worden gelogd. In deze logging dienen de volgende zaken te zijn vermeld: • Welke autorisaties toegewezen of verwijderd zijn, bij welk gebruikers-ID; • De wijziging in de betreffende autorisatie (rol/profiel/autorisatiegroep); • De naam of het gebruikers-ID van de functionaris die de wijziging heeft doorgevoerd;

22

•

De datum van de wijziging.

4.2.1 Beheer gebruikers-ID’s Het beheer van gebruikers-ID’s omvat diverse activiteiten. De algemene gebruikersgegevens zullen moeten worden beheerd. Van iedere gebruiker dient de naam bekend te zijn, zodat deze geïdentificeerd kan worden. Verder kan het praktisch zijn als afdelings- en locatiegegevens worden geregistreerd bij het gebruikers-ID, zodat gebruikers gemakkelijk terug te vinden zijn binnen de organisatie. Dit is ook van belang bij de controle van de toewijzing van autorisaties, omdat aan de hand van de afdeling en locatie vaak al voor een deel bepaald kan worden of de gebruiker de juiste autorisaties heeft. Veel organisaties hebben echter een intranet waarop deze gegevens te achterhalen zijn aan de hand van de naam van de gebruiker, dus dan zou het bijhouden van deze gegevens bij de gebruikers-ID’s alleen maar extra beheeractiviteiten kosten. Daarnaast omvat het beheer van gebruikers-ID’s ook het beheer van de gekoppelde wachtwoorden. Ook het blokkeren en deblokkeren van gebruikersID’s is een activiteit die bij het beheer van gebruikers-ID’s hoort. Een andere activiteit die van toepassing is bij het beheer van gebruikers-ID’s, is dat gebruikers-ID’s worden verwijderd wanneer deze niet meer mogen worden gebruikt. Dit kan het geval zijn wanneer een persoon een andere functie heeft gekregen of niet meer werkzaam is binnen de organisatie. Hiervoor is het dus noodzakelijk dat wijzigingen in het personeelsbestand worden doorgegeven aan de beheerders van gebruikers-ID’s. Verder dienen gebruikers-ID’s te worden geblokkeerd indien deze tijdelijk niet worden gebruikt. Deze gegevens staan op zich nog los van autorisaties maar zijn wel van indirect belang bij het autorisatieproces. Deze hebben namelijk te maken met identificatie en authenticatie. Het moet duidelijk zijn dat wanneer autorisaties worden toegewezen aan een gebruikers-ID, dit ook het ID is dat ook daadwerkelijk uniek aan de gebruiker is toegewezen en dat autorisaties niet aan verkeerde gebruikers-ID’s worden toegewezen. Ook is het belangrijk dat nietgeautoriseerde gebruikers niet in kunnen loggen met een gebruikers-ID welke aan anderen toebehoort. Daarmee zouden deze gebruikers de autorisaties van iemand anders hebben. 4.2.2 Koppeling autorisaties aan gebruikers-ID’s De gebruikers-ID’s die zijn aangemaakt dienen te worden gekoppeld aan autorisaties. De wijze waarop dit plaatsvindt, is afhankelijk van het autorisatiemechanisme dat wordt gehanteerd. Dit is meestal afhankelijk van het systeem. Gebruikers zouden alleen geautoriseerd mogen zijn voor activiteiten, die in het kader van de uitoefening van hun functie noodzakelijk zijn. Het is daarom bij de koppeling van autorisaties belangrijk dat duidelijk is welke activiteiten, door welke functie worden uitgevoerd en welke autorisaties dus moeten worden gekoppeld. Een autorisatiematrix is hierbij een goed hulpmiddel. Hierin zou dan per functie aangegeven moeten zijn, welke autorisaties toegewezen zouden moeten worden. Hier zou alleen van afgeweken mogen worden in overleg met een functionaris die verantwoordelijk is voor de AO/IC binnen de organisatie. Deze functionaris zou formeel akkoord moeten geven, alvorens de afwijkende autorisaties mogen worden gekoppeld.

23

Indien mogelijk zou er een directe koppeling moeten zijn met de functie die gebruikers vervullen, op basis van de gegevens in het HR systeem. Er zou een technische koppeling gemaakt kunnen worden, zodat gebruikers automatisch de autorisaties krijgen toegewezen die bij de functie horen, die zij volgens het HR systeem vervullen. In dat geval zouden de medewerkers ook andere autorisaties toegewezen kunnen krijgen, wanneer zij een andere functie gaan vervullen of wanneer hun functie-inhoud wijzigt. Oftewel automatische aanpassing van de IST- aan de SOLL-situatie. Als een technische koppeling niet mogelijk is dan zou er nog gekozen kunnen worden voor een verificatie met het HR systeem. Voordat er autorisaties aan een gebruikers-ID gekoppeld worden, zou er in het HR systeem nagegaan kunnen worden, welke functie de betreffende gebruiker vervult. Daarnaast zou de HR afdeling wijzigingen van de functie van medewerkers moeten doorgeven aan de functionaris die verantwoordelijk is voor de koppeling van autorisaties in het systeem. Een voorwaarde voor een koppeling met het HR systeem, is dat het HR systeem up-to-date moet zijn. Door een dergelijke koppeling kan het risico op een onjuiste koppeling van autorisaties aan gebruikers-ID’s worden beperkt. 4.2.3. Beheer autorisaties De autorisaties die gekoppeld worden aan de gebruikers-ID’s moeten in de meeste gevallen beheerd worden. Dit is het geval als er sprake is van bijvoorbeeld rollen, profielen of autorisatiegroepen. Deze objecten moeten vaak worden aangemaakt en de inhoud ervan moet worden bepaald. De autorisaties dienen op een heldere en beheersmatige wijze te zijn opgezet. Dit is van groot belang om fouten te voorkomen bij het beheer van de autorisaties, maar ook bij de koppeling van de autorisaties aan de gebruikersID’s. Uiteindelijk is dit ook van belang bij de controle van de toewijzing van autorisaties. De volgende zaken zijn het meest belangrijk bij de opzet ten aanzien van het beheer van autorisaties: • Volledige en up-to-date documentatie van de autorisaties. In de documentatie dient te zijn beschreven hoe de autorisaties zijn opgebouwd. Verder dienen eventuele uitzonderingen op de autorisatieopbouw te worden vermeld. • Duidelijke werkinstructies. Hierin dienen de activiteiten te zijn uitgewerkt die van toepassing zijn bij het beheer van autorisaties. Dit zal vooral betrekking hebben op het incidenten- en wijzigingsproces. • Heldere naamgevingconventies binnen autorisaties. De naamgevingconventie dient op een dusdanige wijze te zijn opgezet zodat het autorisatieproces beheersbaar is en het gemakkelijk te doorgronden is. Hiermee zal de kans op fouten worden beperkt. • Bij de bepaling van autorisaties dienen naast de IT afdeling ook andere afdelingen in de organisatie te worden betrokken. Voor applicaties, gegevens en processen zouden eigenaren moeten worden aangewezen die bij de bepaling en wijziging van autorisaties worden betrokken. • Indien er sprake is van meerdere systemen, dan dienen autorisatiestructuren waar mogelijk op elkaar aan te sluiten, zodat bij gelijksoortige systemen dezelfde autorisatiestructuur wordt gehanteerd. Ook dient er hierbij rekening te worden gehouden met

24

autorisaties die over de systemen heen gaan. Denk hierbij in het bijzonder ook aan functiescheiding tussen de diverse systemen. 4.2.4 Autorisatie aanvraagprocedure Autorisatieaanvragen zouden altijd moeten verlopen volgens een geformaliseerde procedure, met daarin voldoende waarborgen ter voorkoming van fouten en fraude. Deze procedure dient de volgende bepalingen te bevatten: • Autorisatieaanvragen dienen vooraf goedgekeurd te worden door minimaal één functionaris die hiervoor bevoegd is vanuit de organisatie. Dit om te voorkomen dat gebruikers autorisaties toegewezen krijgen die zij niet nodig hebben voor hun werkzaamheden. • Het mag niet mogelijk zijn dat gebruikers hun eigen aanvragen goedkeuren. Anders zou men autorisaties voor het eigen gebruikersID kunnen aanvragen, die men niet nodig heeft voor de eigen werkzaamheden. Dit met als doel om hiermee frauduleuze activiteiten te verrichten. • Er dient handtekeningverificatie plaats te vinden van autorisatie aanvragen, die door middel van een formulier voorzien van een handtekening worden ingediend. Dit om de aanvrager te identificeren en dus uit te sluiten dat de handtekening is vervalst. • Autorisatieaanvragen dienen te worden gearchiveerd. Men moet elke wijziging van autorisaties van gebruikers kunnen achterhalen. Dit kan bijvoorbeeld van groot belang zijn als er fraude is gepleegd. Deze bepalingen zijn van toepassing op de aanvraag van gebruikers-ID’s, de koppeling van gebruikers-ID’s met autorisaties en wijzigingsverzoeken ten aanzien van bijvoorbeeld rollen, profielen of autorisatiegroepen. De volgende bepalingen zouden moeten zijn opgenomen in de autorisatie aanvraagprocedure ten aanzien van de koppeling van autorisaties met gebruikers-ID’s: • Aanvrager mag niet alleen aangeven dat een gebruiker dezelfde autorisaties moet hebben als een andere gebruiker; oftewel het kopiëren van de autorisaties van gebruikers-ID’s is niet toegestaan. Hiermee kan voorkomen worden dat gebruikers te veel of verkeerde autorisaties toegewezen krijgen. Dit omdat de aanvrager in veel gevallen niet van te voren checkt of de gebruiker, die al in het systeem staat, daadwerkelijk de autorisaties heeft die hij of zij zou verwachten. • Autorisaties die op tijdelijke basis extra worden toegevoegd aan gebruikers-ID’s dienen indien mogelijk te worden voorzien van een einddatum. Hiermee kan voorkomen worden dat de autorisaties langer toegewezen zijn dan dat nodig is. • Autorisaties die worden toegevoegd aan gebruikers-ID’s van tijdelijke medewerkers dienen indien mogelijk te worden voorzien van een einddatum. Hiermee kan voorkomen worden dat de autorisaties langer toegewezen zijn dan dat nodig is. Wanneer er sprake is van autorisaties die inhoudelijk ook gewijzigd kunnen worden, dienen hiervoor ook bepalingen te zijn opgenomen in de autorisatie aanvraagprocedure. Dit is het geval wanneer er sprake is van rollen, profielen of

25

autorisatiegroepen die kunnen worden gewijzigd. De procedure dient de volgende bepalingen te bevatten: • Autorisatiewijzigingen dienen te worden gecontroleerd op functiescheiding. Dit om te voorkomen dat er functievermenging ontstaat binnen autorisaties en daarmee gebruikers de mogelijkheid hebben om frauduleuze activiteiten te verrichten. • Autorisatiewijzigingen dienen te worden gecontroleerd op kritische functionaliteit. Hiermee kan voorkomen worden dat gebruikers toegang krijgen tot kritische functionaliteit die zij niet nodig hebben voor hun werkzaamheden. • Autorisatiewijzigingen dienen indien mogelijk te worden getest op een test- en/of acceptatiesysteem. Dit om te voorkomen dat autorisaties op het productiesysteem anders zijn dan men zou verwachten. Alvorens aan deze bepalingen is voldaan mogen de autorisatiewijzigingen niet op productiesystemen actief zijn. Functionarissen die autorisatieaanvragen goed moeten keuren, moeten op de hoogte zijn van de inhoud van de autorisaties. Gebruikers zouden alleen autorisaties toegewezen mogen krijgen die zij in het kader van de functie die zij vervullen nodig hebben. Een autorisatiematrix kan hierbij een goed hulpmiddel zijn. Hierin staat op individueel, functie- of taak-niveau aangegeven welke autorisaties toegewezen zouden moeten worden.

4.2 Rapportage en controle van autorisaties Er dienen periodiek controles plaats te vinden op autorisaties. Indien mogelijk zou dit geautomatiseerd plaats moeten vinden, omdat dan een volledige controle mogelijk is. Als dit niet mogelijk is dan zou een volledige controle vaak teveel tijd kosten. In dat geval zouden er steekproeven moeten worden genomen. De uitvoerende functionarissen zouden zelf hun eigen werkzaamheden kunnen controleren, zodat eventuele onvolkomenheden kunnen worden hersteld. Het is echter van groot belang dat deze controles ook worden uitgevoerd door functionarissen die niet betrokken zijn in uitvoerende processen binnen autorisaties. Als dit niet zou plaatsvinden dan zouden de uitvoerende functionarissen onvolkomenheden (on)bewust kunnen laten bestaan. De controles zouden plaats kunnen vinden door één of meerdere van de volgende functionarissen: • Security manager; • AO/IC manager; • Controller; • Lijnmanager van de functionarissen van de betreffende gebruikersID’s; • IT manager; • Interne auditor; • Information manager. Ook de rapportages die als input dienen voor de controle op autorisaties zouden vervaardigd moeten worden door functionarissen, die niet betrokken zijn in uitvoerende processen binnen autorisaties. Het is aan te bevelen om alle aan gebruikers-ID’s toegewezen autorisaties minimaal één maal per 3 maanden te controleren. De controles zouden zo veel mogelijk geautomatiseerd plaats moeten vinden, waarbij een automatische

26

vergelijking van de SOLL- met de IST-situatie plaatsvindt. Hierbij dient te worden gecontroleerd of de gebruikers alleen die autorisaties toegewezen hebben gekregen, die zij nodig hebben bij de uitoefening van hun functie. Het dient dus bekend te zijn welke functie de medewerkers binnen de organisatie vervullen. Dit kan in veel gevallen achterhaald worden aan de hand van actuele gegevens vanuit het HR systeem. Bij de controle kan een autorisatiematrix als norm worden gebruikt. De in het systeem toegewezen autorisaties aan het gebruikers-ID, zouden vergeleken moeten worden met de autorisaties die de medewerker op basis van zijn of haar functie, vanuit de autorisatiematrix moet hebben. Er dient minimaal maandelijks te worden gecontroleerd of er gebruikers-ID’s bestaan die alle autorisaties hebben binnen informatiesystemen. Er dient te worden geverifieerd of dit terecht is. Ook dient er logging plaats te vinden van de activiteiten van deze gebruikers op de informatiesystemen. Bij de autorisatiecontroles en de daarbij behorende rapportages, dient extra aandacht te worden besteed aan autorisaties binnen kritische functionaliteit en functievermenging binnen autorisaties.

27

5 Hoe richt je met behulp van de techniek het beheer in van logische toegangsbeveiliging in SAP R/3? Het opzetten van een autorisatiestructuur, het goed opzetten van functiescheiding en het beheren van tijdelijke ruime autorisaties voor bijvoorbeeld systeembeheer “elevated access” wordt als lastig of moeilijk bestempeld. Daarnaast worden meer eisen gesteld aan de controle van de logische toegangsbeveiliging. In dit hoofdstuk wordt ingegaan op het opzetten van een goede SAP R/3 specifieke autorisatiestructuur. De voor handen zijnde technieken om logische toegangsbeveiliging te beheren en controleren worden besproken.

5.1 Een autorisatiestructuur SAP AG raadt aan de autorisatiestructuur te laten bestaan uit een twee lagen model. Een twee lagen model kan zowel organisatorisch uitgelegd worden als SAP technisch. Als organisatie en techniek goed op elkaar aansluiten, is het mogelijk dat iedere betrokken medewerker weet hoe de autorisatiestructuur technisch is opgezet en wat het organisatorisch inhoudt. Met andere woorden de samengestelde rol wordt gezien als functie en de enkele rol wordt gezien als een taak. Een functie kan uit meerdere taken bestaan. Hieronder zien we de grafische weergave van een autorisatiestructuur.

Organisatie concept. Het organisatorische concept is weergegeven in het groene vlak. Op een afdeling zijn medewerkers verantwoordelijk voor een aantal activiteiten, die zij uit hoofde van hun functie moeten uitvoeren.

28

Concluderend, een medewerker heeft een functie. Binnen de functie moet de medewerker een aantal activiteiten uitvoeren. Deze activiteiten worden logisch gegroepeerd in een taak. Een functie kan uit meerdere taken bestaan. SAP technisch concept. Het technische concept is weergegeven in het blauwe vlak. Het is de uitdaging van de beheerder het technische concept zo aan te laten sluiten dat het een spiegeling van het organisatorische concept is. Hieronder wordt het organisatorische concept vertaald naar het technische concept: Op een afdeling zijn medewerkers (gebruiker-id) verantwoordelijk voor een aantal activiteiten (transactiecodes, programma’s, etc.), die zij uit hoofde van hun functie (samengestelde rol) moeten uitvoeren. Concluderend, een medewerker (gebruiker-id) heeft een functie (samengestelde rol). Binnen de functie (samengestelde rol) moet de medewerker (gebruiker-id) een aantal activiteiten (transactiecodes, programma’s, etc.) uitvoeren. Bundelen we deze activiteiten (transactiecodes, programma’s, etc.) logisch gegroepeerd in een taak (enkele rol), dan ontstaat het plaatje zoals hierboven staat weergegeven. Deze aanpak zorgt voor een transparante autorisatiestructuur die aansluit op de organisatie van het bedrijf. Complexiteit bedrijfsonderdelen. Bedrijven die SAP R/3 gebruiken voor de ondersteuning van hun processen hebben meestal meerdere vestigingen, fabrieken, verkoopkantoren, distributiecentra, etc. Deze bedrijfsonderdelen worden in SAP R/3 organisatorische velden genoemd. Deze organisatorische velden worden gebruikt om onderscheid te maken tussen deze bedrijfsonderdelen. Door de organisatorische velden logisch te groeperen en in te delen is het mogelijk dat de taken (enkele rollen) door alle bedrijfsonderdelen kunnen worden gebruikt. SAP R/3 ondersteunt dit concept door gebruik te maken van zogenaamde afgeleide rollen. De organisatorische velden kunnen afzonderlijk van de rol worden onderhouden. Hierdoor is het mogelijk een zogenaamde template rol of master rol te bouwen, waarin de organisatorische velden met een dummy waarde worden gevuld. Deze template rol wordt gebruikt om afgeleide rollen te creëren voor elk bedrijfsonderdeel. Door middel van een goed doordachte naamgevingconventie, worden de complexiteit van de bedrijfsonderdelen gemakkelijk te doorgronden en te onderhouden. Zie bijlage II voor een voorbeeld van een opzet van een autorisatiestructuur.

5.2 Technieken binnen SAP R/3 Gezien de complexiteit van het autorisatieconcept binnen SAP R/3 is het aan te bevelen om hulpmiddelen te gebruiken bij het autorisatiebeheer en de controle op de autorisatie-inrichting. Er kan gebruik gemaakt worden van autorisatietools buiten SAP. SAP R/3 biedt standaard hulpmiddelen voor het beheer en de

29

controle van autorisaties, namelijk de Profielgenerator en het Autorisatie Infosysteem. 5.2.1 Profielgenerator De profielgenerator maakt het beheren van autorisaties gemakkelijker, door bepaalde processen te automatiseren en meer flexibiliteit in autorisatietaken te verstrekken. Het voordeel van de profielgenerator is dat er technische aspecten van autorisaties en autorisatie-objecten automatisch worden gegenereerd. Het model van de opbouw dat wordt gehanteerd voor rollen en profielen is flexibel. De profielgenerator maakt het mogelijk (vanaf SAP R/3 versie 4.6C) om het autorisatieconcept op te bouwen door middel van functierollen en/of taakrollen. Hierbij kan gebruik worden gemaakt van losse rollen en van samengestelde rollen. De profielgenerator gebruikt een topdown benadering voor het produceren van autorisaties. Het begint met de opbouw van een rolmenu met transacties en werkt omlaag tot aan de koppeling met individuele gebruikers-ID’s. De profielgenerator is beschikbaar vanaf SAP R/3 versie 3.1G en loopt op alle gesteunde platformen. 5.2.2 Autorisatie Infosysteem Ook het Autorisatie Infosysteem is beschikbaar vanaf SAP R/3 versie 3.1G. Het kan gebruikt worden om snel en gemakkelijk een overzicht van autorisaties, profielen, gebruikers en rollen te verkrijgen. Het biedt mogelijkheden om lijsten te maken met de volgende gegevens: • Gebruikers, rollen en profielen met bepaalde autorisaties; • Autorisaties die een bepaalde gebruiker, rol of profiel heeft; • Alle autorisaties; • Vergelijkingen van autorisaties van gebruikers, rollen en profielen; • Transacties die een gebruiker, rol of profiel kan uitvoeren; • Wijzigingen in gebruikers-ID’s, rollen en profielen. 5.2.3 Centrale gebruikers registratie Centrale gebruikers registratie wordt in SAP R/3 Central User Administration genoemd. De afkorting voor Central User Administration is CUA. CUA binnen SAP systemen valt onder het proces gebruikersbeheer. Binnen complexe systeem landschappen met meerdere systemen en cliënten, zijn de kosten van de administratie van gebruikers erg hoog. Gebruikers hebben toegang tot meer dan een systeem of cliënt om hun taak te kunnen volbrengen. Hiertoe hebben ze meerdere gebruiker –id’s tot hun geschikking. Gebruiker-id’s zijn cliënt afhankelijk, daarom moeten ze specifiek onderhouden worden in elke cliënt en elk systeem. Bijvoorbeeld het onderhouden van een nieuwe gebruiker moet handmatig worden aangelegt in de diverse systemen en diverse cliënts van alle SAP R/3 systemen waar de gebruiker geldig dient te zijn. Bij CUA worden alle gebruiker-id’s centraal onderhouden in een onderhoudsclient van een SAP systeem. Deze onderhoudscliënt communiceert met alle SAP systemen, waarvandaan het hele proces wordt ondersteund.

30

Voordelen van CUA De administratie van een heel systeemlandschap in een enkel central systeem Een overzicht van alle gebruikers informatie van het hele systeemlandschap Consistente gebruiker-id’s binnen het hele gebruikerslandschap Lokaal onderhoud van gebruiker-id’s is mogelijk Lagere kosten voor de administratie van gebruikers SAP AG raadt af de CUA op het productie systeem te installeren. En wel om de volgende redenen: Geen performance impact op het productie systeem Onafhankelijk van de geplande downtime van het productiesysteem Onderhoudsactiviteiten op CUA systeem hebben geen impact op het productie systeem Nadeel is wel dat er extra kosten zijn voor hardware en administratie. De volgende risico’s moeten organisaties in acht nemen bij het opzetten van een CUA: De technische realisatie van de CUA configuratie voldoet niet aan de organisatie van de gebruikers administratie. Het ontstaan van conflicten over de verantwoordelijkheid van gebruikers registratie Gebruikersadministratoren zijn niet opgeleid voor het gebruik van CUA.

5.3 Technieken buiten SAP R/3 Naast de technieken die SAP aanbiedt, zijn er ook geautomatiseerde systemen die helpen de logische toegangsbeveiliging van SAP R/3 te ondersteunen, zowel in beheer als bij controle. SAP AG heeft een systeem gekoppeld aan SAP R/3 genaamd SAP GRC. Daarnaast zijn bijvoorbeeld Approva met Bizrights en CSI met de CSI Accelerator voor handen. Deze systemen werken echter met extracten uit SAP R/3 en zijn daarom niet online. Dit in tegenstelling tot SAP GRC.

5.3.1 Geautomatiseerd systeem Er worden steeds meer eisen gesteld aan het beheren en controleren van de logische toegangscontrole in SAP R/3. Kon je vroeger nog een vergelijking maken tussen transactiecodes door middel van een autorisatiematrix, tegenwoordig zijn dit soort controles niet accuraat genoeg. Mede door geautomatiseerde systemen is het mogelijk geworden de logische toegangsbeveiliging zeer gedetailleerd in kaart te brengen. De geautomatiseerde systemen werken als volgt. De autorisatiematrix op transactiecode niveau geldt nog steeds als input voor het controleren van de autorisaties. Echter naast transactiecodes is het ook mogelijk autorisatie objecten erbij te betrekken, waardoor de controle nauwkeuriger wordt. Naast autorisatie objecten kunnen ook de waarden van deze objecten gecontroleerd worden. Ook de waarden als fabriek, bedrijfscode

31

en verkooporganisatie bijvoorbeeld. Deze informatie wordt in tabellen opgeslagen in het systeem. Hiermee kan het systeem controleren per gebruiker, rol, profiel of de juiste autorisaties zijn toegekend. In bijlage IV is een voorbeeld te vinden van een autorisatiematrix. In bijlage V zijn voorbeelden te vinden van detaillijsten met waarden (transactiecodes, autorisatie-objecten, transactiecodes) die een geautomatiseerd systeem gebruikt voor de controle van het autorisatie concept. Bedrijven worden in toenemende mate afhankelijk van systemen als SAP GRC, Bizrights en CSI accelerator. Het systeem kan ingezet worden bij de volgende processen: 1. Ondersteuning bij autorisatieaanvragen • Vooraf controleren of functievermenging optreedt 2. Ondersteuning bij het opstellen van rapportages • Controle op gebruikers-id’s die langer dan 60 of 90 dagen niet zijn aangelogd • 100% controle functievermenging 3. Ondersteuning bij tijdelijk ruime autorisaties op productieomgeving • Log instellen op gebruikers-id tijdens werkzaamheden met ruime autorisaties op de productieomgeving • Rapportage met alle gebruikers-id’s over een bepaalde periode met ruime autorisaties

6 Nawoord Nu de theorie is toegepast op de praktijk ligt het voor de hand dat organisaties hier gelijk mee aan de slag kunnen. Echter het handvat wat hier nu ligt heeft voorwaarden en beperkingen voor een succesvolle implementatie. Organisaties moeten goed beseffen dat niet alleen de IT afdeling verantwoordelijk is voor logische toegangsbeveiliging, maar ook alle andere afdelingen. Onvoorwaardelijke steun van zowel het management als alle geledingen van de organisatie is onontbeerlijk voor een goede logische toegangsbeveiliging. De organisatie zal keuzes moeten maken voor wat betreft een autorisatiestructuur. Deze keuze bepaald voor een deel al de keuze van een geautomatiseerd systeem. Daarnaast zal deze best practice niet of gedeeltelijk niet werken voor andere systemen, denk hierbij aan SAP CRM, SAP APO, SAP BW of AFAS ERP software, SSA Global (Baan). Logische toegangsbeveiliging in SAP implementeren of verbeteren kan niet in een keer. Daarvoor is de materie te complex. Ontbreekt kennis en ervaring. Daarnaast zullen veel partijen betrokken moeten zijn voor het inrichten of verbeteren hiervan. Dit proces heeft tijd nodig om goed in de organisatie te landen.

32

De meest belangrijke voorwaarden en beperkingen zijn genoemd, echter logische toegangsbeveiliging is een onderwerp wat nu en in de toekomst aandacht blijf eisen. Dat moet ook, want de ontwikkelingen staan niet stil. Bekijken we de toekomst van logische toegangsbeveiliging in SAP R/3, dan spreekt SAP AG al over termen als single sign-on, geïntegreerd binnen een identity management systeem. Hierdoor zal het proces gebruikersbeheer geheel worden herzien. Daarnaast besteedt SAP AG steeds meer aandacht aan de SAP GRC applicatie, onder andere risico-analyse en beheersen van functiescheiding. Genoeg stof voor een volgend scriptieonderwerp. Kortom logische toegangsbeveiliging in SAP R/3 is constant in beweging. Daarom moeten organisaties voordurend kijken naar toepassingen om logische toegangsbeveiliging goed te beheren en te controleren. Zelfreflectie Tijdens mijn scriptie ben ik erachter gekomen dat mijn denkproces erg slordig is. Dat is een eigenschap van mij, dat komt door het feit dat de autorisaties in SAP R/3 in feite geen geheimen meer voor mij kennen. Hierdoor is het voor mij erg logisch een paar stappen over te slaan, echter voor een buitenstaander is dat niet te begrijpen. Door deze scriptie en de gesprekken met Bart Bokhorst is het duidelijk geworden dat ik hier nu en in de toekomst aan zal moeten blijven werken. Ik ben dan ook blij dat hier nu een stuk ligt waar organisaties mee uit de voeten kunnen. Daarom presenteer ik met gepaste trots mijn scriptie.

33

Bijlage: I Literatuur Internet Wikipedia.com Informatiebeveiliging SOX – Sarbanes - Oxley wet. Toegangscontrole IAM – Identity management and access management LDAP - Lightweight Directory Access Protocol SAPSecurityonline.com CUA – Central User Administration sap.com/netherlands/solutions/grc/index.epx Literatuur ISO/IEC 27002 Information technology – Security techniques – Code of practice for information security management Bestuurlijke informatieverzorging Deel 1: Algemene grondslagen – Auteurs Starreveld, Van Leeuwen en Van Nimwegen SAP Authorization System – IBM Business Consulting SAP Security and Authorizations – Mario Linkies, Frank Off Artikelen Autorisatie bij het KLPD middels RBAC in SAP (deel 1)- Auteurs Ir. A.J. van Dijk RE en A.L.P. Algra RBAC: gewoon doen – Auteurs Peter Mienes en Bart Bokhorst ERP postimplementation problems - Auteur Yusuf Musaji Auditing Security and Privacy in ERP Applications – Auteur S. Anantha Sayana Handreiking Identiteiten- en Autorisatiebeheer – Auteurs Robbert Bosch, Frans Calor, Job Couwenberg, Coen de Jonge, André Koot, Jan Wessels De (on)beheersbaarheid van Toegangsbeveiliging – Auteurs Ing. P. Mienes RE en B. Bokhorst RE RA Internetsites voor genoemde systemen sap.com/solutions/grc/index.epx csi4global.com approva.net

34

Bijlage: II Systeemparameter instellingen Voorbeeld van systeemparameter instellingen op een ontwikkelsysteem van SAP R/3

35

Bijlage: III Codificatie formulier Voorbeeld codificatie formulier.

36

Bijlage: IV Autorisatiematrix Voorbeeld autorisatiematrix. Normenkader voor het controleren van functievermenging.

De matrix is niet duidelijk af te lezen, maar een norm die hier wordt vermeld is: Er treed functievermenging op als een gebruiker toegang heeft tot Maintain Vendor Masterdata (Purchasing) en Maintain Purchase Orders. M.a.w. Onderhoud (aanleggen, wijzigen) van stamgegevens van leveranciers en Onderhoud (aanleggen, wijzigen) van bestellingen mogen niet samengevoegd zijn bij een gebruiker.

37

Bijlage: V Audit rapport Voorbeeld audit rapport Een voorbeeld van een audit rapport voor het controleren van functievermenging. Het voorbeeld is gehaald uit de CSI Accelerator Hierin is te zien welke waarden worden gecontroleerd.

Audit Report

CSI Authorization Auditor - Release 7 Reference Process Subject Variant

Rating Sub Process Logical System Criticality

AXXXXASSEA (1) Asset Accounting Maintain Asset Master Data (Don't use variant)

Analysis: Multiple run, Second level AND/OR: AND-logic S_TCODE: YES *

NORM: NO Filter on: *

NC Master Data ZCC3010 SOX_H EXECUTED

Audited Authorization Objects Object A_S_ANLGR A_S_ANLGR A_S_ANLGR A_S_ANLKL A_S_ANLKL A_S_ANLKL

Field ACTVT ACTVT ACTVT ACTVT ACTVT ACTVT

Value 01 02 05 01 02 05

Audited Transaction codes Transaction Code

Description

AS01 AS02 AS05 AS06 AS11 AS21 AS22 AS24 AS25 AS26 AS91 AS92 AT01 AT02 AT91 AT92

Create Asset Master Record Change Asset Master Record Block Asset Master Record Delete Asset Record/Mark for Delet. Create Asset Sub-Number Create Group Asset Change Group Asset Create Group Asset Sub-Number Block group asset Mark group asset for deletion Create Old Asset Change Old Asset Create Asset Master Record (old) Change Asset Master Record (old) Create Old Asset (old) Change Old Asset (old)

Number of users that meet the criteria: 4 the executed flag)

(4 user(s) have Tcode; 0 user(s) are in the norm; 0 user(s) have

User type/status (*) See legenda at the bottom of this report Type/ Status Number of users AA

4

Number of users (TCode) 4

Profiles causing the authorization value access Number of Users

Role/Profile

38

1 RDXX_ACMAD (Maintain fixed assets master data Argyle global) 2 RDXX_APPOS (Maintain fixed assets (periodic) postings - Argyle) 3 RDXX_KCOAM (Maintain overhead accounting master data - Argyle)

3 3 3

Profiles causing the authorization value access Role/Profile 4 RXXX-BEXPR (Support function for programmers (SAP minus)) 5 RXXX-BEXTN (Support function for consultants (SAP minus))

Number of Users 1 1

Profiles causing the S_TCODE authorization value access Role/Profile 1 RDXX_ACMAD (Maintain fixed assets master data Argyle global) 2 RDXX_APPOS (Maintain fixed assets (periodic) postings - Argyle) 3 RXXX-BEXPR (Support function for programmers (SAP minus)) 4 RXXX-BEXTN (Support function for consultants (SAP minus))

Issues/Findings Risk/Opportunity The asset master record consists of two categories of information: General master data and Depreciation data. General master data includes general information (description, inventory note, last inventory date, etc.), account assignment (which links the record to G/L account information), posting information (capitalization date, acquisition date), time dependent information (business area, cost center, location, plant, etc.), real estate information, leasing conditions (agreement number, length of lease), investment support measures, information on the origins of the asset, Insurance data and evaluation groups. Depreciation related information contains depreciation key (kind of depreciation), useful life, ordinary depreciation start date, change over year (when changing from declining balance to straight-line method), index (calculate annually increasing replacement values), variable depreciation amounts, and scrap value. Unauthorized or inappropriate changes to these master data can have consequences like: - incorrect valuation of assets due to wrong depreciations - unnoticed removal (theft) of asset master records - increase fraud sensitivity - incorrect fixed assets physical inventory and possible compliance issues (legal - proof of ownership, tax and investment deductions, Sales & Use Tax, regulatory, )

Recommendations Management Response Control Objective Suggested Controls

39

Number of Users 3 3 1 1

40