Pagpapalit ng master key at signing key, at emergency access

Ito ang mga kontrol sa 21-compliance.md seksiyon 14 na hinihingi ng pangalan ng auditor. Pamamaraan ang pahinang ito; ebidensiya ang mga rekord na nalilikha nito.

Mga key

Sinaselyuhan ang bawat nakaimbak na credential gamit ang bagong data encryption key (DEK). Binabalot ito ng master key (KEK) at iniimbak sa tabi nito ang reference ng master key (key_ref o reference sa loob ng naka-pack na value). Muling ibinabalot ng pagpapalit ng master key ang DEK; hindi nito dine-decrypt o muling ine-encrypt ang credential.

Binabasa ng web tier, worker, at command na bun run kek:rotate ang parehong tatlong setting. Dapat magkapareho ang mga value ng lahat; kung hindi, hindi mabubuksan ng isa ang sinelyuhan ng iba.

Kapag walang QUIRE_MASTER_KEY, pinananatili ng bawat subsystem ang key na hinango nito mula sa QUIRE_SECRET_KEY. Gumagana ito, ipinapakita ng System health page na degraded ang kondisyon, at nananatiling nababasa pagkaraang magtakda ng master key; sa ganitong paraan inililipat ng unang rotation ang lahat mula rito. Kayang i-decrypt ng sinumang nakakabasa sa environment ng proseso ang lahat ng nakaimbak na credential, kaya dapat magtaglay ng master key ang production installation, nasa secret store ito at hindi kasama ng database sa iisang backup.

Pagpapalit

Ipinapakita ang edad ng key sa Platform console, Security, Master key at metric na quire.secrets.master_key.age (araw). Naglalagay ng paalala ang araw-araw na platform.key_age schedule (03:41 UTC) sa platform audit chain kapag 365 araw na ang key at kada 30 araw pagkatapos nito hanggang mapalitan. Magpalit sa oras ng paalala at kapag posibleng nalantad ang key.

1. Gumawa ng bagong key: openssl rand -base64 32.
2. Itakda rito ang QUIRE_MASTER_KEY at itakda ang QUIRE_MASTER_KEY_VERSION sa susunod na label (v2). Ilagay ang lumang key sa QUIRE_MASTER_KEY_RETIRED bilang v1=<old base64>. Magtago ng kopya ng dalawa sa labas ng host na ito.
3. I-deploy ang web tier at worker gamit ang bagong setting. Ibabalot na sa env:QUIRE_MASTER_KEY:v2 ang mga bagong secret; mabubuksan pa rin ang luma gamit ang retired key.
4. Humiling ng rotation na may dahilang itatala sa audit trail:
   • sa console: Security, Master key, Rotate the master key; o
   • sa shell na may parehong environment: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Muling magbabalot ang worker ng isang bahagi bawat minuto (schedule ng scheduler na platform.key_rotation) at magpapatuloy pagkaraang mag-restart. Para tapusin nang isang upuan: bun run kek:rotate run. Bantayan gamit ang bun run kek:rotate status.
6. Kapag nakasaad sa record na tapos na ang rotation at zero unresolved at zero failed, alisin sa QUIRE_MASTER_KEY_RETIRED ang retired key at muling i-deploy. Panatilihin ito hanggang noon: maaaring nakabalot pa rin rito ang hindi nailipat na value.

Aling data ang sinusuri ng job

Bawat store na may naka-pack na DEK: ang nasa SEALED_STORES (apps/worker/src/key-rotation.ts). Sinusuri sa control database ang mga store nito; iniisa-isa naman ang store ng organisasyon sa ilalim ng row-level security bawat organisasyon, sa database na kinaroroonan nito. Kaya sa database na iyon iniikot ang key ng tenant na naka-pin sa dedicated database. Pumapalya ang isang test kapag nadagdagan ang schema ng column na may naka-wrap na key na wala sa listahan, gayundin kapag may sealed column sa pagsusuri ng credential na hindi nasasaklaw ng listahan.

Ang rekord

• ops.key_rotation: isang row bawat rotation, kasama ang dahilan, humiling, estado, at kabuuan (muling binalot, napapanahon na, unresolved, failed).
• ops.key_rotation_progress: isang row bawat store at scope na nasuri, kasama ang mga reference ng key na hindi mabasa at bilang ng value sa ilalim ng bawat isa. Nilalaktawan ng ipinagpatuloy na rotation ang mga ito.
• Platform audit chain: platform/key_rotation_request (kasama ang dahilan), isang platform/key_rotation_store bawat store kasama ang bilang, at platform/key_rotation_complete o platform/key_rotation_fail; platform/key_age_reminder para sa paalala.
• Mga metric: quire.secrets.master_key.age at quire.secrets.rewrap.outstanding (mga value na hindi nailipat ng huling rotation).

Kapag unresolved ang mga value

