Platform documentatie

Mews is een cloud-native, serverloos, multi-tenant SaaS platform. Dit heeft veel gevolgen voor alle aspecten van de manier waarop Mews werkt en hoe het voldoet aan verschillende vereisten en compliance. Het is belangrijk om naar Mews te kijken door het prisma van deze filosofie terwijl je andere gedeeltes van deze documentatie leest, omdat het anders kan zijn dan meer traditionele systemen en sommige vereisten of vragen niet van toepassing zijn als je het Mews platform bekijkt.

Cloud-native

Vanaf dag één is Mews gebouwd voor de cloud. De systeemarchitectuur is ontworpen voor implementatie in de cloud en maakt gebruik van alle voordelen die dit met zich meebrengt. Mews is geen systeem dat is ontworpen om on-premises te draaien en later is geporteerd of aangepast voor implementatie in de cloud, wat betekent dat sommige processen of procedures anders werken of helemaal niet plaatsvinden.

Serverloos

Er zijn meerdere manieren om werkzaamheden uit te voeren binnen een cloud omgeving. Aan de ene kant van het spectrum kun je alleen de low-level diensten in de cloud gebruiken, zoals virtuele machines, en al het andere zelf afhandelen. Het voordeel hiervan is dat alle cloud providers dergelijke primitieve functionaliteit bieden en dat het daarom vrij eenvoudig is om over te stappen - hoewel je wel expertise moet hebben over hoe je de servers, databases enz. moet configureren en doorlopend zelf moet onderhouden. Aan de andere kant van het spectrum kun je verder gaan dan functionaliteit op laag niveau en de cloud als dienst gebruiken, bijvoorbeeld computing of opslagdiensten. Op die manier zorgt de cloud provider voor de configuratie en het onderhoud - het nadeel is dat je meer vastzit aan je specifieke cloud provider. We zijn een trotse partner van Microsoft en maken optimaal gebruik van Microsoft Azure. Daarom zitten we aan de serverloze kant van het spectrum. We gebruiken diensten als Azure App Service voor het hosten van webapplicaties en Azure SQL Database en Azure Storage als opslagdiensten. Daarom beheren we zelf geen virtuele machines, webservers of databaseservers - dat is de verantwoordelijkheid van onze cloud provider, inclusief de compliance en beveiliging van dergelijke diensten. Deze diensten hebben hun eigen SLA's die door Azure zijn gedefinieerd. We hebben onze oplossing daarop gebouwd op een manier die hun diensten en SLA's combineert met ons systeem, om onze SLA's te garanderen. We gebruiken dezelfde techniek om onze compliance, beveiliging, disaster recovery en andere aspecten te garanderen die in meer detail worden gecoupeerd in de volgende gedeelten.

Multi-tenant

Er is één productie "installatie" van het platform Mews die al onze klanten gebruiken. Dat betekent dat onze klanten altijd op de nieuwste versie van het platform draaien, met dezelfde functies en functionaliteit die voor iedereen op het platform beschikbaar zijn (afhankelijk van het abonnement). Vanuit het oogpunt van gegevens zijn data niet gescheiden, de opslag wordt gedeeld. Vanuit een beveiligingsperspectief lijkt het eigenlijk erg op een single-tenant systeem. Daar moeten we ervoor zorgen dat gebruikers met verschillende privilegeniveaus alleen toegang hebben tot de data waartoe ze toegang hebben. Op multi-tenant systemen kan de tenant worden gezien als een andere "laag" van privileges. Met een multi-tenant oplossing kunnen we boven enterprise of boven keten scenario's effectief implementeren en een geweldige gastervaring leveren, vooral in de guest portal.

SaaS

Het enige wat je nodig hebt om het platform Mews te gebruiken is internet en een webbrowser. Voor de rest zorgen wij. We houden ons bezig met alle aspecten die in deze documentatie worden gecoupeerd, en we streven ernaar om ze zo goed mogelijk te doen terwijl we ons voortdurend verbeteren. Het is onze verantwoordelijkheid om ervoor te zorgen dat het systeem snel is, altijd beschikbaar is, back-ups heeft, veilig is, voldoet aan alle wetgevingen, altijd up-to-date is, toegankelijk is voor iedereen over de hele wereld en bruikbaar is voor een groot aantal gebruikers. Gasten zijn alleen verantwoordelijk voor het bijhouden van externe gegevens als dat wettelijk vereist is. In Frankrijk zijn gasten verplicht om de belastinggegevens gedurende de wettelijk vereiste periode op een veilige externe fysieke drager te bewaren.

