Mesures de seguretat

Principis

• Protecció des del disseny i per defecte (article 25 del RGPD): cada eina neix amb permisos mínims, dades mínimes i traçabilitat.
• Separació estricta entre centres: cap consulta pot creuar dades de dos centres; la pertinença, el rol i el permís es comproven al servidor en cada petició.
• Res sense confirmació humana: les propostes automatitzades (horaris, guàrdies, assistent) s’apliquen només quan una persona les confirma.
• Sense tercers innecessaris: cap analítica, cap publicitat, cap recurs extern que identifiqui les persones.

Identificació i accés

• Contrasenyes amb requisits de robustesa (longitud mínima, majúscules, minúscules, números i símbols) i comprovació que no apareguin en filtracions conegudes. Es guarda només el seu resum criptogràfic.
• Verificació obligatòria del correu electrònic abans d’activar el compte.
• Doble factor d’autenticació obligatori (aplicació d’autenticació amb codi QR, estàndard TOTP) per a tots els comptes amb permisos d’administració de plataforma.
• Sessions que caduquen automàticament al cap de 60 minuts (12 hores al portal de famílies) i es tanquen a totes les pestanyes en tancar-ne una.
• La sessió viatja en una galeta HttpOnly, Secure i SameSite=Strict limitada a l’API, de manera que cap script del navegador ni cap altre lloc web pot llegir-la. Les peticions que modifiquen dades exigeixen a més un origen de confiança.
• Invitacions nominatives amb enllaç d’un sol ús, caducitat curta i vinculació al correu verificat de la persona destinatària.
• Limitació de velocitat en els punts d’entrada (registre, inici de sessió, verificacions) per frenar atacs de força bruta.

Autorització

• Model de permisos per centre, pertinença, rol i permís específic, aplicat al servidor. Amagar una opció a la interfície mai es considera una mesura de seguretat.
• Els permisos de plataforma (revisió d’altes de centres, administració) requereixen doble factor a cada sessió.
• L’accés a la informació més sensible (per exemple, plans individualitzats) queda registrat individualment.

Xifratge

• Tot el trànsit va xifrat amb TLS i el servei imposa HTTPS estricte (HSTS).
• Els camps més sensibles es guarden xifrats a la base de dades, amb claus separades de les credencials de l’aplicació.
• Els documents contractuals i les evidències de signatura es xifren amb XChaCha20-Poly1305 amb una clau pròpia, i cada accés hi queda registrat.
• Les còpies de seguretat es xifren abans de sortir del servidor.

Traçabilitat i auditoria

• Registre d’auditoria de les accions rellevants: qui, què, quan, des d’on i sobre quina entitat, amb les dades sensibles redactades.
• Registre versionat de l’acceptació de les condicions d’ús i de la lectura de la política de privacitat per cada compte.
• Els contractes conserven la versió de la plantilla, el resum criptogràfic del document i la pista d’auditoria de la signatura.

Minimització, conservació i supressió

• Els camps operatius estan dissenyats per no admetre dades que la finalitat no requereix.
• Política de conservació configurada per tipus de dada, amb anonimització irreversible o supressió automàtica en vèncer el termini (terminis a la política de privacitat).
• Diferenciació entre baixa operativa i supressió definitiva per preservar els historials que el centre ha de conservar per obligació legal.
• Retorn de les dades al centre en format reutilitzable en acabar el servei.

Infraestructura i operació

• Allotjament en un centre de dades de la Unió Europea, amb accés administratiu restringit per clau i sense contrasenyes.
• Secrets (claus, contrasenyes de serveis) gestionats fora del codi i del repositori, amb permisos restringits al sistema.
• Desplegaments amb comprovacions prèvies que refusen una configuració insegura o incompleta (per exemple, sense doble factor obligatori o sense els secrets necessaris) i comprovacions posteriors que verifiquen que el servei ha arrencat correctament.
• Còpies de seguretat periòdiques, xifrades i emmagatzemades fora del servidor, amb retenció de 30 dies i procediment de restauració verificable.
• Actualitzacions de seguretat de les dependències i revisió automàtica de vulnerabilitats conegudes.
• Capçaleres de seguretat del navegador (política de continguts, protecció contra emmarcament i contra la detecció de tipus).

Gestió d’incidents i violacions de seguretat

• Procediment documentat de resposta: contenció, anàlisi, comunicació i mesures correctores.
• Notificació al centre responsable, sense dilació indeguda, de qualsevol violació de la seguretat que afecti les seves dades, amb la informació necessària perquè pugui notificar-la a l’autoritat de control dins de les 72 hores i, si escau, a les persones afectades.
• Per als tractaments dels quals Hall és responsable, notificació directa a l’AEPD i a les persones afectades en els termes dels articles 33 i 34 del RGPD.

Proveïdors i subencarregats

Hall només utilitza proveïdors amb contracte d’encàrrec, ubicats a la Unió Europea o amb garanties adequades de transferència, i els llista a la política de privacitat. Cap proveïdor pot utilitzar les dades per a finalitats pròpies, i el proveïdor del model d’intel·ligència artificial de l’assistent no les utilitza per entrenar models.

Què no afirmem encara

Hall no afirma disposar d’una certificació externa (ISO 27001, Esquema Nacional de Seguretat) fins que l’hagi obtinguda i pugui acreditar-la. Els centres públics que necessitin una declaració o certificació de conformitat amb l’Esquema Nacional de Seguretat per contractar poden demanar a Hall l’estat d’aquest procés.

Versió

Document hall-security-v1.0. Aquesta pàgina descriu mesures implementades, no intencions; es revisa a cada canvi que les afecti i es pot aportar com a annex del contracte d’encàrrec.