Master key en signing key rotearje, en needtagong

De kontrôles yn seksje 14 fan 21-compliance.md dêr’t in auditor by namme om freget. Dizze side is de proseduere; de records dy’t dy opleveret binne it bewiis.

De kaaien

Elk bewarre bewiis wurdt fersifere mei in nije data-encryption key (DEK). De master key (KEK) ferpakt de DEK, en it referinsjelabel fan de master key wurdt dernjonken bewarre (key_ref, of de ferwizing yn in gearstald wearde). By it rotearjen fan de master key wurde DEK’s opnij ferpakt. It bewiis sels wurdt nea ûntsifere of opnij fersifere.

Setting	Betsjutting
`QUIRE_MASTER_KEY`	Aktuele master key: 32 byte, base64. Elk nij geheim wurdt dêrmei ferpakt
`QUIRE_MASTER_KEY_VERSION`	It ferzjelabel. `v1` as it net ynsteld is. Ferheegje dit elke kear datst de kaai feroarest
`QUIRE_MASTER_KEY_RETIRED`	Eardere kaaien dêr’t bewarre geheimen noch ûnder sitte kinne, as `v1=<base64>,v0=<base64>`. Allinnich lêzen, nea skreaun

De web tier, worker en it kommando bun run kek:rotate lêze deselde trije ynstellingen. Se moatte allegear deselde wearden hawwe, oars kin ien net iepenje wat in oare ferpakt hat.

Sûnder QUIRE_MASTER_KEY hâldt elk subsysteem de kaai dy’t it fan QUIRE_SECRET_KEY ôfliedt. Dat wurket; de side Systeemsûnens lit de steat as degradearre sjen, en it bliuwt lêsber as in master key ynsteld wurdt. Sa ferhuzet by de earste rotaasje alles derfan ôf. Elkenien dy’t de prosesomjouwing lêze kin, kin elk bewarre bewiis ûntsiferje; in produksjeynlaasje moat dus in master key hawwe, bewarre yn in secret store en net yn deselde reservekopy as de database.

Rotearje

De leeftyd fan de kaai stiet yn it platfoarmkonsole by Security, Master key, en as metric quire.secrets.master_key.age (dagen). It deistige skema platform.key_age (03:41 UTC) skriuwt in herinnering yn de auditkeatling fan it platfoarm as de kaai 365 dagen âld wurdt, en dêrnei elke 30 dagen oant se rotearre is. Roteer nei in herinnering en elke kear dat in kaai bleatlein wêze kin.

Meitsje de nije kaai: openssl rand -base64 32.
Stel QUIRE_MASTER_KEY yn op de nije wearde en QUIRE_MASTER_KEY_VERSION op it folgjende label (v2). Ferpleats de âlde kaai nei QUIRE_MASTER_KEY_RETIRED as v1=<old base64>. Hâld fan beide in kopy bûten dizze host.
Set de web tier en worker yn mei de nije ynstellingen. Nije geheimen wurde no ferpakt ûnder env:QUIRE_MASTER_KEY:v2; âlde geheimen iepenje noch mei de eardere kaai.
Freegje de rotaasje oan mei in reden dy’t yn it auditlogboek komt:
- yn it konsole: Security, Master key, Rotate the master key; of
- yn in shell mei deselde omjouwing: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
De worker ferpakt elke minút in part op skema platform.key_rotation en giet nei in trochstart fierder. Om alles yn ien sesje ôf te meitsjen: bun run kek:rotate run. Folgje de fuortgong mei bun run kek:rotate status.
As it record sjen lit dat de rotaasje foltôge is mei nul net oplost en nul mislearre, helje de eardere kaai út QUIRE_MASTER_KEY_RETIRED en set de tsjinsten opnij yn. Hâld de kaai oant dan: in wearde dy’t net ferpleatst wurde koe, is noch mei de âlde kaai ferpakt.

Wat de taak trochgiet

Elke store mei in ferpakt DEK: de stores yn SEALED_STORES (apps/worker/src/key-rotation.ts). Stores fan de kontrôledatabase wurde yn de kontrôledatabase trochgien; organisaasjestores ien organisaasje tagelyk ûnder row-level security, yn de database dêr’t de organisaasje yn stiet. Sa wurdt in tenant op in tawijde database dêr ek rotearre. In test mislearret as it skema in kolom mei in ferpakte kaai krijt dy’t de list net neamt; in oare test docht dat as de credential review in fersifere kolom fynt dy’t de list mist.

It record

ops.key_rotation: ien rige per rotaasje, mei reden, oanfreger, steat en totalen (opnij ferpakt, al aktueel, net oplost, mislearre).
ops.key_rotation_progress: ien rige per trochgiene store en omfang, mei de kaaiferwizingen dy’t net lêzen wurde koene en it tal wearden ûnder elke ferwizing. In ferfette rotaasje slacht dizze oer.
Auditkeatling fan it platfoarm: platform/key_rotation_request (mei reden), ien platform/key_rotation_store per store mei tellings, en platform/key_rotation_complete of platform/key_rotation_fail; platform/key_age_reminder foar de herinnering.
Metrics: quire.secrets.master_key.age en quire.secrets.rewrap.outstanding (wearden dy’t de lêste rotaasje net ferpleatse koe).

As wearden net oplost binne

