Plattform-Dokumentation

Funktionen sind wichtig, aber ebenso die Integrität der Plattform, die Sie nutzen. Leistung, Verfügbarkeit und Sicherheit sind von entscheidender Bedeutung. Deshalb haben wir einige wichtige Informationen über die Mews-Plattform zusammengestellt.

For your convenience, we have provided a German translation of this page. This translation is for informational purposes only and is currently being updated. The definitive version of this page is the English version.

Inhalt

zurück

exit icon

Philosophie

Mews ist eine Cloud-native, serverlose, Multi-Tenant-SaaS-Plattform. Dies wirkt sich in vielerlei Hinsicht auf alle Aspekte der Arbeitsweise von Mews und auf dessen Art der Erfüllung verschiedener Auflagen und Compliance-Anforderungen aus. Es ist wichtig, beim Lesen anderer Abschnitte dieser Dokumentation Mews aus philosophischer Perspektive zu betrachten, da Unterschiede zu traditionelleren Systemen bestehen können und einige Anforderungen oder Fragen bei der Betrachtung der Mews-Plattform nicht anwendbar sind.
 

Cloud-nativ

 
Vom ersten Tag an wurde Mews für die Cloud entwickelt. Die Systemarchitektur wurde für den Cloud-Bereitstellung konzipiert und macht sich alle damit verbundenen Vorteile zu Nutze. Mews ist kein System, das für den Betrieb vor Ort entwickelt und später für die Cloud-Bereitstellung portiert oder angepasst wurde, was bedeutet, dass einige Prozesse oder Verfahren anders oder gar nicht funktionieren.
 

Serverlos

 
Es gibt mehrere Möglichkeiten, in einer Cloud-Umgebung zu arbeiten. An einem Ende des Spektrums könnten Sie nur die einfachen Cloud-Dienste wie Virtual Machines nutzen und alles andere selbst erledigen. Der Vorteil dabei ist, dass alle Cloud-Anbieter solche primitiven Funktionen anbieten und ein Anbieterwechsel demzufolge recht einfach ist – obwohl ein gewisses Know-how erforderlich ist, um die Server, Datenbanken usw. zu konfigurieren und kontinuierlich selbst zu warten.
 
Am anderen Ende des Spektrums könnten Sie über die einfache Funktionalität hinausgehen und die Cloud beispielsweise für Rechen- oder Speicherdienste nutzen. Auf diese Weise kümmert sich der Cloud-Anbieter um die Konfiguration und Wartung. Der Nachteil ist, dass Sie stärker an Ihren spezifischen Cloud-Anbieter gebunden sind.
 
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 Dienste wie Azure App Service für Web-Application-Hosting sowie Azure SQL Database und Azure Storage als Speicherdienste. Daher betreiben wir selbst keine Virtual Machines, Web- oder Datenbankserver. Dafür und für die Einhaltung der Vorschriften und die Sicherheit solcher Dienste ist unser Cloud-Anbieter zuständig.
 
Diese Dienste haben ihre eigenen, von Azure festgelegten SLAs. Darauf basiert unsere Lösung. Wir haben ihre Dienste und SLAs mit unserem System kombiniert, um unsere SLAs zu garantieren. Wir verwenden dieselbe Technik, um unsere Compliance, Sicherheit, die Wiederherstellung im Notfall (Disaster Recovery) und andere Aspekte zu gewährleisten, auf die in weiteren Abschnitten näher eingegangen wird.
 

Multi-Tenant


Es gibt eine einzige Produktions-„Installation“ der Mews-Plattform, die von allen unseren Kunden genutzt wird. Das bedeutet, dass unsere Kunden immer mit der neuesten Version der Plattform, mit den gleichen Funktionen und dem gleichen Funktionsumfang wie alle anderen Nutzer der Plattform (je nach Abonnement-Ebene) arbeiten. Aus Datenperspektive sind die Daten nicht getrennt, sondern werden gemeinsam gespeichert.
Aus Sicherheitsperspektive ähnelt es sehr stark einem Single-Tenant-System. Dort müssten wir sicherstellen, dass Nutzer mit unterschiedlichen Berechtigungsstufen nur auf die Daten zugreifen können, für die sie eine Zugangsberechtigung haben. In Multi-Tenant-Systemen kann der Tenant als eine weitere „Ebene“ von Privilegien verstanden werden. Mit einer Multi-Tenant-Lösung können wir effektiv unternehmens- oder kettenübergreifende Szenarien implementieren und insbesondere im Gästeportal ein großartiges Gästeerlebnis bieten.

SaaS


Um die Mews-Plattform nutzen zu können, brauchen Sie lediglich das Internet und einen Webbrowser. Um alles andere kümmern wir uns. Wir kümmern uns um alle Aspekte, die in dieser Dokumentation behandelt werden, und sind bestrebt, sie so gut wie möglich umzusetzen und uns gleichzeitig kontinuierlich zu verbessern. Es liegt in unserer Verantwortung, dafür zu sorgen, dass das System schnell ist, immer zur Verfügung steht, über Sicherungskopien verfügt, sicher ist, allen Rechtsvorschriften entspricht, immer auf dem neuesten Stand ist, für jedermann auf der ganzen Welt zugänglich ist und von einem breiten Spektrum von Nutzern verwendet werden kann.
 
