Wie DeepMirror deinen Lebenslauf schützt, ohne deinen privaten Kontext zu veröffentlichen

Ein Lebenslauf kann weit mehr als deinen beruflichen Werdegang enthalten.

Dazu gehören möglicherweise Name, Wohnort, Kontaktdaten, Arbeitgeber, Ausbildung, berufliche Lücken, Ambitionen und Hinweise auf persönliche Umstände. Ein reflektierender Check-in kann noch sensibler sein: Er beschreibt vielleicht Unsicherheit, Konflikte, Beziehungen oder eine Entscheidung, die du noch niemandem mitgeteilt hast.

Deshalb ist die Frage berechtigt:

Was passiert, wenn ich diese Informationen über das Internet teile? Werden sie öffentlich auffindbar oder bleiben sie privat?

DeepMirror schützt gespeicherte Lebensläufe, in der Cloud gespeicherte Check-ins und zugehörige erfasste persönliche Datensätze durch Envelope-Verschlüsselung auf Anwendungsebene mit Google Cloud Key Management Service.

Wer nur die betreffenden Datenbankeinträge erhielte, bekäme keinen lesbaren Lebenslauf- oder Reflexionstext. Die benötigten kryptografischen Schlüssel werden getrennt verwaltet. Ihre Verwendung ist über die Cloud-Identität der Anwendung eingeschränkt.

Gleichzeitig kann DeepMirror bewusst bereitgestellte Informationen für personalisierte berufliche Vorschläge nutzen. Privatsphäre und Nutzen widersprechen sich nicht: Informationen müssen kein öffentliches Profil werden, um nützlich zu sein.

Privates Matching unterscheidet sich von öffentlicher Auffindbarkeit

Berufliche Netzwerke und private Karrierewerkzeuge erfüllen unterschiedliche Zwecke.

Ein berufliches Netzwerkprofil soll anderen helfen, dich zu finden. Abhängig von deinen Einstellungen können Profilinformationen angemeldeten Mitgliedern, öffentlichen Suchmaschinen, nicht angemeldeten Personen oder zugelassenen externen Diensten angezeigt werden.

LinkedIn bietet Einstellungen zur Begrenzung dieser Sichtbarkeit; nicht jedes Profil ist öffentlich. Die Dokumentation erklärt dennoch, dass freigegebene öffentliche Profilteile in Suchmaschinen erscheinen können und Änderungen dort erst nach Wochen oder Monaten sichtbar werden. Laut LinkedIn sind Profile grundsätzlich für angemeldete Mitglieder sichtbar, abhängig von Einstellungen und bestimmten Ausnahmen.

Diese Sichtbarkeit ist nicht zwangsläufig eine Sicherheitslücke. Auffindbarkeit gehört zum Zweck eines beruflichen Netzwerks. Es ist einfach ein anderes Datenschutzmodell.

Entscheidend ist die Unterscheidung zwischen Veröffentlichung und autorisierter Verarbeitung.

Veröffentlichung macht Informationen einem Publikum zugänglich. Sobald jemand sie sehen kann, verhindern technische Kontrollen nicht jeden Screenshot, jede Notiz, jeden Download oder jede Erinnerung. Auch nach einer Änderung der Sichtbarkeit können frühere Kopien außerhalb der Kontrolle der ursprünglichen Plattform bleiben.

Autorisierte Verarbeitung bedeutet, Informationen zu verwenden, weil du ein bestimmtes Ergebnis angefordert hast. Dafür müssen sie weder anderen Nutzern angezeigt noch in ein öffentliches Verzeichnis aufgenommen oder von Suchmaschinen indexiert werden.

Diese Trennung ermöglicht DeepMirror, Informationen zu berücksichtigen, deren Veröffentlichung oft unangebracht wäre.

Ein öffentliches Profil könnte dich als Produktmanager mit Erfahrung in Gesundheitstechnologie beschreiben. Private Reflexionen könnten zeigen, dass du frühe Produktentwicklung liebst, ständige Abstimmungen mit Interessengruppen dich aber erschöpfen. Das kann wichtig sein, um eine passende Stelle einzuschätzen, gehört jedoch nicht auf ein öffentlich durchsuchbares Profil.

DeepMirror kann diesen privaten Kontext für die von dir angeforderte Funktion nutzen, ohne ihn zu veröffentlichen. Das unterstützt ein aussagekräftigeres Matching als bloß höhere Profilsichtbarkeit. Es garantiert nicht, dass jeder Vorschlag passt: Berufliche Passung ist teilweise subjektiv, Informationen können fehlen, und Menschen wie Rollen verändern sich.

