Rotacio de ĉefa kaj subskribaj ŝlosiloj, kaj urĝa aliro

Rotacii ĉefan ŝlosilon protektantan konservitajn legitimilojn kaj uzi urĝan aliron.

La kontroloj en sekcio 14 de 21-compliance.md, kiujn revizoro petas laŭnome. Ĉi tiu paĝo donas la proceduron; la registroj produktitaj de ĝi estas la pruvoj.

La ŝlosiloj

Ĉiu konservita legitimilo estas sigelita per freŝa datuma ĉifroŝlosilo (DEK). La DEK estas envolvita per la ĉefa ŝlosilo (KEK), kaj la referenco de la ĉefa ŝlosilo estas konservita apud ĝi (key_ref aŭ referenco ene de pakita valoro). Rotacio de ĉefa ŝlosilo envolvas la DEK-ojn denove. Ĝi neniam malĉifras aŭ reĉifras legitimilon.

Agordo	Signifo
`QUIRE_MASTER_KEY`	Aktuala ĉefa ŝlosilo: 32 bajtoj, base64. Ĉiu nova sekreto estas envolvita per ĝi
`QUIRE_MASTER_KEY_VERSION`	Ĝia versietikedo. `v1` se ne agordita. Pliigu ĝin ĉiufoje kiam vi ŝanĝas la ŝlosilon
`QUIRE_MASTER_KEY_RETIRED`	Antaŭaj ŝlosiloj kiuj ankoraŭ povas envolvi konservitajn sekretojn, kiel `v1=<base64>,v0=<base64>`. Legata, neniam skribata

La reta tavolo, worker kaj komando bun run kek:rotate legas la samajn tri agordojn. Ili devas havi identajn valorojn, alie unu ne povas malfermi tion, kion alia sigelis.

Sen QUIRE_MASTER_KEY, ĉiu subsistemo konservas la ŝlosilon derivitan el QUIRE_SECRET_KEY. Tio funkcias; la paĝo Sistema sano montras ĝin kiel malbonigitan, kaj ĝi restas legebla post agordo de ĉefa ŝlosilo — tiel la unua rotacio forigas ĉion de ĝi. Ĉiu povanta legi la procesmedion povas malĉifri ĉiun konservitan legitimilon, do produkta instalaĵo havu ĉefan ŝlosilon, konservatan en sekreta konservejo kaj ne en la sama sekurkopio kiel datumbazo.

Rotacii

La aĝo de ŝlosilo aperas en Platforma konzolo, Sekureco, Ĉefa ŝlosilo, kaj kiel metriko quire.secrets.master_key.age (tagoj). Ĉiutaga horaro platform.key_age (03:41 UTC) skribas memorigilon al la platforma kontrolĉeno kiam la ŝlosilo atingas 365 tagojn, kaj denove ĉiun 30-an tagon ĝis rotacio. Rotaciu pro memorigilo aŭ kiam ajn ŝlosilo povus esti elmontrita.

Generu novan ŝlosilon: openssl rand -base64 32.
Agordu QUIRE_MASTER_KEY al ĝi kaj QUIRE_MASTER_KEY_VERSION al la sekva etikedo (v2). Movu la malnovan ŝlosilon al QUIRE_MASTER_KEY_RETIRED kiel v1=<old base64>. Konservu kopion de ambaŭ aliloke ol ĉe ĉi tiu gastiganto.
Disfaldigu retan tavolon kaj worker kun la novaj agordoj. Novaj sekretoj nun estas envolvitaj sub env:QUIRE_MASTER_KEY:v2; malnovaj ankoraŭ malfermiĝas per la retiriĝinta ŝlosilo.
Petu rotacion kaj donu kialon registriĝontan en la kontrolprotokolo:
- en konzolo: Sekureco, Ĉefa ŝlosilo, Rotacii la ĉefan ŝlosilon; aŭ
- en ŝelo kun sama medio: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
Worker envolvas unu parton minute (la horaro de scheduler platform.key_rotation) kaj rekomencas post restartigo. Por fini per unu fojo: bun run kek:rotate run. Observu ĝin per bun run kek:rotate status.
Kiam registro montras finitan rotacion kun nul nesolvitaj kaj nul malsukcesintaj, forigu la retiriĝintan ŝlosilon el QUIRE_MASTER_KEY_RETIRED kaj redeplojigu. Ĝis tiam konservu ĝin: valoro ne movita ankoraŭ estas envolvita per la malnova ŝlosilo.

