Hoofsleutel- en ondertekeningsleutelrotasie, en noodtoegang

Die kontroles waarna ’n ouditeur by naam vra, staan in afdeling 14 van die nakomingsgids. Hierdie bladsy beskryf die prosedure; die rekords wat dit lewer, is die bewyse.

Die sleutels

Elke gestoorde aanmeldbewys word met ’n vars data-enkripsiesleutel (DEK) verseël. Die DEK word deur die hoofsleutel (KEK) toegedraai, en die verwysing na die hoofsleutel word daarby gestoor (key_ref, of die verwysing binne ’n saamgepakde waarde). Rotasie van die hoofsleutel draai die DEK’s weer toe. Dit ontsyfer of her-enkripteer nooit ’n aanmeldbewys nie.

Instelling	Betekenis
`QUIRE_MASTER_KEY`	Die huidige hoofsleutel: 32 grepe, base64. Elke nuwe geheim word daarmee toegedraai
`QUIRE_MASTER_KEY_VERSION`	Sy weergawemerker. `v1` as dit ongestel is. Verhoog dit wanneer jy die sleutel verander
`QUIRE_MASTER_KEY_RETIRED`	Vorige sleutels waaronder geheime nog kan wees, as `v1=<base64>,v0=<base64>`. Slegs leesbaar, nooit geskryf nie

Die webvlak, werker en bun run kek:rotate-opdrag lees dieselfde drie instellings. Hulle moet dieselfde waardes hê, anders kan een nie oopmaak wat ’n ander verseël het nie.

Sonder QUIRE_MASTER_KEY behou elke substelsel die sleutel wat dit uit QUIRE_SECRET_KEY aflei. Dit werk; die Stelselgesondheid-bladsy wys dit as verswak, en dit bly leesbaar nadat jy ’n hoofsleutel gestel het. Só skuif die eerste rotasie alles daarvan af. Enigiemand wat die prosesomgewing kan lees, kan elke gestoorde aanmeldbewys ontsyfer, daarom behoort ’n produksie-installasie ’n hoofsleutel te hê, in ’n geheimewinkel gehou en nie in dieselfde rugsteun as die databasis nie.

Roteer

Die sleutelleeftyd verskyn op Platformkonsole, Sekuriteit, Hoofsleutel, en as maatstaf quire.secrets.master_key.age (dae). Die daaglikse platform.key_age-skedule (03:41 UTC) skryf ’n herinneringinskrywing in die platformouditketting wanneer die sleutel 365 dae oud is, en weer elke 30 dae totdat dit geroteer is. Roteer met die herinnering, en wanneer ’n sleutel moontlik blootgestel is.

Genereer die nuwe sleutel: openssl rand -base64 32.
Stel QUIRE_MASTER_KEY daarop en QUIRE_MASTER_KEY_VERSION op die volgende merker (v2). Skuif die ou sleutel na QUIRE_MASTER_KEY_RETIRED as v1=<old base64>. Hou ’n kopie van albei elders as op hierdie gasheer.
Ontplooi die webvlak en werker met die nuwe instellings. Nuwe geheime word nou toegedraai onder env:QUIRE_MASTER_KEY:v2; oues kan steeds met die afgetrede sleutel oopgemaak word.
Versoek die rotasie met die rede wat in die ouditspoor moet verskyn:
- in die konsole: Sekuriteit, Hoofsleutel, Roteer hoofsleutel; of
- in ’n dop met dieselfde omgewing: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
Die werker draai elke minuut ’n gedeelte weer toe (die skeduleerder se platform.key_rotation-skedule) en hervat ná herbegin. Om dit in een sitting te voltooi: bun run kek:rotate run. Volg dit met bun run kek:rotate status.
Wanneer die rekord wys dat rotasie voltooi is met nul onopgeloste en nul mislukte, verwyder die afgetrede sleutel uit QUIRE_MASTER_KEY_RETIRED en ontplooi weer. Hou dit tot dan: ’n waarde wat dit nie kon verskuif nie, is steeds onder die ou sleutel toegedraai.

Waaroor die taak loop

Elke winkel wat ’n toegedraaide DEK bevat: dié in SEALED_STORES (apps/worker/src/key-rotation.ts). Beheerdatabasiswinkels word op die beheerdatabasis deurgegaan; organisasiewinkels word een organisasie op ’n slag deurgegaan onder ryvlak-sekuriteit, in watter databasis die organisasie ook al is. ’n Tenant wat aan ’n toegewyde databasis gepen is, word dus daarin geroteer. Een toets misluk wanneer ’n skema ’n kolom met ’n toegedraaide sleutel bykry wat die lys nie benoem nie, en nog een wanneer die geloofsbriefoorsig ’n verseëlde kolom klassifiseer wat die lys mis.

Die rekord

ops.key_rotation: een ry per rotasie, met rede, aanvraer, toestand en totale (weer toegedraai, reeds huidig, onopgelos, misluk).
ops.key_rotation_progress: een ry per winkel en omvang sodra dit deurgegaan is, met die sleutelverwysings wat dit nie kon lees nie en hoeveel waardes onder elkeen was. ’n Hervatte rotasie slaan hierdie oor.
Platformouditketting: platform/key_rotation_request (met rede), een platform/key_rotation_store per winkel met sy tellings en platform/key_rotation_complete of platform/key_rotation_fail; platform/key_age_reminder vir die herinnering.
Maatstawwe: quire.secrets.master_key.age en quire.secrets.rewrap.outstanding (waardes wat die laaste rotasie nie kon verskuif nie).