Schutz beginnt vor der Speicherung

Im Verlauf eines Lebenslaufs oder Check-ins gibt es mehrere getrennte Schritte:

1. Die Informationen gelangen von deinem Gerät zu DeepMirror.
2. Die Anwendung prüft, wer die Anfrage stellt.
3. Sie verarbeitet die angeforderten Informationen.
4. Für die Cloud-Speicherung bestimmte Informationen werden verschlüsselt.
5. Die verschlüsselten Daten werden gespeichert.
6. Bei einer späteren autorisierten Anfrage werden sie geladen und entschlüsselt.

Für jeden Schritt sind andere Kontrollen nötig. „Die Datenbank ist verschlüsselt“ lässt zu viele Fragen offen.

Verschlüsselung während der Übertragung

Verbindungen zur bereitgestellten DeepMirror-Anwendung verwenden HTTPS. Transport Layer Security, kurz TLS, schützt die Kommunikation zwischen Browser und Cloud-Dienst vor gewöhnlichem Abhören im Netzwerk.

DeepMirror läuft auf Google Cloud Run. Laut Google beendet dessen Frontend-Infrastruktur die öffentliche TLS-Verbindung und leitet den Verkehr über einen verschlüsselten Kanal innerhalb der Cloud-Run-Infrastruktur weiter. Das ist Transportverschlüsselung. Sie schützt den Kommunikationskanal und ist von der Anwendungsverschlüsselung gespeicherter persönlicher Daten zu unterscheiden.

Anwendungsverschlüsselung vor dem Speichern in der Datenbank

Firestore verschlüsselt Daten automatisch vor dem Schreiben auf Datenträger. DeepMirror verlässt sich nicht allein auf diesen Plattformschutz.

Bei erfassten persönlichen Datensätzen verschlüsselt DeepMirror die sensiblen Nutzdaten bereits in der Anwendung, bevor sie an Firestore gesendet werden. Firestore erhält einen schon verschlüsselten Wert und schützt ihn zusätzlich durch die eigene Speicherverschlüsselung.

Die Datenbank erhält den erfassten persönlichen Text nicht als gewöhnliches lesbares Feld. Diese zusätzliche Ebene verbessert den Schutz bei einer Offenlegung von Firestore-Daten ohne gleichzeitigen Zugriff auf die für die Schlüsselverwaltung autorisierte Identität der Anwendung.

Ein eigener Zufallsschlüssel für jedes Datenpaket

DeepMirror verwendet nicht einen einzigen statischen Schlüssel direkt für alle Lebensläufe und Check-ins.

Jedes verschlüsselte Datenpaket erhält einen neu erzeugten zufälligen Datenschlüssel, kurz DEK. Er verschlüsselt genau dieses Paket mit authentifizierter Fernet-Verschlüsselung.

Ein gemeinsamer Datenschlüssel für große Mengen persönlicher Informationen würde einen unnötig großen Schadensbereich schaffen. Eigene Schlüssel pro Paket reduzieren die Datenmenge, die unmittelbar von einem einzelnen DEK abhängt.

Fernet bietet zwei zusammengehörige Eigenschaften:

• Vertraulichkeit: Ohne Schlüssel sind die Nutzdaten nicht lesbar.
• Integrität und Authentizität: Nicht autorisierte Änderungen am verschlüsselten Wert werden beim Entschlüsseln erkannt.

Werden verschlüsselte Bytes verändert, gekürzt oder ersetzt, entsteht daraus nicht stillschweigend veränderter Lebenslauftext. Die Authentifizierung schlägt fehl und das Datenpaket wird zurückgewiesen.

Cloud KMS schützt den Datenschlüssel getrennt

Auch der Datenschlüssel selbst muss geschützt sein. Ihn im Klartext neben dem verschlüsselten Lebenslauf abzulegen, würde den Zweck der Verschlüsselung unterlaufen.

DeepMirror sendet deshalb den zufälligen DEK an Google Cloud Key Management Service. Ein zentral verwalteter Schlüssel zur Schlüsselverschlüsselung verschlüsselt ihn – er „verpackt“ ihn. Nur diese verpackte Form wird zusammen mit den verschlüsselten Nutzdaten gespeichert.

Die versionierte Verschlüsselungshülle enthält:

• die Version des Verschlüsselungsformats,
• eine zugelassene KMS-Schlüsselreferenz,
• den verpackten Datenschlüssel und
• die verschlüsselten persönlichen Nutzdaten.

Zum Entschlüsseln muss die Anwendung den Datensatz laden, sich mit ihrer Dienstidentität bei Cloud KMS authentifizieren, den DEK durch KMS entpacken lassen und mit ihm den Inhalt authentifizieren und entschlüsseln.

