---
title: "Rotasi kunci master lan kunci signing, lan akses break-glass"
description: "Muter kunci master sing nglindhungi kredensial sing disimpen, lan nggunakake akses break-glass."
image: "https://docs.quirelms.com/og.png"
---

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

# Rotasi kunci master lan kunci signing, lan akses break-glass

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

Kontrol ing 21-compliance.md bagean 14 sing dijaluk auditor kanthi jeneng. Kaca iki prosedure; cathetan sing diprodhuksi iku buktine.

## Kunci <!--quire:the-keys-->

Saben kredensial sing disimpen disegel nganggo kunci enkripsi data anyar (DEK). DEK dibungkus dening kunci master (KEK), lan referensi kunci master disimpen ing sandhinge (`key_ref`, utawa referensi ing njero nilai packed). Muter kunci master mbungkus maneh DEK. Ora tau dekripsi utawa enkripsi maneh kredensial.

| Setelan | Tegese |
| --- | --- |
| `QUIRE_MASTER_KEY` | Kunci master saiki: 32 byte, base64. Saben rahasia anyar dibungkus ing ngisore |
| `QUIRE_MASTER_KEY_VERSION` | Label versine. `v1` nalika ora disetel. Naikke saben ngganti kunci |
| `QUIRE_MASTER_KEY_RETIRED` | Kunci sadurunge sing isih bisa digunakake rahasia sing disimpen, minangka `v1=<base64>,v0=<base64>`. Diwaca, ora tau ditulis |

Tier web, worker lan prentah `bun run kek:rotate` maca telung setelan sing padha. Kabeh kudu duwe nilai sing padha, utawa salah siji ora bisa mbukak apa sing disegel liyane.

Tanpa `QUIRE_MASTER_KEY` saben subsistem njaga kunci sing diturunake saka `QUIRE_SECRET_KEY`. Iku bisa, kaca kesehatan Sistem nuduhake minangka degraded, lan tetep bisa diwaca sawise nyetel kunci master, sing carane rotasi kapisan mindhah kabeh saka iku. Sapa wae sing bisa maca lingkungan proses bisa dekripsi saben kredensial sing disimpen, dadi instalasi produksi kudune duwe kunci master, disimpen ing toko rahasia lan dudu ing serep sing padha karo database.

## Muter <!--quire:rotating-->

Umur kunci katon ing konsol Platform, Security, Master key, lan minangka metrik `quire.secrets.master_key.age` (dina). Jadwal saben dina `platform.key_age` (03:41 UTC) nulis entri pangeling menyang rante audit platform nalika kunci tekan 365 dina, lan maneh saben 30 dina nganti diputer. Puter ing pangeling, lan saben kunci bisa wis kebukak.

1. Gawe kunci anyar: `openssl rand -base64 32`.
2. Setel `QUIRE_MASTER_KEY` menyang iku lan `QUIRE_MASTER_KEY_VERSION` menyang label sabanjure (`v2`). Pindah kunci lawas menyang `QUIRE_MASTER_KEY_RETIRED` minangka `v1=<old base64>`. Simpen salinan kalorone ing papan liya saka host iki.
3. Deploy tier web lan worker kanthi setelan anyar. Rahasia anyar saiki dibungkus ing sangisore `env:QUIRE_MASTER_KEY:v2`; sing lawas isih mbukak liwat kunci sing dipensiunake.
4. Njaluk rotasi, kanthi alesan sing bakal ana ing jejak audit:
   - ing konsol: Security, Master key, Rotate the master key; utawa
   - ing shell kanthi lingkungan sing padha: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker mbungkus maneh irisan semenit (jadwal `platform.key_rotation` scheduler) lan nerusake sawise restart. Kanggo ngrampungake ing siji lungguh: `bun run kek:rotate run`. Awasi nganggo `bun run kek:rotate status`.
6. Nalika cathetan nuduhake rotasi rampung kanthi **nol ora dirampungake lan nol gagal**, copot kunci sing dipensiunake saka `QUIRE_MASTER_KEY_RETIRED` lan deploy maneh. Nganti iku njaga: nilai sing ora bisa dipindahake isih dibungkus ing sangisore kunci lawas.

### Apa sing dilangkahi pagawean <!--quire:what-the-job-walks-->

Saben toko sing nyekel DEK sing dibungkus: sing ana ing `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Toko database kontrol dilangkahi ing database kontrol; toko organisasi dilangkahi siji organisasi ing wektu ing sangisore keamanan tingkat baris, ing database apa wae sing nyekel organisasi, supaya tenant sing disematake menyang database khusus diputer ing database kasebut. Tes gagal nalika skema entuk kolom kunci-bungkusan sing ora dijenengi dhaptar, lan liyane nalika review kredensial nggolongake kolom sing disegel sing ora kalebu dhaptar.

### Cathetan <!--quire:the-record-->

- `ops.key_rotation`: siji baris per rotasi, kanthi alesan, sapa sing njaluk, statuse lan totale (dibungkus maneh, wis saiki, ora dirampungake, gagal).
- `ops.key_rotation_progress`: siji baris per toko lan scope yen wis dilangkahi, kanthi referensi kunci sing ora bisa diwaca lan pirang nilai ana ing sangisore saben. Rotasi sing diterusake ngliwati iki.
- Rante audit platform: `platform/key_rotation_request` (kanthi alesan), siji `platform/key_rotation_store` per toko kanthi cacahane, lan `platform/key_rotation_complete` utawa `platform/key_rotation_fail`; `platform/key_age_reminder` kanggo pangeling.
- Metrik: `quire.secrets.master_key.age` lan `quire.secrets.rewrap.outstanding` (nilai sing ora bisa dipindahake rotasi pungkasan).

### Nalika nilai ora dirampungake <!--quire:when-values-are-unresolved-->

Nilai sing ora dirampungake dibungkus ing sangisore referensi kunci sing ora dicekel instalasi iki, utawa ora ing wujud sing dijanjikake kolome. Cathetan kemajuan nyebutake referensi (contone `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Balekake kunci kasebut menyang `QUIRE_MASTER_KEY_RETIRED` lan mbukak rotasi liyane, utawa, yen kunce ilang selawase, njaluk administrator organisasi ngetik kredensial maneh: banjur disegel ing sangisore kunci saiki. Rotasi gagal nuduhake kaluputane ing cathetan; ndandani sababe lan njaluk maneh.

