Izolarea datelor multi-chiriaș: de ce „filtrăm pe cont” nu este suficient

Dacă administrezi proprietăți pentru mai mult de un proprietar, sau pentru mai multe entități juridice, există o întrebare care merită pusă despre orice software în care introduci aceste date: ce anume oprește situația financiară a Proprietarului A să apară undeva vizibil echipei Proprietarului B? „Filtrăm pe cont în interfață” și „nu este posibil să interoghezi între conturi” sunt răspunsuri foarte diferite — iar diferența contează cel mai mult exact atunci când ceva nu funcționează corect, nu atunci când totul merge conform planului.

Filtrarea la nivel de aplicație este o convenție, nu o garanție

Majoritatea software-ului izolează datele chiriașilor adăugând un filtru la fiecare interogare — „doar rândurile în care company_id corespunde”. Funcționează, exact până când o interogare undeva în cod uită acest filtru: un endpoint nou, o interogare de raportare scrisă în grabă, un job de fundal care parcurge „toate” înregistrările în loc de cele ale unei companii. Nimic nu impune regula, în afară de faptul că fiecare dezvoltator și-o amintește, de fiecare dată, pentru totdeauna. Pentru o aplicație cu un singur chiriaș, acesta este un risc minor. Pentru un software care deține datele financiare și ale chiriașilor mai multor proprietari, este o categorie diferită de problemă.

Ce înseamnă de fapt izolarea la nivel de bază de date

Alternativa este să impui limita chiar în baza de date — securitate la nivel de rând (row-level security) în Postgres, în cazul Casement — astfel încât nici măcar o interogare care uită să filtreze pe companie să nu poată vedea rândurile altei companii. Nu este un strat de restricție din interfață adăugat peste o vedere partajată a datelor; baza de date însăși refuză să le returneze. Este o garanție semnificativ mai puternică decât „aplicația ar trebui să filtreze asta”, pentru că nu depinde de faptul că fiecare linie de cod este scrisă corect.

De ce acest lucru contează în special pentru administratorii de proprietăți

• Nu ești singurul proprietar al datelor. Spre deosebire de un utilizator SaaS obișnuit al unei singure companii, un administrator de proprietăți care acționează pentru mai mulți proprietari gestionează, de regulă, informații financiare și despre chiriași care apartin altcuiva — miza unei scurgeri este a altcuiva, nu doar a ta.
• Proprietarii întreabă. Un client-proprietar care evaluează dacă să încredințeze unui administrator de proprietăți datele portofoliului său are dreptul să întrebe cum sunt izolate de ale tuturor celorlalți — „impus la nivel de bază de date” este un răspuns concret; „suntem atenți” nu este.

Cum gestionează Casement acest lucru

Fiecare tabel de chiriaș din Casement are un identificator de companie impus de securitatea la nivel de rând din Postgres, nu doar prin filtrare la nivel de aplicație — iar stratul de aplicație filtrează în continuare explicit pe lângă acesta, ca o a doua verificare, nu ca singura. Nu este cea mai vizibilă funcție într-un demo de produs, dar este cea de care depind toate celelalte.

Casement este în prezent în proces de onboarding pentru un număr mic de companii de administrare a proprietăților pilot. Dacă administrezi pentru mai mult de un proprietar, merită să întrebi direct despre asta într-un demo live.