Kion trairas tasko

Ĉiun konservejon enhavantan envolvitan DEK: tiujn en SEALED_STORES (apps/worker/src/key-rotation.ts). Konservaĵoj de kontrola datumbazo estas trairataj tie; organizaĵaj konservaĵoj estas trairataj po unu organizaĵo sub row-level security en la datumbazo kiu enhavas ĝin, do luanto ligita al dediĉita datumbazo estas rotaciata en tiu datumbazo. Testo malsukcesas kiam la skemo ricevas envolvitan ŝlosilkolumnon ne listigitan, kaj alia kiam revizio de legitimiloj klasifikas sigelitan kolumnon preterlasitan de la listo.

La registro

ops.key_rotation: unu vico por ĉiu rotacio, kun kialo, petinto, stato kaj totaloj (ree envolvitaj, jam aktualaj, nesolvitaj, malsukcesintaj).
ops.key_rotation_progress: unu vico por konservejo kaj amplekso post trairo, kun la ŝlosilreferencoj nelegeblaj kaj nombro de valoroj sub ĉiu. Rekomencita rotacio preterlasas ĉi tiujn.
Platforma kontrolĉeno: platform/key_rotation_request (kun kialo), po unu platform/key_rotation_store por konservejo kun kalkuloj, kaj platform/key_rotation_complete aŭ platform/key_rotation_fail; platform/key_age_reminder por memorigilo.
Metrikoj: quire.secrets.master_key.age kaj quire.secrets.rewrap.outstanding (valoroj, kiujn la lasta rotacio ne povis movi).

Kiam valoroj estas nesolvitaj

Nesolvita valoro estas envolvita per ŝlosilreferenco ne posedata de ĉi tiu instalaĵo aŭ ne havas la formon promesitan de sia kolumno. La progreso-registro nomas la referencon (ekzemple env:QUIRE_MASTER_KEY:v0 (unreadable)). Restarigu tiun ŝlosilon en QUIRE_MASTER_KEY_RETIRED kaj rulu alian rotacion; se la ŝlosilo estas perdita por ĉiam, petu al administranto de organizaĵo reenigi la legitimilon: ĝi tiam estas sigelita per la aktuala ŝlosilo. Malsukcesintaj rotacioj montras eraron en la registro; korektu la kaŭzon kaj petu denove.

Subskribaj ŝlosiloj

Apartaj de ĉefa ŝlosilo: ĉiu organizaĵo subskribas siajn OpenID Connect-ĵetonojn kaj LTI-mesaĝojn per propra RSA-ŝlosilo publikigita ĉe /.well-known/jwks.json. Funkciiganto ne bezonas interveni. Ĉiuhora horaro platform.signing_keys publikigas posteulon sep tagojn antaŭ la naŭdek tagoj de la nuna ŝlosilo; semajnon poste la posteulo komencas subskribi kaj la malnova ŝlosilo iĝas retiriĝanta; naŭdek tagojn poste la malnova ŝlosilo estas forigita kaj forlasas la ŝlosilaron. Ĉiu paŝo estas platform/signing_key_advance-registro en la platforma kontrolĉeno.

Por frue anstataŭigi ŝlosilon de organizaĵo, ekzemple post malkovro:

en konzolo: Sekureco, Ĉefa ŝlosilo, Publikigi novan subskribŝlosilon (bezonas platform/keys_manage); aŭ
en ŝelo kun la medio de worker: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status listigas ĉies ŝlosilojn laŭ stadio.

