Hovednøkkel- og signeringsnøkkelrotering, og nødtilgang

Kontrollene i 21-compliance.md seksjon 14 som en revisor ber om ved navn. Denne siden er prosedyren; postene den produserer er bevisene.

Nøklene

Hver lagret legitimasjon forsegles med en fersk datakrypteringsnøkkel (DEK). DEK-en pakkes inn av hovednøkkelen (KEK-en), og referansen til hovednøkkelen lagres ved siden av (key_ref, eller referansen inne i en pakket verdi). Rotering av hovednøkkelen pakker DEK-ene inn på nytt. Den dekrypterer eller rekrypterer aldri en legitimasjon.

Webnivået, arbeideren og bun run kek:rotate-kommandoen leser de samme tre innstillingene. De må alle ha de samme verdiene, ellers kan ikke en av dem åpne det en annen forseglet.

Uten QUIRE_MASTER_KEY beholder hvert delsystem nøkkelen det utleder fra QUIRE_SECRET_KEY. Det virker, Systemhelse-siden viser det som forringet, og det forblir lesbart etter at du setter en hovednøkkel, som er hvordan den første roteringen flytter alt bort fra den. Alle som kan lese prosessmiljøet kan dekryptere alle lagrede legitimasjoner, så en produksjonsinstallasjon bør ha en hovednøkkel, oppbevart i et hemmelighetslager og ikke i samme sikkerhetskopi som databasen.

Rotering

Nøkkelalderen vises på Plattformkonsoll, Sikkerhet, Hovednøkkel, og som metrikken quire.secrets.master_key.age (dager). Den daglige platform.key_age-planen (03:41 UTC) skriver en påminnelsesoppføring til plattformrevisjonskjeden når nøkkelen når 365 dager, og igjen hver 30. dag til den roteres. Roter på påminnelsen, og hver gang en nøkkel kan ha vært eksponert.

1. Generer den nye nøkkelen: openssl rand -base64 32.
2. Sett QUIRE_MASTER_KEY til den og QUIRE_MASTER_KEY_VERSION til neste merkelapp (v2). Flytt den gamle nøkkelen til QUIRE_MASTER_KEY_RETIRED som v1=<old base64>. Behold en kopi av begge et annet sted enn denne verten.
3. Rull ut webnivået og arbeideren med de nye innstillingene. Nye hemmeligheter pakkes nå inn under env:QUIRE_MASTER_KEY:v2; gamle åpnes fortsatt gjennom den pensjonerte nøkkelen.
4. Be om roteringen, med begrunnelsen som skal stå i revisjonssporet:
   • i konsollen: Sikkerhet, Hovednøkkel, Roter hovednøkkelen; eller
   • på et skall med samme miljø: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Arbeideren pakker inn en skive i minuttet (platform.key_rotation-planen til planleggeren) og fortsetter etter en omstart. For å fullføre det i én sitting: bun run kek:rotate run. Følg med på den med bun run kek:rotate status.
6. Når posten viser at roteringen er fullført med null uløste og null mislykkede, fjerner du den pensjonerte nøkkelen fra QUIRE_MASTER_KEY_RETIRED og ruller ut på nytt. Til da beholder du den: en verdi den ikke kunne flytte ligger fortsatt innpakket under den gamle nøkkelen.

Hva jobben går gjennom

Alle lagre som holder en innpakket DEK: dem i SEALED_STORES (apps/worker/src/key-rotation.ts). Kontrolldatabaselagre gås gjennom på kontrolldatabasen; organisasjonslagre gås gjennom én organisasjon om gangen under sikkerhet på radnivå, i den databasen som holder organisasjonen, slik at en tenant festet til en dedikert database roteres i den databasen. En test feiler når skjemaet får en innpakket-nøkkel-kolonne som listen ikke navngir, og en annen når legitimasjonsgjennomgangen klassifiserer en forseglet kolonne listen overser.

Posten

• ops.key_rotation: én rad per rotering, med begrunnelsen dens, hvem som ba om den, tilstanden dens og totalene dens (pakket inn på nytt, allerede gjeldende, uløste, mislykkede).
• ops.key_rotation_progress: én rad per lager og omfang når gjennomgått, med nøkkelreferansene den ikke kunne lese og hvor mange verdier som lå under hver. En gjenopptatt rotering hopper over disse.
• Plattformrevisjonskjede: platform/key_rotation_request (med begrunnelsen), én platform/key_rotation_store per lager med tellingene dens, og platform/key_rotation_complete eller platform/key_rotation_fail; platform/key_age_reminder for påminnelsen.
• Metrikker: quire.secrets.master_key.age og quire.secrets.rewrap.outstanding (verdier siste rotering ikke kunne flytte).

Når verdier er uløste

