---
title: "Rotacija glavnog ključa, ključa za potpisivanje i hitni pristup"
description: "Rotirajte glavni ključ koji štiti sačuvane pristupne podatke i koristite hitni pristup."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/bs/llms.txt
> Use this file to discover all available pages before exploring further.
# Rotacija glavnog ključa, ključa za potpisivanje i hitni pristup
Kontrole koje revizor po imenu traži navedene su u odjeljku 14 dokumenta 21-compliance.md. Ova stranica sadrži postupak; zapisi koje on proizvodi predstavljaju dokaz.
## Ključevi
Svaki sačuvani pristupni podatak zapečaćen je svježim ključem za šifrovanje podataka (DEK). DEK se omotava glavnim ključem (KEK), a referenca glavnog ključa čuva se uz njega (`key_ref` ili referenca unutar zapakovane vrijednosti). Rotacijom glavnog ključa DEK-ovi se ponovo omotavaju. Pristupni podaci se pritom nikada ne dešifruju niti ponovo šifruju.
| Postavka | Značenje |
| --- | --- |
| `QUIRE_MASTER_KEY` | Trenutni glavni ključ: 32 bajta, base64. Svaka nova tajna omotava se njime |
| `QUIRE_MASTER_KEY_VERSION` | Oznaka verzije. Ako nije postavljena, `v1`. Povećajte je pri svakoj promjeni ključa |
| `QUIRE_MASTER_KEY_RETIRED` | Raniji ključevi kojima su tajne možda još omotane, u obliku `v1=,v0=`. Čitaju se, ali se njima ne šifruje |
Web sloj, worker i komanda `bun run kek:rotate` čitaju iste tri postavke. Njihove vrijednosti moraju biti jednake ili neki proces neće moći otvoriti ono što je drugi zapečatio.
Bez `QUIRE_MASTER_KEY` svaka podsistema koristi ključ izveden iz `QUIRE_SECRET_KEY`. To funkcioniše, stranica Zdravlje sistema prikazuje pogoršano stanje, a podaci ostaju čitljivi kada postavite glavni ključ; tako se prvom rotacijom sve premješta sa starog ključa. Svako ko može čitati okruženje procesa može dešifrovati sve sačuvane pristupne podatke, pa produkcijska instalacija treba imati glavni ključ u spremištu tajni, odvojeno od sigurnosne kopije baze.
## Rotiranje ključa
Starost ključa prikazuje se u konzoli Platform, u Security, Master key i putem metrike `quire.secrets.master_key.age` (dani). Dnevni zadatak `platform.key_age` (03:41 UTC) upisuje podsjetnik u revizorski lanac platforme kada ključ navrši 365 dana, a zatim svakih 30 dana dok se ne rotira. Rotirajte ga nakon podsjetnika i uvijek kada je možda otkriven.
1. Generišite novi ključ: `openssl rand -base64 32`.
2. Postavite `QUIRE_MASTER_KEY` na novu vrijednost, a `QUIRE_MASTER_KEY_VERSION` na sljedeću oznaku (`v2`). Stari ključ premjestite u `QUIRE_MASTER_KEY_RETIRED` kao `v1=`. Sačuvajte kopije oba ključa izvan ovog hosta.
3. Implementirajte web sloj i worker s novim postavkama. Nove tajne sada se omotavaju referencom `env:QUIRE_MASTER_KEY:v2`; stare se još mogu otvoriti pomoću povučenog ključa.
4. Zatražite rotaciju i navedite razlog koji će se upisati u revizorski dnevnik:
- u konzoli: Security, Master key, Rotate the master key; ili
- u shellu s istim okruženjem: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker svake minute ponovo omotava dio vrijednosti (zadatak schedulera `platform.key_rotation`) i nastavlja nakon ponovnog pokretanja. Za dovršetak u jednom koraku pokrenite `bun run kek:rotate run`. Napredak pratite pomoću `bun run kek:rotate status`.
6. Kada zapis pokaže da je rotacija završena uz **nula neriješenih i nula neuspjelih** vrijednosti, uklonite povučeni ključ iz `QUIRE_MASTER_KEY_RETIRED` i ponovo implementirajte. Dotad ga zadržite: vrijednost koju rotacija nije uspjela premjestiti i dalje je omotana starim ključem.
### Šta zadatak obrađuje
Svako spremište koje čuva omotani DEK: stavke iz `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Spremišta kontrolne baze obrađuju se u toj bazi, a spremišta organizacija obrađuju se jednu po jednu uz row-level security u bazi gdje se organizacija nalazi; zato se organizacija vezana za namjensku bazu rotira upravo u njoj. Test pada kada se šemi doda kolona omotanog ključa koja nije navedena u popisu; drugi test pada ako pregled pristupnih podataka klasifikuje zapečaćenu kolonu koju popis propušta.
### Evidencija
- `ops.key_rotation`: po jedan red za rotaciju s razlogom, podnosiocem zahtjeva, stanjem i ukupnim brojevima (ponovo omotane, već aktuelne, neriješene, neuspjele).
- `ops.key_rotation_progress`: po jedan red za obrađeno spremište i opseg s referencama ključeva koje nije bilo moguće pročitati i brojem vrijednosti ispod svake reference. Nastavljena rotacija preskače te stavke.
- Revizorski lanac platforme: `platform/key_rotation_request` (s razlogom), po jedan `platform/key_rotation_store` po spremištu s brojevima i `platform/key_rotation_complete` ili `platform/key_rotation_fail`; `platform/key_age_reminder` za podsjetnik.
- Metrike: `quire.secrets.master_key.age` i `quire.secrets.rewrap.outstanding` (vrijednosti koje posljednja rotacija nije mogla premjestiti).
### Neriješene vrijednosti
Neriješena vrijednost omotana je referencom ključa koja nedostaje u ovoj instalaciji ili nema oblik koji njena kolona zahtijeva. Zapis napretka navodi referencu (npr. `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Vratite ključ u `QUIRE_MASTER_KEY_RETIRED` i ponovo pokrenite rotaciju; ako je ključ trajno izgubljen, zamolite administratora organizacije da ponovo unese pristupni podatak koji će se tada zapečatiti aktuelnim ključem. Neuspjela rotacija navodi grešku u zapisu; uklonite uzrok i ponovo je zatražite.
## Ključevi za potpisivanje
Nezavisno od glavnog ključa, svaka organizacija potpisuje vlastite OpenID Connect tokene i LTI poruke svojim RSA ključem objavljenim na `/.well-known/jwks.json`. Ovdje operater ne treba ništa poduzimati. Satni zadatak `platform.signing_keys` objavljuje sljedeći ključ sedam dana prije isteka devedesetodnevnog važenja aktuelnog ključa; sedmicu poslije sljedeći počinje potpisivati, a stari prelazi u povlačenje; nakon još 90 dana stari se briše i uklanja iz skupa ključeva. Svaki korak evidentira se kao `platform/signing_key_advance` u revizorskom lancu platforme.
Da biste ranije zamijenili ključ organizacije, npr. nakon njegovog otkrivanja:
- u konzoli: Security, Master key, Publish a new signing key (potrebno je `platform/keys_manage`); ili
- u shellu s okruženjem workera: `bun run kek:rotate signing-keys rotate
--tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate
signing-keys status` prikazuje fazu ključa za svaku organizaciju.
Novi ključ objavljuje se odmah i počinje potpisivati nakon sedam dana, kada se aktuelni povuče. Sedmica je namjerna: oslanjajuće strane keširaju skup ključeva, pa bi kraće preklapanje istovremeno pokvarilo sve alate. Povučeni ključ ostaje u skupu još 90 dana da bi se i dalje provjeravali tokeni koje je već potpisao. Ako nakon otkrivanja treba ranije prestati vjerovati ključu, njegov red se briše direktnim pristupom operatera bazi i uz vlastitu evidenciju promjene (hitni pristup je samo za čitanje); tada verifikacija tokena potpisanih tim ključem ne uspijeva. Prisilna rotacija bilježi se kao `platform/signing_key_rotate` u revizorskom lancu, uz razlog. Workeru trebaju iste postavke `QUIRE_MASTER_KEY` kao web sloju da bi omotao novi ključ; komanda `bun run kek:rotate` za glavni ključ ponovo omotava i ključeve za potpisivanje (`oauth_signing_key` se nalazi u `SEALED_STORES`).
## Hitni produkcijski pristup
Niko nema stalni pristup produkciji. Kada nešto ne može čekati, vlasnik izdaje privremeno hitno odobrenje u Platform konzoli: Security, Break-glass access.
- Odobrenje ima opseg (jedna organizacija ili registar platforme), razlog od najmanje 20 znakova koji navodi incident ili tiket i period od 5 do 240 minuta. Ističe automatski i provjerava se pri svakoj naredbi.
- Može ga dobiti vlasnik koji ga izdaje ili drugi vlasnik (postupak s dvije osobe). Koristi ga samo osoba kojoj je izdato. Izdavanje zahtijeva `platform/break_glass_issue`, a korištenje `platform/break_glass_use`; prema podrazumijevanim postavkama oba su prava samo za vlasnike.
- Naredbe se izvršavaju kroz gateway, ne prijavom u bazu: samo za čitanje, jedna po jedna, ograničene na organizaciju ili kontrolni registar, uz vremensko ograničenje od pet sekundi i najviše 500 redova. Binarne vrijednosti prikazuju se prema veličini.
- Revizorski lanac platforme bilježi izdavanje s razlogom, opoziv, svaku naredbu prije izvršenja (`platform/break_glass_statement`; odbijene imaju ishod `denied`) i svaki rezultat (`platform/break_glass_result`). `ops.break_glass_statement` sadrži ID-jeve revizorskih stavki kako bi se zapis izdavanja povezao s njima.
- Upis nije dostupan. Promjenu koja ne može čekati izdanje provodi operater vlastitim pristupom bazi i u zasebnom zapisu o promjeni, izvan ovog proizvoda; taj zapis treba navesti isti ID incidenta.
Zašto se ne izdaju pristupni podaci za bazu: Postgres prijava traje duže od sesije koja ju je zatražila, zaobilazi row-level security na koju se aplikacija oslanja i ne može zapisati u revizorski lanac ovog proizvoda. Naredbe bi se evidentirale samo ako je neko isporučio serverski dnevnik. Gateway čini revizorski trag osobinom samog pristupa, a ne postupkom oko njega.
Da biste odgovorili na revizorski zahtjev: izlistajte odobrenja za traženi period (Break-glass access), otvorite historiju odobrenja da vidite naredbe i ID-jeve revizorskih zapisa, pa ih pročitajte u revizorskom lancu platforme (`bun run audit:verify --platform` potvrđuje cjelovitost lanca).
Source: https://docs.quirelms.com/bs/ops/key-rotation/index.mdx