---
title: "Hovednøkkel- og signeringsnøkkelrotering, og nødtilgang"
description: "Roter hovednøkkelen som beskytter lagrede legitimasjoner, og bruk nødtilgang."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/nb/llms.txt
> Use this file to discover all available pages before exploring further.
# Hovednøkkel- og signeringsnøkkelrotering, og nødtilgang
Kontrollene i 21-compliance.md seksjon 14 som en revisor ber om ved navn. Denne siden er prosedyren; postene den produserer er bevisene.
## Nøklene
Hver lagret legitimasjon forsegles med en fersk datakrypteringsnøkkel (DEK). DEK-en pakkes inn av hovednøkkelen (KEK-en), og referansen til hovednøkkelen lagres ved siden av (`key_ref`, eller referansen inne i en pakket verdi). Rotering av hovednøkkelen pakker DEK-ene inn på nytt. Den dekrypterer eller rekrypterer aldri en legitimasjon.
| Innstilling | Betydning |
| --- | --- |
| `QUIRE_MASTER_KEY` | Den gjeldende hovednøkkelen: 32 bytes, base64. Alle nye hemmeligheter pakkes inn under den |
| `QUIRE_MASTER_KEY_VERSION` | Versjonsmerkelappen dens. `v1` når usatt. Hev den hver gang du bytter nøkkel |
| `QUIRE_MASTER_KEY_RETIRED` | Tidligere nøkler lagrede hemmeligheter fortsatt kan ligge under, som `v1=,v0=`. Leses, skrives aldri |
Webnivået, arbeideren og `bun run kek:rotate`-kommandoen leser de samme tre innstillingene. De må alle ha de samme verdiene, ellers kan ikke en av dem åpne det en annen forseglet.
Uten `QUIRE_MASTER_KEY` beholder hvert delsystem nøkkelen det utleder fra `QUIRE_SECRET_KEY`. Det virker, Systemhelse-siden viser det som forringet, og det forblir lesbart etter at du setter en hovednøkkel, som er hvordan den første roteringen flytter alt bort fra den. Alle som kan lese prosessmiljøet kan dekryptere alle lagrede legitimasjoner, så en produksjonsinstallasjon bør ha en hovednøkkel, oppbevart i et hemmelighetslager og ikke i samme sikkerhetskopi som databasen.
## Rotering
Nøkkelalderen vises på Plattformkonsoll, Sikkerhet, Hovednøkkel, og som metrikken `quire.secrets.master_key.age` (dager). Den daglige `platform.key_age`-planen (03:41 UTC) skriver en påminnelsesoppføring til plattformrevisjonskjeden når nøkkelen når 365 dager, og igjen hver 30. dag til den roteres. Roter på påminnelsen, og hver gang en nøkkel kan ha vært eksponert.
1. Generer den nye nøkkelen: `openssl rand -base64 32`.
2. Sett `QUIRE_MASTER_KEY` til den og `QUIRE_MASTER_KEY_VERSION` til neste merkelapp (`v2`). Flytt den gamle nøkkelen til `QUIRE_MASTER_KEY_RETIRED` som `v1=`. Behold en kopi av begge et annet sted enn denne verten.
3. Rull ut webnivået og arbeideren med de nye innstillingene. Nye hemmeligheter pakkes nå inn under `env:QUIRE_MASTER_KEY:v2`; gamle åpnes fortsatt gjennom den pensjonerte nøkkelen.
4. Be om roteringen, med begrunnelsen som skal stå i revisjonssporet:
- i konsollen: Sikkerhet, Hovednøkkel, Roter hovednøkkelen; eller
- på et skall med samme miljø: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Arbeideren pakker inn en skive i minuttet (`platform.key_rotation`-planen til planleggeren) og fortsetter etter en omstart. For å fullføre det i én sitting: `bun run kek:rotate run`. Følg med på den med `bun run kek:rotate status`.
6. Når posten viser at roteringen er fullført med **null uløste og null mislykkede**, fjerner du den pensjonerte nøkkelen fra `QUIRE_MASTER_KEY_RETIRED` og ruller ut på nytt. Til da beholder du den: en verdi den ikke kunne flytte ligger fortsatt innpakket under den gamle nøkkelen.
### Hva jobben går gjennom
Alle lagre som holder en innpakket DEK: dem i `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Kontrolldatabaselagre gås gjennom på kontrolldatabasen; organisasjonslagre gås gjennom én organisasjon om gangen under sikkerhet på radnivå, i den databasen som holder organisasjonen, slik at en tenant festet til en dedikert database roteres i den databasen. En test feiler når skjemaet får en innpakket-nøkkel-kolonne som listen ikke navngir, og en annen når legitimasjonsgjennomgangen klassifiserer en forseglet kolonne listen overser.
### Posten
- `ops.key_rotation`: én rad per rotering, med begrunnelsen dens, hvem som ba om den, tilstanden dens og totalene dens (pakket inn på nytt, allerede gjeldende, uløste, mislykkede).
- `ops.key_rotation_progress`: én rad per lager og omfang når gjennomgått, med nøkkelreferansene den ikke kunne lese og hvor mange verdier som lå under hver. En gjenopptatt rotering hopper over disse.
- Plattformrevisjonskjede: `platform/key_rotation_request` (med begrunnelsen), én `platform/key_rotation_store` per lager med tellingene dens, og `platform/key_rotation_complete` eller `platform/key_rotation_fail`; `platform/key_age_reminder` for påminnelsen.
- Metrikker: `quire.secrets.master_key.age` og `quire.secrets.rewrap.outstanding` (verdier siste rotering ikke kunne flytte).
### Når verdier er uløste
En uløst verdi er pakket inn under en nøkkelreferanse denne installasjonen ikke holder, eller er ikke i formen kolonnen dens lover. Fremdriftsposten navngir referansen (for eksempel `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Gjenopprett den nøkkelen inn i `QUIRE_MASTER_KEY_RETIRED` og kjør en ny rotering, eller, hvis nøkkelen er borte for godt, la organisasjonens administrator skrive inn legitimasjonen igjen: den forsegles da under gjeldende nøkkel. Mislykkede roteringer viser feilen sin på posten; fiks årsaken og be igjen.
## Signeringsnøkler
Atkilt fra hovednøkkelen: hver organisasjon signerer sine OpenID Connect-tokens og LTI-meldinger med sin egen RSA-nøkkel, publisert på `/.well-known/jwks.json`. Ingenting her trenger en operatør. Den timelige `platform.signing_keys`-planen publiserer en etterfølger syv dager før gjeldende nøkkels nitti er ute, en uke senere begynner etterfølgeren å signere og den gamle nøkkelen blir avtroppende, og nitti dager etter det slettes den gamle nøkkelen og forlater nøkkelmengden. Hvert steg er en `platform/signing_key_advance`-oppføring på plattformrevisjonskjeden.
For å erstatte en organisasjons nøkkel tidlig, for eksempel etter en eksponering:
- i konsollen: Sikkerhet, Hovednøkkel, Publiser en ny signeringsnøkkel (trenger `platform/keys_manage`); eller
- på et skall med arbeiderens miljø: `bun run kek:rotate signing-keys rotate --tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate signing-keys status` viser alle organisasjoners nøkler etter stadium.
Den nye nøkkelen publiseres med én gang og begynner å signere etter syv dager, når gjeldende nøkkel trer tilbake. Uken er bevisst: avhengige parter mellomlagrer nøkkelmengden, og en kortere overlapping feiler alle verktøy med én gang. Den avtroppende nøkkelen blir i nøkkelmengden i nitti dager til slik at tokens den allerede signerte fortsatt verifiseres; hvis eksponeringen betyr at den må slutte å stoles på før, er sletting av raden dens en endring gjort med operatørens egen databasetilgang under en endringspost (nødtilgang er skrivebeskyttet), og tokens signert med den feiler da verifisering. Den tvungne roteringen er `platform/signing_key_rotate` i revisjonskjeden, med begrunnelsen. Arbeideren trenger de samme `QUIRE_MASTER_KEY`-innstillingene som webnivået for å pakke inn den nye nøkkelen; `bun run kek:rotate` for hovednøkkelen pakker signeringsnøkler inn på nytt med alt annet (`oauth_signing_key` er i `SEALED_STORES`).
## Nødtilgang til produksjon
Ingen holder stående tilgang til produksjon. Når noe ikke kan vente, utsteder en eier en nødtilgangsbevilling: Plattformkonsoll, Sikkerhet, Nødtilgang.
- En bevilling har et omfang (én organisasjon, eller plattformregisteret), en begrunnelse på minst 20 tegn som navngir hendelsen eller billetten, og et vindu på 5 til 240 minutter. Den utløper av seg selv: den sjekkes mot klokken på hver setning.
- Den kan utstedes til eieren som utsteder den, eller til en annen eier (topersonsformen). Bare personen den ble utstedt til kan bruke den. Utstedelse trenger `platform/break_glass_issue` og bruk trenger `platform/break_glass_use`; begge er kun eier som standard.
- Setninger kjøres gjennom porten, ikke på en databasepålogging: skrivebeskyttet, én om gangen, begrenset til organisasjonen eller til kontrollregisteret, med fem sekunders tidsavbrudd og høyst 500 rader. Binære verdier vises etter størrelse.
- Plattformrevisjonskjeden registrerer utstedelsen (med begrunnelsen), tilbakekallingen, hver setning før den kjøres (`platform/break_glass_statement`, avviste med utfall `denied`) og hvert resultat (`platform/break_glass_result`). `ops.break_glass_statement` holder revisjonsoppførings-ID-ene, slik at utstedelsesposten kobles til revisjonsoppføringene dens.
- Skriving tilbys ikke. En endring som ikke kan vente på en utgivelse bruker operatørens egen databasetilgang under sin egen endringspost, utenfor dette produktet, og posten bør sitere hendelsesreferansen brukt her.
Hvorfor ikke utstede databaselegitimasjon: en Postgres-pålogging overlever økten som ba om den, omgår sikkerheten på radnivå applikasjonen er avhengig av, og kan ikke skrive til dette produktets revisjonskjede, slik at setningene dens ville vært revidert bare så langt noen sendte tjenerloggen. Porten gjør revisjonssporet til en egenskap ved tilgangen snarere enn en praksis rundt den.
For å svare på en revisjonsforespørsel: list bevillingene i perioden (Nødtilgang), åpne en bevillings historikk for setningene dens og revisjonsoppførings-ID-ene, og les disse oppføringene på plattformrevisjonskjeden (`bun run audit:verify --platform` beviser at kjeden er intakt).
Source: https://docs.quirelms.com/nb/ops/key-rotation/index.mdx