Naka-wrap ang unresolved na value gamit ang key reference na wala sa installation mo o hindi ito ayon sa hugis na inaasahan ng column. Ipinapakita ng progress record ang reference, halimbawa env:QUIRE_MASTER_KEY:v0 (unreadable). Ibalik ang key na iyon sa QUIRE_MASTER_KEY_RETIRED at magpatakbo muli ng rotation; o, kung tuluyan nang nawala ang key, hilingin sa administrador ng organisasyon na muling ilagay ang credential upang maiselyo ito gamit ang kasalukuyang key. Ipinapakita ng record ang error ng failed rotation; itama ang sanhi at humiling muli.

Mga signing key

Bukod sa master key, pumipirma ang bawat organisasyon ng OpenID Connect token at LTI message gamit ang sarili nitong RSA key, na inilalathala sa /.well-known/jwks.json. Walang kailangang gawin dito ang operator. Inilalathala ng oras-oras na platform.signing_keys schedule ang kapalit pitong araw bago mag-90 araw ang kasalukuyang key; makalipas ang isang linggo magsisimulang pumirma ang kapalit at magiging retiring ang luma; 90 araw pa ang lilipas bago burahin ang luma sa key set. Itinatala ang bawat hakbang sa platform audit chain bilang platform/signing_key_advance.

Para maagang palitan ang key ng organisasyon, halimbawa kapag nalantad ito:

• sa console: Security, Master key, Publish a new signing key (kailangan ang platform/keys_manage); o
• sa shell na may environment ng worker: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". Inililista ng bun run kek:rotate signing-keys status ang mga key ng bawat organisasyon ayon sa yugto.

Agad na inilalathala ang bagong key at magsisimulang pumirma pagkaraan ng pitong araw, kapag nagretiro na ang kasalukuyan. Sadyang isang linggo ang pagitan dahil naka-cache ang key set ng relying party at mabibigo ang lahat ng tool nang sabay kung mas maikli ito. Mananatili sa key set ang retiring na key sa loob ng 90 araw pa para patuloy na ma-verify ang mga pinirmahan na nitong token. Kung kailangang huwag na itong pagkatiwalaan agad dahil sa exposure, burahin ang row nito gamit ang sariling database access ng operator sa ilalim ng change record (read-only ang break-glass access); mabibigo na ang pag-verify sa token na nilagdaan nito. platform/signing_key_rotate ang forced rotation sa audit chain, kasama ang rason. Kailangan ng worker ang parehong QUIRE_MASTER_KEY setting ng web tier para ibalot ang bagong key; muling binabalot ng bun run kek:rotate para sa master key ang mga signing key kasama ng iba (oauth_signing_key ay nasa SEALED_STORES).

Emergency access sa production

Walang may permanenteng access sa production. Kapag hindi makapaghintay ang problema, nagbibigay ang may-ari ng break-glass grant: Platform console, Security, Break-glass access.

• May scope ang grant (isang organisasyon o platform registry), dahilan na hindi bababa sa 20 character at tumutukoy sa incident o ticket, at tagal na 5 hanggang 240 minuto. Kusang mag-e-expire ito; sinusuri ang oras sa bawat statement.
• Maaaring ibigay ang grant sa nagbigay na may-ari o sa ibang may-ari (two-person process). Tanging pinagbigyan nito ang makagagamit. Kailangan ang platform/break_glass_issue sa pagbibigay at platform/break_glass_use sa paggamit; default na may-ari lang ang parehong pahintulot.
• Dumaraan sa gateway, hindi database login, ang mga statement: read-only, paisa-isa, limitado sa organisasyon o control registry, may limang segundong timeout at hanggang 500 row. Ipinapakita ang binary value ayon sa laki.
• Itinatala ng platform audit chain ang pagbibigay (kasama ang dahilan), pagbawi, bawat statement bago patakbuhin (platform/break_glass_statement; denied ang resulta ng tinanggihan), at bawat resulta (platform/break_glass_result). Nasa ops.break_glass_statement ang ID ng audit entry kaya naiuugnay ang grant sa mga audit entry nito.
• Hindi pinapayagan ang pagsusulat. Kung hindi makapaghintay ng release ang pagbabago, gamitin ang sariling database access ng operator sa ilalim ng sarili nitong change record, sa labas ng produktong ito; dapat tukuyin ng record ang incident reference na ginamit dito.

Bakit hindi maglabas ng database credential? Higit na matagal ang Postgres login kaysa sa session na humiling nito, lumalampas ito sa row-level security na inaasahan ng application, at hindi ito nakapagsusulat sa audit chain ng produktong ito; kaya ang server log lang ang magtatala sa statement kapag nailabas ito. Ginagawang katangian ng access ng gateway ang audit trail sa halip na dagdag na gawain.

Para sagutin ang audit request: ilista ang mga grant sa panahong hinihingi (Break-glass access), buksan ang history ng grant para sa statement at ID ng audit entry, at basahin ang mga entry sa platform audit chain (bun run audit:verify --platform ang nagpapatunay na buo ang chain).