---
title: "Peavõtme ja allkirjastamisvõtme vahetamine ning hädaolukorra juurdepääs"
description: "Vaheta salvestatud mandaate kaitsvat peavõtit ning kasuta hädaolukorra juurdepääsu."
image: "https://docs.quirelms.com/og.png"
---

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

# Peavõtme ja allkirjastamisvõtme vahetamine ning hädaolukorra juurdepääs

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

Juhtimiseeskirjas 21-compliance.md jaotises 14 on need kontrollid nimetatud
viisil, mida audiitor küsib. See leht kirjeldab toimingut; selle tulemusel tekkivad
kirjed on tõendid.

## Võtmed <!--quire:the-keys-->

Iga salvestatud mandaat pitseeritakse uue andmekrüptovõtmega (DEK). DEK
pakitakse peavõtmega (KEK) ning peavõtme viide säilitatakse selle kõrval
(`key_ref` või pakitud väärtuse sees olev viide). Peavõtme vahetamisel pakitakse
DEK-id uuesti. Mandaati ei dekrüptita ega krüptita uuesti.

| Seade | Tähendus |
| --- | --- |
| `QUIRE_MASTER_KEY` | Praegune peavõti: 32 baiti, base64-vormingus. Iga uus saladus pakitakse sellega |
| `QUIRE_MASTER_KEY_VERSION` | Selle versioonimärgend. Vaikimisi `v1`. Tõsta seda võtme vahetamisel |
| `QUIRE_MASTER_KEY_RETIRED` | Varasemad võtmed, mille all võivad saladused olla, kujul `v1=<base64>,v0=<base64>`. Loetakse, ei kirjutata |

Veebikiht, töötleja ja käsk `bun run kek:rotate` loevad kõiki kolme seadistust.
Väärtused peavad kõikjal ühtima, muidu ei saa üks neist avada teise pitseeritud
väärtusi.

Kui `QUIRE_MASTER_KEY` puudub, kasutab iga alamsüsteem võtit, mille tuletab
`QUIRE_SECRET_KEY`-st. See töötab, kuid süsteemi tervise leht kuvab halvenenud
olekut; seadistatud peavõtme lisamisel jäävad andmed loetavaks, nii et esimese
vahetusega saab kõik sellelt võtmele üle viia. Igaüks, kes saab lugeda protsessi
keskkonnamuutujaid, võib dekrüptida kõik salvestatud mandaadid. Seetõttu peab
tootmispaigaldisel olema saladuste hoidlas talletatud peavõti, mida ei hoita
andmebaasi varukoopiaga samas kohas.

## Võtme vahetamine <!--quire:rotating-->

Võtme vanus kuvatakse jaotises Platform console, Security, Master key ning
mõõdikuna `quire.secrets.master_key.age` (päevades). Igapäevane ajastatud töö
`platform.key_age` (03:41 UTC) lisab platvormi auditi ahelasse meeldetuletuse,
kui võti saab 365 päeva vanaks, seejärel iga 30 päeva järel kuni vahetamiseni.
Vaheta võti meeldetuletuse saamisel ja alati, kui see võis lekkida.

1. Genereeri uus võti: `openssl rand -base64 32`.
2. Määra `QUIRE_MASTER_KEY` sellele ja `QUIRE_MASTER_KEY_VERSION` järgmisele
   versioonimärgisele (`v2`). Lisa
   vana võti `QUIRE_MASTER_KEY_RETIRED` väärtusena `v1=<old base64>`. Hoia mõlemat
   koopiat mujal kui selles hostis.
3. Juuruta veebikiht ja töötleja uute seadetega. Uued saladused pakitakse nüüd
   `env:QUIRE_MASTER_KEY:v2` alla; vanu saab endiselt avada pensionile jäetud
   võtmega.
4. Küsi võtmevahetust, lisades auditi jäljele põhjuse:
   - konsoolis: Security, Master key, Rotate the master key; või
   - sama keskkonnaga käsureal: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Töötleja pakib minutis ühe osa ümber (ajastaja `platform.key_rotation`) ja
   jätkab pärast taaskäivitamist. Kõigi korraga lõpetamiseks käivita
   `bun run kek:rotate run`. Jälgi edenemist käsuga `bun run kek:rotate status`.