En uløst verdi er pakket inn under en nøkkelreferanse denne installasjonen ikke holder, eller er ikke i formen kolonnen dens lover. Fremdriftsposten navngir referansen (for eksempel env:QUIRE_MASTER_KEY:v0 (unreadable)). Gjenopprett den nøkkelen inn i QUIRE_MASTER_KEY_RETIRED og kjør en ny rotering, eller, hvis nøkkelen er borte for godt, la organisasjonens administrator skrive inn legitimasjonen igjen: den forsegles da under gjeldende nøkkel. Mislykkede roteringer viser feilen sin på posten; fiks årsaken og be igjen.

Signeringsnøkler

Atkilt fra hovednøkkelen: hver organisasjon signerer sine OpenID Connect-tokens og LTI-meldinger med sin egen RSA-nøkkel, publisert på /.well-known/jwks.json. Ingenting her trenger en operatør. Den timelige platform.signing_keys-planen publiserer en etterfølger syv dager før gjeldende nøkkels nitti er ute, en uke senere begynner etterfølgeren å signere og den gamle nøkkelen blir avtroppende, og nitti dager etter det slettes den gamle nøkkelen og forlater nøkkelmengden. Hvert steg er en platform/signing_key_advance-oppføring på plattformrevisjonskjeden.

For å erstatte en organisasjons nøkkel tidlig, for eksempel etter en eksponering:

• i konsollen: Sikkerhet, Hovednøkkel, Publiser en ny signeringsnøkkel (trenger platform/keys_manage); eller
• på et skall med arbeiderens 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 organisasjoners nøkler etter stadium.

Den nye nøkkelen publiseres med én gang og begynner å signere etter syv dager, når gjeldende nøkkel trer tilbake. Uken er bevisst: avhengige parter mellomlagrer nøkkelmengden, og en kortere overlapping feiler alle verktøy med én gang. Den avtroppende nøkkelen blir i nøkkelmengden i nitti dager til slik at tokens den allerede signerte fortsatt verifiseres; hvis eksponeringen betyr at den må slutte å stoles på før, er sletting av raden dens en endring gjort med operatørens egen databasetilgang under en endringspost (nødtilgang er skrivebeskyttet), og tokens signert med den feiler da verifisering. Den tvungne roteringen er platform/signing_key_rotate i revisjonskjeden, med begrunnelsen. Arbeideren trenger de samme QUIRE_MASTER_KEY-innstillingene som webnivået for å pakke inn den nye nøkkelen; bun run kek:rotate for hovednøkkelen pakker signeringsnøkler inn på nytt med alt annet (oauth_signing_key er i SEALED_STORES).

Nødtilgang til produksjon

Ingen holder stående tilgang til produksjon. Når noe ikke kan vente, utsteder en eier en nødtilgangsbevilling: Plattformkonsoll, Sikkerhet, Nødtilgang.

• En bevilling har et omfang (én organisasjon, eller plattformregisteret), en begrunnelse på minst 20 tegn som navngir hendelsen eller billetten, og et vindu på 5 til 240 minutter. Den utløper av seg selv: den sjekkes mot klokken på hver setning.
• Den kan utstedes til eieren som utsteder den, eller til en annen eier (topersonsformen). Bare personen den ble utstedt til kan bruke den. Utstedelse trenger platform/break_glass_issue og bruk trenger platform/break_glass_use; begge er kun eier som standard.
• Setninger kjøres gjennom porten, ikke på en databasepålogging: skrivebeskyttet, én om gangen, begrenset til organisasjonen eller til kontrollregisteret, med fem sekunders tidsavbrudd og høyst 500 rader. Binære verdier vises etter størrelse.
• Plattformrevisjonskjeden registrerer utstedelsen (med begrunnelsen), tilbakekallingen, hver setning før den kjøres (platform/break_glass_statement, avviste med utfall denied) og hvert resultat (platform/break_glass_result). ops.break_glass_statement holder revisjonsoppførings-ID-ene, slik at utstedelsesposten kobles til revisjonsoppføringene dens.
• Skriving tilbys ikke. En endring som ikke kan vente på en utgivelse bruker operatørens egen databasetilgang under sin egen endringspost, utenfor dette produktet, og posten bør sitere hendelsesreferansen brukt her.

Hvorfor ikke utstede databaselegitimasjon: en Postgres-pålogging overlever økten som ba om den, omgår sikkerheten på radnivå applikasjonen er avhengig av, og kan ikke skrive til dette produktets revisjonskjede, slik at setningene dens ville vært revidert bare så langt noen sendte tjenerloggen. Porten gjør revisjonssporet til en egenskap ved tilgangen snarere enn en praksis rundt den.

For å svare på en revisjonsforespørsel: list bevillingene i perioden (Nødtilgang), åpne en bevillings historikk for setningene dens og revisjonsoppførings-ID-ene, og les disse oppføringene på plattformrevisjonskjeden (bun run audit:verify --platform beviser at kjeden er intakt).