Wanneer waardes onopgelos is

’n Onopgeloste waarde is onder ’n sleutelverwysing toegedraai wat hierdie installasie nie het nie, of het nie die vorm wat sy kolom beloof nie. Die vorderingsrekord benoem die verwysing (byvoorbeeld env:QUIRE_MASTER_KEY:v0 (unreadable)). Herstel daardie sleutel in QUIRE_MASTER_KEY_RETIRED en voer nog ’n rotasie uit, of laat die organisasie se administrateur, as die sleutel vir altyd weg is, die aanmeldbewys weer invoer; dit word dan onder die huidige sleutel verseël. Mislukte rotasies wys hul fout op die rekord; herstel die oorsaak en versoek weer.

Ondertekeningsleutels

Apart van die hoofsleutel: elke organisasie onderteken sy OpenID Connect-tekens en LTI-boodskappe met sy eie RSA-sleutel, gepubliseer by /.well-known/jwks.json. ’n Operateur hoef hier niks te doen nie. Die uurlikse platform.signing_keys-skedule publiseer ’n opvolger sewe dae voordat die huidige sleutel 90 dae oud is; ’n week later begin die opvolger onderteken en tree die oue af; 90 dae daarna word die ou sleutel geskrap en uit die stel verwyder. Elke stap is ’n platform/signing_key_advance-inskrywing in die platformouditketting.

Om ’n organisasie se sleutel vroeg te vervang, byvoorbeeld ná blootstelling:

in die konsole: Sekuriteit, Hoofsleutel, Publiseer ’n nuwe ondertekeningsleutel (vereis platform/keys_manage); of
in ’n dop met die werker se omgewing: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status lys elke organisasie se sleutels volgens stadium.

Die nuwe sleutel word dadelik gepubliseer en begin ná sewe dae onderteken wanneer die huidige sleutel aftree. Die week is doelbewus: vertrouende partye kas die sleutelstel, en ’n korter oorvleueling laat elke nutsding gelyktydig misluk. Die afgetrede sleutel bly nog 90 dae in die sleutelstel sodat reeds ondertekende tekens bly verifieer; as blootstelling beteken dit moet vroeër ophou vertrou word, is skrapping van sy ry ’n verandering met die operateur se eie databasistoegang onder ’n veranderingsrekord (noodtoegang is leesalleen), en tekens wat daarmee onderteken is, misluk dan met verifikasie. Die gedwonge rotasie is platform/signing_key_rotate in die ouditketting, met die rede. Die werker benodig dieselfde QUIRE_MASTER_KEY-instellings as die webvlak om die nuwe sleutel toe te draai; bun run kek:rotate vir die hoofsleutel draai ondertekeningsleutels saam met alles anders weer toe (oauth_signing_key is in SEALED_STORES).

Noodtoegang tot produksie

Niemand het deurlopende toegang tot produksie nie. Wanneer iets nie kan wag nie, reik ’n eienaar ’n noodtoelating uit: Platformkonsole, Sekuriteit, Noodtoegang.

’n Toelating het ’n omvang (een organisasie of die platformregister), ’n rede van minstens 20 karakters wat die voorval of kaartjie benoem, en ’n tydvenster van 5 tot 240 minute. Dit verval vanself: dit word teen die horlosie by elke stelling nagegaan.
Dit kan uitgereik word aan die eienaar wat dit uitreik, of aan ’n ander eienaar (tweepersoonvorm). Net die aangewese persoon kan dit gebruik. Uitreiking vereis platform/break_glass_issue en gebruik vereis platform/break_glass_use; albei is by verstek net vir eienaars.
Stellings loop deur die poort, nie met ’n databasisaantekening nie: leesalleen, een op ’n slag, beperk tot die organisasie of beheerdersregister, met ’n tydsbeperking van vyf sekondes en hoogstens 500 rye. Binêre waardes word volgens grootte vertoon.
Die platformouditketting teken uitreiking aan (met rede), herroeping, elke stelling voor dit loop (platform/break_glass_statement, geweierdes met uitkoms denied) en elke resultaat (platform/break_glass_result). ops.break_glass_statement bevat die ouditinskrywing-ID’s, sodat die uitreikingsrekord met hulle skakel.
Skrywings word nie aangebied nie. ’n Verandering wat nie vir ’n vrystelling kan wag nie, gebruik die operateur se eie databasistoegang onder ’n eie veranderingsrekord, buite hierdie produk; die rekord behoort die voorvalverwysing hier te noem.

Waarom nie databasistoegang uitreik nie? ’n Postgres-aanmelding leef langer as die sessie wat dit gevra het, omseil die ryvlak-sekuriteit waarop die toepassing staatmaak en kan nie na hierdie produk se ouditketting skryf nie; sy stellings sou dus net so ver geoudit word as wat iemand die bedienerlog verskeep. Die poort maak die ouditspoor ’n eienskap van toegang self, eerder as ’n praktyk daaromheen.

Om ’n ouditversoek te beantwoord: lys die toelatings in die tydperk (Noodtoegang), maak die geskiedenis van ’n toelating oop vir sy stellings en ouditinskrywing-ID’s, en lees daardie inskrywings in die platformouditketting (bun run audit:verify --platform bewys dat die ketting heel is).