Resumen de seguridad / Informe técnico de seguridad

Última actualización: 25 de octubre de 2026 (versión 1.0).

Periodicidad de revisión: anual, y ante cualquier cambio sustancial en la arquitectura de la plataforma

1. Introducción

PassportScan Cloud es una plataforma de Software como Servicio (Software-as-a-Service) operada por GlobeID Limited («GlobeID») que permite a los proveedores de alojamiento capturar documentos de identidad de los huéspedes, obtener consentimientos y firmas, y cumplir con las obligaciones legales de registro de huéspedes (policía, autoridades estadísticas y fronterizas), así como la integración con sistemas PMS.

Este documento describe la arquitectura de seguridad y las medidas técnicas y organizativas que protegen la plataforma y los datos personales tratados en ella. Está destinado a clientes, clientes potenciales y auditores, complementa el Acuerdo de Tratamiento de Datos (DPA) y la Lista de Subencargados, y constituye la respuesta de referencia a los cuestionarios de seguridad. Describe la plataforma de producción tal como está desplegada en la fecha de entrada en vigor de este documento.

2. Programa de seguridad y cumplimiento

• GlobeID opera un Sistema de Gestión de Seguridad de la Información (SGSI) alineado con la norma ISO/IEC 27001:2022, con un Director de Seguridad de la Información (Chief Information Security Officer) designado, un registro de riesgos y una Declaración de Aplicabilidad; el SGSI se revisa mediante auditorías internas y revisiones por la dirección planificadas con un ciclo anual.
• RGPD: GlobeID actúa como encargado del tratamiento de los datos de los huéspedes en virtud del DPA y ha designado un Delegado de Protección de Datos externo. Se mantienen registros de las actividades de tratamiento, una EIPD (evaluación de impacto) para los datos de identidad de los huéspedes y un procedimiento para el ejercicio de los derechos de los interesados.
• Los datos de tarjetas de pago son gestionados exclusivamente por Stripe; PassportScan no opera un Entorno de Datos de Titulares de Tarjetas y nunca recibe números de tarjeta, CVV ni fechas de caducidad.
• La supervisión de los controles es continua mediante una plataforma de automatización de cumplimiento conectada a los proveedores de servicios en la nube, de código fuente y de identidad; se encargan periódicamente pruebas de penetración independientes y se realiza el seguimiento de los hallazgos hasta su resolución.

3. Alojamiento y arquitectura

4. Seguridad de la red

• Privado por defecto: todos los servicios se ejecutan en subredes privadas de una VPC dedicada. Solo las interfaces orientadas al cliente, la consola de administración del personal y dos API públicas son accesibles desde Internet, a través de Amazon API Gateway y un Application Load Balancer público. La consola de administración está protegida por AWS WAF y por su propia autenticación, con cuentas de personal asignadas individualmente y autenticación multifactor obligatoria. Todos los microservicios internos, el motor de automatización y el motor de OCR solo son accesibles desde dentro de la VPC o a través de la VPN corporativa.
• Cortafuegos de aplicaciones web: el perímetro público (las etapas de API Gateway y el balanceador de carga público) está protegido por AWS WAF. Los grupos de reglas gestionados por AWS Amazon IP Reputation List y Known Bad Inputs bloquean orígenes y cargas maliciosas, el Core Rule Set de AWS (alineado con OWASP) se evalúa en cada solicitud, y la limitación de velocidad bloquea los orígenes abusivos, con límites más estrictos en los puntos de acceso de autenticación.
• Cifrado en tránsito: los puntos de acceso públicos aceptan únicamente TLS 1.2 y TLS 1.3 (política de seguridad de API Gateway TLS_1_2; política del balanceador de carga ELBSecurityPolicy-TLS13-1-2-2021-06 con conjuntos de cifrado modernos ECDHE-GCM). El tráfico HTTP se redirige a HTTPS y se aplica HTTP Strict Transport Security (HSTS) en el balanceador de carga público. Los certificados se emiten y renuevan automáticamente mediante AWS Certificate Manager.
• Acceso administrativo: los ingenieros acceden a los servicios internos únicamente a través de una VPN de confianza cero vinculada a su identidad individual; no hay SSH ni RDP expuestos a Internet, ni servidor de salto (bastion host).
• Registro de red: los VPC Flow Logs (todo el tráfico) y los registros de acceso al servidor de S3 se conservan durante 90 días.

