---
title: "Galvenās atslēgas un paraksta atslēgu maiņa un ārkārtas piekļuve"
description: "Mainiet galveno atslēgu, kas aizsargā saglabātos akreditācijas datus, un izmantojiet ārkārtas piekļuvi."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/lv/llms.txt
> Use this file to discover all available pages before exploring further.
# Galvenās atslēgas un paraksta atslēgu maiņa un ārkārtas piekļuve
Kontroli 21-compliance.md 14. sadaļā, ko auditors prasa pēc nosaukuma. Šī lapa
ir kārtība; tās radītie ieraksti ir pierādījumi.
## Atslēgas
Katrai saglabātajai akreditāciju datu kopai ir noslēgta ar svaigu datu
šifrēšanas atslēgu (DEK). DEK ir ietīts galvenajā atslēgā (KEK), un galvenās
atslēgas atsauce tiek glabāta blakus (`key_ref` vai atsauce iekš iepakotas
vērtības). Galvenās atslēgas maiņa atkārtoti ietīt DEK. Tā nekad neatsifrē un
neatsifrē no jauna akreditācijas datus.
| Iestatījums | Nozīme |
| --- | --- |
| `QUIRE_MASTER_KEY` | Pašreizējā galvenā atslēga: 32 baiti, base64. Katrs jauns noslēpums tiek ietīts zem tās |
| `QUIRE_MASTER_KEY_VERSION` | Tās versijas etiķete. `v1`, ja nav iestatīts. Palieliniet to katru reizi, kad maināt atslēgu |
| `QUIRE_MASTER_KEY_RETIRED` | Iepriekšējās atslēgas, zem kurām vēl var būt glabāti noslēpumi, kā `v1=,v0=`. Tikai lasāms, nekad neierakstāms |
Tīmekļa slānis, darbinīks un komanda `bun run kek:rotate` lasa tos pašus trīs
iestatījumus. Tiem visiem jābūt ar vienādām vērtībām, citādi viens no tiem nevar
atvērt to, ko cits bija noslēdzis.
Bez `QUIRE_MASTER_KEY` katra apakšsistēma patur atslēgu, ko tā izved no
`QUIRE_SECRET_KEY`. Tas darbojas, Sistēmas veselības lapa to rāda kā pasliktinātu,
un tā paliek lasāma arī pēc tam, kad esi iestatījis galveno atslēgu — tā pirmā
maiņa pārvieto visu prom no tās. Ikviens, kas var lasīt procesa vidi, var atsifrēt
katru saglabāto akreditāciju datu kopu, tāpēc produkcijas instalācijai jābūt
galvenajai atslēgai, kas glabājas slepenību glabātuvē un ne tajā pašā dublējumā
kur datubāze.
## Maiņa
Atslēgas vecums ir redzams Platformas konsoles sadaļā Drošība, Galvenā atslēga,
un kā metrika `quire.secrets.master_key.age` (dienas). Ikdienas grafiks
`platform.key_age` (03:41 UTC) platformas audita ķēdī ieraksta atgādinājumu, kad
atslēga sasniedz 365 dienas, un atkal ik pēc 30 dienām, līdz tā ir nomainīta.
Mainiet pēc atgādinājuma un katru reizi, kad atslēga varētu būt bijusi pakļauta.
1. Ģenerējiet jaunu atslēgu: `openssl rand -base64 32`.
2. Iestatiet uz to `QUIRE_MASTER_KEY` un nākamo etiķeti
`QUIRE_MASTER_KEY_VERSION` (`v2`). Pārvietojiet veco atslēgu uz
`QUIRE_MASTER_KEY_RETIRED` kā `v1=`. Paturiet abu kopiju kaut
kur citur ārpus šī servera.
3. Izvietojiet tīmekļa slāni un darbinīku ar jaunajiem iestatījumiem. Jaunie
noslēpumi tagad tiek ietīti zem `env:QUIRE_MASTER_KEY:v2`; vecie joprojām
atveras caur atsaukto atslēgu.
4. Pieprasiet maiņu ar iemeslu, kas paliks izsekojamības ķēdī:
- konsole: Drošība, Galvenā atslēga, Mainīt galveno atslēgu; vai
- uz komandrindas ar to pašu vidi: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Darbinīks minūtē ietīt pa daļai (plānotāja grafiks `platform.key_rotation`)
un atsāk pēc restarta. Lai to pabeigtu vienā reizē:
`bun run kek:rotate run`. Vērojiet ar `bun run kek:rotate status`.
6. Kad ierāda rāda, ka maiņa pabeigta ar **nulle neatrisinātu un nulle
neizdevušos**, noņemiet atsaukto atslēgu no `QUIRE_MASTER_KEY_RETIRED` un
atkārtoti izvietojiet. Līdz tam paturiet to: vērtība, ko tā nevarēja
pārvietot, joprojām ir ietīta zem vecās atslēgas.
### Ko darbs apiet
Katru glabātuvi, kas glabā ietītu DEK: tās, kas ir `SEALED_STORES`
(`apps/worker/src/key-rotation.ts`). Kontroldatubāzes glabātuves tiek apietas
kontroldatubāzē; organizāciju glabātuves tiek apietas pa vienai organizācijai
zem rindu līmeņa drošības, tajā datubāzē, kurā glabājas organizācija, tāpēc
nomnieks, kas piesaistīts atsevišķai datubāzei, tiek mainīts tai datubāzei.
Tests neizdodas, kad shēmā pievienota ietītās atslēgas kolonna, ko saraksts
nesauc, un vēl viens — kad akreditācijas datu pārbaude klasificē noslēgtu
kolonu, ko saraksts izlaiž.
### Ieraksts
- `ops.key_rotation`: viena rinda katrai maiņai ar tās iemeslu, kurš to pieprasīja,
tās stāvokli un tās kopsummas (atkārtoti ietīti, jau aktuāli, neatrisināti,
neizdevušies).
- `ops.key_rotation_progress`: viena rinda katrai glabātuvei un tvērumam, tiklīdz
tā ir apietas, ar atslēgu atsacēm, kuras tā nevarēja nolasīt, un cik vērtību
bija zem katras. Atsākta maiņu tās izlaiž.
- Platformas audita ķēde: `platform/key_rotation_request` (ar iemeslu), viens
`platform/key_rotation_store` katrai glabātuvei ar tā skaitļiem, un
`platform/key_rotation_complete` vai `platform/key_rotation_fail`;
`platform/key_age_reminder` atgādinājumam.
- Metrikas: `quire.secrets.master_key.age` un `quire.secrets.rewrap.outstanding`
(vērtības, ko pēdējā maiņa nevarēja pārvietot).
### Kad vērtības ir neatrisinātas
Neatrisināta vērtība ir ietīta zem atslēgas atsaces, kuru šī instalācija
nepatur, vai arī tā nav tajā formā, kuru sola tās kolonna. Progresa ieraksts
nosauc atsaci (piemēram, `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Atjaunojiet
to atslēgu `QUIRE_MASTER_KEY_RETIRED` un palaidiet vēl vienu maiņu vai, ja
atslēga ir beigusies uz visiem laikiem, ļaujiet organizācijas administratoram
ievadīt akreditācijas datus no jauna: tad tie tiek noslēgti zem pašreizējās
atslēgas. Neizdevušās maiņas savā ierādā rāda kļūdu; izlabojiet cēloni un
pieprasiet atkārtoti.
## Paraksta atslēgas
Atsevišķi no galvenās atslēgas: katra organizācija paraksta savus OpenID Connect
žetonus un LTI ziņojumus ar savu RSA atslēgu, kas publicēta vietnē
`/.well-known/jwks.json`. Neko no tā nevajag operatoram. Ikstundas grafiks
`platform.signing_keys` publicē mantinieku septiņas dienas pirms tam, kad
pašreizējās atslēgas deviņdesmit dienas beidzas, nedēļu vēlāk mantinieks sāk
parakstīt un vecā atslēga kļūst par atsaukto, un deviņdesmit dienas pēc tam
vecā atslēga tiek izdzēsta un pamet atslēgu kopu. Katrs solis ir
`platform/signing_key_advance` ieraksts platformas audita ķēdī.
Lai organizācijas atslēgu aizstātu agrāk, piemēram, pēc noplūdes:
- konsoles sadaļā Drošība, Galvenā atslēga, Publicēt jaunu paraksta atslēgu
(vajag `platform/keys_manage`); vai
- uz komandrindas ar darbinīka vidi: `bun run kek:rotate signing-keys rotate
--tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate
signing-keys status` uzskaita katras organizācijas atslēgas pēc posma.
Jaunā atslēga tiek publicēta uzreiz un pēc septiņām dienām sāk parakstīt, kad
pašreizējā atslēga atsakās. Nedēļa ir apzināta: paļaujošās puses kešo atslēgu
kopu, un īsāks pārklājums uzreiz izslēgtu katru rīku. Atsauktā atslēga atslēgu
kopā paliek vēl deviņdesmit dienas, lai jau tās parakstītie žetoni turpinātu
pārbaudīties; ja noplūde nozīmē, ka tai jāpārstāj uzticēties agrāk, tās rindas
dzēšana ir izmaiņa, ko veic ar paša operatora datubāzes piekļuvi zem izmaiņu
ieraksta (ārkārtas piekļuve ir tikai lasāma), un ar to parakstītie žetoni tad
neiziet pārbaudi. Spiesta maiņa ir `platform/signing_key_rotate` audita ķēdī ar
iemeslu. Darbinīkam tādi paši `QUIRE_MASTER_KEY` iestatījumi kā tīmekļa slānim,
lai ietītu jauno atslēgu; `bun run kek:rotate` galvenajai atslēgai atkārtoti ietīj
arī paraksta atslēgas kopā ar pārējo (`oauth_signing_key` ir `SEALED_STORES`).
## Ārkārtas piekļuve produkcijai
Nevienam nav pastāvīgas piekļuves produkcijai. Kad kaut kas nevar gaidīt,
īpašnieks izdod ārkārtas piekļuves piešķīrumu: Platformas konsole, Drošība,
Ārkārtas piekļuve.
- Piešķīrumam ir tvērums (viena organizācija vai platformas reģistrs), iemesls
vismaz 20 rakstzīmju garumā, kas nosauc incidentu vai biļeti, un logs no 5
līdz 240 minūtēm. Tas beidzas pats: tas tiek pārbaudīts pret pulksteni katram
paziņojumam.
- To var izdot īpašniekam, kas to izdod, vai citam īpašniekam (divu personu
forma). To drīkst izmantot tikai persona, kurai tas izdots. Izdošanai vajag
`platform/break_glass_issue`, bet izmantošanai — `platform/break_glass_use`;
abas pēc noklusējuma ir tikai īpašniekam.
- Paziņojumi iet caur vārtiem, nevis uz datubāzes pieteikšanos: tikai lasāmi,
pa vienam, ierobežoti organizācijai vai kontroles reģistram, ar piecu sekunžu
laika limitu un ne vairāk kā 500 rindām. Binārās vērtības tiek rādītas pēc
izmēra.
- Platformas audita ķēde reģistrē izdošanu (ar iemeslu), atsaukšanu, katru
paziņojumu pirms tā izpildes (`platform/break_glass_statement`, noraidītie ar
iznākumu `denied`) un katru rezultātu (`platform/break_glass_result`).
`ops.break_glass_statement` glabā audita ierakstu ID, lai izdošanas ieraksts
savienotos ar saviem audita ierakstiem.
- Ierakstīšana netiek piedāvāta. Izmaiņa, kas nevar gaidīt versiju, izmanto
paša operatora datubāzes piekļuvi ar savu izmaiņu ierādu, ārpus šī produkta, un
ierādā jāatsaucas uz šeit izmantoto incidenta atsauksmi.
Kāpēc neizdot akreditācijas datus datubāzei: Postgres pieteikšanās pārdzīvo
sesiju, kas to pieprasīja, apiet rindu līmeņa drošību, uz kuru paļaujas
lietotne, un nevar rakstīt šī produkta audita ķēdī, tāpēc tās paziņojumi tiktu
auditorēti tikai tik, cik kāds būtu aizsūtījis servera žurnālu. Vārti padara
izsekojamības ķēdi par piekļuves īpašību, nevis praksi ap to.
Lai atbildētu uz audita pieprasījumu: uzskaitiet piešķīrumus periodā
(Ārkārtas piekļuve), atveriet piešķīruma vēsturi tā paziņojumiem un audita
ierakstu ID un izlasiet tos ierakstus platformas audita ķēdī
(`bun run audit:verify --platform` pierāda, ka ķēde ir neskarta).
Source: https://docs.quirelms.com/lv/ops/key-rotation/index.mdx