Obměna hlavního a podpisového klíče a nouzový přístup

Jde o kontroly uvedené v části 14 dokumentu 21-compliance.md, na které se auditoři ptají podle názvu. Tato stránka popisuje postup; vzniklé záznamy jsou důkazy.

Klíče

Každý uložený přihlašovací údaj se zapečetí novým klíčem pro šifrování dat (DEK). DEK obalí hlavní klíč (KEK) a vedle něj se uloží reference hlavního klíče (key_ref, případně reference uvnitř sbalené hodnoty). Při obměně hlavního klíče se DEK znovu obalí. Přihlašovací údaje se nikdy nerozšifrují ani znovu nezašifrují.

Webová vrstva, worker i příkaz bun run kek:rotate načítají stejné tři nastavení. Jejich hodnoty se musí shodovat, jinak některá služba neotevře údaje zapečetěné jinou.

Bez QUIRE_MASTER_KEY používá každý subsystém klíč odvozený z QUIRE_SECRET_KEY. Funguje to, stránka System health však stav označí jako omezený. Po nastavení hlavního klíče lze tyto údaje dál číst; první obměna je právě takto přesune pod nový klíč. Každý, kdo může číst prostředí procesu, může dešifrovat všechny uložené přihlašovací údaje. Produkční instalace by proto měla mít hlavní klíč uložený v trezoru tajných údajů, nikoli ve stejné záloze jako databáze.

Obměna

Stáří klíče se zobrazuje v konzoli Platform, v části Security, Master key, a jako metrika quire.secrets.master_key.age (dny). Denní plán platform.key_age (03:41 UTC) zapíše připomínku do auditního řetězce platformy, jakmile klíč dosáhne stáří 365 dnů; dokud ho neobměníte, upozornění se opakuje každých 30 dnů. Klíč obměňte po připomínce i kdykoli mohl být zpřístupněn neoprávněné osobě.

1. Vygenerujte nový klíč: openssl rand -base64 32.
2. Nastavte QUIRE_MASTER_KEY na nový klíč a QUIRE_MASTER_KEY_VERSION na následující označení (v2). Starý klíč přesuňte do QUIRE_MASTER_KEY_RETIRED jako v1=<old base64>. Oba klíče si uložte mimo tento hostitel.
3. Nasaďte webovou vrstvu a worker s novým nastavením. Nové tajné údaje se budou obalovat pod env:QUIRE_MASTER_KEY:v2; staré se budou dál otevírat pomocí odebraného klíče.
4. Požádejte o obměnu a uveďte důvod, který se zapíše do auditního protokolu:
   • v konzoli: Security, Master key, Rotate the master key; nebo
   • v shellu se stejným prostředím: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Worker znovu obaluje část údajů každou minutu podle plánu platform.key_rotation v scheduleru a po restartu pokračuje. Chcete-li vše dokončit najednou, spusťte bun run kek:rotate run. Průběh sledujte příkazem bun run kek:rotate status.
6. Až záznam ukáže dokončenou obměnu s nulou nevyřešených a nulou neúspěšných, odeberte starý klíč z QUIRE_MASTER_KEY_RETIRED a znovu nasaďte služby. Do té doby ho ponechte: hodnota, kterou se nepodařilo přesunout, může být stále obalená starým klíčem.

Co úloha prochází

Úloha prochází každé úložiště s obaleným DEK: ty uvedené v SEALED_STORES (apps/worker/src/key-rotation.ts). Úložiště řídicí databáze prochází v řídicí databázi; úložiště organizací prochází po jedné organizaci pod row-level security v databázi, která danou organizaci obsahuje. Tenant připnutý k vyhrazené databázi se tedy obmění právě v ní. Test selže, pokud schéma přidá sloupec s obaleným klíčem, který v seznamu není; další test selže, pokud kontrola přihlašovacích údajů označí zapečetěný sloupec, který seznam opomíjí.

Záznam

• ops.key_rotation: jeden řádek pro každou obměnu, obsahuje její důvod, žadatele, stav a součty (znovu obalené, již aktuální, nevyřešené a neúspěšné údaje).
• ops.key_rotation_progress: po průchodu jeden řádek pro každé úložiště a rozsah, včetně referencí, které nešlo přečíst, a počtu jejich hodnot. Při obnovení obměny se tyto záznamy přeskočí.
• Auditní řetězec platformy: platform/key_rotation_request (včetně důvodu), jeden platform/key_rotation_store pro každé úložiště s jeho počty a platform/key_rotation_complete nebo platform/key_rotation_fail; pro připomínku se zapisuje platform/key_age_reminder.
• Metriky: quire.secrets.master_key.age a quire.secrets.rewrap.outstanding (hodnoty, které se při poslední obměně nepodařilo přesunout).

Nevyřešené hodnoty

