---
title: "Мастер-кілт пен қол қою кілтін ауыстыру, сондай-ақ break-glass қолжетімділігі"
description: "Сақталған кілттерді қорғайтын мастер-кілтті ауыстырыңыз және break-glass қолжетімділігін пайдаланыңыз."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/kk/llms.txt
> Use this file to discover all available pages before exploring further.

# Мастер-кілт пен қол қою кілтін ауыстыру, сондай-ақ break-glass қолжетімділігі

<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 health
беті оны degraded көрсетеді, және сіз мастер-кілт орнатқаннан кейін
оқыла береді — алғашқы ауыстыру бәрін осыдан ауыстыратын да осы.
Процесс ортасын оқи алатын кез келген адам әр сақталған кілтті аша
алады, сондықтан өндірістік орнатылымда мастер-кілт болуы керек —
оны құпиялар қоймасында ұстаңыз және дерекқормен бір сақтық
көшірмеде емес.

## Ауыстыру <!--quire:rotating-->

Кілт жасы Platform console, Security, Master key бөлімінде және
`quire.secrets.master_key.age` метрикасы (күндер) түрінде көрінеді.
Күнделікті `platform.key_age` кестесі (03:41 UTC) кілт 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. Аудит тізбегінде тұратын себебімен бірге ауыстыруға сұраныс
   жіберіңіз:
   - консольде: Security, Master key, Rotate the master key; немесе
   - сол ортасы бар shell-де: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker минутына бір бөлігін қайта орап отырады (scheduler-дің
   `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`). Басқару дерекқорының
қоймалары басқару дерекқорында араланады; ұйым қоймалары ұйым
қай дерекқорда болса, сол дерекқорда, жол деңгейіндегі қауіпсіздік
астында бір ұйымнан бір ұйым араланады, сондықтан жеке дерекқорға
бекітілген tenant сол дерекқорда ауыстырылады. Схема тізім
атамайтын оралған кілт бағанын алғанда тест сәтсіз болады, және
тағы біреуі — қілттерді қарау тізімнен өткізген мөрленген бағанды
жіберіп алғанда.

### Жазба <!--quire:the-record-->

- `ops.key_rotation`: әр ауыстыруға бір жол, оның себебі, кім
  сұрағаны, күйі және жиынтықтары (қайта оралған, әлі ағымдағы,
  шешілмеген, сәтсіз).
- `ops.key_rotation_progress`: араланғаннан кейін әр қойма мен
  ауқымға бір жол, оқи алмаған кілт сілтемелерімен және әрқайсысында
  неше мән тұрғанымен. Жалғасқан ауыстырулар мұны аттап өтеді.
- Platform audit тізбегі: `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-->

Мастер-кілттен бөлек: әр ұйым өзінің RSA кілтімен OpenID Connect
токендеріне және LTI хабарламаларына қол қояды, ол `/.well-known/jwks.json`
мекенжайында жарияланады. Мұнда оператор қажет емес. Сағаттық
`platform.signing_keys` кестесі ағымдағы кілттің тоқсан күні
бітпей тұрып жеті күн бұрын ізбасарды жариялайды, бір аптадан кейін
ізбасар қол қоюды бастайды және ескі кілт retiring күйіне өтеді, одан
кейін тоқсан күннен соң ескі кілт жойылып, кілттер жиынтығынан
кетеді. әр қадам platform audit тізбегіндегі
`platform/signing_key_advance` жазбасы.

Ұйым кілтін мерзімінен бұрын ауыстыру үшін, мысалы ұшырағаннан кейін:

- консольде: 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` әр ұйымның кілттерін сатысы бойынша тізеді.

