Plattform-Dokumentation

Mews ist eine cloudnative, serverlose, mehrmandantenfähige SaaS-Plattform. Dies hat viele Auswirkungen auf alle Aspekte der Betriebsabläufe von Mews und auf die Erfüllung verschiedener Anforderungen und Regelkonformitäten. Es ist wichtig, Mews durch das Prisma dieser Philosophie zu betrachten, während du die anderen Bereiche dieser Dokumentation liest, denn es kann sich von traditionellen Systemen unterscheiden und einige Anforderungen oder Fragen sind nicht anwendbar, wenn man die Mews Plattform betrachtet.

Cloudnativ

Vom ersten Tag an wurde Mews für die Cloud entwickelt. Die Systemarchitektur wurde für die Installierung in der Cloud entwickelt und nutzt alle Vorteile, die dies mit sich bringt. Mews ist kein System, das für den Betrieb vor Ort entwickelt und später für die Installierung in der Cloud portiert oder angepasst wurde, was bedeutet, dass einige Prozesse oder Abläufe anders oder gar nicht ablaufen.

Serverlos

Es gibt mehrere Möglichkeiten, in einer Cloud-Umgebung zu arbeiten. Auf der einen Seite des Spektrums könntest du nur die einfachen Cloud Services wie virtuelle Maschinen nutzen und alles andere selbst in die Hand nehmen. Das hat den Vorteil, dass alle Cloud-Anbieter solche primitiven Funktionen anbieten und es daher relativ einfach ist, sie zu wechseln - obwohl du wissen musst, wie du die Server, Datenbanken usw. konfigurierst und weiter selbst wartest. Am anderen Ende des Spektrums kannst du über die Funktionen auf niedriger Ebene hinausgehen und die Cloud als Service nutzen, z. B. als Rechen- oder Speicherdienst. Auf diese Weise kümmert sich der Cloud-Anbieter um die Konfiguration und Wartung - der Nachteil ist, dass du stärker an deinen spezifischen Cloud-Anbieter gebunden wirst. Wir sind ein stolzer Partner von Microsoft und nutzen Microsoft Azure in vollem Umfang. Wir befinden uns also auf der serverlosen Seite des Spektrums. Wir nutzen Services wie Azure App Service für das Hosting von Webanwendungen sowie Azure SQL Database und Azure Storage als Speicherdienste. Deshalb betreiben wir keine virtuellen Maschinen, Webserver oder Datenbankserver selbst - dafür ist unser Cloud-Anbieter zuständig, auch nicht für die Regelkonformität und Sicherheit dieser Services. Diese Services haben ihre eigenen, von Azure definierten SLAs. Wir haben unsere Lösung so aufgebaut, dass wir ihre Services und SLAs mit unserem System kombinieren, um unsere SLAs zu garantieren. Wir verwenden dieselbe Technik, um unsere Regelkonformität, Sicherheit, Disaster Recovery und andere Aspekte zu gewährleisten, die in den weiteren Bereichen ausführlicher behandelt werden.

Multi-Tenant

Es gibt eine einzige "Produktionsinstallation" der Plattform Mews , die von allen unseren Kunden genutzt wird. Das bedeutet, dass unsere Kunden immer auf der neuesten Version der Plattform laufen, mit den gleichen Features und Funktionen, die jedem anderen auf der Plattform zur Verfügung stehen (je nach Abonnementstufe). Aus Sicht der Daten werden die Daten nicht getrennt, sondern gemeinsam gespeichert. Aus der Sicherheitsperspektive ist es eigentlich einem Single-Tenant-System sehr ähnlich. Dort müssten wir sicherstellen, dass Benutzer mit unterschiedlichen Berechtigungsstufen nur auf die Daten zugreifen können, für die sie eine Berechtigung haben. Bei mandantenfähigen Systemen kann der Mandant als eine weitere "Schicht" von Privilegien verstanden werden. Mit einer mandantenfähigen Lösung können wir Szenarien, die über das Unternehmen oder die Hotelkette hinausgehen, effektiv implementieren und ein großartiges Gästeerlebnis bieten, insbesondere im Guest Portal.

SaaS

Das Einzige, was du brauchst, um die Plattform Mews zu nutzen, sind das Internet und ein Webbrowser. Um alles andere kümmern wir uns. Wir kümmern uns um alle Aspekte, die in dieser Dokumentation behandelt werden, und wir bemühen uns, sie so gut wie möglich zu machen und uns dabei ständig weiter zu verbessern. Wir sind dafür verantwortlich, dass das System schnell ist, immer verfügbar ist, über Backups verfügt, sicher ist, allen Gesetzen entspricht, immer auf dem neuesten Stand ist, für jeden auf der ganzen Welt zugänglich ist und von einer Vielzahl von Benutzern genutzt werden kann. Kunden sind nur dann für die Führung externer Aufzeichnungen verantwortlich, wenn dies gesetzlich vorgeschrieben ist. In Frankreich sind die Kunden verpflichtet, die Steuerunterlagen für den gesetzlich vorgeschriebenen Zeitraum auf einem sicheren externen Datenträger aufzubewahren.

