> Los controles de seguridad de AuraCliniq con nombre, alcance y algoritmo: AES-256-GCM en archivos clínicos, TLS en tránsito, aislamiento entre clínicas en el motor de PostgreSQL y respaldo verificado. Página original: https://auracliniq.com/seguridad.html Sitio: AuraCliniq — software médico y expediente clínico electrónico (Honduras). Resumen del producto para modelos de lenguaje: https://auracliniq.com/llms.txt --- # Seguridad e Infraestructura Arquitectura diseñada por Aura Dev Studio En AuraCliniq sabemos que un expediente clínico no es solo un documento, es la salud de un paciente. Por eso, hemos construido nuestra plataforma sobre una arquitectura tecnológica robusta, priorizando la integridad, la disponibilidad y la encriptación por encima de todo. ### Servidores Privados DigitalOcean Nuestra plataforma opera en infraestructuras de alto rendimiento (Droplets) alojadas en DigitalOcean. Contamos con monitoreo continuo y una página de estado pública, además de redes seguras contra ataques de denegación de servicio (DDoS). ### Aislamiento por Docker AuraCliniq no corre como un software tradicional; cada entorno está contenedorizado (Docker). Esto significa que los procesos están aislados a nivel de sistema operativo, previniendo intrusiones laterales. ## 1. Cifrado de la Información Aplicamos cifrado en tres frentes distintos, y conviene distinguirlos porque no son lo mismo: - **Archivos clínicos (AES-256-GCM):** cada resultado de laboratorio, imagen o documento que se adjunta a un expediente se cifra *antes* de escribirse en disco. La llave de cifrado se guarda separada de los datos. Un archivo copiado del servidor es ilegible sin ella. - **Respaldos (AES-256):** cada respaldo de la base de datos se cifra antes de almacenarse. Un respaldo sin cifrar es una copia completa de la clínica esperando a que alguien la encuentre. - **Tránsito (TLS/HTTPS):** todo el tráfico entre el navegador de su clínica y nuestros servidores viaja cifrado mediante Caddy. Ninguna contraseña, diagnóstico o mensaje puede leerse en el camino. ## 2. Aislamiento de Datos entre Clínicas El aislamiento entre clínicas está implementado a nivel del **motor de base de datos** (Row Level Security de PostgreSQL), no en la lógica de la aplicación. La diferencia es sustantiva: si una consulta del sistema omitiera filtrar por clínica —por un error de programación, hoy o dentro de tres años— PostgreSQL devuelve cero filas en vez de datos ajenos. El comportamiento por defecto es negar el acceso, no concederlo. ## 3. Control de Acceso y Autenticación La seguridad de las cuentas se apoya en cuatro controles, todos activos hoy: - **Verificación en dos pasos (2FA):** disponible para médicos y para el personal administrativo. El código de un solo uso se envía por **WhatsApp**, con envío por correo electrónico como canal de respaldo. Una contraseña filtrada no alcanza para entrar. - **Contraseñas con hash bcrypt:** nunca se almacenan en texto plano. Ningún miembro de nuestro equipo puede leerlas, ni tampoco quien obtuviera acceso a la base de datos. - **Permisos por rol:** la gestión de usuarios, la bitácora y los informes exigen el rol que corresponde, y el servidor lo verifica en cada petición, no solo la pantalla. La historia clínica —consultas, diagnósticos, recetas y archivos— solo la ven los médicos y la administración de la clínica; la recepción y facturación trabajan con los datos de contacto y las alertas, y el servidor les niega el resto. Cada apertura de un expediente queda registrada en la bitácora. - **Límite de intentos de inicio de sesión:** los intentos repetidos se bloquean automáticamente, lo que hace inviable probar contraseñas por fuerza bruta. ## 4. Respaldos y Restauración Verificada Operamos tres redes de seguridad independientes: - **Respaldo diario de la base de datos:** automático, cifrado, conservado **30 días**. Cubre historiales médicos, archivos clínicos adjuntos e información transaccional. - **Copia en un segundo proveedor:** cada noche, ese respaldo —base de datos, archivos clínicos y configuración del sistema— se guarda también, ya cifrado, en **Cloudflare R2**, un proveedor distinto del que aloja la plataforma. Si el proveedor principal tuviera un problema grave, la información sigue a salvo en otro lugar. Cada copia se verifica al guardarse, y probamos descargarla y abrirla. - **Copias de la infraestructura completa:** gestionadas por DigitalOcean con retención de 7 días, almacenadas fuera del servidor. Ante un fallo del equipo, el sistema íntegro se levanta desde ahí. Y un punto que casi nadie publica: **probamos la restauración**. Tomamos un respaldo real, lo restauramos en un entorno aislado y comparamos tabla por tabla contra producción. Un respaldo que nunca se restauró no es un respaldo; es una suposición. ## 5. Bitácora de Auditoría Cada acceso a un expediente queda registrado con usuario, acción y fecha. Ante una consulta interna o un reclamo, la respuesta no depende de la memoria de nadie: está en el registro. ## 6. Monitoreo y Disponibilidad El servicio se monitorea de forma continua desde una infraestructura **independiente de la nuestra**, de modo que siga observando incluso si nuestros servidores fallan. El estado en tiempo real es público y cualquiera puede consultarlo en [estado.auracliniq.com](https://estado.auracliniq.com). ## 7. Infraestructura AuraCliniq opera sobre **PostgreSQL**, un motor relacional con garantías transaccionales (ACID) que aseguran la integridad de cada expediente. Cada servicio corre en contenedores aislados (Docker), lo que evita que un problema en un componente se propague al resto. Los datos residen en centros de datos de DigitalOcean en Nueva York, Estados Unidos. ¿Necesita que su departamento de IT evalúe nuestra infraestructura? Contáctenos a través de nuestro soporte técnico oficial.