Die Kunden sind nur dann zur Führung externer Aufzeichnungen verpflichtet, wenn dies gesetzlich vorgeschrieben ist. In Frankreich sind die Kunden verpflichtet, die Steuerunterlagen während des gesetzlich vorgeschriebenen Zeitraums auf einem sicheren externen physischen Datenträger aufzubewahren.

Infrastruktur

Wir verwenden Microsoft Azure als Cloud-Anbieter und nutzen die folgenden Dienste:
  • Azure SQL Database für die Speicherung von relationalen Daten
  • Azure Storage für die Speicherung von Binärdaten und Systemressourcen
  • Azure Cosmos DB für die Speicherung von nicht-relationalen Daten
  • Azure Cache für Redis (Remote-Wörterbuchserver) als Cache-Speicher
  • Azure App Service für Application Hosting
  • Azure DNS für Domain-Management
  • Azure CDN als Content Delivery Network für Bilder und andere Ressourcen
  • Azure Traffic Manager für DNS-basierte Lastverteilung
  • Azure Application Gateway für Weiterleitung
  • Azure Automation für Prozessautomatisierung
  • Azure Application Insights für Telemetrie
  • Azure Cognitive Services für KI-Dienste
Einige dieser Dienste sind multinational ausgerichtet und verfügen über eine von Azure eingebaute Georeplikation und hohe Verfügbarkeit; andere sind an eine einzige Region gebunden. Wir haben zwei Regionen, die voll funktionsfähig sind: die primäre Region in Westeuropa (Niederlande) und die sekundäre Region in Nordeuropa (Irland). Unsere primäre Datenbank ist ein Hochverfügbarkeitscluster im primären Rechenzentrum, mit Replikaten in der sekundären Region. Wir haben App Services, SQL-Datenbanken, Redis-Caches und Cosmos DB in beiden Rechenzentren. Die restlichen Dienste werden gemeinsam genutzt.
 

Andere Dienste

 
Darüber hinaus nutzen wir andere Dienste Dritter für verschiedene Zwecke:
Rapid7 insightOps für die Protokollierung
  • Sentry für Fehlermeldungen
  • NewRelic für Leistungsüberwachung
  • PagerDuty für Vorfallsmanagement
  • Firebase für Push-Benachrichtigungen
  • Namecheap für Domainregistrierung.
  • PCI Proxy als Kartentokenisierungsdienst
  • Twilio als Anbieter von Textnachrichten
  • Twilio Sendgrid als Anbieter von E-Mail-Diensten
  • Google Analytics für Analysen des Nutzerverhaltens
  • Hotjar für Analysen des Nutzerverhaltens
  • GitHub als Programm zur Quellcodeverwaltung
  • Azure DevOps als kontinuierliche Integrationspipeline
  • Zapier für Systemintegration
  • Browserstack als Testwerkzeug
  • Statusseite für öffentliche Systemstatusinformationen

Technologiepaket

 
Als Programmiersprachen verwenden wir C# und .NET im Backend, JavaScript/TypeScript und React im Frontend sowie Flutter und Kotlin für mobile Anwendungen. Darüber hinaus verwenden wir viele Open-Source-Bibliotheken, Frameworks und andere Programmiersprachen und Technologien. Die vollständige Liste wird ständig weiterentwickelt, und Sie können einen vollständigen, aktuellen Technologiepaket mit all unseren Diensten, Infrastrukturen, Tools, Sprachen usw. auf unserem StackShare einsehen.
 

Umgebungen

 

Die Mews-Plattform läuft in mehreren Instanzen, die als Umgebungen bezeichnet werden; einige von ihnen sind öffentlich, andere sind privat:

Wiederherstellung im Notfall (Disaster Recovery)

Unsere Disaster-Recovery-Strategie ist ein Cloud-natives System, dessen Schwerpunkt auf Datensicherungen und im Falle eines Vorfalls auf der Wiederherstellung dieser Daten liegt. Alle anderen Dienste sind „zustandslos“, was bedeutet, dass wir sie im Falle eines Notfalls ohne Informationsverlust wiederherstellen können. Wir verlassen uns stark auf die Funktionen, die Microsoft Azure in diesem Bereich bietet, und wir haben unsere eigenen Sicherungsstufen, die auf den Standardfunktionen von Azure aufbauen.
 

Azure SQL-Datenbank

 

