Invitationer og brugeroprettelse på tværs af kunder

En invitation er den hurtigste vej ind i en kundes del af produktet, og derfor er den også et af de steder, hvor grænsen mellem kunderne bliver sat på prøve hver eneste dag. Hvad testen skal dække, hviler på et enkelt spørgsmål: kan en bruger komme ind hos en kunde, få en rolle eller beholde en adgang, som kundens egen administrator ikke har givet?

Funktionerne til at invitere, oprette, flytte og fjerne brugere er ikke nødvendigvis dem, kunderne nævner først. Men når de spørger til adskillelsen mellem kunder, kan det være netop her, deres egne sikkerhedsfolk kigger, fordi det er kundens administrator, der bruger funktionerne, og kundens ansvar, hvis en forkert person får adgang.

Hvor grænsen bliver krydset i det daglige

I et produkt med mange kunder flytter brugerne sig hele tiden. Nogle eksempler, der rejser hvert sit spørgsmål:

Invitation fra kundens administrator · den inviterede får adgang til netop den kunde og den rolle, der blev valgt, og intet andet.
Selvoprettelse · en bruger opretter sig selv og bliver knyttet til en kunde, fx ud fra sin mailadresse.
Brugere hos flere kunder · en revisor, en konsulent eller en bogholder, der arbejder for flere af jeres kunder med samme login.
Ændring af rolle · en bruger forfremmes eller får frataget rettigheder.
Fjernelse · en medarbejder stopper hos kunden og skal miste adgangen med det samme.
Overdragelse · ejerskabet af en kundekonto flyttes til en anden person.

Hver af dem er en almindelig funktion, men også et sted, hvor en fejl kan give adgang på tværs. Den britiske NCSC lægger vægt på, at andre kunder ikke må kunne tilgå, ændre eller påvirke en kundes opsætning, og brugeradministrationen er en stor del af den opsætning. → Multi-tenant: test af adskillelsen mellem kunderne

Hvad testen afprøver

En test af brugeradministrationen ser på funktionerne fra flere sider. Testeren bruger dem som kundens administrator, som almindelig bruger og som en, der slet ikke er inviteret, og ser, om resultatet svarer til det, rollen tillader.

Spørgsmålene er blandt andet:

Rækkevidden af en invitation · kan en invitation bruges til en anden kunde eller en anden rolle end den, der blev valgt?
Hvem der kan invitere · kan en bruger uden administratorrettigheder invitere andre eller give dem mere, end brugeren selv har?
Levetiden · gælder en invitation længere, end den burde, eller kan den bruges af en anden end modtageren?
Fjernelsen · mister en fjernet bruger adgangen overalt, også gennem API’et og igangværende sessioner?
Skiftet mellem kunder · ser en bruger, der arbejder for to kunder, kun den kunde, der er valgt i øjeblikket?

OWASP beskriver, hvordan mange roller, grupper og hierarkier gør kontrollen af, hvem der må hvad, svær at få rigtig. Brugeradministration er et sted, hvor det kan vise sig. → Roller og rettigheder i produktet

Det, I skal stille til rådighed

For at testen kan sige noget, skal den have noget at arbejde med. Det kræver mere forberedelse end en almindelig test af funktionerne:

Mindst to kunder · så testeren kan afprøve, om en invitation eller en bruger kan krydse grænsen.
Administratorer hos begge · med ret til at invitere og fjerne brugere.
En bruger, der er knyttet til flere kunder · hvis produktet tillader det.
Adgang til de mails, invitationerne sendes til · så hele forløbet kan følges.

Aftal også, om selvoprettelse er med, og hvilke regler der gælder for den hos de testkunder, der er sat op. Notér desuden, hvilke af jeres egne regler for adgangskoder, totrinslogin og udløb af invitationer der var slået til under testen. → Testlejere

Når kunderne bruger deres eget login

Mange erhvervskunder kobler produktet til deres eget login, så brugerne oprettes og fjernes automatisk fra kundens egen brugeradministration. Det flytter en del af ansvaret til kunden, men ikke det hele. Det er stadig jeres produkt, der afgør, hvilken kunde og hvilken rolle en bruger havner hos, og hvad der sker, når kunden fjerner en bruger hos sig selv.

Testen bør derfor se på samspillet: får en bruger, der kommer ind via kundens login, kun adgang til den kunde, koblingen er sat op til? Og fjernes adgangen i produktet, når den fjernes hos kunden? → Single sign-on mod kundernes egne login

Jeres egne medarbejdere som brugere

Nogle produkter lader jeres supportfolk logge ind som en bruger hos kunden eller blive inviteret ind i en kundes del af produktet for at hjælpe. Det er en bevidst åbning, og den skal behandles sådan: hvem kan gøre det, kan kunden se det, og forsvinder adgangen igen, når sagen er løst? → Supportadgang og administrationsmodul

Hvis jeres medarbejdere kan blive inviteret som almindelige brugere, kan det også være svært for kunden at se, at det er jer. Det er værd at tage stilling til, før kunden spørger.

Et tænkt eksempel: et softwarehus leverer et system til projektstyring, hvor kundens administrator kan invitere eksterne samarbejdspartnere ind i enkelte projekter. Samarbejdspartneren kan selv være kunde i produktet med sin egen virksomhed. Her skal testen vise, at den eksterne bruger kun ser det projekt, invitationen gjaldt, og at adgangen forsvinder, når projektet lukkes eller invitationen trækkes tilbage. Det er præcis den situation, kundens sikkerhedsfolk vil spørge til, fordi det er her, deres data bevidst deles med nogen uden for virksomheden.

Det skal I lade være med

Teste med én kunde · så kan testen ikke vise, om en invitation kan krydse grænsen.
Kun teste invitationen og ikke fjernelsen · det er fjernelsen, kunderne regner med, når en medarbejder stopper.
Glemme brugere hos flere kunder · det er netop dem, der står tættest på grænsen.
Lade API’et stå uden for testen af brugeradministration · samme regler skal gælde dér.
Love kunderne, at en fjernet bruger aldrig kan komme ind igen · beskriv, hvad testen afprøvede.

Hvad kan og ikke kan konkluderes

En test af brugeradministrationen kan vise, om invitationer, rolleændringer og fjernelser holdt sig inden for den rigtige kunde i de situationer, der blev afprøvet. Den siger ikke noget om kundernes egne beslutninger om, hvem der får adgang, eller om dele af produktet, der ikke var med. Hvad der blev afprøvet, skal fremgå af rapporten, så kunden kan læse det selv. → Omfangsafsnittet

Tjekliste til brugeradministrationen i testen

☐ Er invitation, selvoprettelse, rolleændring, fjernelse og overdragelse med i omfanget?
☐ Har testeren mindst to kunder med hver deres administrator?
☐ Er der en bruger, der er knyttet til flere kunder, hvis produktet tillader det?
☐ Er fjernelse afprøvet både i brugerfladen og gennem API’et?
☐ Er samspillet med kundernes eget login med, hvor det bruges?
☐ Er jeres egne medarbejderes adgang som brugere hos kunden vurderet?

Kilder

NCSC (UK): Principle 9, Secure user management: styring af brugere og roller, og at andre kunder ikke må kunne tilgå, ændre eller påvirke en kundes opsætning.
OWASP API Security Top 10 2023: Broken Function Level Authorization: komplekse roller, grupper og hierarkier gør kontrollen af adgang til funktioner svær.

Senest gennemgået: oktober 2026.