Egen instans vs. multi-tenant SaaS: hvad betyder det for jeres data?

Hvad er forskellen på egen instans og multi-tenant SaaS?

Egen instans og multi-tenant SaaS beskriver, hvordan en løsning adskiller kunder og deler ressourcer. Adskillelsen kan ligge i applikationen, databasen eller infrastrukturen; betegnelserne alene fortæller ikke, hvor data behandles.

I denne guide sammenligner vi to forenklede eksempler: en løsning med delt applikation og datalager og en løsning med en dedikeret applikation og database pr. kunde. I praksis findes blandingsformer. Vi kan bygge løsningen i jeres egne systemer.

I en multi-tenant-løsning deles nogle ressourcer mellem kunder, mens adskillelsen kan ske på flere lag. I vores eksempel på en egen instans er applikation og database dedikeret til én kunde; den fysiske infrastruktur og fælles tjenester kan stadig være delt. Placering, adgang, rettigheder og exit skal undersøges i den konkrete opsætning og aftale.

Multi-tenant betyder, at en løsning betjener flere kunder med deling af nogle ressourcer. Egen instans bruges her om en dedikeret applikation og database pr. kunde. Leverandører kan bruge begreberne forskelligt, så spørg hvilke lag der faktisk er adskilt.

I guiden gennemgår vi praktiske hensyn ved de to eksempelmodeller: drift, GDPR, datahåndtering og exit. Brug spørgsmålene til at undersøge en konkret løsning frem for at udlede dens egenskaber alene af etiketten.

Hvad er forskellen: helt konkret?

Som forenklet billede kan en delt løsning sammenlignes med et kontorfællesskab, og en dedikeret applikation og database med særskilte kontorer. Billedet siger ikke, om bygningen, forsyningen eller andre fælles tjenester er adskilt; tilsvarende kan software være isoleret på ét lag og dele ressourcer på et andet.

Multi-tenant: delte ressourcer på forskellige lag

En multi-tenant-løsning kan bruge en fælles applikation og en delt database med kundespecifik adgang, eksempelvis via et kunde-id. Andre løsninger har separate databaser eller applikationer på delt infrastruktur. Spørg derfor, hvad der deles, og hvordan adskillelsen håndhæves.

Logisk adskillelse er ikke i sig selv usikker, men kræver korrekt adgangsstyring og drift. Om kunder deler database, fysisk lager eller andre tjenester afhænger af opsætningen. Betegnelsen multi-tenant er ikke dokumentation for et bestemt datalayout.

Egen instans: jeres egen kørende kopi

I guidens eksempel på en egen instans er applikationen og databasen dedikeret til én virksomhed. Netværk, servere eller støttetjenester kan stadig være delt, så en egen instans garanterer ikke fysisk isolation. Instansen kan hostes af leverandøren eller, hvis produkt og vilkår tillader det, på jeres egen infrastruktur.

Dedikerede instanser kan bygge på samme standardkode og datamodel. Opdateringer kan ske samlet eller gradvist efter den valgte driftsmodel, og der kan være flere versioner i brug. Standardisering og kundeadskillelse er forskellige egenskaber, som begge skal beskrives.

Hvorfor vælger leverandører multi-tenant?

Svaret er økonomi og drift, set fra leverandørens side.

Stordriftsfordele for leverandøren

Deling af ressourcer kan sænke omkostningen pr. kunde og samle dele af drift og vedligehold. Besparelsen afhænger af skala, belastning og krav til isolation. En løsning kan stadig bestå af flere installationer og databaser, som skal opdateres og overvåges.

Hurtigere udrulning af nye funktioner

Fælles software kan gøre det muligt at udrulle ændringer til mange kunder. Udrulningen kan også ske gradvist, efter kundeaftaler eller med funktioner aktiveret for udvalgte grupper. Samtidig opdatering og adgang til samme funktioner følger ikke automatisk af multi-tenant.

Vurder fordele og kontrol i den konkrete aftale

Undersøg, hvordan driftsmodellen påvirker pris, opdateringer og jeres kontrol over data og integrationer. En delt løsning kan give stordriftsfordele, men de konkrete kundeegenskaber og exitvilkår skal fremgå af produkt og aftale.

GDPR og databehandleraftaler: hvad ændrer en egen instans?

