BYOC kontra vanlig SaaS: vilket är säkrast?

Ingen av modellerna är magiskt “ohackbar” — men de fallerar på väldigt olika sätt. Vanlig multi-tenant-SaaS håller alla kunder i en central databas, så ett enda intrång kan exponera tusentals organisationer på en gång. BYOC (Bring Your Own Cloud) tar bort den centrala databasen helt: varje organisations data ligger isolerad på sitt eget molnkonto, så spridningsytan för en incident hos en tenant är en tenant, inte hela kundbasen. Den strukturella skillnaden — plus vad den gör för dataresidens och utträde — är vad “säkrare” faktiskt betyder här.

Det här inlägget jämför de två säkerhetsmodellerna ärligt: på spridningsyta, tenant-isolering, dataresidens, begränsning vid intrång, och vad som händer när du lämnar. Det bygger vidare på modellen i vad ett BYOC agency OS är; är begreppet nytt för dig, börja där.

Hur lagrar vanlig multi-tenant-SaaS din data?

Den mesta affärsmjukvara du använder är multi-tenant-SaaS. Leverantören kör en applikation mot en central databas, och varje kund — “tenant” på fikonspråk — delar den. Dina CRM-kontakter och en konkurrents ligger i samma tabeller, åtskilda av applikationslogik: vanligtvis en tenant-ID-kolumn på varje rad som koden ska filtrera på vid varje läsning och skrivning.

Det här är faktiskt ett bra tekniskt mönster. Det är billigt att driva, enkelt att uppdatera och det skalar. Men det koncentrerar data. Tusentals företags poster hamnar i ett schema, på infrastruktur bara leverantören kontrollerar, nåbar genom en applikation och en uppsättning databasinloggningar. Den koncentrationen är roten till säkerhetsavvägningen.

Vad är “spridningsyta”, och varför gynnar det BYOC?

Spridningsyta (på engelska blast radius) är hur mycket som exponeras när en sak går fel: en läckt inloggning, en felkonfigurerad lagringshink, en opatchad sårbarhet, en illvillig insider. Frågan är inte bara “hur troligt är ett intrång” utan “hur illa blir det när ett väl inträffar”.

I multi-tenant-SaaS är spridningsytan för en incident på databasnivå hela kundbasen. Ett intrång i det centrala lagret är potentiellt allas data på en gång. Historien bekräftar det: de största SaaS-intrången är stora just för att en enda felkälla satt framför tusentals tenanter.

I en BYOC-modell finns inget centralt lager att bryta sig in i. Varje organisations data ligger på sitt eget molnkonto, så en incident hos en tenant begränsas till just den tenanten. Det finns ingen delad databas att ta sig vidare genom och inget enskilt mål vars komprometterande ger allas poster. Du har inte gjort en incident omöjlig — du har satt ett tak för hur långt en kan sprida sig.

Är min data verkligen isolerad? Multi-tenant kontra per-tenant-isolering

“Isolering” är där marknadsföring och arkitektur ofta skiljs åt, så det är värt att vara exakt med nivåerna:

• Logisk isolering (typisk SaaS). En databas, ett schema, tenanter åtskilda av ett tenant-ID och applikationskod. Om den koden har en bugg — ett saknat filter, en trasig behörighetskontroll — eller om någon får åtkomst på databasnivå under applikationen, kan åtskillnaden mellan tenanter brista. Det här är den klassiska multi-tenant-säkerhetsrisken: isoleringen hänger på att mjukvaran beter sig felfritt, överallt, varje gång.
• Instansisolering (“dedikerad på leverantörens konto”). Vissa leverantörer ger större kunder en separat databas — men fortfarande på leverantörens molnkonto. Bättre än ett delat schema, men leverantören håller ändå alla kunders data under sin egen kontroll, så det samlade målet finns kvar.
• Kontoisolering (BYOC). Varje organisations databas skapas på sitt eget molnkonto. Isoleringen är en gräns mellan separata konton, inte ett filter inuti ett delat system. Det finns ingen central plats där alla kunders data samexisterar, så läckage mellan kunder har inget delat medium att färdas genom.

sSystm använder kontoisolering: när du registrerar dig med ditt Cloudflare-konto skapar plattformen en dedikerad Cloudflare D1-databas på ditt konto. Isoleringen mellan din byrå och vilken annan kund som helst är isoleringen mellan två separata molnkonton. Du kan läsa exakt hur den datamodellen är byggd på sidan Säkerhet & datamodell.

BYOC kontra multi-tenant-SaaS: säkerhetsjämförelsen