6. Kui kirjes on vahetus lõpetatud ning **lahendamata ja nurjunud väärtusi on
   null**, eemalda `QUIRE_MASTER_KEY_RETIRED`-ist pensionile jäetud võti ja
   juuruta uus seadistus. Seni hoia vana võtit alles: mõni väärtus, mida ei
   õnnestunud teisaldada, võib olla endiselt selle all pakitud.

### Milliseid kirjeid töö läbib <!--quire:what-the-job-walks-->

Kõiki mälukohti, mis sisaldavad pakitud DEK-i: loendis `SEALED_STORES`
(`apps/worker/src/key-rotation.ts`) nimetatuid. Juhtandmebaasi kirjed käiakse
läbi juhtandmebaasis; organisatsiooni kirjed läbivad reale-põhise turbe all ühe
organisatsiooni kaupa ja selles andmebaasis, kus see asub. Seega vahetatakse
eriandmebaasi seotud rentniku võti vastavas andmebaasis. Test nurjub, kui skeemi
lisandub pakitud võtme veerg, mida loendis pole, samuti siis, kui mandaatide
ülevaates liigitatakse pitseeritud veerg, mis loendist puudub.

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

- `ops.key_rotation`: iga vahetuse rida koos põhjuse, taotleja, oleku ja
  loenduritega (uuesti pakitud, juba ajakohased, lahendamata, nurjunud).
- `ops.key_rotation_progress`: iga läbitud hoidla ja ulatuse rida koos
  loetamatute võtmeviidete ja nende all olnud väärtuste arvuga. Jätkatud töö jätab
  need vahele.
- Platvormi auditi ahel: `platform/key_rotation_request` (koos põhjusega), iga
  hoidla kohta `platform/key_rotation_store` koos loenduritega ning
  `platform/key_rotation_complete` või `platform/key_rotation_fail`; meeldetuletus
  lisatakse kirjena `platform/key_age_reminder`.
- Mõõdikud: `quire.secrets.master_key.age` ja
  `quire.secrets.rewrap.outstanding` (eelmise vahetusega teisaldamata väärtused).

### Kui väärtused jäävad lahendamata <!--quire:when-values-are-unresolved-->

Lahendamata väärtus on pakitud võtmeviitega, mida paigaldis ei tunne, või selle
kuju ei vasta veeru määratlusele. Edenemiskirjes nimetatakse viide, näiteks
`env:QUIRE_MASTER_KEY:v0 (unreadable)`. Taasta see võti muutujasse
`QUIRE_MASTER_KEY_RETIRED` ja käivita uus vahetus või palu organisatsiooni
halduril mandaati uuesti sisestada, kui võti on jäädavalt kadunud; see pitseeritakse
siis praeguse võtmega. Nurjunud vahetuse veateade kuvatakse kirjes; paranda põhjus
ja esita uus taotlus.

## Allkirjastamisvõtmed <!--quire:signing-keys-->

Peavõtmest eraldi allkirjastab iga organisatsioon OpenID Connecti märgid ja LTI
sõnumid enda RSA-võtmega, mis avaldatakse aadressil `/.well-known/jwks.json`.
Operaator ei pea midagi tegema. Iga tunni järel käivituv `platform.signing_keys`
avaldab järglasvõtme seitse päeva enne praeguse 90-päevase kehtivusaja lõppu;
nädala pärast hakkab uus võti allkirjastama ning vana muutub pensionile jäävaks;
90 päeva pärast kustutatakse vana võti võtmekogumist. Iga sammu kohta lisatakse
platvormi auditi ahelasse kirje `platform/signing_key_advance`.

Organisatsiooni võtme enneaegseks vahetamiseks, näiteks lekke järel:

- konsoolis: Security, Master key, Publish a new signing key (vajab
  õigust `platform/keys_manage`); või