We gebruiken Microsoft Azure als cloud provider. Sommige van de cloud diensten zijn wereldwijd met geo-replicatie en hoge beschikbaarheid ingebouwd door Azure; sommige diensten zijn gebonden aan één regio.

We maken gebruik van een aantal Microsoft-regio's:

EU-regio's:

• West-Europa (Nederland).
• Noord-Europa (Ierland).
• Duitsland West-Centraal (Frankfurt).
• Zweden Centraal (Gävle).

Regio's in de VS:

• US West 3 (Arizona)
• VS Oost (Virginia)
• VS Oost 2 (Virginia)
• VS Zuid-Centraal (Texas)

Onze primaire database is een cluster met hoge beschikbaarheid in Duitsland West Central, met replicas in Noord-Europa.

Tech-stack

We gebruiken veel programmeertalen, frameworks en technologieën. Voornamelijk:

• C# en .NET aan de achterkant
• JavaScript/TypeScript en React aan de voorkant
• Flutter en Kotlin in mobiele toepassingen

Omgevingen

Het platform Mews draait in meerdere instanties, omgevingen genaamd; sommige zijn openbaar, andere privé:

• Productieomgeving
• Demo-omgeving
• Ontwikkelomgeving
• Feature-branch omgevingen

Als cloud-native systeem draait onze disaster recovery-strategie om back-ups van data en de mogelijkheid om deze terug te zetten in geval van een incident. Alle andere diensten zijn "stateless", wat betekent dat we ze in geval van een ramp kunnen herstellen zonder informatieverlies. We vertrouwen sterk op functies die Microsoft Azure op dit gebied biedt, plus we hebben onze eigen niveaus van back-ups gebouwd bovenop de standaard Azure functies.

Azure SQL database

We gebruiken de premium tier van Azure SQL database met een replica in de secundaire geografische regio. Deze opstelling heeft al verschillende back-up lagen en mechanismen out of the box, volledig beschreven in de Azure SQL database documentatie. Bovendien hebben we onze eigen back-upprocessen. Alle opties, zowel de ingebouwde als de onze, worden hieronder beschreven:

• Binnen een datacenter draait de database dienst als een cluster met hoge beschikbaarheid van twee identieke replica's van de database met een bijna realtime latency van de data (lage milliseconden). In het geval van een ramp met de primaire database, valt de dienst onmiddellijk terug naar de secundaire database. We kunnen deze fallback ook handmatig triggeren.
• De database dienst biedt point-in-time restore waarmee we een complete database kunnen herstellen naar een bepaald tijdstip tot 35 dagen terug.
• Het databasecluster in de primaire regio wordt geo-gerepliceerd naar het secundaire cluster met hoge beschikbaarheid in de secundaire regio. In het geval van een ramp in de primaire regio kunnen we een failover uitvoeren naar de secundaire regio en de secundaire replica promoveren naar master. We kunnen dat snel en betrouwbaar doen met auto-failover groepen.
• We maken dagelijks snapshots van de primaire database met behulp van de point-in-time restore mogelijkheid naar een andere back-up server. De back-upserver bevat twee volledig herstelde kopieën van maximaal 24 en 48 uur oud, klaar voor onmiddellijk gebruik in het geval van een ramp die zowel de primaire als de secundaire database treft. Deze snapshots kunnen ook worden gebruikt in het geval van gedeeltelijke beschadiging van data om de data onmiddellijk te herstellen.

Azure Opslag

Als opslagplaats voor binaire data gebruiken we Azure Storage, geconfigureerd om geo-redundante opslagmogelijkheden te gebruiken. De data wordt automatisch drie keer gerepliceerd in de primaire regio en drie keer in de secundaire regio. Het storage account gebruikt ook een soft-delete functie die applicatiespecifieke problemen voorkomt en ons in staat stelt om mogelijk beschadigde data te herstellen. Net als bij de SQL database voeren we dagelijks incrementele back-ups uit van alle data in de opslag naar een back-up opslag die klaar is voor onmiddellijk gebruik in het geval van een ramp die de primaire opslag aantast.

Kosmos DB

