मास्टर कुञ्जी र हस्ताक्षर कुञ्जी घुमाउने, र ब्रेक-ग्लास पहुँच

21-compliance.md खण्ड 14 का नियन्त्रण जुन अडिटरले नामै लिएर सोध्छ। यो पृष्ठ प्रक्रिया हो; यसले बनाउने रेकर्ड प्रमाण हुन्।

कुञ्जीहरू

हरेक भण्डारित प्रमाण नयाँ डेटा इन्क्रिप्सन कुञ्जी (DEK) ले सिल हुन्छ। DEK मास्टर कुञ्जी (KEK) ले बेरिन्छ, र मास्टर कुञ्जीको सन्दर्भ यसको छेउमा भण्डारण हुन्छ (key_ref, वा प्याक गरिएको मानभित्रको सन्दर्भ)। मास्टर कुञ्जी घुमाउँदा DEK पुनः बेरिन्छ। यसले प्रमाण कहिल्यै डिक्रिप्ट वा पुनः इन्क्रिप्ट गर्दैन।

वेब तह, वर्कर र bun run kek:rotate आदेशले उही तीन सेटिङ पढ्छन्। सबैको मान उही हुनैपर्छ, नत्र एउटाले अर्कोले सिल गरेको खोल्न सक्दैन।

QUIRE_MASTER_KEY बिना हरेक उपप्रणालीले QUIRE_SECRET_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. अडिट ट्रेलमा बस्ने कारणसहित घुमाउने अनुरोध गर्नुहोस्:
   • कन्सोलमा: सुरक्षा, मास्टर कुञ्जी, मास्टर कुञ्जी घुमाउनुहोस्; वा
   • उही वातावरण भएको सेलमा: 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 बाट हटाउनुहोस् र पुनः परिनियोजन गर्नुहोस्। तबसम्म राख्नुहोस्: यसले सार्न नसकेको मान अझै पुरानो कुञ्जीमुनि बेरिएको छ।

कामले के घुम्छ

बेरिएको DEK राख्ने हरेक भण्डार: SEALED_STORES मा भएका (apps/worker/src/key-rotation.ts)। नियन्त्रण डेटाबेस भण्डार नियन्त्रण डेटाबेसमा घुम्छन्; सङ्गठन भण्डार पङ्क्ति-स्तर सुरक्षामा एक-एक सङ्गठन घुम्छन्, सङ्गठन भएको डेटाबेसमा, त्यसैले समर्पित डेटाबेसमा पिन गरिएको टेनान्ट त्यही डेटाबेसमा घुम्छ। स्किमाले बेरिएको-कुञ्जी स्तम्भ पाउँदा सूचीले नाम नदिए परीक्षण असफल हुन्छ, र प्रमाण समीक्षाले सिल गरिएको स्तम्भ वर्गीकरण गर्दा अर्को असफल हुन्छ जुन सूचीले छुटाउँछ।

रेकर्ड

• 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 (अन्तिम घुमाउनेले सार्न नसकेका मान)।

मान अनसुलझे हुँदा

अनसुलझे मान यस स्थापनासँग नभएको कुञ्जी सन्दर्भमुनि बेरिएको छ, वा यसको स्तम्भले दिने आकारमा छैन। प्रगति रेकर्डले सन्दर्भ नाम दिन्छ (उदाहरणका लागि env:QUIRE_MASTER_KEY:v0 (unreadable))। त्यो कुञ्जी QUIRE_MASTER_KEY_RETIRED मा पुनर्स्थापना गर्नुहोस् र अर्को घुमाउने चलाउनुहोस्, वा, कुञ्जी सदाका लागि हराएको भए, सङ्गठनको प्रशासकलाई प्रमाण फेरि हाल्न लगाउनुहोस्: यो त्यसपछि हालको कुञ्जीमुनि सिल हुन्छ। असफल घुमाउनेले रेकर्डमा त्रुटि देखाउँछन्; कारण ठीक गर्नुहोस् र फेरि अनुरोध गर्नुहोस्।

हस्ताक्षर कुञ्जीहरू

मास्टर कुञ्जीबाट छुट्टै: हरेक सङ्गठनले आफ्ना OpenID Connect टोकन र LTI सन्देश आफ्नै RSA कुञ्जीले हस्ताक्षर गर्छ, /.well-known/jwks.json मा प्रकाशित। यहाँ सञ्चालकलाई केही चाहिँदैन। प्रतिघण्टा platform.signing_keys तालिकाले हालको कुञ्जीको नब्बे दिन सकिनु सात दिनअघि उत्तराधिकारी प्रकाशन गर्छ, एक हप्ता पछि उत्तराधिकारीले हस्ताक्षर सुरु गर्छ र पुरानो कुञ्जी सेवानिवृत्त हुन्छ, र त्यसको नब्बे दिनपछि पुरानो कुञ्जी मेटिन्छ र कुञ्जी सेट छोड्छ। हरेक चरण प्लेटफर्म अडिट शृङ्खलामा platform/signing_key_advance प्रविष्टि हो।

सङ्गठनको कुञ्जी चाँडै प्रतिस्थापन गर्न, उदाहरणका लागि उजागर पछि:

• कन्सोलमा: सुरक्षा, मास्टर कुञ्जी, नयाँ हस्ताक्षर कुञ्जी प्रकाशन गर्नुहोस् (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 मा छ)।

ब्रेक-ग्लास उत्पादन पहुँच

कसैसँग उत्पादनको स्थायी पहुँच हुँदैन। पर्खन नसक्ने केही हुँदा, स्वामीले ब्रेक-ग्लास अनुदान जारी गर्छ: प्लेटफर्म कन्सोल, सुरक्षा, ब्रेक-ग्लास पहुँच।

• अनुदानको दायरा हुन्छ (एउटा सङ्गठन, वा प्लेटफर्म रजिस्ट्री), घटना वा टिकट नाम दिने कम्तीमा 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 लगइनले माग्ने सत्रभन्दा लामो आयु बोक्छ, अनुप्रयोग भर पर्ने पङ्क्ति-स्तर सुरक्षा छल्छ, र यस उत्पादनको अडिट शृङ्खलामा लेख्न सक्दैन, त्यसैले यसका कथन कसैले सर्भर लग पठाएसम्म मात्र अडिट हुन्छन्। गेटवेले अडिट ट्रेललाई यस वरिपरिको अभ्यासको सट्टा पहुँचकै गुण बनाउँछ।

अडिट अनुरोधको जवाफ दिन: अवधिका अनुदान सूचीबद्ध गर्नुहोस् (ब्रेक-ग्लास पहुँच), यसका कथन र अडिट प्रविष्टि id का लागि अनुदानको इतिहास खोल्नुहोस्, र प्लेटफर्म अडिट शृङ्खलामा ती प्रविष्टि पढ्नुहोस् (bun run audit:verify --platform ले शृङ्खला अखण्ड छ प्रमाणित गर्छ)।