Pagrindinio rakto ir pasirašymo rakto rotavimas bei avarinė prieiga

Kontrolės iš 21-compliance.md 14 skyriaus, apie kurias auditorius klausia pavadinimu. Šis puslapis yra procedūra; jo sukuriami įrašai yra įrodymai.

Raktai

Kiekvieni išsaugoti prisijungimo duomenys užkabinami šviežiu duomenų šifravimo raktu (DEK). DEK suvyniojamas pagrindinio rakto (KEK), o pagrindinio rakto nuoroda saugoma šalia (key_ref arba nuoroda supakuotoje reikšmėje). Pasukus pagrindinį raktą, DEK suvyniojami iš naujo. Prisijungimo duomenų niekada neiššifruojama ir iš naujo neužšifruojama.

Tinklo sluoksnis, darbininkas ir komanda bun run kek:rotate skaito tuos pačius tris nustatymus. Jie visi turi turėti vienodas reikšmes, arba vienas jų negalės atidaryti to, ką užkabinęs kitas.

Be QUIRE_MASTER_KEY kiekviena posistema išlaiko raktą, kurį išveda iš QUIRE_SECRET_KEY. Tai veikia, Sistemos sveikatos puslapyje tai rodoma kaip pablogęs, ir jis lieka skaitomas, kai nustatote pagrindinį raktą – būtent taip pirmasis rotavimas viską nuo jo perkelia. Kas gali perskaityti proceso aplinką, gali iššifruoti kiekvienus išsaugotus prisijungimo duomenis, todėl gamybinis diegimas turėtų turėti pagrindinį raktą, saugomą paslapčių saugykloje, o ne toje pačioje atsarginėje kopijoje kaip duomenų bazė.

Rotavimas

Rakto amžius rodomas platformos konsolėje, Security, Master key, ir kaip matuoklis quire.secrets.master_key.age (dienos). Kasdienė platform.key_age tvarkaraštis (03:41 UTC) įrašo priminimo eilutę į platformos audito grandinę, kai raktas pasiekia 365 dienas, ir dar kartą kas 30 dienų, kol jis nepasuotas. Rotuokite pagal priminimą ir kiekvieną kartą, kai raktas galėjo būti atskleistas.

1. Sugeneruokite naują raktą: openssl rand -base64 32.
2. Nustatykite QUIRE_MASTER_KEY į jį ir QUIRE_MASTER_KEY_VERSION į kitą žymą (v2). Seną raktą perkelkite į QUIRE_MASTER_KEY_RETIRED kaip v1=<old base64>. Abiejų kopijas laikykite kur kitur, ne šioje sistemoje.
3. Paleiskite tinklo sluoksnį ir darbininką su naujais nustatymais. Naujos paslaptys dabar suvyniojamos po env:QUIRE_MASTER_KEY:v2; senos vis tiek atidaromos atsargos raktu.
4. Paprašykite rotavimo su priežastimi, kuri liks audito pėdsake:
   • konsolėje: Security, Master key, Rotate the master key; arba
   • komandų eilutėje su ta pačia aplinka: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Darbininkas per minute suvynioja vieną riekelę (tvarkytuvo platform.key_rotation tvarkaraštis) ir po paleidimo iš naujo tęsia. Kad baigtumėte vienu prisėdimu: bun run kek:rotate run. Stebėkite su bun run kek:rotate status.
6. Kai įraše rotavimas parodomas baigtas su zero unresolved and zero failed, pašalinkite atsargos raktą iš QUIRE_MASTER_KEY_RETIRED ir paleiskite diegimą iš naujo. Iki tol jį laikykite: reikšmės, kurios nepavyko perkelti, vis tiek suvyniojamos po seno rakto.

Ką užduotis peržiūri

Kiekvieną saugyklą, laikančią suvyniotą DEK: tas, kurios yra SEALED_STORES (apps/worker/src/key-rotation.ts). Valdymo duomenų bazės saugyklos peržiūrimos valdymo duomenų bazėje; organizacijų saugyklos peržiūrimos po vieną organizaciją su eilučių lygio apsauga, toje duomenų bazėje, kurioje yra organizacija, todėl nuomininkas, pririštas prie atskiros duomenų bazės, rotuojamas toje duomenų bazėje. Testas nepavyksta, kai schemoje atsiranda suvynioto rakto stulpelio, kurio sąraše nėra, ir kitas, kai prisijungimo duomenų peržiūra priskiria užkabintą stulpelį, kurio sąrašas nepastebi.

Įrašas

• ops.key_rotation: viena eilutė rotavimui, su jo priežastimi, kas jį prašė, būsena ir jo sumomis (suvyniota iš naujo, jau teisinga, neišspręsta, nepavyko).
• ops.key_rotation_progress: viena eilutė kiekvienai saugyklai ir apimčiai kartą peržiūrėjus, su rakto nuorodomis, kurių nepavyko perskaityti, ir kiek reikšmių buvo po kiekviena. Tęsiamas rotavimas jas praleidžia.
• Platformos audito grandinė: platform/key_rotation_request (su priežastimi), po vieną platform/key_rotation_store kiekvienai saugyklai su jos skaičiais ir platform/key_rotation_complete arba platform/key_rotation_fail; platform/key_age_reminder priminimui.
• Matuokliai: quire.secrets.master_key.age ir quire.secrets.rewrap.outstanding (reikšmės, kurių paskutinis rotavimas neperkėlė).

Kai reikšmės neišspręstos