Das zentrale KMS-Schlüsselmaterial liegt weder in der Datenbank noch im Anwendungscode. Ein autorisierter Aufrufer fordert eine kryptografische Operation von KMS an, statt den Hauptschlüssel selbst abzurufen.

Warum Envelope-Verschlüsselung wichtig ist

Stell dir vor, ein Angreifer erhält einen verschlüsselten Lebenslaufdatensatz aus der Datenbank.

Er findet den Chiffretext, einen verschlüsselten Datenschlüssel, die Referenz auf dessen KMS-Schlüssel und begrenzte betriebliche Metadaten. Den Datenschlüssel im Klartext oder das Material des KMS-Hauptschlüssels findet er nicht.

Der verschlüsselte Datenbankwert allein reicht deshalb nicht. Zusätzlich wäre Zugriff auf eine Identität nötig, die den richtigen KMS-Schlüssel verwenden darf.

Dadurch entstehen zwei Schutzgrenzen:

• Die Speichergrenze enthält Chiffretext.
• Die Grenze der Schlüsselverwaltung kontrolliert, ob dieser entschlüsselt werden darf.

Beide Grenzen müssen geschützt werden. Eine Offenlegung der Datenbank allein macht die erfassten persönlichen Inhalte jedoch nicht lesbar.

Die Verschlüsselung ist an die Nutzeridentität gebunden

Beim Verpacken des DEK übergibt DeepMirror zusätzliche authentifizierte Daten, die aus der normalisierten Nutzeridentität abgeleitet werden.

Diese Daten sind nicht geheim. Sie binden die kryptografische Operation an einen bestimmten Kontext. Cloud KMS verlangt beim Entpacken denselben authentifizierten Kontext.

Wird eine Verschlüsselungshülle vom Datenbankort eines Nutzers an den eines anderen kopiert, lässt sie sich deshalb nicht als Datensatz der zweiten Person entschlüsseln. Der kryptografische Kontext stimmt nicht mehr.

Das ergänzt die übliche Zugriffskontrolle über Datenbankpfade durch Nutzertrennung beim Entpacken der Schlüssel.

Nur zugelassene KMS-Schlüssel werden akzeptiert

Die Hülle verweist auf den KMS-Schlüssel, der ihren DEK verpackt hat. Daraus entsteht eine Sicherheitsfrage: Könnte ein veränderter Datenbankeintrag die Anwendung dazu bringen, einen beliebigen KMS-Schlüssel zu verwenden?

DeepMirror nutzt dafür eine ausdrückliche Positivliste. Nur konfigurierte KMS-Schlüsselressourcen werden akzeptiert. Verweist eine Hülle auf einen anderen Schlüssel, wird die Entschlüsselung vor dem KMS-Aufruf abgelehnt.

So können Datenbankinhalte die Anwendung nicht zu einem beliebig einsetzbaren KMS-Aufrufer machen.

Bei Konfigurationsfehlern wird nicht ungeschützt gespeichert

Gefährlich wäre ein stiller Rückfall auf schwächere Verschlüsselung, weil KMS nicht verfügbar ist oder bei der Bereitstellung fehlt.

DeepMirror ist im Produktivbetrieb so ausgelegt, dass es im Fehlerfall geschlossen bleibt: Für erfasste Schreibvorgänge ist KMS-gestützte Verschlüsselung erforderlich. Fehlt die nötige Konfiguration, scheitert das Speichern, statt den Schutz unbemerkt zu verringern.

Bei einem schweren Konfigurationsproblem kann Speichern dadurch vorübergehend unmöglich sein. Ein unsicherer Schreibvorgang wird aber nicht als erfolgreich geschützt dargestellt.

Welche Informationen zum Lebenslauf werden verschlüsselt?

Bei gespeicherten Lebensläufen umfasst das verschlüsselte Paket:

• den von der Anwendung verwendeten Lebenslauftext,
• den ursprünglichen Dateinamen,
• den gemeldeten Inhaltstyp und
• den im Paket enthaltenen Upload-Zeitstempel.

Wiederverwendbare persönliche Nachweise aus dem Lebenslauf werden ebenfalls verschlüsselt gespeichert. Career-Mirror-Berichte – mit persönlichem Berichtstext, Nutzeranfrage, Region, Aktion und gespeicherter Auswahl – nutzen denselben Verschlüsselungsweg auf Anwendungsebene.

Der Schutz reicht damit über das hochgeladene Dokument hinaus. Persönlich aufschlussreiche Schlussfolgerungen und erzeugte Datensätze sollen keine Klartextkopie der schon beim Eingang verschlüsselten Informationen werden.