- töötleja keskkonnaga shellis: `bun run kek:rotate signing-keys rotate
  --tenant <slug or id> --reason "Key exposed, INC-3310"`.
  `bun run kek:rotate signing-keys status` loetleb kõikide organisatsioonide võtmed
  oleku järgi.

Uus võti avaldatakse kohe ning hakkab allkirjastama seitsme päeva pärast, kui
praegune võti pensionile läheb. Nädalane kattuvusaeg on tahtlik: võtmekogumit
vahemällu salvestavad osapooled vajavad seda, muidu katkeks korraga kõigi
tööriistade ühendus. Pensionile jääv võti püsib veel 90 päeva võtmekogumis, et
juba allkirjastatud märgid oleksid kontrollitavad. Kui lekke tõttu tuleb see
varem usaldusest eemaldada, kustutatakse selle rida operaatori enda
andmebaasiõigusega muudatuse jälje alusel (hädaolukorra juurdepääs on
kirjutuskaitstud); seejärel nurjub selle võtmega allkirjastatud märkide kontroll.
Jõuga tehtud vahetus kantakse põhjusega platvormi auditi ahelasse kirjena
`platform/signing_key_rotate`. Uue võtme pakkimiseks vajab töötleja samu
`QUIRE_MASTER_KEY` seadeid mis veebikiht; peavõtme jaoks käivitatav
`bun run kek:rotate` pakib koos teiste väärtustega ümber ka allkirjastamisvõtmed
(`oauth_signing_key` asub loendis `SEALED_STORES`).

## Hädaolukorra juurdepääs tootmisele <!--quire:break-glass-production-access-->

Kellelgi pole tootmiskeskkonnale püsivat juurdepääsu. Kui probleem ei saa oodata,
annab omanik hädaolukorra loa: Platform console, Security, Break-glass access.

- Loal on ulatus (üks organisatsioon või platvormi register), vähemalt 20 märgi
  pikkune intsidenti või piletit nimetav põhjus ning 5–240 minuti pikkune
  kehtivusaeg. Luba aegub ise; selle kehtivust kontrollitakse iga lause puhul
  kella järgi.
- Luba võib anda loa taotlevale omanikule või teisele omanikule (kahe inimese
  kord). Kasutada saab seda ainult saaja. Andmine vajab õigust
  `platform/break_glass_issue`, kasutamine aga õigust `platform/break_glass_use`;
  mõlemad on vaikimisi ainult omanikele.
- Laused käitatakse andmebaasi sisselogimise asemel lüüsi kaudu: ainult lugemine,
  ükshaaval, piiratud organisatsiooni või juhtregistriga, viiesekundilise
  ajalimiidi ja kuni 500 reaga. Binaarväärtusi näidatakse suuruse järgi.
- Platvormi auditi ahel talletab loa andmise (põhjusega), tühistamise, iga lause
  enne selle käivitamist (`platform/break_glass_statement`; keelatud toimingute
  tulemus on `denied`) ja iga tulemuse (`platform/break_glass_result`). Tabel
  `ops.break_glass_statement` sisaldab auditikirjete ID-sid, nii et loakirje
  seostub vastavate auditisündmustega.
- Kirjutamist ei võimaldata. Enne väljalaset tehtav vältimatu muudatus kasutab
  operaatori enda andmebaasiõigust ja eraldi muudatuse jälge, väljaspool seda
  toodet; kirjes tuleks viidata siin kasutatud intsidendile.

Miks mitte väljastada andmebaasi mandaati? Postgresi sisselogimine kestab kauem
kui taotletud seanss, möödub rakenduse kasutatavast reale-põhisest turbest ega
saa kirjutada selle toote auditi ahelasse; seega auditeeritaks päringuid ainult
serverilogide väljasaatmise ulatuses. Lüüsi puhul on auditijälg juurdepääsu omadus,
mitte sellega seotud töökorraldus.

Audiitori päringule vastamiseks loetle ajavahemiku load (Break-glass access),
ava loa ajalugu, et näha selle lauseid ja auditisündmuste ID-sid, ning loe need
platvormi auditi ahelast (`bun run audit:verify --platform` kinnitab ahela terviklust).

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