---
title: "Rotation af hovednøgle og signeringsnøgle samt nødadgang"
description: "Rotér hovednøglen, der beskytter gemte legitimationsoplysninger, og brug nødadgang."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/da/llms.txt
> Use this file to discover all available pages before exploring further.

# Rotation af hovednøgle og signeringsnøgle samt nødadgang

<span id="master-key-and-signing-key-rotation-and-break-glass-access"></span>

Kontrollerne i afsnit 14 i 21-compliance.md, som en revisor beder om ved navn.
Denne side beskriver fremgangsmåden; de optegnelser, den producerer, er dokumentationen.

## Nøglerne <!--quire:the-keys-->

Hver gemt legitimationsoplysning forsegles med en ny datakrypteringsnøgle (DEK). DEK'en
indpakkes af hovednøglen (KEK), og hovednøglens reference gemmes ved siden af den (`key_ref` eller referencen i en pakket værdi). Rotation
af hovednøglen indpakker DEK'erne igen. Den dekrypterer eller krypterer aldrig en legitimationsoplysning på ny.

| Indstilling | Betydning |
| --- | --- |
| `QUIRE_MASTER_KEY` | Den aktuelle hovednøgle: 32 byte, base64. Alle nye hemmeligheder indpakkes med den |
| `QUIRE_MASTER_KEY_VERSION` | Dens versionsetiket. `v1`, hvis den ikke er angivet. Forøg den, hver gang du ændrer nøglen |
| `QUIRE_MASTER_KEY_RETIRED` | Tidligere nøgler, som gemte hemmeligheder stadig kan være indpakket med, som `v1=<base64>,v0=<base64>`. Kun til læsning, aldrig skrivning |

Weblaget, worker og kommandoen `bun run kek:rotate` læser de samme tre
indstillinger. De skal alle have samme værdier, ellers kan en komponent ikke åbne det,
en anden har forseglet.

Uden `QUIRE_MASTER_KEY` bruger hvert delsystem den nøgle, det udleder af
`QUIRE_SECRET_KEY`. Det fungerer, siden Systemstatus viser tilstanden som forringet,
og data forbliver læsbare, efter du indstiller en hovednøgle. Sådan flytter den første rotation
alt væk fra den afledte nøgle. Alle, der kan læse procesmiljøet, kan dekryptere
alle gemte legitimationsoplysninger, så en produktionsinstallation bør have en hovednøgle,
der opbevares i et hemmelighedslager og ikke i samme backup som databasen.

## Rotation <!--quire:rotating-->

Nøglens alder vises i platformskonsollen under Sikkerhed, Hovednøgle og som metrikken
`quire.secrets.master_key.age` (dage). Den daglige tidsplan `platform.key_age` (03.41 UTC)
skriver en påmindelse i platformens auditkæde, når nøglen er 365
dage gammel, og igen hver 30. dag, indtil den roteres. Rotér, når du får påmindelsen, og når som helst en nøgle kan være blevet eksponeret.

1. Generér den nye nøgle: `openssl rand -base64 32`.
2. Sæt `QUIRE_MASTER_KEY` til den, og sæt `QUIRE_MASTER_KEY_VERSION` til den næste etiket
   (`v2`). Flyt den gamle nøgle til `QUIRE_MASTER_KEY_RETIRED` som `v1=<old base64>`.
   Opbevar kopier af begge et andet sted end på denne vært.
3. Udrul weblaget og worker med de nye indstillinger. Nye hemmeligheder indpakkes nu
   med `env:QUIRE_MASTER_KEY:v2`; ældre hemmeligheder kan stadig åbnes med den
   udfasede nøgle.
4. Anmod om rotationen med den begrundelse, der skal stå i auditsporet:
   - i konsollen: Sikkerhed, Hovednøgle, Rotér hovednøglen; eller
   - i en shell med det samme miljø: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker indpakker en portion i minuttet (schedulerens tidsplan `platform.key_rotation`) og fortsætter efter genstart. Hvis du vil gøre det hele i én omgang: `bun run kek:rotate run`. Følg status med `bun run kek:rotate status`.
6. Når posten viser, at rotationen er gennemført med **nul uløste og nul fejl**, skal du fjerne den udfasede nøgle fra `QUIRE_MASTER_KEY_RETIRED` og udrulle igen.
   Behold den indtil da: En værdi, den ikke kunne flytte, er stadig indpakket med den gamle nøgle.

### Hvad jobbet gennemgår <!--quire:what-the-job-walks-->

Alle lagre med en indpakket DEK: dem i `SEALED_STORES`
(`apps/worker/src/key-rotation.ts`). Lagre i kontroldatabasen gennemgås i kontroldatabasen; organisationslagre gennemgås én organisation ad gangen under
row-level security i den database, der indeholder organisationen, så en lejer, der er fastlåst til en dedikeret database, roteres dér. En test fejler, når
skemaet får en indpakket nøglekolonne, som listen ikke nævner, og en anden test fejler, når
gennemgangen af legitimationsoplysninger klassificerer en forseglet kolonne, som listen overser.

### Optegnelsen <!--quire:the-record-->

- `ops.key_rotation`: én række pr. rotation med dens begrundelse, hvem der anmodede om den,
  dens status og totaler (indpakket igen, allerede aktuel, uløst, mislykket).
- `ops.key_rotation_progress`: én række pr. lager og omfang, når det er gennemgået, med de
  nøglereferencer, det ikke kunne læse, og antallet af værdier under hver. En genoptaget
  rotation springer disse over.
- Platformens auditkæde: `platform/key_rotation_request` (med begrundelsen), én
  `platform/key_rotation_store` pr. lager med optællingerne og
  `platform/key_rotation_complete` eller `platform/key_rotation_fail`;
  `platform/key_age_reminder` for påmindelsen.