We hebben Cosmos DB geconfigureerd om te worden gerepliceerd in meerdere regio's. Cosmos DB repliceert de data transparant naar alle regio's bijbehorend aan ons account en ondersteunt automatische failover in geval van regionale uitval. Op dit moment slaan we alleen niet-bedrijfskritische data op in Cosmos DB (bijv. logs) en daarom hebben we geen extra data layer gebouwd bovenop de aangeboden functies van de dienst.

Onze filosofie als het gaat om implementaties is om zo vaak mogelijk te implementeren en hoe kleiner de geïmplementeerde change-set, hoe beter. De belangrijkste reden is dat dit ons helpt om voltooide functies en oplossingen zo snel mogelijk aan onze klanten te leveren, zodat zij er meteen van kunnen profiteren. De tweede reden is het minimaliseren van problemen tijdens implementaties en het vereenvoudigen van onderzoek en rollback in geval van problemen. Al onze implementaties veroorzaken geen downtime voor de eindgebruiker.

Implementatieschema's

Ons platform is niet één enkele applicatie die we en bloc implementeren, maar eerder een verzameling systemen en applicaties die samenwerken en communiceren en die hun eigen implementatieschema's hebben. Er zijn drie hoofdcategorieën applicaties met respectievelijke implementatieschema's:

• Backend platform (server) wordt minstens één keer per weekdag geïmplementeerd. Bovendien kunnen, indien nodig, ad-hoc implementaties worden uitgevoerd voor verschillende doeleinden, zoals hot fixes. Het standaardscenario is dat alle wijzigingen (functies, bug fixes, verbeteringen) continu worden geïmplementeerd in de ontwikkelomgeving. Eenmaal per dag maken we automatisch een momentopname van de versie van de ontwikkelomgeving en implementeren deze naar de demo-omgeving (dit wordt feature-freeze genoemd). De volgende dag, als er geen problemen waren op de demo-omgeving, wordt die versie geïmplementeerd in de productieomgeving. Alle implementaties gebeuren geleidelijk op alle instanties en regio's. Tijdens het proces bewaken we het systeem en in geval van problemen kunnen we het proces terugdraaien.
• Webapplicaties (bijv. Commander, Distributor of Navigator) worden onafhankelijk geïmplementeerd zodra een wijziging in de applicatie is voltooid. Dat betekent dat wanneer een functie is geïmplementeerd of een bug is opgelost en door de kwaliteitscontrole komt, deze onmiddellijk wordt geïmplementeerd voor zowel demo als productie. Dit is echte continue levering, wat betekent dat er 50 of 0 implementaties op een dag kunnen zijn, afhankelijk van hoeveel wijzigingen er die dag zijn afgerond. Ook hier bewaken we de gezondheid van de applicaties en kunnen we elk proces terugdraaien als dat nodig is.
• Mobiele applicaties worden onregelmatig geïmplementeerd vanwege verificatieprocessen in applicatiewinkels. Af en toe, wanneer we vaststellen dat de reeks voltooide wijzigingen in de ontwikkelversie van de applicatie redelijk groot is, of wanneer dit om andere redenen nodig is, brengen we een nieuwe versie van de applicatie uit. Vervolgens wordt het gepubliceerd naar de desbetreffende applicatiewinkel, waar het het verificatieproces doorloopt. Na enige tijd (uren of dagen) bereikt de nieuwe versie de apparaten van eindgebruikers.

We reserveren de optie van geplande downtime die nodig is voor systeemwijzigingen, hoewel ons doel is om deze optie nooit te gebruiken. Tot nu toe hebben we het maar één keer hoeven gebruiken, in 2013, toen we onze cloud provider migreerden van AppHarbor naar Microsoft Azure. Sindsdien hebben we geen geplande downtime meer gehad.

Vrijgaveproces

Het is belangrijk om onderscheid te maken tussen implementeren en uitbrengen. Implementeren is het moment waarop de verandering de productie bereikt. De verandering hoeft echter niet voor alle klanten beschikbaar te zijn. Het moment waarop de verandering beschikbaar is voor een klant wordt een release genoemd. Kleinere veranderingen, bug fixes, verbeteringen of andere niet-kritieke zaken worden vrijgegeven aan al onze klanten zodra ze zijn geïmplementeerd. Voor grotere of kritischere veranderingen houden we ons echter aan het volgende release-proces in 4 stappen:

1. 1. Interne alfa: De wijziging wordt alleen vrijgegeven aan Mews medewerkers. Wij gebruiken Mews ook intern, daarom zijn wij de "kanaries" die de verandering testen.
2. 2. Besloten bèta: De verandering wordt vrijgegeven aan een geselecteerde subset van klanten die early-adopter groepen vormen. Als de verandering vooral belangrijk is voor iemand die betrokken was bij het ontdekken en leveren van het product, dan kan hij of zij ook worden opgenomen in privébèta. Voor deze stap en ook voor interne alpha gebruiken we LaunchDarkly om de set van beïnvloede klanten te beheren.
3. 3. Openbare bèta: De verandering wordt vrijgegeven aan iedereen die ervoor kiest. Meestal introduceren we een optie in instellingen waarmee iedereen voor de verandering kan kiezen.
4. 4. Algemene beschikbaarheid: De wijziging wordt vrijgegeven voor al onze klanten.

Voor alle soorten problemen, waaronder incidenten, beveiligingsincidenten, bugs, onderzoeken of monitoringwaarschuwingen, volgen we een strikt oplossingsproces. Het proces is gedocumenteerd in onze interne kennisbank. Elk probleem, ongeacht de ernst ervan, heeft een team toegewezen gekregen en wordt onmiddellijk aan het team gecommuniceerd via een intern Slack kanaal.

Voor problemen die van grote invloed zijn op de gast, is er een extra escalatieproces om ervoor te zorgen dat ze met spoed worden aangepakt. Dergelijke incidenten worden gecommuniceerd in een bedrijfsbreed incidentkanaal en er worden regelmatig updates gedeeld met interne en externe belanghebbenden.

Na de oplossing voert het team een oorzakenanalyse uit, ontwerpt het oplossingen en publiceert het postmortemdocument. De oplossingen die voortkomen uit de postmortem worden geïmplementeerd binnen een periode die wordt bepaald door onze interne SLO.

Het platform Mews werkt met zeer gevoelige data van gasten, daarom zijn veiligheid en privacy van gegevens onmisbare elementen van het systeem. Onze algemene benadering op dit gebied is dat niets mag afhangen van mensen of hun kennis. Al onze beveiligingsmaatregelen en interne processen zijn op die manier ontworpen; hoewel onze ontwikkelaars bijvoorbeeld regelmatig worden getraind in best practices voor veilig coderen, vertrouwen we hier niet alleen op voor beveiliging. Onze processen en raamwerken zijn ontworpen om het maken van bugs in de beveiliging te verbieden, of het op zijn minst extreem moeilijk te maken voor een ontwikkelaar om beveiligingsproblemen in ons systeem te introduceren als het technisch niet mogelijk is om het volledig te verbieden. Dit wordt weerspiegeld in ons proces voor het oplossen van beveiligingsproblemen, dat verderop wordt beschreven. Onze beveiligingsstrategie wordt geleid door twee hoofdprincipes:

1. 1. Het aanvalsoppervlak minimaliseren, de reikwijdte en complexiteit verminderen.
2. 2. Voortdurende penetratietests van het aanvalsoppervlak, met uitgebreide en grondige oplossing van alle bevindingen.

Naast deze proactieve maatregelen ondergaan we vaak audits, certificeringen, due diligence-processen en pentests door externe bedrijven die door ons zijn aangewezen (bijv. PCI-DSS, ISO) of door onze potentiële klanten.

Het aanvalsoppervlak minimaliseren

De beste manier om veiligheidsproblemen te voorkomen is door de mogelijkheid om ze te maken volledig uit te sluiten. Dit sluit aan bij onze serverloze filosofie: we hebben geen controle over hardware, bedrifssystemen, webservers of databaseservers. We kunnen geen van deze systemen verkeerd configureren en we kunnen niet vergeten om beveiligingspatches toe te passen enz. - Dit is de verantwoordelijkheid van Azure, die grote beveiligingsteams hebben. We gebruiken een zeer beperkte configuratie van de Azure diensten, waarvoor opties zijn om enkele aanvullende beveiligingsfuncties in te schakelen. Om ervoor te zorgen dat we geen van deze opties missen, gebruiken we Azure Security Advisor, die ons over al deze opties informeert, bijvoorbeeld wanneer Azure nieuwe functies introduceert die de beveiliging van onze systemen kunnen versterken. Dankzij al het bovenstaande wordt ons aanvalsoppervlak (vanuit het systeemperspectief) effectief gereduceerd tot de applicatiecode die we ontwikkelen. Raadpleeg voor meer informatie over de Azure beveiligingsmogelijkheden de Azure documentatie over beveiligingsfundamenten.

