Rotation af hovednøgle og signeringsnøgle samt nødadgang

Kontrollerne i afsnit 14 i 21-compliance.md, som en revisor beder om ved navn. Denne side beskriver fremgangsmåden; de optegnelser, den producerer, er dokumentationen.

Nøglerne

Hver gemt legitimationsoplysning forsegles med en ny datakrypteringsnøgle (DEK). DEK’en indpakkes af hovednøglen (KEK), og hovednøglens reference gemmes ved siden af den (key_ref eller referencen i en pakket værdi). Rotation af hovednøglen indpakker DEK’erne igen. Den dekrypterer eller krypterer aldrig en legitimationsoplysning på ny.

Weblaget, worker og kommandoen bun run kek:rotate læser de samme tre indstillinger. De skal alle have samme værdier, ellers kan en komponent ikke åbne det, en anden har forseglet.

Uden QUIRE_MASTER_KEY bruger hvert delsystem den nøgle, det udleder af QUIRE_SECRET_KEY. Det fungerer, siden Systemstatus viser tilstanden som forringet, og data forbliver læsbare, efter du indstiller en hovednøgle. Sådan flytter den første rotation alt væk fra den afledte nøgle. Alle, der kan læse procesmiljøet, kan dekryptere alle gemte legitimationsoplysninger, så en produktionsinstallation bør have en hovednøgle, der opbevares i et hemmelighedslager og ikke i samme backup som databasen.

Rotation

Nøglens alder vises i platformskonsollen under Sikkerhed, Hovednøgle og som metrikken quire.secrets.master_key.age (dage). Den daglige tidsplan platform.key_age (03.41 UTC) skriver en påmindelse i platformens auditkæde, når nøglen er 365 dage gammel, og igen hver 30. dag, indtil den roteres. Rotér, når du får påmindelsen, og når som helst en nøgle kan være blevet eksponeret.

1. Generér den nye nøgle: openssl rand -base64 32.
2. Sæt QUIRE_MASTER_KEY til den, og sæt QUIRE_MASTER_KEY_VERSION til den næste etiket (v2). Flyt den gamle nøgle til QUIRE_MASTER_KEY_RETIRED som v1=<old base64>. Opbevar kopier af begge et andet sted end på denne vært.
3. Udrul weblaget og worker med de nye indstillinger. Nye hemmeligheder indpakkes nu med env:QUIRE_MASTER_KEY:v2; ældre hemmeligheder kan stadig åbnes med den udfasede nøgle.
4. Anmod om rotationen med den begrundelse, der skal stå i auditsporet:
   • i konsollen: Sikkerhed, Hovednøgle, Rotér hovednøglen; eller
   • i en shell med det samme miljø: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Worker indpakker en portion i minuttet (schedulerens tidsplan platform.key_rotation) og fortsætter efter genstart. Hvis du vil gøre det hele i én omgang: bun run kek:rotate run. Følg status med bun run kek:rotate status.
6. Når posten viser, at rotationen er gennemført med nul uløste og nul fejl, skal du fjerne den udfasede nøgle fra QUIRE_MASTER_KEY_RETIRED og udrulle igen. Behold den indtil da: En værdi, den ikke kunne flytte, er stadig indpakket med den gamle nøgle.

Hvad jobbet gennemgår

Alle lagre med en indpakket DEK: dem i SEALED_STORES (apps/worker/src/key-rotation.ts). Lagre i kontroldatabasen gennemgås i kontroldatabasen; organisationslagre gennemgås én organisation ad gangen under row-level security i den database, der indeholder organisationen, så en lejer, der er fastlåst til en dedikeret database, roteres dér. En test fejler, når skemaet får en indpakket nøglekolonne, som listen ikke nævner, og en anden test fejler, når gennemgangen af legitimationsoplysninger klassificerer en forseglet kolonne, som listen overser.

Optegnelsen

• ops.key_rotation: én række pr. rotation med dens begrundelse, hvem der anmodede om den, dens status og totaler (indpakket igen, allerede aktuel, uløst, mislykket).
• ops.key_rotation_progress: én række pr. lager og omfang, når det er gennemgået, med de nøglereferencer, det ikke kunne læse, og antallet af værdier under hver. En genoptaget rotation springer disse over.
• Platformens auditkæde: platform/key_rotation_request (med begrundelsen), én platform/key_rotation_store pr. lager med optællingerne og platform/key_rotation_complete eller platform/key_rotation_fail; platform/key_age_reminder for påmindelsen.
• Metrikker: quire.secrets.master_key.age og quire.secrets.rewrap.outstanding (værdier, som den seneste rotation ikke kunne flytte).

Når værdier ikke kan løses