Wir verwenden die Premium-Stufe der Azure SQL-Datenbank mit einer Replik in der sekundären geografischen Region. Diese Konfiguration verfügt bereits über mehrere sofort einsatzbereite Sicherungsstufen und -mechanismen, die in der Dokumentation zur Azure SQL-Datenbank ausführlich beschrieben sind. Darüber hinaus haben wir unsere eigenen Sicherungsprozesse. Alle Optionen, sowohl die vorinstallierten als auch unsere eigenen, sind im Folgenden beschrieben:
  • Innerhalb eines Rechenzentrums wird der Datenbankdienst als Hochverfügbarkeitscluster aus zwei identischen Replikaten der Datenbank mit nahezu Echtzeit-Datenlatenz (wenige Millisekunden) ausgeführt. Im Falle eines Notfalls in der primären Datenbank greift der Dienst sofort auf die sekundäre Datenbank zurück. Alternativ können wir diesen Rückgriff auch manuell auslösen.
  • Der Datenbankdienst bietet eine Point-in-Time-Wiederherstellung, mit der wir eine komplette Datenbank zu einem bestimmten Zeitpunkt bis zu 35 Tage zurück wiederherstellen können.
  • Der Datenbankcluster in der primären Region wird auf den sekundären Hochverfügbarkeitscluster in der sekundären Region georepliziert. In Notfallsituationen in der primären Region können wir eine Ausfallsicherung (Failover) zur sekundären Region durchführen und die sekundäre Replik zur primären Region erheben. Mit Auto-Failover-Gruppen können wir das schnell und zuverlässig erledigen.
  • Wir führen täglich Snapshots der primären Datenbank durch, indem wir die Point-in-Time-Wiederherstellungsfunktion auf einem anderen Backup-Server nutzen. Auf dem Backup-Server befinden sich zwei vollständig wiederhergestellte Kopien, die höchstens 24 und 48 Stunden alt sind. In einer Notfallsituation, die sowohl die primäre als auch die sekundäre Datenbank betrifft, können diese Kopien sofort verwendet werden. Alternativ können diese Snapshots im Falle einer teilweisen Datenbeschädigung zur sofortigen Wiederherstellung der Daten verwendet werden.

Azure Storage

Als Speicher für Binärdaten verwenden wir Azure Storage, dessen Konfiguration die Verwendung geo-redundanter Speichermöglichkeiten ermöglicht. Die Daten werden sowohl in der primären Region als auch in der sekundären Region jeweils dreimal automatisch repliziert. Das Speicherkonto verfügt außerdem über eine Soft-Delete-Funktion, die anwendungsspezifische Probleme verhindert und die Wiederherstellung möglicherweise beschädigter Daten ermöglicht. Ähnlich wie bei der SQL-Datenbank führen wir täglich inkrementelle Sicherungskopien aller Daten im Speicher auf einem Sicherungskopienspeicher durch, der bei einem Notfall, der den primären Speicher betrifft, sofort genutzt werden kann.

Cosmos DB

Wir haben Cosmos DB so konfiguriert, dass es 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 in Cosmos DB nur nicht geschäftskritische Daten (z. B. Protokolle) und haben daher keine zusätzliche Sicherungsebene, die auf den angebotenen Funktionen des Dienstes aufbaut.

Bereitstellung

In Bezug auf Bereitstellungen folgen wir unserer Philosophie, so oft wie möglich bereitzustellen. Dabei gilt: Je kleiner der bereitgestellte Änderungssatz ist, desto besser. Der Hauptgrund dafür ist, dass wir unseren Kunden so schnell wie möglich fertige Funktionen und Korrekturen zur Verfügung stellen können, damit sie sofort davon profitieren können. Der zweite Grund ist die Minimierung von Problemen während der Bereitstellung und die Vereinfachung der Untersuchung und des Rollbacks im Falle von Problemen. Bei allen unseren Bereitstellungen entstehen keine Ausfallzeiten für den Endnutzer.
 

Bereitstellungszeitpläne

 
Bei unserer Plattform handelt es sich nicht um eine einzelne Anwendung, die wir en masse bereitstellen würden, sondern um eine Ansammlung von Systemen und Anwendungen, die zusammenarbeiten und miteinander kommunizieren und für die es eigene Bereitstellungszeitpläne gibt. Es gibt drei Hauptkategorien von Anwendungen mit entsprechenden Bereitstellungszeitplänen:
  • Die Backend-Plattform (Server) wird mindestens einmal pro Wochentag bereitgestellt. Darüber hinaus können bei Bedarf Ad-hoc-Bereitstellungen für verschiedene Zwecke vorgenommen werden, z. B. für Hotfixes. Im Rahmen des Standardszenarios werden alle Änderungen (Funktionen, Fehlerbehebungen, Verbesserungen) kontinuierlich in der Entwicklungsumgebung bereitgestellt. Einmal am Tag wird automatisch ein Snapshot der Version der Entwicklungsumgebung erstellt und in der Demo-Umgebung bereitgestellt (dies wird als „Feature-Freeze“ bezeichnet). Wenn am darauffolgenden Tag auf der Demoseite keine Probleme aufgetreten sind, wird diese Version in der Produktionsumgebung bereitgestellt. Alle Bereitstellungen erfolgen schrittweise auf allen Instanzen und in allen Regionen. Während des Prozesses überwachen wir das System und können im Falle von Problemen den Prozess zurücksetzen.
  • Webanwendungen (z. B. Commander, Distributor oder Navigator) werden unabhängig voneinander bereitgestellt, sobald eine Änderung in der Anwendung abgeschlossen ist. Das bedeutet, dass jedes Mal, wenn eine Funktion implementiert oder ein Fehler behoben wurde und die Qualitätssicherung erfolgreich durchlaufen ist, diese sofort sowohl in der Demo- als auch in der Produktionsumgebung bereitgestellt werden. Es handelt sich um eine echte fortlaufende Lieferung, was bedeutet, dass es an einem Tag 50 oder 0 Bereitstellungen 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 Anwendungsspeichern unregelmäßig bereitgestellt. Wenn wir gelegentlich feststellen, dass der Umfang der abgeschlossenen Änderungen in der Entwicklungsversion der Anwendung relativ groß ist, oder wenn andere Gründe dies erfordern, veröffentlichen wir eine neue Version der Anwendung. Sie wird dann im jeweiligen Anwendungsspeicher veröffentlicht und durchläuft dort den Verifizierungsprozess. Nach einiger Zeit (Stunden oder Tage) erreicht die neue Version die Endnutzergeräte.