Doorgaan met penetratietesten

Zoals al is aangetoond, richten we ons primair op beveiliging op applicatieniveau. Om ervoor te zorgen dat ons systeem veilig is, ondergaan we voortdurend penetratietests door cobalt.io. Op elk moment wordt een deel van ons systeem of een product met pennen getest en we zorgen ervoor dat het hele oppervlak continu wordt gecoupeerd met tests.

Er zijn meerdere benaderingen om beveiligingsproblemen aan te pakken. We zijn trots op onze aanpak en pakken elk beveiligingsprobleem post-mortem aan, wat betekent dat we een gedetailleerde analyse van de hoofdoorzaak uitvoeren en vervolgens niet alleen het individuele probleem oplossen, maar ook alle soortgelijke problemen in al onze producten. Bovendien nemen we maatregelen om te voorkomen dat dergelijke problemen zich in de toekomst opnieuw voordoen. Als er bijvoorbeeld een probleem wordt gevonden in een van onze API's, werken we ons API-framework zodanig bij dat het probleem in al onze API's wordt geëlimineerd. Of we implementeren een statische code-analyzer die automatisch kan inchecken op het probleem in onze codebase en in nieuwe code die we produceren. Dus ook al wordt er maar één product tegelijk getest, we passen onze bevindingen toe op alle producten. Kijk voor meer informatie in het gedeelte Incidenten.

Technische beveiligingsmaatregelen

Vanuit technisch oogpunt doen we veel om niet alleen het platform zelf, maar ook onze klanten te beveiligen. Hier zijn er een paar:

• Data wordt tijdens het transport versleuteld, we handhaven ten minste TLS 1.2 en behalen een A+rating in de Qualys SSL Labs test.
• Data in alle soorten opslag die we gebruiken, worden in rust versleuteld.
• We maken gebruik van meerdere niveaus van interne systeemlogs en leveren audit logs aan onze klanten binnen het platform.
• We scannen regelmatig ASV, interne en externe kwetsbaarheden.
• Al onze apparaten worden beschermd door anti-virus/anti-malware software en worden centraal beheerd door MDM-oplossingen.
• We handhaven een sterk wachtwoordbeleid, gebruiken 1Password en dwingen MFA af in alle interne systemen die deze functionaliteit bieden.
• We gebruiken Azure Active Directory en SSO voor alle interne systemen die deze functionaliteit bieden.
• We volgen het principe van de laagste privileges voor al onze interne systemen.
• Ons platform ondersteunt MFA en dwingt sterke wachtwoorden van onze gebruikers af.
• Wachtwoorden van gebruikers worden gehasht met bcrypt en nooit in platte tekst opgeslagen.
• Alle gevoelige sleutels en tokens van gebruikers die moeten worden gebruikt voor verificatie door derden (zoals FTP-wachtwoorden) worden versleuteld in Azure SQL Database.
• Alle gevoelige Mews sleutels en tokens worden versleuteld in de configuratie.

Veiligheidsmaatregelen voor mensen

• We voeren achtergrondcontroles uit voor alle kandidaten in gevoelige functies die we gaan aannemen. De omvang en grondigheid van deze controles hangt af van de functie en anciënniteit van de kandidaat.
• Contracten met al onze medewerkers bevatten geheimhoudingsclausules en medewerkers zijn verplicht zich te houden aan interne regels voor de verwerking van persoonlijke data.
• Alle medewerkers doorlopen de oriëntatie bij indiensttreding met verplichte training over beveiliging en data privacy.
• Alle medewerkers gebruiken 1Password en genereren hun hoofdwachtwoord met diceware.
• Alle leden van de technische afdeling (ontwikkelaars, data-analisten, kwaliteitsborging, IT) volgen minstens één keer per jaar een verplichte beveiligingstraining.

Betaalkaart data

