Neidio i'r cynnwys

Newid yr allwedd feistr a'r allwedd lofnodi, a mynediad brys

Newid yr allwedd feistr sy'n diogelu manylion mewngofnodi sydd wedi'u storio, a defnyddio mynediad brys.

Gweld fel Markdown

Y rheolyddion yn adran 14 o 21-compliance.md y mae archwilydd yn gofyn amdanynt wrth eu henw. Y weithdrefn sydd ar y dudalen hon; y cofnodion a gynhyrchir ganddi yw’r dystiolaeth.

Yr allweddi

Mae pob manylyn mewngofnodi sydd wedi’i storio wedi’i selio ag allwedd amgryptio data (DEK) newydd. Caiff y DEK ei lapio gan yr allwedd feistr (y KEK), a chaiff cyfeirnod yr allwedd feistr ei storio wrth ei hymyl (key_ref, neu’r cyfeirnod y tu mewn i werth wedi’i becynnu). Mae newid yr allwedd feistr yn ail-lapio’r DEKau. Nid yw byth yn dadgryptio nac yn ail-amgryptio manylyn mewngofnodi.

Gosodiad Ystyr
QUIRE_MASTER_KEY Yr allwedd feistr gyfredol: 32 beit, base64. Caiff pob cyfrinach newydd ei lapio oddi tani
QUIRE_MASTER_KEY_VERSION Ei label fersiwn. v1 os nad yw wedi’i osod. Codwch ei werth bob tro y newidiwch yr allwedd
QUIRE_MASTER_KEY_RETIRED Allweddi cynharach y gall cyfrineiriau fod oddi tanynt o hyd, fel v1=<base64>,v0=<base64>. Darllen yn unig, byth ysgrifennu

Mae’r haen we, y worker a’r gorchymyn bun run kek:rotate yn darllen yr un tri gosodiad. Rhaid i bob un fod â’r un gwerthoedd, neu ni all un ohonynt agor yr hyn a seliwyd gan y llall.

Heb QUIRE_MASTER_KEY, mae pob is-system yn cadw’r allwedd mae’n ei deillio o QUIRE_SECRET_KEY. Mae hynny’n gweithio, mae tudalen iechyd y System yn ei dangos fel diraddedig, ac mae’n aros yn ddarllenadwy ar ôl gosod allwedd feistr, a dyna sut mae’r newid cyntaf yn symud popeth oddi tani. Gall unrhyw un sy’n gallu darllen amgylchedd y broses ddadgryptio pob manylyn mewngofnodi sydd wedi’i storio; felly dylai gosodiad cynhyrchu gael allwedd feistr, wedi’i chadw mewn storfa cyfrinachau ac nid yn yr un copi wrth gefn â’r gronfa ddata.

Newid yr allwedd

Dangosir oedran yr allwedd ar gonsol y Platfform, Diogelwch, Allwedd feistr, ac fel metrig quire.secrets.master_key.age (dyddiau). Mae amserlen ddyddiol platform.key_age (03:41 UTC) yn ysgrifennu cofnod atgoffa yng nghadwyn archwilio’r platfform pan fydd yr allwedd yn cyrraedd 365 diwrnod, ac eto bob 30 diwrnod nes ei newid. Newidiwch hi wrth weld yr atgoffa, ac unrhyw bryd y gallai allwedd fod wedi’i datgelu.

  1. Cynhyrchwch allwedd newydd: openssl rand -base64 32.
  2. Gosodwch QUIRE_MASTER_KEY iddi a QUIRE_MASTER_KEY_VERSION i’r label nesaf (v2). Symudwch yr hen allwedd i QUIRE_MASTER_KEY_RETIRED fel v1=<old base64>. Cadwch gopi o’r ddwy rywle heblaw’r host hwn.
  3. Defnyddiwch yr haen we a’r worker gyda’r gosodiadau newydd. Caiff cyfrinachau newydd eu lapio nawr o dan env:QUIRE_MASTER_KEY:v2; gellir dal agor yr hen rai â’r allwedd wedi’i harchifo.
  4. Gofynnwch am newid yr allwedd, ynghyd â’r rheswm a fydd yn y cofnod archwilio:
    • yn y consol: Diogelwch, Allwedd feistr, Newid yr allwedd feistr; neu
    • mewn plisgyn â’r un amgylchedd: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
  5. Mae’r worker yn ail-lapio cyfran bob munud (amserlen platform.key_rotation y scheduler) ac yn ailddechrau ar ôl ailgychwyn. I’w chwblhau mewn un eisteddiad: bun run kek:rotate run. Monitrwch â bun run kek:rotate status.
  6. Pan fydd y cofnod yn dangos bod y newid wedi’i gwblhau gyda dim heb eu datrys a dim methiant, tynnwch yr allwedd sydd wedi’i harchifo o QUIRE_MASTER_KEY_RETIRED ac ail-ddefnyddiwch. Tan hynny, cadwch hi: mae gwerth na allai ei symud yn dal wedi’i lapio â’r hen allwedd.

