---
title: "मास्टर और हस्ताक्षर कुंजी बदलना, तथा आपातकालीन पहुँच"
description: "सहेजे क्रेडेंशियल की रक्षा करने वाली मास्टर कुंजी बदलें और आपातकालीन पहुँच इस्तेमाल करें।"
image: "https://docs.quirelms.com/og.png"
---

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

# मास्टर और हस्ताक्षर कुंजी बदलना, तथा आपातकालीन पहुँच

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

21-compliance.md के अनुभाग 14 वाले नियंत्रण हैं जिन्हें auditor नाम से माँगता है।
यह पृष्ठ प्रक्रिया है; इससे बने रिकॉर्ड सबूत हैं।

## कुंजियाँ <!--quire:the-keys-->

हर सहेजे क्रेडेंशियल को नई data encryption key (DEK) से seal किया जाता है। DEK
को master key (KEK) wrap करती है और master key का reference उसके पास
(`key_ref`, या packed value के भीतर reference) सहेजा जाता है। Master key बदलने
से DEK दोबारा wrap होते हैं। कोई credential decrypt या re-encrypt नहीं होता।

| Setting | अर्थ |
| --- | --- |
| `QUIRE_MASTER_KEY` | मौजूदा master key: 32 bytes, base64। हर नया secret इससे wrap होता है |
| `QUIRE_MASTER_KEY_VERSION` | इसका version label। unset होने पर `v1`। key बदलते समय इसे बढ़ाएँ |
| `QUIRE_MASTER_KEY_RETIRED` | पुराने secrets अब भी जिन keys के नीचे हो सकते हैं, जैसे `v1=<base64>,v0=<base64>`। पढ़ें, कभी लिखें नहीं |

Web tier, worker और `bun run kek:rotate` command एक ही तीन settings पढ़ते हैं। इनके
मान बिल्कुल समान होने चाहिए, वरना उनमें से एक वह नहीं खोल पाएगा जिसे दूसरे ने
seal किया था।

`QUIRE_MASTER_KEY` न होने पर हर subsystem `QUIRE_SECRET_KEY` से निकली key रखता
है। यह काम करता है, System health पृष्ठ इसे degraded बताता है, और master key
सेट करने के बाद भी पढ़ा जा सकता है; पहली rotation इसी तरह सब कुछ उस key से हटाती
है। Process environment पढ़ सकने वाला हर व्यक्ति सहेजे सभी credentials decrypt
कर सकता है, इसलिए production install में master key को secret store में रखें,
database के backup के साथ नहीं।

## Rotation करना <!--quire:rotating-->

Key की उम्र Platform console, Security, Master key और metric
`quire.secrets.master_key.age` (दिनों) में दिखती है। रोज़ की
`platform.key_age` schedule (03:41 UTC) key 365 दिन की होने पर platform audit
chain में reminder entry लिखती है, फिर बदले जाने तक हर 30 दिन में। Reminder पर
और जब भी key उजागर हुई हो सकती है, rotation करें।

1. नई key बनाएँ: `openssl rand -base64 32`।
2. `QUIRE_MASTER_KEY` को उस पर और `QUIRE_MASTER_KEY_VERSION` को अगले label
   (`v2`) पर सेट करें। पुरानी key को `QUIRE_MASTER_KEY_RETIRED` में
   `v1=<old base64>` के रूप में ले जाएँ। दोनों की कॉपी इस host से अलग रखें।
3. नई settings के साथ web tier और worker deploy करें। नए secrets अब
   `env:QUIRE_MASTER_KEY:v2` के नीचे wrap होंगे; पुराने retired key से खुलते रहेंगे।
4. Audit trail में रहने वाले कारण सहित rotation माँगें:
   - console में: Security, Master key, Rotate the master key; या
   - उसी environment वाले shell में:
     `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`।
