BYOC vs tradisjonell SaaS: hva er sikrere?

Ingen av modellene er magisk “unhackable” - men de mislykkes på veldig forskjellige måter. Tradisjonell multi-tenant SaaS holder hver kunde i én sentral database, så et enkelt brudd kan avsløre tusenvis av organisasjoner samtidig. BYOC (Ta med Own Cloud) fjerner den sentrale databasen helt: hver organisasjons data sitter isolert på sin egen skykonto, så eksplosjonsradiusen til en hendelse per leietaker er én leietaker, ikke hele kundebasen. Den strukturelle forskjellen – pluss hva den gjør for dataopphold og utgang - er hva “sikrere” faktisk betyr her.

Dette innlegget sammenligner de to sikkerhetsmodellene ærlig: på sprengningsradius, leietaker isolasjon, dataopphold, inneslutning av brudd og hva som skjer når du drar. Den bygger på modellen beskrevet i hva et BYOC-byrå OS er; hvis du er ny på semester, start der.

Hvordan lagrer tradisjonell multi-tenant SaaS dataene dine?

Det meste av forretningsprogramvare du bruker er multi-tenant SaaS. Selgeren driver en applikasjon mot en sentral database, og hver kunde — “leietaker” i sjargong — deler det. Dine CRM-kontakter og en konkurrents sitter i samme bord, holdt fra hverandre av applikasjonslogikk: typisk en leietaker-ID-kolonne på hver rad som koden er ment å filtrere på for hver lesing og skriving.

Dette er et genuint godt ingeniørmønster. Den er billig i drift, enkel å bruke oppdatering, og den skalerer. Men det konsentrerer data. Tusenvis av selskapers poster ende opp i ett skjema, på infrastruktur kun leverandøren kontrollerer, tilgjengelig gjennom ett program og ett sett med databaselegitimasjon. Den konsentrasjonen er roten til sikkerhetsavveiningen.

Hva er “blast radius”, og hvorfor favoriserer det BYOC?

Sprengningsradius er hvor mye som blir eksponert når én ting går galt: en lekket legitimasjon, en feilkonfigurert lagringsbøtte, en uopprettet sårbarhet, en ondsinnet insider. Spørsmålet er ikke bare “hvor sannsynlig er en hendelse”, men “hvordan ille er det når det skjer”.

I multi-tenant SaaS er eksplosjonsradiusen til en hendelse på databasenivå hele kundebase. Et brudd på sentrallageret er potensielt alles data med en gang. Historien viser dette: de største SaaS-bruddene er store nøyaktig fordi ett feilpunkt satt foran tusenvis av leietakere.

I en BYOC-modell er det ingen sentral butikk å bryte. Hver organisasjons data bor på sin egen skykonto, så en per-leietaker-hendelse er begrenset til den leietaker. Det er ingen delt database å pivotere gjennom og ikke noe enkelt mål hvis kompromiss gir alles rekorder. Du har ikke gjort en hendelse umulig - du har begrenset hvor langt man kan spre seg.

Er dataene mine virkelig isolert? Multi-tenant vs per-tenant isolation

“Isolasjon” er der markedsføring og arkitektur ofte skiller veier, så det er verdt det være nøyaktig om nivåene:

• Logisk isolasjon (typisk SaaS). Én database, ett skjema, leietakere atskilt med en leietaker-ID og applikasjonskode. Hvis den koden har en feil — en manglende filter, en ødelagt tilgangssjekk - eller hvis noen får databasenivå tilgang under applikasjonen, kan separasjonen mellom leietakere mislykkes. Dette er den klassiske sikkerhetsrisikoen for flere leietakere: isolasjon avhenger av programvarens oppførsel perfekt, overalt, hver gang.
• Forekomstisolering (“dedikert på leverandørens konto”). Noen leverandører gir større kunder en egen database — men fortsatt på leverandørens skykonto. Bedre enn et delt skjema, men leverandøren har fortsatt hver kundes data under sin egen kontroll, så det aggregerte målet forblir.
• Kontoisolering (BYOC). Hver organisasjons database er klargjort på sin egen skykonto. Isolasjon er en grense mellom separate kontoer, ikke et filter inne i ett delt system. Det er ikke noe sentralt sted hvor alle kundenes data eksisterer side om side, så kryss-leietakerlekkasje mellom kunder har ingen delt medium å reise gjennom.

sSystm bruker kontoisolering: ved registrering med Cloudflare-kontoen din, plattformen tilbyr en dedikert Cloudflare D1-database på din konto. Den isolasjon mellom byrået ditt og enhver annen kunde er isolasjonen mellom to separate skykontoer. Du kan lese nøyaktig hvordan den datamodellen er bygget på Sikkerhets- og datamodell side.

BYOC vs multi-tenant SaaS: sikkerhetssammenligningen

