Medidas técnicas y organizativas

1. Alcance y entorno

• Empresa: CreatorFlow Labs S.L., Madrid, España. Un equipo pequeño que trabaja totalmente en remoto. No operamos servidores propios, salas de servidores ni una red corporativa de oficina, y no se almacenan datos personales en las instalaciones de la empresa.
• Alojamiento: Todo el servicio se ejecuta en Amazon Web Services (AWS) en la Unión Europea, en la región eu-west-1 (Irlanda). La aplicación, las bases de datos, las cachés, el almacenamiento de objetos y las copias de seguridad se encuentran todos en esa región.
• Datos tratados: Nombres de usuario de Instagram e identificadores públicos de perfil, el texto de los comentarios y de los mensajes directos que activan las automatizaciones o que resultan de ellas, las direcciones de email recogidas mediante automatizaciones, los eventos de clic en enlaces, y los datos de cuenta y de facturación de los clientes. No está previsto tratar categorías especiales de datos personales en el sentido del artículo 9 del RGPD.
• Responsabilidad compartida: AWS proporciona la seguridad física y ambiental de los centros de datos. CreatorFlow opera todo lo que va desde el sistema operativo hacia arriba. Cada una de las secciones siguientes indica si un control corresponde a AWS o a CreatorFlow.

2. Control de acceso físico (Zutrittskontrolle)

• Instalaciones de la empresa: No aplicable. En las instalaciones de CreatorFlow no hay servidores, equipos de red ni soportes de datos que contengan datos personales. Por eso, no se nos aplican las salas de servidores con cerradura, los armarios o gabinetes de servidores, la gestión de llaves, los registros de visitantes, los sistemas de alarma ni las normas para el personal de limpieza o de mantenimiento.
• Centros de datos (AWS): Control heredado de AWS. Los centros de datos de AWS aplican seguridad perimetral, control de acceso con tarjeta identificativa y biometría, acompañamiento de visitantes, videovigilancia (CCTV) y registro de accesos. Estos controles se auditan conforme a ISO 27001 y SOC 2. Los clientes pueden pedir los informes a través de nosotros u obtenerlos directamente en AWS Artifact.
• Alimentación de emergencia y protección contra incendios: Control heredado de AWS. Los centros de datos cuentan con alimentación eléctrica redundante, sistemas de alimentación ininterrumpida (SAI o UPS) y generadores, y con detección y extinción automáticas de incendios. Estos controles están cubiertos por los mismos informes de auditoría.

3. Control de acceso a los sistemas (Zugangskontrolle)

• Autenticación de los clientes: Los clientes inician sesión con una dirección de email y una contraseña, o mediante el inicio de sesión con Google. El formulario de registro exige contraseñas de al menos 8 caracteres. Actualmente, este mínimo solo se aplica en el navegador, no en el servidor. Las contraseñas se almacenan como hashes con sal, nunca en texto plano. La migración a un algoritmo moderno de hash de contraseñas (bcrypt o argon2) figura como un punto pendiente. Las cuentas nuevas se crean después de una verificación reCAPTCHA. Actualmente no se exige confirmar el email antes del primer uso.
• Sesiones: Las sesiones se almacenan en el servidor y se identifican mediante una cookie firmada con el atributo HttpOnly, limitada a nuestro dominio, que caduca a los 7 días. Esta cookie todavía no tiene el atributo Secure; añadirlo forma parte de nuestra hoja de ruta de seguridad. Cambiar la contraseña cierra la sesión actual y revoca los tokens de «recordarme», pero actualmente no cierra las demás sesiones activas en otros dispositivos. Si un administrador cambia la dirección de email de la cuenta, se invalidan todas las sesiones de ese usuario.
• Bloqueo de cuentas: Todavía no existe un bloqueo automático de la cuenta tras intentos fallidos reiterados de inicio de sesión. Las protecciones adicionales contra el uso abusivo del inicio de sesión forman parte de nuestra hoja de ruta de seguridad. Los enlaces para restablecer la contraseña solo se envían a la dirección de email registrada en la cuenta.
• Acceso a Instagram: Nunca pedimos ni almacenamos contraseñas de Instagram. Las cuentas de Instagram se conectan mediante el flujo OAuth 2.0 oficial de Meta, y los tokens de acceso resultantes se cifran en la capa de aplicación (AES-256) antes de almacenarse.
• Acceso del personal y a la infraestructura: El acceso a la consola de AWS, a los servidores y a las funciones administrativas se limita a personal designado con credenciales individuales. El acceso a los servidores se realiza por SSH con claves individuales. Las funciones administrativas dentro de la aplicación están restringidas a una única cuenta de administrador incluida en una lista de permitidos y están sujetas a límites de frecuencia de solicitudes.