Wir nutzen Microsoft Azure als Cloud-Anbieter. Einige der Cloud Services sind global und verfügen über eine von Azure eingebaute Georeplikation und hohe Verfügbarkeit; andere Services sind an eine einzige Region gebunden.

Wir nutzen eine Reihe von Microsoft-Regionen:

EU-Regionen:

• Westeuropa (Niederlande).
• Nordeuropa (Irland).
• Deutschland West Mitte (Frankfurt).
• Schweden Mitte (Gävle).

US-Regionen:

• US West 3 (Arizona)
• US-Ost (Virginia)
• US East 2 (Virginia)
• US South Central (Texas)

Unsere primäre Datenbank ist ein Cluster mit hoher Verfügbarkeit in Deutschland West Central, mit Replikaten in Nordeuropa.

Technologie-Stack

Wir verwenden viele Programmiersprachen, Frameworks und Technologien. In erster Linie:

• C# und .NET im Backend
• JavaScript/TypeScript und React auf dem Frontend
• Flutter und Kotlin in mobilen Anwendungen

Umgebungen

Die Plattform Mews läuft in mehreren Instanzen, die Umgebungen genannt werden; einige davon sind öffentlich, andere sind privat:

• Produktionsumgebung
• Demoumgebung
• Entwicklungsumgebung
• Feature-Zweige Umgebungen

Als cloudnatives System dreht sich unsere Disaster-Recovery-Strategie um Datensicherungen und die Möglichkeit, diese im Falle eines Vorfalls wiederherzustellen. Alle anderen Services sind "zustandslos", was bedeutet, dass wir sie im Falle einer Katastrophe ohne Informationsverlust wiederherstellen können. Wir verlassen uns stark auf die Features, die Microsoft Azure in diesem Bereich bietet, und wir haben unsere eigenen Sicherungsstufen, die auf den Standardfunktionen von Azure aufbauen.

Azure SQL-Datenbank

Wir nutzen den Premium Tier der Azure SQL-Datenbank mit einer Replik in der sekundären geografischen Region. Dieses Setup verfügt bereits von Haus aus über mehrere Sicherungsebenen und -mechanismen, die in der Azure SQL-Datenbankdokumentation ausführlich beschrieben sind. Darüber hinaus haben wir unsere eigenen Backup-Prozesse. Alle Optionen, sowohl die eingebauten als auch unsere, werden im Folgenden beschrieben:

• In einem Rechenzentrum läuft der Service als Hochverfügbarkeits-Cluster mit zwei identischen Replikaten der Datenbank mit einer Datenlatenz von nahezu Echtzeit (wenige Millisekunden). Im Falle einer Katastrophe in der primären Datenbank greift der Service sofort auf die sekundäre Datenbank zurück. Alternativ können wir diesen Fallback auch manuell auslösen.
• Der Datenbank Service bietet Point-in-Time Restore, mit dem wir eine komplette Datenbank zu einem bestimmten Zeitpunkt bis zu 35 Tage zurück wiederherstellen können.
• Der Datenbank-Cluster in der primären Region wird auf den sekundären Hochverfügbarkeits-Cluster in der sekundären Region georepliziert. Im Falle eines Desasters in der primären Region können wir ein Failover zur sekundären Region durchführen und die sekundäre Replik zum Master befördern. Mit Auto-Failover-Gruppen können wir das schnell und zuverlässig tun.
• Wir führen täglich Snapshots der primären Datenbank durch und nutzen die Point-in-Time Restore-Funktion auf einem anderen Backup-Server. Der Backup-Server hält zwei vollständig wiederhergestellte Kopien bereit, die höchstens 24 und 48 Stunden alt sind und im Falle einer Katastrophe, die sowohl die primäre als auch die sekundäre Datenbank betrifft, sofort eingesetzt werden können. Alternativ können diese Snapshots im Falle einer teilweisen Beschädigung der Daten verwendet werden, um die Daten sofort wiederherzustellen.

Azure Speicher

Als Speicher für binäre Daten verwenden wir Azure Storage, das so konfiguriert ist, dass es geo-redundante Speichermöglichkeiten nutzt. Die Daten werden automatisch dreimal in der Primärregion und dreimal in der Sekundärregion repliziert. Das Konto verfügt außerdem über ein Feature zum sanften Löschen, das anwendungsspezifische Probleme verhindert und es uns ermöglicht, potenziell beschädigte Daten wiederherzustellen. Ähnlich wie bei der SQL-Datenbank führen wir täglich inkrementelle Backups aller Daten im Speicher durch, die im Falle einer Katastrophe, die den Primärspeicher betrifft, sofort verwendet werden können.

