Documentación de la plataforma

Mews es una plataforma SaaS nativa en la nube, sin servidor y multiinquilino. Esto tiene muchas implicaciones en todos los aspectos del funcionamiento de Mews y en el cumplimiento de diversos requisitos. Es importante que veas Mews a través del prisma de esta filosofía mientras lees otras secciones de esta documentación, porque puede ser diferente de los sistemas más tradicionales, y algunos requisitos o preguntas no son aplicables cuando se considera la plataforma Mews.

Nativo en la nube

Desde el primer día, Mews se creó para la nube. La arquitectura del sistema se diseñó para su despliegue en la nube y aprovecha todas las ventajas que ello conlleva. Mews no es un sistema diseñado para funcionar en las instalaciones y posteriormente portado o ajustado para su implementación en la nube, lo que significa que algunos procesos o procedimientos funcionan de forma diferente o no se producen en absoluto.

Sin servidor

Hay múltiples formas de operar en un entorno de nube. En un extremo del espectro, podrías utilizar sólo los servicios en la nube de bajo nivel, como las máquinas virtuales, y manejar todo lo demás por tu cuenta. La ventaja de esto es que todos los proveedores de nubes ofrecen esa funcionalidad primitiva y, por tanto, es bastante sencillo cambiarlos, aunque necesitas tener conocimientos sobre cómo configurar los servidores, las bases de datos, etc. y mantenerlos continuamente por tu cuenta. En el otro extremo del espectro, podrías ir más allá de la funcionalidad de bajo nivel y utilizar la nube como un servicio, por ejemplo, servicios informáticos o de almacenamiento. De este modo, el proveedor de la nube se encarga de la configuración y el mantenimiento; la desventaja es que quedas más atado a tu proveedor de la nube concreto. Somos un socio orgulloso de Microsoft y utilizamos Microsoft Azure en todo su potencial. Por lo tanto, estamos en el lado sin servidor del espectro. Utilizamos servicios como Azure App Service para alojar aplicaciones web, y Azure SQL Database y Azure Storage como servicios de almacenamiento. Por lo tanto, no operamos ninguna máquina virtual, servidor web o servidor de base de datos por nuestra cuenta: eso es responsabilidad de nuestro proveedor de la nube, incluido el cumplimiento y la seguridad de tales servicios. Estos servicios tienen sus propios SLA definidos por Azure. Construimos nuestra solución sobre ella de forma que combina sus servicios y SLA junto con nuestro sistema, para garantizar nuestros SLA. Utilizamos la misma técnica para garantizar nuestro cumplimiento, seguridad, recuperación ante desastres y otros aspectos que se cubren con más detalle en otras secciones.

Multiinquilino

Existe una única "instalación" de producción de la plataforma Mews que utilizan todos nuestros clientes. Eso significa que nuestros clientes siempre están ejecutando la última versión de la plataforma, con las mismas características y funcionalidad disponibles para cualquier otra persona en la plataforma (dependiendo del nivel de suscripción). Desde el punto de vista de los datos, éstos no se segregan, sino que se comparten. Desde el punto de vista de la seguridad, en realidad es muy similar a un sistema de inquilino único. En ese caso, tendríamos que asegurarnos de que los usuarios con distintos niveles de privilegio sólo pueden acceder a los datos a los que se les ha concedido acceso. En los sistemas multiinquilino, el inquilino puede entenderse como otra "capa" de privilegios. Disponer de una solución multiinquilino nos permite implementar eficazmente escenarios por encima de la empresa o de la cadena y ofrecer una gran experiencia del huésped, especialmente en el portal del huésped.

SaaS

Lo único que necesitas para utilizar la plataforma Mews es Internet y un navegador web. De todo lo demás, nos encargamos nosotros. Nos ocupamos de todos los aspectos que se cubren en esta documentación, y nos esforzamos por hacerlo lo mejor posible mientras mejoramos continuamente. Es nuestra responsabilidad garantizar que el sistema sea rápido, esté siempre disponible, tenga copias de seguridad, sea seguro, cumpla todas las legislaciones, esté siempre actualizado, sea accesible para todo el mundo y utilizable por una amplia gama de usuarios. Los clientes sólo son responsables de mantener registros externos si así lo exige la ley. En Francia, los clientes tienen la obligación de conservar los registros fiscales en un soporte físico externo seguro durante el periodo legalmente exigido.

