Master és aláírókulcsok cseréje, vészhelyzeti hozzáférés

A 21-compliance.md 14. szakaszában leírt vezérlők, amelyeket az auditor név szerint kér. Ez az eljárás; az általa létrehozott rekordok szolgálnak bizonyítékként.

A kulcsok

Minden tárolt hitelesítő adatot új adattitkosítási kulccsal (DEK) titkosítunk. A DEK-et a master kulcs (KEK) csomagolja be, a master kulcs hivatkozását pedig mellette tároljuk (key_ref, vagy a csomagolt értékben található hivatkozás). A master kulcs cseréje újracsomagolja a DEK-eket. Magát a hitelesítő adatot soha nem fejti vissza vagy titkosítja újra.

A webes réteg, a worker és a bun run kek:rotate parancs ugyanazt a három beállítást olvassa. Az értékeknek mindenhol egyezniük kell, különben az egyik nem tudja felnyitni azt, amit a másik csomagolt be.

QUIRE_MASTER_KEY nélkül minden alrendszer a QUIRE_SECRET_KEY alapján származtatott kulcsot használja. Ez működik, a System health oldal romlott állapotot jelez, és a master kulcs beállítása után is olvasható marad; az első kulcscsere így helyezi át róla az összes adatot. A folyamatkörnyezetet olvasni képes bárki visszafejtheti az összes tárolt hitelesítő adatot, ezért éles telepítésben titoktárolóban tartott master kulcsra van szükség, nem az adatbázissal azonos mentésben.

Kulcscsere

A kulcs életkora a Platform konzol Security, Master key részében és a quire.secrets.master_key.age mérőszámban (nap) látható. A napi platform.key_age ütemezés (03:41 UTC) bejegyzést ír a platform auditláncába, amikor a kulcs eléri a 365 napot, majd 30 naponta ismétel, amíg le nem cserélik. Cseréljen a figyelmeztetéskor, illetve bármikor, ha a kulcs esetleg illetéktelenhez kerülhetett.

1. Hozza létre az új kulcsot: openssl rand -base64 32.
2. Állítsa a QUIRE_MASTER_KEY értékét az új kulcsra, a QUIRE_MASTER_KEY_VERSION értékét pedig a következő címkére (v2). A régi kulcsot tegye a QUIRE_MASTER_KEY_RETIRED értékébe v1=<old base64> formában. Mindkettőről őrizzen meg másolatot ezen a hoston kívül.
3. Telepítse a webes réteget és a workert az új beállításokkal. Az új titkokat mostantól az env:QUIRE_MASTER_KEY:v2 alatt csomagolja be; a régiek továbbra is a visszavont kulccsal nyithatók meg.
4. Kérje a cserét, az auditnyomvonalban szereplő indokkal:
   • a konzolon: Security, Master key, Rotate the master key; vagy
   • azonos környezetű parancssorban: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. A worker percenként egy adagrészt csomagol újra a scheduler platform.key_rotation ütemezése szerint, és újraindítás után folytatja. Egyetlen menetben a bun run kek:rotate run paranccsal fejezheti be. A bun run kek:rotate status paranccsal figyelheti.
6. Amikor a rekord szerint a csere zero unresolved és zero failed állapotban befejeződött, távolítsa el a visszavont kulcsot a QUIRE_MASTER_KEY_RETIRED értékéből, majd telepítsen újra. Addig őrizze meg, mert ami nem volt áthelyezhető, továbbra is azzal van csomagolva.

Mit jár be a feladat

Minden becsomagolt DEK-et tároló adattárat: a SEALED_STORES elemeit (apps/worker/src/key-rotation.ts). A vezérlőadatbázis adattárait azon belül járja be; a szervezeti adattárakat szervezetenként, row-level security mellett, abban az adatbázisban, amelyben a szervezet van, így a dedikált adatbázishoz rögzített tenant kulcsa is ott cserélődik le. Egy teszt hibát jelez, ha a sémába olyan becsomagolt kulcsoszlop kerül, amely nincs a listán; egy másik pedig akkor, ha a hitelesítőadat-felülvizsgálat olyan titkosított oszlopot talál, amely kimaradt.

A rekord

• ops.key_rotation: sor cserénként, az indokkal, a kérelmezővel, az állapottal és az összesítésekkel (újracsomagolva, már aktuális, megoldatlan, sikertelen).
• ops.key_rotation_progress: sor minden bejárt adattárhoz és hatókörhöz; tartalmazza a nem olvasható kulcshivatkozásokat és az alattuk lévő értékek számát. Folytatáskor ezeket kihagyja.
• Platform auditlánc: platform/key_rotation_request (indokkal), adattáranként egy platform/key_rotation_store a számlálókkal, majd platform/key_rotation_complete vagy platform/key_rotation_fail; emlékeztetőként platform/key_age_reminder.
• Mérőszámok: quire.secrets.master_key.age és quire.secrets.rewrap.outstanding (az előző cserével át nem helyezhető értékek).

Megoldatlan értékek

