Documentation de la plateforme

Mews est une plateforme SaaS cloud-native, sans serveur et multi-tenant. Cela a de nombreuses conséquences sur tous les aspects des opérations de Mews et sur la manière dont elle satisfait aux diverses exigences et à la conformité. Il est important de considérer Mews à travers le prisme de cette philosophie tout en lisant les autres sections de cette documentation, car elle peut être différente des systèmes plus traditionnels, et certaines exigences ou questions ne sont pas applicables lorsque l'on considère la plateforme Mews.

Application cloud-native

Dès le premier jour, Mews a été conçu pour le cloud. L'architecture du système a été conçue pour être implémentée dans le cloud et elle utilise tous les avantages qui en découlent. Mews n'est pas un système qui a été conçu pour fonctionner sur site et qui a ensuite été porté ou ajusté pour être implémenté dans le cloud, ce qui signifie que certains processus ou procédures fonctionnent différemment ou ne se produisent pas du tout.

Sans serveur

Il existe de multiples façons d'opérer dans un environnement cloud. D'un côté, vous pourriez n'utiliser que les services cloud de bas niveau, comme les machines virtuelles, et gérer tout le reste par vos propres moyens. L'avantage est que tous les fournisseurs de cloud offrent une telle fonctionnalité primitive et qu'il est donc assez simple d'en changer - bien que vous deviez avoir des compétences pour configurer les serveurs, les bases de données, etc. et continuer à les entretenir par vous-même. À l'autre extrémité du spectre, vous pourriez aller au-delà des fonctionnalités de bas niveau et utiliser le cloud comme un service, par exemple des services de calcul ou de stockage. De cette manière, le fournisseur de services en nuage s'occupe de la configuration et de la maintenance - l'inconvénient est que vous devenez de plus en plus lié à votre fournisseur de services en nuage spécifique. Nous sommes fiers d'être un partenaire de Microsoft et d'utiliser Microsoft Azure au maximum de son potentiel. C'est pourquoi nous nous situons du côté de la technologie sans serveur. Nous utilisons des services comme Azure App Service pour l'hôte des applications web, et Azure SQL Database et Azure Storage comme services de stockage. Par conséquent, nous n'exploitons pas nous-mêmes de machines virtuelles, de serveurs web ou de serveurs de base de données - cette responsabilité incombe à notre fournisseur de cloud, y compris en ce qui concerne la conformité et la sécurité de ces services. Ces services ont leurs propres accords de niveau de service définis par Azure. Nous avons construit notre solution sur cette base, de manière à combiner leurs services et leurs accords de niveau de service avec notre système, afin de garantir nos accords de niveau de service. Nous utilisons la même technique pour garantir notre conformité, notre sécurité, notre reprise après sinistre et d'autres aspects abordés plus en détail dans d'autres sections.

Multi-locataires