Utilizamos Microsoft Azure como proveedor de la nube. Algunos de los servicios en nube son globales, con georreplicación y alta disponibilidad incorporadas por Azure; otros servicios están vinculados a una sola región.

Utilizamos varias regiones de Microsoft:

Regiones de la UE:

• Europa Occidental (Países Bajos).
• Norte de Europa (Irlanda).
• Alemania Centro Oeste (Frankfurt).
• Suecia Central (Gävle).

Regiones de EEUU:

• US Oeste 3 (Arizona)
• Este de EEUU (Virginia)
• US Este 2 (Virginia)
• US Centro Sur (Texas)

Nuestra base de datos principal es un clúster de alta disponibilidad en Alemania Centro-Oeste, con réplicas en el norte de Europa.

Stack tecnológico

Utilizamos muchos lenguajes de programación, marcos de trabajo y tecnologías. Principalmente:

• C# y .NET en el backend
• JavaScript/TypeScript y React en el frontend
• Flutter y Kotlin en aplicaciones móviles

Entornos

La plataforma Mews se ejecuta en múltiples instancias llamadas entornos; algunos son públicos y otros privados:

• Entorno de producción
• Entorno de pruebas
• Entorno de desarrollo
• Entornos de rama de características

Como sistema nativo en la nube, nuestra estrategia de recuperación ante desastres gira en torno a las copias de seguridad de los datos y la capacidad de restaurarlos en caso de incidente. Todos los demás servicios son "sin estado", lo que significa que, en caso de catástrofe, podemos restablecerlos sin pérdida de información. Dependemos en gran medida de las características que ofrece Microsoft Azure en este ámbito, y además tenemos nuestros propios niveles de copias de seguridad construidos sobre las características estándar de Azure.

Base de datos Azure SQL

Utilizamos la capa premium de la base de datos Azure SQL con una réplica en la región geográfica secundaria. Esta configuración ya dispone de varias capas y mecanismos de copia de seguridad de fábrica, descritos con todo detalle en la documentación de la base de datos Azure SQL. Además, tenemos nuestros propios procesos de copia de seguridad. Todas las opciones, tanto las incorporadas como las nuestras, se describen a continuación:

• Dentro de un centro de datos, el servicio de base de datos se ejecuta como un clúster de alta disponibilidad de dos réplicas idénticas de la base de datos con latencia de datos casi en tiempo real (pocos milisegundos). En caso de desastre en la base de datos principal, el servicio recurre inmediatamente a la base de datos secundaria. Alternativamente, podemos activar este retroceso manualmente.
• El servicio de base de datos ofrece restauración puntual, que nos permite restaurar una base de datos completa a un momento determinado hasta 35 días atrás.
• El clúster de base de datos de la región primaria se georreplica en el clúster secundario de alta disponibilidad de la región secundaria. En caso de desastre en la región primaria, podemos realizar una conmutación por error a la región secundaria y ascender la réplica secundaria a maestra. Podemos hacerlo de forma rápida y fiable utilizando grupos de recuperación automática.
• Realizamos instantáneas diarias de la base de datos principal utilizando la función de restauración puntual en otro servidor de copia de seguridad. El servidor de copia de seguridad mantiene dos copias totalmente restauradas, con una antigüedad máxima de 24 y 48 horas, listas para su uso inmediato en caso de desastre que afecte tanto a la base de datos primaria como a la secundaria. Alternativamente, estas instantáneas pueden utilizarse en caso de corrupción parcial de los datos para restaurarlos inmediatamente.

Almacenamiento Azure

Como almacén de datos binarios, utilizamos Azure Storage configurado para utilizar capacidades de almacenamiento georredundante. Los datos se replican automáticamente tres veces en la región primaria y tres veces en la región secundaria. La cuenta de almacenamiento también utiliza una característica de borrado suave que evita problemas específicos de la aplicación y nos permite recuperar datos potencialmente corruptos. De forma similar a la base de datos SQL, realizamos copias de seguridad incrementales diarias de todos los datos del almacenamiento en un almacenamiento de seguridad que está listo para su uso inmediato en caso de desastre que afecte al almacenamiento primario.