Megoldatlan az az érték, amelyet olyan kulcshivatkozással csomagoltak be, amelyet ez a telepítés nem ismer, vagy amely nem felel meg az oszlop által ígért formának. A folyamatrekord megnevezi a hivatkozást, például env:QUIRE_MASTER_KEY:v0 (unreadable). Állítsa vissza a kulcsot a QUIRE_MASTER_KEY_RETIRED értékébe, és indítson új cserét; ha végleg elveszett, kérje meg a szervezet rendszergazdáját a hitelesítő adat újbóli megadására, amelyet már az aktuális kulccsal titkosítunk. A sikertelen cserék hibája megjelenik a rekordban; javítsa ki az okát, majd kérje újra.

Aláírókulcsok

A master kulcstól külön, minden szervezet a saját RSA-kulcsával írja alá az OpenID Connect tokeneket és LTI-üzeneteket; a kulcs itt jelenik meg: /.well-known/jwks.json. Itt az üzemeltetőnek nincs teendője. Az óránkénti platform.signing_keys ütemezés hét nappal a jelenlegi kulcs kilencven napjának lejárta előtt közzéteszi az utódját; egy héttel később az utód kezd aláírni, a régi visszavont állapotú lesz; további kilencven nap után töröljük a régit a kulcskészletből. Minden lépés platform/signing_key_advance bejegyzésként kerül a platform auditláncába.

Korai kulcscseréhez, például kiszivárgás után:

• a konzolon: Security, Master key, Publish a new signing key (szükséges a platform/keys_manage); vagy
• a worker környezetét használó parancssorban: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". A bun run kek:rotate signing-keys status felsorolja a szervezetek kulcsait szakasz szerint.

Az új kulcsot azonnal közzétesszük, és hét nap után kezd aláírni, amikor a jelenlegi visszavonul. A várakozás szándékos: a függő rendszerek gyorsítótárazzák a kulcskészletet; rövidebb átfedés minden eszközt egyszerre hibáztatna. A visszavont kulcs még kilencven napig a készletben marad, így az általa már aláírt tokenek továbbra is ellenőrizhetők. Ha a kiszivárgás miatt hamarabb meg kell szüntetni a bizalmat, a sor törlése az üzemeltető saját adatbázis-hozzáférésével, változásrekord alapján végzett módosítás (a vészhelyzeti hozzáférés csak olvasásra jogosít); az ezzel a kulccsal aláírt tokenek ezután hibásak lesznek. A kényszerített csere platform/signing_key_rotate bejegyzésként kerül az auditláncba az indokkal együtt. Az új kulcs becsomagolásához a workernek ugyanazok a QUIRE_MASTER_KEY beállítások kellenek, mint a webes rétegnek; a master kulcshoz használt bun run kek:rotate az aláírókulcsokat is újracsomagolja (oauth_signing_key a SEALED_STORES része).

Vészhelyzeti éles hozzáférés

Senki nem rendelkezik állandó éles hozzáféréssel. Ha valami nem várhat, egy tulajdonos vészhelyzeti hozzáférést ad ki: Platform konzol, Security, Break-glass access.

• A jogosultság hatóköre egy szervezet vagy a platform regisztere lehet; legalább 20 karakteres indokot kell megadni, amely az incidenst vagy jegyet nevezi meg, valamint 5–240 perces időablakot. Magától lejár: minden utasítás előtt ellenőrizzük az időt.
• Kiadható a kiállító tulajdonosnak vagy egy másik tulajdonosnak (két személyes jóváhagyás). Csak a címzett használhatja. A kiadáshoz platform/break_glass_issue, használatához platform/break_glass_use szükséges; alapértelmezés szerint mindkettő csak tulajdonosoké.
• Az utasítások az átjárón futnak, nem adatbázis-bejelentkezéssel: csak olvasás, egyesével, a szervezetre vagy vezérlőregiszterre korlátozva, öt másodperces időkorláttal és legfeljebb 500 sorral. A bináris értékeket méretük jelzi.
• A platform auditlánca rögzíti a kiadást (indokkal), visszavonást, minden utasítást végrehajtás előtt (platform/break_glass_statement, az elutasítottakat denied eredménnyel), valamint minden eredményt (platform/break_glass_result). Az ops.break_glass_statement az auditbejegyzés-azonosítókat tárolja, így a kiadási rekord összekapcsolható velük.
• Írási művelet nem érhető el. A kiadásig nem várható változtatást az üzemeltető saját adatbázis-hozzáférésével, saját változásrekord alatt, a terméken kívül kell végrehajtani; a rekordban szerepeljen az itt hivatkozott incidensazonosító.

Miért nem adunk adatbázis-hitelesítő adatot: a Postgres-bejelentkezés a kérő munkamenet után is érvényes marad, megkerüli az alkalmazás row-level security védelmét, és nem írhat a termék auditláncába, így az utasítások legfeljebb akkor kapnak naplózást, ha valaki elküldte a szervernaplót. Az átjáró magát a hozzáférést teszi auditálhatóvá, nem csak egy körülötte kialakított gyakorlatot.

Auditkérés megválaszolásához listázza az adott időszak jogosultságait (Break-glass access), nyissa meg az egyik előzményeit az utasítások és auditazonosítók megtekintéséhez, majd olvassa el ezeket a platform auditláncában. A bun run audit:verify --platform bizonyítja a lánc épségét.