## Kunci signing <!--quire:signing-keys-->

Kapisah saka kunci master: saben organisasi nandatangani tokene OpenID Connect lan pesen LTI nganggo kunci RSA dhewe, diterbitake ing `/.well-known/jwks.json`. Ora ana ing kene sing butuh operator. Jadwal saben jam `platform.signing_keys` nerbitake penerus pitung dina sadurunge sangang puluh dina kunci saiki entek, seminggu mengko penerus miwiti nandatangani lan kunci lawas dadi pensiun, lan sangang puluh dina sawise iku kunci lawas dibusak lan metu saka set kunci. Saben langkah iku entri `platform/signing_key_advance` ing rante audit platform.

Kanggo ngganti kunci organisasi luwih awal, contone sawise kebukak:

- ing konsol: Security, Master key, Publish a new signing key (butuh `platform/keys_manage`); utawa
- ing shell kanthi lingkungan worker: `bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310"`. `bun run kek:rotate signing-keys status` ndhaftar kunci saben organisasi miturut tahap.

Kunci anyar diterbitake langsung lan miwiti nandatangani sawise pitung dina, nalika kunci saiki pensiun. Seminggu disengaja: pihak sing ngandelake nyimpen set kunci, lan tumpang tindih luwih cendhak nggagalake saben piranti bebarengan. Kunci pensiun tetep ing set kunci sangang puluh dina maneh supaya token sing wis ditandatangani tetep verifikasi; yen kebukak tegese kudu mandheg dipercaya luwih awal, mbusak barise iku owahan sing digawe nganggo akses database operator dhewe ing sangisore cathetan owahan (akses break-glass mung waca), lan token sing ditandatangani karo iku banjur gagal verifikasi. Rotasi peksa iku `platform/signing_key_rotate` ing rante audit, kanthi alesan. Worker butuh setelan `QUIRE_MASTER_KEY` sing padha karo tier web kanggo mbungkus kunci anyar; `bun run kek:rotate` kanggo kunci master mbungkus maneh kunci signing karo kabeh liyane (`oauth_signing_key` ana ing `SEALED_STORES`).

## Akses produksi break-glass <!--quire:break-glass-production-access-->

Ora ana sing nyekel akses tetap menyang produksi. Nalika ana sing ora bisa ngenteni, owner ngetokake hibah break-glass: konsol Platform, Security, Break-glass access.

- Hibah duwe scope (siji organisasi, utawa registri platform), alesan paling ora 20 karakter sing nyebutake insiden utawa tiket, lan jendhela 5 nganti 240 menit. Kadaluwarsa dhewe: dipriksa nglawan jam ing saben statement.
- Bisa ditokake menyang owner sing ngetokake, utawa menyang owner liya (formulir wong loro). Mung wong sing ditokake sing bisa nggunakake. Ngetokake butuh `platform/break_glass_issue` lan nggunakake butuh `platform/break_glass_use`; kalorone mung owner kanthi gawan.
- Statement mlaku liwat gateway, dudu ing login database: mung waca, siji-siji, diwatesi menyang organisasi utawa menyang registri kontrol, kanthi timeout limang detik lan paling akeh 500 baris. Nilai biner ditampilake miturut ukuran.
- Rante audit platform nyathet sing ngetokake (kanthi alesan), pencabutan, saben statement sadurunge mlaku (`platform/break_glass_statement`, sing ditolak kanthi asil `denied`) lan saben asil (`platform/break_glass_result`). `ops.break_glass_statement` nyekel id entri audit, supaya cathetan penerbitan gabung menyang entri audite.
- Tulisan ora ditawakake. Owahan sing ora bisa ngenteni rilis nggunakake akses database operator dhewe ing sangisore cathetan owahane dhewe, ing njaba produk iki, lan cathetan kudune nyebut referensi insiden sing digunakake ing kene.

Kenapa ora ngetokake kredensial database: login Postgres luwih awet tinimbang sesi sing njaluk, ngliwati keamanan tingkat baris sing diandelake aplikasi, lan ora bisa nulis menyang rante audit produk iki, supaya statemente bakal diaudit mung nganti ana sing ngirim log server. Gateway nggawe jejak audit sifat saka akses tinimbang praktik ing sakubenge.

Kanggo mangsuli panjalukan audit: dhaptar hibah ing periode (Break-glass access), bukak riwayat hibah kanggo statemente lan id entri audit, lan waca entri kasebut ing rante audit platform (`bun run audit:verify --platform` mbuktekake rante utuh).

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