Cosmos DB

Tenemos configurada la base de datos Cosmos para que se replique en varias regiones. Cosmos DB replica de forma transparente los datos en todas las regiones vinculadas a nuestra cuenta, y admite la conmutación por error automática en caso de interrupción regional. Actualmente, sólo almacenamos datos no críticos para la empresa en Cosmos DB (por ejemplo, registros) y, por lo tanto, no tenemos ninguna capa adicional de copias de seguridad construida sobre las características ofrecidas del servicio.

Nuestra filosofía en lo que respecta a las implementaciones es desplegarlas con la mayor frecuencia posible y cuanto menor sea el conjunto de cambios desplegados, mejor. La razón principal es que esto nos ayuda a entregar las características y correcciones terminadas a nuestros clientes lo antes posible para que puedan beneficiarse de ellas inmediatamente. La razón secundaria es minimizar los problemas durante las implementaciones y simplificar la investigación y la reversión en caso de problemas. Todas nuestras implementaciones no suponen tiempo de inactividad para el usuario final.

Calendarios de implementación

Nuestra plataforma no es una única aplicación que desplegaríamos en bloque, sino un conjunto de sistemas y aplicaciones que funcionan y se comunican entre sí y que tienen sus propios calendarios de implementación. Hay tres categorías principales de aplicaciones con sus respectivos calendarios de implementación:

• La plataforma backend (servidor) se despliega al menos una vez cada día de la semana. Además, si es necesario, se pueden realizar implementaciones ad hoc para diversos fines, por ejemplo, correcciones en caliente. El escenario estándar es que todos los cambios (características, corrección de errores, mejoras) se desplieguen continuamente en el entorno de desarrollo. Una vez al día, tomamos automáticamente una instantánea de la versión del entorno de desarrollo y la desplegamos en el entorno de pruebas (esto se llama congelación de características). Al día siguiente, si no hubo problemas en el sitio de pruebas, esa versión se despliega en el entorno de producción. Todas las implementaciones se realizan gradualmente en todas las instancias y regiones. Durante el proceso, supervisamos el sistema y, en caso de que surja algún problema, podemos revertir el proceso.
• Las aplicaciones web (por ejemplo, Commander, Distributor o Navigator) se despliegan de forma independiente cada vez que se finaliza un cambio en la aplicación. Esto significa que cuando se implementa una característica o se corrige un error y se supera el control de calidad, se despliega inmediatamente tanto en demostración como en producción. Se trata de una verdadera entrega continua, lo que significa que puede haber 50 o 0 implementaciones en un día, dependiendo de cuántos cambios se finalicen ese día. De nuevo, controlamos la salud de las aplicaciones y podemos revertir cualquier proceso si es necesario.
• Las aplicaciones móviles se despliegan de forma irregular, debido a los procesos de verificación en las tiendas de aplicaciones. De vez en cuando, cuando determinamos que el conjunto de cambios terminados en la versión de desarrollo de la aplicación es razonablemente grande, o cuando es necesario por otras razones, publicamos una nueva versión de la aplicación. A continuación, se publica en la tienda de aplicaciones correspondiente, donde se somete al proceso de verificación. Después de algún tiempo (horas o días), la nueva versión llega a los dispositivos de los usuarios finales.

Nos reservamos la opción de programar el tiempo de inactividad necesario para realizar cambios en el sistema, aunque nuestro objetivo es no utilizar nunca esta opción. Hasta ahora, sólo hemos tenido que utilizarlo una vez en 2013, cuando migrábamos nuestro proveedor de nube de AppHarbor a Microsoft Azure. Desde entonces, no hemos tenido ningún tiempo de inactividad programado.

Proceso de liberación