Tous nos clients utilisent une seule "installation" de production de la plateforme Mews. Cela signifie que nos clients utilisent toujours la dernière version de la plateforme, avec les mêmes fonctionnalités que n'importe qui d'autre sur la plateforme (en fonction du niveau d'abonnement). Du point de vue des données, celles-ci ne sont pas séparées, le stockage est partagé. Du point de vue de la sécurité, il est en fait très similaire à un système à locataire unique. Dans ce cas, il faudrait s'assurer que les utilisateurs ayant des niveaux de privilèges différents ne peuvent accéder qu'aux données auxquelles ils sont autorisés à accéder. Dans les systèmes à plusieurs locataires, le locataire peut être considéré comme une autre "couche" de privilèges. Le fait de disposer d'une solution multi-locataires nous permet de mettre en œuvre efficacement des scénarios au-dessus de l'entreprise ou de la chaîne et d'offrir une expérience client exceptionnelle, en particulier dans le portail des clients.

SaaS

Mews La seule chose dont vous avez besoin pour utiliser la plateforme Internet des objets est l'internet et un navigateur web. Nous nous occupons de tout le reste. Nous traitons tous les aspects qui sont abordés dans cette documentation, et nous nous efforçons de les faire aussi bien que possible tout en continuant à nous améliorer. Il est de notre responsabilité de veiller à ce que le système soit rapide, toujours disponible, doté de sauvegardes, sécurisé, conforme à toutes les législations, toujours à jour, accessible à tous dans le monde entier et utilisable par un large éventail d'utilisateurs. Les clients ne sont tenus de tenir des registres externes que si la loi l'exige. En France, les clients ont l'obligation de conserver les documents fiscaux sur un support physique externe sécurisé pendant la période légale requise.

Nous utilisons Microsoft Azure comme fournisseur de cloud. Certains services cloud sont mondiaux et bénéficient de la géo-réplication et de la haute disponibilité intégrées par Azure ; d'autres sont limités à une seule région.

Nous utilisons un certain nombre de régions Microsoft :

Régions de l'UE :

• Europe de l'Ouest (Pays-Bas).
• Europe du Nord (Irlande).
• Allemagne Centre-Ouest (Francfort).
• Suède centrale (Gävle).

Régions des États-Unis :

• US West 3 (Arizona)
• Est des États-Unis (Virginie)
• US East 2 (Virginie)
• US South Central (Texas)

Notre base de données principale est un cluster à haute disponibilité situé dans le centre-ouest de l'Allemagne, avec des répliques en Europe du Nord.

Écosystème

Nous utilisons de nombreux langages de programmation, cadres et technologies. Principalement :

• C# et .NET en arrière-plan
• JavaScript/TypeScript et React sur le frontend
• Flutter et Kotlin dans les applications mobiles

Environnements

La plateforme Mews fonctionne dans plusieurs instances appelées environnements ; certains d'entre eux sont publics, d'autres sont privés :

• Environnement de production
• Environnement démo
• Environnement de développement
• Environnements à fonctionnalités multiples

En tant que système cloud-native, notre stratégie de reprise après sinistre s'articule autour des sauvegardes de données et de la capacité à les restaurer en cas d'incident. Tous les autres services sont "sans état", ce qui signifie qu'en cas de sinistre, nous sommes en mesure de les restaurer sans perte d'informations. Nous nous appuyons fortement sur les fonctionnalités qu'offre Microsoft Azure dans ce domaine, et nous disposons en outre de nos propres niveaux de sauvegarde construits sur les fonctionnalités standard d'Azure.

Base de données Azure SQL

Nous utilisons le niveau premium de la base de données Azure SQL avec une réplique dans la région géographique secondaire. Cette configuration dispose déjà de plusieurs couches et mécanismes de sauvegarde, décrits en détail dans la documentation de la base de données Azure SQL. En outre, nous disposons de nos propres processus de sauvegarde. Toutes les options, qu'elles soient intégrées ou non, sont décrites ci-dessous :

• Au sein d'un centre de données, le service de base de données fonctionne comme un cluster à haute disponibilité de deux répliques identiques de la base de données avec une latence des données en temps quasi réel (quelques millisecondes). En cas de sinistre de la base de données primaire, le service se rabat immédiatement sur la base de données secondaire. Il est également possible de déclencher ce repli manuellement.
• Le service de base de données offre une restauration ponctuelle qui nous permet de restaurer une base de données complète à un moment donné, jusqu'à 35 jours en arrière.
• Le cluster de base de données de la région primaire est géo-répliqué sur le cluster secondaire à haute disponibilité de la région secondaire. En cas de sinistre dans la région primaire, nous sommes en mesure d'effectuer un basculement vers la région secondaire et de promouvoir la réplique secondaire au rang de maître. Nous pouvons le faire rapidement et de manière fiable en utilisant des groupes de basculement automatique.
• Nous réalisons des instantanés quotidiens de la base de données primaire en utilisant la capacité de restauration à un moment donné sur un autre serveur de sauvegarde. Le serveur de sauvegarde contient deux copies entièrement restaurées, datant au maximum de 24 et 48 heures, prêtes à être utilisées immédiatement en cas de sinistre affectant à la fois la base de données primaire et la base de données secondaire. Ces instantanés peuvent également être utilisés dans le cas d'une corruption partielle des données afin de les restaurer immédiatement.

Stockage Azure

Comme magasin pour les données binaires, nous utilisons Azure Storage configuré pour utiliser des capacités de stockage géo-redondantes. Les données sont automatiquement répliquées trois fois dans la région primaire et trois fois dans la région secondaire. Le compte de stockage utilise également une fonctionnalité de suppression en douceur qui évite les problèmes spécifiques aux applications et nous permet de récupérer les données potentiellement corrompues. Comme pour la base de données SQL, nous effectuons des sauvegardes incrémentielles quotidiennes de toutes les données du stockage dans un stockage de secours qui est prêt à être utilisé immédiatement en cas de sinistre affectant le stockage primaire.

Cosmos DB

Nous avons configuré Cosmos DB pour qu'elle soit répliquée dans plusieurs régions. Cosmos DB réplique de manière transparente les données dans toutes les régions associées à notre compte et prend en charge le basculement automatique en cas de panne régionale. Actuellement, nous ne stockons que des données non critiques dans Cosmos DB (par exemple les journaux) et nous n'avons donc pas de couche de données supplémentaire en plus des fonctionnalités offertes par le service.

Notre philosophie en matière d'implémentations est de déployer aussi souvent que possible et plus l'ensemble des changements déployés est petit, mieux c'est. La raison principale est que cela nous aide à livrer les fonctionnalités finies et les correctifs à nos clients dès que possible afin qu'ils puissent en bénéficier immédiatement. La raison secondaire est de minimiser les problèmes lors des déploiements et de simplifier l'investigation et le retour en arrière en cas de problème. Tous nos déploiements n'entraînent aucune interruption de service pour l'utilisateur final.

Les calendriers d'implémentation

Notre plateforme n'est pas une application unique que nous déploierions en bloc, mais plutôt un ensemble de systèmes et d'applications qui fonctionnent et communiquent ensemble et qui ont leur propre calendrier d'implémentation. Il existe trois grandes catégories d'applications avec leurs calendriers d'implémentation respectifs :

• La plateforme dorsale (serveur) est déployée au moins une fois par jour de la semaine. En outre, si nécessaire, des implémentations ad hoc peuvent être effectuées à des fins diverses, par exemple pour des corrections à chaud. Le scénario standard est que toutes les modifications (fonctionnalités, corrections de bugs, améliorations) sont continuellement implémentées dans l'environnement de développement. Une fois par jour, nous prenons automatiquement un instantané de la version de l'environnement de développement et nous le déployons dans l'environnement démo (c'est ce qu'on appelle le gel des fonctionnalités). Le jour suivant, si aucun problème n'est survenu sur le site de démonstration, cette version est implémentée dans l'environnement de production. Tous les déploiements se font progressivement sur l'ensemble des instances et des régions. Pendant le processus, nous surveillons le système et, en cas de problème, nous sommes en mesure de revenir en arrière.
• Les applications web (par exemple Commander, Distributor ou Navigator) sont implémentées indépendamment chaque fois qu'un changement est finalisé dans l'application. Cela signifie que chaque fois qu'une fonctionnalité est implémentée ou qu'un bug est corrigé et qu'il passe l'assurance qualité, il est immédiatement implémenté à la fois en démo et en production. Il s'agit d'une véritable livraison continue, ce qui signifie qu'il peut y avoir 50 ou 0 déploiements en une journée, en fonction du nombre de changements finalisés ce jour-là. Là encore, nous surveillons l'état des applications et nous sommes en mesure d'annuler n'importe quel processus si nécessaire.
• Les applications mobiles sont déployées de manière irrégulière, en raison des processus de vérification dans les magasins d'applications. De temps en temps, lorsque nous déterminons que l'ensemble des changements terminés dans la version de développement de l'application est raisonnablement important, ou lorsque cela est nécessaire pour d'autres paramètres, nous publions une nouvelle version de l'application. Elle est ensuite publiée dans le magasin d'applications correspondant, où elle passe par le processus de vérification. Après un certain temps (heures ou jours), la nouvelle version arrive sur les appareils des utilisateurs finaux.

Nous nous réservons la possibilité de programmer des temps d'arrêt nécessaires à la modification des systèmes, bien que notre objectif soit de ne jamais recourir à cette option. Jusqu'à présent, nous n'avons dû l'utiliser qu'une seule fois, en 2013, lors de la migration de notre fournisseur de cloud d'AppHarbor vers Microsoft Azure. Depuis lors, nous n'avons pas eu de temps d'arrêt programmé.

Processus de libération

Il est important de faire la distinction entre l'implémentation et la libération. L'implémentation est le moment où le changement atteint la production. Toutefois, le changement ne doit pas nécessairement être disponible pour tous les clients. Le moment où le changement est disponible pour un client est appelé "release". Les petites modifications, les corrections de bug, les améliorations ou d'autres éléments non critiques sont communiqués à tous nos clients dès qu'ils sont implémentés. Cependant, pour les changements plus importants ou plus critiques, nous nous en tenons au processus de publication en 4 étapes suivant :

1. 1. Alpha interne : La modification n'est diffusée qu'aux employés de Mews. Nous utilisons également Mews en interne, nous sommes donc les "canaris" qui testent le changement.
2. 2. Bêta privée : La modification est diffusée auprès d'un sous-ensemble de clients sélectionnés qui forment des groupes d'utilisateurs précoces. Si le changement est particulièrement important pour une personne qui a participé au processus de découverte et de livraison du produit, elle peut également être incluse dans la version bêta privée. Pour cette étape et également pour l'alpha interne, nous utilisons LaunchDarkly pour gérer l'ensemble des clients impactés.
3. 3. Bêta publique : La modification est mise à la disposition de tous ceux qui l'ont acceptée. En général, nous introduisons une option dans les paramètres qui permet à tout le monde d'accepter le changement.
4. 4. Disponibilité générale : Le changement est mis à la disposition de tous nos clients.

Pour tous les types de problèmes, y compris les incidents, les incidents de sécurité, les bugs, les enquêtes ou les alertes de surveillance, nous suivons un processus de résolution strict. Le processus est documenté dans notre base de connaissances interne. Chaque problème, quelle que soit sa gravité, se voit attribuer une équipe et est immédiatement communiqué à l'équipe à l'aide d'un canal Slack interne.

Pour les problèmes ayant un impact significatif sur les clients, il existe une procédure d'escalade supplémentaire afin de s'assurer qu'ils sont traités d'urgence. Ces incidents sont communiqués dans un canal d'incidents à l'échelle de la société et des mises à jour régulières sont partagées avec les parties prenantes internes et externes.

Après la résolution, l'équipe effectue une analyse des causes profondes, conçoit des solutions et publie le document post-mortem. Les solutions issues du post-mortem sont implémentées dans un délai défini par notre SLO interne.

Mews La plateforme Personnalisé travaille avec des données clients très sensibles, c'est pourquoi la sécurité et la confidentialité des données sont des éléments non négociables du système. Notre approche générale dans ce domaine est que rien ne doit reposer sur les personnes ou leurs connaissances. Toutes nos mesures de sécurité et nos processus internes sont conçus dans ce sens ; par exemple, si nos développeurs sont régulièrement formés aux meilleures pratiques de codage sécurisé, nous ne nous appuyons pas uniquement sur celles-ci pour assurer la sécurité. Nos processus et nos cadres sont conçus pour interdire la création de bugs de sécurité ou, à tout le moins, pour rendre extrêmement difficile pour un développeur d'introduire des problèmes de sécurité dans notre système s'il n'est pas techniquement possible de l'interdire totalement. Cela se reflète dans notre processus de résolution des problèmes de sécurité, qui est décrit plus loin. Notre stratégie de sécurité est régie par deux grands principes :

1. 1. Minimiser la surface d'attaque, en réduisant sa portée et sa complexité.
2. 2. Des tests de pénétration continus de la surface d'attaque, avec une résolution étendue et approfondie de toutes les découvertes.

Outre ces mesures proactives, nous sommes très souvent soumis à des audits, des certifications, des processus de diligence raisonnable et des tests d'intrusion par des sociétés tierces, soit désignées par nous (par exemple PCI-DSS, ISO), soit par nos clients potentiels.

Réduire la surface d'attaque

La meilleure façon d'éviter les problèmes de sécurité est d'éliminer complètement la possibilité de les créer. Cela s'aligne sur notre philosophie serverless : nous ne contrôlons pas le matériel, les systèmes d'exploitation, les serveurs web ou les serveurs de base de données. Nous ne pouvons pas mal configurer l'un de ces systèmes, ni oublier d'appliquer les correctifs de sécurité, etc. - C'est la responsabilité d'Azure, qui dispose de grandes équipes de sécurité. Nous utilisons une configuration très limitée des services Azure, pour lesquels il existe des options permettant d'activer certaines fonctionnalités de sécurité supplémentaires. Pour être sûrs de n'en manquer aucune, nous utilisons Azure Security Advisor, qui nous informe de toutes ces options, par exemple lorsqu'Azure introduit de nouvelles fonctionnalités susceptibles de renforcer la sécurité de nos systèmes. Grâce à tout ce qui précède, notre surface d'attaque (du point de vue du système) se réduit effectivement au code d'application que nous développons. Pour plus d'informations sur les capacités de sécurité d'Azure, veuillez consulter la documentation sur les principes de sécurité d'Azure.

Tests de pénétration continus

Comme nous l'avons déjà démontré, nous nous concentrons principalement sur la sécurité au niveau de l'application. Afin de garantir la sécurité de notre système, nous continuons à subir des tests de pénétration effectués par cobalt.io. À tout moment, une partie de notre système ou de notre produit fait l'objet d'un test de résistance et nous veillons à ce que toute la surface soit couverte par des tests de manière continue.

Il existe de multiples approches pour remédier aux vulnérabilités en matière de sécurité. Nous sommes fiers de notre approche et abordons chaque problème de sécurité de manière post-mortem, ce qui signifie que nous effectuons une analyse détaillée des causes profondes et résolvons ensuite non seulement l'instance individuelle, mais aussi toutes les instances similaires dans tous nos produits. En outre, nous avons mis en place des mesures pour éviter que de tels problèmes ne se reproduisent à l'avenir. Par exemple, si un problème est détecté dans l'une de nos API, nous mettons à jour notre cadre d'API de manière à éliminer le problème de toutes nos API. Ou bien nous implémentons un analyseur de code statique qui peut effectuer un check-in automatique du problème dans notre base de code, ainsi que dans le nouveau code que nous produisons. Ainsi, même si un seul produit est testé à la fois, nous appliquons nos conclusions à tous les produits. Pour plus d'informations, effectuez un check-in dans la section Incidents.

Mesures de sécurité technique

D'un point de vue technique, nous faisons beaucoup de choses pour assurer la sécurité non seulement de la plateforme elle-même, mais aussi de nos clients. En voici quelques-unes :

• Les données sont cryptées en transit, nous appliquons au moins le protocole TLS 1.2 et obtenons lanoteA+ au test Qualys SSL Labs.
• Les données contenues dans tous les types de stockage que nous utilisons sont cryptées au repos.
• Nous utilisons plusieurs niveaux de journaux de système internes et fournissons des journaux d'audit à nos clients à l'intérieur de la plateforme.
• Nous effectuons régulièrement des scans ASV, des scans de vulnérabilité internes et externes.
• Tous nos appareils sont protégés par des logiciels anti-virus/anti-malware et sont gérés de manière centralisée par des solutions MDM.
• Nous appliquons une politique de mots de passe forts, utilisons 1Password et appliquons la MFA dans tous les systèmes internes qui offrent cette fonctionnalité.
• Nous utilisons Azure Active Directory et SSO pour tous les systèmes internes qui offrent cette fonctionnalité.
• Nous suivons le principe du moindre privilège pour tous nos systèmes internes.
• Notre plateforme prend en charge le MFA et impose des mots de passe forts à nos utilisateurs.
• Les mots de passe des utilisateurs sont hachés à l'aide de bcrypt et ne sont jamais stockés en clair.
• Toutes les clés et tokens sensibles des utilisateurs qui doivent être utilisés pour l'authentification de tiers (comme les mots de passe FTP) sont chiffrés dans Azure SQL Database.
• Toutes les clés et tokens Mews sensibles sont cryptés dans la configuration.

Mesures de sécurité pour les personnes

• Nous effectuons des check-in pour tous les candidats à des fonctions sensibles que nous sommes sur le point d'engager. L'étendue et la rigueur de ces check-in dépendent de la fonction et de l'ancienneté du candidat.
• Les contrats conclus avec tous nos employés contiennent des clauses de confidentialité et les employés sont tenus de respecter les règles internes relatives au traitement des données à caractère personnel.
• Tous les employés suivent une séance d'orientation pour les nouveaux embauchés, qui comprend une formation obligatoire à la sécurité et à la confidentialité des données.
• Tous les employés utilisent 1Password et génèrent leur mot de passe principal à l'aide de diceware.
• Tous les membres du département technique (développeurs, analystes de données, assurance qualité, IT) suivent une formation obligatoire en matière de sécurité au moins une fois par an.

Données des cartes de paiement

Un bon exemple de réduction de la surface d'attaque est la façon dont nous traitons les données sensibles des cartes de paiement. Mews utilise Proxy PCI comme fournisseur de tokenisation de cartes. Les données sensibles des cartes, comme le numéro ou le CVV, n'atteignent même pas notre infrastructure. Prenons l'exemple d'un flux simple qui consiste à recevoir les données d'une carte de crédit d'un tiers (par exemple un canal de réservation) et à débiter cette carte :

1. 1. Lorsqu'un tiers a besoin de nous envoyer les détails d'une carte, il ne nous routera pas directement la demande, comme cela se fait habituellement, mais il la routera vers le Proxy PCI.
2. 2. Le Proxy PCI reçoit la demande, détecte les détails de la carte, les stocke et les remplace par des tokens qui ne sont plus sensibles. Cette partie est appelée tokenisation.
3. 3. Proxy PCI nous transmet la demande, qui contient désormais des tokens.
4. 4. Nous stockons la tokenisation dans notre base de données.
5. 5. Pour débiter la carte, nous créons une demande de passerelle de paiement. Cependant, au lieu d'utiliser directement les données de la carte (que nous n'avons pas), nous utilisons des tokens. Et au lieu d'envoyer la demande directement à la passerelle de paiement, nous la faisons router vers le Proxy PCI.
6. 6. Proxy PCI reçoit la demande de notre part, détecte les tokens qui s'y trouvent et les remplace par les données sensibles de la carte. Cette partie s'appelle la détokénisation.
7. 7. Proxy PCI transmet la demande, qui contient désormais des données sensibles, à la passerelle de paiement.