Kosmos DB

Wir haben Cosmos DB so konfiguriert, dass sie in mehrere Regionen repliziert wird. Cosmos DB repliziert die Daten transparent in alle Regionen, die mit unserem Konto verbunden sind, und unterstützt ein automatisches Failover im Falle eines regionalen Ausfalls. Derzeit speichern wir nur nicht geschäftskritische Daten in Cosmos DB (z.B. Protokolle) und haben daher keine zusätzliche Sicherungsschicht, die über die angebotenen Features des Services hinausgeht.

Unsere Philosophie bei der Installierung ist es, so oft wie möglich zu installieren, und je weniger Änderungen vorgenommen werden, desto besser. Der Hauptgrund dafür ist, dass wir unseren Kunden so schnell wie möglich fertige Features und Korrekturen zur Verfügung stellen können, damit sie sofort davon profitieren können. Der zweite Grund ist, Probleme bei der Installierung zu minimieren und die Untersuchung und das Rollback im Falle von Problemen zu vereinfachen. Alle unsere Installierungen verursachen keine Ausfallzeiten für den Benutzer.

Zeitpläne für die Installierung

Bei unserer Plattform handelt es sich nicht um eine einzelne Anwendung, die wir en-bloc installieren, sondern um eine Ansammlung von Systemen und Anwendungen, die zusammenarbeiten und miteinander kommunizieren und für die es einen eigenen Zeitplan zur Installierung gibt. Es gibt drei Hauptkategorien von Anwendungen mit entsprechenden Zeitplänen für die Installierung:

• Die Backend Plattform (Server) wird mindestens einmal pro Werktag installiert. Darüber hinaus können bei Bedarf Ad-hoc-Installationen für verschiedene Zwecke durchgeführt werden, z.B. für Hotfixes. Das Standardszenario ist, dass alle Änderungen (Features, Fehlerkorrekturen, Verbesserungen) kontinuierlich in der Entwicklungsumgebung installiert werden. Einmal am Tag erstellen wir automatisch einen Snapshot der Version der Entwicklungsumgebung und installieren ihn in der Demoumgebung (dies wird Feature-Freeze genannt). Am nächsten Tag, wenn es auf der Demoumgebung keine Probleme gab, wird diese Version in der Produktionsumgebung installiert. Alle Installierungen erfolgen nach und nach auf allen Instanzen und in allen Regionen. Während des Prozesses überwachen wir das System und können im Falle eines Problems den Prozess zurücksetzen.
• Webanwendungen (z. B. Commander, Distributor oder Navigator) werden unabhängig installiert, sobald eine Änderung in der Anwendung abgeschlossen ist. Das heißt, wenn ein Feature implementiert oder ein Fehler behoben wurde und die Qualitätssicherung bestanden hat, wird es sofort in der Demo und in der Produktion installiert. Das ist eine echte kontinuierliche Bereitstellung, was bedeutet, dass es an einem Tag 50 oder 0 Installierungen geben kann, je nachdem, wie viele Änderungen an diesem Tag fertiggestellt werden. Auch hier überwachen wir den Zustand der Anwendungen und sind in der Lage, jeden Prozess bei Bedarf zurückzusetzen.
• Mobile Anwendungen werden aufgrund von Überprüfungsprozessen in den Application Stores unregelmäßig installiert. Von Zeit zu Zeit, wenn wir feststellen, dass die Menge der fertigen Änderungen in der Entwicklungsversion der Anwendung angemessen groß ist, oder wenn es aus anderen Gründen notwendig ist, veröffentlichen wir eine neue Version der Anwendung. Sie wird dann im jeweiligen Application Store veröffentlicht, wo sie den Verifizierungsprozess durchläuft. Nach einiger Zeit (Stunden oder Tage) erreicht die neue Version die Geräte der Benutzer.

Wir reservieren uns die Möglichkeit von geplanten Ausfallzeiten, die für Systemänderungen notwendig sind, obwohl wir bestrebt sind, diese Möglichkeit nie zu nutzen. Bisher mussten wir es nur einmal im Jahr 2013 nutzen, als wir unseren Cloud-Anbieter von AppHarbor zu Microsoft Azure migriert haben. Seitdem hatten wir keine geplante Ausfallzeit mehr.

Freigabeprozess

Es ist wichtig, zwischen Installierung und Freigabe zu unterscheiden. Die Installierung ist der Zeitpunkt, an dem die Änderung die Produktion erreicht. Die Änderung muss jedoch nicht unbedingt für alle Kunden verfügbar sein. Der Moment, in dem die Änderung für einen Kunden verfügbar ist, wird als Freigabe bezeichnet. Kleinere Änderungen, Fehlerbehebungen, Verbesserungen oder andere unkritische Dinge werden an alle unsere Kunden weitergegeben, sobald sie installiert sind. Bei größeren oder kritischen Änderungen halten wir uns jedoch an den folgenden 4-stufigen Freigabeprozess:

1. 1. Internes Alpha: Die Änderung ist nur für die Mitarbeiter von Mews freigegeben. Wir verwenden Mews auch intern, daher sind wir die "Kanarienvögel", die die Änderung testen.
2. 2. Private Beta: Die Änderung wird für eine ausgewählte Untergruppe von Kunden freigegeben, die Early-Adopter-Gruppen bilden. Wenn die Änderung für jemanden besonders wichtig ist, der an der Produktentwicklung und -bereitstellung beteiligt war, kann er auch in die private Beta einbezogen werden. Für diesen Schritt und auch für das interne Alpha verwenden wir LaunchDarkly, um die betroffenen Kunden zu verwalten.
3. 3. Öffentliche Beta: Die Änderung wird für alle freigegeben, die sich für die Änderung entscheiden. Normalerweise führen wir in den Einstellungen eine Option ein, die es jedem erlaubt, die Änderung zu übernehmen.
4. 4. Allgemeine Verfügbarkeit: Die Änderung ist für alle unsere Kunden freigegeben.

Bei allen Arten von Problemen, einschließlich Vorfällen, Sicherheitsvorfällen, Fehlern, Untersuchungen oder Überwachungswarnungen, folgen wir einem strengen Lösungsprozess. Der Prozess ist in unserer internen Wissensdatenbank dokumentiert. Jedes Problem, unabhängig vom Schweregrad, wird einem Team zugewiesen und sofort über einen internen Slack Channel an das Team weitergeleitet.

Für Probleme, die erhebliche Auswirkungen auf den Kunden haben, gibt es einen zusätzlichen Eskalationsprozess, um sicherzustellen, dass sie schnellstmöglich gelöst werden. Solche Vorfälle werden in einem firmenweiten Channel kommuniziert und regelmäßig an interne und externe Stakeholder weitergeleitet.

Nach der Lösung führt das Team eine Ursachenanalyse durch, entwickelt Lösungen und veröffentlicht das Postmortem-Dokument. Die Lösungen, die sich aus dem Postmortem ergeben, werden innerhalb einer von unserer internen SLO festgelegten Frist implementiert.

Die Plattform Mews arbeitet mit sehr sensiblen Daten der Kunden, daher sind Sicherheit und Datenschutz nicht verhandelbare Elemente des Systems. Unser allgemeiner Ansatz in diesem Bereich ist, dass sich nichts auf die Menschen oder ihr Wissen verlassen sollte. Alle unsere Sicherheitsmaßnahmen und internen Prozesse sind so konzipiert. Unsere Entwickler werden zwar regelmäßig in den besten Praktiken zur sicheren Programmierung geschult, aber wir verlassen uns bei der Sicherheit nicht ausschließlich darauf. Unsere Prozesse und Frameworks sind so konzipiert, dass sie die Entstehung von Sicherheitsfehlern verhindern oder es einem Entwickler zumindest extrem schwer machen, Sicherheitsprobleme in unser System einzubringen, wenn es technisch nicht möglich ist, sie vollständig zu verhindern. Dies spiegelt sich in unserem Prozess zur Lösung von Sicherheitsproblemen wider, der weiter unten beschrieben wird. Unsere Sicherheitsstrategie wird von zwei Hauptprinzipien bestimmt:

1. 1. Minimierung der Angriffsfläche, Reduzierung des Umfangs und der Komplexität.
2. 2. Kontinuierliche Penetrationstests der Angriffsoberfläche mit umfassender und gründlicher Beseitigung aller Ergebnisse.

Neben diesen proaktiven Maßnahmen unterziehen wir uns häufig Audits, Zertifizierungen, Due-Diligence-Prozessen und Pen-Tests durch externe Firmen, die entweder von uns (z. B. PCI-DSS, ISO) oder von unseren potentiellen Kunden beauftragt wurden.

Minimierung der Angriffsfläche

Der beste Weg, Sicherheitsprobleme zu vermeiden, ist, sie von vornherein auszuschließen. Dies entspricht unserer serverlosen Philosophie: Wir haben keine Kontrolle über Hardware, Managementsysteme, Webserver oder Datenbankserver. Wir sind nicht in der Lage, eines dieser Systeme falsch zu konfigurieren oder zu vergessen, Sicherheits-Patches aufzuspielen usw. - Dafür ist Azure zuständig, das über große Sicherheitsteams verfügt. Wir verwenden eine sehr begrenzte Konfiguration der Azure Services, für die es Optionen gibt, um einige zusätzliche Sicherheitsfeatures zu aktivieren. Um sicherzustellen, dass wir nichts davon verpassen, nutzen wir den Azure Security Advisor, der uns über alle diese Optionen informiert, zum Beispiel wenn Azure neue Features einführt, die die Sicherheit unserer Systeme erhöhen könnten. Dank all der oben genannten Punkte wird unsere Angriffsfläche (aus der Systemperspektive) effektiv auf den von uns entwickelten Anwendungscode reduziert. Weitere Informationen zu den Sicherheitsfunktionen von Azure findest du in der Dokumentation zu den Sicherheitsgrundlagen von Azure.