Wir behalten uns die Möglichkeit vor, für Systemänderungen notwendige Ausfallzeiten einzuplanen, obwohl wir bestrebt sind, nie von dieser Möglichkeit Gebrauch zu machen. Bislang mussten wir nur einmal im Jahr 2013 davon Gebrauch machen, als wir unseren Cloud-Anbieter von AppHarbor zu Microsoft Azure migrierten. Seitdem hatten wir keine geplanten Ausfallzeiten mehr.
 

Freigabeprozess

 

Es ist wichtig, zwischen Bereitstellung und Freigabe zu unterscheiden. Die Bereitstellung 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, Fehlerkorrekturen, Verbesserungen oder andere unkritische Dinge werden für alle unsere Kunden freigegeben, sobald sie implementiert sind. Bei größeren oder kritischen Änderungen halten wir uns jedoch an den folgenden 4-stufigen Freigabeprozess:
 
  1. 1. Internal Alpha: Die Änderung wird nur für Mews-Mitarbeiter freigegeben. Wir verwenden Mews auch intern, daher fungieren wir als „Kanarienvögel“, die die Änderung testen.
  2. 2. Private Beta: Die Änderung wird für eine ausgewählte Untergruppe von Kunden freigegeben, die die sogenannte Early-Adopter-Gruppen bilden. Wenn die Änderung für jemanden, der an der Produktentwicklung und -auslieferung beteiligt war, besonders wichtig ist, kann auch diese Person in die Private Beta-Gruppe einbezogen werden. Sowohl für diesen Schritt als auch für Internal Alpha verwenden wir LaunchDarkly, um die Menge der betroffenen Kunden zu verwalten.
  3. 3. Public Beta: Die Änderung wird für jeden freigegeben, der sich für die Änderung entscheidet. Normalerweise führen wir in den Einstellungen eine Option ein, die es jedem ermöglicht, die Änderung zu übernehmen.
  4. 4. Allgemeine Verfügbarkeit: Die Änderung wird für alle unsere Kunden freigegeben.

Vorfälle

Bei allen Arten von Vorfällen, einschließlich Sicherheitsvorfällen, Fehlern, Untersuchungen oder Überwachungswarnungen, folgen wir einem strengen Lösungsprozess. Der Prozess wird in unserer internen Wissensdatenbank dokumentiert und alle Techniker und 24/7-Supportmitarbeiter sind damit vertraut. Intern verwenden wir YouTrack als Ticketing-Tool und als „Single Source of Truth“. Jedes Ticket wird ungeachtet seines Schweregrads einem Team zugewiesen und umgehend über den internen Slack-Kanal an das jeweilige Team übermittelt.

Für kritische Vorfälle gibt es einen zusätzlichen Eskalationsfluss und -prozess:

  • Der Vorfall wird im unternehmensweiten Vorfallkanal übermittelt.
  • Der Vorfall wird über PagerDuty direkt an den Teamleiter eskaliert.
  • Wenn die Meldung nicht innerhalb von 15 Minuten vom Teamleiter bestätigt wird, wird sie an den Abteilungsleiter weitergeleitet.
  • Wenn die Meldung nicht innerhalb von 30 Minuten bestätigt wird, wird sie an den CTO weitergeleitet.
  • Für den Vorfall wird ein Koordinator ernannt.
  • Der Koordinator richtet einen Kommunikationskanal für den jeweiligen Vorfall ein.
  • Der Koordinator aktualisiert in regelmäßigen Abständen unsere StatusSeite.
  • Der Koordinator stellt sicher, dass alle relevanten Personen in die Lösung des Vorfalls einbezogen werden.
  • Der Koordinator informiert alle Beteiligten über die Fortschritte bei der Lösung des Vorfalls.
  • Nach der Lösung wird eine Post-Mortem-Aufgabe erstellt. Das Team führt eine Ursachenanalyse durch, entwirft Lösungen und veröffentlicht den Post-Mortem-Status auf der StatusSeite.
  • Die Lösungen, die sich aus dem Post-Mortem-Status ergeben, werden innerhalb der von unserem internen SLO festgelegten Frist umgesetzt.

Sicherheit

