El servicio de documentos · cifrado, acceso y los límites que son reales
Todas las afirmaciones de cumplimiento de este sitio —la americana, la europea, la británica, la alemana— acaban apuntando a una misma maquinaria: el servicio que guarda los documentos clínicos. Esta página explica cómo funciona, en lenguaje corriente, y después hace algo que casi toda la documentación de proveedor evita.
Enumera los riesgos que no tienen arreglo técnico. No los que resolvimos y nos gustaría contarle, sino aquellos en los que la respuesta honesta es «esto puede pasar, esta es la razón de haberlo elegido así, y esto es lo que usted tiene que hacer al respecto». Si solo lee una sección, lea esa.
Imagine cada documento clínico dentro de una caja con su propio candado, y cada candado con una llave distinta. Esas llaves están a su vez guardadas en una caja fuerte. Los documentos y las llavecitas viven en su base de datos. La llave de la caja fuerte no.
Ese es todo el diseño. Todo lo de abajo es detalle sobre él, y merece la pena enunciar las consecuencias antes que la mecánica:
Quien copie su base de datos entera se lleva las cajas y las llavecitas cerradas. Sin la llave de la caja fuerte, no se abre ninguna. Eso es lo que pone a su alcance la exención por cifrado del derecho de brechas: puede sostener que los datos eran ininteligibles, siempre que no se llevaran también la llave de la caja fuerte.
Para eliminar un documento se destruye su llavecita. La caja queda, vacía y para siempre inabrible. Eso es más fuerte que borrar una fila: una fila borrada vuelve desde la copia de seguridad de anoche, una llave destruida no.
No hay copia maestra, ni depósito en el proveedor, ni servicio de recuperación. Si la llave de la caja fuerte desaparece, todos los documentos clínicos que usted guarda desaparecen con ella. Esto es deliberado, y la sección 05 explica por qué cualquier «solución» sería peor que el problema.
La técnica se llama cifrado de sobre, y es la que usan los bancos y los proveedores de nube para el mismo problema. Hay tres capas. La razón de que sean tres y no una está en la tercera columna.
| Capa | Qué es | Por qué está separada |
|---|---|---|
| La versión del documento | El fichero en sí —un informe de sesión, un registro de incidente, un documento de identidad— cifrado con AES-256-GCM. El resultado cifrado se escribe en un directorio propio en disco, fuera del almacén de ficheros ordinario de Odoo, y nunca se sirve por la ruta normal de descarga. | Mantener el texto cifrado fuera del área de ficheros ordinaria significa que un servidor web mal configurado no puede publicar ficheros clínicos por accidente, porque no están donde un servidor web miraría. |
| La clave de datos (DEK) | Una clave aleatoria nueva de 256 bits, generada para cada versión de cada documento. No por paciente, no por documento: por versión. Se guarda en la base de datos, pero solo en forma envuelta. | Una clave por versión es lo que hace precisa la eliminación. Destruir la clave de una versión elimina exactamente esa versión y ninguna otra, así que se puede conservar una corrección mientras se elimina el original, o al revés. |
| La clave de instalación (KEK) | Una sola clave de 256 bits para toda la instalación, guardada en un fichero del servidor, que envuelve todas las claves de datos. Nunca se guarda en la base de datos y nunca sale del servidor. | Esta es la separación que hace el trabajo. La base de datos y las claves son cosas distintas, en sitios distintos, con copias de seguridad distintas, así que conseguir una no le da la otra. |
Existen seis cosas por cada versión de documento. Se mantienen deliberadamente en sitios distintos, porque todo el diseño descansa en que ningún sitio guarde dos de ellas.
| La pieza | Dónde se guarda | Qué le da tener solo esto |
|---|---|---|
| El fichero en sí, cifrado | Un directorio propio en el servidor, dispuesto como
<store>/<first 2 of uuid>/<next 2>/<uuid>.enc.v<version>. Los directorios son solo del propietario, los ficheros de lectura y escritura del propietario. Fuera del almacén de ficheros de Odoo, así que no se alcanza por /web/content y no lo toca la recolección de basura de adjuntos. |
Nada. Texto cifrado autenticado sin clave. Un fichero por versión, así que archivar una versión nueva no puede sobrescribir la anterior. |
| El nonce y dos hashes | En la base de datos, en la fila de la versión: el nonce usado en este cifrado, un hash del texto plano y un hash del texto cifrado. | Nada por sí solo , pero el hash del texto plano hace falta para reconstruir la vinculación de abajo, así que perderlo hace indescifrable el texto cifrado. Eso es de diseño, no un descuido. |
| La clave de datos, envuelta | En la base de datos, cifrada bajo la clave de instalación. La forma desenvuelta existe solo en memoria, durante una lectura, y se descarta inmediatamente después. | Nada sin la clave de instalación. Una base de datos robada le da claves envueltas y rutas de texto cifrado, y ninguna de las dos abre nada. |
| La clave de instalación | Un fichero en el servidor, legible solo por la cuenta con la que corre Odoo. Nunca en la base de datos. Nunca en el almacén de ficheros. Nunca dentro de una raíz de copia de seguridad declarada : cada una de esas comprobaciones se hace al arrancar y es fatal, no un aviso. | Nada sin la base de datos, que guarda las claves de datos envueltas, y sin el almacén de texto cifrado. Hacen falta tres cosas separadas, y se guardan en tres sitios. |
| Las reglas de acceso | En la base de datos, como registros: quién puede abrir qué, con qué base y hasta cuándo. | Deciden qué puede abrir un compañero . No tienen ningún efecto sobre alguien que tenga los ficheros pero no las claves, que es el caso para el que está el cifrado. |
| El registro de accesos | En la base de datos, de solo anexado y encadenado por hash. Cada lectura, no solo cada cambio. | El registro de quién abrió qué. Se escribe antes de entregar el contenido, así que una descarga que alguien cancela sigue quedando registrada como un acceso. |
Todo lo de arriba es más fácil de comprobar contra estos. El primero es lo que ocurre cuando se archiva un documento; el segundo es lo que ocurre cuando alguien pide ver uno. Lea el segundo con atención : es donde la mayoría de los sistemas son más débiles de lo que afirman.
Un informe de sesión, un registro de incidente, un documento de identidad. Llega a memoria.
32 bytes de la fuente criptográfica de aleatoriedad del sistema operativo. No derivada de una contraseña, no reutilizada de otro documento, no reutilizada de la versión anterior de este documento.
una clave por versión: esto es lo que hace precisa la eliminaciónUn SHA-256 del texto plano, y un número de 96 bits usado una sola vez. Ninguna función del núcleo de cifrado acepta un nonce de quien la llama, así que aquí no se puede cometer el clásico error de reutilización.
AES-256-GCM, con uuid | número de versión | huella del contenido como datos autenticados adicionales. Esa vinculación es obligatoria. Un texto cifrado que después se copie a otro documento o a otra versión se negará a descifrarse en lugar de abrirse en silencio bajo las reglas de acceso de la persona equivocada.
Cifrada con la clave de instalación, etiquetada con la generación de la clave y su espacio de nombres, y guardada en la base de datos en esa forma. La clave desenvuelta se descarta de la memoria de inmediato.
Se escribe en un fichero temporal del directorio de destino, se vuelca al disco físico y luego se renombra en su sitio, así que una caída a mitad de escritura no puede dejar media versión. El fichero temporal contiene texto cifrado, nunca texto plano.
Ruta de almacenamiento, nonce, los dos hashes, tamaño y la clave envuelta. Nunca el texto plano, nunca una clave desenvuelta, nunca la clave de instalación.
Quién lo archivó, cuándo, de qué tamaño y de qué tipo. De solo anexado y encadenado con las entradas anteriores.
Un clínico en el back office, o un paciente en su propia página de historias. Los dos pasan por las mismas comprobaciones; ninguna vía se salta las de la otra.
En la vía de cara al paciente, las historias no se muestran a una cuenta que solo tiene contraseña. El rechazo dice qué hacer al respecto en lugar de fingir que el documento no existe.
Un límite de peticiones por persona en la vía de cara al paciente. Se dice con claridad, porque decirlo no filtra nada y ahorra una llamada de soporte.
Primero las reglas de denegación : una sola es definitiva. Después las reglas de permiso: si no encaja ninguna, la respuesta es no. El acceso de emergencia se consulta solo en ese punto, así que puede alcanzar lo que nunca se concedió pero no puede revocar una denegación. Las etiquetas de sensibilidad se aplican al final y solo pueden quitar acceso.
cerrado por defecto · en esta comprobación no existe ninguna rama de superusuarioLa entrada se escribe primero, así que una transferencia que alguien aborta a medias sigue constando como un acceso. El registro es de solo anexado y está encadenado por hash; las entradas no se pueden quitar después en silencio, ni por nosotros ni por su propia administración.
Antes de tocar ninguna clave. Así, la corrupción en el almacén se informa como corrupción y no aparece después como un confuso fallo de autenticación.
Se usa para desenvolver la clave de datos de esta versión, comprobando sobre la marcha la generación de la clave y su espacio de nombres. Una clave envuelta para un espacio de nombres no se puede desenvolver como otro, ni siquiera por alguien que tenga las dos claves de instalación.
El identificador del documento, el número de versión y la huella del contenido se reconstruyen y tienen que coincidir. La manipulación, una clave equivocada y un texto cifrado movido desde otro registro fallan todos aquí, y todos fallan de forma idéntica, porque decirle a un atacante qué parte falló es información gratis.
La clave de datos se descarta de memoria. Ningún camino de código de este producto escribe en disco un byte descifrado : ni para previsualizaciones, ni para miniaturas, ni para indexar búsquedas.
Una versión eliminada informa de que su clave ya no existe. No hay alternativa, ni copia en caché, ni ruta de recuperación, que es precisamente el sentido de eliminarla así.
Una sola clave protege todas las claves de datos de la instalación, así que su manejo es la parte que merece revisarse línea a línea. Todas las comprobaciones de abajo se ejecutan al arrancar y todas son fatales: el servidor no arranca, en lugar de funcionar con una protección que usted cree tener y no tiene.
32 bytes de la fuente de aleatoriedad del sistema operativo, escritos en un fichero creado con permiso de lectura solo para el propietario en un único paso, así que nunca es legible brevemente por nadie más.
El fichero debe contener o 32 bytes en bruto o 64 caracteres hexadecimales. No se acepta nada más: una frase de paso se rechaza en lugar de estirarse hasta convertirla en clave, porque una frase de paso estirada es una clave más débil que parece más fuerte.
Ni en la base de datos. Ni en el directorio de datos de Odoo, ni en su ruta de addons, ni en su almacén de ficheros. Ni dentro del almacén de texto cifrado. Ni dentro de ningún directorio que usted haya declarado como raíz de copia de seguridad.
Esa última es la que la gente falla. Una copia de seguridad que contiene a la vez la base de datos y la clave es una clave comprometida, y deja la instalación fuera del puerto seguro americano de brechas y de la exención europea del art. 34(3)(a), que es la razón entera de que el cifrado esté aquí.
Rotar la clave de instalación vuelve a envolver las claves de datos y no reescribe ni un solo byte de texto cifrado. Cien mil documentos rotan tan rápido como se puedan volver a cifrar cien claves, no tan rápido como se puedan reescribir cien mil ficheros.
El número de generación va dentro de la envoltura, así que una clave envuelta bajo la generación antigua no se puede abrir en silencio como si fuera la nueva.
Eliminar una versión sobrescribe su clave envuelta con bytes aleatorios en lugar de dejar el campo en blanco, así que no queda nada que recuperar ni siquiera de la página de la base de datos.
El envoltorio de metadatos de la versión y todo el registro de accesos sobreviven: usted todavía puede demostrar que tuvo el documento y que lo eliminó correctamente. Una versión no se puede borrar mientras su clave siga existiendo, así que el orden nunca puede ser el equivocado.
Estos son los sitios donde el cifrado se suele implementar casi correctamente, y ese casi es toda la diferencia.
Cuando se cifra una versión, el cifrado se ata al identificador de ese documento, a su número de versión y a una huella de su contenido. Los criptógrafos lo llaman datos autenticados adicionales, y aquí es obligatorio: ninguna llamada puede saltárselo.
El efecto: un texto cifrado copiado en otro documento, o en otra versión, se niega a descifrarse. No se abre en silencio bajo las reglas de acceso del paciente equivocado, que es precisamente el ataque al que está expuesto un sistema sin esta vinculación.
AES-GCM es catastróficamente débil si se usa dos veces el mismo nonce con la misma clave: un atacante que vea dos textos cifrados así puede recuperar información de ambos. Es el error de implementación clásico.
Aquí cada cifrado genera su propio nonce y ninguna función acepta un nonce de quien la llama. El error no se hace más difícil de cometer; se hace imposible de cometer.
El núcleo de cifrado está escrito como una pieza independiente, sin dependencia del framework de la aplicación, para que quien audite la afirmación sobre el cifrado pueda leerla y probarla por separado sin ejecutar un sistema de clínica.
Si su equipo de seguridad quiere verificar lo que dice esta página en lugar de creérselo, ese es el fichero que hay que darles, y es corto.
Donde la ley separa las notas de proceso del propio terapeuta de la historia clínica —la excepción americana de las notas de psicoterapia es el caso más claro—, esas notas se cifran bajo una segunda clave de instalación, distinta. La clave que abre la historia ordinaria no las abre.
Esto importa porque convierte la separación en una propiedad del almacenamiento y no de las reglas de acceso. Si mañana todos los permisos del sistema estuvieran mal, la clave ordinaria seguiría sin descifrar esas notas. También significa que la segunda clave debe configurarse antes de arrancar: archivar una nota así sin ella falla en lugar de caer en silencio a la clave principal, porque una caída silenciosa destruiría la separación sin que nadie se diera cuenta.
A menudo se confunden. El cifrado protege frente a alguien que no debería estar en el sistema en absoluto. No hace nada contra el problema mucho más común: alguien que sí está en el sistema, mirando una historia que no tiene por qué leer.
Para eso está la capa de autorización, y funciona con un principio distinto al de casi todos los sistemas: el acceso sigue a la relación de tratamiento, no al cargo.
Cada vez. No una vez al iniciar sesión.
Dicho explícitamente, porque los auditores lo preguntan
A veces un clínico necesita de verdad una historia con la que no tiene relación: una crisis, una llamada fuera de horario, un compañero que cae enfermo. Donde su organización lo permita, hay acceso de rotura de cristal. Usarlo abre una sesión registrada que se revisa después.
Un sistema que solo deniega es inseguro a su manera, y en el Reino Unido es explícitamente no conforme: el Principio Caldicott 7 hace el deber de compartir tan importante como el deber de proteger. Así que el acceso existe, y su uso nunca es silencioso.
Contra un tipo de documento; ese tipo es lo que decide las reglas, el periodo de conservación y quién puede abrirlo.
En palabras claras, antes de guardarse. Casi todos los errores de archivado ocurren porque nadie sabía dónde iba a aterrizar un documento.
Vinculada a este documento, a esta versión y a una huella de este contenido.
La clave desenvuelta existe solo en memoria, durante el momento en que hace falta.
Con sus propios permisos, en su propio directorio.
Cada apertura registrada antes de que aparezca el contenido.
Como una versión nueva, con su propia clave nueva. El original queda intacto y sigue siendo legible: una historia modificable no vale nada como prueba.
Se niega a descifrarse, porque el cifrado está vinculado a la identidad del documento original.
Desde el final de la relación, no desde el día en que se creó el fichero.
El material de la clave se sobrescribe con bytes aleatorios y después se borra la fila de la clave. Sobrescribir primero es deliberado: si el proceso se interrumpe, el modo de fallo es un documento que no se puede leer, nunca uno que sobrevive cuando no debía.
Usted todavía puede demostrar que la historia existió, quién la vio a lo largo de veinte años y que se eliminó en plazo. El contenido es ilegible para cualquiera, de forma permanente, nosotros incluidos.
Todo lo de arriba es lo que el sistema hace bien. Esta sección es lo contrario: los sitios donde puede pasar algo malo y ninguna cantidad de ingeniería lo cierra , porque cerrarlo costaría más protección de la que compra.
Cada uno dice qué ocurre de verdad, qué hacemos al respecto y qué queda de su lado. Si un proveedor le dice que su cifrado no tiene ninguno de estos, o no lo ha pensado o espera que usted tampoco.
Qué ocurre: se borra el fichero de la clave, falla el disco, se reconstruye el servidor sin ella, o la única persona que sabía dónde estaba se ha marchado. Todos los documentos clínicos del sistema quedan permanentemente ilegibles. No difíciles de recuperar: imposibles. La base de datos está intacta y no vale nada.
Por qué no lo arreglamos: los únicos arreglos son una copia en poder del proveedor o una puerta trasera de recuperación. Los dos destruyen la propiedad por la que existe todo el diseño. Si tuviéramos una copia, «una base de datos robada no es una brecha» dejaría de ser cierto, y cada promesa de esta página sobre lo que no podemos ver sería falsa. Una clave recuperable es una clave que otro puede usar.
Qué hacemos: el sistema se niega a arrancar si la clave falta, en lugar de funcionar en silencio y dejar que usted descubra el problema cuando un documento no se abra. La comprobación de arranque también rechaza si el fichero de la clave es legible por alguien que no sea su propietario, o si pertenece a la cuenta equivocada.
Qué es suyo: haga copia de seguridad de la clave, aparte de los datos, y pruebe que puede restaurarla. Dos personas deberían saber dónde está. Este es el deber operativo de mayor consecuencia de toda la plataforma, y cuesta unos diez minutos hacerlo bien.
Qué ocurre: una administración envía por correo el fichero de la clave a un compañero, lo pega en un ticket, lo copia a un portátil, o un técnico que se va se queda una copia. Cualquiera que tenga las dos cosas , ese fichero y una copia de la base de datos, puede descifrar todos los documentos, sin conexión, sin iniciar sesión, y no se escribe nada en su registro de accesos , porque el registro anota las lecturas hechas a través de la aplicación, y esto se salta la aplicación por completo.
Por qué no lo arreglamos: la clave tiene que ser legible por el software que la usa. Cualquier proceso que pueda leerla puede copiarla. Los módulos de seguridad por hardware mueven este problema en lugar de resolverlo: el software sigue teniendo que poder pedirle al módulo que desenvuelva claves, así que un atacante con los privilegios de ese software sigue obteniendo texto plano.
Qué hacemos: los permisos del fichero se comprueban al arrancar, así que una clave legible por todos detiene el sistema en lugar de pasar desapercibida. Y como usted se aloja a sí mismo, nosotros no tenemos el fichero en absoluto : la población de personas que podrían copiarlo es su personal, no su personal más el nuestro.
Qué es suyo: trate la clave como un objeto físico controlado. Restrinja quién puede iniciar sesión en el servidor, use cuentas de administración individuales en lugar de una compartida y rote la clave cuando se marche alguien con acceso al servidor: la sección 06 explica por qué rotar es barato.
Qué ocurre: el fallo más silencioso y más común. Alguien configura una copia de seguridad que barre el servidor entero, y el fichero de la clave queda dentro del mismo archivo que la base de datos. Ahora una sola cinta robada contiene las dos mitades, el cifrado no protege nada y —peor todavía— usted seguiría reclamando la exención por cifrado en un informe de brecha, porque sobre el papel todo estaba cifrado.
Por qué es difícil: nada del sistema en marcha se ve distinto. Funciona perfectamente. El problema existe solo en la copia de seguridad, y solo importa el día en que la roban.
Qué hacemos: este es el único de esta lista contra el que en parte sí diseñamos algo. Usted declara sus directorios de copia de seguridad en la configuración, y el sistema se niega a arrancar si el fichero de la clave está dentro de uno de ellos. Si no declara ninguna ruta de copia de seguridad, avisa de que la exención no se puede verificar, porque una afirmación sin comprobar es la peligrosa.
Qué es suyo: declare las raíces de copia de seguridad con honestidad, y compruebe qué incluye de verdad su herramienta de copia en lugar de lo que usted cree que incluye.
Qué ocurre: una terapeuta abre el expediente de un paciente que además es su vecino. Una recepcionista busca a una celebridad local. Todas las reglas se cumplieron: la persona tenía una relación asistencial válida, o motivos válidos, y simplemente abusó de ello. Aquí el cifrado es irrelevante. Y el control de acceso también, porque el acceso estaba concedido.
Por qué ningún sistema lo arregla: el software no puede leer intenciones. Un sistema que lo intentara —bloqueando un acceso porque un nombre parece local— bloquearía trabajo clínico real en una emergencia, que es un daño por sí mismo y, en el Reino Unido, un incumplimiento por sí mismo.
Qué hacemos: hacerlo visible en lugar de imposible. Cada apertura queda registrada antes de que aparezca el contenido, en un registro que nadie puede editar, ni su administración ni nosotros. Las relaciones asistenciales terminan, y el acceso termina con ellas tras un breve periodo de gracia, así que la ventana es estrecha. El acceso de emergencia es un acto separado, deliberado y revisado, no una capacidad silenciosa.
Qué es suyo: alguien tiene que hacer de verdad esa lectura del registro. El módulo de gobernanza le da a la revisión un hogar —cadencia, revisor con nombre, rastro de hallazgos—, pero un registro que nadie mira no disuade a nadie. Este es el control que más a menudo existe sobre el papel y nunca ocurre.
Qué ocurre: para mostrar un documento a un clínico autorizado, el software tiene que descifrarlo. Durante ese momento existe en la memoria del servidor como texto legible. Alguien con control total del sistema operativo puede, en principio, leerlo ahí, o modificar el software para que guarde copias.
Por qué ningún sistema lo arregla: esto es cierto de cualquier sistema que muestre algo a alguien alguna vez. Si la máquina puede mostrar el documento, el dueño de la máquina puede obtener el documento. El cifrado protege los datos en reposo y en tránsito; no puede proteger los datos frente al ordenador que los está tratando lícitamente.
Qué hacemos: minimizar la ventana: el descifrado ocurre en memoria durante el momento de la lectura y el texto plano nunca se escribe en disco. Y el alojamiento propio significa que usted es la parte que tiene root, no nosotros.
Qué es suyo: la administración del servidor es el rol de mayor privilegio que tiene. Pocas personas, nombradas individualmente, claves en vez de contraseñas y un registro de quién tiene acceso. Va en la lista de altas y bajas, al lado de las cuentas clínicas.
Qué ocurre: una regla de conservación está mal configurada, o se ejecuta un borrado sobre la selección equivocada. Las claves se sobrescriben y los documentos son ilegibles. No hay deshacer, y restaurar la copia de seguridad de anoche no ayuda : la copia contiene el mismo texto cifrado, y su clave ya no está.
Por qué no lo arreglamos: una eliminación reversible no es una eliminación. Todo el valor del cripto-borrado ante un regulador es que no se puede deshacer. Una «papelera» para claves destruidas significaría que los datos nunca se destruyeron de verdad, y cada afirmación de supresión que usted hizo sería falsa.
Qué hacemos: las claves no se pueden borrar por ninguna vía ordinaria: la operación de borrado está bloqueada de plano y la eliminación ocurre solo por la ruta de borrado criptográfico, que escribe una entrada de auditoría a su paso. Las retenciones legales suspenden la eliminación por completo. La conservación cuenta desde fechas de anclaje almacenadas y no desde la antigüedad del fichero, así que la causa más común de eliminación con fecha equivocada no se da.
Qué es suyo: revise la configuración de conservación antes de arrancar, no después de la primera pasada de eliminación. Y confirme que las tareas programadas se están ejecutando de verdad: una tarea de conservación que se paró en silencio es un problema distinto, pero se descubre de la misma manera, es decir, demasiado tarde.
Qué ocurre: las historias de salud mental se conservan veinte años y a veces más. AES-256 no se considera hoy rompible, ni siquiera por los ordenadores cuánticos sobre los que se especula, pero ningún ingeniero honesto promete nada sobre 2046 sin que se le mueva la cara.
Por qué nadie lo arregla: no se puede comprar protección contra un resultado matemático que todavía no ha ocurrido. Quien venda almacenamiento «a prueba de cuántica» para historias clínicas está vendiendo un cuento.
Qué hacemos: hacer que el algoritmo y las claves sean sustituibles sin tocar sus datos. La rotación de claves vuelve a envolver todas las claves de datos bajo una clave de instalación nueva sin reescribir ni un solo byte de texto cifrado, así que es una tarea de fondo y no un proyecto de migración. La criptografía está aislada en un componente pequeño y revisable precisamente para poder sustituirla cuando llegue el momento.
Qué es suyo: rote periódicamente en lugar de nunca, y cuente con volver a cifrar una vez en la vida de una historia de veinte años. Planifíquelo como mantenimiento, no como una crisis.
Mire lo que tienen en común los siete. En todos los casos el «arreglo» que cerraría el riesgo —una clave recuperable, una eliminación reversible, un sistema que lee intenciones, protección frente a su propia administración— destruiría algo más valioso de lo que protege. La elección de diseño no es que estos riesgos se pasaran por alto. Es que cerrarlos haría falsas las garantías restantes.
Lo que queda de su lado es poco, concreto y sobre todo procedimental: haga copia de la clave por separado, controle quién puede llegar al servidor, declare sus rutas de copia de seguridad, lea el registro de accesos y revise una vez los ajustes de conservación. Esa lista cabe en una página y es toda la lista.
Dado que el riesgo 1 y el riesgo 2 son los dos puntos de mayor consecuencia de esta página, merece la pena ser preciso sobre qué partes son automáticas y cuáles son suyas.
| Comprobación | Estado | Qué ocurre |
|---|---|---|
| La clave existe | ✓ | Verificado al arrancar. Una clave ausente detiene el sistema en lugar de dejarlo funcionar y fallar más tarde, documento a documento, delante de un paciente. |
| Solo su propietario puede leerla | ✓ | Una clave legible por el grupo o por todos es fatal al arrancar, no un aviso en un registro que nadie lee. |
| Pertenece a la cuenta correcta | ✓ | Se comprueba contra la cuenta con la que corre el servicio. Una clave que pertenece al usuario de un técnico que se marchó es un hallazgo. |
| No está dentro de un directorio de copia de seguridad | ✓ | Usted declara sus raíces de copia de seguridad; el sistema se niega a arrancar si la clave está dentro de una. Si no declara ninguna, avisa de que la exención por brecha no se puede verificar. |
| No está en un sitio del que viajaría con los datos | ✓ | Hay una lista corta de directorios donde la clave nunca puede vivir, y se rechaza de plano. |
| Es una clave de verdad | ✓ | Se acepta solo como 32 bytes en bruto o 64 caracteres hexadecimales. Un fichero truncado o corrupto se rechaza en lugar de usarse para producir documentos que nadie podrá abrir jamás. |
| Tiene copia de seguridad, aparte | — | Suyo, y el software no puede ayudar. No podemos verificar una copia que no se nos permite ver, y un sistema que pudiera comprobar la copia de su propia clave sería un sistema capaz de alcanzarla. Dos personas, dos sitios, restauración probada. |
| Quién puede llegar al servidor | — | Suyo. Cualquiera con root puede leer la clave. Esa lista debería ser corta, con nombres y revisada cuando se marche gente. |
| Rotación cuando alguien se marcha | ⚙ | Soportada y barata: la rotación vuelve a envolver todas las claves de datos bajo una clave de instalación nueva sin reescribir ningún texto cifrado, y las claves sustituidas se pueden conservar para desenvolver lo que siga en curso. Decidir cuándo rotar es suyo. Después de que se marche una administración de servidor es el momento obvio, y es el que más se pasa por alto. |
Cada versión de cada documento clínico se cifra con su propia clave, vinculada a la identidad de ese documento para que no se pueda mover a otro sitio. Esas claves se envuelven bajo una única clave de instalación que vive fuera de la base de datos y nunca sale de su servidor, así que una base de datos robada no es una comunicación de datos, y la eliminación se hace destruyendo una clave en lugar de borrando una fila. Los documentos se abren solo para personas con una relación de tratamiento vigente, y cada apertura se escribe antes en un registro encadenado, así que el abuso es visible incluso cuando el acceso era legítimo. Lo que la ingeniería no puede arreglar está nombrado en la sección 05, y la versión corta de su parte es: haga copia de la clave por separado, mantenga el acceso al servidor corto y con nombres, declare sus rutas de copia de seguridad, lea el registro y revise una vez los ajustes de conservación antes de arrancar.
Cada página de país se apoya en la maquinaria descrita aquí y añade la maquinaria de derechos y gobernanza que exige su propia ley.
