> acerca de > terminos politicas > Medidas de seguridad

Medidas de seguridad

Medidas de seguridad
PDF

Medidas de seguridad de ProcessMind

Fecha de entrada en vigor: 14 de septiembre de 2026

Este documento describe las medidas técnicas y organizativas («TOM») que ProcessMind B.V. mantiene para proteger la confidencialidad, integridad y disponibilidad de los Datos del Cliente. ProcessMind aplica un enfoque de defensa en profundidad, en el que varias capas de seguridad independientes protegen los Datos del Cliente en todos los niveles: desde la red y la infraestructura hasta la identidad, la autorización, el aislamiento de datos, el cifrado, la supervisión y el desarrollo de software. Estas medidas complementan el Anexo sobre tratamiento de datos, la Política de privacidad y la Política de alojamiento SaaS. ProcessMind revisa y actualiza estas medidas al menos una vez al año.

Los Datos del Cliente nunca se venden, comparten ni utilizan por terceros para sus propios fines.

1. Seguridad de la infraestructura

1.1 Plataforma en la nube. ProcessMind está alojado exclusivamente en Amazon Web Services (AWS) en la UE (Fráncfort, Alemania, eu-central-1). AWS cuenta con las certificaciones ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 y PCI DSS. Consulte Programas de cumplimiento de AWS para obtener la lista completa.

1.2 Arquitectura sin servidor. La lógica de la aplicación de ProcessMind se ejecuta en AWS Lambda y en servicios gestionados por AWS. ProcessMind no opera servidores de aplicaciones de larga duración gestionados por el cliente, lo que elimina una gran parte de las tareas de aplicación de parches al sistema operativo y de refuerzo de la seguridad de los servidores.

1.3 Límites de red. ProcessMind mantiene una VPC de AWS para los controles de bases de datos y de red. Aurora PostgreSQL se ejecuta en subredes privadas sin salida a Internet, no es de acceso público y tiene habilitados los registros de flujo de VPC. Por defecto, ProcessMind no ubica las funciones Lambda de la aplicación dentro de la VPC. Las funciones Lambda acceden a Aurora a través de AWS RDS Data API mediante TLS, utilizando autenticación de IAM y Secrets Manager.

1.4 Distribución de contenido y controles perimetrales. El sitio web dirigido a los clientes, la SPA del frontend y el tráfico de recursos públicos se sirven a través de Amazon CloudFront. Todas las distribuciones de CloudFront aplican una política TLS mínima de TLS 1.2 (2021). Las distribuciones del sitio web y de la SPA del frontend también añaden encabezados de respuesta de seguridad, incluidos HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, la política de referencia y la política de permisos. La distribución de recursos públicos utiliza CloudFront Origin Access Control para mantener privado el bucket de origen. El tráfico de API dirigido a los clientes se gestiona por separado mediante Amazon API Gateway: el tráfico HTTPS de solicitud/respuesta se sirve a través de una HTTP API en un subdominio de API dedicado, y las conexiones de clientes en tiempo real se sirven a través de una API WebSocket de API Gateway independiente en un subdominio WebSocket dedicado.

1.5 Separación de entornos. Los entornos de producción y desarrollo utilizan cuentas de AWS, bases de datos y pilas de infraestructura independientes. Las credenciales de los desarrolladores no permiten acceder a los Datos del Cliente de producción.

2. Cifrado de datos

2.1 Cifrado en tránsito. Todos los datos transmitidos entre los clientes y los servicios de ProcessMind se cifran mediante TLS 1.2 o superior. Los endpoints dirigidos a los clientes están disponibles a través de HTTPS. Los buckets de S3, los temas de SNS y las colas de SQS creados directamente por ProcessMind exigen acceso exclusivamente mediante SSL. El acceso a la base de datos a través de RDS Data API y las demás llamadas a servicios de AWS utilizan HTTPS/TLS.

2.2 Cifrado en reposo. Aurora PostgreSQL se cifra en reposo mediante claves de AWS KMS gestionadas por el cliente, con rotación automática de claves. Los buckets de S3 de datos de clientes y operativos creados directamente por ProcessMind, incluidos los buckets de cargas, recursos y registros de acceso, utilizan claves de KMS gestionadas por el cliente. Los grupos de registros de CloudWatch, los temas de SNS y las colas de SQS creados directamente por ProcessMind también utilizan claves de KMS gestionadas por el cliente. Los buckets de origen del sitio web y del frontend gestionados por SST utilizan cifrado del servidor de S3 gestionado por AWS (SSE-S3 / AES-256), en lugar de claves de KMS gestionadas por el cliente.