La nova ŝlosilo estas publikigita tuj kaj komencas subskribi post sep tagoj, kiam la nuna emeritiĝas. Tiu semajno estas intenca: fidantaj partioj konservas ŝlosilaron en kaŝmemoro, kaj pli mallonga interkovro fiaskigus ĉiujn ilojn samtempe. La retiriĝanta ŝlosilo restas en la aro ankoraŭ naŭdek tagojn por ke jam subskribitaj ĵetonoj plu validu. Se la elmontriĝo postulas pli fruan ĉeson de fido, forigo de ĝia vico estas ŝanĝo farota per propra datumbaza aliro de la funkciiganto laŭ ŝanĝregistro (urĝa aliro estas nurlegebla); ĵetonoj subskribitaj per ĝi tiam malsukcesos validigon. La devigita rotacio estas platform/signing_key_rotate en kontrolĉeno kun kialo. Worker bezonas samajn QUIRE_MASTER_KEY-agordojn kiel reta tavolo por envolvi novan ŝlosilon; bun run kek:rotate por ĉefa ŝlosilo envolvas denove subskribajn ŝlosilojn kune kun ĉio alia (oauth_signing_key estas en SEALED_STORES).

Urĝa produkta aliro

Neniu havas konstantan aliron al produktado. Kiam io ne povas atendi, posedanto donas urĝan alirpermeson: Platforma konzolo, Sekureco, Urĝa aliro.

Permeso havas amplekson (unu organizaĵon aŭ platforman registron), kialon de almenaŭ 20 signoj nomantan incidenton aŭ bileton, kaj fenestron de 5 ĝis 240 minutoj. Ĝi aŭtomate eksvalidiĝas: ĉe ĉiu instrukcio ĝi estas kontrolata kontraŭ la horloĝo.
Ĝi povas esti donita al eldonanta posedanto aŭ alia posedanto (dupersona formo). Nur la celita persono povas uzi ĝin. Donado bezonas platform/break_glass_issue kaj uzado bezonas platform/break_glass_use; ambaŭ estas defaŭlte nur por posedantoj.
Instrukcioj ruliĝas tra la enirejo, ne per datumbaza ensaluto: nurlegaj, unuope, limigitaj al la organizaĵo aŭ kontrolregistro, kun kvinsekunda tempolimo kaj maksimume 500 vicoj. Duumaj valoroj estas montrataj laŭ grando.
La platforma kontrolĉeno registras la eldonon (kun kialo), revokon, ĉiun instrukcion antaŭ ĝia rulado (platform/break_glass_statement; rifuzitaj kun rezulto denied) kaj ĉiun rezulton (platform/break_glass_result). ops.break_glass_statement enhavas ID-ojn de kontrolregistraĵoj, por ke la eldonregistro ligiĝu al ili.
Skribado ne estas ofertata. Ŝanĝo ne atendebla ĝis eldono uzas propran datumbazan aliron de la funkciiganto sub aparta ŝanĝregistro, ekster ĉi tiu produkto, kaj tiu registro referencu la incidenton uzitan ĉi tie.

Kial ne doni datumbazajn legitimilojn? Postgres-ensaluto daŭras pli longe ol la sesio petinta ĝin, preterpasas row-level security uzatan de aplikaĵo kaj ne povas skribi al la kontrolĉeno de ĉi tiu produkto; do ĝiaj instrukcioj estus registrataj nur tiom longe, kiom iu sendis servilan protokolon. La enirejo faras kontrolspuron eco de aliro, ne kutimo ĉirkaŭ ĝi.

Por respondi al revizia peto: listigu permesojn de la periodo (Urĝa aliro), malfermu historion por vidi instrukciojn kaj ID-ojn de kontrolregistroj, kaj legu tiujn registrojn en la platforma kontrolĉeno (bun run audit:verify --platform pruvas, ke la ĉeno estas sendifekta).