Măsuri tehnice și organizatorice

Anexă la Acordul de prelucrare a datelor. Descrie măsurile cerute de Art. 32 GDPR. Se poate cere oricând la contact@cabinetuldigital.ro.

1. Ce acoperă

Aplicația ține fișe de pacient, măsurători, planuri alimentare, analize încărcate, jurnal alimentar și programări. O parte sunt date privind sănătatea, categorie specială sub Art. 9 GDPR. Măsurile de mai jos sunt gândite pentru nivelul ăsta de sensibilitate, nu pentru o aplicație obișnuită.

2. Unde stau datele

Baza de date, conturile și fișierele sunt la Supabase, în Frankfurt (eu-central-1). Serverul aplicației e la Railway, în Amsterdam. E-mailurile pleacă prin Resend, în UE. Lista completă a furnizorilor, cu rolul fiecăruia, e în politica de confidențialitate.

3. Cine intră în cont

• Autentificare prin furnizor dedicat (Supabase Auth). Parolele nu ajung niciodată la noi și nu sunt vizibile nimănui.
• Parolele scurse în breșe publice cunoscute sunt respinse la înregistrare.
• Sesiunea expiră: cel mult 30 de zile, iar la 7 zile de inactivitate te delogează singură.
• Fiecare cerere e verificată criptografic (semnătură asimetrică, cu emitentul și destinatarul fixate). Rolul se citește din baza noastră la fiecare cerere, nu din ce trimite browserul.
• Implicit închis: un ecran fără permisiune explicită e refuzat, nu permis.

4. Accesul nostru administrativ

Spunem asta pe față, fiindcă e adevărat la orice furnizor de software și rar scris: personalul tehnic al furnizorului are acces administrativ la sisteme.

• Nu există niciun ecran în aplicație prin care noi să vedem fișele cuiva. Nu există rol de administrator care să treacă dincolo de un cabinet.
• Accesul se face doar prin consolele furnizorilor de infrastructură, pe conturi nominale, fără conturi comune și fără parole împărțite între persoane, iar toate aceste conturi sunt protejate cu autentificare în doi pași.
• Se folosește doar pentru mentenanță și remedierea defecțiunilor, sub obligație de confidențialitate, și doar cât e nevoie.
• Cheile de administrare stau exclusiv pe server, ca variabile de mediu. Nu ajung niciodată în browser și nu sunt în codul sursă.

5. Criptare

Traficul e criptat integral pe drum (HTTPS, cu HSTS impus). Datele sunt criptate în repaus de furnizorul bazei de date. Cererile către server sunt semnate și validate.

6. Analize și alte fișiere

• Documentele medicale, materialele și pozele din jurnal stau în spații de stocare private, nu publice. Nu au adresă pe care s-o poată deschide cineva din exterior.
• Se ajunge la ele doar prin linkuri temporare, generate la cerere și valabile între 1 și 30 de minute, în funcție de tipul de fișier.
• Calea fiecărui fișier conține cabinetul și pacientul, deci un fișier nu poate ajunge accidental în dreptul altcuiva.
• Tipul fișierului se verifică pe conținutul real, nu pe ce declară browserul, ca să nu se poată încărca un script deghizat în poză. Limită de 15 MB.

7. Separarea între cabinete

Fiecare cerere e legată de cabinetul din care vine, iar cabinetul se ia din identitatea verificată, niciodată din ce trimite browserul. Nu există cale prin care un specialist să ceară datele altuia. Pacientul vede doar propria fișă, după aceeași regulă.

8. Securitatea aplicației

• Antete de securitate impuse pe tot site-ul: politică de conținut restrictivă, interdicție de încadrare în alt site, HSTS.
• Toate datele primite sunt validate după o schemă strictă; câmpurile necunoscute sunt respinse, nu ignorate.
• Interogările către baza de date sunt parametrizate, deci nu se pot injecta comenzi.
• Limitare de trafic pe adresă IP, mai strânsă pe rutele publice.
• Nu folosim unelte de măsurare sau înregistrare a ecranelor în aplicație și în portal. Statisticile rulează doar pe site-ul public de prezentare, cu acordul vizitatorului.

9. Jurnal de acces

Accesul la documentele medicale ale unui pacient se înregistrează: cine a accesat, ce pacient, ce document, de la ce adresă IP și când. Aplicația doar adaugă intrări în jurnal; nu există nicio funcție prin care o intrare să fie modificată sau ștearsă separat. Jurnalul supraviețuiește ștergerii unei fișe de pacient, ca să rămână proba accesului, și se șterge odată cu întregul cabinet, împreună cu datele la care se referă.

10. Copii de siguranță

Baza de date are o copie automată zilnică, cu păstrare de 7 zile, ținută de furnizorul de găzduire. Copiile se rotesc singure. Nu le deschidem ca să restaurăm conturi șterse de utilizator, ci doar în caz de defecțiune tehnică.

11. Ștergere și portabilitate

• Ștergerea unui pacient elimină fișa, tot ce ține de ea și fișierele lui din stocare, plus contul lui de portal.
• Ștergerea cabinetului face același lucru pentru toți pacienții, apoi pentru datele cabinetului și conturile lui. Nu există ștergere „de formă", care doar ascunde datele.
• Înainte de ștergere, specialistul își poate descărca o arhivă completă cu datele și fișierele cabinetului, ca să-și poată respecta propriile obligații de păstrare.

12. Medii separate

Dezvoltarea și testarea se fac pe o bază de date complet separată, cu date de test. Nimeni nu lucrează pe datele reale ale cabinetelor.

13. Dacă apare o încălcare de securitate

Anunțăm specialistul (operatorul) fără întârziere nejustificată după ce aflăm, cu ce știm la momentul respectiv: ce s-a întâmplat, ce categorii și cam câte persoane sunt afectate, ce urmări sunt probabile și ce am făcut. Scopul e ca operatorul să-și poată respecta termenul de 72 de ore către ANSPDCP.

14. Ce urmează

Ca să fie clar ce e făcut și ce e în lucru: extinderea jurnalului de acces peste documentele medicale, către restul datelor de pacient; monitorizare automată a erorilor; și izolare impusă și la nivelul bazei de date, ca al doilea strat peste cel din aplicație. Actualizăm documentul când intră.

15. Întrebări

Pentru orice lămurire sau pentru un chestionar de securitate, scrie la contact@cabinetuldigital.ro.