---
title: Tenant-isolasjon: når én kunde kan se en annen
description: Deler kundene deres samme installasjon, er isolasjonen mellom dem en av de få feilene som kan koste dere alle kundene samtidig. Her er hva som ryker, og hvorfor.
updated: 2026-08-21
canonical: https://glippen.no/svakheter/tenant-isolasjon
author: Erik Nilsen
cwe: CWE-639
---

# Tenant-isolasjon: når én kunde kan se en annen

Tenant-isolasjon er skillet som sikrer at kunder som deler den samme installasjonen av en tjeneste, ikke kan nå hverandres data.

Det er tilgangskontroll ett nivå over brukeren, og konsekvensen er tilsvarende større: én feil her rammer ikke én bruker, men potensielt hele kundelisten.

## Hva som kan se dette

Dette er usynlig utenfra. En passiv sjekk av domenet sier ingenting om hvordan applikasjonen skiller kundene fra hverandre, og en skanner har ingen måte å vite hvem som skulle hatt tilgang til hva. Feilen er stille også innenfra: alt ser riktig ut for den vanlige brukeren, helt til noen setter opp to kunder og prøver grensen med vilje.

- Gratis ekstern sjekk: ser det ikke
- Egenvurdering: ser det ikke

## Hvordan den avdekkes

Tenant-isolasjon er tilgangskontroll på et nivå over brukeren. Spørsmålet er ikke om Kari kan se Pers data, men om alt hos kunde A er utilgjengelig for alle hos kunde B. Det er den samme klassen feil som IDOR, med en konsekvens som er en helt annen: én feil rammer ikke én bruker, men hele kundelisten.

Vi tester det med to kunder vi setter opp selv, ikke med to brukere hos samme kunde. Deretter går vi gjennom det samme som ellers, med ett tillegg: alt som identifiserer en kunde blir kontrollert overalt der det kan komme inn. Feilen sitter sjelden i innloggingen. Den sitter i et sted der kundetilhørigheten ble lest fra noe klienten sendte inn, i stedet for fra sesjonen.

Rapporter, eksporter, søk, vedlegg, varsler og bakgrunnsjobber er der vi finner den oftest. Det er funksjoner som er bygget etter at isolasjonen var på plass, og som henter data på en litt annen måte enn resten.

Integrasjoner mot andre systemer er den andre. Data som går ut til et tredje system og kommer tilbake, har vært utenfor det som håndhever isolasjonen, og kommer ofte tilbake uten den.

## Hva som lukker den

### Kundetilhørighet leses aldri fra forespørselen

Hvilken kunde en innlogget bruker tilhører, er noe systemet vet fra sesjonen. Kommer det inn som en parameter, en header eller et felt i en forespørsel, kan det endres av den som sender den.

Dette er den enkeltårsaken vi ser oftest, og den er som regel innført med gode hensikter: noen trengte å kunne bytte kontekst, for eksempel for support, og løsningen ble et felt alle kan sende.

### Isolasjonen hører hjemme i datalaget

Ligger kontrollen i hver enkelt spørring, er den så sterk som utviklerens hukommelse den dagen spørringen ble skrevet. Det holder en stund, og så kommer det en rapport eller en eksport til.

Det som holder er at kundeavgrensningen ligger i laget alle spørringer går gjennom, slik at en spørring uten avgrensning enten er umulig å skrive eller feiler høylytt. Hvordan det gjøres, avhenger av basen og rammeverket dere har, og det er en av tingene vi går gjennom sammen etterpå.

### Se over det som kjører uten en bruker

Bakgrunnsjobber, planlagte oppgaver og administrasjonsverktøy kjører ofte med utvidede rettigheter og uten en innlogget bruker å avgrense mot. Det er en legitim nødvendighet, og det er samtidig stedet der isolasjonen oftest er slått av permanent.

Gå gjennom hver av dem og still ett spørsmål: hvis denne jobben fikk feil kunde-id, hva ville skje. Svaret bør være at den stopper.

### Dokumenter at det er prøvd

Selger dere til enterprise eller offentlig sektor, kommer spørsmålet om kundeseparasjon i sikkerhetsskjemaet før eller siden, og det er formulert som et spørsmål om hva dere har gjort for å kontrollere det. Da er en test med to oppsatte kunder og en rapport som sier hva som ble prøvd, et konkret svar der de fleste leverandører har en formulering.

## Kilder

- [OWASP Top 10: A01 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
- [OWASP API Security Top 10: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)