--- title: "Pagpapalit ng master key at signing key, at emergency access" description: "Palitan ang master key na nagpoprotekta sa nakaimbak na credential at gamitin ang emergency access." image: "https://docs.quirelms.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://docs.quirelms.com/fil/llms.txt > Use this file to discover all available pages before exploring further. # 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. | Setting | Kahulugan | | --- | --- | | `QUIRE_MASTER_KEY` | Kasalukuyang master key: 32 byte, base64. Dito ibinabalot ang bawat bagong secret | | `QUIRE_MASTER_KEY_VERSION` | Label ng bersiyon nito; `v1` kapag hindi itinakda. Itaas ito tuwing papalitan ang key | | `QUIRE_MASTER_KEY_RETIRED` | Mga lumang key na maaaring gumamit sa pag-seal ng secret, gaya ng `v1=,v0=`. Binabasa, hindi sinusulatan | 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=`. 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 --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). Source: https://docs.quirelms.com/fil/ops/key-rotation/index.mdx