Een goed voorbeeld van het verkleinen van het aanvalsoppervlak is de manier waarop we omgaan met gevoelige data van betaalkaarten. Mews gebruikt PCI Proxy als leverancier van tokenisatie van kaarten. Gevoelige data zoals kaartnummer of CVV bereiken onze infrastructuur nooit. Laten we als voorbeeld eens kijken naar een eenvoudige stroom waarbij kaartgegevens worden ontvangen van een derde partij (bijvoorbeeld een boekingskanaal) en vervolgens in rekening worden gebracht:

1. 1. Als derde partijen kaartgegevens naar ons willen sturen, sturen ze het verzoek niet rechtstreeks naar ons door, zoals gebruikelijk is, maar naar PCI Proxy.
2. 2. PCI Proxy ontvangt het verzoek, detecteert de kaartgegevens, slaat ze op en vervangt ze door tokens die niet langer gevoelig zijn. Dit deel wordt tokenisatie genoemd.
3. 3. PCI Proxy stuurt het verzoek, dat nu tokens bevat, naar ons door.
4. 4. We slaan het token op in onze database.
5. 5. Om de betaalkaart in rekening te brengen, maken we een betaalverzoek aan. Maar in plaats van de kaartdata direct te gebruiken (die we niet hebben), gebruiken we tokens. En in plaats van het verzoek rechtstreeks naar de betaalgateway te sturen, sturen we het door naar PCI Proxy.
6. 6. PCI Proxy ontvangt het verzoek van ons, detecteert de tokens en vervangt ze door de gevoelige kaartgegevens. Dit deel wordt detokenization genoemd.
7. 7. PCI Proxy stuurt het verzoek, dat nu gevoelige data bevat, door naar de betaalgateway.

Veel soorten aanvallen zijn nutteloos omdat onze dataopslag geen gevoelige gegevens bevat.

Om toegang te krijgen tot de PCI DSS Shared Responsibility Matrix, navigeer je naar het gedeelte "Documenten" op ons trust.mews.com platform. Van daaruit kun je direct de PCI DSS matrix opvragen.

Mews Het platform verwerkt persoonlijke en andere soorten gevoelige gegevens, maar we zijn geen standaard SaaS-dienst die alleen gegevensverwerkers verwerkt, dus om alle gegevensstromen te begrijpen is het belangrijk om de twee functies die Mews vervult te onderscheiden:

Gegevensverwerker: In de relatie tussen onze klanten (hotels) en ons zijn wij een gegevensverwerker voor al hun gegevens die het platform binnenkomen, inclusief persoonlijke gegevens van hun gasten. Dit maakt deel uit van de diensten die we aan onze klanten leveren.

Gegevensverantwoordelijke: In de relatie tussen onze gebruikers (individuen) en ons, zijn wij gegevensverantwoordelijke voor hun persoonlijke gegevens - wij bieden een "reisportemonnee" dienst en andere diensten aan onze gebruikers.

Deze twee functies en werkwijzen van Mews zijn strikt gescheiden en de data worden nooit gemengd. En omdat we een multi-tenant oplossing zijn, kan één fysiek persoon zijn persoonlijke data in N+1 kopieën op het platform Mews hebben. Als de persoon interactie had met N van onze klanten (bijv. reserveringen had in N verschillende hotels), dan worden er N klantaccounts opgeslagen en Mews is daar de gegevensverwerker. De "+1" vertegenwoordigt een andere kopie van de persoonlijke data die is opgeslagen in het geval dat de persoon zich heeft aangemeld bij Mews als gebruiker om gebruik te maken van de "travel wallet" service. Voor deze enkele kopie is Mews de gegevensverantwoordelijke. We hebben geen gezamenlijke zeggenschapsregeling.

Alle soorten data worden opgeslagen in onze Azure dataopslag volgens het gedeelte Infrastructuur van deze documentatie. We archiveren de data niet en back-ups worden slechts voor een beperkte periode bewaard.

Data van onze klanten

De gegevens komen handmatig in het systeem door een medewerker van onze klant of worden verstrekt door hun gasten, zowel direct (door gegevensuitwisseling van de reisportemonnee naar de klant) als indirect, bijvoorbeeld via boekingskanalen en onze API's. De data bestaat uit persoonlijke gegevens van klanten van onze klanten die meestal reizigers zijn van over de hele wereld.

