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.

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