Sicherheitsübersicht / Sicherheits-Whitepaper

Zuletzt aktualisiert: 25. Oktober 2026 (Version 1.0).

Überprüfungsturnus: jährlich sowie bei jeder wesentlichen Änderung der Plattformarchitektur

1. Einleitung

PassportScan Cloud ist eine Software-as-a-Service-Plattform, die von GlobeID Limited („GlobeID") betrieben wird und es Beherbergungsbetrieben ermöglicht, Ausweisdokumente von Gästen zu erfassen, Einwilligungen und Unterschriften einzuholen sowie gesetzliche Meldepflichten gegenüber Behörden (Polizei-, Statistik- und Grenzbehörden) zu erfüllen und eine PMS-Integration zu nutzen.

Dieses Dokument beschreibt die Sicherheitsarchitektur sowie die technischen und organisatorischen Maßnahmen, die die Plattform und die darauf verarbeiteten personenbezogenen Daten schützen. Es richtet sich an Kunden, Interessenten und Prüfer, ergänzt den Auftragsverarbeitungsvertrag (AVV) und die Liste der Unterauftragsverarbeiter und dient als Referenzantwort für Sicherheitsfragebögen. Es beschreibt die Produktionsplattform in der zum Stichtag dieses Dokuments eingesetzten Form.

2. Sicherheitsprogramm und Compliance

• GlobeID betreibt ein an ISO/IEC 27001:2022 ausgerichtetes Informationssicherheits-Managementsystem (ISMS) mit einem benannten Chief Information Security Officer, einem Risikoregister und einer Erklärung zur Anwendbarkeit (Statement of Applicability); das ISMS wird durch interne Audits und Managementbewertungen überprüft, die in einem jährlichen Zyklus geplant sind.
• DSGVO: GlobeID handelt als Auftragsverarbeiter für Gästedaten im Rahmen des AVV und hat einen externen Datenschutzbeauftragten benannt. Verzeichnisse von Verarbeitungstätigkeiten, eine Datenschutz-Folgenabschätzung (DSFA) für Ausweisdaten von Gästen und ein Verfahren zur Wahrnehmung von Betroffenenrechten werden geführt.
• Zahlungskartendaten werden ausschließlich von Stripe verarbeitet; PassportScan betreibt keine Karteninhaberdaten-Umgebung (Cardholder Data Environment) und erhält zu keinem Zeitpunkt Kartennummern, CVV oder Ablaufdaten.
• Die Kontrollüberwachung erfolgt kontinuierlich über eine Compliance-Automatisierungsplattform, die mit den Cloud-, Quellcode- und Identitätsanbietern verbunden ist; unabhängige Penetrationstests werden regelmäßig beauftragt und festgestellte Schwachstellen bis zu ihrer Behebung nachverfolgt.

3. Hosting und Architektur

4. Netzwerksicherheit

• Standardmäßig privat: Jeder Dienst läuft in privaten Subnetzen einer dedizierten VPC. Nur die kundenseitigen Frontends, die Administrationskonsole für Mitarbeiter und zwei öffentliche APIs sind über das Internet erreichbar, und zwar über Amazon API Gateway und einen öffentlichen Application Load Balancer. Die Admin-Konsole ist durch AWS WAF und eine eigene Authentifizierung mit persönlich zugewiesenen Mitarbeiterkonten und verpflichtender Multi-Faktor-Authentifizierung geschützt. Alle internen Microservices, die Automatisierungs-Engine und die OCR-Engine sind nur innerhalb der VPC oder über das Unternehmens-VPN erreichbar.
• Web Application Firewall: Der öffentliche Zugangspunkt (API-Gateway-Stages und der öffentliche Load Balancer) ist durch AWS WAF geschützt. Die von AWS verwalteten Regelgruppen Amazon IP Reputation List und Known Bad Inputs blockieren bösartige Quellen und Payloads, das AWS Core Rule Set (an OWASP ausgerichtet) wird bei jeder Anfrage ausgewertet, und eine Ratenbegrenzung blockiert missbräuchliche Quellen, mit strengeren Grenzwerten für Authentifizierungs-Endpunkte.
• Transportverschlüsselung: Öffentliche Endpunkte akzeptieren ausschließlich TLS 1.2 und TLS 1.3 (API-Gateway-Sicherheitsrichtlinie TLS_1_2; Load-Balancer-Richtlinie ELBSecurityPolicy-TLS13-1-2-2021-06 mit modernen ECDHE-GCM-Cipher-Suites). HTTP wird auf HTTPS umgeleitet, und HTTP Strict Transport Security (HSTS) wird auf dem öffentlichen Load Balancer durchgesetzt. Zertifikate werden automatisch über AWS Certificate Manager ausgestellt und erneuert.
• Administrativer Zugriff: Entwickler erreichen interne Dienste ausschließlich über ein Zero-Trust-VPN, das an ihre individuelle Identität gebunden ist; es gibt weder SSH- noch RDP-Zugänge, die dem Internet ausgesetzt sind, und keinen Bastion-Host.
• Netzwerkprotokollierung: VPC Flow Logs (gesamter Datenverkehr) und S3-Serverzugriffsprotokolle werden 90 Tage lang aufbewahrt.

5. Datensicherheit

5.1 Verschlüsselung

5.2 Datenstandort und Datenresidenz

• Die zentralen Plattformdienste und die primären Datenbanken werden ausschließlich in AWS eu-west-1 (Irland) gehostet; es ist keine regionsübergreifende Replikation von Datenbanken konfiguriert.
• Sofern ein Kunde die Speicherung von Dokumentenbildern aktiviert, werden die Bilder in der S3-Region gespeichert, die der Jurisdiktion der Unterkunft entspricht. Bereitgestellte Regionen: eu-west-1 (Europa), us-east-1 (Nordamerika), sa-east-1 (Südamerika), ap-southeast-1 (Asien-Pazifik) und ap-southeast-2 (Australien). Jeder regionale Bucket verwendet dieselbe Konfiguration für Verschlüsselung, Versionierung und Zugriffsprotokollierung.
• Übermittlungen außerhalb des EWR sind durch das AWS Data Processing Addendum und die Standardvertragsklauseln abgedeckt, wie im Auftragsverarbeitungsvertrag (AVV) beschrieben.

5.3 Geheimnisse und Schlüssel

• Anwendungsgeheimnisse, API-Schlüssel und Verschlüsselungsschlüssel werden im AWS Systems Manager Parameter Store (SecureString) gespeichert und beim Start in die Container eingespeist; sie werden niemals in den Quellcode übernommen oder in Images eingebettet.
• Datenbank-Zugangsdaten werden entweder von AWS generiert und rotiert (RDS-verwaltete Geheimnisse im AWS Secrets Manager) oder als SecureStrings im AWS Systems Manager Parameter Store gespeichert und beim Start als Geheimnisse in die Container eingespeist.
• Änderungen an Geheimnissen in der Produktionsumgebung erfolgen über einen auditierten Betriebsworkflow und nicht manuell über die Konsole. Datenbankpasswörter der Anwendung werden durch unsere interne Betriebsplattform nach einem festgelegten Zeitplan ohne Ausfallzeiten rotiert.

5.4 Backups und Aufbewahrung

• Aurora MySQL: automatisierte tägliche Backups mit 15-tägiger Aufbewahrung und kontinuierlicher Point-in-Time-Wiederherstellung; Löschschutz aktiviert; vor jeder Löschung eines Clusters wird ein finaler Snapshot erstellt.
• Objektspeicher: Versionierung mit 90-tägiger Aufbewahrung früherer Versionen zum Schutz vor versehentlichem Löschen oder Überschreiben.
• Bei Vertragsende werden die Kundendaten an den Kunden zurückgegeben und/oder auf dessen Verlangen innerhalb von 30 Tagen nach der Anforderung gelöscht, wie im Auftragsverarbeitungsvertrag (AVV) festgelegt; Sicherungskopien laufen anschließend über den oben beschriebenen Aufbewahrungszyklus ab.

6. Identitäts- und Zugriffsverwaltung

• Kundennutzer authentifizieren sich über den Identitätsanbieter der Plattform (Clerk) mit E-Mail-Verifizierung, Sitzungsverwaltung und optionaler Multi-Faktor-Authentifizierung; der Zugriff innerhalb eines Kundenkontos ist rollenbasiert.
• GlobeID-Mitarbeiter: Der Zugriff auf Quellcode, CI/CD und die interne Verwaltungskonsole erfolgt über die GitHub-Organisation mit erzwungener Zwei-Faktor-Authentifizierung. Kein Entwickler verfügt über dauerhaften Zugriff auf das Produktions-AWS-Konto, und keine von einer Person gehaltene Zugangsberechtigung kann eine Rolle darin übernehmen: Änderungen und Betrieb der Produktionsumgebung erfolgen ausschließlich über unsere interne Betriebsplattform und auditierte Betriebsabläufe, ohne Konsolen- oder Kommandozeilenzugang für Entwickler. Entwickler haben nach dem Prinzip der minimalen Rechtevergabe ausschließlich Zugriff auf die Entwicklungs- und Staging-Konten. Überwachung und Betrieb nutzen dedizierte Rollen mit minimalen Rechten; die begrenzten Betriebsaktionen, die über unsere Betriebsplattform verfügbar sind (zum Beispiel rollierender Neustart, Wartungsmodus, geplante Rotation von Zugangsdaten, genehmigte einmalige Datenaufgaben und Datenbank-Snapshots), sind auf benannte Ressourcen beschränkt, rollenbasiert abgesichert und — bei Datenoperationen in der Produktionsumgebung — durch einen zweiten Administrator freizugeben sowie auditiert. Ein dokumentiertes Notfallverfahren (Break-Glass-Verfahren) ist auf benannte Organisationsinhaber beschränkt, läuft ausschließlich über unser CI/CD-System und wird bei jeder Nutzung protokolliert und überprüft.
• Der Zugriff auf Produktionsdatenbanken wird Entwicklern nicht dauerhaft gewährt: Er wird just-in-time über unsere interne Betriebsplattform unter Angabe eines Grundes beantragt, von einem zweiten Administrator (niemals dem Antragsteller) genehmigt, als Datenbankbenutzer mit Beschränkung auf eine Datenbank und eine Zugriffsstufe bereitgestellt — niemals mit Rechten zur Schemaänderung —, zeitlich begrenzt (in der Produktionsumgebung höchstens 4 Stunden für Lesezugriff und 1 Stunde für Schreibzugriff) und bei Ablauf automatisch entzogen; Zugangsdaten werden nur dem Antragsteller angezeigt. Jeder Antrag, jede Genehmigung und jeder Entzug wird protokolliert. Der Export von Produktionsdaten auf Arbeitsplatzrechner ist untersagt.
• Produktionsdaten verbleiben in der Produktionsumgebung: Entwicklung und Staging verwenden ausschließlich synthetische oder anonymisierte Daten. Datenbank-Snapshots werden nur in eine neue Datenbank in der Umgebung wiederhergestellt, aus der sie stammen, sodass Produktionsdaten niemals in Entwicklungs- oder Testumgebungen wiederhergestellt werden; eine Wiederherstellung in der Produktionsumgebung erfordert die Angabe eines Grundes und die Genehmigung eines zweiten Administrators. Korrekturen an Produktionsdaten erfolgen ausschließlich über vorab deklarierte, im Code-Review geprüfte Aufgaben, die zuerst in der Staging-Umgebung getestet und von einem zweiten Administrator genehmigt werden — niemals über Ad-hoc-SQL.
• Prüfpfad für Operator-Aktivitäten: Alle privilegierten Vorgänge, die über die Betriebsplattform durchgeführt werden, einschließlich des Zugriffs auf Protokollinhalte der Produktionsumgebung — Zugriffsanträge und Genehmigungen, Release-Freigaben und Rollbacks, Änderungen des Betriebszustands von Umgebungen, Konfigurationsänderungen, Dokumentenfreigaben und elektronische Signaturen —, werden mit der Identität des Operators (GitHub SSO, 2FA erzwungen), Zeitstempel und Ergebnis protokolliert und stehen Prüfern als Nachweis zur Verfügung.
• CI/CD zu AWS authentifiziert sich über GitHub OpenID Connect-Föderation mit einer dedizierten Deployment-Rolle je Umgebung, beschränkt auf die benannten Repositories der Plattform.
• Verfahren für Eintritt, Wechsel und Austritt von Mitarbeitern, Überprüfungen und Vertraulichkeitsverpflichtungen sind Bestandteil des HR-Sicherheitsverfahrens; Zugriffsüberprüfungen werden regelmäßig durchgeführt.

7. Sichere Entwicklung und Änderungsmanagement

• Jede Änderung gelangt über Git in die Produktionsumgebung: Pull Request, unabhängiges Code-Review (Genehmigung durch eine andere Person als den Autor), automatisierte Prüfungen und ein Freigabeprozess nach dem Prinzip Branch pro Umgebung (Entwicklung → Staging → Produktion). Jede Überführung in die Staging- und in die Produktionsumgebung wird von einem Administrator beantragt und von einem anderen Administrator über die Betriebsplattform genehmigt, mit ausdrücklicher Bestätigung aller darin enthaltenen Datenbankmigrationen; die Überführung in die Produktionsumgebung erfordert zusätzlich eine QA-Freigabe des Staging-Releases. Jedes Änderungspaket ist vom Ticket bis zur bereitgestellten Version nachverfolgbar, und Produktionsbereitstellungen außerhalb der Betriebsplattform werden abgelehnt, außer im Rahmen des Break-Glass-Verfahrens.
• Container-Images werden einmal erstellt und beim Push in die Registry auf bekannte Schwachstellen gescannt; Tags in der Produktions-Registry sind unveränderlich (ein freigegebenes Tag kann niemals unbemerkt ersetzt werden), und die Produktionsumgebung bezieht genau den in der Staging-Umgebung validierten Image-Digest — für die Produktionsumgebung wird nichts neu erstellt.
• Infrastrukturänderungen folgen demselben Weg (Terraform-Plan beim Pull Request, Anwendung beim Merge) und ergeben einen vollständigen, überprüfbaren Prüfpfad der Produktionsänderungen.
• Releases können je Komponente zurückgerollt werden; die bereitgestellte Version jeder Komponente wird vor jeder Überführung aufgezeichnet.

8. Protokollierung, Überwachung und Reaktion auf Sicherheitsvorfälle

• Zentralisierte Protokolle: Anwendungs- und Zugriffsprotokolle aller Dienste werden an Datadog (EU-Standort, datadoghq.eu) und Amazon CloudWatch übermittelt; Anwendungsprotokolle werden bis zu 90 Tage aufbewahrt. Personenbezogene Daten und Geheimnisse werden in den Diensten maskiert, bevor Protokolle an Datadog gesendet werden, und erneut bei der Anzeige: Über unsere Betriebsplattform sehen Mitarbeiter, die keine Administratoren sind, Produktionsprotokollinhalte mit an Ort und Stelle maskierten personenbezogenen Werten, und automatisierte sowie KI-Tools erhalten keine Anfrage- oder Antwort-Nutzdaten, während die für die Diagnose erforderlichen Informationen (Fehlermeldungen, Anfragekennungen, Statuscodes) sichtbar bleiben. Jeder Zugriff auf Produktionsprotokollinhalte wird auditiert.
• Cloud-Audit und Bedrohungserkennung: AWS CloudTrail zeichnet jeden Management-API-Aufruf im Produktionskonto über alle Regionen hinweg auf, mit Integritätsvalidierung der Protokolldateien und versionierter Speicherung; Amazon GuardDuty analysiert kontinuierlich CloudTrail, VPC Flow Logs und DNS-Aktivitäten in jeder Region, in der wir tätig sind, auf Bedrohungen wie den Missbrauch von Zugangsdaten, Ausspähversuche und Kommunikation mit als bösartig bekannten Hosts; die Ergebnisse werden vom Betriebsteam überprüft.
• Alarmierung: CloudWatch-Alarme zu Datenbanken, Caches, Load Balancern, API Gateway und ECS-Task-Lebenszyklusereignissen benachrichtigen das Betriebsteam über SNS; die Anwendungsleistung wird in Datadog überwacht; der Zustand der Infrastruktur, Warteschlangen, Kosten und Hinweise auf veraltete Komponenten je Umgebung werden in der Überwachungskonsole der Betriebsplattform konsolidiert.
• Öffentliche Statusseite: Die Verfügbarkeit der Plattform wird extern überwacht und unter https://status.passportscan.net veröffentlicht, mit automatischer Kommunikation zu Vorfällen und Wartungsarbeiten.
• Reaktion auf Sicherheitsvorfälle: Ein dokumentiertes Verfahren für die Reaktion auf Vorfälle und Datenschutzverletzungen (Incident Response & Data Breach Procedure) definiert Schweregrade, Rollen und Eskalation. Verletzungen des Schutzes personenbezogener Daten werden den betroffenen Kunden unverzüglich, in jedem Fall jedoch innerhalb von 48 Stunden, gemäß dem Auftragsverarbeitungsvertrag gemeldet sowie, soweit erforderlich, der Aufsichtsbehörde innerhalb von 72 Stunden (Art. 33 DSGVO).
• Offenlegung von Schwachstellen: Sicherheitsforscher können Probleme gemäß der Richtlinie zur Offenlegung von Schwachstellen (Vulnerability Disclosure Policy) melden (security@passportscan.net).

9. Geschäftskontinuität und Notfallwiederherstellung

• Die Produktionsumgebung läuft auf verwalteten AWS-Diensten über drei Verfügbarkeitszonen in eu-west-1: Der Aurora-Speicher wird sechsfach über die drei Zonen repliziert, zentrale Dienste führen mindestens zwei Tasks verteilt über die Zonen mit automatischer lastabhängiger Skalierung aus, und ECS ersetzt einen ausgefallenen Task automatisch in einer intakten Zone hinter den Load Balancern. Bereitstellungen verwenden einen Circuit Breaker, der automatisch ein Rollback durchführt, wenn eine neue Version ihre Zustandsprüfungen nicht besteht.
• Datenbanken können auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungsfensters von 15 Tagen wiederhergestellt werden; das Wiederherstellungsverfahren ist Teil der jährlichen Notfallwiederherstellungsübung.
• Eine Business-Impact-Analyse sowie ein Plan für Geschäftskontinuität und Notfallwiederherstellung definieren Wiederherstellungsziele für die Plattform (Recovery Time Objective unter zwei Stunden für den zentralen Check-in-Dienst; Recovery Point Objective in der Größenordnung von Minuten dank Point-in-Time-Recovery).
• Abhängigkeiten von Dritten (Cloud-Anbieter, Identitätsanbieter, Zahlungsdienstleister, Protokollverwaltung, Bot-Schutz und Geschäftskommunikationsdienste) werden im Rahmen des Lieferantensicherheitsprozesses bewertet und in der Unterauftragsverarbeiter-Liste aufgeführt.

10. Unterauftragsverarbeiter

Dritte, die personenbezogene Daten von Kunden im Auftrag von GlobeID verarbeiten, sind mit ihrem Zweck und Verarbeitungsort in der öffentlichen Unterauftragsverarbeiter-Liste unter https://www.passportscan.net/sub-processor/ aufgeführt. Kunden werden über Ergänzungen gemäß dem Auftragsverarbeitungsvertrag benachrichtigt.

11. Geteilte Verantwortung

GlobeID ist für die Sicherheit der Plattform wie oben beschrieben verantwortlich. Kunden bleiben verantwortlich für: die Verwaltung ihrer Benutzer und Zugangsdaten (einschließlich der Aktivierung der MFA), die Absicherung der für den Zugriff auf die Plattform verwendeten Geräte und Netzwerke, die rechtmäßige Konfiguration der Aufbewahrungs- und regionalen Speicheroptionen, die Bereitstellung von Datenschutzhinweisen für Gäste sowie die Sicherheit aller von ihnen angebundenen PMS- oder Drittsysteme.

12. Kontakt

Sicherheitsfragen und Fragebögen: security@passportscan.net Datenschutz und Datenschutzbeauftragter: privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublin 7, D07 P4AX, Irland (CRO 559612)