5. Worker हर मिनट एक हिस्सा re-wrap करता है (`platform.key_rotation` scheduler
   schedule) और restart के बाद जारी रहता है। एक बार में पूरा करने के लिए
   `bun run kek:rotate run` चलाएँ। `bun run kek:rotate status` से देखें।
6. रिकॉर्ड rotation पूरी दिखाए और **zero unresolved तथा zero failed** हों तो
   `QUIRE_MASTER_KEY_RETIRED` से retired key हटाकर फिर deploy करें। तब तक उसे
   रखें: जो value यह स्थानांतरित नहीं कर पाया वह अब भी पुरानी key से wrap है।

### Job किन चीज़ों पर चलता है <!--quire:what-the-job-walks-->

Wrap किए DEK रखने वाला हर store: `SEALED_STORES` में मौजूद stores
(`apps/worker/src/key-rotation.ts`)। Control database stores को control database
में scan किया जाता है; organisation stores को row-level security के तहत एक बार
में एक संगठन करके, जिस भी database में वह संगठन हो वहाँ scan करते हैं, इसलिए
समर्पित database पर pin tenant उसी database में बदलता है। Schema में सूची से छूटा
wrapped-key column जुड़ने पर एक test और credential review से छूटा sealed column
होने पर दूसरा test विफल होता है।

### रिकॉर्ड <!--quire:the-record-->

- `ops.key_rotation`: हर rotation की एक row, जिसमें कारण, अनुरोधकर्ता, स्थिति और
  कुल संख्याएँ (re-wrapped, पहले से current, unresolved, failed) हैं।
- `ops.key_rotation_progress`: scan किए गए हर store और scope की एक row, जिसमें
  पढ़ न सकी key references और हर एक के नीचे की values की संख्या है। जारी की गई
  rotation इन्हें छोड़ देती है।
- Platform audit chain: `platform/key_rotation_request` (कारण सहित), हर store
  के लिए counts समेत एक `platform/key_rotation_store`, और
  `platform/key_rotation_complete` या `platform/key_rotation_fail`;
  reminder के लिए `platform/key_age_reminder`।
- Metrics: `quire.secrets.master_key.age` और `quire.secrets.rewrap.outstanding`
  (आख़िरी rotation जिन values को नहीं हटा सकी)।

### Values unresolved हों तो <!--quire:when-values-are-unresolved-->

Unresolved value ऐसी key reference के नीचे wrap है जो इस install के पास नहीं,
या उसका आकार column के वादे से मेल नहीं खाता। Progress record reference बताता
है (उदाहरण के लिए `env:QUIRE_MASTER_KEY:v0 (unreadable)`)। वह key
`QUIRE_MASTER_KEY_RETIRED` में वापस रखें और दूसरी rotation चलाएँ, या key हमेशा
के लिए खो गई हो तो संगठन का प्रशासक credential फिर दर्ज करे: वह current key से
seal होगा। असफल rotation अपनी त्रुटि record में दिखाती है; कारण ठीक करके फिर
अनुरोध करें।

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

Master key से अलग, हर संगठन अपने OpenID Connect tokens और LTI messages पर अपने
RSA key से हस्ताक्षर करता है; यह `/.well-known/jwks.json` पर प्रकाशित है। यहाँ
संचालक को कुछ करने की ज़रूरत नहीं। हर घंटे चलने वाली `platform.signing_keys`
schedule मौजूदा key के 90 दिन पूरे होने से सात दिन पहले अगला key प्रकाशित करती
है; एक सप्ताह बाद अगला key हस्ताक्षर शुरू करता है और पुराना retiring होता है;
उसके 90 दिन बाद पुराना key मिटाकर key set से हटता है। हर चरण platform audit
chain में `platform/signing_key_advance` entry है।

Exposure के बाद, उदाहरण के लिए, संगठन की key जल्दी बदलने के लिए:

- console में: Security, Master key, Publish a new signing key (इसके लिए
  `platform/keys_manage` चाहिए); या