Kontinuierliche Penetrationstests

Wie bereits erwähnt, liegt unser Hauptaugenmerk auf der Sicherheit auf Anwendungsebene. Um sicherzustellen, dass unser System sicher ist, unterziehen wir uns kontinuierlich Penetrationstests durch cobalt.io. Zu jedem Zeitpunkt wird ein Teil unseres Systems oder eines Produkts mit einem Stift getestet und wir stellen sicher, dass die gesamte Oberfläche kontinuierlich mit Tests abgedeckt wird.

Es gibt verschiedene Ansätze, wie Sicherheitslücken geschlossen werden können. Wir sind stolz auf unseren Ansatz und gehen jedes Sicherheitsproblem post-mortem an, d.h. wir führen eine detaillierte Ursachenanalyse durch und lösen dann nicht nur den einzelnen Fall, sondern alle ähnlichen Fälle in allen unseren Produkten. Darüber hinaus haben wir Maßnahmen ergriffen, die verhindern, dass solche Probleme in Zukunft wieder auftreten. Wenn zum Beispiel ein Problem in einer unserer APIs gefunden wird, aktualisieren wir unser API-Framework so, dass es das Problem in allen unseren APIs beseitigt. Oder wir implementieren einen statischen Code-Analyzer, der den Fehler in unserer Codebasis automatisch eincheckt, ebenso wie den neuen Code, den wir produzieren. Auch wenn jeweils nur ein Produkt getestet wird, wenden wir unsere Erkenntnisse auf alle Produkte an. Weitere Informationen findest du im Bereich "Vorfälle".

Technische Sicherheitsmaßnahmen

Aus technischer Sicht gibt es eine Menge Dinge, die wir tun, um die Sicherheit nicht nur der Plattform selbst, sondern auch unserer Kunden zu gewährleisten. Hier sind einige von ihnen:

• Die Daten werden bei der Übertragung verschlüsselt, wir setzen mindestens TLS 1.2 ein und erreichenim Qualys SSL Labs Test eine A+Rate.
• Die Daten in allen von uns genutzten Speichermedien werden im Ruhezustand verschlüsselt.
• Wir verwenden mehrere Ebenen von internen Systemprotokollen und stellen unseren Kunden innerhalb der Plattform Audit-Protokolle zur Verfügung.
• Wir führen regelmäßig ASV-Scans, interne und externe Schwachstellen-Scans durch.
• Alle unsere Geräte sind durch Anti-Virus/Anti-Malware-Software geschützt und werden durch MDM-Lösungen zentral verwaltet.
• Wir setzen strenge Passwortrichtlinien durch, verwenden 1Password und erzwingen MFA in allen internen Systemen, die diese Funktion anbieten.
• Wir nutzen Azure Active Directory und SSO für alle internen Systeme, die diese Funktion anbieten.
• Wir folgen dem Prinzip des geringsten Privilegs für alle unsere internen Systeme.
• Unsere Plattform unterstützt MFA und erzwingt starke Passwörter für unsere Benutzer.
• Die Passwörter der Benutzer werden mit bcrypt gehasht und niemals im Klartext gespeichert.
• Alle sensiblen Benutzerschlüssel und Token, die für die Authentifizierung von Drittanbietern verwendet werden müssen (wie FTP-Passwörter), werden in Azure SQL Database verschlüsselt.
• Alle sensiblen Mews Schlüssel und Tokenisierungen werden in der Konfiguration verschlüsselt.

Sicherheitsmaßnahmen für Menschen

• Wir führen für alle Bewerber/innen in sensiblen Rollen, die wir einstellen wollen, Hintergrundüberprüfungen durch. Der Umfang und die Gründlichkeit dieser Überprüfungen hängen von der Rolle und dem Dienstalter des Bewerbers ab.
• Die Verträge mit allen unseren Mitarbeitern enthalten Vertraulichkeitsklauseln und die Mitarbeiter sind verpflichtet, die internen Regeln zur Verarbeitung personenbezogener Daten zu befolgen.
• Alle Mitarbeiter nehmen an einer Einführungsschulung teil, die verpflichtende Sicherheits- und Datenschutzschulungen beinhaltet.
• Alle Mitarbeiter nutzen 1Password und generieren ihr Master-Passwort mit Diceware.
• Alle Mitglieder der technischen Abteilung (Entwickler, Datenanalysten, Qualitätssicherung, IT) nehmen mindestens einmal jährlich an einer obligatorischen Sicherheitsschulung teil.