Onze klanten kunnen verschillende data over hun gasten vastleggen, zoals voornaam, achternaam, tweede achternaam, geboortedatum, nationaliteit, identiteitsdocumenten (paspoort, identiteitskaart, rijbewijs, visa), adressen, e-mailadres, telefoonnummer, enz. Betaalkaartgegevens worden ook verzameld, maar zijn niet direct toegankelijk voor onze klant of voor ons. Raadpleeg voor meer details het gedeelte Beveiliging van deze documentatie.

Verwerking

We verwerken persoonlijke data in overeenstemming met het addendum voor gegevensverwerking dat we met onze klanten ondertekenen. We hebben toegang tot de data wanneer dat nodig is om onze diensten te kunnen leveren (bijv. het onderzoeken van bugs of het op andere manieren helpen van onze klanten op basis van hun verzoeken). We kunnen de data gebruiken voor interne statistische en analytische doeleinden; deze worden echter altijd geanonimiseerd en we houden ons aan de contractuele verplichtingen. Raadpleeg het gedeelte Subverwerkers met een lijst van bedrijven van derden die optreden als subverwerkers van de data van de klant, of een deelverzameling van de data van de klant.

Behoud

We bewaren persoonlijke gegevens zo lang als nodig is, gezien de doeleinden waarvoor ze zijn verstrekt of verzameld. Aangezien wij de verwerker zijn als het gaat om persoonlijke gegevens die onze klanten (de gegevensverantwoordelijken) verzamelen, zijn wij onderworpen aan hun instructies over hoe om te gaan met de gegevens. Het is de verantwoordelijkheid van de klant om ervoor te zorgen dat de bewaarperioden die van toepassing zijn op persoonlijke data in overeenstemming zijn met de wet. Om onze klanten in staat te stellen de bewaarperioden te beheren, geven we onze klanten opties om:

• Wis handmatig het volledige gastprofiel en de persoonlijke data die daar zijn opgeslagen. Dit heeft gevolgen voor alle bovenstaande datapunten en alle data wordt hard verwijderd.
• Automatisch opschonen van gastprofielen instellen na een opgegeven periode zonder gebruik. In dit geval voert het systeem uit wat anders handmatig zou moeten worden gedaan met de eerste optie.

Voor betaaldata kunnen onze klanten eenvoudig de periode, in dagen, instellen waarna de betaalkaartgegevens van de gast automatisch worden gewist. Dit is een geautomatiseerd proces dat alle aan het gastprofiel gekoppelde data van de kaart wist. Clearing betekent dat Mews het token van de kaart niet bewaart en PCI Proxy geen informatie over die kaart heeft. Wanneer het proces is ingesteld, wist het systeem elk token uit de database Mews en wordt de kaart van PCI Proxy gewist.

Wanneer we data hard verwijderen van een van de Azure dataopslagplaatsen die we gebruiken, volgt Microsoft strikte normen voor het overschrijven van opslagbronnen voordat ze opnieuw worden gebruikt, evenals de fysieke vernietiging van buiten gebruik gestelde hardware.

Data aanvragen

Wij bieden onze klanten middelen om verzoeken om data en verzoeken om het verwijderen van data van hun gasten in te willigen. We voorzien het gebruikersportaal ook van functionaliteit voor berichten waarmee onze klanten gemakkelijk met hun klanten kunnen communiceren. Als er een verzoek aan onze FG(dpo@mews.com) wordt gestuurd dat bedoeld is voor onze klanten en niet voor ons, sturen we een dergelijk verzoek door naar de juiste ontvanger.

Data van onze gebruikers

De data komt alleen handmatig in het systeem wanneer de gebruiker zijn profiel invult of bijwerkt. Of tijdens het aanmelden. Om de beste ervaring te bieden, bijvoorbeeld bij het inchecken in een nieuw hotel, kunnen onze gebruikers alle data registreren die een hotel nodig heeft voor het inchecken. Het is aan de gebruikers om te beslissen of ze hun gegevens willen delen met een bepaalde klant van ons en in welke mate.

Bovenop deze deelbare data registreren we gebruikersnamen, wachtwoorden (gehasht), middelen voor 2FA verificatie en andere details die nodig zijn voor een probleemloos gebruik van ons platform.

Wij verwerken de persoonlijke data van onze gebruikers in overeenstemming met ons privacybeleidMews .

Behoud