Die Mews-Plattform arbeitet mit sehr sensiblen Kundendaten. Daher sind Sicherheit und Datenschutz nicht verhandelbare Elemente des Systems. Wir verfolgen in diesem Bereich den allgemeinen Ansatz, dass man sich nicht auf den Menschen oder sein Wissen verlassen sollte. Alle unsere Sicherheitsmaßnahmen und internen Prozesse sind in diesem Sinne konzipiert. So werden unsere Entwickler zwar regelmäßig in den besten Praktiken zur sicheren Programmierung geschult. Aber wenn es um Sicherheit geht, verlassen wir uns nicht ausschließlich darauf. Unsere Prozesse und Frameworks sind darauf ausgelegt, die Entstehung von Sicherheitsfehlern zu verhindern oder einem Entwickler das Einschleusen von Sicherheitsproblemen in unser System zumindest extrem zu erschweren, wenngleich es technisch nicht möglich ist, dies vollständig zu verhindern. Dies spiegelt sich in unserem Verfahren zur Lösung von Sicherheitsproblemen wider, das später beschrieben wird. Unsere Sicherheitsstrategie stützt sich auf zwei Hauptprinzipien:
 
  1. 1. Minimierung der Angriffsfläche, Reduzierung des Umfangs und der Komplexität.
  2. 2. Kontinuierliche Penetrationstests der Angriffsfläche mit umfassender und gründlicher Beseitigung aller Ergebnisse.

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

Minimierung der Angriffsfläche

 
Der beste Weg, Sicherheitsprobleme zu vermeiden, besteht darin, deren Entstehung von vornherein auszuschließen. Dies steht im Einklang mit unserer serverlosen Philosophie: wir haben keine Kontrolle über Hardware, Betriebssysteme, Webserver oder Datenbankserver. Es ist ausgeschlossen, dass wir eines dieser Systeme falsch konfigurieren oder dass wir vergessen, Sicherheits-Patches anzuwenden usw. Dafür ist Azure mit seinen großen Sicherheitsteams zuständig. Wir verwenden eine sehr begrenzte Konfiguration der Azure-Dienste, für die es Optionen gibt, um einige zusätzliche Sicherheitsfunktionen zu aktivieren. Um sicherzustellen, dass wir keine dieser Optionen übersehen, verwenden wir den Azure Security Advisor, der uns über alle diese Optionen benachrichtigt, beispielsweise wenn Azure neue Funktionen einführt, die die Sicherheit unserer Systeme verbessern könnten. Dank all dieser Faktoren reduziert sich unsere Angriffsfläche (aus der Systemperspektive) effektiv auf den von uns entwickelten Anwendungscode. Weitere Informationen zu den Sicherheitsfunktionen von Azure finden Sie unter Dokumentation mit grundlegenden Azure-Sicherheitsinformationen.
 

Kontinuierliche Penetrationstests

Wie bereits dargelegt, liegt unser Hauptaugenmerk auf der Anwendungssicherheit. Um die Sicherheit unseres Systems zu gewährleisten, unterziehen wir uns kontinuierlich Penetrationstests durch cobalt.io. Zu jedem beliebigen Zeitpunkt wird ein Teil unseres Systems oder Produkts einem Penetrationstest unterzogen und wir stellen sicher, dass die gesamte Oberfläche kontinuierlich durch Tests abgedeckt ist.
Es gibt mehrere Ansätze zur Beseitigung von Sicherheitslücken. Wir sind stolz auf unseren Ansatz und gehen jedes Sicherheitsproblem nach dem Post-Mortem-System 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, um zu verhindern, dass sich solche Probleme in Zukunft wiederholen. Wenn beispielsweise ein Problem in einer unserer APIs gefunden wird, aktualisieren wir unser API-Framework so, dass das Problem in allen unseren APIs beseitigt wird. Oder wir implementieren einen statischen Code-Analyzer, der unsere Codebasis automatisch nach dem Problem als auch nach neuem Code durchsucht, den wir produzieren. Auch wenn jeweils nur ein Produkt getestet wird, wenden wir unsere Erkenntnisse auf alle Produkte an. Weitere Informationen finden Sie im Abschnitt „Vorfälle“.
 

Technische Sicherheitsmaßnahmen

 
Aus technischer Sicht gibt es viele Maßnahmen, die wir ergreifen, um nicht nur die Sicherheit der Plattform, sondern auch die unserer Kunden zu gewährleisten. Hier sind einige von ihnen:
  • Die Daten werden während der Übertragung verschlüsselt. Wir setzen mindestens TLS 1.2 durch und erreichen eine A+ Bewertung im Qualys SSL Labs-Test.
  • Die Daten in allen von uns verwendeten Speicherarten werden im Ruhezustand verschlüsselt.
  • Wir verwenden mehrere Ebenen der internen Systemprotokolle und stellen unseren Kunden innerhalb der Plattform Prüfprotokolle zur Verfügung.
  • Wir führen regelmäßig ASV-Scans sowie interne und externe Anfälligkeitsprüfungen 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 bieten.
  • Wir verwenden Azure Active Directory und SSO für alle internen Systeme, die diese Funktion bieten.
  • Für alle unsere internen Systeme gilt das Least-Privilege-Prinzip.
  • Unsere Plattform unterstützt MFA und erzwingt starke Passwörter für unsere Benutzer.
  • Benutzerkennwörter werden mit bcrypt gehasht und niemals im Klartext gespeichert.
  • Alle sensiblen Benutzerschlüssel und Tokens, die für die Authentifizierung durch Drittanbieter verwendet werden müssen (wie FTP-Passwörter), werden in der Azure SQL-Datenbank verschlüsselt.
  • Alle sensiblen Mews-Schlüssel und -Tokens werden in der Konfiguration verschlüsselt.