5. Seguridad de los datos

5.1 Cifrado

5.2 Ubicación y residencia de los datos

• Los servicios principales de la plataforma y las bases de datos primarias se alojan exclusivamente en AWS eu-west-1 (Irlanda); no se ha configurado ninguna replicación de bases de datos entre regiones.
• Cuando un cliente habilita el almacenamiento de imágenes de documentos, las imágenes se almacenan en la región de S3 correspondiente a la jurisdicción del establecimiento. Regiones aprovisionadas: eu-west-1 (Europa), us-east-1 (América del Norte), sa-east-1 (América del Sur), ap-southeast-1 (Asia-Pacífico) y ap-southeast-2 (Australia). Cada bucket regional aplica la misma configuración de cifrado, control de versiones y registro de accesos.
• Las transferencias fuera del EEE están cubiertas por el Anexo de Tratamiento de Datos de AWS y las Cláusulas Contractuales Tipo, tal y como se describe en el DPA.

5.3 Secretos y claves

• Los secretos de la aplicación, las claves de API y las claves de cifrado se almacenan en AWS Systems Manager Parameter Store (SecureString) y se inyectan en los contenedores en el arranque; nunca se incluyen en el código fuente ni se incorporan a las imágenes.
• Las credenciales de las bases de datos son generadas y rotadas por AWS (secretos gestionados por RDS en AWS Secrets Manager) o se almacenan como SecureStrings en AWS Systems Manager Parameter Store y se inyectan en los contenedores como secretos en el arranque.
• Los cambios de secretos en producción se realizan a través de un flujo de trabajo de operaciones auditado, no manualmente desde la consola. Las contraseñas de las bases de datos de la aplicación se rotan de forma programada mediante nuestra plataforma interna de operaciones, sin tiempo de inactividad.

5.4 Copias de seguridad y conservación

• Aurora MySQL: copias de seguridad diarias automatizadas con una conservación de 15 días y recuperación continua a un punto en el tiempo; protección contra eliminación habilitada; se realiza una instantánea final antes de cualquier eliminación del clúster.
• Almacenamiento de objetos: control de versiones con conservación de las versiones anteriores durante 90 días, lo que protege contra la eliminación o sobrescritura accidentales.
• Al finalizar el contrato, los datos del cliente se devuelven al cliente y/o se eliminan a petición de este, en un plazo de 30 días desde la solicitud, según lo establecido en el DPA; las copias de seguridad expiran posteriormente conforme al ciclo de conservación indicado anteriormente.

6. Gestión de identidades y accesos

