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-鈥濱nstallation鈥� 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 鈥濫bene鈥� 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 einsehen.
 

Umgebungen

 

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

  • Entwicklungsumgebung
  • Feature-Branch-Umgebungen

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 鈥瀦ustandslos鈥�, 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 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 锄耻谤眉肠办. 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 锄耻谤眉肠办 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. 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.
 

叠别谤别颈迟蝉迟别濒濒耻苍驳蝉锄别颈迟辫濒盲苍别

 
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 叠别谤别颈迟蝉迟别濒濒耻苍驳蝉锄别颈迟辫濒盲苍别 gibt. Es gibt drei Hauptkategorien von Anwendungen mit entsprechenden 叠别谤别颈迟蝉迟别濒濒耻苍驳蝉锄别颈迟辫濒盲苍别n:
  • 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 鈥濬eature-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 锄耻谤眉肠办setzen.
  • 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 锄耻谤眉肠办zusetzen.
  • 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 鈥濳anarienv枚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.

痴辞谤蹿盲濒濒别

Bei allen Arten von 痴辞谤蹿盲濒濒别n, 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 鈥濻ingle 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 痴辞谤蹿盲濒濒别 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 尝枚蝉耻苍驳别苍 und ver枚ffentlicht den Post-Mortem-Status auf der StatusSeite.
  • Die 尝枚蝉耻苍驳别苍, 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
 

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 鈥灣沾前诿け舯舯疴€�.
 

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-尝枚蝉耻苍驳别苍 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 鈥濱nfrastruktur鈥� 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 鈥濽nterauftragsverarbeiter鈥�, 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:
  • 萝莉社 B.V. 鈥撯€疦L
  • 萝莉社, s.r.o. 鈥� CZ
  • 萝莉社, Ltd. 鈥� UK
  • 萝莉社 Sarl 鈥� FR
  • 萝莉社 GmbH 鈥� DE
  • 萝莉社 Iberica S.L. 鈥� ES
  • 萝莉社, S.R.L. 鈥� IT
  • 萝莉社, Pty Ltd. 鈥� AU
  • 萝莉社, 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:
  • PCI-DSS Stufe 1 - (14. Juli 2023 - 14. Juli 2024, QSA Verizon).
  • ISO 9001 - (28. Februar 2018 - 27. Februar 2024).
  • ISO 27001 - (16. M盲rz 2018 - 9. Februar 2024).
  • NF525 PMS - (7. Februar 2024 - 7. Februar 2025).
  • NF525 POS - Zertifikat in PDF (7. Februar 2024 - 7. Februar 2025).