En værdi kan ikke løses, hvis den er indpakket med en nøglerreference, denne installation ikke har, eller hvis den ikke har den form, kolonnen angiver. Statusposten angiver referencen (for eksempel env:QUIRE_MASTER_KEY:v0 (unreadable)). Gendan den nøgle i QUIRE_MASTER_KEY_RETIRED, og kør en ny rotation. Hvis nøglen er tabt for altid, skal organisationens administrator indtaste legitimationsoplysningen igen: så forsegles den med den aktuelle nøgle. Mislykkede rotationer viser fejlen på posten; ret årsagen, og anmod igen.

Signeringsnøgler

Adskilt fra hovednøglen: Hver organisation signerer sine OpenID Connect-tokens og LTI-meddelelser med sin egen RSA-nøgle, der offentliggøres på /.well-known/jwks.json. Operatøren behøver ikke foretage sig noget. Den timebaserede tidsplan platform.signing_keys offentliggør en efterfølger syv dage før den nuværende nøgle fylder halvfems dage. En uge senere begynder efterfølgeren at signere, og den gamle nøgle bliver udfaset. Halvfems dage derefter slettes den gamle nøgle og fjernes fra nøglesamlingen. Hvert trin er en platform/signing_key_advance-post i platformens auditkæde.

Hvis du vil udskifte en organisations nøgle før tid, for eksempel efter en eksponering:

• i konsollen: Sikkerhed, Hovednøgle, Udgiv en ny signeringsnøgle (kræver platform/keys_manage); eller
• i en shell med workers miljø: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status viser alle organisationers nøgler efter trin.

Den nye nøgle offentliggøres med det samme og begynder at signere efter syv dage, når den nuværende nøgle udfases. Ventetiden er bevidst: Modtagere cacher nøglesamlingen, og et kortere overlap får alle værktøjer til at fejle på samme tid. Den udfasede nøgle forbliver i nøglesamlingen i halvfems dage mere, så tokens, den allerede har signeret, fortsat kan valideres. Hvis en eksponering betyder, at den ikke længere må betros, kan rækken slettes med operatørens egen databaseadgang under en ændringspost (nødadgang giver kun læseadgang), hvorefter tokens signeret med den fejler validering. Den tvungne rotation registreres som platform/signing_key_rotate i auditkæden med begrundelsen. Worker skal bruge de samme QUIRE_MASTER_KEY-indstillinger som weblaget for at indpakke den nye nøgle; bun run kek:rotate til hovednøglen indpakker signeringsnøgler igen sammen med alt andet (oauth_signing_key findes i SEALED_STORES).

Nødadgang til produktion

Ingen har permanent adgang til produktion. Når noget ikke kan vente, udsteder en ejer en nødadgangstilladelse: Platformskonsol, Sikkerhed, Nødadgang.

• Tilladelsen gælder et omfang (én organisation eller platformregistret), har en begrundelse på mindst 20 tegn, der angiver hændelsen eller sagsnummeret, og et tidsrum på 5 til 240 minutter. Den udløber automatisk: Den kontrolleres mod uret ved hver sætning.
• Den kan udstedes til ejeren, der udsteder den, eller til en anden ejer (to-personers godkendelse). Kun den person, tilladelsen er udstedt til, kan bruge den. Udstedelse kræver platform/break_glass_issue, og brug kræver platform/break_glass_use; begge er som standard kun for ejere.
• Sætninger udføres gennem gatewayen, ikke med et database-login: skrivebeskyttet, én ad gangen, begrænset til organisationen eller kontrolregistret, med en timeout på fem sekunder og højst 500 rækker. Binære værdier vises med deres størrelse.
• Platformens auditkæde registrerer udstedelsen (med begrundelsen), tilbagekaldelsen, hver sætning før den køres (platform/break_glass_statement; afviste sætninger får resultatet denied) og hvert resultat (platform/break_glass_result). ops.break_glass_statement indeholder id’erne for auditposterne, så udstedelsesposten kan sammenkobles med dens auditposter.
• Skrivning tilbydes ikke. En ændring, der ikke kan vente på en udgivelse, foretages med operatørens egen databaseadgang under sin egen ændringspost uden for dette produkt, og posten bør henvise til det hændelsesnummer, der bruges her.

Hvorfor ikke udstede databaselegitimationsoplysninger? Et Postgres-login varer længere end den session, der bad om det, omgår den row-level security, applikationen er afhængig af, og kan ikke skrive til produktets auditkæde. Derfor ville sætninger kun blive auditeret, så langt som nogen havde sendt serverloggen. Gatewayen gør auditsporet til en egenskab ved adgangen i stedet for en praksis omkring den.

Hvis du skal besvare en revisionsanmodning: Find tilladelserne fra perioden under Nødadgang, åbn en tilladelses historik for at se dens sætninger og auditpost-id’er, og læs disse poster i platformens auditkæde (bun run audit:verify --platform beviser, at kæden er intakt).