De nombreux types d'attaques sont rendus inutiles par le fait que nos stockages de données ne contiennent pas de données sensibles.

Pour accéder à la matrice de responsabilité partagée PCI DSS, veuillez vous rendre dans la section "Documents" de notre plateforme trust.mews.com sur notre plateforme. De là, vous pouvez directement demander la matrice PCI DSS.

Mews traite des données personnelles et d'autres types de données sensibles, mais nous ne sommes pas un service SaaS de processeur standard. Pour comprendre tous les flux de données, il est donc important de distinguer les deux fonctions qu'occupe Mews:

Processeur de données : Dans la relation entre nos clients (hôtels) et nous, nous sommes un processeur de données pour toutes leurs données entrant dans la plateforme, y compris les données personnelles de leurs clients. Cela fait partie du service que nous offrons à nos clients.

Responsable du traitement : Dans la relation entre nos utilisateurs (particuliers) et nous, nous sommes un responsable du traitement de leurs données à caractère personnel - nous fournissons un service de "portefeuille de voyage" et d'autres applications à nos utilisateurs.

Ces deux fonctions et modes opératoires de Mews sont strictement distincts et les données ne se mélangent jamais. Et comme nous sommes une solution multi-locataires, une seule personne physique peut avoir ses données personnelles en N+1 copies dans la plateforme Mews. Si la personne a interagi avec N de nos clients (par exemple, elle a fait des réservations dans N hôtels différents), alors N comptes clients sont stockés, et Mews est le processeur de données dans ce cas. Le "+1" représente une autre copie des données personnelles qui sont stockées dans le cas où la personne s'est inscrite sur Mews en tant qu'utilisateur afin d'étudier le service "travel wallet". Pour cette copie unique, Mews est le responsable du traitement des données. Nous n'avons pas d'accord de contrôle conjoint.