Neišspręsta reikšmė suvyniojama po rakto nuorodos, kurios šis diegimas neturi, arba ji neatitinka tos formos, kurią žada jos stulpelis. Eigos įraše įvardijama nuoroda (pavyzdžiui env:QUIRE_MASTER_KEY:v0 (unreadable)). Atkurkite tą raktą į QUIRE_MASTER_KEY_RETIRED ir paleiskite kitą rotavimą, arba, jei raktas dingo visam laikui, leiskite organizacijos administratoriui įvesti prisijungimo duomenis iš naujo: tada jie bus užkabinti po dabartinio rakto. Nepavykę rotavimai rodo savo klaidą įraše; pataisykite priežastį ir paprašykite iš naujo.

Pasirašymo raktai

Atskirai nuo pagrindinio rakto: kiekviena organizacija pasirašo savo OpenID Connect žetonus ir LTI žinutes savu RSA raktu, paskelbtu adresu /.well-known/jwks.json. Tam nereikia jokio operatoriaus. Kasdienis platform.signing_keys tvarkaraštis paskelbia įpėdinį septynias dienas prieš pasibaigiant dabartinio rakto devyniasdešimčiai, po savaitės įpėdinis pradeda pasirašyti, o senas raktas tampa atsargos, o po to devyniasdešimties dienų senas raktas ištrinamas ir palieka raktų rinkinį. Kiekvienas žingsnis yra platform/signing_key_advance įrašas platformos audito grandinėje.

Kad ankščiau pakeistumėte organizacijos raktą, pavyzdžiui, po atskleidimo:

• konsolėje: Security, Master key, Publish a new signing key (reikia platform/keys_manage); arba
• komandų eilutėje su darbininko aplinka: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status išvardija kiekvienos organizacijos raktus pagal stadiją.

Naujas raktas paskelbiamas iš karto ir pradeda pasirašyti po septynių dienų, kai dabartinis raktas atsitraukia. Savaitė yra numatyta sąmoningai: raktų rinkinį talpina pasitikinčios šalys, ir trumpesnis persidengimas iš karto sugadintų kiekvieną įrankį. Atsargos raktas lieka raktų rinkinyje dar devyniasdešimt dienų, kad jau jo pasirašyti žetonai ir toliau tikrintųsi; jei atskleidimas reiškia, kad jam reikia anksčiau nustoti būti patikimu, jo eilutės ištrynimas yra pakeitimas, atliekamas operatoriaus paties duomenų bazės prieiga pagal pakeitimų įrašą (avarinė prieiga yra tik skaitymui), ir tada juo pasirašyti žetonai nepereina patikros. Priverstinis rotavimas yra platform/signing_key_rotate audito grandinėje, su priežastimi. Darbininkui reikia tų pačių QUIRE_MASTER_KEY nustatymų, kaip tinklo sluoksniui, kad suvyniotų naują raktą; bun run kek:rotate pagrindiniam raktui suvynioja ir pasirašymo raktus su visu kitu (oauth_signing_key yra SEALED_STORES).

Avarinė gamybinė prieiga

Niekas neturi nuolatinės prieigos prie gamybos. Kai kažkas negali laukti, savininkas išduoda avarinės prieigos suteikimą: Platform console, Security, Break-glass access.

• Suteikimas turi apimtį (vieną organizaciją arba platformos registrą), priežastį nuo 20 simbolių, įvardijančią incidentą arba bilietą, ir langą nuo 5 iki 240 minučių. Jis pasibaigia pats: tikrinamas pagal laikrodį kiekvienai teiginiui.
• Jį galima išduoti tam savininkui, kuris jį išduoda, arba kitam savininkui (dvi žmonių forma). Naudotis gali tik tas žmogus, kuriam jis išduotas. Išdavimui reikia platform/break_glass_issue, o naudojimui – platform/break_glass_use; abu pagal nutylėjimą tik savininkams.
• Teiginiai vykdomi per vartų paslaugą, ne prisijungus prie duomenų bazės: tik skaitymui, po vieną, apriboti organizacijos arba valdymo registro, su penkių sekundžių laiko limitu ir daugiausia 500 eilučių. Dvinarės reikšmės rodomos pagal dydį.
• Platformos audito grandinė registruoja išdavimą (su priežastimi), atšaukimą, kiekvieną teiginį prieš jam veikiant (platform/break_glass_statement, atmesti su rezultatu denied) ir kiekvieną rezultatą (platform/break_glass_result). ops.break_glass_statement saugo audito įrašų id, todėl išdavimo įrašas susiejamas su savo audito įrašais.
• Rašymai nesiūlami. Pakeitimas, kuris negali laukti versijos, naudoja paties operatoriaus duomenų bazės prieigą su savo pakeitimų įrašu, už šio produkto ribų, ir įraše turėtų būti nurodytas incidento numeris, naudojamas čia.

Kodėl neišduodami duomenų bazės prisijungimo duomenų: Postgres prisijungimas gyvena ilgiau už seansą, kuris jo paprašė, apėina eilučių lygio apsaugą, kuria remiasi programa, ir negali įrašyti į šio produkto audito grandinę, todėl jo teiginiai būtų audituojami tik tiek, kiek kas nors būtų išsiuntęs serverio žurnalą. Vartų paslauga daro audito pėdsaką prieigos savybe, o ne praktika aplink ją.

Kad atsakytumėte į audito prašymą: išvardykite suteikimus laikotarpiu (Break-glass access), atidarykite suteikimo istoriją jo teiginiams ir audito įrašų id ir perskaitykite tuos įrašus platformos audito grandinėje (bun run audit:verify --platform įrodo, kad grandinė sveika).