2.3 Gestión de claves y secretos. Las claves de cifrado de bases de datos se gestionan de forma centralizada mediante AWS KMS, y el acceso a las claves se rige por políticas de IAM que siguen los principios de privilegio mínimo. Las credenciales de la base de datos se almacenan en AWS Secrets Manager. El secreto maestro de Aurora y el secreto restringido del usuario de la aplicación rotan automáticamente cada treinta (30) días. Las claves y los secretos de producción nunca se almacenan en el código fuente; las credenciales exclusivas de desarrollo están aisladas de producción. Algunos recursos auxiliares gestionados por AWS/CDK/SST siguen utilizando cifrado gestionado por AWS cuando el servicio o el marco de trabajo no permite configurar claves gestionadas por el cliente.

3. Aislamiento y residencia de los datos

3.1 Aislamiento de inquilinos. Cada inquilino cliente recibe una instancia de base de datos dedicada y aislada. Los Datos del Cliente nunca se mezclan con los datos de otros clientes en el nivel de la base de datos. Los metadatos compartidos (por ejemplo, registros de cuentas, facturación y asignaciones de usuarios a inquilinos) se almacenan en una base de datos multiinquilino independiente con controles de acceso estrictos. Además, las tablas compartidas cuyo ámbito se limita a un inquilino o una organización están protegidas por políticas de seguridad a nivel de fila (RLS) de PostgreSQL, aplicadas mediante un contexto de base de datos específico para cada solicitud.

3.2 Residencia de los datos. Todos los Datos del Cliente, incluidas las bases de datos, las cargas de archivos, las copias de seguridad y los resultados de consultas, se almacenan exclusivamente en la UE (Fráncfort, Alemania). Cuando se contrata a un subencargado del tratamiento ubicado fuera del EEE para una actividad de tratamiento específica (por ejemplo, el tratamiento mediante modelos de IA o el procesamiento de pagos), la transferencia está cubierta por un mecanismo de transferencia adecuado, tal como se describe en la Adenda de tratamiento de datos, y el subencargado y su ubicación de tratamiento figuran en la Lista de subencargados.

3.3 Conservación y supresión de datos. Los plazos de conservación y supresión se establecen en la sección 6 del Anexo sobre tratamiento de datos. Los clientes pueden suprimir sus datos en cualquier momento mediante la aplicación o poniéndose en contacto con ProcessMind. Las copias de seguridad se eliminan al vencer los períodos de conservación de copias de seguridad aplicables (sección 7.1).

4. Gestión de identidades y accesos

4.1 Autenticación. ProcessMind admite el inicio de sesión único (SSO) mediante Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC y LinkedIn OAuth 2.0/OIDC. ProcessMind actúa como parte confiante y no almacena contraseñas de usuarios. El proveedor de identidad aplica la autenticación multifactor; por ejemplo, cuando una organización conecta Microsoft Entra ID (Azure AD), se aplican las políticas de acceso y MFA propias de dicha organización.

4.2 Gestión de sesiones. Las sesiones del navegador utilizan JSON Web Tokens (JWT) firmados, transmitidos mediante cookies seguras HttpOnly con los atributos SameSite y Secure. Las firmas de los tokens se validan en cada solicitud autenticada.

4.3 Modelo de autorización. ProcessMind no depende de los autorizadores nativos de API Gateway para sus API principales de la aplicación. La autorización se aplica mediante envoltorios compartidos de controladores Lambda que validan el estado de la sesión y el ámbito del inquilino antes de que se ejecute la lógica de negocio. Las rutas públicas se incluyen expresamente en una lista de permitidas para flujos no autenticados, webhooks, recepción de eventos y solicitudes CORS preflight. Los endpoints de API externos utilizan controladores de autenticación dedicados. El acceso a los Datos del Cliente se limita al contexto autenticado del inquilino o de la organización.

4.4 Privilegio mínimo. Los sistemas internos siguen el principio de privilegio mínimo. Las funciones de IAM se limitan a los recursos mínimos necesarios cuando el marco de trabajo permite una delimitación precisa. Algunas funciones generadas por SST/CDK utilizan políticas gestionadas o insertadas más amplias para los enlaces y la operación en tiempo de ejecución; estos casos se revisan, se limitan a recursos específicos cuando es posible y se registran como excepciones explícitas.

4.5 Controles de acceso de los empleados. El acceso de los empleados a los sistemas internos se gestiona mediante Active Directory con SSO y MFA obligatoria. El control de acceso basado en roles (RBAC) garantiza que el acceso a los Datos del Cliente se limite al personal autorizado que necesite conocerlos. Los derechos de acceso se revisan periódicamente.

