Verschlüsselung
Wo Verschlüsselung eingesetzt wird – und wo noch nicht.
Verschlüsselung schützt eine Verifizierung an mehreren unterschiedlichen Stellen: die Verbindung, das Bild, das Secret, das Backup, das Passwort. Wir führen jede einzelne lieber ehrlich auf, als einmal „verschlüsselt“ zu sagen und Sie annehmen zu lassen, das gelte für alles.
Bei der Übertragung
TLS am Edge, erzwungen auch auf der Ledger-Datenbank.
Jede Anfrage an ShieldID wird verschlüsselt, bevor sie die Anwendung erreicht.
- Der öffentliche Edge beendet TLS für jede Verbindung, mit HSTS und einem restriktiven Satz von Sicherheits-Headern, sodass eine Anfrage verschlüsselt ist, bevor sie irgendetwas dahinter erreicht.
- Die primäre Ledger-Datenbank erzwingt TLS bei jeder Verbindung, die sie annimmt. Eine unverschlüsselte Verbindung wird schlicht abgelehnt, nicht nur per Konfiguration unerwünscht.
- Die Anwendung prüft das Zertifikat der Datenbank gegen eine fest hinterlegte Zertifizierungsstelle und kontrolliert den Hostnamen, anstatt dem erstbesten Zertifikat zu vertrauen.
Im Ruhezustand
ID-Bilder und Geburtsdaten sind verschlüsselt. Wir benennen genau, was noch nicht verschlüsselt ist.
„Im Ruhezustand verschlüsselt“ wird oft in einem Atemzug über eine ganze Plattform gesagt. Hier steht, was das heute tatsächlich abdeckt.
- ID-Bilder und das Selfie
- Während der Speicherung mit AES-256-GCM verschlüsselt, bis zur automatischen Bereinigung, die sie löscht.
- Geburtsdatum
- Verschlüsselt gespeichert, nie im Klartext, wo auch immer ein Verifizierungsdatensatz sie enthält.
- Secrets (API-Schlüssel, Datenbank-Zugangsdaten, Signaturschlüssel)
- In einem dedizierten Secrets-Tresor aufbewahrt, nicht in der Anwendungskonfiguration oder im Quellcode.
- Der Rest der Datenbank und allgemeine Speichervolumes
- Derzeit weder auf Festplatten- noch auf Datenbankebene verschlüsselt. Das sagen wir direkt, statt eine lückenlose Abdeckung zu suggerieren.
Secrets
Ein Tresor, tokengeschützt, mit protokollierter Rotation.
Anwendungszugangsdaten liegen nicht verstreut in Konfigurationsdateien.
Zentralisiert
API-Schlüssel, Datenbank-Zugangsdaten und Webhook-Secrets werden in einem dedizierten Secrets-Management-System aufbewahrt und ausschließlich über eine authentifizierte, tokengeschützte API gelesen und geschrieben.
Rotation wird auditiert
Ein dedizierter Rotationsprozess protokolliert jede Änderung von Zugangsdaten und jeden abgelehnten Versuch in einem manipulationssicheren Protokoll, das nur Fingerabdrücke der Werte speichert, niemals die Werte selbst.
Nie in Code oder Konfiguration
Secrets werden beim Start aus dem Tresor gelesen, nicht in den Quellcode eingecheckt oder in einer Umgebungsdatei belassen, die mit einem Deployment ausgeliefert wird.
Backups
Verschlüsselt, bevor sie den Arbeitsspeicher verlassen, mit einer Wiederherstellungsübung, die Sie ohne Eingriff in die Produktion durchführen können.
Ein Backup umfasst die Anwendung, ihre Konfiguration und die Datenbank.
- Mit AES-256 verschlüsselt, unter Verwendung eines Schlüssels aus dem Secrets-Tresor. Ist dieser Schlüssel nicht verfügbar, weigert sich das Backup-Skript, eine unverschlüsselte Datei zu schreiben, statt stillschweigend darauf auszuweichen.
- Es gibt ein dokumentiertes, skriptgesteuertes Wiederherstellungsverfahren, das einen Probemodus in einen temporären Speicherort unterstützt, sodass der Vorgang getestet werden kann, ohne Livedaten anzutasten.
- Backups verbleiben derzeit am selben Standort. Wir bieten weder georedundante Backups noch einen separaten Disaster-Recovery-Standort an und sagen das auch auf den Seiten zu Datenresidenz und Compliance, nicht nur hier.
Passwörter, Sitzungen und API-Schlüssel
Nichts, was Sie authentifiziert, wird in einer Form gespeichert, die jemand lesen und wiederverwenden könnte.
Drei verschiedene Arten von Secrets, drei verschiedene Behandlungen, alle unumkehrbar.
- Passwörter
- Gehasht, nie im Klartext gespeichert oder protokolliert.
- Sitzungstokens
- Das Token im Sitzungs-Cookie Ihres Browsers ist ein zufälliger 32-Byte-Wert, der als HttpOnly-Cookie gesetzt wird.
- API-Schlüssel
- Gespeichert als SHA-256-Hashes. Nur ein kurzes Präfix bleibt im Klartext erhalten, sodass Sie einen Schlüssel in einer Liste erkennen können, ohne dass der vollständige Wert jemals wieder abrufbar ist.
Was diese Seite nicht behauptet
Kein DDoS-Schutz, keine WAF, keine Georedundanz.
Wir befinden uns derzeit weder hinter einem Content-Delivery-Network noch hinter einer Web Application Firewall, und wir behaupten keine Verschlüsselung auf Festplatten- oder Datenbankebene für jedes gespeicherte Byte. Eine einfache Ratenbegrenzung schützt die Anmeldung und andere aufwendige Endpunkte, ist aber noch keine gehärtete, dauerhafte Schutzschicht gegen Missbrauch. Wenn für die eigene Prüfung Ihrer Organisation eine bestimmte Kontrolle wichtig ist, fragen Sie uns direkt, statt anzunehmen, dass ein allgemeiner Ausdruck sie abdeckt.
Fragen
Klare Antworten zur Verschlüsselung.
Lesen Sie, wie Aufbewahrung und Datenspeicherort zusammenhängen.
Verschlüsselung ist nur eine von mehreren Kontrollen. Sehen Sie, was wann gelöscht wird und wo die Daten liegen, solange sie existieren.