In net oploste wearde is ferpakt ûnder in kaaiferwizing dy’t dizze ynstallaasje net hat, of hat net de foarm dy’t de kolom taseit. It fuortgongsrecord neamt de ferwizing (bygelyks env:QUIRE_MASTER_KEY:v0 (unreadable)). Set dy kaai werom yn QUIRE_MASTER_KEY_RETIRED en fier in nije rotaasje út, of lit, as de kaai foargoed fuort is, de behearder fan de organisaasje it bewiis opnij ynfiere: dan wurdt it mei de aktuele kaai fersifere. Mislearre rotaasjes litte de flater yn it record sjen; ferhelp de oarsaak en freegje opnij oan.

Signing keys

Los fan de master key: elke organisaasje ûndertekenet OpenID Connect-tokens en LTI-berjochten mei in eigen RSA-kaai, publisearre op /.well-known/jwks.json. In operator hoecht hjir neat foar te dwaan. It skema platform.signing_keys publisearret elk oere in opfolger sân dagen foar’t de njoggentich dagen fan de aktuele kaai om binne; in wike letter ûndertekenet de opfolger en wurdt de âlde kaai ôfgeande; njoggentich dagen dêrnei wurdt de âlde kaai wiske en út de kaaiset helle. Elke stap is in yngong platform/signing_key_advance yn de auditkeatling.

Om de kaai fan in organisaasje earder te ferfangen, bygelyks nei bleatstelling:

yn it konsole: Security, Master key, Publish a new signing key (freget platform/keys_manage); of
yn in shell mei de omjouwing fan 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 list de kaaien fan alle organisaasjes neffens faze.

De nije kaai wurdt daliks publisearre en begjint nei sân dagen mei ûndertekenjen, as de aktuele kaai ôfgeand wurdt. Dy wike is mei opsetsin: fertrouwende systemen bewarje de kaaiset yn cache, en in koartere oerlaap makket dat alle ark tagelyk mislearje kinne. De ôfgeande kaai bliuwt noch njoggentich dagen yn de kaaiset sadat al ûndertekene tokens ferifiearre bliuwe. As bleatstelling fereasket dat dy earder net mear fertroud wurdt, is it wiskjen fan syn rige in feroaring fia de eigen databanktagong fan de operator ûnder in feroaringsrecord (needtagong is allinnich-lêzen); tokens mei dy kaai falle dan ôf by ferifikaasje. De twongen rotaasje is platform/signing_key_rotate yn it auditlogboek, mei de reden. De worker hat deselde QUIRE_MASTER_KEY-ynstellingen as de web tier nedich om de nije kaai te ferpakken; bun run kek:rotate foar de master key ferpakt signing keys mei de rest opnij (oauth_signing_key stiet yn SEALED_STORES).

Needtagong ta produksje

Nimmen hat permaninte tagong ta produksje. As eat net wachtsje kin, jout in eigner in needtagongsrjocht út: Platfoarmkonsole, Security, Break-glass access.

In rjocht hat in omfang (ien organisaasje of it platfoarmregister), in reden fan op syn minst 20 tekens mei it ynsidint of ticket, en in tiidfinster fan 5 oant 240 minuten. It ferrint automatysk: by elke statement wurdt it mei de klok ferlike.
It kin útjûn wurde oan de eigner dy’t it útjout of oan in oare eigner (fereasket twa persoanen). Allinnich de persoan oan wa’t it útjûn is, kin it brûke. Utjaan freget platform/break_glass_issue; brûken freget platform/break_glass_use. Standert binne beide allinnich foar eigners.
Statements rinne troch de gateway, net fia in databankoanmelding: allinnich lêzen, ien tagelyk, beheind ta de organisaasje of it kontrôleregister, mei in timeout fan fiif sekonden en maksimaal 500 rigen. Binêre wearden wurde mei harren grutte werjûn.
De auditkeatling fan it platfoarm registrearret it útjaan (mei reden), ynlûken, elke statement foardat dy útfierd wurdt (platform/break_glass_statement, ôfwiisde statements mei resultaat denied) en elk resultaat (platform/break_glass_result). ops.break_glass_statement bewarret de ID’s fan audit-yngongen, sadat it útjouwingsrecord oan syn yngongen keppele is.
Skriuwen wurdt net oanbean. In feroaring dy’t net op in release wachtsje kin, wurdt bûten dit produkt mei de eigen databanktagong fan de operator útfierd ûnder in eigen feroaringsrecord; dat record heart de hjir brûkte ynsidintreferinsje te neamen.

Wêrom gjin databankbewizen útjaan: in Postgres-oanmelding bliuwt bestean nei de sesje dy’t derom frege, omgiet de row-level security dêr’t de applikaasje op fertrout en kin net nei de auditkeatling fan dit produkt skriuwe. Statements soene dan allinnich sa fier kontrolearre wurde as immen de tsjinnerlog ferstjoerd hie. De gateway makket it auditspoar in eigenskip fan de tagong ynstee fan in gewoante deromhinne.

Om in auditfersyk te beantwurdzjen: list de rjochten yn de perioade (Break-glass access), iepenje de skiednis fan in rjocht foar de statements en audit-ID’s en lês dy yngongen yn de auditkeatling fan it platfoarm (bun run audit:verify --platform bewiist dat de keatling yntakt is).