---
title: "የዋናና የፊርማ ቁልፎችን ማሽከርከር፣ እና የአደጋ ጊዜ መዳረሻ"
description: "የተቀመጡ ምስክርነቶችን የሚጠብቀውን ዋና ቁልፍ ያሽከርክሩና የአደጋ ጊዜ መዳረሻን ይጠቀሙ።"
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/am/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` ወይም በታሸገ እሴት ውስጥ)። ዋና ቁልፉን ማሽከርከር DEKዎቹን እንደገና ይጠቀልላል። ምስክርነትን አይፈታም ወይም እንደገና አይመስጥርም።

| ቅንብር | ትርጉም |
| --- | --- |
| `QUIRE_MASTER_KEY` | የአሁኑ ዋና ቁልፍ፤ 32 ባይት፣ base64። አዲስ ሚስጥር ሁሉ በእሱ ይጠቀለላል |
| `QUIRE_MASTER_KEY_VERSION` | የስሪት ምልክት፤ ካልተቀመጠ `v1` ነው። ቁልፉን በቀየሩ ጊዜ ሁሉ ያሳድጉት |
| `QUIRE_MASTER_KEY_RETIRED` | ሚስጥሮች አሁንም ሊጠቀለሉባቸው የሚችሉ አሮጌ ቁልፎች፣ ለምሳሌ `v1=<base64>,v0=<base64>`። ለማንበብ ብቻ ነው፣ አይጻፍበትም |

የድር ክፍሉ፣ worker እና `bun run kek:rotate` ትእዛዝ ተመሳሳይ ሶስቱን ቅንብሮች ያነባሉ። እሴቶቹ ተመሳሳይ መሆን አለባቸው፤ ካልሆነ አንዱ ሌላው የዘጋውን መክፈት አይችልም።

`QUIRE_MASTER_KEY` ከሌለ እያንዳንዱ ንዑስ ስርዓት ከ`QUIRE_SECRET_KEY` የሚያወጣውን ቁልፍ ይጠቀማል። ይህ ይሰራል፤ የSystem ጤና ገጽ ግን እንደተቀነሰ ያሳያል። ዋና ቁልፍ ከተቀመጠ በኋላም ውሂቡ ሊነበብ ይችላል፤ የመጀመሪያው ማሽከርከር ሁሉንም ከዚያ ቁልፍ የሚያወጣበት ዘዴ ይህ ነው። የሂደቱን environment ማንበብ የሚችል ማንም የተቀመጡትን ምስክርነቶች ሊፈታ ይችላል፤ ስለዚህ በምርት አካባቢ ዋና ቁልፉ በሚስጥር ማከማቻ ውስጥ መሆንና ከውሂብ ጎታ ምትኬ ጋር አለመቀመጥ አለበት።

## ማሽከርከር <!--quire:rotating-->

የቁልፉ ዕድሜ በPlatform console፣ Security፣ Master key ላይ እና በ`quire.secrets.master_key.age` ሜትሪክ (ቀናት) ይታያል። ዕለታዊው `platform.key_age` መርሐግብር ቁልፉ 365 ቀን ሲሞላ በplatform audit ሰንሰለት ላይ ማስታወሻ ይጽፋል፣ ከዚያም እስኪሽከረከር ድረስ በየ30 ቀኑ ይደግማል። በማስታወሻው ላይና ቁልፉ ሊጋለጥ በሚችልበት ጊዜ ያሽከርክሩ።

1. አዲሱን ቁልፍ ያመንጩ፦ `openssl rand -base64 32`።
2. `QUIRE_MASTER_KEY`ን ወደ አዲሱ ቁልፍ፣ `QUIRE_MASTER_KEY_VERSION`ንም ወደ ቀጣዩ ምልክት (`v2`) ያቀናብሩ። አሮጌውን ቁልፍ በ`QUIRE_MASTER_KEY_RETIRED` ውስጥ እንደ `v1=<old base64>` ያስቀምጡ። ሁለቱንም ቁልፎች ከዚህ አገልጋይ በተለየ ቦታ ያቆዩ።
3. የድር ክፍሉንና workerን በአዲሶቹ ቅንብሮች ያሰማሩ። አዲስ ሚስጥሮች በ`env:QUIRE_MASTER_KEY:v2` ይጠቀለላሉ፤ አሮጌዎቹ አሁንም በተወገደው ቁልፍ ሊከፈቱ ይችላሉ።
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` መርሐግብር በየደቂቃው አንድ ክፍል እንደገና ይጠቀልላል፣ ከዳግም ማስነሳትም ይቀጥላል። በአንድ ጊዜ ለማጠናቀቅ፦ `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`)። የመቆጣጠሪያ ውሂብ ጎታ ማከማቻዎች በዚያው ውሂብ ጎታ ውስጥ ይመረመራሉ፤ የድርጅት ማከማቻዎች ግን በድርጅት አንድ በአንድ፣ row-level security ስር፣ ድርጅቱ ባለበት ውሂብ ጎታ ውስጥ ይከናወናሉ፤ በተለየ ውሂብ ጎታ ላይ የተመደበ ተከራይም በዚያው ይሽከረከራል። ስኪማው በዝርዝሩ ያልተጠቀሰ የታሸገ ቁልፍ አምድ ካከለ ሙከራ ይወድቃል፤ የምስክርነት ግምገማውም የተዘለለ የታሸገ አምድ ካገኘ ሌላ ሙከራ ይወድቃል።