Tous les types de données sont stockés dans notre stockage de données Azure conformément à la section Infrastructure de cette documentation. Nous n'effectuons aucun archivage des données et les sauvegardes ne sont conservées que pour une période limitée.

Données de nos clients

Les données entrent dans le système soit manuellement par un employé de notre client, soit sont fournies par leurs clients à la fois directement (par partage du portefeuille de voyage au client) et indirectement, par exemple via les canaux de réservation et nos API. Les données consistent en des informations personnelles sur les clients de nos clients, qui sont pour la plupart des voyageurs du monde entier.

Nos clients sont en mesure d'enregistrer divers points de données concernant leurs clients, tels que le prénom, le nom, l'avant-dernier nom, la date de naissance, la nationalité, les pièces d'identité (passeport, carte d'identité, permis de conduire, visa), l'adresse, l'adresse électronique, le numéro de téléphone, etc. Les données relatives aux cartes de paiement sont également collectées, mais elles ne sont pas directement accessibles à notre client ni à nous-mêmes. Pour plus de détails, veuillez vous référer à la section Sécurité de cette documentation.

Traitement

Nous traitons les données personnelles conformément à l'addendum sur le traitement des données que nous signons avec nos clients. Nous sommes en mesure d'accéder aux données lorsque cela est nécessaire pour fournir notre service (par exemple, pour enquêter sur des bugs ou aider nos clients d'une autre manière en fonction de leurs demandes). Nous pourrions utiliser les données à des fins statistiques et d'analyse internes ; cependant, elles sont toujours anonymisées et nous suivons les obligations contractuelles. Veuillez vous référer à la section Sous-traitants qui énumère les sociétés tierces qui agissent en tant que sous-traitants des données du client, ou d'un sous-ensemble des données du client.

Rétention

Nous conservons les données personnelles aussi longtemps que nécessaire, compte tenu des finalités pour lesquelles elles ont été fournies ou collectées. Étant donné que nous sommes le processeur lorsqu'il s'agit de données à caractère personnel que nos clients (les responsables du traitement) collectent, nous sommes soumis à leurs instructions sur la manière de traiter les données. Il incombe au client de s'assurer que les périodes de conservation applicables aux données à caractère personnel sont conformes à la loi. Pour permettre à nos clients de gérer les périodes de conservation, nous leur offrons les options suivantes :

• Effacez manuellement le profil complet du client et les données personnelles qui y sont stockées. Cela a un impact sur tous les points de données énumérés ci-dessus, et une suppression en dur de toutes les données est effectuée.
• Personnalisé le nettoyage automatique des profils des clients après une période déterminée sans utilisation. Dans cette étude de cas, le système effectue ce qui devrait autrement être fait manuellement en utilisant la première option.

Pour les données de paiement, nos clients peuvent facilement définir la période, en jours, après laquelle les informations relatives à la carte de paiement du client seront automatiquement effacées. Il s'agit d'un processus automatisé qui efface toutes les données de la carte liées au profil du client. La tokenisation signifie que Mews ne conserve pas le jeton de la carte et que Proxy PCI ne dispose pas d'informations sur cette carte. Lorsque le processus est mis en place, le système efface tous les tokens de la base de données Mews , et la carte du Proxy PCI est effacée.

Lorsque nous supprimons en dur des données de l'un des stockages de données Azure que nous utilisons, Microsoft respecte des normes strictes en matière d'écrasement des ressources de stockage avant leur réutilisation, ainsi qu'en matière de destruction physique du matériel mis hors service.

Demandes de données

Nous fournissons à nos clients les moyens de répondre aux demandes de données et de suppression de données émanant de leurs clients. Nous fournissons également au portail utilisateur une fonctionnalité de messagerie qui permet à nos clients de communiquer facilement avec leurs clients. Si une demande adressée à notre DPO(dpo@mews.com) est destinée à nos clients et non à nous, nous la transmettons au destinataire approprié.

Données de nos utilisateurs

Les données n'entrent dans le système que manuellement, lorsque l'utilisateur remplit ou met à jour son profil. Ou lors de l'inscription. Afin d'offrir la meilleure expérience possible, par exemple lorsque vous effectuez un check-in dans un nouvel hôtel, nos utilisateurs peuvent enregistrer n'importe quelle donnée dont un hôtel pourrait avoir besoin pour le processus de check-in. Il appartient aux utilisateurs de décider s'ils souhaitent partager leurs données avec un de nos clients et dans quelle mesure.

En plus de ces points de données partageables, nous enregistrons les noms d'utilisateur, les mots de passe (hachés), les moyens d'authentification 2FA et d'autres détails nécessaires à une utilisation sans friction de notre plateforme.

Nous traitons les données personnelles de nos utilisateurs conformément à notre politique de confidentialitéMews .

Rétention

En raison de la nature du produit, dont la fonction principale est de servir de portefeuille de données personnelles pouvant être utilisé à tout moment dans le futur pour partager les données avec nos clients, les données sont stockées aussi longtemps que l'utilisateur possède un compte chez nous.

Demandes de données

Le portail de l'utilisateur fournit aux utilisateurs toutes les données personnelles que nous stockons et la possibilité de supprimer leur profil. Vous pouvez également contacter directement notre DPO à l'adresse dpo@mews.com.

Pour soutenir la prestation de nos services, Mews engage et utilise des prestataires de services qui ont accès à certaines données à caractère personnel. Un sous-traitant tiers est un service que nous, en tant que processeur de données, utilisons pour fournir des services à nos clients (hôtels) qui sont les responsables du traitement.

Nous sélectionnons ces sous-traitants tiers avec le plus grand soin et exigeons d'eux au moins un audit/une certification SOC 2, PCI-DSS ou un autre audit/une autre certification équivalente dans le secteur.

Pour le provisionnement de nos services, nous faisons appel aux sous-traitants suivants :

• Mews La résidence dépend du produit Personnalisé et de la configuration du client, les données étant hébergées soit dans l'Union européenne, soit aux États-Unis (voir la section Infrastructure pour plus de détails sur les régions).
• Google Ireland, Ltd. - IE - Notifications push, autres services. Les données résident aux États-Unis.
• SFDC Irlande, Ltd. - IE - Poste de travail, portail de la communauté. Les données résident dans l'Union européenne.
• Datatrans AG - CH - Tokenisation des cartes de crédit. Les données résident en Suisse.
• Twilio, Inc - US - Mailing et messagerie texte. Les données résident aux États-Unis.
• Aircall SAS - FR - Système téléphonique professionnel intégré basé sur le cloud. Les données résident aux États-Unis.
• OKTA, Inc - États-Unis - Logiciel de gestion des identités et des accès basé sur le cloud. Les données résident dans l'Union européenne.
• Gooddata Ireland Limited - IE - Plate-forme d'analyse et de business intelligence basée sur le cloud. Les données résident dans l'Union européenne.
• Cloudflare - États-Unis - Réseau de diffusion de contenu. Les données résident dans le monde entier. Le trafic sera automatiquement routé vers le centre de données le plus proche.
• Confluent Europe LTD - Royaume-Uni - Plate-forme de flux de données basée sur le cloud. Les données résident dans l'Union européenne.
• Intellum, Inc - États-Unis - Système de gestion de l'apprentissage. Les données résident dans l'Union européenne.
• Zuplo - États-Unis - Passerelle API et gestion des API. Les données résident dans le monde entier. Le trafic sera automatiquement routé vers le centre de données le plus proche.
• Secoda Inc - États-Unis - Services de gouvernance des données et de catalogage. Les données sont conservées aux États-Unis, à Singapour et en Allemagne.
• Smart Gift Voucher Ltd - Royaume-Uni - Provisionnement d'un service d'achat, d'émission, de remboursement et de rapprochement de chèques-cadeaux. Les données résident dans l'Union européenne et au Royaume-Uni.

Dans certains cas, Mews peut engager des prestataires de services (partenaires certifiés) qui fournissent des services professionnels de consultation et d'implémentation au nom de Mews à des clients spécifiques (hôtels) qui achètent ce type de services à Mews. Le choix du fournisseur de services et de sa localisation peut varier en fonction de la disponibilité et de la localisation du client.

La liste des affiliés de Mews est disponible à l'adresse suivante : https://www.mews.com/en/affiliates

Notre approche des certifications consiste à les juger au cas par cas et à la demande. Nous ne sommes pas proactifs dans ce domaine, car même si certaines certifications peuvent être utiles pour apprendre à améliorer certains processus, et peuvent fournir l'assurance que ce que vous faites est considéré comme une bonne pratique, nous constatons également que certaines certifications ont du mal à suivre l'évolution des nouvelles technologies et des pratiques modernes de développement de logiciels. Par conséquent, nous n'entreprenons que les certifications qui ont un sens pour nous ou qui sont une nécessité absolue pour nous.

Vous trouverez toutes nos certifications actuelles à l'adresse suivante : trust.mews.com.