માસ્ટર કી અને સહી કીનું રોટેશન તથા ઇમરજન્સી ઍક્સેસ

ઓડિટર નામથી પૂછે તેવા 21-compliance.md ના વિભાગ 14 ના નિયંત્રણો અહીં છે. આ પાનું પ્રક્રિયા છે; તેનાથી બનતા રેકોર્ડ પુરાવા છે.

કીઓ

દરેક સંગ્રહિત ઓળખપત્ર નવી data encryption key (DEK) વડે સીલ થાય છે. DEK ને master key (KEK) લપેટે છે અને master key નો સંદર્ભ તેની બાજુમાં સંગ્રહાય છે (key_ref, અથવા packed value ની અંદરનો સંદર્ભ). Master key ફેરવવાથી DEK ફરી લપેટાય છે. ઓળખપત્ર ક્યારેય decrypt કે ફરી encrypt થતું નથી.

વેબ સ્તર, worker અને bun run kek:rotate આદેશ એ જ ત્રણ સેટિંગ વાંચે છે. તેમનાં મૂલ્યો સરખાં હોવા જોઈએ, નહિતર એક પ્રક્રિયા બીજી સીલ કરેલી વસ્તુ ખોલી શકશે નહીં.

QUIRE_MASTER_KEY ન હોય ત્યારે દરેક ઉપપ્રણાલી QUIRE_SECRET_KEY માંથી મેળવેલી key રાખે છે. આ કામ કરે છે, System health પાનું તેને degraded બતાવે છે, અને તમે master key સેટ કરો પછી પણ વાંચી શકાય છે; પ્રથમ rotation દ્વારા બધું તેની બહાર ખસેડાય છે. પ્રક્રિયાના environment વાંચી શકે તેવી કોઈપણ વ્યક્તિ દરેક સંગ્રહિત ઓળખપત્ર decrypt કરી શકે છે, તેથી production સ્થાપનમાં master key હોવી જોઈએ, secret store માં રાખવી જોઈએ અને ડેટાબેઝના એ જ backup માં ન રાખવી જોઈએ.

રોટેશન

કીની ઉંમર Platform console, Security, Master key માં અને quire.secrets.master_key.age (દિવસ) metric તરીકે દેખાય છે. દૈનિક platform.key_age schedule (03:41 UTC) કી 365 દિવસની થાય ત્યારે platform audit chain માં યાદ અપાવતી એન્ટ્રી લખે છે અને રોટેશન ન થાય ત્યાં સુધી દર 30 દિવસે ફરી લખે છે. યાદ અપાય ત્યારે અને કી ખુલ્લી પડી હોવાની શક્યતા હોય ત્યારે ફેરવો.

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. નવી સેટિંગ સાથે વેબ સ્તર અને worker deploy કરો. નવા secrets હવે env:QUIRE_MASTER_KEY:v2 હેઠળ લપેટાય છે; જૂનાં retired key વડે હજુ ખુલે છે.
4. audit trail માં રહેવાનું કારણ આપીને રોટેશન માગો:
   • console માં: Security, Master key, Rotate the master key; અથવા
   • એ જ environment ધરાવતા shell માં: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. worker દર મિનિટે એક ભાગ ફરી લપેટે છે (platform.key_rotation schedule) અને restart પછી આગળ ચાલુ રાખે છે. એક જ વખતમાં પૂર્ણ કરવા: bun run kek:rotate run. તેની સ્થિતિ bun run kek:rotate status વડે જુઓ.
6. રેકોર્ડમાં rotation પૂર્ણ અને zero unresolved and zero failed દેખાય ત્યારે QUIRE_MASTER_KEY_RETIRED માંથી જૂની key કાઢી deploy કરો. ત્યાં સુધી તેને રાખો: જે value ખસેડી ન શકાય તે હજુ જૂની key હેઠળ લપેટાયેલી છે.

જોબ કઈ વસ્તુઓ તપાસે છે

લપેટેલી DEK ધરાવતા દરેક store: SEALED_STORES માંના store (apps/worker/src/key-rotation.ts). Control database ના stores control database પર તપાસાય છે; organisation ના stores દરેક organisation માટે row-level security હેઠળ, તે જે database માં હોય ત્યાં તપાસાય છે, જેથી સમર્પિત database પર નિશ્ચિત tenant નું રોટેશન ત્યાં જ થાય. સ્કીમામાં wrapped-key column ઉમેરાય અને યાદીમાં નામ ન હોય તો એક કસોટી નિષ્ફળ જાય છે; credential review માં sealed column હોય પણ યાદીમાં ન હોય તો બીજી કસોટી નિષ્ફળ જાય છે.

રેકોર્ડ

• ops.key_rotation: દરેક rotation માટે એક row, જેમાં કારણ, કોણે વિનંતી કરી, સ્થિતિ અને કુલ આંકડા (ફરી લપેટેલી, પહેલેથી વર્તમાન, unresolved, failed) હોય છે.
• ops.key_rotation_progress: તપાસેલા દરેક store અને scope માટે એક row, જેમાં વાંચી ન શકાયેલા key references અને દરેક હેઠળ રહેલી values ની સંખ્યા હોય છે. ફરી શરૂ કરેલું rotation આને છોડે છે.
• Platform audit chain: platform/key_rotation_request (કારણ સાથે), દરેક store માટે ગણતરીઓ સાથેની platform/key_rotation_store અને platform/key_rotation_complete અથવા platform/key_rotation_fail; યાદ અપાવવા માટે platform/key_age_reminder.
• Metrics: quire.secrets.master_key.age અને quire.secrets.rewrap.outstanding (છેલ્લા rotation માં ખસેડી ન શકાયેલી values).

Values unresolved હોય ત્યારે