• Usuarios de los clientes: se autentican a través del proveedor de identidad de la plataforma (Clerk) con verificación de correo electrónico, gestión de sesiones y autenticación multifactor opcional; el acceso dentro de la cuenta de un cliente se basa en roles.
• Personal de GlobeID: el acceso al código fuente, a la CI/CD y a la consola de gestión interna se realiza a través de la organización de GitHub con autenticación de dos factores obligatoria. Ningún ingeniero dispone de acceso permanente a la cuenta de producción de AWS, y ninguna credencial en poder de una persona puede asumir un rol en dicha cuenta: la producción se modifica y opera exclusivamente a través de nuestra plataforma interna de operaciones y de flujos de trabajo de operaciones auditados, sin que exista vía de consola ni de línea de comandos para los ingenieros. Los desarrolladores tienen acceso con privilegios mínimos únicamente a las cuentas de desarrollo y de preproducción (staging). La monitorización y las operaciones utilizan roles dedicados con privilegios mínimos; las acciones operativas limitadas disponibles en nuestra plataforma de operaciones (por ejemplo, reinicio progresivo, modo de mantenimiento, rotación programada de credenciales, tareas puntuales de datos aprobadas e instantáneas de bases de datos) están acotadas a recursos designados, condicionadas por rol y, en el caso de operaciones sobre datos de producción, por un segundo administrador, y son auditadas. Un procedimiento documentado de emergencia (break-glass) está restringido a propietarios designados de la organización, se ejecuta únicamente a través de nuestro sistema de CI/CD y queda registrado y revisado cada vez que se utiliza.
• Acceso a bases de datos de producción: no se concede de forma permanente a los ingenieros: se solicita en el momento preciso (just-in-time) a través de nuestra plataforma interna de operaciones indicando un motivo, es aprobado por un segundo administrador (nunca el solicitante), se aprovisiona como un usuario de base de datos acotado a una sola base de datos y un solo nivel de acceso, nunca con permisos de modificación de esquema, con limitación temporal (en producción, un máximo de 4 horas para acceso de lectura y 1 hora para acceso de escritura) y se elimina automáticamente a su vencimiento; las credenciales se muestran únicamente al solicitante. Toda solicitud, aprobación y revocación queda registrada. Está prohibida la exportación de datos de producción a estaciones de trabajo.
• Los datos de producción permanecen en producción: los entornos de desarrollo y preproducción utilizan únicamente datos sintéticos o anonimizados. Las instantáneas de bases de datos se restauran únicamente en una nueva base de datos dentro del mismo entorno del que se tomaron, de modo que los datos de producción nunca se restauran en entornos de desarrollo o de pruebas; una restauración en producción requiere la indicación de un motivo y la aprobación de un segundo administrador. Las correcciones de datos de producción se realizan únicamente mediante tareas previamente declaradas y sometidas a revisión de código, probadas primero en preproducción y aprobadas por un segundo administrador — nunca mediante SQL ad hoc.
• Registro de auditoría de la actividad de los operadores: todas las operaciones privilegiadas realizadas a través de la plataforma de operaciones, incluido el acceso al contenido de los registros (logs) de producción — solicitudes y aprobaciones de acceso, promociones y reversiones de versiones, cambios del estado de encendido de los entornos, cambios de configuración, aprobaciones de documentos y firmas electrónicas — quedan registradas con la identidad del operador (SSO de GitHub, 2FA obligatoria), la marca de tiempo y el resultado, y están disponibles como evidencia para los auditores.
• De la CI/CD a AWS: la autenticación se realiza mediante federación OpenID Connect de GitHub con un rol de despliegue dedicado por entorno, restringido a los repositorios designados de la plataforma.
• Los procedimientos de incorporación, cambio de puesto y baja (joiner/mover/leaver), la verificación de antecedentes y los compromisos de confidencialidad forman parte del procedimiento de seguridad de RR. HH.; las revisiones de accesos se realizan de forma periódica.

7. Desarrollo seguro y gestión de cambios

• Todo cambio llega a producción a través de Git: pull request, revisión de código independiente (aprobación por una persona distinta del autor), comprobaciones automatizadas y un flujo de promoción con una rama por entorno (desarrollo → preproducción → producción). Cada promoción a preproducción y a producción es solicitada por un administrador y aprobada por un administrador distinto a través de la plataforma de operaciones, con un reconocimiento explícito de cualquier migración de base de datos que conlleve; la promoción a producción requiere además una validación (sign-off) de control de calidad (QA) sobre la versión de preproducción. Cada conjunto de cambios es trazable desde el ticket hasta la versión desplegada, y los despliegues en producción realizados fuera de la plataforma de operaciones son rechazados, salvo en el marco del procedimiento de emergencia (break-glass).
• Las imágenes de contenedor se construyen una sola vez y se analizan en busca de vulnerabilidades conocidas en el momento de su envío (push) al registro; las etiquetas del registro de producción son inmutables (una etiqueta publicada nunca puede ser sustituida de forma silenciosa) y producción extrae exactamente el digest de imagen validado en preproducción — nada se reconstruye para producción.
• Los cambios de infraestructura siguen el mismo proceso (plan de Terraform en la pull request, aplicación al fusionar), lo que proporciona un registro de auditoría completo y revisable de los cambios en producción.
• Las versiones pueden revertirse por componente; la versión desplegada de cada componente se registra antes de cada promoción.

8. Registro, supervisión y respuesta a incidentes