- worker के environment वाले shell में:
  `bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310"`।
  `bun run kek:rotate signing-keys status` हर संगठन की keys को चरण के अनुसार सूचीबद्ध करता है।

नई key तुरंत प्रकाशित होती है और सात दिन बाद हस्ताक्षर शुरू करती है, जब मौजूदा
key retire होता है। सप्ताह जानबूझकर है: relying parties key set cache करते हैं
और कम overlap सभी tools को एक साथ विफल करता है। Retiring key और 90 दिन key set
में रहता है, ताकि उसके पहले हस्ताक्षर किए tokens सत्यापित हों; exposure के कारण
उसे जल्दी अविश्वसनीय करना हो तो उसकी row मिटाना संचालक की अपनी database पहुँच
से change record के तहत किया जाने वाला बदलाव है (break-glass पहुँच read-only है),
और उसके tokens सत्यापन में विफल होंगे। ज़बरदस्ती rotation कारण सहित audit chain
में `platform/signing_key_rotate` है। नई key wrap करने के लिए worker को web tier
जैसी `QUIRE_MASTER_KEY` settings चाहिए; master key के लिए `bun run kek:rotate` बाकी
सबके साथ signing keys को re-wrap करता है (`oauth_signing_key`, `SEALED_STORES`
में है)।

## Production की आपातकालीन पहुँच <!--quire:break-glass-production-access-->

Production की स्थायी पहुँच किसी के पास नहीं है। कुछ इंतज़ार न कर सके तो owner
आपातकालीन grant जारी करता है: Platform console, Security, Break-glass access।

- Grant का scope (एक संगठन या platform registry), घटना या ticket बताने वाला कम-से-कम
  20 अक्षरों का कारण, और 5 से 240 मिनट की अवधि होती है। हर statement पर घड़ी से
  जाँच होती है और अवधि अपने आप समाप्त होती है।
- इसे जारी करने वाले owner को या किसी दूसरे owner को (दो व्यक्ति वाला तरीका)
  दिया जा सकता है। सिर्फ़ वही व्यक्ति इसे इस्तेमाल कर सकता है। जारी करने के लिए
  `platform/break_glass_issue`, इस्तेमाल के लिए `platform/break_glass_use` चाहिए;
  डिफ़ॉल्ट रूप से दोनों owner तक सीमित हैं।
- Statements database login से नहीं, gateway से चलते हैं: read-only, एक बार में
  एक, संगठन या control registry तक सीमित, पाँच सेकंड timeout और अधिकतम 500 rows।
  Binary values आकार से दिखाई जाती हैं।
- Platform audit chain जारी करना (कारण सहित), रद्द करना, चलने से पहले हर statement
  (`platform/break_glass_statement`, अस्वीकृत का outcome `denied`) और हर परिणाम
  (`platform/break_glass_result`) दर्ज करती है। `ops.break_glass_statement` audit
  entry IDs रखता है, इसलिए जारी करने का रिकॉर्ड अपनी audit entries से जुड़ता है।
- Writes का विकल्प नहीं है। Release तक न रुक सकने वाला बदलाव संचालक की अपनी
  database पहुँच से अपने change record के तहत इस product के बाहर होता है; रिकॉर्ड
  में यहाँ इस्तेमाल incident reference देना चाहिए।

Database credentials क्यों न दें: Postgres login माँगने वाले session से आगे तक
चलता है, application पर निर्भर row-level security को पार करता है और product की
audit chain में नहीं लिख सकता, इसलिए statements सिर्फ़ उतने दर्ज होंगे जितना
किसी ने server log भेजा। Gateway audit trail को पहुँच का गुण बनाता है, उसके आसपास
की प्रक्रिया नहीं।

Audit अनुरोध का जवाब देने के लिए: अवधि के grants सूचीबद्ध करें (Break-glass
access), grant का इतिहास खोलकर statements और audit entry IDs देखें, फिर platform
audit chain में वे entries पढ़ें (`bun run audit:verify --platform` साबित करता है कि
chain सही है)।

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