4. Control de acceso a los datos (Zugriffskontrolle)

• Delimitación por cliente (tenant): Cada registro de cliente (automatizaciones, contactos, actividad, analítica) se almacena con el identificador del espacio de trabajo al que pertenece, y la aplicación solo muestra a cada usuario los espacios de trabajo de los que es miembro. Las comprobaciones de pertenencia al espacio de trabajo en el servidor están implantadas en una parte de la API y se están ampliando a todos los endpoints vinculados a un espacio de trabajo. Hasta que esto se complete, no describimos la separación entre clientes como totalmente aplicada en la capa de la API.
• Necesidad de conocer: Solo el personal designado que opera el servicio puede acceder a los datos de producción, y solo para tareas de soporte, gestión de incidentes y mantenimiento.
• Protección de credenciales: Los tokens de acceso de Instagram se cifran en reposo y se excluyen de las lecturas predeterminadas de la base de datos, por lo que no aparecen en las consultas ni en las exportaciones habituales.
• Datos de pago: Stripe gestiona íntegramente los datos de las tarjetas. CreatorFlow nunca recibe ni almacena números de tarjeta completos.

5. Control de la transferencia de datos (Weitergabekontrolle)

• Cifrado en tránsito: Las conexiones entre los usuarios y el servicio, y entre el servicio y Meta, Stripe y nuestros proveedores de email y de registros, se cifran con TLS.
• Subencargados del tratamiento: Los datos personales solo se comunican a los subencargados del tratamiento enumerados en la sección 5 del DPA, en virtud de condiciones de tratamiento de datos. Los datos se alojan y se registran en la Unión Europea. Las transferencias a subencargados fuera de la UE se basan en las Cláusulas contractuales tipo o en el Marco de Privacidad de Datos UE-EE. UU., según se establece en el DPA.
• Exportaciones: Los clientes pueden exportar en un archivo CSV los contactos que han recogido. Una vez exportados, esos datos quedan bajo el control y la responsabilidad del cliente.
• Soportes extraíbles: No aplicable. No se usan soportes de datos extraíbles (memorias USB, discos externos, cintas de copia de seguridad) para datos personales, por lo que no se necesita un inventario de soportes de datos.

6. Registros y control de entrada de datos (Eingabekontrolle)

• Registros de la aplicación: La aplicación genera registros estructurados de cada webhook procesado, cada ejecución de automatización, cada envío de mensaje y cada solicitud a la API. Cada registro lleva un identificador de correlación, para poder seguir un mismo evento de principio a fin.
• Registros de acceso: La capa HTTP anota una línea de registro de acceso por cada solicitud.
• Almacenamiento central y conservación: Todos los registros se envían a una plataforma de registros alojada en la UE (New Relic, región de datos de la UE) y se conservan durante 30 días. Los usuarios de la aplicación no pueden editar los registros.
• Registro de auditoría administrativa: Las acciones que el personal de CreatorFlow realiza en las cuentas de los clientes desde la interfaz de administración, incluidas las eliminaciones de cuentas y los cambios del email de la cuenta, se anotan en un registro de auditoría con el administrador que realiza la acción, la fecha y hora, y el resultado.
• Inicios de sesión fallidos: Actualmente, los intentos fallidos de inicio de sesión de los clientes no se anotan en un registro de seguridad específico. Esto forma parte de nuestra hoja de ruta de seguridad.