Es importante distinguir entre desplegar y liberar. La implementación es el momento en que el cambio llega a la producción. Sin embargo, el cambio no tiene por qué estar necesariamente disponible para todos los clientes. El momento en que el cambio está disponible para un cliente se llama liberación. Los cambios más pequeños, las correcciones de errores, las mejoras u otras cosas no críticas se publican para todos nuestros clientes en cuanto se despliegan. Sin embargo, para cambios mayores o más críticos, nos ceñimos al siguiente proceso de liberación de 4 pasos:

1. 1. Alfa interno: El cambio se publica sólo para los empleados de Mews. También utilizamos internamente Mews , por lo que somos los "canarios" que prueban el cambio.
2. 2. Beta privada: El cambio se lanza a un subconjunto seleccionado de clientes que forman grupos de primeros usuarios. Si el cambio es especialmente importante para alguien que participó en el proceso de descubrimiento y entrega del producto, también se le podría incluir en la beta privada. Para este paso y también para el alfa interno, utilizamos LaunchDarkly para gestionar el conjunto de clientes impactados.
3. 3. Beta pública: El cambio se libera para cualquiera que se acoja al cambio. Normalmente, introducimos una opción en ajustes que permite a cualquiera optar por el cambio.
4. 4. Disponibilidad general: El cambio se libera para todos nuestros clientes.

Para todo tipo de problemas, incluidos incidentes, incidentes de seguridad, errores, investigaciones o alertas de supervisión, seguimos un estricto proceso de resolución. El proceso está documentado en nuestra base de conocimientos interna. Cada incidencia, independientemente de su gravedad, tiene un equipo asignado y se comunica inmediatamente al equipo mediante un canal interno de Slack.

Para los problemas con un impacto significativo en el cliente, existe un proceso de distribución adicional para garantizar que se abordan con urgencia. Estos incidentes se comunican en un canal de incidentes de toda la empresa y se comparten actualizaciones periódicas con las partes interesadas internas y externas.

Tras la resolución, el equipo realiza un análisis de la causa raíz, diseña soluciones y publica el documento postmortem. Las soluciones derivadas del postmortem se implementan en un periodo definido por nuestro SLO interno.

La plataforma Mews trabaja con datos de clientes muy sensibles, por lo que la seguridad y la privacidad de datos son elementos innegociables del sistema. Nuestro planteamiento general en este ámbito es que nada debe depender de las personas ni de sus conocimientos. Todas nuestras medidas de seguridad y procesos internos están diseñados en ese sentido; por ejemplo, aunque nuestros desarrolladores reciben regularmente formación sobre las mejores prácticas de codificación segura, no confiamos únicamente en ello para la seguridad. Nuestros procesos y marcos de trabajo están diseñados para prohibir la creación de errores de seguridad o, como mínimo, para dificultar enormemente que un desarrollador introduzca problemas de seguridad en nuestro sistema si no es técnicamente posible prohibirlo por completo. Esto se refleja en nuestro proceso de resolución de problemas de seguridad, que se describe más adelante. Nuestra estrategia de seguridad se rige por dos principios fundamentales:

1. 1. Minimizar la superficie de ataque, reduciendo su alcance y complejidad.
2. 2. Pruebas de penetración continuas de la superficie de ataque, con resolución exhaustiva y minuciosa de cualquier hallazgo.

Además de estas medidas proactivas, muy a menudo nos sometemos a auditorías, certificaciones, procesos de diligencia debida y pen tests por parte de empresas de terceros, ya sean designadas por nosotros (por ejemplo, PCI-DSS, ISO) o por nuestros clientes potenciales.

Minimizar la superficie de ataque

La mejor forma de evitar cualquier problema de seguridad es eliminar por completo la posibilidad de que se produzcan en primer lugar. Esto concuerda con nuestra filosofía "sin servidor": no controlamos el hardware, los sistemas operativos, los servidores web ni los servidores de bases de datos. No podemos desconfigurar ninguno de estos sistemas, ni olvidarnos de aplicar parches de seguridad, etc. - Esto es responsabilidad de Azure, que cuenta con grandes equipos de seguridad. Utilizamos una configuración muy limitada de los servicios Azure, para los que hay opciones de activar algunas características de seguridad adicionales. Para asegurarnos de que no se nos pasa ninguna, utilizamos Azure Security Advisor, que nos notifica todas esas opciones, por ejemplo cuando Azure introduce alguna característica nueva que podría reforzar la seguridad de nuestros sistemas. Gracias a todo lo anterior, nuestra superficie de ataque (desde la perspectiva del sistema) se reduce efectivamente al código de la aplicación que desarrollamos. Para obtener más información sobre las capacidades de seguridad de Azure, consulta la documentación sobre fundamentos de seguridad de Azure.