Daten der Zahlungskarte

Ein gutes Beispiel für die Verringerung der Angriffsfläche ist unser Umgang mit sensiblen Daten von Zahlungskarten. Mews verwendet PCI Proxy als Anbieter für die Tokenisierung von Karten. Sensible Daten wie Kartennummer oder CVV erreichen unsere Infrastruktur nicht einmal. Betrachten wir als Beispiel einen einfachen Ablauf, bei dem Kartendaten von einem Drittanbieter (z.B. einem Channel für Buchungen) empfangen und dann abgebucht werden:

1. 1. Wenn Drittanbieter Kartendaten an uns senden müssen, steuern sie die Anfrage nicht wie üblich direkt an uns, sondern leiten sie an PCI Proxy weiter.
2. 2. PCI Proxy empfängt die Anfrage, erkennt die Kartendaten, speichert sie und ersetzt sie durch Token, die nicht mehr sensibel sind. Dieser Teil wird Tokenisierung genannt.
3. 3. PCI Proxy leitet die Anfrage, die nun Token enthält, an uns weiter.
4. 4. Wir speichern das Token in unserer Datenbank.
5. 5. Um die Karte abzubuchen, erstellen wir eine Zahlungsanforderung für das Zahlungsgateway. Anstatt jedoch direkt die Daten der Karte zu verwenden (die wir nicht haben), nutzen wir Token. Und anstatt die Anfrage direkt an das Zahlungsgateway zu senden, leiten wir sie an den PCI Proxy weiter.
6. 6. PCI Proxy empfängt die Anfrage von uns, erkennt die Token dort und ersetzt sie durch die sensiblen Kartendaten. Dieser Teil wird Detokenization genannt.
7. 7. PCI Proxy leitet die Anfrage, die nun sensible Daten enthält, an das Zahlungsgateway weiter.

Viele Arten von Angriffen werden nutzlos gemacht, weil unsere Datenspeicher die sensiblen Daten nicht enthalten.

Um auf die PCI DSS Shared Responsibility Matrix zuzugreifen, navigiere bitte zum Bereich "Dokumente" auf unserer Trust.mews.com Plattform. Von dort aus kannst du direkt die PCI DSS-Matrix anfordern.

Mews Plattform verarbeitet personenbezogene und andere Arten von sensiblen Daten, aber wir sind kein reiner Auftragsverarbeiter-SaaS-Service. Um alle Datenflüsse zu verstehen, ist es daher wichtig, die beiden Rollen zu unterscheiden, die Mews einnimmt:

Auftragsverarbeiter: In der Beziehung zwischen unseren Kunden (Hotels) und uns sind wir Auftragsverarbeiter für alle ihre Daten, die auf die Plattform gelangen, einschließlich der personenbezogenen Daten ihrer Kunden. Dies ist ein Teil des Services, den wir unseren Kunden bieten.

Verantwortlicher: In der Beziehung zwischen unseren Benutzern (Einzelpersonen) und uns sind wir der Verantwortliche für ihre personenbezogenen Daten - wir stellen unseren Benutzern einen "Travel Wallet" Service und andere Anwendungen zur Verfügung.

Diese beiden Rollen und Betriebsabläufe von Mews sind streng voneinander getrennt, und die Daten werden niemals vermischt. Und da wir eine mandantenfähige Lösung sind, kann eine einzelne natürliche Person ihre persönlichen Daten in N+1 Kopien auf der Plattform Mews haben. Wenn die Person mit N unserer Kunden interagiert hat (z.B. Reservierungen in N verschiedenen Hotels hatte), dann werden N Kundenkonten gespeichert, und Mews ist dort der Auftragsverarbeiter. Das "+1" stellt eine weitere Kopie der persönlichen Daten dar, die gespeichert werden, wenn sich die Person als Benutzer auf Mews anmeldet, um den "Travel Wallet" Service zu nutzen. Für diese einzige Kopie ist Mews der Verantwortliche für die Daten. Wir haben keine Vereinbarung über eine gemeinsame Beherrschung.

Alle Arten von Daten werden in unserem Azure-Datenspeicher gespeichert, wie im Bereich Infrastruktur dieser Dokumentation beschrieben. Wir archivieren die Daten nicht und die Backups werden nur für einen begrenzten Zeitraum aufbewahrt.

Daten unserer Kunden

Die Daten gelangen entweder manuell durch einen Mitarbeiter unseres Kunden in das System oder werden von dessen Kunden sowohl direkt (durch die Weitergabe von Travel Wallet an den Kunden) als auch indirekt, z.B. über Buchungskanäle und unsere APIs, bereitgestellt. Bei den Daten handelt es sich um persönliche Daten der Kunden unserer Kunden, die meist Reisende aus aller Welt sind.

