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.

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=<old base64>. 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 <slug or id> --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).