Unresolved value એવી key reference હેઠળ લપેટાયેલી છે જે આ સ્થાપન પાસે નથી, અથવા તેના કૉલમના વચનબદ્ધ સ્વરૂપમાં નથી. Progress record reference બતાવે છે (ઉદાહરણ તરીકે env:QUIRE_MASTER_KEY:v0 (unreadable)). તે key ને QUIRE_MASTER_KEY_RETIRED માં પુનઃસ્થાપિત કરીને બીજું rotation ચલાવો, અથવા key કાયમ માટે ખોવાઈ ગઈ હોય તો organisation ના administrator ને ઓળખપત્ર ફરી દાખલ કરવા કહો: તે પછી હાલની key હેઠળ સીલ થશે. નિષ્ફળ rotation તેની ભૂલ રેકોર્ડમાં બતાવે છે; કારણ સુધારી ફરી વિનંતી કરો.

Signing keys

Master key થી અલગ: દરેક organisation પોતાના OpenID Connect tokens અને LTI messages પોતાની RSA key વડે સહી કરે છે, જે /.well-known/jwks.json પર પ્રકાશિત થાય છે. અહીં operator ને કંઈ કરવાનું નથી. દર કલાકે ચાલતું platform.signing_keys schedule હાલની key ના 90 દિવસ પૂરા થાય તેના સાત દિવસ પહેલાં આગળની key પ્રકાશિત કરે છે; એક અઠવાડિયા પછી આગળની key સહી શરૂ કરે છે અને જૂની retiring બને છે; 90 દિવસ પછી જૂની key કાઢી key set માંથી દૂર થાય છે. દરેક પગલું platform audit chain માં platform/signing_key_advance એન્ટ્રી બને છે.

Organisation ની key વહેલી બદલવા માટે, ઉદાહરણ તરીકે 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 દરેક organisation ની key નો તબક્કો બતાવે છે.

નવી key તરત પ્રકાશિત થાય છે અને સાત દિવસ પછી, હાલની key નિવૃત્ત થાય ત્યારે, સહી શરૂ કરે છે. આ અઠવાડિયું ઇરાદાપૂર્વક છે: relying parties key set cache કરે છે, અને ટૂંકો overlap બધાં tools ને એકસાથે નિષ્ફળ કરે છે. જૂની key તેના વડે પહેલેથી સહી થયેલા tokens ચકાસી શકાય તે માટે બીજા 90 દિવસ key set માં રહે છે; ખુલ્લી પડેલી key ને વહેલી વિશ્વસનીયતા બહાર કરવી પડે તો તેની row કાઢવી એ operator પોતાના database access વડે change record હેઠળ કરે છે (break-glass access માત્ર વાંચવા માટે છે), અને પછી તેની સહીવાળા tokens ચકાસણીમાં નિષ્ફળ જશે. બળજબરીથી કરેલું rotation audit chain માં કારણ સાથે platform/signing_key_rotate બને છે. નવી key લપેટવા worker ને વેબ સ્તર જેવી જ QUIRE_MASTER_KEY સેટિંગ્સ જોઈએ; master key માટેનું bun run kek:rotate બીજા બધાની સાથે signing keys ફરી લપેટે છે (oauth_signing_key SEALED_STORES માં છે).

Production માટે break-glass ઍક્સેસ

કોઈ પાસે production માટે કાયમી ઍક્સેસ નથી. કોઈ બાબત રાહ ન જોઈ શકે ત્યારે owner break-glass grant આપે છે: Platform console, Security, Break-glass access.

• Grant નો scope (એક organisation અથવા platform registry), ઓછામાં ઓછા 20 અક્ષરનું કારણ જેમાં incident અથવા ticket નો ઉલ્લેખ હોય, અને 5 થી 240 મિનિટનો સમયગાળો હોય છે. તે આપમેળે સમાપ્ત થાય છે: દરેક statement વખતે ઘડિયાળ સામે તપાસાય છે.
• તે આપનાર owner પોતાને અથવા બીજા owner ને આપી શકે છે (બે-વ્યક્તિ રીત). ફક્ત જેને અપાયો હોય તે જ વાપરી શકે છે. આપવા platform/break_glass_issue અને વાપરવા platform/break_glass_use જરૂરી છે; મૂળભૂત રીતે બંને ફક્ત owner માટે છે.
• Statements database login પર નહીં, gateway મારફતે ચાલે છે: માત્ર વાંચવા માટે, એક સમયે એક, organisation અથવા 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 રાખે છે, જેથી issuance record audit entries સાથે જોડાય છે.
• લખવાની સુવિધા નથી. રિલીઝની રાહ ન જોઈ શકે એવો ફેરફાર આ product ની બહાર operator પોતાના database access વડે પોતાના change record હેઠળ કરે છે અને તેમાં અહીં વપરાયેલ incident reference આપવો જોઈએ.

Database credentials કેમ ન આપીએ: Postgres login તેને માગનાર session કરતાં લાંબો સમય જીવે છે, એપ્લિકેશન આધાર રાખે છે તે row-level security ને બાયપાસ કરે છે અને આ product ની audit chain માં લખી શકતો નથી; તેથી તેના statements ફક્ત server log મોકલાય ત્યાં સુધી જ audit થશે. Gateway audit trail ને ઍક્સેસની જ લાક્ષણિકતા બનાવે છે, તેની આસપાસની પ્રથા નહીં.

Audit વિનંતીનો જવાબ આપવા: તે સમયગાળાના grants યાદીબદ્ધ કરો (Break-glass access), grant નો ઇતિહાસ ખોલીને statements અને audit entry ids જુઓ, અને platform audit chain પર તે entries વાંચો (bun run audit:verify --platform chain અખંડિત હોવાની ખાતરી આપે છે).