---
title: "માસ્ટર કી અને સહી કીનું રોટેશન તથા ઇમરજન્સી ઍક્સેસ"
description: "સંગ્રહિત ઓળખપત્રોને સુરક્ષિત રાખતી માસ્ટર કી ફેરવો અને ઇમરજન્સી ઍક્સેસ વાપરો."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/gu/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-->

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

| સેટિંગ | અર્થ |
| --- | --- |
| `QUIRE_MASTER_KEY` | હાલની master key: 32 bytes, base64. દરેક નવું secret તેની નીચે લપેટાય છે |
| `QUIRE_MASTER_KEY_VERSION` | તેનું version label. સેટ ન હોય ત્યારે `v1`. key બદલો ત્યારે તેને વધારો |
| `QUIRE_MASTER_KEY_RETIRED` | અગાઉની keys, જેના હેઠળ secrets હજુ હોઈ શકે, `v1=<base64>,v0=<base64>` રૂપે. વાંચાય છે, લખાતું નથી |

વેબ સ્તર, 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 માં ન રાખવી જોઈએ.

## રોટેશન <!--quire:rotating-->

કીની ઉંમર 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 હેઠળ લપેટાયેલી છે.

### જોબ કઈ વસ્તુઓ તપાસે છે <!--quire:what-the-job-walks-->

લપેટેલી 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 હોય પણ યાદીમાં ન હોય તો બીજી
કસોટી નિષ્ફળ જાય છે.

### રેકોર્ડ <!--quire:the-record-->

- `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 હોય ત્યારે <!--quire:when-values-are-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 <!--quire: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 ઍક્સેસ <!--quire:break-glass-production-access-->

કોઈ પાસે 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 અખંડિત હોવાની ખાતરી આપે છે).

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