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

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

कुंजियाँ

हर सहेजे क्रेडेंशियल को नई 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 नहीं होता।

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 करना

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 किन चीज़ों पर चलता है

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 विफल होता है।

रिकॉर्ड

• 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 हों तो

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

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 की आपातकालीन पहुँच

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 सही है)।