Uanset model gælder databeskyttelsesforordningen. Når en leverandør behandler personoplysninger på jeres vegne, er jeres virksomhed dataansvarlig og leverandøren databehandler, og så kræver reglerne en databehandleraftale. Datatilsynet forklarer rollefordelingen mellem dataansvarlig og databehandler i deres vejledning om rollefordeling, og EU's samlede krav til virksomheders håndtering af persondata er beskrevet i EU's GDPR-gennemgang for virksomheder.

GDPR stiller ikke krav om den ene eller anden arkitektur. Men arkitekturen påvirker, hvor let det er at leve op til kravene, og hvor let det er at dokumentere det:

Overblik over hvor data bor

Som dataansvarlig skal I kunne redegøre for, hvor personoplysninger behandles, og hvem der har adgang. I begge modeller skal I kortlægge alle behandlingssteder, herunder hos model-, lognings- og driftsleverandører, og undersøge de relevante aftaler. Antallet af led og kvaliteten af dokumentationen afhænger af den konkrete løsning.

Sletning og indsigt

Registreredes rettigheder (indsigt, berigtigelse, sletning) skal kunne efterleves i praksis. En separat database kan give et afgrænset sted at kontrollere sletning, men sikkerhedskopier, logning og underleverandører skal med i kontrollen. I begge modeller skal I undersøge, hvordan sletning dokumenteres på tværs af relevante lagre og tjenester.

Adgangsbegrænsning

Jo færre systemer og personer der kan tilgå jeres data, desto lettere er det at holde adgangen på et minimum. En dedikeret instans kan begrænse eksponeringen mellem kunder; angrebsfladen afhænger også af adgangsstyring, integrationer og drift.

Multi-tenant er ikke i sig selv uforenelig med GDPR. En egen instans kan gøre visse afgrænsninger lettere at undersøge, men dokumentationen skal i begge modeller dække den faktiske opsætning, adgang og leverandørkæde.

Dataejerskab og exit: hvad sker der, når I vil ud?

Det mest oversete spørgsmål ved ethvert softwarevalg stilles først den dag, man vil skifte: hvordan kommer vi ud: med alt vores?

Exit fra multi-tenant SaaS

I en SaaS-aftale kan exit være begrænset til bestemte eksportformater, og fortsat adgang til softwaren kan ophøre med abonnementet. Det skal undersøges konkret: Hvilke data, relationer, historik og konfigurationer kan flyttes, og hvilke rettigheder får I? Multi-tenant-arkitektur alene afgør hverken eksportens omfang eller retten til fortsat drift.

Exit fra en egen instans

Med en egen instans er udgangspunktet et andet: databasen er adskilt fra andre kunders, og aftalen bør sikre, at I kan få den udleveret i sin helhed. Hvis aftalen og løsningen understøtter det, kan I få en fuld databasekopi til migration. Fortsat egen drift kræver de nødvendige rettigheder og adgang til afhængige tjenester, også ved self-host.

Licensen afgør, hvor reel friheden er

Licensen og aftalen er centrale for fortsat drift. En egen instans kan stadig være afhængig af leverandørens tilladelse og eksterne tjenester. Undersøg konkrete rettigheder, begrænsninger og eventuelle tidsbestemte licensændringer; adgang til kildekode er ikke i sig selv en garanti for, at hele løsningen kan drives videre.

Sikkerhed: isolation vs. delt infrastruktur

Sikkerhedsdiskussionen mellem de to modeller er mere nuanceret, end begge lejre normalt fremstiller den.

Argumentet for egen instans

Adskilte applikationer og databaser kan begrænse spredningen af fejl mellem kunder. Effekten afhænger også af fælles tjenester, netværk og adgangsstyring. Undersøg derfor, hvilke dele et angreb kan nå, frem for at antage, at en dedikeret instans alene begrænser skaden.

Argumentet for multi-tenant

Store SaaS-leverandører har sikkerhedsteams, døgnovervågning og hurtige patch-processer, som de færreste SMV'er selv kan matche. En velfungerende multi-tenant-platform kan derfor i praksis være bedre beskyttet end en dårligt vedligeholdt egen instans. Isolation hjælper ikke, hvis instansen kører glemt software uden opdateringer.

Den ærlige konklusion

Sikkerhed afgøres mindre af arkitekturen og mere af driftsdisciplinen. Egen instans giver strukturelle fordele, mulighed for at begrænse konsekvensen af fejl pr. kunde, en adskillelse, der kan dokumenteres for den konkrete opsætning, men kun hvis instanserne holdes opdaterede og drives professionelt. Det taler for instans-modeller, hvor leverandøren standardiserer og vedligeholder alle instanser centralt, frem for modeller hvor hver installation sander til i sin egen version.