• Registros centralizados: los registros de aplicación y de acceso de todos los servicios se envían a Datadog (sitio de la UE, datadoghq.eu) y a Amazon CloudWatch; los registros de aplicación se conservan hasta 90 días. Los datos personales y los secretos se enmascaran en los servicios antes de que los registros se envíen a Datadog, y de nuevo en el momento de su visualización: a través de nuestra plataforma de operaciones, el personal distinto de los administradores ve el contenido de los registros de producción con los valores personales enmascarados en su lugar, y las herramientas automatizadas y de IA no reciben los contenidos de las solicitudes ni de las respuestas, mientras que la información necesaria para el diagnóstico (mensajes de error, identificadores de solicitud, códigos de estado) permanece visible. Todo acceso al contenido de los registros de producción queda auditado.
• Auditoría en la nube y detección de amenazas: AWS CloudTrail registra todas las llamadas a las API de gestión realizadas en la cuenta de producción, en todas las regiones, con validación de la integridad de los archivos de registro y almacenamiento con control de versiones; Amazon GuardDuty analiza de forma continua la actividad de CloudTrail, de VPC Flow Logs y de DNS en todas las regiones en las que operamos para detectar amenazas como el uso indebido de credenciales, el reconocimiento y la comunicación con hosts maliciosos conocidos; los hallazgos son revisados por el equipo de operaciones.
• Alertas: las alarmas de CloudWatch sobre bases de datos, cachés, balanceadores de carga, API Gateway y eventos del ciclo de vida de las tareas de ECS notifican al equipo de operaciones a través de SNS; el rendimiento de las aplicaciones se supervisa en Datadog; el estado de la infraestructura, las colas, los costes y los avisos de obsolescencia por entorno se consolidan en la consola de supervisión de la plataforma de operaciones.
• Página pública de estado: la disponibilidad de la plataforma se supervisa de forma externa y se publica en https://status.passportscan.net, con comunicación automática de incidentes y mantenimientos.
• Respuesta a incidentes: un Procedimiento de Respuesta a Incidentes y Violaciones de Datos documentado define los niveles de gravedad, las funciones y el escalado. Las violaciones de la seguridad de los datos personales se notifican a los clientes afectados sin dilación indebida y, en cualquier caso, en un plazo de 48 horas, según lo establecido en el DPA, y a la autoridad de control en un plazo de 72 horas cuando sea exigible (art. 33 del RGPD).
• Divulgación de vulnerabilidades: los investigadores de seguridad pueden notificar problemas conforme a la Política de Divulgación de Vulnerabilidades (security@passportscan.net).

9. Continuidad del negocio y recuperación ante desastres

• La producción se ejecuta en servicios gestionados de AWS distribuidos en tres zonas de disponibilidad en eu-west-1: el almacenamiento de Aurora se replica seis veces en las tres zonas, los servicios principales ejecutan al menos dos tareas repartidas entre zonas con escalado automático en función de la carga, y ECS sustituye automáticamente una tarea fallida en una zona en buen estado detrás de los balanceadores de carga. Las implementaciones utilizan un circuit breaker (disyuntor) que revierte automáticamente cuando una nueva versión no supera sus comprobaciones de estado.
• Las bases de datos pueden restaurarse a cualquier momento dentro del período de retención de 15 días; el procedimiento de restauración forma parte del ejercicio anual de recuperación ante desastres.
• Un Análisis de Impacto en el Negocio y un Plan de Continuidad del Negocio y Recuperación ante Desastres definen los objetivos de recuperación de la plataforma (objetivo de tiempo de recuperación inferior a dos horas para el servicio principal de check-in; objetivo de punto de recuperación del orden de minutos gracias a la recuperación a un momento dado).
• Las dependencias de terceros (proveedor de nube, proveedor de identidad, proveedor de pagos, gestión de registros, protección contra bots y servicios de comunicación empresarial) se evalúan en el proceso de seguridad de proveedores y figuran en la Lista de Subencargados.

10. Subencargados

Los terceros que tratan datos personales de los clientes por cuenta de GlobeID figuran, junto con su finalidad y la ubicación del tratamiento, en la Lista pública de Subencargados disponible en https://www.passportscan.net/sub-processor/. Las incorporaciones se notifican a los clientes de conformidad con el DPA.

11. Responsabilidad compartida

GlobeID es responsable de la seguridad de la plataforma según lo descrito anteriormente. Los clientes siguen siendo responsables de: gestionar sus usuarios y credenciales (incluida la activación de la MFA), proteger los dispositivos y las redes utilizados para acceder a la plataforma, configurar de forma lícita las opciones de retención y de almacenamiento regional, facilitar avisos de privacidad a los huéspedes, así como de la seguridad de cualquier PMS o sistema de terceros que conecten.

12. Contacto

Consultas y cuestionarios de seguridad: security@passportscan.net Privacidad y DPO: privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublín 7, D07 P4AX, Irlanda (CRO 559612)