--- title: "Rotation von Master- und Signaturschlüsseln sowie Notfallzugriff" description: "Rotieren Sie den Master-Schlüssel zum Schutz gespeicherter Zugangsdaten und verwenden Sie den Notfallzugriff." image: "https://docs.quirelms.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://docs.quirelms.com/de/llms.txt > Use this file to discover all available pages before exploring further. # Rotation von Master- und Signaturschlüsseln sowie Notfallzugriff Die in Abschnitt 14 von 21-compliance.md beschriebenen Kontrollen, nach denen Prüfer ausdrücklich fragen. Diese Seite erläutert das Verfahren; die dabei erzeugten Protokolle sind die Nachweise. ## Die Schlüssel Jede gespeicherte Zugangsinformation wird mit einem neuen Datenschlüssel (DEK) versiegelt. Der DEK wird durch den Master-Schlüssel (KEK) umhüllt; die Referenz des Master-Schlüssels wird daneben gespeichert (`key_ref` oder die Referenz in einem gepackten Wert). Bei einer Rotation des Master-Schlüssels werden die DEKs neu umhüllt. Zugangsinformationen selbst werden dabei weder entschlüsselt noch erneut verschlüsselt. | Einstellung | Bedeutung | | --- | --- | | `QUIRE_MASTER_KEY` | Der aktuelle Master-Schlüssel: 32 Byte, Base64. Jeder neue Secret wird mit diesem Schlüssel umhüllt | | `QUIRE_MASTER_KEY_VERSION` | Die Versionsbezeichnung. Ohne Angabe `v1`. Erhöhen Sie sie bei jedem Schlüsselwechsel | | `QUIRE_MASTER_KEY_RETIRED` | Frühere Schlüssel, unter denen gespeicherte Secrets noch liegen können, etwa `v1=,v0=`. Wird gelesen, nie geschrieben | Web-Tier, Worker und der Befehl `bun run kek:rotate` lesen dieselben drei Einstellungen. Sie müssen überall identisch sein, sonst kann eine Komponente nicht öffnen, was eine andere versiegelt hat. Ohne `QUIRE_MASTER_KEY` verwendet jedes Teilsystem weiterhin den Schlüssel, den es aus `QUIRE_SECRET_KEY` ableitet. Das funktioniert; die Systemzustandsseite zeigt den Status als beeinträchtigt an. Daten bleiben auch dann lesbar, wenn Sie später einen Master-Schlüssel festlegen. So werden bei der ersten Rotation alle Werte von diesem Schlüssel wegbewegt. Jede Person, die die Prozessumgebung lesen kann, kann alle gespeicherten Zugangsdaten entschlüsseln. Eine Produktionsinstallation sollte daher einen Master-Schlüssel verwenden, der in einem Secret Store und nicht zusammen mit der Datenbank gesichert wird. ## Rotation Das Alter des Schlüssels wird in der Plattformkonsole unter Security, Master key sowie als Metrik `quire.secrets.master_key.age` (Tage) angezeigt. Der tägliche Zeitplan `platform.key_age` (03:41 UTC) schreibt einen Erinnerungseintrag in die Plattform-Auditkette, wenn der Schlüssel 365 Tage alt ist, und danach alle 30 Tage bis zur Rotation. Rotieren Sie bei einer Erinnerung und immer dann, wenn ein Schlüssel möglicherweise offengelegt wurde. 1. Erzeugen Sie einen neuen Schlüssel: `openssl rand -base64 32`. 2. Setzen Sie `QUIRE_MASTER_KEY` auf den neuen Wert und `QUIRE_MASTER_KEY_VERSION` auf die nächste Bezeichnung (`v2`). Verschieben Sie den alten Schlüssel nach `QUIRE_MASTER_KEY_RETIRED` und geben Sie ihn als `v1=` an. Bewahren Sie eine Kopie beider Schlüssel an einem anderen Ort als diesem Host auf. 3. Stellen Sie den Web-Tier und den Worker mit den neuen Einstellungen bereit. Neue Secrets werden nun mit `env:QUIRE_MASTER_KEY:v2` umhüllt; alte lassen sich weiterhin über den ausgemusterten Schlüssel öffnen. 4. Fordern Sie die Rotation mit einem Grund an, der im Audit-Protokoll gespeichert wird: - in der Konsole: Security, Master key, Rotate the master key; oder - in einer Shell mit derselben Umgebung: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`. 5. Der Worker umhüllt pro Minute eine Teilmenge neu (Zeitplan `platform.key_rotation` des Schedulers) und setzt nach einem Neustart fort. Für einen einzelnen Durchlauf: `bun run kek:rotate run`. Überwachen Sie den Vorgang mit `bun run kek:rotate status`. 6. Sobald der Datensatz den Abschluss mit **null ungelösten und null fehlgeschlagenen** Werten anzeigt, entfernen Sie den ausgemusterten Schlüssel aus `QUIRE_MASTER_KEY_RETIRED` und stellen Sie erneut bereit. Bis dahin muss er erhalten bleiben: Ein Wert, den die Rotation nicht verschieben konnte, ist weiterhin mit dem alten Schlüssel umhüllt. ### Was der Job durchläuft Jeder Speicher, der einen umhüllten DEK enthält: die Einträge in `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Speicher in der Kontrolldatenbank werden dort durchlaufen; Organisationsspeicher werden jeweils für eine Organisation unter Row-Level-Security abgearbeitet, und zwar in der Datenbank, in der die Organisation liegt. Dadurch wird auch ein an eine dedizierte Datenbank gebundener Mandant in dieser Datenbank rotiert. Ein Test schlägt fehl, wenn das Schema eine Spalte mit umhülltem Schlüssel erhält, die in der Liste nicht aufgeführt ist. Ein weiterer schlägt fehl, wenn die Prüfung der Zugangsdaten eine versiegelte Spalte erfasst, die in der Liste fehlt. ### Der Datensatz - `ops.key_rotation`: eine Zeile pro Rotation mit Grund, anfordernder Person, Status und Summen (neu umhüllt, bereits aktuell, ungelöst, fehlgeschlagen). - `ops.key_rotation_progress`: nach dem Durchlauf eine Zeile pro Speicher und Bereich mit den Schlüsselreferenzen, die nicht gelesen werden konnten, sowie der Anzahl der darunter gespeicherten Werte. Bei einer fortgesetzten Rotation werden diese übersprungen. - Plattform-Auditkette: `platform/key_rotation_request` (einschließlich des Grundes), ein `platform/key_rotation_store` pro Speicher mit seinen Summen sowie `platform/key_rotation_complete` oder `platform/key_rotation_fail`; außerdem `platform/key_age_reminder` für die Erinnerung. - Metriken: `quire.secrets.master_key.age` und `quire.secrets.rewrap.outstanding` (Werte, die die letzte Rotation nicht verschieben konnte). ### Wenn Werte ungelöst bleiben Ein ungelöster Wert ist mit einer Schlüsselreferenz umhüllt, die dieser Installation nicht vorliegt, oder entspricht nicht der von seiner Spalte zugesicherten Form. Im Fortschrittsdatensatz wird die Referenz genannt (zum Beispiel `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Nehmen Sie diesen Schlüssel wieder in `QUIRE_MASTER_KEY_RETIRED` auf und führen Sie eine weitere Rotation aus. Oder bitten Sie, falls der Schlüssel endgültig verloren ist, den Administrator der Organisation, die Zugangsinformation erneut einzugeben; sie wird dann mit dem aktuellen Schlüssel versiegelt. Bei fehlgeschlagenen Rotationen steht der Fehler im Datensatz. Beheben Sie die Ursache und fordern Sie die Rotation erneut an. ## Signaturschlüssel Unabhängig vom Master-Schlüssel signiert jede Organisation ihre OpenID-Connect-Tokens und LTI-Nachrichten mit einem eigenen RSA-Schlüssel, der unter `/.well-known/jwks.json` veröffentlicht wird. Hier ist kein Eingriff durch Betreiber erforderlich. Der stündliche Zeitplan `platform.signing_keys` veröffentlicht sieben Tage vor Ablauf der 90 Tage des aktuellen Schlüssels einen Nachfolger. Eine Woche später beginnt der Nachfolger mit dem Signieren, und der alte Schlüssel geht in den Ruhestand. 90 Tage danach wird der alte Schlüssel gelöscht und aus dem Schlüsselsatz entfernt. Jeder Schritt wird als `platform/signing_key_advance` in der Plattform-Auditkette aufgezeichnet. So ersetzen Sie den Schlüssel einer Organisation vorzeitig, zum Beispiel nach einer Offenlegung: - in der Konsole: Security, Master key, Publish a new signing key (erfordert `platform/keys_manage`); oder - in einer Shell mit der Umgebung des Workers: `bun run kek:rotate signing-keys rotate --tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate signing-keys status` listet die Schlüssel aller Organisationen nach Phase auf. Der neue Schlüssel wird sofort veröffentlicht und beginnt nach sieben Tagen mit dem Signieren, wenn der aktuelle Schlüssel in den Ruhestand geht. Diese Woche ist bewusst vorgesehen: Vertrauende Systeme speichern den Schlüsselsatz im Cache zwischen, und eine kürzere Überschneidung würde alle Tools gleichzeitig ausfallen lassen. Der ausgemusterte Schlüssel bleibt weitere 90 Tage im Schlüsselsatz, damit bereits damit signierte Tokens weiterhin verifiziert werden können. Falls eine Offenlegung ein früheres Ende des Vertrauens erfordert, kann ein Betreiber mit eigenem Datenbankzugriff die Zeile unter einem Änderungsdatensatz löschen (Notfallzugriff ist schreibgeschützt); mit diesem Schlüssel signierte Tokens schlagen dann bei der Prüfung fehl. Die erzwungene Rotation wird mit ihrem Grund als `platform/signing_key_rotate` in der Auditkette gespeichert. Der Worker benötigt dieselben `QUIRE_MASTER_KEY`-Einstellungen wie der Web-Tier, um den neuen Schlüssel zu umhüllen. `bun run kek:rotate` für den Master-Schlüssel umhüllt zusammen mit den übrigen Werten auch die Signaturschlüssel neu (`oauth_signing_key` steht in `SEALED_STORES`). ## Notfallzugriff auf die Produktion Niemand hat dauerhaften Zugriff auf die Produktion. Wenn etwas keinen Aufschub duldet, erteilt ein Eigentümer eine Notfallberechtigung: Plattformkonsole, Security, Break-glass access. - Eine Berechtigung umfasst einen Geltungsbereich (eine Organisation oder das Plattformregister), einen mindestens 20 Zeichen langen Grund mit Vorfalls- oder Ticketnummer sowie ein Zeitfenster von 5 bis 240 Minuten. Sie läuft selbstständig ab: Bei jeder Anweisung wird sie anhand der Uhrzeit geprüft. - Sie kann der ausstellenden Person selbst oder einer anderen Eigentümerperson erteilt werden (Vier-Augen-Prinzip). Nur die Person, der sie erteilt wurde, darf sie verwenden. Zum Ausstellen ist `platform/break_glass_issue`, zum Verwenden `platform/break_glass_use` erforderlich; standardmäßig sind beides ausschließlich Eigentümerrechte. - Anweisungen laufen über das Gateway und nicht über eine Datenbankanmeldung: schreibgeschützt, einzeln, auf die Organisation oder das Kontrollregister beschränkt, mit einem Zeitlimit von fünf Sekunden und höchstens 500 Zeilen. Binärwerte werden nach Größe angezeigt. - Die Plattform-Auditkette protokolliert das Erteilen (mit Grund), den Widerruf, jede Anweisung vor ihrer Ausführung (`platform/break_glass_statement`; abgelehnte Anweisungen erhalten das Ergebnis `denied`) und jedes Resultat (`platform/break_glass_result`). `ops.break_glass_statement` enthält die IDs der Audit-Einträge, sodass der Erteilungsdatensatz mit seinen Audit-Einträgen verknüpft ist. - Schreibzugriffe werden nicht angeboten. Eine Änderung, die nicht bis zu einer Version warten kann, wird mit dem eigenen Datenbankzugriff des Betreibers und unter einem eigenen Änderungsdatensatz außerhalb dieses Produkts durchgeführt. Der Datensatz sollte die hier verwendete Vorfallsreferenz angeben. Warum nicht einfach Datenbankzugangsdaten ausstellen? Eine Postgres-Anmeldung besteht über die Sitzung hinaus fort, die sie angefordert hat, umgeht die Row-Level-Security der Anwendung und kann nicht in die Auditkette dieses Produkts schreiben. Ihre Anweisungen würden daher nur insoweit protokolliert, wie Serverprotokolle ausgeliefert werden. Das Gateway macht den Auditverlauf zu einem Bestandteil des Zugriffs, statt ihn einer zusätzlichen Praxis zu überlassen. Beantworten Sie eine Prüfungsanfrage so: Listen Sie die Berechtigungen im betreffenden Zeitraum auf (Break-glass access), öffnen Sie den Verlauf einer Berechtigung mit ihren Anweisungen und Audit-Eintrags-IDs und lesen Sie die Einträge in der Plattform-Auditkette (`bun run audit:verify --platform` weist nach, dass die Kette intakt ist). Source: https://docs.quirelms.com/de/ops/key-rotation/index.mdx