Beth mae’r swydd yn ei archwilio

Pob storfa sy’n dal DEK wedi’i lapio: y rhai yn SEALED_STORES (apps/worker/src/key-rotation.ts). Archwilir storfeydd y gronfa reoli ar y gronfa reoli; archwilir storfeydd sefydliadau un sefydliad ar y tro o dan ddiogelwch ar lefel rhes, yn y gronfa ddata sy’n dal y sefydliad. Felly caiff tenant wedi’i binio i gronfa ddata benodol ei newid yn y gronfa honno. Mae prawf yn methu pan fydd y sgema’n ennill colofn allwedd wedi’i lapio nad yw’r rhestr yn ei henwi, ac un arall pan fydd adolygiad manylion mewngofnodi’n dosbarthu colofn wedi’i selio na chynhwysir yn y rhestr.

Y cofnod

  • ops.key_rotation: un rhes fesul newid, gyda’r rheswm, pwy ofynnodd amdano, ei gyflwr a’i gyfansymiau (wedi’u haillapio, eisoes yn gyfredol, heb eu datrys, wedi methu).
  • ops.key_rotation_progress: un rhes fesul storfa a chwmpas unwaith yr archwiliwyd hwy, gyda’r cyfeirnodau allwedd na ellid eu darllen a faint o werthoedd oedd o dan bob un. Mae newid parhaus yn hepgor y rhain.
  • Cadwyn archwilio’r platfform: platform/key_rotation_request (gyda’r rheswm), un platform/key_rotation_store fesul storfa gyda’i chyfrifiadau, a platform/key_rotation_complete neu platform/key_rotation_fail; platform/key_age_reminder ar gyfer yr atgoffa.
  • Metrigau: quire.secrets.master_key.age a quire.secrets.rewrap.outstanding (gwerthoedd na allai’r newid diwethaf eu symud).

Pan na ellir datrys gwerthoedd

Mae gwerth heb ei ddatrys wedi’i lapio o dan gyfeirnod allwedd nad yw’r gosodiad hwn yn ei feddu, neu nid yw ar ffurf y mae ei golofn yn ei haddo. Mae’r cofnod cynnydd yn enwi’r cyfeirnod (er enghraifft env:QUIRE_MASTER_KEY:v0 (unreadable)). Adferwch yr allwedd honno i QUIRE_MASTER_KEY_RETIRED a rhedwch newid arall, neu, os yw’r allwedd wedi mynd am byth, gofynnwch i weinyddwr y sefydliad nodi’r manylyn mewngofnodi eto: caiff ei selio wedyn o dan yr allwedd gyfredol. Mae newidiadau a fethodd yn dangos eu gwall ar y cofnod; cywirwch yr achos a gofynnwch eto.

Allweddi llofnodi

Ar wahân i’r allwedd feistr: mae pob sefydliad yn llofnodi ei docynnau OpenID Connect a negeseuon LTI gyda’i allwedd RSA ei hun, a gyhoeddir yn /.well-known/jwks.json. Nid oes angen gweithredwr yma. Mae amserlen bob awr platform.signing_keys yn cyhoeddi allwedd olynydd saith diwrnod cyn i naw deg diwrnod yr allwedd gyfredol ddod i ben; wythnos yn ddiweddarach mae’r olynydd yn dechrau llofnodi a daw’r hen allwedd yn un sy’n ymddeol; naw deg niwrnod wedyn caiff yr hen allwedd ei dileu a’i thynnu o’r set allweddi. Mae pob cam yn gofnod platform/signing_key_advance yng nghadwyn archwilio’r platfform.

I ddisodli allwedd sefydliad yn gynnar, er enghraifft ar ôl datgelu:

  • yn y consol: Diogelwch, Allwedd feistr, Cyhoeddi allwedd lofnodi newydd (mae angen platform/keys_manage); neu
  • mewn plisgyn ag amgylchedd y worker: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". Mae bun run kek:rotate signing-keys status yn rhestru allweddi pob sefydliad fesul cam.

