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.

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=<old base64> 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 <slug or id> --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).