5. Registro, supervisión y auditoría

5.1 Registro centralizado. El registro de acceso a la API HTTP y el registro de acceso a WebSocket están habilitados con campos JSON estructurados y se escriben en Amazon CloudWatch Logs con un período de retención de un (1) año. Esos grupos de registros de acceso están cifrados con una clave de AWS KMS administrada por el cliente. Los registros de la aplicación están centralizados en grupos de registros de Amazon CloudWatch cifrados con una clave de AWS KMS administrada por el cliente y se conservan durante diez (10) años. Los grupos de registros de auditoría y telemetría independientes también están cifrados con una clave de AWS KMS administrada por el cliente y se conservan durante diez (10) años. El grupo de exportación de registros del motor Aurora PostgreSQL se conserva durante una (1) semana.

5.2 Qué se registra y qué no. ProcessMind registra los eventos de acceso a la API HTTP y a WebSocket: hora de la solicitud, identificadores de solicitud, ruta o vía de acceso, estado de respuesta y latencia. Los registros de acceso no incluyen la dirección IP de origen ni el agente de usuario de quien realiza la llamada. ProcessMind también registra eventos de autenticación, rutas de fallo asíncronas y la actividad de la aplicación Lambda de soporte en grupos de registros centralizados de CloudWatch. Los registros de flujo de VPC están habilitados. Actualmente, ProcessMind no habilita el registro de acceso estándar de CloudFront en las distribuciones del sitio web, la SPA del frontend ni los recursos públicos.

5.3 Supervisión y alertas. Las alarmas y los Dashboard de CloudWatch supervisan el estado del sistema, las colas de mensajes no entregados y los fallos pertinentes para la seguridad. Los fallos de procesamiento asíncrono se dirigen a colas de mensajes no entregados cifradas (conservación de catorce (14) días; dos (2) días para las colas de miniaturas y de índices de búsqueda), y las alarmas de DLQ activan notificaciones de SNS para su investigación. Además, ProcessMind utiliza Sentry para el seguimiento de errores del frontend en tiempo real, la supervisión del rendimiento y la reproducción de sesiones. Las reproducciones de sesiones solo se graban en las sesiones en las que se produce un error, y el texto, las entradas de formularios y los medios se enmascaran o bloquean en las reproducciones. Los datos de Sentry se incorporan en la UE (Fráncfort) y se limitan a los Datos de uso de ProcessMind (errores del navegador, trazas de rendimiento, metadatos del dispositivo y grabaciones de reproducción enmascaradas). Sentry figura en la lista de subencargados.

5.4 Protección de registros. Los registros se almacenan en grupos de registros de CloudWatch dedicados y con acceso controlado, y se cifran en reposo. Los registros de producción y desarrollo se mantienen separados mediante límites de entorno y de cuenta.

6. Validación automatizada de controles y gestión de vulnerabilidades

6.1 Qué hace ProcessMind. ProcessMind ejecuta cdk-nag como parte de su flujo de trabajo de síntesis y despliegue de infraestructura, utilizando varios conjuntos de reglas del sector (incluidos AWS Solutions, NIST 800-53 y PCI DSS). Se generan informes por pila y se revisan como parte de la gestión de cambios de infraestructura. Los hallazgos se clasifican como corregidos, riesgo aceptado o mejora planificada.

6.2 Gestión de excepciones. Las supresiones se registran en un registro central cuando el marco de trabajo lo permite, se limitan a las pilas afectadas y requieren una justificación por escrito; cuando una pila contiene una supresión insertada, esta se documenta junto a dicha pila. Cuando se corrige un hallazgo, la supresión correspondiente se actualiza o elimina. ProcessMind no considera la supresión una exención general de la revisión.

6.3 Qué no hace actualmente ProcessMind. ProcessMind realiza un seguimiento y revisa las excepciones sustanciales a los controles de infraestructura. Las principales son:

  • Las Lambdas de la aplicación no se ubican dentro de la VPC de forma predeterminada; acceden a Aurora a través de la RDS Data API mediante TLS, con autenticación de IAM y Secrets Manager
  • ninguna parte del servicio está protegida por AWS WAF: AWS WAF no admite las API HTTP de API Gateway, y los demás puntos de entrada tampoco están protegidos por WAF (las conexiones WebSocket utilizan tokens HMAC de corta duración; las restricciones geográficas relacionadas con los pagos se aplican en el sistema de pagos); las distribuciones estáticas tampoco tienen habilitado el registro de acceso estándar de CloudFront
  • la recuperación de la base de datos se basa en las copias de seguridad automatizadas de Aurora y en la recuperación a un momento dado, en lugar de un plan independiente de AWS Backup o de Aurora Enhanced Monitoring
  • no hay replicación de S3 entre regiones ni S3 Object Lock para los buckets modificables
  • algunos recursos auxiliares gestionados por AWS/CDK/SST utilizan cifrado gestionado por AWS o políticas de IAM generadas más amplias cuando el servicio no ofrece una alternativa controlada por el cliente

