Ko isto namestitev programske opreme uporablja več strank, mora ponudnik SaaS odgovoriti na temeljno vprašanje: kako so podatki posameznih strank (najemnikov) ločeni med seboj? Najbolj razširjen odgovor v panogi je skupna podatkovna baza, v kateri ima vsaka tabela dodaten stolpec, kot je »tenant_id«, po katerem se filtrira vsaka poizvedba. To deluje, vendar je v celoti odvisno od tega, ali je to filtriranje pravilno izvedeno na vsakem posameznem mestu v kodi. 1Tool ubira strukturno drugačno pot.
Lastna podatkovna baza za vsako stranko namesto skupne tabele
Pri 1Tool vsaka stranka dobi lastno, fizično ločeno podatkovno bazo. Ta se poveže dinamično med izvajanjem – sistem ob prijavi uporabnika ve, s katero podatkovno bazo stranke mora komunicirati, in ustrezno vzpostavi povezavo. Ločevanje torej ne poteka na ravni aplikacije prek pogoja filtra, temveč že na ravni infrastrukture. Programska napaka, zaradi katere bi pri skupni podatkovni bazi teoretično lahko pozabili na pogoj filtra in bi postali vidni podatki druge stranke, je pri strogi arhitekturi »ena podatkovna baza na stranko« izključena že vnaprej: preprosto ni skupne tabele, iz katere bi lahko pomotoma prebrali preveč.
Lastni strežniki za velike stranke, ločen predpomnilnik za vse
To ločevanje je mogoče po potrebi peljati še dlje. Za posebej velike stranke lahko 1Tool dodeli celo povsem lasten strežnik podatkovne baze – z lastnim gostiteljem in lastnimi dostopnimi podatki – namesto da bi podatkovna baza tekla na isti skupni strežniški infrastrukturi kot pri drugih strankah. Tako se izolacija razširi z logične na fizično raven infrastrukture, kadar je to za stranko smiselno iz varnostnih razlogov ali zaradi zmogljivosti. Poleg tega 1Tool tudi predpomnilnik upravlja ločeno za vsako stranko: tudi predpomnjeni podatki se hranijo ločeno po strankah, tako da tudi na tej ravni ne more priti do mešanja podatkov med strankami.
Natančno določene pravice znotraj stranke
Ločevanje med strankami je le ena raven nadzora dostopa. Znotraj posamezne stranke sistem pravic z več deset specializiranimi pravili filtriranja – tako imenovanimi scopes – dodatno določa, katere posamezne zapise sme določen uporabnik sploh videti. Tako je na primer mogoče urediti, da prodajni zastopnik vidi le svoje kontakte, vodja pa ima popoln pregled – vse znotraj iste podatkovne baze, ki je že izolirana po strankah. Za podjetja z visokimi zahtevami glede varstva in varnosti podatkov je ta kombinacija pomemben argument pri izbiri ponudnika. Skupna podatkovna baza s stolpci tenant_id je v obratovanju cenejša za skaliranje, vendar zahteva, da je vsaka posamezna poizvedba v celotnem sistemu pravilno filtrirana – leta in leta ter skozi številne generacije razvijalcev. Prava arhitektura z ločeno podatkovno bazo za vsako stranko to jamstvo prenese z logike aplikacije na samo infrastrukturo.
Pogosta vprašanja
Ali lastna podatkovna baza za vsako stranko pomeni, da so podatki fizično shranjeni ločeno?
Da, vsaka stranka dobi lastno, ločeno podatkovno bazo namesto skupnih tabel z oznako stranke kot stolpcem za filtriranje.
Ali lahko posamezne stranke delujejo na povsem lastnem strežniku?
Za posebej velike stranke je to mogoče – vključno z lastnim gostiteljem in lastnimi dostopnimi podatki, ločeno od skupne strežniške infrastrukture.
Kako je znotraj stranke urejeno, kdo vidi katere zapise?
Za to skrbi sistem pravic s številnimi specializiranimi pravili filtriranja, ki delujejo poleg ločevanja podatkovnih baz in omejujejo dostop do posameznih zapisov za vsakega uporabnika.
Kako pomembna je prava izolacija podatkovnih baz za zahteve glede varstva podatkov v vašem podjetju?
Preberite tudi
- Obveščanje drugih sistemov: zahteve HTTP neposredno iz avtomatiziranega poteka dela
- Dohodni webhooki: strukturiran prenos zunanjih podatkov v CRM