7. Control de separación (Trennungskontrolle)

• Separación entre clientes: Los datos de los clientes se separan de forma lógica por identificador de espacio de trabajo en la capa de datos (arquitectura multi-tenant). A través de la aplicación, los clientes no pueden ver datos que pertenecen a otros espacios de trabajo.
• Separación funcional: Los datos de cuenta y de autenticación se guardan en una base de datos distinta de la de los datos de la aplicación (automatizaciones, contactos, analítica).
• Entornos: Las pruebas automatizadas se ejecutan en una base de datos aislada en memoria y nunca acceden a los datos de producción. El desarrollo diario usa bases de datos locales. El personal designado también consulta directamente los datos de producción para tareas de soporte, depuración e investigación de incidentes. Hay un único entorno de producción y no existe un entorno de preproducción (staging) separado. Antes de cada publicación, los cambios se verifican en local y con el conjunto de pruebas automatizadas, y se pueden revertir.
• Separación física: No aplicable más allá del límite de la cuenta de AWS. Todas las cargas de trabajo se ejecutan en una cuenta de AWS dedicada, propiedad de CreatorFlow.

8. Disponibilidad y resiliencia (Verfügbarkeitskontrolle)

• Infraestructura: El servicio se ejecuta en una sola región de AWS (eu-west-1), dentro de un grupo de escalado automático que sustituye automáticamente cualquier servidor de computación que falle. Los datos se guardan en volúmenes de almacenamiento persistente, que se conservan cuando se sustituye el servidor.
• Instantáneas: Antes de los cambios de infraestructura se crean instantáneas (snapshots) de los volúmenes, que se conservan en la misma región de AWS. Las instantáneas que pueden contener datos personales se eliminan por rotación.
• Resiliencia de los webhooks: Meta vuelve a enviar los webhooks de Instagram durante un tiempo después de una caída temporal, y Stripe reintenta los webhooks de facturación durante varios días. Por eso, las interrupciones breves no provocan la pérdida de eventos.
• Supervisión: El estado de la aplicación, el volumen de procesamiento y las tasas de error se supervisan mediante nuestra plataforma de registros. Los despliegues se observan y se comparan con una referencia tomada antes del despliegue.
• Límites: No hay conmutación por error entre varias regiones ni ningún objetivo de tiempo de recuperación o de punto de recuperación asumido formalmente. El servicio no está destinado a casos de uso que requieran una disponibilidad continua garantizada.
• Resiliencia de los centros de datos: Control heredado de AWS (alimentación eléctrica, refrigeración y red redundantes, extinción de incendios); véase la sección 2.

9. Gestión de parches y de cambios

• Proceso de cambios: Los cambios no triviales empiezan con una especificación escrita y un plan de implementación. El código está cubierto por un conjunto de pruebas automatizadas que se ejecuta en bases de datos de prueba aisladas. Cada versión se compila y se somete a una comprobación de tipos antes del despliegue.
• Publicación de versiones: La aplicación se despliega como imágenes de contenedor versionadas. Para revertir una versión, se puede volver a desplegar una imagen anterior. Las funcionalidades de mayor riesgo se publican controladas por indicadores de funcionalidad (feature flags), que se pueden desactivar sin un nuevo despliegue y que se pueden activar primero para una parte de los espacios de trabajo.
• Verificación: Antes de cada despliegue se registran las métricas clave, que después se comparan para detectar pronto cualquier regresión.
• Dependencias y sistema operativo: Las dependencias de terceros y las imágenes base de los contenedores se actualizan mediante el proceso habitual de publicación, y el sistema operativo del servidor se renueva cuando se sustituye el servidor de computación. No hay un calendario fijo de aplicación de parches. Las actualizaciones relevantes para la seguridad se priorizan según su gravedad.
• Registro de hallazgos de seguridad: Los hallazgos de nuestras propias auditorías de seguridad se anotan en un registro interno con una puntuación de gravedad y se corrigen por orden de riesgo.

