Het VNSG Magazine, het vakblad voor alle SAP gebruikers in Nederland en Vlaanderen, verschijnt 5 keer per jaar. PTWEE geeft in iedere editie een praktische tip over testen in een SAP omgeving. Deze tip gaat over het testen van SAP autorisaties.
Testen van autorisaties
Bij SAP implementaties of upgrades wordt vaak te weinig of te laat aandacht gegeven aan het testen van autorisaties. De functionaliteit wordt in eerste instantie getest op de juiste werking, zonder de bijbehorende rollen en rechten in SAP. Dat is begrijpelijk, maar wat is dan een goed moment om de autorisaties te testen, zonder de functionele tests te verstoren? En wat is een goede aanpak voor het testen van autorisaties? Deze tip bevat handvatten voor het goed testen van SAP autorisaties.
Positieve en negatieve tests
Bij het testen van autorisaties is er een groot verschil tussen zogenaamde positieve en negatieve tests. Positieve tests worden uitgevoerd om te controleren of een gebruiker de benodigde autorisaties heeft om zijn of haar werk goed uit te kunnen voeren in SAP. Negatieve tests worden uitgevoerd om te voorkomen dat gebruikers bevoegdheden hebben die ze niet nodig (of niet mogen) hebben in hun rol. Dit kan onbewuste schade door gebruikers veroorzaken of zelfs leiden tot misbruik. Om de SAP beveiliging in een bredere context te testen kunnen aanvullende negatieve tests worden uitgevoerd. Dit om te voorkomen dat onbevoegden zich toegang kunnen verschaffen tot het SAP systeem. De zogenaamde OWASP top 10 kan daarbij nuttige input zijn. Het Open Web Application Security Project (OWASP) is een wereldwijde organisatie die zich bezighoudt met het vinden en bestrijden van lekken in applicaties. Jaarlijks wordt een top 10 van meest voorkomende security bedreigingen gepubliceerd (zie www.owasp.org).
Risicoanalyse
De eerste stap om te komen tot een goede testaanpak is het uitvoeren van een risicoanalyse voor het kwaliteitsattribuut beveiliging. Voor de verschillende SAP onderdelen, (sub)processen en/of interfaces wordt bepaald welke beveiligingsrisico’s er zijn. Daarbij wordt, net zoals bij de risicoanalyse op functionaliteit het geval is, per onderdeel de foutkans en de schade bepaald.
De combinaties van foutkans en schade bepalen uiteindelijk de risicoklassen (zie ook de tip ‘Baseer de testaanpak op risico’s’ in het VNSG magazine van december 2011).
Testaanpak
De uitkomsten van de risicoanalyse worden gebruikt om de diepgang en aanpak van het testen van de verschillende onderdelen te bepalen. Zo kan er bijvoorbeeld worden besloten om bij de hoog risico gebieden extra veel aandacht te besteden aan negatieve tests. Voor de laag risico onderdelen worden de autorisaties alleen positief getest. Dit gebeurt dan impliciet, tijdens de gebruikers acceptatie test (GAT).
Een goede manier om te komen tot negatieve testcases is het definiëren van zogenaamde ‘abuse- cases’. Het doel hiervan is leren denken als iemand die misbruik zou willen maken van het SAP systeem. Abuse-cases maken het begrijpen van de mogelijke beveiligingsissues voor gebruikers zonder beveiligingskennis makkelijker. Vervolgens worden bij de abuse-cases verschillende negatieve testcases gespecificeerd. Zowel het in kaart brengen van de abuse-cases als het specificeren van de negatieve testcases is een taak voor de tester.
Binnen de testaanpak moet ook het onderscheid tussen statische en dynamische tests duidelijk naar voren komen. De eerste tests die worden uitgevoerd door de bouwer van de autorisatieprofielen zijn voornamelijk statisch van aard. Ze zijn bedoeld om te verifiëren of de profielen voldoen aan de requirements die zijn vastgelegd in de vorm van een autorisatiematrix. Deze tests zijn onderdeel van de unittest (UT). Dynamische tests zijn tests waarbij de autorisaties worden getest middels het uitvoeren van verschillende functionele handelingen in SAP. Deze tests worden voornamelijk uitgevoerd in de systeemintegratietest (SIT) en de gebruikers acceptatie test (GAT).
Tijdens de SIT wordt in eerste instantie de functionaliteit getest zonder de beperking van autorisaties. De reden daarvoor is dat eerst de goede functionele werking van het systeem moet worden aangetoond. Wanneer met de rollen en bijbehorende autorisaties wordt getest dan wordt het lastig om functionele- en autorisatie bevindingen van elkaar te onderscheiden. Daarom is het verstandig om dit zuiver te houden.
Daarnaast kunnen de eerste dynamische autorisatie tests tijdens de SIT worden uitgevoerd. Bijvoorbeeld voor alleen de hoog risico onderdelen. Op basis van de ‘abuse-cases’ die zijn opgesteld kunnen de testcases worden ontworpen en uitgevoerd. De volgende dynamische tests worden uitgevoerd tijdens de gebruikers acceptatie test (GAT). In deze fase worden de belangrijkste scenario’s getest met gebruikmaking van de juiste SAP rollen en bijbehorende bevoegdheden. Daarmee worden de positieve tests uitgevoerd. Eventueel kunnen aan de scenario’s extra stappen worden toegevoegd voor extra negatieve autorisatie tests tijdens de GAT (‘kan ik iets wat niet zou moeten kunnen’).
Fasering
De verschillende onderdelen van het testtraject zijn in onderstaand afbeelding afgezet tegen de ASAP fasering. Het opstellen van ‘abuse-cases’ kan al in een vroeg stadium gebeuren. Gedeeltelijk tijdens het uitvoeren van de risico analyse en daarnaast door deel te nemen aan blueprint workshops.
Conclusie
Het mag duidelijk zijn dat het goed testen van autorisaties en beveiliging een aparte aanpak vereist. Dit wordt vaak onderschat waardoor pas in een (te) laat stadium wordt bepaald hoe de autorisaties worden getest. Een goede testmanager voorkomt dit en geeft het testen van autorisaties en beveiliging een gepaste plek in de teststrategie.
