De ce datele biroului au nevoie de o bază de date izolată

Când o echipă de IT sau de securitate evaluează un instrument de rezervare pentru spații de lucru, chestionarul întreabă de obicei despre criptare, single sign-on și unde se află serverele. Rareori pune întrebarea care contează cel mai mult pentru această categorie de date: datele organizației noastre sunt separate fizic de ale tuturor celorlalți clienți sau sunt o coloană într-un tabel partajat?

Rezervarea birourilor pare o categorie de date cu risc scăzut până când enumeri ce conține: cine a fost în ce clădire în ce zi, la ce birou, lângă cine, cu ce vizitatori și unde și-a parcat mașina. Acesta este un jurnal al deplasărilor forței tale de muncă. Merită aceeași izolare pe care ai cere-o pentru datele de HR sau de salarizare.

Acest articol explică cele două moduri în care furnizorii SaaS stochează datele multi-tenant, de ce Desk & Park oferă fiecărei organizații propria bază de date izolată și ce înseamnă această decizie pentru oamenii care semnează pentru securitate, confidențialitate și conformitate.

Două arhitecturi, un singur compromis

Aproape orice produs SaaS este multi-tenant: o singură aplicație deservește mulți clienți. Întrebarea este unde se află granița dintre clienți.

Bază de date partajată, coloană de tenant

Abordarea obișnuită. Rândurile fiecărui client stau în aceleași tabele, iar fiecare rând poartă un tenant_id. Fiecare interogare trebuie să filtreze după el. Aplicația, nu baza de date, este responsabilă să țină clienții separați.

Este populară pentru că este ieftin de operat: o bază de date, o schemă, o migrare. Este însă și sursa unei întregi clase de incidente de securitate. Un singur WHERE tenant_id = ? lipsă dintr-una din miile de interogări, un raport care face join între tabele fără filtru, un bug de caching, și clientul A vede datele clientului B. Aceste buguri nu sunt ipotetice; sunt o categorie recurentă de breșe SaaS făcute publice și sunt greu de găsit, pentru că fiecare interogare luată separat pare corectă.

Bază de date izolată per organizație

Fiecare client primește propria bază de date, cu propriile tabele, propriile credențiale și propriile backupuri. Aplicația se conectează la baza de date potrivită pentru organizația care face cererea. Nu există niciun filtru tenant_id de uitat, pentru că nu există niciun alt tenant în baza de date din care să se scurgă date.

Îl costă pe furnizor mai multă disciplină operațională: provizionarea, migrarea și monitorizarea a sute sau mii de baze de date în loc de una. Acest cost este tocmai ideea. Este plătit de furnizor, o singură dată, în inginerie, în loc să fie plătit de client, mai târziu, într-un incident.

Cum este construit Desk & Park

Desk & Park rulează pe o arhitectură cu bază de date per organizație. Concret:

Un plan de control păstrează doar ce este necesar pentru rutare și facturare: numele organizațiilor, planul, corespondența dintre o organizație și baza sa de date și propriul jurnal de audit al platformei. Nu conține rezervări, planuri de etaj sau directoare de angajați.
O bază de date PostgreSQL per organizație păstrează tot ce ține de acea organizație: utilizatori, roluri, locații, hărți, birouri, locuri de parcare, săli, rezervări, check-in-uri, vizitatori, notificări și jurnalul de audit al organizației.
Credențiale per organizație. Aplicația deschide o conexiune către baza de date a unei organizații cu credențiale limitate la acea bază de date. O cerere venită de la organizația A nu poate fi executată pe baza de date a organizației B nici măcar din greșeală, pentru că aplicația nu deține niciodată o conexiune către ea.
Backup, restaurare și ștergere per organizație. Backupurile se fac per bază de date. Restaurarea unei organizații la starea de ieri nu atinge pe nimeni altcineva. Ștergerea unei organizații la finalul unui contract înseamnă eliminarea bazei sale de date, ceea ce este o ștergere completă și verificabilă, nu un DELETE WHERE tenant_id care speră că a găsit fiecare rând.

Codul aplicației este partajat; datele nu sunt. Aceasta este granița pe care un auditor o poate indica.

Ce le aduce izolarea celor care semnează

Pentru CISO: o rază de impact mai mică

O vulnerabilitate într-un strat de interogări multi-tenant expune toți clienții deodată. Cu baze de date izolate, aceeași clasă de bug nu poate traversa granița unei organizații, pentru că granița este impusă de motorul bazei de date și de credențialele conexiunii, nu de logica aplicației. Izolarea nu face o aplicație imună la buguri; face ca un bug într-un loc să fie o problemă a unui singur client în loc de una la nivelul întregii platforme.

Pentru DPO: răspunsuri clare la întrebările GDPR

