Sicherheit
Sicherheit, die sich wie Gastfreundschaft anfühlt.
Ein Identity Provider ist nur so gut wie die Mauern zwischen seinen Mandanten und die Sorgfalt, mit der er Secrets behandelt. So ist Usher Identity gebaut. Wir beschreiben, was die Software tut; Zertifizierungen nehmen wir nicht für uns in Anspruch.
Architektur
Getrennte Domains, getrennte Netzwerke.
Die eigenen Seiten von Usher Identity und der Issuer jedes Kunden liegen auf unterschiedlichen registrierbaren Domains. Die Datenbanken stehen in einem Netzwerk ohne Zugang zum Internet, und der einzige Weg hinaus führt über einen Proxy, der prüft, wohin es geht.
- Caddy terminiert TLS für jeden Host und entfernt Header, die nur die eigenen Dienste von Usher Identity setzen dürfen.
- Die Auth-Schicht antwortet für jede Umgebung und unterscheidet sie anhand des Hosts; nichts wird für einen Host zwischengespeichert und an einen anderen ausgeliefert.
- Jeder Dienst spricht mit Valkey als eigener Nutzer, beschränkt auf seine eigenen Schlüssel. Einen Standardnutzer gibt es nicht.
- Anweisungen, die Tokens oder Codes enthalten, werden nie mit ihren Werten ins Datenbank-Log geschrieben.
Das Internet
Menschen, deine Apps, deine Server
Der Edge
Caddy: TLS, HSTS, entfernt interne Header
usheridentity.com
Website und Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Auth-Schicht
Issuer und Lobby jeder Umgebung
Datennetzwerk · kein Weg nach draußen
Postgres
Ein Schema pro Umgebung
Valkey
Jeder Dienst auf seine eigenen Schlüssel beschränkt
Der einzige Weg nach draußen
Egress-Proxy
Für jede URL, die ein Kunde angibt
Discovery, JWKS, Logout
Nur öffentliche Adressen
Isolation
Nichts geteilt, worauf es ankommt.
Jede Umgebung eines Projekts bekommt ihr eigenes Postgres-Schema, eigene Signaturschlüssel und eigene Secrets, versiegelt mit ihrem eigenen Datenschlüssel. Ihr Issuer ist ein Host auf der Mandanten-Domain, und ihre Cookies sind Host-only: Ein Browser sendet die Cookies einer Umgebung nie an eine andere.
usheridentity.com
Die Website, Usher Identity Console, Konten bei Usher Identity
*.usherid.com
Ein Issuer pro Umgebung, auf einer eigenen Domain
Nutzer, Sitzungen und Tokens liegen in einem Schema, das eigens für diese Umgebung angelegt ist. Abfragen laufen gegen dieses Schema, nie gegen eine gemeinsame Tabelle mit Mandantenspalte.
Kopiere das versiegelte Google-Client-Secret aus der Produktionsumgebung von Acme in die Produktionsumgebung von Northwind.
Verschlüsselung im Ruhezustand
Envelope Encryption, an ihren Ort gebunden.
Secrets, die du Usher Identity anvertraust, werden mit AES-256-GCM unter einem Datenschlüssel versiegelt, der zu genau einer Umgebung gehört. Die Datenschlüssel sind ihrerseits mit einem versionierten Hauptschlüssel verschlüsselt, der außerhalb der Datenbank liegt.
- Datenschlüssel pro Umgebung
- Wird der Datenschlüssel einer Umgebung kompromittiert, verrät das nichts über den einer anderen.
- AAD-Bindung
- Umgebung und Zweck sind in jeden Chiffretext eingebunden, sodass sich ein Wert nicht zwischen Zeilen oder Mandanten verschieben lässt.
- Versionierte Schlüssel
- Jeder versiegelte Wert vermerkt die Schlüsselversion, mit der er erstellt wurde. So lassen sich Schlüssel rotieren und alte Werte neu verschlüsseln.
- Authentifiziert
- Dank des GCM-Tags lässt sich ein manipulierter Wert gar nicht erst öffnen, statt zu etwas anderem entschlüsselt zu werden.
Hauptschlüssel
Außerhalb der Datenbank aufbewahrt, versioniert
Datenschlüssel, einer pro Umgebung
Mit dem Hauptschlüssel verschlüsselt
Das Secret
Mit AES-256-GCM unter dem Datenschlüssel versiegelt
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Praktiken
Die Details, mit Sorgfalt umgesetzt.
Passwörter, falls du sie nutzt
Gehasht mit Argon2id zu den von OWASP empfohlenen Kosten (19 MiB, zwei Durchläufe), mit einer Obergrenze für gleichzeitige Berechnungen, damit eine Flut von Anmeldungen den Dienst nicht lahmlegen kann. Neue Passwörter werden über die Range-API von Have I Been Pwned mit bekannten Datenlecks abgeglichen; die API sieht dabei nur ein kurzes Präfix des Passwort-Hashs. Die Mindestlänge beträgt standardmäßig 12 Zeichen.
Nichts gespeichert, was sich wiederverwenden ließe
Client-Secrets, Tokens, Magic-Link-Tokens und Codes per E-Mail werden gehasht gespeichert. Backup-Codes werden verschlüsselt. Ein Autorisierungscode gilt fünf Minuten; ein Code per E-Mail erlaubt drei Versuche.
Rate Limits an jeder Tür
Anmeldung, Registrierung, Codes per E-Mail, Magic Links, das Zurücksetzen von Passwörtern und die Prüfung zweiter Faktoren haben jeweils ein eigenes Limit: zum Beispiel zehn Anmeldungen mit Passwort pro Minute und fünf Codes per E-Mail alle zehn Minuten.
Eine strikte Content-Security-Policy
Jede Seite der Lobby bekommt eine frische Nonce und eine darauf aufgebaute Richtlinie: Es laufen nur Skripte dieses Origins, die die Nonce tragen, Formulare senden nur an denselben Origin, und andere Websites können die Seite nicht in einen Frame einbetten.
Ein Audit-Log, dem du vertrauen kannst
Änderungen an Workspaces, Projekten und Umgebungen werden in ein Log geschrieben, an das sich nur anhängen lässt. Jeder Eintrag ist per Hash mit dem vorherigen verkettet, sodass ein geänderter oder fehlender Eintrag auffällt.
Ein Egress-Proxy für Kunden-URLs
Jede Anfrage, die Usher Identity an eine von einem Kunden angegebene Adresse stellt (OIDC-Discovery, JWKS, Back-Channel-Logout), verlässt das System über einen einzigen Proxy. Er löst den Namen einmal auf, lehnt private, Loopback-, Link-Local- und Cloud-Metadaten-Adressen ab und verbindet sich mit genau der Adresse, die er geprüft hat. So kann DNS-Rebinding aus einer Kunden-URL keine interne machen.
Handles, die nie zweimal vergeben werden
Das Handle einer Produktionsumgebung ist das erste Label ihres Issuers. Console ist nur auf Einladung zugänglich, eine wegen Phishing gemeldete Lobby wird gesperrt, und ein einmal genutztes Handle wird nie wieder vergeben, weil alte Apps seinen Tokens vielleicht noch vertrauen.
Sitzungen, die enden, wenn du es sagst
Usher Identity prüft bei jeder Anfrage seine eigenen Sitzungen, statt einer zwischengespeicherten Kopie zu vertrauen. Eine Sitzung, die du beendest, ist also sofort vorbei. Access-Tokens sind kurzlebig (standardmäßig zehn Minuten), und deine API kann sie per Introspection prüfen.
Responsible Disclosure
Etwas gefunden? Sag es uns zuerst.
Wenn du glaubst, eine Sicherheitslücke in Usher Identity gefunden zu haben, möchten wir davon hören – und arbeiten mit dir daran, sie zu beheben.
- Was du gefunden hast, wo, und wie es sich reproduzieren lässt.
- Was jemand damit anstellen könnte, so wie du es verstehst.
- Wie wir dich erreichen können und ob du namentlich genannt werden möchtest.
Bitte teste nur mit Umgebungen, die dir gehören, greif nicht auf Daten anderer zu, und gib uns angemessen Zeit, das Problem zu beheben, bevor du es öffentlich machst. Eine Seite, die sich als Anmeldeseite von Usher Identity ausgibt, meldest du unter Missbrauch melden.