Vanwege de aard van het product, waarvan de belangrijkste functie is om te dienen als een persoonlijke gegevensportemonnee die op elk moment in de toekomst kan worden gebruikt om de gegevens te delen met onze klanten, worden de gegevens opgeslagen zolang de gebruiker een account bij ons heeft.

Data aanvragen

Het gebruikersportaal biedt de gebruikers al hun persoonlijke data die we opslaan en de mogelijkheid om hun profiel te verwijderen. Je kunt ook rechtstreeks contact opnemen met onze FG via dpo@mews.com.

Om de levering van onze diensten te ondersteunen, maakt Mews gebruik van dienstenleveranciers die toegang hebben tot bepaalde persoonlijke data. Een derde partij subverwerker is een dienst die wij, als gegevensverwerker, gebruiken om diensten te leveren aan onze klanten (hotels) die gegevensverantwoordelijke zijn.

We selecteren deze derde partijen zeer zorgvuldig en eisen van hen minimaal SOC 2, PCI-DSS of een andere gelijkwaardige audit/certificering voor de sector.

Voor het leveren van onze diensten schakelen we de volgende subverwerkers in:

• Residentie is afhankelijk van het Mews product en de configuratie van de gast, waarbij data wordt geconfigureerd in de Europese Unie of de Verenigde Staten (zie gedeelte Infrastructuur voor regionale details).
• Google Ierland, Ltd. - IE - Pushmeldingen, andere diensten. Data bevindt zich in de Verenigde Staten.
• SFDC Ierland, Ltd. - IE - Supportdesk, community portaal. Data bevindt zich in de Europese Unie.
• Datatrans AG - CH - Creditcard tokenisatie. Data bevindt zich in Zwitserland.
• Twilio, Inc. - VS - Mailing en sms. Data bevindt zich in de Verenigde Staten.
• Aircall SAS - FR - Cloudgebaseerd geïntegreerd bedrijfstelefoonsysteem. Data bevindt zich in de Verenigde Staten.
• OKTA, Inc. - VS - Software voor cloudgebaseerd identiteits- en toegangsbeheer. Data bevindt zich in de Europese Unie.
• Gooddata Ireland Limited - IE - Cloudgebaseerd platform voor analyses en business intelligence. Data bevindt zich in de Europese Unie.
• Cloudflare, Inc. - VS - Netwerk voor de levering van inhoud. Data bevinden zich overal ter wereld. Verkeer wordt automatisch doorgestuurd naar het dichtstbijzijnde datacenter.
• Confluent Europe LTD - UK - Cloudgebaseerd platform voor het streamen van data. Data bevindt zich in de Europese Unie.
• Intellum, Inc. - VS - Leerbeheersysteem. Data bevindt zich in de Europese Unie.
• Zuplo, Inc. - VS - API Gateway en API management. Data bevinden zich overal ter wereld. Verkeer wordt automatisch doorgestuurd naar het dichtstbijzijnde datacenter.
• Secoda Inc. - VS - Diensten op het gebied van data governance en catalogisering. Data bevindt zich in de Verenigde Staten, Singapore en Duitsland
• Smart Gift Voucher Ltd - Verenigd Koninkrijk - Dienstverlening voor de aankoop, uitgifte, inwisseling en afstemming van cadeaubonnen. Data bevindt zich in de Europese Unie en het Verenigd Koninkrijk.

In bepaalde gevallen kan Mews dienstverleners (gecertificeerde partners) inschakelen die namens Mews professionele consultatie- en implementatiediensten leveren aan specifieke klanten (hotels) die dit soort diensten afnemen van Mews. De keuze van de dienstverlener en hun locatie kan variëren op basis van beschikbaarheid en de locatie van de klant.

De lijst van Mews Affiliates is beschikbaar op https://www.mews.com/nl/affiliates

Onze benadering van certificeringen is om ze van geval tot geval en op verzoek te beoordelen. We zijn niet proactief op dit gebied, want hoewel sommige certificeringen nuttig kunnen zijn om te leren bepaalde processen te verbeteren en zekerheid kunnen bieden dat wat je doet als best practice wordt beschouwd, zien we ook dat sommige certificeringen het moeilijk hebben om gelijke tred te houden met nieuwe technologieën en moderne softwareontwikkelingspraktijken. Daarom doen we alleen certificeringen die voor ons zinvol of absoluut noodzakelijk zijn.

Je kunt al onze huidige certificeringen vinden op trust.mews.com.