Pruebas de penetración continuas

Como ya hemos demostrado, nos centramos principalmente en la seguridad a nivel de aplicación. Para garantizar la seguridad de nuestro sistema, nos sometemos continuamente a pruebas de penetración realizadas por cobalt.io. En un momento dado, una parte de nuestro sistema o de un producto se somete a pruebas de pluma y nos aseguramos de que toda la superficie esté cubierta de pruebas de forma continua.

Existen múltiples enfoques sobre cómo abordar las vulnerabilidades de seguridad. Estamos orgullosos de nuestro enfoque y abordamos cada problema de seguridad de forma post mortem, lo que significa que realizamos un análisis detallado de la causa raíz y luego resolvemos no sólo la instancia individual, sino todas las instancias similares en todos nuestros productos. Además, tomamos medidas para evitar que estos problemas se repitan en el futuro. Por ejemplo, si se detecta un problema en una de nuestras API, actualizamos nuestro marco API de forma que elimine el problema de todas nuestras API. O implementamos un analizador de código estático que puede comprobar el problema en nuestra base de código automáticamente, así como en el código nuevo que producimos. Así, aunque se pruebe un solo producto a la vez, aplicamos nuestras conclusiones a todos ellos. Para más información, consulta la sección Incidencias.

Medidas técnicas de seguridad

Desde el punto de vista técnico, hacemos muchas cosas para garantizar la seguridad no sólo de la propia plataforma, sino también de nuestros clientes. Aquí tienes algunas de ellas:

• Los datos se cifran en tránsito, aplicamos al menos TLS 1.2 y obtenemosla tarifa A+en la prueba de Qualys SSL Labs.
• Los datos de todos los tipos de almacenamiento que utilizamos están encriptados en reposo.
• Utilizamos varios niveles de registros internos del sistema y proporcionamos registros de auditoría a nuestros clientes dentro de la plataforma.
• Realizamos escaneos ASV periódicos, escaneos de vulnerabilidades internas y externas.
• Todos nuestros dispositivos están protegidos por software antivirus/antimalware y se gestionan de forma centralizada mediante soluciones MDM.
• Aplicamos una política de contraseñas seguras, utilizamos 1Password y aplicamos la MFA en todos los sistemas internos que ofrecen esta funcionalidad.
• Utilizamos Azure Active Directory y SSO para todos los sistemas internos que ofrecen esta funcionalidad.
• Seguimos el principio del menor privilegio para todos nuestros sistemas internos.
• Nuestra plataforma admite MFA e impone contraseñas seguras a nuestros usuarios.
• Las contraseñas de los usuarios se cifran mediante bcrypt y nunca se almacenan en texto plano.
• Todas las llaves y tokens sensibles de usuario que deban utilizarse para la autenticación de terceros (como las contraseñas FTP) se encriptan en Azure SQL Database.
• Todas las llaves y tokens sensibles de Mews se cifran en la configuración.

Medidas de seguridad para las personas

• Realizamos comprobaciones de los antecedentes de todos los candidatos en roles delicados que vamos a contratar. El alcance y la minuciosidad de estos controles dependen del rol y la antigüedad del candidato.
• Los contratos con todos nuestros empleados contienen cláusulas de confidencialidad y los empleados están obligados a seguir las normas internas sobre tratamiento de datos personales.
• Todos los empleados pasan por la orientación para nuevos empleados, que incluye formación obligatoria sobre seguridad y privacidad de datos.
• Todos los empleados utilizan 1Password y generan su contraseña maestra utilizando diceware.
• Todos los miembros del departamento técnico (desarrolladores, analistas de datos, control de calidad, TI) reciben formación obligatoria sobre seguridad al menos una vez al año.