Cyhoeddir yr allwedd newydd ar unwaith ac mae’n dechrau llofnodi ar ôl saith diwrnod, pan fydd yr allwedd gyfredol yn ymddeol. Mae’r wythnos yn fwriadol: mae partïon dibynnol yn storio’r set allweddi mewn storfa, a byddai cyfnod gorgyffwrdd byrrach yn methu pob offeryn ar unwaith. Mae’r allwedd sy’n ymddeol yn aros yn y set allweddi am naw deg diwrnod arall fel bod dilysu tocynnau a lofnodwyd ganddi’n parhau; os yw’r datgeliad yn golygu bod yn rhaid peidio ag ymddiried ynddi ynghynt, mae dileu ei rhes yn newid a wneir â mynediad cronfa ddata’r gweithredwr ei hun o dan gofnod newid (darllen yn unig yw mynediad brys), ac yna bydd dilysu tocynnau a lofnodwyd ganddi’n methu. Mae’r newid gorfodol yn platform/signing_key_rotate yn y gadwyn archwilio, gyda’r rheswm. Mae angen yr un gosodiadau QUIRE_MASTER_KEY â’r haen we ar y worker i lapio’r allwedd newydd; mae bun run kek:rotate ar gyfer yr allwedd feistr yn ail-lapio allweddi llofnodi ynghyd â phopeth arall (oauth_signing_key yn SEALED_STORES).

Mynediad brys i gynhyrchu

Nid oes gan neb fynediad parhaol i gynhyrchu. Pan na all rhywbeth aros, mae perchennog yn rhoi caniatâd brys: consol y Platfform, Diogelwch, Mynediad brys.

  • Mae gan ganiatâd gwmpas (un sefydliad neu gofrestrfa’r platfform), rheswm o leiaf 20 nod sy’n enwi’r digwyddiad neu docyn, a ffenestr o 5 i 240 munud. Daw i ben ar ei ben ei hun: caiff ei wirio yn erbyn y cloc ar bob datganiad.
  • Gellir ei roi i’r perchennog sy’n ei roi, neu i berchennog arall (y ffurflen dau berson). Dim ond y person y’i rhoddwyd iddo all ei ddefnyddio. Mae ei roi angen platform/break_glass_issue a’i ddefnyddio angen platform/break_glass_use; dim ond perchnogion all wneud y ddau yn ddiofyn.
  • Mae datganiadau’n mynd drwy’r porth, nid mewngofnodi cronfa ddata: darllen yn unig, un ar y tro, wedi’u cyfyngu i’r sefydliad neu gofrestrfa reoli, gyda therfyn amser o bum eiliad ac uchafswm o 500 rhes. Dangosir gwerthoedd deuaidd yn ôl eu maint.
  • Mae cadwyn archwilio’r platfform yn cofnodi’r caniatâd (gyda’r rheswm), ei ddirymu, pob datganiad cyn iddo redeg (platform/break_glass_statement, y rhai a wrthodwyd gydag outcome denied) a phob canlyniad (platform/break_glass_result). Mae ops.break_glass_statement yn dal IDau’r cofnodion archwilio, felly mae cofnod y rhoi wedi’i gysylltu â’i gofnodion archwilio.
  • Ni chynigir ysgrifennu. Mae newid na all aros am ddatganiad yn defnyddio mynediad cronfa ddata’r gweithredwr ei hun o dan ei gofnod newid ei hun, y tu allan i’r cynnyrch hwn, a dylai’r cofnod ddyfynnu’r cyfeirnod digwyddiad a ddefnyddiwyd yma.

Pam na roddir manylion mewngofnodi cronfa ddata: mae mewngofnodi Postgres yn para’n hirach na’r sesiwn a ofynnodd amdano, yn osgoi’r diogelwch ar lefel rhes y mae’r rhaglen yn dibynnu arno, ac ni all ysgrifennu i gadwyn archwilio’r cynnyrch hwn; felly dim ond cyn belled ag y cludodd rhywun log gweinydd y byddai ei ddatganiadau’n cael eu harchwilio. Mae’r porth yn gwneud y llwybr archwilio’n briodwedd mynediad, yn hytrach nag arfer a osodir o’i gwmpas.

I ateb cais archwilio: rhestrwch y caniatadau yn y cyfnod (Mynediad brys), agorwch hanes caniatâd i weld ei ddatganiadau ac IDau cofnodion archwilio, a darllenwch y cofnodion hynny yng nghadwyn archwilio’r platfform (bun run audit:verify --platform yn profi bod y gadwyn yn gyfan).

Llywio

Teipiwch i chwilio…

↑↓ llywio↵ dewisEsc cau