Personenbezogene Sicherheitsmaßnahmen

  • Wir führen bei allen Kandidaten für sensible Positionen, für die wir einstellen möchten, eine Hintergrundüberprüfung durch. Der Umfang und die Gründlichkeit dieser Überprüfungen hängen von der Funktion und der Vorrangigkeit des Bewerbers ab.
  • Die Verträge mit allen unseren Mitarbeitern enthalten Vertraulichkeitsklauseln. Die Mitarbeiter sind ferner verpflichtet, die internen Vorschriften für die Verarbeitung personenbezogener Daten einzuhalten.
  • Alle Mitarbeiter nehmen an einer Einführungsschulung für neue Mitarbeiter teil, die obligatorische Sicherheits- und Datenschutzschulungen umfasst.
  • Alle Mitarbeiter verwenden 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.

Zahlungskartendaten

 

Ein gutes Beispiel für die Verringerung der Angriffsfläche ist unser Umgang mit sensiblen Zahlungskartendaten. Mews verwendet PCI-Proxy als Anbieter für Kartentokenisierung. Selbst sensible Kartendaten wie Nummer oder CVV erreichen unsere Infrastruktur nicht. Als Beispiel betrachten wir einen einfachen Ablauf zum Empfangen von Kartendetails von Dritten (z. B. Buchungskanal) und anschließenden Belasten dieser Karte:
  • 1. Wenn Dritte Kartendetails an uns senden müssen, leiten sie die Anfrage nicht wie üblich direkt an uns sondern an PCI Proxy weiter.
  • 2. PCI Proxy empfängt die Anfrage, erkennt die Kartendaten, speichert sie und ersetzt sie durch Tokens, die nicht mehr sensibel sind. Dieser Teil wird als Tokenisierung bezeichnet.
  • 3. PCI Proxy leitet die Anfrage, die nun Tokens enthält, an uns weiter.
  • 4. Wir speichern den Token in unserer Datenbank.
  • 5. Um die Karte zu belasten, erstellen wir eine Anfrage für das Zahlungsgateway. Anstatt jedoch direkt die Kartendaten zu verwenden (über die wir nicht verfügen), verwenden wir Tokens. Und anstatt die Anfrage direkt an das Zahlungsgateway zu senden, leiten wir sie an PCI Proxy weiter.
  • 6. PCI Proxy erhält die Anfrage von uns, erkennt die Tokens und ersetzt sie durch die sensiblen Kartendaten. Dieser Teil wird als Enttokenisierung bezeichnet.
  • 7. PCI Proxy leitet die Anfrage, die nun sensible Daten enthält, an das Zahlungsgateway weiter.
Viele Arten von Angriffen sind nutzlos, da unsere Datenspeicher die sensiblen Daten nicht enthalten.

Datenschutz

Die Mews-Plattform verarbeitet personenbezogene und andere Arten von sensiblen Daten. Allerdings sind wir kein reiner SaaS-Dienst. Um alle Datenflüsse zu verstehen, ist es daher wichtig, die beiden Rollen von Mews zu unterscheiden:
 
Datenverarbeiter: In der Beziehung zwischen uns und unseren Kunden (Hotels) fungieren wir als Datenverarbeiter für alle ihre Daten, die auf die Plattform gelangen, einschließlich der personenbezogenen Daten ihrer Klienten. Dies ist ein Teil der Dienste, die wir unseren Kunden anbieten.
 
Datenverantwortlicher: In der Beziehung zwischen uns und unseren Benutzern (Einzelpersonen) fungieren wir als Datenverantwortlicher für ihre personenbezogenen Daten. Wir stellen unseren Benutzern einen Travel-Wallet-Dienst und andere Anwendungen zur Verfügung.
Diese beiden Rollen und operationellen Aufgaben von Mews sind streng voneinander getrennt, und die Daten werden niemals vermischt. Und da wir als eine Multi-Tenant-Lösung fungieren, kann eine einzelne natürliche Person ihre personenbezogenen Daten in N+1 Kopien in der Mews-Plattform führen. Wenn die Person mit N unserer Kunden interagiert hat (z. B. eine Reservierung in N verschiedenen Hotels hatte), dann werden N Kundenkonten gespeichert und Mews fungiert dort als Datenverarbeiter. Das „+1“ stellt eine weitere Kopie der personenbezogenen Daten dar, die für den Fall gespeichert werden, dass sich die Person bei Mews als Benutzer anmeldet, um den Travel-Wallet-Dienst zu nutzen. Für diese einzelne Kopie fungiert Mews als Datenverantwortlicher. Wir haben keine Vereinbarung über eine gemeinsame Verantwortung.
Alle Arten von Daten werden gemäß dem Abschnitt „Infrastruktur“ in dieser Dokumentation in unseren Azure-Datenspeichern gespeichert. Wir führen keine Archivierung der Daten durch und Sicherungskopien werden nur für einen begrenzten Zeitraum aufbewahrt.
 