10. Gestión de incidentes y de brechas de seguridad

• Contacto: Los problemas de seguridad se pueden comunicar a security@creatorflow.so. Acusamos recibo de los avisos y los investigamos. No tenemos un programa de recompensas económicas por vulnerabilidades (bug bounty).
• Gestión: Los incidentes se investigan con los registros centrales, se contienen, se documentan con una cronología y su causa raíz, y se corrigen. Las lecciones aprendidas se incorporan al registro de hallazgos de seguridad.
• Notificación al cliente: Si una brecha de seguridad de los datos personales afecta a los datos de un cliente, se la notificamos a ese cliente sin dilación indebida después de tener conocimiento de ella, con la información descrita en la sección 8 del DPA, para que el cliente pueda cumplir sus propias obligaciones conforme a los artículos 33 y 34 del RGPD.

11. Medidas organizativas

• Confidencialidad: El personal con acceso a datos personales está sujeto a obligaciones de confidencialidad contractuales o legales.
• Ciclo de vida de los accesos: El acceso a la infraestructura y a las funciones administrativas se concede de forma individual y se retira cuando una persona deja la empresa o cambia de función.
• Dispositivos y trabajo en remoto: El equipo trabaja en remoto. Solo se accede a los datos de producción con credenciales individuales y mediante conexiones cifradas (TLS, SSH). Como práctica habitual, estos datos no se almacenan en dispositivos locales. No hay una red corporativa de oficina, por lo que no se usa una VPN. Cada conexión administrativa se autentica y se cifra de forma individual.
• Mesa limpia y registros en papel: No aplicable en el sentido clásico: los datos personales tratados mediante el servicio solo existen en formato electrónico dentro de AWS, y no se guardan registros en papel con datos de clientes.
• Terceros y mantenimiento: El personal externo de mantenimiento, limpieza o soporte no tiene acceso a los sistemas de producción. No se usa el mantenimiento remoto por parte de terceros. Solo el personal de CreatorFlow opera la infraestructura.
• Protección de endpoints en los servidores: Las cargas de trabajo de producción se ejecutan como contenedores Linux con usuarios sin privilegios de root, en un servidor que solo expone HTTPS públicamente. Los equipos de trabajo de los empleados no forman parte de la red de producción.

12. Supresión y conservación

• Eliminación de la cuenta: Previa solicitud, se elimina la cuenta junto con todos sus espacios de trabajo, automatizaciones, contactos, registros de actividad, estados pendientes de automatización y conexiones de Instagram, y se borra el contacto correspondiente de los emails de marketing. Cada eliminación se anota en un registro de auditoría.
• Eliminación de contactos: El cliente puede eliminar contactos concretos (direcciones de email recogidas), lo que permite atender las solicitudes de supresión de los titulares de los datos.
• Caducidad automática: Los registros temporales que se usan mientras una automatización espera una acción del usuario (por ejemplo, que responda con su email o que empiece a seguir la cuenta) dejan de poder usarse en un plazo de 24 a 48 horas, según el tipo de automatización, y se eliminan físicamente de la base de datos en un plazo de 48 horas.
• Registros: Los registros de la aplicación y de acceso se conservan durante 30 días.
• Instantáneas: Véase la sección 8. Las instantáneas solo se restauran para recuperar el servicio tras un fallo del sistema. Los datos personales que se hubieran suprimido antes de una restauración de este tipo tendrían que volver a suprimirse después. No existe una conciliación automática para ello, por lo que volvemos a realizar las supresiones manualmente previa solicitud.

13. Revisión de estas medidas