---
title: "Pagrindinio rakto ir pasirašymo rakto rotavimas bei avarinė prieiga"
description: "Rotuokite pagrindinį raktą, saugantį išsaugotus prisijungimo duomenis, ir naudokite avarinę prieigą."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/lt/llms.txt
> Use this file to discover all available pages before exploring further.
# Pagrindinio rakto ir pasirašymo rakto rotavimas bei avarinė prieiga
Kontrolės iš 21-compliance.md 14 skyriaus, apie kurias auditorius klausia
pavadinimu. Šis puslapis yra procedūra; jo sukuriami įrašai yra įrodymai.
## Raktai
Kiekvieni išsaugoti prisijungimo duomenys užkabinami šviežiu duomenų
šifravimo raktu (DEK). DEK suvyniojamas pagrindinio rakto (KEK), o pagrindinio
rakto nuoroda saugoma šalia (`key_ref` arba nuoroda supakuotoje reikšmėje).
Pasukus pagrindinį raktą, DEK suvyniojami iš naujo. Prisijungimo duomenų
niekada neiššifruojama ir iš naujo neužšifruojama.
| Nustatymas | Reikšmė |
| --- | --- |
| `QUIRE_MASTER_KEY` | Dabartinis pagrindinis raktas: 32 baitai, base64. Kiekviena nauja paslaptis suvyniojama po juo |
| `QUIRE_MASTER_KEY_VERSION` | Jo versijos žyma. Kai nenustatyta – `v1`. Pakelkite ją kiekvieną kartą, kai keičiate raktą |
| `QUIRE_MASTER_KEY_RETIRED` | Ankstesni raktai, po kurių gali slėpti paslaptys, kaip `v1=,v0=`. Skaitoma, niekada neįrašoma |
Tinklo sluoksnis, darbininkas ir komanda `bun run kek:rotate` skaito tuos pačius
tris nustatymus. Jie visi turi turėti vienodas reikšmes, arba vienas jų negalės
atidaryti to, ką užkabinęs kitas.
Be `QUIRE_MASTER_KEY` kiekviena posistema išlaiko raktą, kurį išveda iš
`QUIRE_SECRET_KEY`. Tai veikia, Sistemos sveikatos puslapyje tai rodoma kaip
pablogęs, ir jis lieka skaitomas, kai nustatote pagrindinį raktą – būtent taip
pirmasis rotavimas viską nuo jo perkelia. Kas gali perskaityti proceso aplinką,
gali iššifruoti kiekvienus išsaugotus prisijungimo duomenis, todėl gamybinis
diegimas turėtų turėti pagrindinį raktą, saugomą paslapčių saugykloje, o ne
toje pačioje atsarginėje kopijoje kaip duomenų bazė.
## Rotavimas
Rakto amžius rodomas platformos konsolėje, Security, Master key, ir kaip
matuoklis `quire.secrets.master_key.age` (dienos). Kasdienė `platform.key_age`
tvarkaraštis (03:41 UTC) įrašo priminimo eilutę į platformos audito grandinę,
kai raktas pasiekia 365 dienas, ir dar kartą kas 30 dienų, kol jis nepasuotas.
Rotuokite pagal priminimą ir kiekvieną kartą, kai raktas galėjo būti atskleistas.
1. Sugeneruokite naują raktą: `openssl rand -base64 32`.
2. Nustatykite `QUIRE_MASTER_KEY` į jį ir `QUIRE_MASTER_KEY_VERSION` į kitą
žymą (`v2`). Seną raktą perkelkite į `QUIRE_MASTER_KEY_RETIRED` kaip
`v1=`. Abiejų kopijas laikykite kur kitur, ne šioje sistemoje.
3. Paleiskite tinklo sluoksnį ir darbininką su naujais nustatymais. Naujos
paslaptys dabar suvyniojamos po `env:QUIRE_MASTER_KEY:v2`; senos vis tiek
atidaromos atsargos raktu.
4. Paprašykite rotavimo su priežastimi, kuri liks audito pėdsake:
- konsolėje: Security, Master key, Rotate the master key; arba
- komandų eilutėje su ta pačia aplinka: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Darbininkas per minute suvynioja vieną riekelę (tvarkytuvo
`platform.key_rotation` tvarkaraštis) ir po paleidimo iš naujo tęsia.
Kad baigtumėte vienu prisėdimu: `bun run kek:rotate run`. Stebėkite su
`bun run kek:rotate status`.
6. Kai įraše rotavimas parodomas baigtas su **zero unresolved and zero
failed**, pašalinkite atsargos raktą iš `QUIRE_MASTER_KEY_RETIRED` ir
paleiskite diegimą iš naujo. Iki tol jį laikykite: reikšmės, kurios nepavyko
perkelti, vis tiek suvyniojamos po seno rakto.
### Ką užduotis peržiūri
Kiekvieną saugyklą, laikančią suvyniotą DEK: tas, kurios yra `SEALED_STORES`
(`apps/worker/src/key-rotation.ts`). Valdymo duomenų bazės saugyklos
peržiūrimos valdymo duomenų bazėje; organizacijų saugyklos peržiūrimos po
vieną organizaciją su eilučių lygio apsauga, toje duomenų bazėje, kurioje yra
organizacija, todėl nuomininkas, pririštas prie atskiros duomenų bazės,
rotuojamas toje duomenų bazėje. Testas nepavyksta, kai schemoje atsiranda
suvynioto rakto stulpelio, kurio sąraše nėra, ir kitas, kai prisijungimo
duomenų peržiūra priskiria užkabintą stulpelį, kurio sąrašas nepastebi.
### Įrašas
- `ops.key_rotation`: viena eilutė rotavimui, su jo priežastimi, kas jį
prašė, būsena ir jo sumomis (suvyniota iš naujo, jau teisinga, neišspręsta,
nepavyko).
- `ops.key_rotation_progress`: viena eilutė kiekvienai saugyklai ir apimčiai
kartą peržiūrėjus, su rakto nuorodomis, kurių nepavyko perskaityti, ir kiek
reikšmių buvo po kiekviena. Tęsiamas rotavimas jas praleidžia.
- Platformos audito grandinė: `platform/key_rotation_request` (su priežastimi),
po vieną `platform/key_rotation_store` kiekvienai saugyklai su jos skaičiais
ir `platform/key_rotation_complete` arba `platform/key_rotation_fail`;
`platform/key_age_reminder` priminimui.
- Matuokliai: `quire.secrets.master_key.age` ir
`quire.secrets.rewrap.outstanding` (reikšmės, kurių paskutinis rotavimas
neperkėlė).
### Kai reikšmės neišspręstos
Neišspręsta reikšmė suvyniojama po rakto nuorodos, kurios šis diegimas neturi,
arba ji neatitinka tos formos, kurią žada jos stulpelis. Eigos įraše įvardijama
nuoroda (pavyzdžiui `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Atkurkite tą raktą
į `QUIRE_MASTER_KEY_RETIRED` ir paleiskite kitą rotavimą, arba, jei raktas
dingo visam laikui, leiskite organizacijos administratoriui įvesti prisijungimo
duomenis iš naujo: tada jie bus užkabinti po dabartinio rakto. Nepavykę
rotavimai rodo savo klaidą įraše; pataisykite priežastį ir paprašykite iš naujo.
## Pasirašymo raktai
Atskirai nuo pagrindinio rakto: kiekviena organizacija pasirašo savo OpenID
Connect žetonus ir LTI žinutes savu RSA raktu, paskelbtu adresu
`/.well-known/jwks.json`. Tam nereikia jokio operatoriaus. Kasdienis
`platform.signing_keys` tvarkaraštis paskelbia įpėdinį septynias dienas
prieš pasibaigiant dabartinio rakto devyniasdešimčiai, po savaitės įpėdinis
pradeda pasirašyti, o senas raktas tampa atsargos, o po to devyniasdešimties
dienų senas raktas ištrinamas ir palieka raktų rinkinį. Kiekvienas žingsnis
yra `platform/signing_key_advance` įrašas platformos audito grandinėje.
Kad ankščiau pakeistumėte organizacijos raktą, pavyzdžiui, po atskleidimo:
- konsolėje: Security, Master key, Publish a new signing key (reikia
`platform/keys_manage`); arba
- komandų eilutėje su darbininko aplinka: `bun run kek:rotate signing-keys rotate
--tenant --reason "Key exposed, INC-3310"`.
`bun run kek:rotate signing-keys status` išvardija kiekvienos organizacijos
raktus pagal stadiją.
Naujas raktas paskelbiamas iš karto ir pradeda pasirašyti po septynių dienų,
kai dabartinis raktas atsitraukia. Savaitė yra numatyta sąmoningai: raktų
rinkinį talpina pasitikinčios šalys, ir trumpesnis persidengimas iš karto
sugadintų kiekvieną įrankį. Atsargos raktas lieka raktų rinkinyje dar
devyniasdešimt dienų, kad jau jo pasirašyti žetonai ir toliau tikrintųsi; jei
atskleidimas reiškia, kad jam reikia anksčiau nustoti būti patikimu, jo eilutės
ištrynimas yra pakeitimas, atliekamas operatoriaus paties duomenų bazės
prieiga pagal pakeitimų įrašą (avarinė prieiga yra tik skaitymui), ir tada
juo pasirašyti žetonai nepereina patikros. Priverstinis rotavimas yra
`platform/signing_key_rotate` audito grandinėje, su priežastimi. Darbininkui
reikia tų pačių `QUIRE_MASTER_KEY` nustatymų, kaip tinklo sluoksniui, kad
suvyniotų naują raktą; `bun run kek:rotate` pagrindiniam raktui suvynioja ir
pasirašymo raktus su visu kitu (`oauth_signing_key` yra `SEALED_STORES`).
## Avarinė gamybinė prieiga
Niekas neturi nuolatinės prieigos prie gamybos. Kai kažkas negali laukti,
savininkas išduoda avarinės prieigos suteikimą: Platform console, Security,
Break-glass access.
- Suteikimas turi apimtį (vieną organizaciją arba platformos registrą),
priežastį nuo 20 simbolių, įvardijančią incidentą arba bilietą, ir langą
nuo 5 iki 240 minučių. Jis pasibaigia pats: tikrinamas pagal laikrodį
kiekvienai teiginiui.
- Jį galima išduoti tam savininkui, kuris jį išduoda, arba kitam savininkui
(dvi žmonių forma). Naudotis gali tik tas žmogus, kuriam jis išduotas.
Išdavimui reikia `platform/break_glass_issue`, o naudojimui –
`platform/break_glass_use`; abu pagal nutylėjimą tik savininkams.
- Teiginiai vykdomi per vartų paslaugą, ne prisijungus prie duomenų bazės:
tik skaitymui, po vieną, apriboti organizacijos arba valdymo registro,
su penkių sekundžių laiko limitu ir daugiausia 500 eilučių. Dvinarės
reikšmės rodomos pagal dydį.
- Platformos audito grandinė registruoja išdavimą (su priežastimi), atšaukimą,
kiekvieną teiginį prieš jam veikiant (`platform/break_glass_statement`,
atmesti su rezultatu `denied`) ir kiekvieną rezultatą
(`platform/break_glass_result`). `ops.break_glass_statement` saugo audito
įrašų id, todėl išdavimo įrašas susiejamas su savo audito įrašais.
- Rašymai nesiūlami. Pakeitimas, kuris negali laukti versijos, naudoja
paties operatoriaus duomenų bazės prieigą su savo pakeitimų įrašu, už šio
produkto ribų, ir įraše turėtų būti nurodytas incidento numeris, naudojamas
čia.
Kodėl neišduodami duomenų bazės prisijungimo duomenų: Postgres prisijungimas
gyvena ilgiau už seansą, kuris jo paprašė, apėina eilučių lygio apsaugą, kuria
remiasi programa, ir negali įrašyti į šio produkto audito grandinę, todėl jo
teiginiai būtų audituojami tik tiek, kiek kas nors būtų išsiuntęs serverio
žurnalą. Vartų paslauga daro audito pėdsaką prieigos savybe, o ne praktika
aplink ją.
Kad atsakytumėte į audito prašymą: išvardykite suteikimus laikotarpiu
(Break-glass access), atidarykite suteikimo istoriją jo teiginiams ir audito
įrašų id ir perskaitykite tuos įrašus platformos audito grandinėje
(`bun run audit:verify --platform` įrodo, kad grandinė sveika).
Source: https://docs.quirelms.com/lt/ops/key-rotation/index.mdx