Self-host: hvornår giver det mening?

Self-host (at køre softwaren på egen infrastruktur) er den mest vidtgående form for egen instans. Det giver kontrol over den del af løsningen, I selv driver, herunder drift, adgang og sikkerhedskopier, men data kan stadig sendes til eksterne tjenester.

Til gengæld overtager I også ansvaret. Self-host giver mest mening, når:

Data er særligt følsomme eller underlagt interne/eksterne krav om, at de ikke må forlade eget miljø.
I har driftskompetence: nogen skal kunne opdatere, overvåge og sikkerhedskopiere systemet.
Uafhængighed er et strategisk mål, I vil kunne køre videre uanset hvad der sker hos leverandøren.

For virksomheder uden egen driftskapacitet kan en leverandørhostet egen instans være en mulighed. Undersøg dog driftsansvar, adgang og afhængigheder. Muligheden for self-host afhænger af produktets installation, licens og supportvilkår; den kan ikke afgøres alene ud fra betegnelsen single-tenant eller multi-tenant.

Standardisering uden centralisering

En mulig udfordring ved mange dedikerede instanser er vedligeholdelsen. Fælles standardkode, dokumenterede datamodeller og automatiseret udrulning kan understøtte driften. Versioner og opdateringstidspunkter kan variere efter den valgte model.

En sådan driftsmodel kan beskrives ved tre adskilte hensyn:

Produktet kan standardiseres: instanser kan bygge på fælles kode og datamodel. Opdateringer kan rulles ud samlet eller gradvist.
Dataene er adskilte: hver kunde har sin egen database. Adgangen skal stadig sikres, også i eventuel delt infrastruktur.
Driften kan standardiseres: fælles procedurer og automatisering kan hjælpe vedligeholdelsen. Ressourceforbruget skal vurderes for den konkrete løsning.

I denne eksempelmodel har hver virksomhed en dedikeret applikation og database, mens produkt og driftsværktøjer kan være fælles. Hvor meget drift det sparer, og hvilke lag der stadig deles, skal undersøges særskilt.

Egen instans og multi-tenant SaaS sammenlignet dimension for dimension
Dimension	Multi-tenant SaaS	Egen instans
Hvor bor data?	Kan ligge i delt eller separat database på delt infrastruktur	I eksemplet en dedikeret database; fysisk infrastruktur kan være delt
GDPR-dokumentation	Afhænger af leverandørens processer og aftalekæde	Kræver dokumentation for hele databehandlerkæden
Exit	Eksport, migration og fortsat drift afhænger af produkt, aftale og licens	Databasekopi og fortsat drift afhænger af aftale, licens og tekniske afhængigheder
Sikkerhedsprofil	Afhænger af isolation, adgangsstyring og drift på de delte lag	Dedikerede lag kan begrænse spredning; fælles tjenester skal stadig sikres
Opdateringer	Kan ske samlet eller gradvist efter driftsmodel og aftaler	Kan standardiseres og ske samlet eller gradvist
Self-host muligt?	Afhænger af produkt, licens og supportvilkår	Afhænger af produkt, licens og supportvilkår
Typisk prisprofil	Lav indgangspris, pris pr. bruger	Varierer; dedikerede ressourcer pr. kunde

Gråzoner og hybridformer: når etiketten snyder

Virkeligheden er sjældent så ren som de to modeller ovenfor. Markedet er fuldt af mellemformer, og etiketterne bruges løst, så det er værd at kende de mest almindelige gråzoner, før I tager en leverandørs ord for pålydende.

"Dedikeret skema" i en delt database

Et særskilt skema eller særskilte tabeller i en delt database er én form for logisk adskillelse. Det er noget andet end en dedikeret database, men siger ikke alene noget om sikkerhed eller exitrettigheder. Spørg, hvilke lag der deles, hvordan adgang styres, og hvilke eksport- eller migrationsmuligheder aftalen omfatter.

Dedikeret applikation, delt datalag

En anden mellemform er en dedikeret applikation, som bruger et delt datalag. Her skal adskillelsen undersøges både i applikationen og datalaget. GDPR-dokumentation og exit afhænger af den samlede behandling, adgang, tekniske muligheder og aftaler.

Enterprise-tiers med "single tenant"-tilkøb

Nogle SaaS-leverandører tilbyder dedikerede miljøer til større organisationer. Undersøg pris og vilkår i det konkrete tilbud. Et dedikeret miljø giver ikke i sig selv ret til at køre softwaren videre uden leverandøren; det afhænger af licens, aftale og tekniske afhængigheder.