Datos de la tarjeta de pago

Un gran ejemplo de reducción de la superficie de ataque es cómo manejamos los datos sensibles de las tarjetas de pago. Mews utiliza PCI Proxy como proveedor de tokenización de tarjetas. Los datos sensibles de la tarjeta, como el número o el CVV, nunca llegan a nuestra infraestructura. Como ejemplo, consideremos un flujo sencillo de recepción de los datos de la tarjeta de terceros (por ejemplo, el canal de reservas) y, a continuación, el cargo en esa tarjeta:

1. 1. Cuando terceros necesitan enviarnos los datos de la tarjeta, no nos envían la solicitud directamente, como sería lo habitual, sino que la envían a PCI Proxy.
2. 2. PCI Proxy recibe la solicitud, detecta los datos de la tarjeta, los almacena y los sustituye por tokens que ya no son sensibles. Esta parte se llama tokenización.
3. 3. PCI Proxy nos reenvía la solicitud, que ahora contiene tokens.
4. 4. Almacenamos el token en nuestra base de datos.
5. 5. Para cargar la tarjeta, creamos un pedido de pasarela de pago. Sin embargo, en lugar de utilizar directamente los datos de la tarjeta (que no tenemos), utilizamos tokens. Y en lugar de enviar la solicitud directamente a la pasarela de pago, la enviamos a PCI Proxy.
6. 6. PCI Proxy recibe nuestra solicitud, detecta los tokens que hay y los sustituye por los datos sensibles de la tarjeta. Esta parte se llama destokenización.
7. 7. PCI Proxy reenvía la solicitud, que ahora contiene datos sensibles, a la pasarela de pago.

Muchos tipos de ataques resultan inútiles, debido a que nuestros almacenes de datos no contienen los datos sensibles.

Para acceder a la Matriz de Responsabilidad Compartida PCI DSS, navega hasta la sección "Documentos" de nuestra confianza.mews.com. Desde ahí, puedes solicitar directamente la matriz PCI DSS.

Mews La plataforma procesa datos personales y otros tipos de datos sensibles, sin embargo, no somos un servicio SaaS estándar de sólo procesador, así que para entender todos los flujos de datos, es importante distinguir los dos roles que ocupa Mews:

Procesador de datos: En la relación entre nuestros clientes (hoteles) y nosotros, somos un procesador de datos para todos sus datos que entran en la plataforma, incluidos los datos personales de sus clientes. Esto forma parte del servicio que prestamos a nuestros clientes.

Controlador de datos: En la relación entre nuestros usuarios (particulares) y nosotros, somos controladores de sus datos personales: proporcionamos un servicio de "monedero de viajes" y otros servicios a nuestros usuarios.

Estos dos roles y modos de operaciones de Mews son estrictamente distintos, y los datos nunca se mezclan. Y como somos una solución multiinquilino, una sola persona física puede tener sus datos personales en N+1 copias en la plataforma Mews. Si la persona ha interactuado con N de nuestros clientes (por ejemplo, ha hecho reservas en N hoteles diferentes), entonces se almacenan N cuentas de cliente, y Mews es el procesador de datos en ese caso. El "+1" representa otra copia de los datos personales que se almacenan en caso de que la persona se registre en Mews como usuario para utilizar el servicio de "monedero de viaje". Para esta copia única, Mews es el controlador de datos. No tenemos ningún acuerdo de control conjunto.

Todos los tipos de datos se almacenan en nuestro almacén de datos Azure de acuerdo con la sección Infraestructura de esta documentación. No archivamos los datos y las copias de seguridad sólo se conservan durante un periodo de tiempo limitado.

Datos de nuestros clientes

Los datos entran en el sistema manualmente por un empleado de nuestro cliente o son proporcionados por sus clientes tanto directamente (compartiéndolos desde el monedero de viajes con el cliente) como indirectamente, por ejemplo, a través de canales de reserva y nuestras API. Los datos consisten en datos personales de los clientes de nuestros clientes, que en su mayoría son viajeros de todo el mundo.

