---
title: "Master és aláírókulcsok cseréje, vészhelyzeti hozzáférés"
description: "A tárolt hitelesítő adatokat védő master kulcs cseréje és vészhelyzeti hozzáférés használata."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/hu/llms.txt
> Use this file to discover all available pages before exploring further.

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

<span id="master-key-and-signing-key-rotation-and-break-glass-access"></span>

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 <!--quire:the-keys-->

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.

| Beállítás | Jelentés |
| --- | --- |
| `QUIRE_MASTER_KEY` | Aktuális master kulcs: 32 bájt, base64. Minden új titok ezzel kerül becsomagolásra |
| `QUIRE_MASTER_KEY_VERSION` | Verziócímke; beállítás nélkül `v1`. A kulcscserekor növelje |
| `QUIRE_MASTER_KEY_RETIRED` | Régebbi kulcsok, amelyekkel még lehetnek titkok csomagolva, például `v1=<base64>,v0=<base64>`. Olvasásra használjuk, írásra nem |

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 <!--quire:rotating-->

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 <!--quire:what-the-job-walks-->

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 <!--quire:the-record-->

- `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 <!--quire:when-values-are-unresolved-->

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 <!--quire:signing-keys-->

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 <!--quire:break-glass-production-access-->

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.

Source: https://docs.quirelms.com/hu/ops/key-rotation/index.mdx