Sådan skærer I igennem

Gråzonerne betyder ikke, at etiketterne er ubrugelige, kun at de skal efterprøves. De tre spørgsmål, der skærer igennem enhver marketingformulering: Har vi vores egen database (ja/nej)? Kan løsningen self-hostes (ja/nej)? Får vi en fuld databasekopi ved exit (ja/nej)? Svarene afklarer forskellige forhold: dataadskillelse, mulighed for egen drift og exit-rettigheder. En egen instans kan være leverandørhostet uden mulighed for self-host.

Sådan vurderer I en leverandør: 7 spørgsmål om datahåndtering

Uanset hvilken model I hælder til, afslører disse syv spørgsmål hurtigt, hvor gennemtænkt en leverandørs datahåndtering er:

Hvor bor vores data helt konkret: i hvilket system, i hvilket land, hos hvilken infrastrukturleverandør?
Deler vi database med andre kunder? Hvis ja: hvordan er adskillelsen implementeret, og er den nogensinde auditeret?
Hvem kan tilgå vores data hos leverandøren, og logges adgangen?
Hvordan ser en fuld eksport ud? Bed om at se et eksempel: format, omfang, sammenhænge.
Hvad sker der konkret ved opsigelse? Hvor længe ligger data hos jer bagefter, og hvordan dokumenteres sletning?
Kan løsningen self-hostes: nu eller senere? Svaret afslører arkitekturens reelle fleksibilitet.
Hvad siger licensen om vores rettigheder til at køre systemet videre uden leverandøren?

En leverandør, der svarer klart og konkret på alle syv, tager datahåndtering alvorligt. Vage svar på spørgsmål 4-7 er det klassiske varsel om en svær exit.

Vil I dybere ned i det tilgrænsende stof, har vi også skrevet om EU's AI-forordning og hvad den betyder for danske virksomheder, om datakvalitet og CRM-data-hygiejne og om hvad CRM-automatisering egentlig er, alle tre emner støder direkte op til spørgsmålet om, hvor og hvordan virksomhedens data bor. Ser I bredere på softwarestrategien, er guiden til SaaS-salgsstrategi et godt supplement.

Ofte stillede spørgsmål

Er egen instans det samme som on-premise?

Nej. On-premise betyder, at softwaren kører på jeres egne fysiske servere. En egen instans betyder, at I har jeres egen dedikerede installation med egen database, den kan hostes i skyen af leverandøren eller self-hostes, hvis produkt, licens og supportvilkår tillader det. On-premise er altså én måde at drive en egen instans på, men ikke den eneste.

Er multi-tenant SaaS ulovligt eller i strid med GDPR?

Nej, arkitekturen er ikke i sig selv i strid med GDPR. I skal i begge modeller kunne dokumentere relevante behandlingssteder, adgang, aftaler og sletning. En egen instans kan give en tydeligere teknisk afgrænsning, men giver ikke automatisk enklere dokumentation eller lovlig behandling.

Bliver egen instans ikke hurtigt forældet software?

Det afhænger af vedligeholdelsen. Fælles standardkode og en dokumenteret opdateringsproces kan understøtte driften. Udrulning kan ske samlet eller gradvist, og flere versioner kan være i brug. Afklar ansvar, supportperioder og opdateringsvilkår.

Hvad koster egen instans i forhold til multi-tenant?

Det varierer for meget til et generelt svar: multi-tenant har typisk lav indgangspris og pris pr. bruger, mens instans-baserede løsninger prissættes på andre måder, fordi hver kunde har dedikerede ressourcer. Sammenlign altid totalomkostningen over flere år (inklusive prisen for en eventuel exit) frem for månedsprisen alene.

Kan vi flytte fra multi-tenant SaaS til en egen instans senere?

Det kan være muligt, men afhænger af det nye produkt, eksportmuligheder, rettigheder og tekniske afhængigheder. Undersøg datamængde, format, relationer og konfiguration, og afprøv en migration. Arkitekturens navn eller antal år som kunde afgør ikke alene opgavens størrelse.

Hvordan ved vi, om en leverandørs "egen instans" er ægte?

Bed leverandøren beskrive adskillelsen af applikation, database, fysisk infrastruktur og fælles tjenester. Spørg særskilt til self-host og databaseeksport, da de afhænger af produkt og aftale. Et eget skema i en delt database er logisk adskillelse, ikke en dedikeret database; det gør de konkrete vilkår nødvendige at undersøge.