Unsere Kunden können verschiedene Daten über ihre Kunden erfassen, wie z.B. Vorname, Nachname, Nachname, Geburtsdatum, Staatsangehörigkeit, Ausweisdokumente (Reisepass, Personalausweis, Führerschein, Visa), Adressen, E-Mail-Adressen, Telefonnummern, etc. Die Daten der Zahlungskarten werden ebenfalls erfasst, sind aber weder für den Kunden noch für uns direkt zugänglich. Weitere Informationen findest du im Bereich Sicherheit in dieser Dokumentation.

Verarbeitung

Wir verarbeiten personenbezogene Daten in Übereinstimmung mit dem Zusatz zur Datenverarbeitung, den wir mit unseren Kunden unterzeichnen. Wir können auf die Daten zugreifen, wenn dies zur Erbringung unseres Services notwendig ist (z. B. um Fehler zu untersuchen oder unseren Kunden auf andere Weise zu helfen). Wir können die Daten für interne statistische und analytische Zwecke verwenden; sie werden jedoch immer anonymisiert und wir halten uns an die vertraglichen Verpflichtungen. Im Bereich Unterauftragsverarbeiter findest du eine Liste der Firmen, die als Unterauftragsverarbeiter der Daten des Kunden oder einer Teilmenge der Daten des Kunden fungieren.

Rückhaltung

Wir speichern personenbezogene Daten so lange, wie es für den Zweck, für den sie bereitgestellt oder erhoben wurden, erforderlich ist. Da wir der Auftragsverarbeiter sind, wenn es um personenbezogene Daten geht, die unsere Kunden (die Verantwortlichen) sammeln, sind wir in Bezug auf den Umgang mit den Daten an ihre Weisungen gebunden. Es liegt in der Verantwortung des Kunden, dafür zu sorgen, dass die Aufbewahrungsfristen für personenbezogene Daten rechtskonform sind. Um unseren Kunden die Möglichkeit zu geben, die Aufbewahrungsfristen zu verwalten, bieten wir unseren Kunden folgende Optionen an:

• Lösche manuell das komplette Kundenprofil und die dort gespeicherten persönlichen Daten. Dies wirkt sich auf alle oben aufgeführten Datenpunkte aus, und alle Daten werden hart gelöscht.
• Richte eine automatische Bereinigung von Kundenprofilen nach einem bestimmten Zeitraum ohne Nutzung ein. In diesem Fall führt das System aus, was sonst mit der ersten Option manuell erledigt werden müsste.

Für Zahlungsdaten können unsere Kunden einfach den Zeitraum in Tagen festlegen, nach dem die Zahlungskartendaten des Kunden automatisch gelöscht werden. Dabei handelt es sich um einen automatischen Prozess, der alle Daten im Anhang des Gastprofils löscht. Clearing bedeutet, dass Mews das Token der Karte nicht behält und PCI Proxy keine Informationen über diese Karte hat. Wenn der Prozess eingerichtet ist, löscht das System alle Token aus der Datenbank Mews und die Karte aus dem PCI Proxy wird gelöscht.

Wenn wir Daten aus einem der von uns genutzten Azure-Datenspeicher löschen, befolgt Microsoft strenge Standards für das Überschreiben von Speicherressourcen vor ihrer Wiederverwendung sowie für die physische Zerstörung der außer Betrieb genommenen Hardware.

Datenanfragen

Wir stellen unseren Kunden Mittel zur Verfügung, um Datenanfragen und Datenlöschungsanträge ihrer Kunden zu erfüllen. Außerdem stellen wir dem Benutzerportal eine Messaging Funktion zur Verfügung, die es unseren Kunden ermöglicht, einfach mit ihren Kunden zu kommunizieren. Falls eine Anfrage an unseren Datenschutzbeauftragten(dpo@mews.com) für unsere Kunden und nicht für uns bestimmt ist, leiten wir sie an den richtigen Empfänger weiter.

Daten unserer Benutzer

Die Daten werden nur manuell in das System eingegeben, wenn der Benutzer sein Profil ausfüllt oder aktualisiert. Oder während der Anmeldung. Um das beste Erlebnis zu bieten, z.B. beim Einchecken in ein neues Hotel, können unsere Benutzer alle Daten erfassen, die ein Hotel für den Check-in benötigt. Die Benutzer entscheiden selbst, ob und in welchem Umfang sie ihre Daten mit einem bestimmten Kunden von uns teilen möchten.

Zusätzlich zu diesen gemeinsam nutzbaren Daten erfassen wir Benutzernamen, Passwörter (gehasht), Mittel zur Zwei-Faktor-Authentifizierung (2FA) und andere Details, die für eine reibungslose Nutzung unserer Plattform notwendig sind.

Wir verarbeiten die personenbezogenen Daten unserer Benutzer in Übereinstimmung mit unserer Mews Datenschutzerklärung.

Rückhaltung