El registro completo de supresiones se mantiene junto con el código de infraestructura y está disponible previa solicitud. El uso de cdk-nag paquetes de reglas constituye una validación de controles de ingeniería, no una certificación externa, una opinión de auditoría ni una declaración legal de cumplimiento de HIPAA, NIST o PCI DSS.

6.4 Gestión de dependencias. Las dependencias de software se supervisan continuamente para detectar vulnerabilidades conocidas. Las vulnerabilidades críticas y de gravedad alta se corrigen con un plazo objetivo de siete (7) días. Las dependencias se actualizan de forma periódica.

6.5 Ciclo de vida de desarrollo de software seguro (SDLC). ProcessMind aplica un enfoque de defensa en profundidad al desarrollo de software. Todo cambio en producción debe superar varias capas independientes de validación automatizada antes de su implementación:

  • Análisis estático y seguridad de tipos: El modo estricto de TypeScript y ESLint hacen cumplir la corrección de tipos, la seguridad frente a valores nulos y los patrones de programación pertinentes para la seguridad en tiempo de compilación.
  • Revisión de código asistida por IA: El análisis asistido por IA aporta una perspectiva adicional de revisión de las solicitudes de incorporación de cambios para identificar riesgos de seguridad, errores lógicos y desviaciones de las convenciones, como complemento de las pruebas automatizadas.
  • Pruebas unitarias y de integración: un conjunto completo de pruebas de Vitest valida la lógica empresarial, los patrones de acceso a los datos, el comportamiento de la API y la gestión de errores frente a recursos de AWS activos en el entorno de desarrollo.
  • Pruebas de extremo a extremo: las pruebas de navegador basadas en Playwright verifican flujos de trabajo críticos de los usuarios, incluidos la autenticación, la carga de datos, el modelado de procesos, la simulación y el aislamiento multiinquilino.
  • Análisis de cumplimiento de la infraestructura: cdk-nag valida el código de infraestructura frente a varios marcos de cumplimiento con cada cambio.
  • Análisis de vulnerabilidades de dependencias: las auditorías automatizadas de dependencias impiden que vulnerabilidades conocidas críticas y de gravedad alta lleguen a producción.

La revisión humana se centra en la arquitectura, los límites de seguridad y las decisiones de diseño, en lugar de en la inspección del código línea por línea. Cuando se trate de cambios estructurales, sensibles desde el punto de vista de la seguridad o relacionados con la infraestructura, se requiere la aprobación expresa de una persona, además de la validación automatizada.

Todas las capas de validación se aplican mediante CI como requisitos obligatorios para la fusión de cambios de aplicación e infraestructura en la rama principal. El contenido del sitio web y las versiones de los recursos estáticos siguen un proceso de publicación independiente y documentado, con comprobaciones en el momento del despliegue —incluida una comprobación automatizada de que los documentos legales están actualizados— en lugar de la barrera de CI de la aplicación. Las correcciones urgentes en producción pueden omitir la barrera de CI, pero deberán ir seguidas de una ejecución completa de la canalización y de una revisión posterior al incidente en un plazo de veinticuatro (24) horas.

7. Copias de seguridad y recuperación ante desastres

7.1 Copias de seguridad automatizadas. Amazon Aurora realiza copias de seguridad continuas y automatizadas con un período de retención de siete (7) días. Las copias de seguridad se cifran con las mismas claves de KMS gestionadas por el cliente que las bases de datos de origen.

7.2 Recuperación a un momento dado. Aurora admite la recuperación a un momento dado hasta cualquier segundo dentro del período de retención de las copias de seguridad, lo que permite una restauración rápida en caso de corrupción de datos o eliminación accidental.

7.3 Durabilidad y control de versiones de S3. Las cargas de archivos y los artefactos operativos se almacenan en Amazon S3, que ofrece una durabilidad del 99,999999999 % (11 nueves). El control de versiones está habilitado en el bucket de cargas y en los buckets de recursos para facilitar la recuperación y la reversión. Los buckets del sitio web y de implementación del frontend contienen artefactos de compilación reproducibles y no se consideran un sistema de copias de seguridad. Actualmente, ProcessMind no habilita la replicación de S3 entre regiones.

