Skip to content

Izolarea Datelor

Cum asigură platforma că o clinică nu poate vedea niciodată datele altei clinici.


Problema

Într-o platformă multi-tenant — unde multe clinici partajează aceeași infrastructură — cel mai mare risc este scurgerea datelor între clinici. Un bug în cod, o interogare configurată greșit sau o eroare de autorizare ar putea teoretic expune înregistrările pacienților unei clinici alteia.

Cum o Rezolvăm

Izolarea datelor este impusă la nivelul bazei de date, nu doar la nivelul aplicației. Aceasta se numește Row-Level Security (RLS).

Toate datele din sistem aparțin unei organizații (clinici). Când un specialist de la Clinica A se autentifică, fiecare interogare de bază de date pe care o declanșează este filtrată automat numai la datele Clinicii A — de către baza de date însăși.

Ce înseamnă asta în practică

  • Un bug în codul aplicației nu poate expune accidental datele Clinicii B Clinicii A. Baza de date respinge orice interogare care traversează granițele, indiferent de ce solicită aplicația.
  • Nu există o „super-interogare" care ocolește izolarea. Chiar și dezvoltatorii aplicației nu pot scrie accidental cod care traversează granițele clinicii în operarea normală.
  • Auditorii pot verifica izolarea direct. Politicile de securitate sunt definite în schema bazei de date — pot fi inspectate și testate independent de codul aplicației.

Cum funcționează

Când un utilizator se autentifică, trei informații sunt setate pe conexiunea lor la baza de date:

  1. Cine sunt — identitatea lor de utilizator
  2. Cărei clinici aparțin — organizația lor
  3. Ce rol au — admin, specialist, customer service etc.

Fiecare tabelă din baza de date are o politică care spune: „Returnează numai rândurile unde organizația se potrivește cu organizația utilizatorului curent." Această politică este impusă de motorul bazei de date la fiecare interogare — SELECT, INSERT, UPDATE și DELETE.

Profiluri portabile ale pacienților

Profilurile pacienților sunt singura excepție de la izolarea strictă a clinicii. Informațiile personale de bază ale unui pacient (nume, data nașterii, alergii) sunt portabile — aparțin pacientului, nu oricărei clinici. Totuși:

  • O clinică poate vedea profilul complet al unui pacient numai după ce pacientul semnează un consimțământ de partajare a profilului pentru acea clinică specifică
  • Înregistrările clinice (programări, formulare, planuri de tratament, rapoarte) sunt întotdeauna izolate — nu traversează niciodată granițele clinicii
  • Înregistrările de consimțământ sunt per-clinică — semnarea la Clinica A nu partajează cu Clinica B

Protecții Suplimentare

StratCe Face
Izolare la nivel de bază de date (RLS)Impune granițele clinicii la fiecare interogare
Autorizare la nivel de aplicație (RBAC)Controlează ce poate face fiecare rol în cadrul clinicii lor
Jurnalizare auditÎnregistrează fiecare acces la date și mutație
Criptare la restCâmpurile sensibile criptate chiar și în interiorul bazei de date
Izolare de rețeaBaza de date nu este expusă pe internet — accesibilă numai din aplicație

Pentru dezvoltatori

Detalii tehnice — definițiile politicilor RLS, configurarea variabilelor de sesiune, arhitectura pool-ului dual de conexiuni și middleware-ul RBAC — sunt disponibile în referințele Politici RLS și Permisiuni RBAC.