Daten unserer Kunden
Die Daten werden entweder von Mitarbeitern unserer Kunden manuell in das System eingegeben oder von deren Kunden sowohl direkt (durch 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 Angaben der Klienten unserer Kunden, bei denen es sich zumeist um Reisende aus aller Welt handelt.
Unsere Kunden sind in der Lage, verschiedene Datenpunkte über ihre Klienten zu erfassen, darunter: Vorname, Nachname, Nachname, Geburtsdatum, Staatsangehörigkeit, Ausweispapiere (Reisepass, Personalausweis, Führerschein, Visum), Adressen, E-Mail-Adresse, Telefonnummer usw. Die Daten der Zahlungskarten werden ebenfalls erfasst, sind jedoch weder für den Kunden noch für uns direkt zugänglich. Weitere Einzelheiten finden Sie im Abschnitt Sicherheit in dieser Dokumentation.
 
Verarbeitung
 
Wir verarbeiten personenbezogene Daten gemäß dem Datenverarbeitungszusatz, den wir mit unseren Kunden unterzeichnen. Wir können auf die Daten zugreifen, wenn dies für die Erbringung unserer Dienste erforderlich ist (z. B. bei der Untersuchung von Fehlern oder bei der Unterstützung unserer Kunden auf der Grundlage ihrer Anfragen). Wir können die Daten zu internen statistischen und analytischen Zwecken verwenden. Zu diesem Zweck sind die Daten jedoch immer anonymisiert und wir halten uns an die vertraglichen Verpflichtungen. Bitte beachten Sie auch den Abschnitt „Unterauftragsverarbeiter“, in dem Drittunternehmen aufgeführt sind, die als Unterauftragsverarbeiter der Kundendaten oder einer Teilmenge der Kundendaten fungieren.
 
Aufbewahrung
 
Wir speichern personenbezogene Daten so lange, wie es für die Zwecke, für die sie bereitgestellt oder erhoben wurden, erforderlich ist. Da wir im Hinblick auf die personenbezogenen Daten, die unsere Kunden (die Verantwortlichen) erheben, als Auftragsverarbeiter fungieren, unterliegen wir in Bezug auf den Umgang mit den Daten deren Weisungen. Es liegt in der Verantwortung des Kunden, sicherzustellen, dass die für personenbezogene Daten geltenden Aufbewahrungsfristen den gesetzlichen Bestimmungen entsprechen. Um unseren Kunden die Möglichkeit zu geben, die Aufbewahrungsfristen zu verwalten, bieten wir unseren Kunden verschiedene Optionen an:
  • Wir löschen manuell das gesamte Kundenprofil und die dort gespeicherten personenbezogenen Daten. Dies wirkt sich auf alle oben aufgeführten Datenpunkte aus und es erfolgt eine endgültige Löschung aller Daten.
  • Nach einem bestimmten Zeitraum ohne Nutzung richten wir die automatische Bereinigung von Kundenprofilen ein. In diesem Fall führt das System den Vorgang aus, der andernfalls bei der ersten Option manuell ausgeführt werden müsste.
  • In Bezug auf Zahlungsdaten können unsere Kunden einfach den Zeitraum in Tagen festlegen, nach dessen Ablauf die Zahlungskarteninformationen des Kunden automatisch gelöscht werden. Dabei handelt es sich um einen automatischen Prozess, bei dem alle Kartendaten gelöscht werden, die mit dem Gastprofil verbunden sind. Löschen bedeutet hier, dass Mews das Kartentoken nicht behält und PCI Proxy keine Informationen zu dieser Karte besitzt. Wenn der Prozess eingerichtet ist, löscht das System alle Tokens aus der Mews-Datenbank und die Karte wird von PCI-Proxy 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. Darüber hinaus stellen wir auf dem Benutzerportal eine Messaging-Funktionalität zur Verfügung, die unseren Kunden eine einfache Kommunikation mit ihren Kunden ermöglicht. Sollte eine Anfrage an unseren Datenschutzbeauftragten (dpo@mews.com) gerichtet sein, die für unsere Kunden und nicht für uns bestimmt ist, leiten wir diese Anfrage an den richtigen Empfänger weiter.
 
Daten unserer Benutzer
 
Die Daten werden nur dann manuell in das System eingegeben, wenn der Benutzer sein Profil ausfüllt oder aktualisiert. Während der Anmeldung ist das auch der Fall. Um das Einchecken in ein neues Hotel so angenehm wie möglich zu gestalten, können unsere Benutzer alle Daten erfassen, die in einem Hotel für den Check-in-Prozess benötigt werden. Und es bleibt den Benutzern überlassen, ob und in welchem Umfang sie ihre Daten mit bestimmten unserer Kunden teilen möchten.
Zusätzlich zu diesen gemeinsam nutzbaren Datenpunkten speichern wir Benutzernamen, Passwörter (gehasht), Mittel zur 2FA-Authentifizierung und andere Details, die für eine reibungslose Nutzung unserer Plattform erforderlich sind.
 
Aufbewahrung
 
Aufgrund der Art des Produkts, dessen Hauptfunktion darin besteht, als Wallet personenbezogener Daten zu fungieren, der jederzeit in der Zukunft verwendet 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
Über das Benutzerportal haben die Benutzer Zugriff auf alle von uns gespeicherten personenbezogenen Daten. Sie haben ferner die Möglichkeit, ihr Profil zu löschen. Alternativ können Sie sich unter dpo@mews.com auch direkt an unseren Datenschutzbeauftragten wenden.

Unterauftragsverarbeiter

Mews beauftragt und nutzt Dienstleister, die Zugang zu bestimmten Benutzerdaten haben und die Auslieferung unserer Dienste unterstützen können. Wir wählen diese Unterauftragsverarbeiter Dritter und Auftragsverarbeiter Dritter sehr sorgfältig aus. Von Unterauftragsverarbeitern Dritter verlangen wir mindestens SOC 2, PCI-DSS oder eine andere gleichwertige Prüfung/Zertifizierung der Branche.
Die folgende Übersicht enthält wichtige Informationen über die Identität, den Standort und die Rolle der einzelnen Unterauftragsverarbeiter.
Unterauftragsverarbeiter Dritter
Ein Unterauftragsverarbeiter Dritter ist ein Dienst, den wir als Datenverarbeiter in Anspruch nehmen, um für unsere Kunden (Hotels), die für die Datenverarbeitung verantwortlich sind, Dienste zu erbringen. Hier finden Sie die Liste der Unterauftragsverarbeiter Dritter:
  • Microsoft Corporation - US - Infrastruktur, Datenspeicherung, andere Dienste. Die Daten befinden sich in der Europäischen Union.
  • Google Ireland, Ltd. - IE - Push-Benachrichtigungen, andere Dienste. 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 - Kreditkartentokenisierung. Die Daten befinden sich in der Schweiz.
  • Twilio, Inc. - US - Mailing und Textnachrichten. Die Daten befinden sich in den Vereinigten Staaten.
  • Learnupon, Ltd. - IE - Lernmanagement-System. Die Daten befinden sich in der Europäischen Union.
  • Aircall SAS - FR - Cloud-basiertes integriertes Telefonsystem für Unternehmen. 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 Analyse- und Business Intelligence-Plattform. Die Daten befinden sich in der Europäischen Union.
  • Cloudflare, Inc. - US - Content Delivery Network Die Daten befinden sich überall auf der Welt. Der Datenverkehr wird automatisch an das nächstgelegene Rechenzentrum weitergeleitet.
Zusätzliche Unterauftragsverarbeiter Dritter
 
Die folgende Liste enthält die Dienstleister (zertifizierte Partner), die von Mews beauftragt wurden, im Namen von Mews professionelle Beratungs- und Bereitstellungsdienste für bestimmte Kunden (Hotels) zu erbringen, die diese Art von Diensten von Mews erwerben. Es sei darauf hingewiesen, dass nicht alle hier aufgeführten Dienstleister von allen Mews-Kunden genutzt werden. Hier finden Sie die Liste der zusätzlichen Unterauftragsverarbeiter Dritter:
  • Unisono Hospitality Management GmbH - Deutschland - Professionelle Beratungs- und Bereitstellungsdienste.
  • CMC Hospitality Software Ltd - Vereinigtes Königreich - Professionelle Beratungs- und Bereitstellungsdienste.
  • Actrois DJ Conseils - Frankreich - Professionelle Beratungs- und Bereitstellungsdienste.
  • Swiss Urban & Mountain Hospitality AG - Schweiz - Professionelle Beratungs- und Bereitstellungsdienste.

Verbundene Unternehmen

Die Mews-Gruppe besteht aus den folgenden verbundenen Unternehmen:
  • Mews Systems B.V. – NL
  • Mews Systems, s.r.o. – CZ
  • Mews Systems, Ltd. – UK
  • Mews Systems Sarl – FR
  • Mews Systems GmbH – DE
  • Mews Systems Iberica S.L. – ES
  • Mews Systems, S.R.L. – IT
  • Mews Systems, Pty Ltd. – AU
  • Mews Systems, Inc. – US
  • Planet Winner, BVBA – BE
  • PMS Winner, AB – SE
  • Databasics Hospitality System, Ltd. – UK
  • Bizzon Limited – UK
  • Bizzon d.o.o. – HR
  • Cenium Scandinavia AS – NO
  • Cenium North America Inc – US
  • Mingus Software Inc – CA

Zertifizierungen

Zertifizierungen werden von Fall zu Fall und nach Bedarf geprüft. Wir sind in diesem Bereich nicht proaktiv eingestellt. Denn obwohl einige Zertifizierungen für die Verbesserung bestimmter Prozesse hilfreich sein können und Ihnen die Gewissheit bieten können, dass Ihre Prozesse als Best Practice gelten, stellen wir auch fest, dass es bei manchen Zertifizierungen schwierig ist, mit neuen Technologien und modernen Softwareentwicklungspraktiken Schritt zu halten. Deshalb führen wir nur die Zertifizierungen durch, die für uns sinnvoll oder absolut notwendig sind. Derzeit verfügen wir über die folgenden Zertifizierungen: