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:
- Cine sunt — identitatea lor de utilizator
- Cărei clinici aparțin — organizația lor
- 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ă vede profilul portabil al unui pacient numai acolo unde pacientul este înscris — rândul
patientsal organizației este granița, iar o clinică fără un astfel de rând nu obține nimic - Î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
Accesul angajaților platformei este excepția, nu regula
Nici angajații proprii ai RestartiX nu pot naviga implicit prin datele identificabile ale pacienților din mai multe clinici. Paginile Console care expun metadate agregate (lista organizațiilor, contoare de pacienți, timestamp-uri de audit) sunt mereu disponibile; paginile care ating date identificabile ale pacienților necesită o elevare break-glass delimitată ca domeniu, limitată în timp, justificată, auditată inclusiv pentru citiri și notificată administratorului clinicii în timp real. Consultați Cum Sunt Protejate Datele Pacienților.
Protecții Suplimentare
| Strat | Ce 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 rest | Câmpurile sensibile criptate chiar și în interiorul bazei de date |
| Izolare de rețea | Baza 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.