Executive Summary
Hvis din kundeportal viser de rigtige data til de forkerte mennesker, har du ikke et teknisk irritationsmoment. Du har en forretningsrisiko. I en dansk SMV kan en enkelt fejl i adgangsstyring betyde, at kunde A ser kunde B’s ordrestatus, at en medarbejder får adgang til løndata, eller at en leverandør kan åbne dokumenter, de aldrig skulle have set. Det er præcis derfor, OWASP placerer Broken Access Control som den mest kritiske webapp-risiko, og derfor en kundeportal er et oplagt sted at teste først.
Den gode nyhed er, at du ikke behøver bestille en stor, tung sikkerhedsøvelse for at få svar. En defensiv pentest af adgangsstyring kan afgrænses, så du får et klart ja eller nej på det vigtigste spørgsmål: Kan kunder, medarbejdere eller leverandører se hinandens data i praksis? Når testen bygges med et lille scope, klare acceptkriterier, executive summary og retest, bliver den et ledelsesværktøj og ikke bare en teknisk rapport.
For mange SMV’er handler det ikke kun om sikkerhed, men også om kundetillid, GDPR og dokumentation over for samarbejdspartnere. GDPR artikel 32 kræver passende tekniske og organisatoriske sikkerhedsforanstaltninger, og NIST SP 800-115 peger på sikkerhedstest som en praktisk måde at finde svagheder og verificere, om krav faktisk virker. Derfor giver en målrettet test af kundeportalens adgangsstyring mening, især hvis du vil have ro i maven uden at drukne i teknik.
Hvorfor adgangsstyring er et ledelsesproblem
Mange ledere tænker om cybersikkerhed som phishing, ransomware og driftstop. Det er forståeligt. Men i kundeportaler og interne websystemer er adgangsstyring ofte der, hvor datalæk opstår uden dramatik. Ingen alarmer. Ingen krypterede filer. Bare de forkerte øjne på de forkerte data.
Det kan ske på helt almindelige måder. En kunde ændrer et tal i en webadresse og ser en anden kundes faktura. En ekstern samarbejdspartner kan åbne dokumenter fra et andet projekt. En intern bruger med for brede rettigheder kan hente hele kundelister ud, selv om rollen kun burde give adgang til egne sager. OWASP Web Security Testing Guide beskriver netop adgangskontrol som et område, der skal testes systematisk, fordi fejl ofte ligger i logikken mellem roller, objekter og dataadskillelse.
For en SMV er konsekvensen sjældent kun teknisk. Det kan koste på tre fronter samtidig. Først taber du tillid hos kunden. Dernæst får du et GDPR-spørgsmål, fordi personoplysninger ikke har været tilstrækkeligt beskyttet. Til sidst får ledelsen et dokumentationsproblem, hvis en kunde, revisor eller større samarbejdspartner spørger, hvordan I har verificeret, at portalen faktisk holder data adskilt.
Hvis du vil arbejde mere struktureret med sikkerhedskrav og dokumentation, er det naturligt at koble testen med en modenhedsanalyse. Hvis du først vil have vurderet den tekniske basis i miljøet, kan et sikkerhedstjek være et godt supplement før eller efter pentesten.
Hvad en defensiv pentest faktisk skal svare på
En defensiv pentest af adgangsstyring skal ikke være en demonstration af, hvor kreativ en tester kan være. Den skal svare på, om jeres vigtigste kontrol virker i virkeligheden. I dette tilfælde om data holdes adskilt mellem de roller og relationer, som portalen er bygget til.
Det betyder, at scope bør være lille og skarpt. Ikke hele platformen. Ikke hele infrastrukturen. Start med de vigtigste dataområder i kundeportalen. Typisk kontosider, dokumentarkiv, ordreoversigt, supportsager, brugeradministration og eventuelle API-kald, som portal eller app bruger i baggrunden. Hvis portalen også bruges af medarbejdere eller leverandører, skal de roller med i testen.
Et ledelsesvenligt scope kan formuleres sådan her: Test om kunder kun kan se egne data, om medarbejdere kun kan se det de skal, og om leverandører kun kan se de projekter eller oplysninger, de er autoriseret til. Det er konkret. Det er målbart. Og det kan ende i et klart ja eller nej.
Hvis du vil forstå selve rammen for en penetrationstest bedre, kan du læse mere om pentest som ydelse. Pointen her er, at testen skal designes som en forretningskontrol. Ikke som en bred teknisk øvelse med 50 sides output, som ingen i ledelsen får læst.
Sådan afgrænser du testen, så resultatet bliver brugbart
Den mest almindelige fejl er at bestille for bredt. Når scope bliver uklart, bliver resultatet også uklart. En lille, defensiv test fungerer bedre, når du på forhånd beslutter hvilke relationer og hvilke data der er vigtigst at bevise noget om.
Et godt udgangspunkt i en dansk SMV er at vælge tre til fem kritiske scenarier. For eksempel om en kunde kan se en anden kundes dokumenter, om en medarbejder med almindelig supportrolle kan tilgå alle kunders data, og om en leverandør kan hoppe mellem projekter eller kunder. Hvis portalen håndterer personoplysninger, priser, kontrakter eller supportsager, er det naturlige testobjekter.
Bed også om tydelige stopregler. Testen må ikke ændre produktionsdata, sende rigtige kundemails eller belaste systemet unødigt. Her er NIST nyttig, fordi guiden fremhæver planlægning, afgrænsning og dokumentation som en central del af testen, ikke bare selve udførelsen. NIST SP 800-115 beskriver netop test som noget, der skal planlægges, analyseres og omsættes til afhjælpning.
Et praktisk setup kan være:
- 2 til 4 brugerroller med realistiske testkonti
- 3 til 5 kritiske datatyper, for eksempel kundedokumenter, ordredata og supportsager
- 1 afgrænset testperiode
- Klare stopregler for drift og data
- Fast retest efter rettelser
Hvis du arbejder med ledelse eller bestyrelse om ansvar, prioritering og risikobillede, kan det være relevant at koble resultaterne til en workshop for ledelse og bestyrelse, så fund bliver omsat til beslutninger og ejerskab.
De acceptkriterier ledelsen bør kræve
En pentest af adgangsstyring bliver først værdifuld, når alle ved, hvornår testen er bestået. Her kommer acceptkriterier ind. De gør dialogen enkel mellem ledelse, udvikling, drift og leverandør.
For denne type test bør du kræve kriterier, som kan læses uden teknisk baggrund. Eksempelvis at ingen testkonto må kunne se eller hente data fra andre kunder. At en medarbejderrolle ikke må få adgang til mere end den dokumenterede opgave kræver. At en leverandørrolle ikke må kunne bevæge sig ud af eget projekt- eller kundeområde. At direkte opslag via URL, ID eller API ikke må give adgang til data uden gyldig rettighed. Og at alle fund verificeres igen i en retest, når de er rettet.
Det er her, defensive pentests skaber ro. De oversætter et diffust spørgsmål til en konkret beslutning: Virker vores dataadskillelse eller ikke. Hvis ikke, hvor er bruddet, hvor alvorligt er det, og hvad skal lukkes først.
OWASP fremhæver, at broken access control ikke kun handler om login, men også om omgåelse af autorisation, adgang til andres records og forkert håndhævelse af roller og regler. OWASP A01 Broken Access Control er derfor et stærkt referencepunkt, når du vil stille skarpe krav uden at tale i tekniske detaljer.
Hvad du skal forlange i rapporten
Mange pentest-rapporter fejler ikke på teknik, men på form. De er skrevet til specialister, selv om beslutningen ligger hos ledelsen. Derfor bør du bede om to lag i leverancen.
Først et executive summary på én til to sider. Det skal forklare hvilke forretningskritiske scenarier der blev testet, om dataadskillelsen holdt, hvad de mest alvorlige fund betyder i praksis, og hvad der bør ske nu. Ikke som dramatik. Bare som klar prioritering.
Dernæst en teknisk del til dem, der skal rette fejlene. Her må der gerne være detaljer om trin, observationer og forslag til afhjælpning. Men for ledelsen er det vigtigste at rapporten svarer på fem spørgsmål: Hvad blev testet. Hvad virkede ikke. Hvem ejer opgaven. Hvad er fristen. Og hvornår kommer retest.
Hvis din virksomhed arbejder med en mere løbende sikkerhedsmodel, kan fund og opfølgning med fordel kobles til Forkant™ som fast rytme for opfølgning, dokumentation og prioritering. Hvis menneskelige arbejdsgange omkring adgang, deling og godkendelser også spiller ind, kan awareness-træning være relevant som supplement til de tekniske rettelser.
Et realistisk eksempel fra en dansk SMV
Forestil dig en ordreportal, hvor kunder logger ind for at se status, fakturaer og servicerapporter. Internt bruger kundeservice den samme portal med udvidede rettigheder, og en ekstern montør har adgang til udvalgte sager. På papiret ser rettighedsmodellen fin ud. I praksis er det først en test, der viser om den holder.
I en defensiv pentest vil man ikke starte med at bryde alt muligt ned. Man vil starte med de sandsynlige kontrolbrud. Kan kunde A tilgå kunde B’s rapport ved at ændre et id i adressen. Kan supportbrugeren eksportere mere data end rollen kræver. Kan montøren se sager uden for eget område. Kan API-kald returnere data, som brugerfladen skjuler, men backend stadig udleverer.
Det er den type spørgsmål, der giver mening for en ejerleder eller driftschef. For hvis svaret er ja, har du et konkret hul. Hvis svaret er nej, har du dokumentation for, at en vigtig kontrol faktisk virker. Det er den ro i maven mange mangler.
Næste skridt: bestil et lille ja eller nej, ikke et stort projekt
Hvis du vil gøre dette håndterbart, så start med at vælge én kundeportal eller ét internt system, hvor dataadskillelse er forretningskritisk. Skriv tre scenarier ned, som aldrig må kunne ske. Beslut hvilke roller der skal med. Kræv fem klare acceptkriterier, et executive summary og en retest. Så har du allerede gjort testen mere værdifuld end mange større sikkerhedsprojekter.
Et godt næste skridt er at samle portalansvarlig, IT-ansvarlig og forretning i 30 minutter og blive enige om scope. Brug mødet til at beslutte hvilke data der er vigtigst, hvilke roller der er i spil, og hvilket ja eller nej ledelsen vil have svar på. Derefter kan du bruge en målrettet pentest som et trygt beslutningsværktøj, og hvis I vil sætte indsatsen ind i en større compliance- og styringsramme, kan en modenhedsanalyse hjælpe med at prioritere næste skridt.