Жаңа кілт бірден жарияланады және жеті күннен кейін, ағымдағы кілт
зейнетке шыққанда, қол қоюды бастайды. Апта ойластырылған: сенім
әріптестері кілттер жиынтығын кэштейді, ал қысқарақ қабаттасу барлық
құралды бірден сәтсіз етеді. Зейнетке шыққан кілт тағы тоқсан күн
кілттер жиынтығында қалады, сондықтан ол қол қойған токендер әлі
расталып отырады; ұшырау оны ертерек сенімсіз деп тануды талап
ететін болса, жолын жою — өзгеріс жазбасының астында оператордың
өз дерекқор қолжетімділігімен жасалады (break-glass қолжетімділігі
тек оқуға арналған), және онымен қол қойылған токендер содан кейін
расталудан өтпейді. Мәжбүрлі ауыстыру аудит тізбегіндегі
`platform/signing_key_rotate` болып, себебімен бірге тізіледі.
Worker жаңа кілтті орау үшін веб-деңгейдегідей сол
`QUIRE_MASTER_KEY` параметрлерін қажет етеді; мастер-кілт үшін
`bun run kek:rotate` басқа бәрімен бірге қол қою кілттерін де қайта
орайды (`oauth_signing_key` `SEALED_STORES` ішінде).

## Өндірістік break-glass қолжетімділігі <!--quire:break-glass-production-access-->

Ешкім өндіріске тұрақты қолжетімділік ұстамайды. Бірде күте
алмайтын кезде иеленуші break-glass рұқсатын береді: Platform
console, Security, Break-glass access.

- Рұқсаттың ауқымы бар (бір ұйым немесе платформа реестрі), оқиға
  немесе тикетті атайтын кемінде 20 таңбалы себеп және 5-тен 240
  минутқа дейінгі терезе. Ол өзінен-өзі жарамсыз болады: әр
  операцияда сағатпен тексеріледі.
- Ол берілетін иеленушіге немесе басқа иеленушіге берілуі мүмкін
  (екі адамдық түрі). Оған берілген адам ғана пайдалана алады.
  Беру үшін `platform/break_glass_issue`, пайдалану үшін
  `platform/break_glass_use` қажет; екеуі әдепкіде тек иеленушіге.
- Операциялар дерекқор кіруінен емес, шлюз арқылы орындалады: тек
  оқу, бір-бірден, ұйымға немесе басқару реестріне шектелген, бес
  секундтық уақыт шегімен және кемінде 500 жолмен. Бинарлық мәндер
  өлшемімен көрсетіледі.
- Platform audit тізбегі берілуді (себебімен бірге), қайтарылуын,
  орындалғанға дейінгі әр операцияны (`platform/break_glass_statement`,
  қабылданбағандары `denied` нәтижесімен) және әр нәтижені
  (`platform/break_glass_result`) жазады.
  `ops.break_glass_statement` аудит жазба id-лерін ұстайды, сондықтан
  берілу жазбасы аудит жазбаларына қосылады.
- Жазу ұсынылмайды. Шығарылымды күте алмайтын өзгеріс өзгеріс
  жазбасының астында өзінің дерекқор қолжетімділігін пайдаланады,
  бұл өнімнің сыртында, ал жазба осы жерде қолданылған оқиға
  сілтемесіне сілтеуі керек.

Неге дерекқор кілттерін бермейміз: Postgres кіруі сұраған сессиядан
ұзақ өмір сүреді, қолданба сүйенетін қатар қатарлы қауіпсіздікті
бұзады және бұл өнімнің аудит тізбегіне жаза алмайды, сондықтан
оның операциялары тек біреу сервер журналын жібергенге дейін ғана
аудиттеледі. Шлюз аудит тізбегін әрекеттің қасындағы емес, оның
өзіне тән қасиет етеді.

Аудит сұранысына жауап беру үшін: кезеңдегі рұқсаттарды тізіңіз
(Break-glass access), рұқсаттың операциялары мен аудит жазба id-лері
үшін тарихын ашыңыз және сол жазбаларды platform audit тізбегінде
оқыңыз (`bun run audit:verify --platform` тізбекті бүтін екенін
дәлелдейді).

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