Begrenzte betriebliche Metadaten bleiben außerhalb des Pakets, damit Datensätze ohne vollständige Entschlüsselung gefunden, sortiert und verwaltet werden können. Dazu können Dokumentkennungen, Erstellungs- oder Änderungszeiten, Versionsnummern, Ergebnisanzahlen und ein Wahrheitswert gehören, der gespeicherte Einträge in einem Bericht anzeigt.

Die Verschlüsselung verbirgt den erfassten Inhalt, nicht unbedingt Existenz, ungefähren Zeitpunkt, Art oder Anzahl der Datensätze.

Wie Check-ins in der Cloud geschützt werden

Bei in der Cloud gespeicherten Check-ins enthält das verschlüsselte Paket die sensiblen Inhalte für ihre Wiederherstellung, darunter Reflexionsantworten und erzeugte Rückmeldungen. Auch relevante abgeleitete persönliche Daten nutzen in mehreren DeepMirror-Bereichen den gemeinsamen Verschlüsselungsmechanismus.

DeepMirror bietet unterschiedliche Speicheroptionen:

• Cloud-Synchronisierung speichert das erfasste Check-in-Paket verschlüsselt in der Cloud.
• Gerät und Cloud behält eine Gerätekopie und zusätzlich den verschlüsselten Cloud-Datensatz.
• Nur Gerät verhindert die dauerhafte Speicherung des eingereichten Check-ins in Firestore.

„Nur Gerät“ ist eine Speicherentscheidung. Die Anwendung erhält den Check-in weiterhin während der Anfrage und verarbeitet ihn für die angeforderte Rückmeldung. Es bedeutet weder Offline-Verarbeitung noch das Versprechen, dass Klartext den Server nie erreicht.

Authentifizierung kommt vor Entschlüsselung

Verschlüsselung schützt gespeicherte Daten. Sie entscheidet nicht, wer sie anfordern darf.

DeepMirror verwendet im Browser die Google-Anmeldung und prüft das Identitätstoken vor dem Aufbau einer Anwendungssitzung. Der Anmeldeablauf umfasst die Verarbeitung des State-Werts, des PKCE-Verifiers und die Prüfung der Token-Zielgruppe.

Das Sitzungscookie im Produktivbetrieb ist als Secure, HttpOnly und SameSite=Lax konfiguriert. Geschützte Datensätze liegen unter nutzerbezogenen Firestore-Pfaden und werden mit der Identität der authentifizierten Sitzung geladen. Diese Identität gehört auch zum kryptografischen Kontext für das Entpacken des Datenschlüssels.

Keine Ebene ersetzt die anderen.

Wann existiert Klartext?

Das ist die wichtigste Grenze, die du verstehen solltest.

DeepMirror kann keine personalisierten Funktionen anbieten und zugleich alle dafür nötigen Informationen dauerhaft vor dem eigenen Server verbergen. Wenn du eine Funktion anforderst, die Lebenslauf oder Reflexionsverlauf benötigt, muss die Anwendung den erforderlichen Klartext vorübergehend wiederherstellen.

Der vorgesehene Sicherheitsablauf ist:

1. Eine authentifizierte Anfrage identifiziert den Nutzer.
2. Die Anwendung lädt den nutzerbezogenen verschlüsselten Datensatz.
3. KMS autorisiert das Entpacken des Datenschlüssels.
4. Die Anwendung authentifiziert und entschlüsselt das Paket.
5. Der für die Funktion erforderliche Kontext wird ausgewählt.
6. Autorisierte Verarbeitungsdienste können die für diesen Vorgang erforderlichen Informationen erhalten.
7. Erfasste Ergebnisse werden vor dem Schreiben in die Datenbank verschlüsselt.

Die genaue Bezeichnung lautet deshalb verschlüsselte serverseitige Verarbeitung, nicht Ende-zu-Ende-Verschlüsselung.

Bei strenger Ende-zu-Ende-Verschlüsselung könnte nur das Gerät des Nutzers entschlüsseln. Weder der DeepMirror-Server noch Verarbeitungsanbieter könnten Klartext wiederherstellen. Für Funktionen mit serverseitiger Personalisierung wäre dafür eine grundlegend andere Architektur nötig.

Wogegen der Schutz hilft

Was Verschlüsselung allein nicht löst

Verschlüsselung beseitigt nicht jedes Sicherheitsrisiko. Voraussetzungen und Wahrscheinlichkeit unterscheiden sich erheblich zwischen Szenarien.

