Un resumen de las medidas que protegen los datos en FlowDule: quién puede entrar, cómo se mantienen separados y cifrados los datos, qué queda registrado y cómo se eliminan los datos.
El artículo 32 del Reglamento General de Protección de Datos exige que tanto el responsable como el encargado del tratamiento adopten medidas técnicas y organizativas adecuadas. Esta página ofrece una visión general del modelo de seguridad de FlowDule, en un lenguaje que podéis usar en vuestra propia documentación. Esta visión general es informativa: el nivel de seguridad vinculante resulta del acuerdo de tratamiento de datos aceptado, del anexo del cliente y del anexo TOMS vinculado a una versión, que prevalece en caso de discrepancia.
La descripción cubre identidad y acceso, separación de datos entre cadenas, cifrado, trazabilidad, integridad de los datos, eliminación y operación.
Identidad y acceso, separación por cadena, cifrado, trazabilidad e integridad de los datos
El inicio de sesión se realiza a través de AWS Cognito con tokens firmados. El acceso se rige por el rol de la persona usuaria y por la cadena y la ubicación a las que pertenece. Si no tiene acceso, la solicitud se rechaza sin revelar si los datos existen siquiera.
Los datos pertenecen a una cadena cada vez. La separación entre clientes se aplica en las capas relevantes: interfaz de usuario, API, lógica de aplicación, base de datos y acceso a archivos, donde row-level security en la base de datos está configurada para rechazar consultas más allá de la cadena en la que la persona ha iniciado sesión. El acceso se evalúa según la pertenencia al cliente, el rol, la ubicación y la relación laboral o de tratamiento correspondiente.
La comunicación con FlowDule se protege con cifrado de transporte moderno. La línea base de producción aprobada aplica cifrado en reposo para las bases de datos, los archivos y los campos sensibles relevantes, además de una gestión controlada de claves con AWS KMS. La implementación criptográfica concreta, el estado de la migración y el acceso a las claves se documentan en el material TOMS y de evidencia confidencial, y solo se facilitan cuando es necesario a través de un canal seguro.
Las acciones relevantes sobre datos de clientes e historiales deben poder rastrearse hasta una persona usuaria identificada o hasta un componente del sistema inequívoco. Los registros se protegen frente a modificación y lectura no autorizadas, tienen un plazo de conservación documentado y no incluyen texto de historial, contraseñas ni tokens. La cobertura de registro está en fase de prueba, y el cliente es responsable de comprobar los accesos por motivos de trabajo de sus propias personas usuarias.
Las notas del historial se versionan. Una corrección se hace como un añadido y el texto original se conserva, de modo que el historial puede leerse tal como era entonces.
El perfil de conservación del cliente se determina según el grupo profesional, el país, la categoría de datos y la finalidad. La eliminación debe abarcar las bases de datos, los archivos, las comparticiones, las colas, las cachés, los archivos de exportación y otras copias activas relevantes, mientras que las copias de seguridad se retiran mediante una rotación documentada. La conservación, la eliminación y la retención legal (legal hold) están en fase de prueba y no se presentan como controles verificados hasta que la prueba haya sido aprobada. Las reglas sobre cuánto tiempo se guardan los datos de historiales, y qué ocurre ante una solicitud de supresión, se describen aparte.
Conservación de datos de historiales
La producción principal se ejecuta en AWS en regiones de la UE: base de datos, API, caché, secretos y KMS principalmente en eu-north-1, archivos en eu-central-1 y eu-north-1 e inicio de sesión en eu-central-1 según la última línea base. La entrega global y los registros de operación no pueden describirse como totalmente fijados a una región, y el alojamiento en la UE no es por sí solo una prueba de que no pueda producirse una transferencia a un tercer país. La gestión de vulnerabilidades y de cambios, la rotación de parches y de claves conforme al plan de claves aprobado, la respuesta a incidentes, la continuidad y una prueba de restauración aislada con resultado medido son requisitos que solo se presentan como verificados cuando los controles se han probado y aprobado.
SeguridadEl acuerdo entre ustedes como responsable del tratamiento y FlowDule como encargado. Las medidas vinculantes del artículo 32 figuran en el anexo TOMS vinculado a versión y hash, que se acepta con el Anexo A del cliente. Esta página es solo un resumen informativo.
Leer el acuerdoLa lista de proveedores que tratan datos por cuenta de FlowDule y cómo se notifican los cambios.
Ver subencargadosEl anexo TOMS aceptado se identifica con título, versión y hash del documento en el Anexo A del cliente. Una revisión empieza normalmente por las TOMS aceptadas, los resúmenes de prueba pertinentes y la documentación de proveedores, y los detalles que puedan comprometer la seguridad o la confidencialidad de otros clientes solo se facilitan mediante un proceso seguro y confidencial. Escribid a privacy@flowdule.com indicando control y periodo.