Dimensjon	Tradisjonell flerleietaker SaaS	BYOC (Bring Your Own Cloud)
Hvor data bor	Én sentral database på leverandørens konto	En dedikert database på din skykonto
Sprengningsradius	Alle leietakere — ett brudd kan avsløre alle	En leietaker — inneholdt til en enkelt konto
Leietaker isolasjon	Logisk (leietaker-ID + app-kode)	Kontonivå (separate skykontoer)
Enkelt mål med høy verdi	Ja — den delte butikken	Ingen sentral butikk å målrette mot
Dataopphold	Leverandørpolicy (“vi er vert i EU”)	Valgt ved klargjøring, valgfri hard EU-garanti
Brudd inneslutning	Avhenger av leverandørdeteksjon og respons	Strukturelt inneholdt til én konto
Utgang / eierskap	Eksporter data, og bygg deretter opp et annet sted	Databasen er allerede din — ingenting å eksportere

Mønsteret over bordet er konsistent: multi-tenant SaaS optimerer for leverandørens operasjonelle bekvemmelighet og konsentrerer risiko; BYOC distribuerer dataene og med det risikoen.

Hvilken modell inneholder et brudd bedre?

Inneslutning handler om hva en angriper kan nå etter et første fotfeste. I en sentralt multi-tenant system, en angriper som kommer under applikasjonen - til database, til sikkerhetskopier, til administrasjonsverktøy - står allerede foran hver leietaker. Sidebevegelse er triviell fordi det ikke er noe annet sted å bevege seg: det er det alt én butikk.

I en BYOC-modell overlater ikke det å kompromittere plattformens applikasjonslag en sentral database, fordi det ikke er en. Hver leietakers data sitter bak grensen til en egen skykonto. For å nå en annen organisasjon, en angriper måtte bryte en annen konto. Det er forskjellen på et brudd som skalerer og en som ikke gjør det.

Dette er grunnen til at vi innrammer BYOC som å endre angrepsflaten og sprengningsradius heller enn å love usårbarhet. En sårbarhet i enhver programvare fortsatt trenger oppdatering, og skykontoen din er nå en del av sikkerhetsbildet – du eier den, så du må sikre den (sterk legitimasjon, minst privilegert tilgang, MFA). BYOC flytter noe ansvar til deg i bytte mot å fjerne den største enkeltstående punkt for aggregert feil. Det er en handel, og for byråer hvis hele virksomheten er klientdata, er det vanligvis den rette.

Hva med dataopphold og GDPR?

Residency er der de to modellene divergerer mest synlig. I konvensjonell SaaS, “vi er vert for EU” er en policy — et løfte som kan endres med en ny underbehandler, en ny region eller en ny bedriftseier. Når en regulator eller en bedriftsklient spør hvor nøyaktig er denne posten og hvem som har tilgang til den, en sentral multi-tenant cluster er en ubehagelig ting å peke på.

Med BYOC er svaret strukturelt. Fordi databasen er klargjort på din konto, velger du dens jurisdiksjon når den opprettes. sSystm lar deg velge din region ved pålogging, inkludert en hard EU-jurisdiksjonsgaranti for database — bosted etter konstruksjon, ikke etter løfte. Vi går dypere på samsvarsvinkel inn dataresidency, GDPR og byråer. Ingenting av dette er juridisk rådgivning, men “dataene lever fysisk i en EU-pinnet database for egen regning” er en vesentlig sterkere posisjon enn en linje i en leverandørens vilkår.

Hva skjer med dataene mine hvis jeg drar?

Sikkerhet inkluderer slutten av forholdet, ikke bare midten. Med tradisjonell SaaS, å forlate betyr å eksportere postene dine gjennom uansett API leverandøren tilbyr og gjenoppbygge relasjonene mellom dem andre steder - og frem til du gjør det, fortsetter dataene dine å ligge i leverandørens butikk. Avregistrering er på deres tidslinje, ikke din.

Med BYOC er exit en ikke-hendelse for dataene. Databasen var alltid på din konto; koble fra plattformen og leverandøren mister tilgang mens du beholder alt - poster, innhold og sikkerhetskopier - akkurat der de var. Det er det ingen eksporttrinn fordi det ikke er noe å legge igjen. Den egenskapen overlapper hverandre tungt med lock-in, som vi dekker inn SaaS leverandørlåsing og hvordan unngå det.

Så, hva er sikrere?

Ærlig talt: det avhenger av trusselmodellen din, og ingen arkitektur er en erstatning for å gjøre det grunnleggende godt. Men hvis din største bekymring er scenariet som holder byråeiere oppe om natten — én hendelse avslører alle våre kunder samtidig — da er BYOC den sterkere modellen, fordi den spesifikke feilmodusen ikke gjør det eksisterer når det ikke er noen sentral database. Det krymper sprengningsradiusen fra alle til en, gjør leietakers isolasjon til en grense mellom kontoer, og gjør bolig- og utgangsegenskaper for arkitekturen i stedet for klausuler i en kontrakt.

Det er innsatsen sSystm er bygget på. Du kan inspisere hvordan datamodellen fungerer siden Sikkerhet og datamodell i stedet for å ta vårt ord for det, og se den bredere filosofien i hva et BYOC-byrå OS er.