Dimension	Vanlig multi-tenant-SaaS	BYOC (Bring Your Own Cloud)
Var datan ligger	En central databas på leverantörens konto	En dedikerad databas på ditt molnkonto
Spridningsyta vid intrång	Alla tenanter — ett intrång kan exponera alla	En tenant — begränsad till ett konto
Tenant-isolering	Logisk (tenant-ID + appkod)	På kontonivå (separata molnkonton)
Enskilt högvärdesmål	Ja — det delade lagret	Inget centralt lager att rikta in sig på
Dataresidens	Leverantörens policy (“vi hostar i EU”)	Väljs vid skapandet, valfri hård EU-garanti
Begränsning vid intrång	Beror på leverantörens upptäckt & respons	Strukturellt begränsad till ett konto
Utträde / ägande	Exportera data, bygg sedan om någon annanstans	Databasen är redan din — inget att exportera

Mönstret genom hela tabellen är detsamma: multi-tenant-SaaS optimerar för leverantörens driftbekvämlighet och koncentrerar risken; BYOC sprider ut datan och, med den, risken.

Vilken modell begränsar ett intrång bättre?

Begränsning handlar om vad en angripare kan nå efter ett första fotfäste. I ett centralt multi-tenant-system står en angripare som tar sig under applikationen — till databasen, till säkerhetskopiorna, till adminverktygen — redan framför varje tenant. Sidledsförflyttning är trivial eftersom det inte finns någon annanstans att ta sig: allt är ett lager.

I en BYOC-modell ger komprometterandet av plattformens applikationslager inte bort en central databas, eftersom det inte finns någon. Varje tenants data sitter bakom gränsen till ett separat molnkonto. För att nå en andra organisation skulle en angripare behöva bryta sig in i ett andra konto. Det är skillnaden mellan ett intrång som skalar och ett som inte gör det.

Därför beskriver vi BYOC som något som ändrar attackytan och spridningsytan snarare än att lova osårbarhet. En sårbarhet i vilken mjukvara som helst behöver fortfarande patchas, och ditt molnkonto är nu en del av säkerhetsbilden — du äger det, så du måste säkra det (starka inloggningar, minsta möjliga behörighet, MFA). BYOC flyttar en del ansvar till dig i utbyte mot att ta bort den enskilt största källan till samlad kollaps. Det är en avvägning, och för byråer vars hela verksamhet är kunddata är det oftast rätt avvägning.

Hur är det med dataresidens och GDPR?

Residens är där de två modellerna skiljer sig mest synbart. I vanlig SaaS är “vi hostar i EU” en policy — ett löfte som kan ändras med en ny underleverantör, en ny region eller en ny ägare. När en tillsynsmyndighet eller en företagskund frågar var exakt ligger den här posten och vem kan komma åt den, är ett centralt multi-tenant-kluster något obekvämt att peka på.

Med BYOC är svaret strukturellt. Eftersom databasen skapas på ditt konto väljer du dess jurisdiktion när den skapas. sSystm låter dig välja region vid inloggning, inklusive en hård garanti för EU-jurisdiktion för databasen — residens genom konstruktion, inte genom löfte. Vi går djupare på efterlevnadsvinkeln i dataresidens, GDPR och byråer. Inget av detta är juridisk rådgivning, men “datan ligger fysiskt i en EU-låst databas på vårt eget konto” är en väsentligt starkare position än en rad i en leverantörs villkor.

Vad händer med min data om jag lämnar?

Säkerhet omfattar slutet på relationen, inte bara mitten. Med vanlig SaaS betyder att lämna att du exporterar dina poster genom vilket API leverantören nu erbjuder och bygger om relationerna mellan dem någon annanstans — och tills du gör det ligger din data kvar i leverantörens lager. Avvecklingen sker på deras tidslinje, inte din.

Med BYOC är utträdet en icke-händelse för datan. Databasen låg alltid på ditt konto; koppla från plattformen så tappar leverantören åtkomst medan du behåller allt — poster, innehåll och säkerhetskopior — precis där de var. Det finns inget exportsteg eftersom det inte finns något att lämna kvar. Den egenskapen överlappar starkt med inlåsning, som vi täcker i SaaS-inlåsning och hur du undviker den.

Så, vilket är säkrast?

Ärligt: det beror på din hotmodell, och ingen arkitektur ersätter att göra grunderna väl. Men om din främsta oro är scenariot som håller byråägare vakna på natten — en incident exponerar alla våra kunder på en gång — så är BYOC den starkare modellen, eftersom just det felläget inte existerar när det inte finns någon central databas. Det krymper spridningsytan från alla till en, gör tenant-isolering till en gräns mellan konton, och gör residens och utträde till egenskaper i arkitekturen i stället för klausuler i ett avtal.

Det är vadet sSystm är byggt på. Du kan granska hur datamodellen fungerar på sidan Säkerhet & datamodell i stället för att ta oss på orden, och se den bredare filosofin i vad ett BYOC agency OS är.