--- title: "Rotacija glavnog ključa i ključa za potpisivanje te hitni pristup" description: "Rotirajte glavni ključ koji štiti pohranjene vjerodajnice i koristite hitni pristup." image: "https://docs.quirelms.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://docs.quirelms.com/hr/llms.txt > Use this file to discover all available pages before exploring further. # Rotacija glavnog ključa i ključa za potpisivanje te hitni pristup Kontrole iz odjeljka 14 dokumenta 21-compliance.md koje revizori traže po imenima. Ova stranica opisuje postupak; zapisi koji nastaju njegovim provođenjem služe kao dokaz. ## Ključevi Svaka pohranjena vjerodajnica šifrira se svježim ključem za šifriranje podataka (DEK). DEK je omotan glavnim ključem (KEK), a njegova referenca pohranjuje se uz njega (`key_ref` ili referenca unutar zapakirane vrijednosti). Rotacijom glavnog ključa ponovno se omataju DEK-ovi. Vjerodajnica se nikad ne dešifrira ni ponovno šifrira. | Postavka | Značenje | | --- | --- | | `QUIRE_MASTER_KEY` | Trenutačni glavni ključ: 32 bajta u base64 kodiranju. Svaka nova tajna omata se njime | | `QUIRE_MASTER_KEY_VERSION` | Oznaka njegove verzije. `v1` ako nije postavljena. Povećajte je pri svakoj promjeni ključa | | `QUIRE_MASTER_KEY_RETIRED` | Stariji ključevi pod kojima se tajne možda još nalaze, u obliku `v1=,v0=`. Služe za čitanje, nikad za zapisivanje | Web sloj, radnik i naredba `bun run kek:rotate` čitaju iste tri postavke. Sve moraju imati jednake vrijednosti ili jedan od njih neće moći otvoriti ono što je drugi omotao. Bez `QUIRE_MASTER_KEY` svaki podsustav zadržava ključ izveden iz `QUIRE_SECRET_KEY`. To funkcionira, stranica System health prikazuje upozoravajuće stanje, a vrijednosti ostaju čitljive nakon postavljanja glavnog ključa. Tako se pri prvoj rotaciji sve premješta sa starog ključa. Svatko tko može čitati okruženje procesa može dešifrirati sve pohranjene vjerodajnice, pa produkcijska instalacija treba imati glavni ključ pohranjen u spremištu tajni, a ne u istoj sigurnosnoj kopiji kao baza podataka. ## Rotacija Starost ključa prikazuje se u konzoli Platform, odjeljku Security, pod Master key, a dostupna je i kao metrika `quire.secrets.master_key.age` (dani). Dnevni raspored `platform.key_age` (03:41 UTC) zapisuje podsjetnik u lanac nadzora platforme kad ključ navrši 365 dana, a zatim svakih 30 dana dok se ne rotira. Provedite rotaciju po primitku podsjetnika i kad god postoji mogućnost da je ključ bio izložen. 1. Stvorite novi ključ: `openssl rand -base64 32`. 2. Postavite `QUIRE_MASTER_KEY` na njegovu vrijednost, a `QUIRE_MASTER_KEY_VERSION` na sljedeću oznaku (`v2`). Stari ključ premjestite u `QUIRE_MASTER_KEY_RETIRED` kao `v1=`. Sačuvajte kopije obaju ključeva na mjestu izvan ovog poslužitelja. 3. Uvedite web sloj i radnika s novim postavkama. Nove tajne sada se omataju pod `env:QUIRE_MASTER_KEY:v2`; stare se i dalje otvaraju putem povučenog ključa. 4. Zatražite rotaciju i navedite razlog koji će ostati u tragu nadzora: - u konzoli: Security, Master key, Rotate the master key; ili - u ljusci s istim okruženjem: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`. 5. Radnik ponovno omata dio vrijednosti svake minute (raspored `platform.key_rotation`) i nastavlja nakon ponovnog pokretanja. Da biste dovršili sve odjednom, pokrenite `bun run kek:rotate run`. Pratite postupak naredbom `bun run kek:rotate status`. 6. Kad zapis pokaže dovršenu rotaciju s **nula nerazriješenih i nula neuspjelih** stavki, uklonite povučeni ključ iz `QUIRE_MASTER_KEY_RETIRED` i ponovno uvedite uslugu. Do tada ga čuvajte: vrijednost koju postupak nije mogao premjestiti i dalje je omotana starim ključem. ### Podaci koje posao obrađuje Svako spremište koje sadrži omotani DEK: ona navedena u `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Spremišta upravljačke baze obrađuju se u upravljačkoj bazi; spremišta organizacija obrađuju se po jedna organizacija odjednom, uz sigurnost na razini retka i u bazi u kojoj se organizacija nalazi. Tako se rotira i klijent prikvačen na namjensku bazu, i to u toj bazi. Test ne prolazi ako shema dobije stupac s omotanim ključem koji nije naveden na popisu; drugi test provjerava da klasifikacija vjerodajnica ne izostavlja nijedan zaštićeni stupac. ### Zapis - `ops.key_rotation`: jedan redak po rotaciji sadrži razlog, podnositelja zahtjeva, stanje i ukupne vrijednosti (ponovno omotano, već aktualno, nerazriješeno, neuspjelo). - `ops.key_rotation_progress`: jedan redak po obrađenom spremištu i opsegu navodi reference ključeva koje postupak nije mogao pročitati te broj vrijednosti pod svakom referencom. Nastavljena rotacija preskače te stavke. - Lanac nadzora platforme: `platform/key_rotation_request` (s razlogom), po jedan `platform/key_rotation_store` za svako spremište s brojevima te `platform/key_rotation_complete` ili `platform/key_rotation_fail`; za podsjetnik se koristi `platform/key_age_reminder`. - Metrike: `quire.secrets.master_key.age` i `quire.secrets.rewrap.outstanding` (vrijednosti koje prethodna rotacija nije mogla premjestiti). ### Nerazriješene vrijednosti Nerazriješena je vrijednost omotana ključem čiju referencu ova instalacija ne posjeduje ili nije u obliku koji njezin stupac zahtijeva. Zapis napretka navodi referencu (primjerice `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Vratite taj ključ u `QUIRE_MASTER_KEY_RETIRED` i ponovno pokrenite rotaciju. Ako je ključ zauvijek izgubljen, zatražite od administratora organizacije da ponovno unese vjerodajnicu; ona će se tada omotati trenutačnim ključem. Neuspjele rotacije prikazuju pogrešku u zapisu; otklonite uzrok pa ponovno podnesite zahtjev. ## Ključevi za potpisivanje Odvojeno od glavnog ključa: svaka organizacija potpisuje svoje tokene OpenID Connect i poruke LTI vlastitim RSA ključem, objavljenim na `/.well-known/jwks.json`. Za ovaj postupak nije potrebna radnja operatera. Dnevni raspored `platform.signing_keys` objavljuje sljedeći ključ sedam dana prije isteka trenutačnog roka od devedeset dana. Tjedan dana kasnije sljedeći ključ počinje potpisivati, a stari prelazi u povlačenje. Devedeset dana nakon toga stari ključ briše se i uklanja iz skupa ključeva. Svaki korak zapisuje se kao `platform/signing_key_advance` u lanac nadzora platforme. Za raniju zamjenu ključa organizacije, primjerice nakon otkrivanja izloženosti: - u konzoli: Security, Master key, Publish a new signing key (potrebna je ovlast `platform/keys_manage`); ili - u ljusci s okruženjem radnika: `bun run kek:rotate signing-keys rotate --tenant --reason "Key exposed, INC-3310"`. Naredbom `bun run kek:rotate signing-keys status` prikazuju se ključevi svih organizacija po fazama. Novi ključ odmah se objavljuje i počinje potpisivati nakon sedam dana, kad se trenutačni ključ povuče. Tjedni razmak namjeran je: pouzdajuće strane predmemoriraju skup ključeva, a kraće preklapanje odjednom bi onemogućilo sve alate. Ključ u povlačenju ostaje u skupu još devedeset dana kako bi se nastavila provjera tokena koje je već potpisao. Ako zbog izloženosti više ne smije biti pouzdan, brisanje njegova retka promjena je koju operator provodi vlastitim pristupom bazi podataka i evidentira zapisom o promjeni (hitni pristup je samo za čitanje); tokeni potpisani tim ključem tada više neće proći provjeru. Prisilna rotacija bilježi se kao `platform/signing_key_rotate` u lancu nadzora, zajedno s razlogom. Radnik treba iste postavke `QUIRE_MASTER_KEY` kao web sloj kako bi omotao novi ključ; naredba `bun run kek:rotate` za glavni ključ ponovno omata ključeve za potpisivanje zajedno sa svima ostalima (`oauth_signing_key` je u `SEALED_STORES`). ## Hitni produkcijski pristup Nitko nema trajni pristup produkciji. Kad nešto ne može čekati, vlasnik izdaje hitno odobrenje: Platform console, Security, Break-glass access. - Odobrenje ima opseg (jedna organizacija ili registar platforme), razlog od najmanje 20 znakova koji navodi incident ili zahtjev te razdoblje od 5 do 240 minuta. Istječe samo od sebe: provjerava se prema satu pri svakoj naredbi. - Može se izdati vlasniku koji ga izdaje ili drugom vlasniku (postupak s dvije osobe). Može ga koristiti samo osoba kojoj je izdano. Za izdavanje je potrebna ovlast `platform/break_glass_issue`, a za korištenje `platform/break_glass_use`; prema zadanim postavkama obje su ovlasti samo za vlasnike. - Naredbe se izvršavaju putem pristupnika, a ne prijavom u bazu: samo za čitanje, jedna po jedna, ograničene na organizaciju ili upravljački registar, uz vremensko ograničenje od pet sekundi i najviše 500 redaka. Binarne se vrijednosti prikazuju prema veličini. - Lanac nadzora platforme bilježi izdavanje (s razlogom), opoziv, svaku naredbu prije njezina izvršavanja (`platform/break_glass_statement`; odbijene imaju ishod `denied`) i svaki rezultat (`platform/break_glass_result`). `ops.break_glass_statement` sadrži ID-jeve zapisa nadzora, pa se zapis o izdavanju može povezati s njima. - Pisanje nije omogućeno. Promjenu koja ne može čekati izdanje operator provodi vlastitim pristupom bazi podataka, uz zaseban zapis o promjeni i izvan ovog proizvoda; u zapisu treba navesti ovdje korištenu referencu incidenta. Zašto se ne izdaju vjerodajnice baze podataka: prijava u Postgres traje dulje od sesije koja ju je zatražila, zaobilazi sigurnost na razini retka na koju se aplikacija oslanja i ne može zapisivati u lanac nadzora ovog proizvoda. Zato bi se njezine naredbe nadzirale samo do trenutka kad netko pošalje zapis poslužitelja. Pristupnik čini trag nadzora sastavnim dijelom pristupa, a ne okolnom praksom. Za odgovor na revizijski zahtjev: navedite odobrenja iz traženog razdoblja (Break-glass access), otvorite povijest odobrenja kako biste vidjeli naredbe i ID-jeve zapisa nadzora te pročitajte te zapise u lancu nadzora platforme (`bun run audit:verify --platform` potvrđuje cjelovitost lanca). Source: https://docs.quirelms.com/hr/ops/key-rotation/index.mdx