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

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/mr/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 मधील ती नियंत्रणे जी ऑडिटर नावाने
मागतो. हे पृष्ठ क्रियाविधी आहे; त्यातून तयार होणाऱ्या नोंदी हे
पुरावे आहेत.

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

प्रत्येक जतन केलेले प्रमाणपत्र नवीन डेटा एन्क्रिप्शन कुंजीने
(DEK) सीलबंद केलेले असते. DEK मास्टर कुंजीने (KEK) आवरलेले असते
आणि मास्टर कुंजीचा संदर्भ त्याच्या बाजूला जतन केलेला असतो
(`key_ref`, किंवा पॅक केलेल्या मूल्यातील संदर्भ). मास्टर कुंजी
फेरबदल केल्यावर DEKs पुन्हा आवरले जातात. ते प्रमाणपत्र कधीही
डिक्रिप्ट किंवा पुन्हा एन्क्रिप्ट करत नाही.

| सेटिंग | अर्थ |
| --- | --- |
| `QUIRE_MASTER_KEY` | सध्याची मास्टर कुंजी: 32 बाइट्स, base64. प्रत्येक नवीन गोपनीय मूल्य त्याखाली आवरलेले असते |
| `QUIRE_MASTER_KEY_VERSION` | तिचे आवृत्ती लेबल. सेट नसेल तर `v1`. कुंजी बदलताना ते वाढवा |
| `QUIRE_MASTER_KEY_RETIRED` | आधी गोपनीय मूल्ये जतन करणाऱ्या जुन्या कुंज्या, अजूनही याखाली असू शकतात, `v1=<base64>,v0=<base64>` म्हणून. वाचला जातो, कधीही लिहिला जात नाही |

वेब थिअर, वर्कर आणि `bun run kek:rotate` कमांड ही तीनही सेटिंग्ज
वाचतात. त्यांना होच मूल्ये असायला हवी, नाहीतर एक दुसऱ्याने
सीलबंद केलेले उघडू शकत नाही.

`QUIRE_MASTER_KEY` न असताना प्रत्येक उपप्रणाली `QUIRE_SECRET_KEY`
पासून तयार करते अशी कुंजी ठेवते. ते काम करते, प्रणाली आरोग्य
पृष्ठ ते कमी क्षमतेचे म्हणून दाखवते आणि तुम्ही मास्टर कुंजी
सेट केल्यावरही ते वाचता येत राहते, ज्यामुळे पहिला फेरबदल सर्व
काही त्यावरून काढतो. प्रोसेस एन्व्हायरमेंट वाचू शकणाऱ्या
कोणालाही प्रत्येक जतन केलेले प्रमाणपत्र डिक्रिप्ट करता येते,
त्यामुळे प्रॉडक्शन स्थापनेला मास्टर कुंजी असायला हवी, जी गोपनीय
स्टोअरमध्ये जतन केलेली असते आणि डेटाबेसच्या त्याच बॅकअपमध्ये
नसते.

## फेरबदल <!--quire:rotating-->

कुंजीचे वय Platform console, Security, Master key वर आणि
`quire.secrets.master_key.age` (दिवस) मेट्रिक म्हणून दिसते.
दैनंदिन `platform.key_age` शेड्यूल (03:41 UTC) कुंजी 365 दिवसांस
पोहोचल्यावर आणि फेरबदल होईपर्यंत दर 30 दिवसांनी, प्लॅटफॉर्म ऑडिट
साखळीत स्मरणपत्र नोंद लिहिते. स्मरणपत्रावरून फेरबदल करा, आणि
कुंजी उघडून गेल्याची शंका आल्यावरही.

1. नवीन कुंजी तयार करा: `openssl rand -base64 32`.
2. `QUIRE_MASTER_KEY` त्यावर सेट करा आणि `QUIRE_MASTER_KEY_VERSION`
   पुढील लेबलवर (`v2`). जुनी कुंजी
   `QUIRE_MASTER_KEY_RETIRED` मध्ये `v1=<old base64>` म्हणून हलवा.
   दोन्हींची प्रत या होस्टबाहेर कुठेतरी ठेवा.