Evaluările de protecție a datelor pun întrebări previzibile, iar baza de date per organizație le dă răspunsuri scurte.

Întrebare	Răspuns cu o bază de date izolată
Unde sunt datele noastre?	În baza voastră de date, în regiunea UE a platformei, separat de toți ceilalți clienți.
Cine le poate accesa?	Aplicația, cu credențiale limitate la baza voastră de date, și personalul de gardă al operatorului, conform procedurii de acces documentate.
Puteți dovedi ștergerea?	Da: baza voastră de date este eliminată, iar eliminarea este înregistrată în jurnalul de audit al platformei.
Puteți restaura doar datele noastre?	Da: backupurile sunt per organizație.
Puteți exporta tot?	Da: un export este un dump al unei singure baze de date, nu un extras filtrat.

Dreptul la ștergere și obligația de restricționare a prelucrării devin operațiuni de bază de date cu un scop clar, nu funcționalități ale aplicației care trebuie testate pentru completitudine.

Pentru responsabilul de conformitate: un control ușor de apărat

Cadre precum ISO 27001 și SOC 2 cer unui furnizor să demonstreze separarea logică dintre clienți. „Fiecare interogare filtrează după tenant” este un control care trebuie reverificat pentru fiecare interogare nouă. „Fiecare client are propria bază de date și propriile credențiale” este un control verificat o singură dată, structural, și care rămâne valabil pe măsură ce produsul crește. Al doilea este mult mai ușor de documentat, atât pentru furnizor, cât și pentru auditul propriu al clientului.

Pentru CIO: performanță și ciclu de viață previzibile

Raportul greu al unei organizații nu încetinește valul de check-in-uri de dimineață al alteia, pentru că nu împart tabele sau indecși. Migrările se derulează per bază de date, așa că o problemă poate fi prinsă la o organizație înainte să ajungă la următoarea. Offboarding-ul este o eliminare a bazei de date, nu un proiect de curățenie.

Restul poveștii despre securitate

Izolarea este fundația, nu întreaga clădire. Controalele pe care echipele de IT le așteaptă stau deasupra ei și merită enumerate, pentru că o arhitectură bună cu o autentificare slabă rămâne slabă:

Single sign-on prin OpenID Connect cu furnizorul tău de identitate și provizionare SCIM, astfel încât noii angajați și cei care pleacă să fie creați și dezactivați din directorul tău, nu manual.
Autentificare cu doi factori (TOTP) și passkey-uri (WebAuthn), cu o politică la nivel de organizație pentru a impune MFA.
Politici de securitate per organizație: expirarea sesiunii, reguli pentru parole, liste de IP-uri permise.
Gestionarea sesiunilor active, astfel încât un administrator să poată vedea și revoca sesiuni.
Un jurnal de audit per organizație care înregistrează cine a schimbat ce, în propria bază de date a organizației.
Plăți prin Stripe, astfel încât datele cardurilor nu ajung niciodată pe platformă.
Acces bazat pe roluri: angajații văd și rezervă; administratorii configurează; membrii consiliului și managerii primesc rapoarte limitate la echipele lor.

Niciunul dintre acestea nu este neobișnuit în SaaS-ul enterprise. Ce este neobișnuit este combinarea lor cu un strat de date în care granița dintre clienți este fizică.

Întrebări de pus oricărui furnizor de soluții de workplace

Dacă compari instrumente, aceste cinci întrebări separă marketingul de arhitectură:

Datele noastre sunt într-o bază de date dedicată sau în tabele partajate cu o coloană de tenant?
Backupurile, restaurările și ștergerile se fac per client?
Ce credențiale folosește aplicația pentru a ajunge la datele noastre și sunt ele limitate la noi?
Cum le dovediți auditorilor voștri separarea clienților?
Poate un bug dintr-un raport sau dintr-un export să returneze vreodată rândurile altui client?

Un furnizor cu o bază de date izolată răspunde la toate cele cinci într-o propoziție fiecare. Un furnizor cu o bază de date partajată trebuie să descrie un proces de testare.

Izolarea ar trebui să fie implicită

Datele de workplace sunt date personale despre prezența fizică a angajaților tăi. Cea mai ieftină arhitectură pentru furnizor pune aceste date lângă ale tuturor celorlalți clienți și are încredere că aplicația le ține separate. Desk & Park a ales-o pe cea mai scumpă, astfel încât granița dintre organizații să fie o bază de date, nu un filtru.

Poți citi detaliile tehnice în rezumatul arhitecturii de pe pagina „Cum funcționează” și în politica de confidențialitate a platformei. Pentru o implementare enterprise cu single sign-on, SCIM și o evaluare de securitate, pagina de prețuri are contactul pentru Enterprise.