### መዝገቡ <!--quire:the-record-->

- `ops.key_rotation`፦ በእያንዳንዱ ማሽከርከር ምክንያቱን፣ የጠየቀውን ሰው፣ ሁኔታውንና ድምሮቹን (እንደገና የተጠቀለሉ፣ አሁኑኑ ያሉ፣ ያልተፈቱ፣ የወደቁ) የያዘ አንድ ረድፍ።
- `ops.key_rotation_progress`፦ አንድ ማከማቻና ወሰን ከተመረመሩ በኋላ አንድ ረድፍ፤ ሊነበቡ ያልቻሉ የቁልፍ ማጣቀሻዎችንና በእያንዳንዱ ስር የነበሩ እሴቶችን ብዛት ይይዛል። የቀጠለ ማሽከርከር እነዚህን ይዘላል።
- Platform audit chain፦ `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-->

የፊርማ ቁልፎች ከዋና ቁልፉ የተለዩ ናቸው። እያንዳንዱ ድርጅት የOpenID Connect ቶከኖቹንና የLTI መልዕክቶቹን በራሱ RSA ቁልፍ ይፈርማል፤ ቁልፉም በ`/.well-known/jwks.json` ይታተማል። ኦፕሬተር ምንም ማድረግ አያስፈልገውም። የሰዓት መርሐግብር `platform.signing_keys` የአሁኑ ቁልፍ 90 ቀን ከመሙላቱ ሰባት ቀን በፊት ተተኪ ቁልፍ ያትማል። ከሳምንት በኋላ ተተኪው መፈረም ይጀምራል፣ አሮጌውም ወደ ጡረታ ይገባል፤ ከ90 ቀን በኋላ አሮጌው ይሰረዛልና ከቁልፍ ስብስቡ ይወገዳል። እያንዳንዱ ደረጃ በplatform audit chain ውስጥ `platform/signing_key_advance` ይመዘገባል።

የድርጅት ቁልፍን ቀድሞ ለመተካት፣ ለምሳሌ ከተጋለጠ፦

- በconsole፦ Security፣ Master key፣ Publish a new signing key (የ`platform/keys_manage` ፈቃድ ያስፈልጋል)፤ ወይም
- በworker አካባቢ ካለ shell ላይ `bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310"` ያስኪዱ። `bun run kek:rotate signing-keys status` የድርጅቶቹን ቁልፎች በደረጃቸው ያሳያል።

አዲሱ ቁልፍ ወዲያውኑ ይታተማል፣ ከሰባት ቀን በኋላም መፈረም ይጀምራል፣ የአሁኑ ቁልፍም በዚያን ጊዜ ወደ ጡረታ ይገባል። ይህ የሳምንት ጊዜ ሆን ተብሎ ተቀምጧል፤ ተቀባይ አካላት የቁልፍ ስብስቡን cache ውስጥ ያቆያሉ፣ አጭር መደራረብ ሁሉንም መሣሪያዎች በአንድ ጊዜ ያቋርጣል። የጡረታ ቁልፉ የፈረማቸው ቶከኖች እንዲረጋገጡ በስብስቡ ውስጥ ተጨማሪ 90 ቀን ይቆያል። መጋለጡ ከዚያ በፊት እንዳይታመን ካስፈለገ ረድፉን በኦፕሬተሩ የራሱ የውሂብ ጎታ መዳረሻ በለውጥ መዝገብ መሠረት ይሰርዙ (break-glass መዳረሻ ለማንበብ ብቻ ነው)፤ በእሱ የተፈረሙ ቶከኖች ከዚያ በኋላ ማረጋገጫ አያልፉም። የግድ ማሽከርከሩ ምክንያቱን ጨምሮ በaudit chain ውስጥ `platform/signing_key_rotate` ይመዘገባል። አዲሱን ቁልፍ ለመጠቅለል worker ከድር ክፍሉ ጋር ተመሳሳይ `QUIRE_MASTER_KEY` ቅንብሮች ይፈልጋል። ዋና ቁልፉን የሚያሽከረክረው `bun run kek:rotate` ትእዛዝ የፊርማ ቁልፎችንም ከሁሉም ጋር ይጠቀልላል (`oauth_signing_key` በ`SEALED_STORES` ውስጥ ነው)።