Nuestros clientes pueden registrar varios datos sobre sus clientes, como nombre, apellidos, segundo apellido, fecha de nacimiento, nacionalidad, documentos de identidad (pasaporte, DNI, carné de conducir, Visa), direcciones, dirección de correo electrónico, número de teléfono, etc. En cuanto a los detalles de tarjeta de pago, también se recogen, pero ni nuestro cliente ni nosotros tenemos acceso directo a ellos. Para más detalles, consulta la sección Seguridad de esta documentación.

Procesando

Tratamos los datos personales de acuerdo con el Anexo de Tratamiento de Datos que firmamos con nuestros clientes. Podemos acceder a los datos cuando sea necesario para prestar nuestro servicio (por ejemplo, investigando errores o ayudando a nuestros clientes de otras formas en función de sus peticiones). Es posible que utilicemos los datos para fines estadísticos y de análisis internos; sin embargo, siempre se anonimizan y cumplimos las obligaciones contractuales. Consulta la sección Subprocesadores en la que se enumeran las empresas de terceros que actúan como subprocesadores de los datos del cliente, o de algún subconjunto de los datos del cliente.

Retención

Almacenamos los datos personales durante el tiempo que sea necesario, teniendo en cuenta los fines para los que fueron proporcionados o recopilados. Puesto que somos el procesador cuando se trata de datos personales que recogen nuestros clientes (los controladores), estamos sujetos a sus instrucciones sobre cómo tratar los datos. Es responsabilidad del cliente asegurarse de que los periodos de conservación aplicables a los datos personales cumplen la ley. Para que nuestros clientes puedan gestionar los periodos de retención, damos a nuestros clientes opciones para:

• Borra manualmente todo el perfil del cliente y los datos personales almacenados en él. Esto afecta a todos los puntos de datos enumerados anteriormente, y se realiza un borrado duro de todos los datos.
• Configura la limpieza automática de los perfiles del cliente tras un periodo determinado sin uso. En este caso, el sistema realiza lo que de otro modo habría que hacer manualmente utilizando la primera opción.

Para los datos de pago, nuestros clientes pueden establecer fácilmente el periodo, en días, tras el cual la información de la tarjeta de pago del cliente se borrará automáticamente. Se trata de un proceso automatizado que borra todos los datos de la tarjeta adjuntos al perfil de huésped. Compensar significa que Mews no conserva el token de la tarjeta, y PCI Proxy no tendrá información sobre esa tarjeta. Cuando se configura el proceso, el sistema borra todos los token de la base de datos Mews , y se borra la tarjeta del PCI Proxy.

Cuando borramos datos de uno de los almacenamientos de datos de Azure que utilizamos, Microsoft sigue normas estrictas para sobrescribir los recursos de almacenamiento antes de su reutilización, así como para la destrucción física del hardware desmantelado.

Solicitudes de datos

Proporcionamos medios a nuestros clientes para satisfacer las solicitudes de datos y las solicitudes de eliminación de datos procedentes de sus clientes. También proporcionamos el portal del usuario con funcionalidad de mensajería que permite a nuestros clientes comunicarse con sus clientes fácilmente. En caso de que haya una solicitud a nuestro OPD(dpo@mews.com) que esté destinada a nuestros clientes y no a nosotros, remitimos dicha solicitud al destinatario adecuado.

Datos de nuestros usuarios

Los datos sólo entran en el sistema manualmente cuando el usuario rellena o actualiza su perfil. O durante la inscripción. Para proporcionar la mejor experiencia, por ejemplo, al realizar el check-in en un hotel nuevo, nuestros usuarios pueden registrar cualquier dato que cualquier hotel pueda necesitar para el proceso de check-in. Corresponde a los usuarios decidir si quieren compartir sus datos con un determinado cliente nuestro y en qué medida.

Además de estos puntos de datos compartibles, registramos nombres de usuario, contraseñas (hash), medios de autenticación 2FA y otros detalles necesarios para un uso sin fricciones de nuestra plataforma.

Tratamos los datos personales de nuestros usuarios de acuerdo con nuestra política de privacidadMews .

Retención