Aufgrund der Beschaffenheit des Produkts, dessen Hauptfunktion darin besteht, als persönliche Daten-Wallet zu dienen, die jederzeit in der Zukunft genutzt werden kann, um die Daten mit unseren Kunden zu teilen, werden die Daten so lange gespeichert, wie der Benutzer ein Konto bei uns hat.

Datenanfragen

Das Benutzerportal bietet den Benutzern alle persönlichen Daten, die wir speichern, und die Möglichkeit, ihr Profil zu löschen. Du kannst dich auch direkt an unseren Datenschutzbeauftragten wenden: dpo@mews.com.

Um die Bereitstellung unserer Services zu unterstützen, bindet Mews Service-Anbieter ein und nutzt sie, die Zugang zu bestimmten personenbezogenen Daten haben. Ein Drittanbieter als Unterauftragsverarbeiter ist ein Service, den wir als Auftragsverarbeiter nutzen, um unseren Kunden (Hotels), die für die Daten verantwortlich sind, Services zu liefern.

Wir wählen diese Drittanbieter-Auftragsverarbeiter sehr sorgfältig aus und verlangen von ihnen mindestens SOC 2, PCI-DSS oder eine andere gleichwertige Prüfung/Zertifizierung.

Für die Erbringung unserer Services beauftragen wir die folgenden Unterauftragsverarbeiter:

• Der Wohnsitz hängt vom Mews Produkt und der Konfiguration des Kunden ab, wobei die Daten entweder in der Europäischen Union oder in den USA gehostet werden (siehe Bereich Infrastruktur für regionale Details).
• Google Ireland, Ltd. - IE - Push-Benachrichtigungen, andere Services. Die Daten befinden sich in den Vereinigten Staaten.
• SFDC Irland, Ltd. - IE - Support Desk, Community Portal. Die Daten befinden sich in der Europäischen Union.
• Datatrans AG - CH - Tokenisierung von Kreditkarten. Die Daten befinden sich in der Schweiz.
• Twilio, Inc. - US - Mailing und Textnachrichten. Die Daten befinden sich in den Vereinigten Staaten.
• Aircall SAS - FR - Cloud-basiertes integriertes Business-Telefonsystem. Die Daten befinden sich in den Vereinigten Staaten.
• OKTA, Inc. - US - Cloud-basierte Software für Identitäts- und Zugangsmanagement. Die Daten befinden sich in der Europäischen Union.
• Gooddata Ireland Limited - IE - Cloud-basierte Plattform für Analytics und Business Intelligence. Die Daten befinden sich in der Europäischen Union.
• Cloudflare, Inc. - US - Content Delivery Network. Die Daten sind auf der ganzen Welt verteilt. Der Datenverkehr wird automatisch an das nächstgelegene Datenzentrum weitergeleitet.
• Confluent Europe LTD - UK - Cloud-basierte Plattform für das Streamen von Daten. Die Daten befinden sich in der Europäischen Union.
• Intellum, Inc. - US - Lernmanagementsystem. Die Daten befinden sich in der Europäischen Union.
• Zuplo, Inc. - US - API Gateway und API Management. Die Daten sind auf der ganzen Welt verteilt. Der Datenverkehr wird automatisch an das nächstgelegene Datenzentrum weitergeleitet.
• Secoda Inc. - US - Services für die Verwaltung und Katalogisierung von Daten. Die Daten befinden sich in den Vereinigten Staaten, Singapur und Deutschland
• Smart Gift Voucher Ltd - UK - Bereitstellung eines Services für den Kauf, die Ausgabe, die Einlösung und den Abgleich von Promocodes. Die Daten befinden sich in der Europäischen Union und im Vereinigten Königreich.

In bestimmten Fällen kann Mews Dienstleister (zertifizierte Partner) beauftragen, die im Namen von Mews professionelle Beratungs- und Installierungsservices für bestimmte Kunden (Hotels) anbieten, die diese Art von Services von Mews erwerben. Die Wahl des Service-Anbieters und dessen Standort kann je nach Verfügbarkeit und Standort des Kunden variieren.

Die Liste der Mews Affiliates findest du unter https://www.mews.com/de/affiliates

Unser Ansatz für Zertifizierungen ist es, sie von Fall zu Fall und nach Bedarf zu beurteilen. Wir sind in diesem Bereich nicht proaktiv, denn obwohl einige Zertifizierungen hilfreich sein können, um zu lernen, bestimmte Prozesse zu verbessern, und die Gewissheit geben, dass das, was du tust, als Best Practice gilt, sehen wir auch, dass einige Zertifizierungen es schwer haben, mit neuen Technologien und modernen Softwareentwicklungsverfahren Schritt zu halten. Deshalb machen wir nur die Zertifizierungen, die für uns Sinn machen oder die für uns absolut notwendig sind.

Alle unsere aktuellen Zertifizierungen findest du unter trust.mews.com.