## የምርት አካባቢ የአደጋ ጊዜ መዳረሻ <!--quire:break-glass-production-access-->

ማንም ሰው በምርት አካባቢ ቋሚ መዳረሻ የለውም። ጉዳዩ መጠበቅ በማይችልበት ጊዜ ባለቤት የአደጋ ጊዜ ፈቃድ ይሰጣል፦ Platform console፣ Security፣ Break-glass access።

- ፈቃዱ ወሰን አለው (አንድ ድርጅት ወይም platform registry)፣ አደጋውን ወይም ቲኬቱን በሚጠራ ቢያንስ 20 ቁምፊ ያለው ምክንያት፣ እና ከ5 እስከ 240 ደቂቃ የሚቆይ ጊዜ። በራሱ ያበቃል፤ እያንዳንዱ መግለጫ ሲፈጸም ሰዓቱ ይፈተሻል።
- ለፈቃዱን ለሰጠው ባለቤት ወይም ለሌላ ባለቤት (የሁለት ሰው ሂደት) ሊሰጥ ይችላል። የተሰጠው ሰው ብቻ ሊጠቀምበት ይችላል። መስጠት `platform/break_glass_issue`፣ መጠቀምም `platform/break_glass_use` ይፈልጋል፤ በነባሪ ሁለቱም ለባለቤቶች ብቻ ናቸው።
- መግለጫዎች በውሂብ ጎታ መግቢያ ሳይሆን በgateway ይሄዳሉ፤ ለማንበብ ብቻ፣ አንድ በአንድ፣ በድርጅቱ ወይም በመቆጣጠሪያ መዝገቡ ውስጥ ብቻ፣ ከፍተኛው 5 ሰከንድና 500 ረድፎች። ሁለትዮሽ እሴቶች በመጠናቸው ይታያሉ።
- Platform audit chain ፈቃዱን መስጠት (ምክንያቱን ጨምሮ)፣ መሻር፣ ከመፈጸሙ በፊት እያንዳንዱን መግለጫ (`platform/break_glass_statement`፣ የተከለከሉት ከውጤት `denied` ጋር) እና እያንዳንዱን ውጤት (`platform/break_glass_result`) ይመዘግባል። `ops.break_glass_statement` የaudit መዝገቦችን መለያዎች ይይዛል፤ የፈቃድ መዝገቡም ከእነዚያ ጋር ሊገናኝ ይችላል።
- ጽሁፍ ማድረግ አይፈቀድም። እስከሚቀጥለው ልቀት መጠበቅ የማይችል ለውጥ በኦፕሬተሩ የራሱ የውሂብ ጎታ መዳረሻ ስር፣ ከዚህ ምርት ውጭ ባለው የለውጥ መዝገብ ይከናወናል። መዝገቡ እዚህ የተጠቀሰውን የአደጋ መለያ መጥቀስ አለበት።

ለምን የውሂብ ጎታ ምስክርነት አንሰጥም፦ የPostgres መግቢያ ክፍለ ጊዜው ከጠየቀው በላይ ይቆያል፣ መተግበሪያው የሚመረኮዝበትን row-level security ያልፋል፣ በዚህ ምርት የaudit ሰንሰለት ላይም መጻፍ አይችልም፤ ስለዚህ መግለጫዎቹ የአገልጋይ ሎግ እስኪላክ ድረስ ብቻ ይመዘገባሉ። Gateway ኦዲት መኖሩን በመዳረሻው ራሱ ያረጋግጣል።

የኦዲት ጥያቄን ለመመለስ፦ በወቅቱ የተሰጡትን ፈቃዶች በBreak-glass access ይዘርዝሩ፤ የፈቃዱን ታሪክ የመግለጫዎቹንና የaudit መዝገቦቹን መለያዎች ለማየት ይክፈቱ፤ ከዚያ በplatform audit chain ላይ እነዚያን መዝገቦች ያንብቡ (`bun run audit:verify --platform` ሰንሰለቱ እንዳልተነካ ያረጋግጣል)።

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