7.4 Continuidad del negocio. Los procedimientos de recuperación ante desastres están documentados y se prueban periódicamente. Puede consultarse un resumen en el documento Recuperación ante desastres, continuidad del negocio y respuesta a incidentes. La arquitectura se basa en servicios gestionados de AWS dentro de la región eu-central-1, que AWS opera en varias zonas de disponibilidad; el clúster de Aurora ejecuta actualmente una única instancia de escritura, por lo que la recuperación de la base de datos se basa en copias de seguridad automatizadas y recuperación a un momento dado, en lugar de una instancia en espera dentro de la región. Las copias de seguridad de Aurora, la durabilidad de S3, las colas de mensajes no entregados y los recursos estáticos que pueden reconstruirse a partir del código fuente forman parte de la estrategia de recuperación.

8. Respuesta a incidentes

8.1 Notificación de incidentes. En caso de un Incidente de Seguridad (según se define en el DPA), ProcessMind notificará a los clientes afectados sin dilación indebida y, cuando sea factible, en un plazo de setenta y dos (72) horas desde que tenga conocimiento del incidente.

8.2 Gestión de incidentes. ProcessMind mantiene procedimientos documentados de respuesta a incidentes que abarcan la identificación, la contención, la erradicación, la recuperación y la revisión posterior al incidente. Puede consultarse un resumen en el documento Recuperación ante desastres, continuidad del negocio y respuesta a incidentes. Las lecciones aprendidas de los incidentes se incorporan a los controles y procesos de seguridad.

8.3 Comunicación. Las notificaciones de incidentes incluyen la naturaleza y el alcance del incidente, las categorías de datos afectadas, las medidas adoptadas para contenerlo y las acciones recomendadas para el cliente.

9. Medidas organizativas

9.1. Gestión de la seguridad de la información. ProcessMind mantiene un sistema de gestión de la seguridad de la información alineado con los principios de ISO 27001. ProcessMind ha seleccionado su vía de certificación para ISO 27001 y la atestación SOC 2 Type II; el proceso formal de certificación aún no ha comenzado.

9.2 Concienciación sobre seguridad. Todo el personal con acceso a los Datos del Cliente recibe formación de concienciación sobre seguridad. Las mejores prácticas de seguridad están integradas en la incorporación, los flujos de trabajo de desarrollo y los procedimientos operativos.

9.3 Gestión de proveedores y subencargados del tratamiento. Los subencargados del tratamiento están obligados contractualmente a cumplir normas de protección de datos equivalentes a las descritas en este documento. ProcessMind mantiene una lista pública de subencargados del tratamiento y avisa con al menos treinta (30) días de antelación antes de contratar a un nuevo subencargado del tratamiento. Los subencargados del tratamiento se revisan anualmente para verificar su cumplimiento.

9.4 Confidencialidad. Todo el personal autorizado a tratar Datos del Cliente está sujeto a obligaciones de confidencialidad por escrito.

10. Cumplimiento y certificaciones

Marco / Norma Estado
RGPD (Reglamento General de Protección de Datos de la UE) Cumple
Residencia de datos en la UE (Fráncfort, Alemania) Aplicada
Certificaciones de infraestructura de AWS (ISO 27001, SOC 2, PCI DSS) Heredadas a través de AWS
ISO 27001 (ProcessMind) Prevista: se ha seleccionado la vía de certificación; el proceso formal aún no ha comenzado
SOC 2 Tipo II (ProcessMind) Prevista: se ha seleccionado la vía de certificación; el proceso formal aún no ha comenzado
Validación automatizada de controles de infraestructura (cdk-nag en AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless) Implementada como validación de controles de ingeniería, no como certificación
Cláusulas contractuales tipo (CCT) para transferencias internacionales Implementadas (véase el DPA)
Anexo sobre tratamiento de datos (DPA) Disponible públicamente

El uso de cdk-nag paquetes de reglas no significa que ProcessMind esté formalmente certificada ni que haya sido auditada de forma independiente con respecto a HIPAA, NIST o PCI DSS. Esos paquetes de reglas se utilizan como salvaguardias de ingeniería para validar el diseño de la infraestructura y hacer un seguimiento explícito de las deficiencias.

Si tiene preguntas sobre seguridad o cumplimiento, o desea solicitar documentación, como informes de auditoría o cuestionarios de seguridad cumplimentados, póngase en contacto con support@processmind.com.