Eine Offenlegung nur der Datenbank ist eine realistische Klasse von Cloud-Sicherheitsvorfällen, gegen die Envelope-Verschlüsselung unmittelbar schützt. Um geschützte Datensätze zu lesen, wäre ein weiterer Fehler nötig: Zugriff auf eine autorisierte Anwendungsidentität oder eine andere Möglichkeit, den richtigen KMS-Schlüssel zu nutzen.

Eine gleichzeitige Kompromittierung von Datenbank, Anwendungslaufzeit und Schlüsselrechten ist grundsätzlich schwieriger als der Zugriff auf einen Datenbankexport, weil mehrere unabhängige Kontrollen überwunden werden müssen. Sie ist deshalb weniger wahrscheinlich, hätte aber größere mögliche Auswirkungen.

Eine gestohlene authentifizierte Sitzung ist ein alltäglicheres Risiko für Nutzer. Wer einen angemeldeten Browser übernimmt, kann möglicherweise als diese Person handeln, ohne die Verschlüsselung anzugreifen. Sichere Cookies, Kontoschutz, konsequentes Abmelden und Mehrfaktorauthentifizierung bleiben wichtig.

Versehentliche Offenlegung über Protokolle oder unnötig umfangreichen Verarbeitungskontext ist ein weiteres betriebliches Risiko. Dafür muss keine Kryptografie gebrochen werden. Deshalb zählen Datenminimierung, Bereinigung von Protokollen, eingeschränkte Rechte und die Kontrolle der Verarbeitungsanbieter ebenso.

Es gibt keinen aussagekräftigen Datensatz, aus dem sich verantwortbar Zahlenwahrscheinlichkeiten für diese Szenarien ableiten ließen. Die Einschätzung bleibt qualitativ:

• Eine reine Datenbankoffenlegung ist plausibel genug, um gezielt dagegen zu schützen.
• Ein Angriff über mehrere Schutzgrenzen verlangt mehr Voraussetzungen und ist entsprechend schwieriger.
• Missbrauch von Sitzungen und Endgeräten bleibt ein praktisches Risiko.
• Kein internetverbundenes System kann ehrlich null Risiko versprechen.

Was du tun kannst

• Schütze dein Google-Konto mit einem starken Passwort und Mehrfaktorauthentifizierung.
• Melde dich auf gemeinsam genutzten Geräten ab.
• Wähle die passende Speicheroption für deine Check-ins.
• Vermeide unnötige persönliche Kennungen in Freitextanfragen.
• Entferne nicht benötigte Lebenslaufangaben wie Ausweisnummer oder handschriftliche Unterschrift.
• Nutze DeepMirrors Export- und Löschfunktionen, wenn du gespeicherte Informationen abrufen oder entfernen möchtest.

Zusammenfassung

Ein Lebenslauf muss nicht öffentlich sichtbar sein, um nützlich zu sein.

Berufliche Netzwerkprofile helfen Menschen, gefunden zu werden. Je nach Einstellung sind Informationen für Mitglieder, Suchmaschinen oder zugelassene verbundene Dienste sichtbar. Das kann wertvoll sein, bedeutet aber, dass ein Publikum das Profil lesen soll.

DeepMirror nutzt ein anderes Modell. Lebenslauf, Check-ins und erfasste abgeleitete Datensätze sind private Kontodaten statt öffentliche Profilinhalte. Sensible gespeicherte Pakete werden einzeln authentifiziert verschlüsselt. Jeder Datenschlüssel wird separat durch Google Cloud KMS verpackt, an die Nutzeridentität gebunden und auf zugelassene Schlüsselressourcen beschränkt.

Wenn du eine personalisierte Funktion anforderst, kann die Anwendung relevante Informationen unter kontrollierter Autorisierung vorübergehend entschlüsseln. Das ermöglicht sinnvolle berufliche Vorschläge, ohne den zugrunde liegenden Lebenslauf, private Vorlieben oder Reflexionen zu veröffentlichen.

Die ehrliche Grenze: Es handelt sich um verschlüsselte serverseitige Verarbeitung, nicht um Ende-zu-Ende-Verschlüsselung. Autorisierte Anwendungskomponenten müssen die für deine Anfrage erforderlichen Informationen erreichen können. Der Schutz liegt in begrenztem Zugriff, der Trennung von Schlüsseln und gespeicherten Daten, Manipulationserkennung und unlesbaren Inhalten bei einer reinen Datenbankoffenlegung.

Dein privater Kontext kann DeepMirror helfen zu verstehen, was zu dir passen könnte, ohne zu einem weiteren öffentlichen Eintrag über dich zu werden.