Hodnota je nevyřešená, pokud je obalená referencí klíče, který instalace nemá, nebo neodpovídá formátu očekávanému jejím sloupcem. Záznam průběhu uvede referenci (například env:QUIRE_MASTER_KEY:v0 (unreadable)). Obnovte klíč v QUIRE_MASTER_KEY_RETIRED a spusťte další obměnu. Pokud je klíč nenávratně ztracen, požádejte administrátora organizace, aby přihlašovací údaje zadal znovu; pak se zapečetí aktuálním klíčem. Záznam zobrazí chybu neúspěšné obměny; opravte její příčinu a požádejte znovu.

Podpisové klíče

Každá organizace používá samostatný klíč RSA pro podpis tokenů OpenID Connect a zpráv LTI. Zveřejňuje se na /.well-known/jwks.json; zde provozovatel nemusí nic dělat. Hodinový plán platform.signing_keys zveřejní nástupce sedm dní před uplynutím devadesátidenní životnosti současného klíče. O týden později začne nový klíč podepisovat a starý začne být vyřazován. Po dalších 90 dnech se starý klíč smaže ze sady. Každý krok se zaznamená v auditním řetězci platformy jako platform/signing_key_advance.

Chcete-li klíč organizace obměnit dříve, například po jeho zpřístupnění:

• v konzoli zvolte Security, Master key, Publish a new signing key (vyžaduje platform/keys_manage); nebo
• v shellu s prostředím workeru spusťte bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". Příkaz bun run kek:rotate signing-keys status uvádí klíče všech organizací podle fáze.

Nový klíč se zveřejní okamžitě a začne podepisovat za sedm dní, až dosavadní klíč přestane platit. Týdenní prodleva je záměrná: spoléhající systémy ukládají sadu klíčů do cache a kratší překryv by najednou vyřadil všechny nástroje. Vyřazovaný klíč zůstává v sadě dalších 90 dnů, aby se dál ověřovaly tokeny, které podepsal. Pokud kvůli zpřístupnění musí přestat být důvěryhodný dříve, může provozovatel pod záznamem změny smazat jeho řádek pomocí vlastního přístupu k databázi (nouzový přístup je pouze pro čtení); ověřování tokenů podepsaných tímto klíčem pak selže. Vynucená obměna se s důvodem zapíše do auditního řetězce jako platform/signing_key_rotate. Worker potřebuje stejné nastavení QUIRE_MASTER_KEY jako webová vrstva, aby nový klíč obalil; obměna hlavního klíče příkazem bun run kek:rotate znovu obalí i podpisové klíče (oauth_signing_key je v SEALED_STORES).

Nouzový přístup do produkce

Nikdo nemá trvalý přístup do produkčního prostředí. Pokud něco nesnese odkladu, vlastník vydá nouzové oprávnění: Platform console, Security, Break-glass access.

• Oprávnění má rozsah (jedna organizace nebo registr platformy), důvod o délce alespoň 20 znaků s označením incidentu či požadavku a časové okno 5 až 240 minut. Automaticky vyprší; při každém příkazu se ověřuje proti hodinám.
• Lze ho vydat žádajícímu vlastníkovi nebo jinému vlastníkovi (režim dvou osob). Použít ho může jen určená osoba. Vydání vyžaduje platform/break_glass_issue a použití platform/break_glass_use; ve výchozím nastavení jsou obě oprávnění pouze pro vlastníky.
• Příkazy se spouštějí přes bránu, nikoli přihlášením do databáze: pouze pro čtení, jeden po druhém, omezené na organizaci nebo řídicí registr, s časovým limitem pěti sekund a nejvýše 500 řádky. Binární hodnoty se zobrazují podle velikosti.
• Auditní řetězec platformy zaznamenává vydání s důvodem, odebrání, každý příkaz před jeho spuštěním (platform/break_glass_statement, odmítnuté s výsledkem denied) a každý výsledek (platform/break_glass_result). Tabulka ops.break_glass_statement uchovává ID auditních záznamů, takže se záznam o vydání propojí s příslušnými položkami auditu.
• Zápisy nejsou nabízeny. Změna, která nesnese čekání na vydání, se provádí mimo produkt vlastním přístupem provozovatele k databázi a samostatným záznamem změny. Záznam má odkazovat na zde uvedené číslo incidentu.

Proč nevydávat přihlašovací údaje k databázi: přihlášení do Postgresu přetrvá relaci, která o něj požádala, obejde row-level security, na níž závisí aplikace, a nemůže zapisovat do auditního řetězce produktu. Příkazy by se tak auditovaly pouze tehdy, pokud někdo odeslal protokol serveru. Brána činí auditní stopu vlastností přístupu, nikoli pouze jeho okolní praxí.

Při žádosti o audit vypište oprávnění vydaná v daném období (Break-glass access), otevřete historii oprávnění se seznamem příkazů a ID auditních záznamů a přečtěte tyto položky v auditním řetězci platformy. Příkaz bun run audit:verify --platform ověří, že je řetězec neporušený.