Wie Verschlüsselung funktioniert,
und was es schützt.

Verschlüsselt bedeutet nicht immer den gleichen Schutz.

Erwägen Sie die Speicherung einer Lieferadresse. Transport-, Festplatten- und Datenverschlüsselung schützen unterschiedliche Grenzen.

Transportverschlüsselung / TLS

Schützt die Kommunikation zwischen Browser und Server. Der empfangende Server kann die Adresse verarbeiten; TLS schützt Datenbankinhalte oder eine kompromittierte Anwendung nicht automatisch.

Speicherverschlüsselung

Schützt vor gestohlenen Festplatten und Sicherungsmedien. Wenn die Datenbank normale Lesevorgänge transparent entschlüsselt, können Benutzer mit SQL-Lesezugriff weiterhin Adressen sehen.

Verschlüsselung vor der Speicherung

Verschlüsseln Sie die Adresse in der Anwendung und speichern Sie Chiffretext. Trennen Sie Datenbank-Leseberechtigungen von Schlüsselnutzungsberechtigungen, um sich vor reinem Datenbankdiebstahl zu schützen.

OneNym kombiniert diese Ebenen mit zweckspezifischer Autorisierung. Eine starke Kryptografie ist ebenso wichtig wie die Begrenzung der Entschlüsselungspfade.

Die gesamte Adresse wird im Speicher entschlüsselt; nur erlaubte Felder gelangen in die Antwort. Es ist keine Verschlüsselung je Feld. Empfänger müssen Klartext schützen, Kunden auch Protokolle und Speicher vor der Registrierung. Einstieg und Hilfe

Schützen Sie einen Datenschlüssel mit einem separaten Schlüssel.

Ein DEK verschlüsselt die Adresse; Ein KEK schützt diesen DEK. Dies ist eine Umschlagverschlüsselung. Es folgt ein Beispiel mit einem dedizierten DEK für jede Adresse.

1. Generieren Sie einen DEK mithilfe einer kryptografisch sicheren Zufallsquelle und verschlüsseln Sie die Adresse mit authentifizierter Verschlüsselung.
2. Umschließen Sie den DEK mit einem KEK, der von einem Schlüsselverwaltungsdienst verwaltet wird. Durch das Wrapping wird der Schlüssel verschlüsselt und geschützt.
3. Speichern Sie Chiffretext, den verpackten DEK, die Schlüsselversion und Entschlüsselungsmetadaten. Speichern Sie keinen Klartext-DEK in der Datenbank.
4. Wenn eine Adresse benötigt wird, autorisieren Sie den Mandant, den Zweck, den Datensatz und die Felder.
5. Der autorisierte Dienst entpackt den DEK, entschlüsselt die Adresse und gibt nur zulässige Felder zurück.

Datenbankschlüsselverwaltungsdienst
Verschlüsselte Adresse KEK zum Schutz des DEK
Umschlossene DEK-Schlüsselnutzungsberechtigungen und -Überprüfung
Nonce-/Tag-/Schlüsselversion
          ↓ Autorisierter Service greift auf beides zu
       Temporäre Entschlüsselung → Versandabwicklung

Selbst ein nicht exportierbarer KEK kann missbraucht werden, wenn seine Nutzungsberechtigungen gestohlen werden. Separater Datenbank- und KMS-Zugriff, Verwaltung, Notfallbetrieb und Dienstanmeldeinformationen. Schützen Sie auch entschlüsselten Speicher und Schlüsselcaches.

Verwalten Sie KEKs über Cloud-Schlüsseldienste.

Der Vault verwaltet seinen KEK in Azure Key Vault. Trennen Sie Schlüsselrechte zum Schutz der Datenschlüssel (DEK) vom Datenbankzugriff.

Cloud-Dienste steuern Schlüssel und Zugriff auf kryptografische Vorgänge. OneNym autorisiert zunächst Mandant, Datensätze, Felder und Zwecke. Geschäftsanwendungen erhalten eingeschränkte Vault-API-Berechtigungen, keinen direkten KEK-Zugriff.

Zwei verschiedene Arten der Schlüsseldrehung.

Durch Drehen eines KEK können DEKs neu verpackt werden, ohne den Chiffretext der Daten zu ändern. Ein kompromittierter DEK erfordert eine Neuverschlüsselung mit einem neuen DEK. Die Rotation kann gestohlenen Klartext oder Kopien alter Schlüssel und Chiffretexte nicht wiederherstellen.

Erkennen Sie Vertretungen und schützen Sie die Vertraulichkeit.

Authentifizierte Verschlüsselung wie AES-GCM erkennt Chiffretextänderungen über ein Authentifizierungs-Tag. Misserfolge ablehnen. Verwenden Sie niemals eine Nonce mit demselben AES-GCM-Schlüssel wieder, auch nicht bei Wiederholungsversuchen und auf mehreren Servern.

Binden Sie Mandanten-ID, Datensatz-ID und Schemaversion als zusätzliche authentifizierte Daten (AAD). Von Mandant A in den Datensatz von Mandant B kopierter Chiffretext schlägt bei der Überprüfung im Vergleich zum erwarteten Mandanten-B-Kontext fehl.

AAD ist nicht verschlüsselt; Geben Sie keine geheimen Adressen ein. Leiten Sie erwartete IDs aus authentifizierten Anfragen und vertrauenswürdigen Datensätzen ab. Das Vertrauen auf IDs, die zusammen mit dem ersetzten Chiffretext bereitgestellt werden, bewahrt die Grenze nicht.

Was bleibt bei einem Verstoß geschützt?

Es wird lediglich eine Datenbankkopie gestohlen

Eine korrekte Verschlüsselung schützt Adressinhalte, wenn Klartextschlüssel und andere Klartextkopien fehlen. Bewerten Sie die Offenlegung von Metadaten wie Anzahl, IDs, Zeitstempel und Größen separat.

Datenbank- und Entschlüsselungsberechtigungen sind gefährdet

Eine Verschlüsselung allein kann den Zugriff nicht verhindern. Begrenzen Sie die Auswirkungen durch bereichsbezogene Autorisierung, Nutzungskontrollen, Anomalieerkennung und Widerruf.

Der Lieferserver ist kompromittiert

Bei der rechtmäßigen Verarbeitung entschlüsselte Adressen können gestohlen werden. Geben Sie keine Felder zurück, die über das hinausgehen, was für die Lieferung erforderlich ist.

Eine Adresse wurde bereits an einen Partner gesendet

Der Widerruf des Tresorschlüssels löscht bereits weitergegebenen Klartext nicht. Regeln Sie auch die Aufbewahrung und Löschung bei Partnern.

Fragen vor der Einführung.

Fragen Sie nicht nur, ob AES verwendet wird: Wer darf Schlüssel nutzen? Ist die Entschlüsselung begrenzt und protokolliert? Wie schnell erreicht ein Widerruf die Caches? Wie wird mit verlorenen Schlüsseln umgegangen? Schutzgrenzen und Betriebsnachweise ermöglichen eine fundierte Bewertung.

Technische Referenzen

Allgemeine Grundlagen zur Verschlüsselung und Schlüsselverwaltung finden Sie in OWASPs Cryptographic Storage Cheat Sheet; zu Schlüsselhierarchien siehe Microsofts Anleitung zur Verschlüsselung gespeicherter Daten. Diese Seite erläutert das Schutzkonzept von OneNym. Schlüssel pro Datensatz sind eine beispielhafte Konfiguration.