- Metrikker: `quire.secrets.master_key.age` og `quire.secrets.rewrap.outstanding`
  (værdier, som den seneste rotation ikke kunne flytte).

### Når værdier ikke kan løses <!--quire:when-values-are-unresolved-->

En værdi kan ikke løses, hvis den er indpakket med en nøglerreference, denne installation ikke
har, eller hvis den ikke har den form, kolonnen angiver. Statusposten angiver referencen
(for eksempel `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Gendan den nøgle i
`QUIRE_MASTER_KEY_RETIRED`, og kør en ny rotation. Hvis nøglen er tabt for
altid, skal organisationens administrator indtaste legitimationsoplysningen igen:
så forsegles den med den aktuelle nøgle. Mislykkede rotationer viser fejlen på
posten; ret årsagen, og anmod igen.

## Signeringsnøgler <!--quire:signing-keys-->

Adskilt fra hovednøglen: Hver organisation signerer sine OpenID Connect-tokens
og LTI-meddelelser med sin egen RSA-nøgle, der offentliggøres på `/.well-known/jwks.json`.
Operatøren behøver ikke foretage sig noget. Den timebaserede tidsplan `platform.signing_keys`
offentliggør en efterfølger syv dage før den nuværende nøgle fylder halvfems dage. En uge senere begynder efterfølgeren at signere, og den gamle nøgle bliver udfaset. Halvfems
dage derefter slettes den gamle nøgle og fjernes fra nøglesamlingen. Hvert trin er en
`platform/signing_key_advance`-post i platformens auditkæde.

Hvis du vil udskifte en organisations nøgle før tid, for eksempel efter en eksponering:

- i konsollen: Sikkerhed, Hovednøgle, Udgiv en ny signeringsnøgle (kræver
  `platform/keys_manage`); eller
- i en shell med workers miljø: `bun run kek:rotate signing-keys rotate
  --tenant <slug or id> --reason "Key exposed, INC-3310"`. `bun run kek:rotate
  signing-keys status` viser alle organisationers nøgler efter trin.

Den nye nøgle offentliggøres med det samme og begynder at signere efter syv dage, når den
nuværende nøgle udfases. Ventetiden er bevidst: Modtagere cacher nøglesamlingen,
og et kortere overlap får alle værktøjer til at fejle på samme tid. Den udfasede nøgle forbliver i nøglesamlingen i halvfems dage mere, så tokens, den allerede har signeret, fortsat kan valideres. Hvis en eksponering betyder, at den ikke længere må betros, kan rækken slettes med operatørens egen databaseadgang under en ændringspost (nødadgang giver kun læseadgang), hvorefter tokens signeret med den fejler validering. Den tvungne rotation registreres som `platform/signing_key_rotate` i auditkæden med begrundelsen. Worker skal bruge de samme `QUIRE_MASTER_KEY`-indstillinger som weblaget for at indpakke den nye nøgle; `bun run kek:rotate` til hovednøglen indpakker signeringsnøgler igen sammen med alt andet (`oauth_signing_key` findes i `SEALED_STORES`).

## Nødadgang til produktion <!--quire:break-glass-production-access-->

Ingen har permanent adgang til produktion. Når noget ikke kan vente, udsteder en ejer
en nødadgangstilladelse: Platformskonsol, Sikkerhed, Nødadgang.

- Tilladelsen gælder et omfang (én organisation eller platformregistret), har en begrundelse på
  mindst 20 tegn, der angiver hændelsen eller sagsnummeret, og et tidsrum på 5 til 240
  minutter. Den udløber automatisk: Den kontrolleres mod uret ved hver
  sætning.
- Den kan udstedes til ejeren, der udsteder den, eller til en anden ejer (to-personers
  godkendelse). Kun den person, tilladelsen er udstedt til, kan bruge den. Udstedelse kræver
  `platform/break_glass_issue`, og brug kræver `platform/break_glass_use`; begge er som standard kun for ejere.
- Sætninger udføres gennem gatewayen, ikke med et database-login: skrivebeskyttet, én ad gangen,
  begrænset til organisationen eller kontrolregistret, med en timeout på fem sekunder
  og højst 500 rækker. Binære værdier vises med deres størrelse.
- Platformens auditkæde registrerer udstedelsen (med begrundelsen), tilbagekaldelsen,
  hver sætning før den køres (`platform/break_glass_statement`; afviste sætninger får
  resultatet `denied`) og hvert resultat (`platform/break_glass_result`).
  `ops.break_glass_statement` indeholder id'erne for auditposterne, så udstedelsesposten
  kan sammenkobles med dens auditposter.
- Skrivning tilbydes ikke. En ændring, der ikke kan vente på en udgivelse, foretages med
  operatørens egen databaseadgang under sin egen ændringspost uden for dette produkt,
  og posten bør henvise til det hændelsesnummer, der bruges her.

Hvorfor ikke udstede databaselegitimationsoplysninger? Et Postgres-login varer længere end den session, der
bad om det, omgår den row-level security, applikationen er afhængig af, og
kan ikke skrive til produktets auditkæde. Derfor ville sætninger kun blive auditeret, så langt som nogen havde sendt serverloggen. Gatewayen gør auditsporet til en
egenskab ved adgangen i stedet for en praksis omkring den.

Hvis du skal besvare en revisionsanmodning: Find tilladelserne fra perioden under Nødadgang,
åbn en tilladelses historik for at se dens sætninger og auditpost-id'er, og læs disse
poster i platformens auditkæde (`bun run audit:verify --platform` beviser, at
kæden er intakt).

Source: https://docs.quirelms.com/da/ops/key-rotation/index.mdx