3. नवीन सेटिंग्जसह वेब थिअर आणि वर्कर डिप्लॉय करा. नवीन
   गोपनीय मूल्या आता `env:QUIRE_MASTER_KEY:v2` खाली आवरलेली
   असतात; जुनी अजूनही रिटायर केलेल्या कुंजीद्वारे उघडतात.
4. ऑडिट ट्रेलमध्ये राहणारे कारण घेऊन फेरबदलची विनंती करा:
   - कन्सोलमध्ये: Security, Master key, मास्टर कुंजी फेरबदला; किंवा
   - त्याच एन्व्हायरमेंट असलेल्या शेलवर:
     `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. वर्कर दर मिनिटाला एक तुकडा पुन्हा आवरतो (शेड्यूलरची
   `platform.key_rotation` वेळापत्रक) आणि पुन्हा सुरू केल्यावर
   पुढे जातो. एकाच बसण्यात पूर्ण करण्यासाठी:
   `bun run kek:rotate run`. `bun run kek:rotate status` ने ते पाहा.
6. नोंदी **शून्य अनिर्धारित आणि शून्य अपयशस्वी** सह फेरबदल
   पूर्ण झाल्याचे दाखवल्यावर, `QUIRE_MASTER_KEY_RETIRED` मधून
   रिटायर केलेली कुंजी काढा आणि पुन्हा डिप्लॉय करा. तोपर्यंत
   ती ठेवा: ती हलवू शकली नाही असे मूल्य अजूनही जुन्या
   कुंजीखाली आवरलेले असते.

### जॉब काय फिरवते <!--quire:what-the-job-walks-->

आवरलेले DEK ठेवणारे प्रत्येक स्टोअर: `SEALED_STORES` मधील
(`apps/worker/src/key-rotation.ts`). कंट्रोल डेटाबेस स्टोअर
कंट्रोल डेटाबेसवर फिरवले जातात; संघटना स्टोअर रो-लेव्हल
सुरक्षेखाली एका संघटनेकडे एकदा, ज्या डेटाबेसमध्ये संघटना आहे
तिथे फिरवले जातात, त्यामुळे समर्पित डेटाबेसशी बांधलेल्या
टेनंटचा त्या डेटाबेसमध्येच फेरबदल होतो. स्कीमेत यादीत नाव
न असलेला आवरलेल-कुंजी स्तंभ आल्यास चाचणी अपयशस्वी होते आणि
प्रमाणपत्र परामर्शात सीलबंद स्तंभ यादी सुटलेला असल्यास दुसरी
चाचणी अपयशस्वी होते.

### नोंद <!--quire:the-record-->

- `ops.key_rotation`: प्रत्येक फेरबदलाची एक ओळ, तिचे कारण, कोणी
  विनंती केली, तिची स्थिती आणि एकूण (पुन्हा आवरलेली, आधीच
  वर्तमान, अनिर्धारित, अपयशस्वी).
- `ops.key_rotation_progress`: प्रत्येक स्टोअर व स्कोपसाठी
  फिरवल्यावर एक ओळ, जे संदर्भ ते वाचू शकले नाहीत आणि प्रत्येक
  खाली किती मूल्ये होती यासह. पुन्हा सुरू झालेला फेरबदल ही
  ओळी वगळतो.
- प्लॅटफॉर्म ऑडिट साखळी: `platform/key_rotation_request` (कारणासह),
  प्रत्येक स्टोअरसाठी एक `platform/key_rotation_store` त्याच्या
  आकड्यांसह, आणि `platform/key_rotation_complete` किंवा
  `platform/key_rotation_fail`; स्मरणपत्रासाठी
  `platform/key_age_reminder`.
- मेट्रिक्स: `quire.secrets.master_key.age` आणि
  `quire.secrets.rewrap.outstanding` (मागील फेरबदलाने हलवू न
  शकलेली मूल्ये).

### मूल्ये अनिर्धारित असतील तेव्हा <!--quire:when-values-are-unresolved-->

अनिर्धारित मूल्य ही स्थापनेकडे नसलेल्या कुंजी संदर्भाखाली
आवरलेली असते, किंवा तिच्या स्तंभाने वचन दिलेल्या स्वरूपात
नसते. प्रगती नोंद तो संदर्भ नावासह सांगते (उदाहरणार्थ
`env:QUIRE_MASTER_KEY:v0 (unreadable)`). ती कुंजी
`QUIRE_MASTER_KEY_RETIRED` मध्ये परत आणा आणि आणखी एक फेरबदल
चालवा, किंवा, कुंजी कायमची गेली असेल तर, संघटनेचे प्रशासक
ते प्रमाणपत्र पुन्हा टाकू द्या: तेव्हे ते सध्याच्या कुंजीखाली
सीलबंद होते. अपयशस्वी फेरबदल नोंदीवर त्यांची त्रुटी दाखवतात;
कारण दुरुस्त करा आणि पुन्हा विनंती करा.

## सही कुंज्या <!--quire:signing-keys-->

मास्टर कुंजीपासून वेगळे: प्रत्येक संघटना स्वतःच्या RSA
कुंजीने स्वतःच्या OpenID Connect टोकन आणि LTI संदेशांना सही
करते, जी `/.well-known/jwks.json` वर प्रकाशित होते. यासाठी
इथे संचालकाची गरज नाही. तासाने चालणारे `platform.signing_keys`
शेड्यूल सध्याच्या कुंजीचे नवें दिवस संपण्यापूर्वी सात दिवसांनी
उत्तराधिकारी प्रकाशित करते, आठवड्यानंतर उत्तराधिकारी सही
सुरू करतो आणि जुनी कुंजी रिटायर होते, आणि त्यानंतर नवें दिवसांनी
जुनी कुंजी हटवली जाते आणि कुंजी संचातून निघते. प्रत्येक पायरी
प्लॅटफॉर्म ऑडिट साखळीतील `platform/signing_key_advance` नोंद
असते.

उदाहरणार्थ उघडणीनंतर, संघटनेची कुंजी लवकर बदलण्यासाठी:

- कन्सोलमध्ये: Security, Master key, नवीन सही कुंजी प्रकाशित करा
  (`platform/keys_manage` लागते); किंवा
- वर्करच्या एन्व्हायरमेंट असलेल्या शेलवर:
  `bun run kek:rotate signing-keys rotate
  --tenant <slug or id> --reason "Key exposed, INC-3310"`. `bun run kek:rotate
  signing-keys status` प्रत्येक संघटनेच्या
  कुंज्या टप्प्यानुसार दाखवते.

नवीन कुंजी लगेच प्रकाशित होते आणि सात दिवसांनंतर, जेव्हा
सध्याची कुंजी रिटायर होते, तेव्हा सही सुरू करते. आठवडा
यादाखतीचा आहे: विश्वासपात्र पक्ष कुंजी संच कॅश करतात आणि
छोटा ओभरलॅप प्रत्येक साधन एकाच वेळी अपयशस्वी करतो. रिटायर
होणारी कुंजी आणखी नवें दिवस कुंजी संचात राहते ज्यामुळे तिने
आधीच सही केलेले टोकन पडताळत राहतात; उघडणीमुळे ती लवकर
विश्वासार्ह राहणे बंद करायचे असेल तर, तिची ओळ हटवणे हे
बदल नोंदीसह, संचालकाच्या स्वतःच्या डेटाबेस प्रवेशाने केलेला
बदल असतो (ब्रेक-ग्लास प्रवेश फक्त वाचनपरायण आहे), आणि त्याने
सही केलेले टोकन नंतर पडताळणीत अपयशस्वी होतात. जबरदस्तीने
केलेला फेरबदल कारणासह ऑडिट साखळीतील
`platform/signing_key_rotate` असतो. नवीन कुंजी आवरण्यासाठी
वर्करला वेब थिअरप्रमाणेच हीच `QUIRE_MASTER_KEY` सेटिंग्ज
लागतात; मास्टर कुंजीसाठीचे `bun run kek:rotate` इतर सर्व करताना
सही कुंज्याही पुन्हा आवरते (`oauth_signing_key` ही
`SEALED_STORES` मध्ये आहे).

## ब्रेक-ग्लास प्रॉडक्शन प्रवेश <!--quire:break-glass-production-access-->

प्रॉडक्शनवर कोणाकडेही कायमस्वरूपी प्रवेश नसतो. काहीतरी
थांबू शकत नसते तेव्हा मालक ब्रेक-ग्लास मंजुरी जारी करतो:
Platform console, Security, Break-glass access.

- मंजुरीला स्कोप (एक संघटना, किंवा प्लॅटफॉर्म रजिस्ट्री), किमान
  20 अक्षरांचे घटना किंवा टिकट नावासह कारण आणि 5 ते 240 मिनिटांची
  विंडो असते. ती स्वतः संपते: प्रत्येक विधानावर घड्याळाशी
  ती तपासली जाते.
- ती जारी करणाऱ्या मालकाला, किंवा दुसऱ्या मालकाला दिली जाऊ
  शकते (दोन माणसांचे स्वरूप). ज्याला ती दिली गेली तोच वापरू
  शकतो. जारी करण्यासाठी `platform/break_glass_issue` आणि
  वापरण्यासाठी `platform/break_glass_use` लागते; दोन्ही
  डीफॉल्टरित्या फक्त मालक यांसाठी आहेत.
- विधाने गेटवेद्वारे चालतात, डेटाबेस लॉगिनवरून नाही: फक्त
  वाचनपरायण, एकाच वेळी एक, संघटना किंवा कंट्रोल रजिस्ट्रीपर्यंत
  मर्यादित, पाच सेकंदांच्या वेळेमर्यादेसह आणि किमान 500 रूंद्या.
  बायनरी मूल्ये आकाराने दाखवली जातात.
- प्लॅटफॉर्म ऑडिट साखळी जारी करणे (कारणासह), रद्द करणे, चालू
  होण्यापूर्वी प्रत्येक विधान (`platform/break_glass_statement`,
  नाकारलेली `denied` परिणामासह) आणि प्रत्येक निकाल
  (`platform/break_glass_result`) नोंदवते.
  `ops.break_glass_statement` ऑडिट एन्ट्री id ठेवते, ज्यामुळे
  जारी करण्याची नोंद तिच्या ऑडिट एंट्रींशी जुळते.
- लेखने दिली जात नाहीत. रिलीजची प्रतीक्षा न करता शक्य नसलेला
  बदल संचालकाच्या स्वतःच्या डेटाबेस प्रवेशाने, त्याच्या स्वतःच्या
  बदल नोंदीसह, या उत्पादनाबाहेर केला जातो आणि नोंदीत इथे
  वापरलेला घटना संदर्भ उद्धृत असायला हवा.

डेटाबेस प्रमाणपत्रे का जारी करत नाही: Postgres लॉगिन त्याची
मागणी करणाऱ्या सत्रापेक्षा जास्त काळ टिकते, अनुप्रयोगावर
अवलंबून असलेल्या रो-लेव्हल सुरक्षेला दुर्लक्ष करते आणि या
उत्पादनाच्या ऑडिट साखळीत लिहू शकत नाही, त्यामुळे त्याची
विधाने फक्त तोपर्यंतच ऑडिटमध्ये येतात जोपर्यंत कोणी सर्व्हर
लॉग पाठवला. गेटवेही ऑडिट ट्रेलला प्रवेशाभोवतीची सवय न राहता
प्रवेशाचे स्वतःचे गुणधर्म बनवतो.

ऑडिट विनंतीला उत्तर देण्यासाठी: कालावधीतील मंजुर्या दाखवा
(Break-glass access), मंजुरीचा इतिहास विधने आणि ऑडिट एन्ट्री
id साठी उघडा आणि त्या एंट्री प्लॅटफॉर्म ऑडिट साखळीत वाचा
(`bun run audit:verify --platform` साखळी अखंड आहे हे सिद्ध करते).

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