Debido a la naturaleza del producto, cuya función principal es servir de monedero de datos personales que puede utilizarse en cualquier momento en el futuro para compartir los datos con nuestros clientes, los datos se almacenan mientras el usuario tenga una cuenta con nosotros.

Solicitudes de datos

El portal del usuario proporciona a los usuarios todos sus datos personales que almacenamos y la posibilidad de eliminar su perfil. Otra opción es ponerte en contacto directamente con nuestro OPD en dpo@mews.com.

Para apoyar la prestación de nuestros servicios, Mews contrata y utiliza proveedores de servicios que tienen acceso a determinados datos personales. Un subprocesador de terceros es un servicio que nosotros, como procesador de datos, utilizamos para prestar servicios a nuestros clientes (hoteles) que son controladores de datos.

Seleccionamos estos subprocesadores terceros con mucho cuidado, y les exigimos al menos SOC 2, PCI-DSS u otra auditoría/certificación equivalente del sector.

Para el aprovisionamiento de nuestros servicios, contratamos a los siguientes subprocesadores:

• La residencia depende del producto Mews y de la configuración del cliente, con datos alojados en la Unión Europea o en Estados Unidos (consulta la sección Infraestructura para conocer los detalles regionales).
• Google España, S.L. - IE - Notificaciones push, otros servicios. Los datos residen en Estados Unidos.
• SFDC Ireland, Ltd. - IE - Escritorio de asistencia, portal de la comunidad. Los datos residen en la Unión Europea.
• Datatrans AG - CH - Tokenización de tarjetas de crédito. Los datos residen en Suiza.
• Twilio, Inc. - EE.UU. - Correo y mensajes de texto. Los datos residen en Estados Unidos.
• Aircall SAS - FR - Sistema telefónico empresarial integrado basado en la nube. Los datos residen en Estados Unidos.
• OKTA, Inc. - EEUU - Software de gestión de identidades de acceso basado en la nube. Los datos residen en la Unión Europea.
• Gooddata Ireland Limited - IE - Plataforma de análisis e inteligencia empresarial basada en la nube. Los datos residen en la Unión Europea.
• Cloudflare, Inc. - EEUU - Red de distribución de contenidos. Los datos residen en todo el mundo. El tráfico se enviará automáticamente al centro de datos más cercano.
• Confluent Europe LTD - Reino Unido - Plataforma de flujo de datos basada en la nube. Los datos residen en la Unión Europea.
• Intellum, Inc. - US - Sistema de gestión del aprendizaje. Los datos residen en la Unión Europea.
• Zuplo, Inc. - US - API Gateway y API manager. Los datos residen en todo el mundo. El tráfico se enviará automáticamente al centro de datos más cercano.
• Secoda Inc. - EE.UU. - Servicios de catalogación y gobierno de datos. Los datos residen en Estados Unidos, Singapur y Alemania
• Smart Gift Voucher Ltd - Reino Unido - Prestación de un servicio de compra, emisión, canje y conciliación de cupones regalo. Los datos residen en la Unión Europea y en el Reino Unido.

En determinados casos, Mews puede contratar a proveedores de servicios (socios certificados) que presten servicios profesionales de consulta e implementación en nombre de Mews a clientes específicos (hoteles) que adquieran este tipo de servicios a Mews. La elección del proveedor de servicios y su ubicación pueden variar en función de la disponibilidad y la ubicación del cliente.

La lista de Afiliados de Mews está disponible en https://www.mews.com/en/affiliates

Nuestro enfoque de las certificaciones consiste en juzgarlas caso por caso, según la demanda. No somos proactivos en este ámbito, porque aunque algunas certificaciones pueden ser útiles para aprender a mejorar determinados procesos, y pueden proporcionar la seguridad de que lo que haces se considera una práctica recomendada, también vemos que a algunas certificaciones les cuesta mantenerse al día con las nuevas tecnologías y las prácticas modernas de desarrollo de software. Por tanto, sólo emprendemos las certificaciones que tienen sentido para nosotros o que son una necesidad absoluta para nosotros.

Puedes encontrar todas nuestras certificaciones actuales en trust.mews.com.