---
title: "ການປ່ຽນ master key ແລະ ກະແຈລາຍລານື້, ແລະ ການເຂົ້າເຖິງແບບ break-glass"
description: "ປ່ຽນ master key ທີ່ປ້ອງກັນລະຫັດເຂົ້າເຖິງທີ່ເກັບໄວ້ ແລະ ໃຊ້ການເຂົ້າເຖິງແບບ break-glass."
image: "https://docs.quirelms.com/og.png"
---

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

# ການປ່ຽນ master key ແລະ ກະແຈລາຍລານື້, ແລະ ການເຂົ້າເຖິງແບບ break-glass

<span id="master-key-and-signing-key-rotation-and-break-glass-access"></span>

ການຄວບຄຸມໃນ 21-compliance.md ບົດທີ 14 ທີ່ຜູ້ກວດກາຖາມດ້ວຍຊື່.
ໜ້ານີ້ແມ່ນຂັ້ນຕອນ; ບັນທຶກທີ່ມັນຜະລິດແມ່ນຫຼັກຖານ.

## ກະແຈຕ່າງໆ <!--quire:the-keys-->

ລະຫັດເຂົ້າເຖິງທຸກໆອັນທີ່ເກັບໄວ້ຖືກຜະໜວກດ້ວຍກະແຈເຂົ້າ
ລະຫັດຂໍ້ມູນທີ່ສ້າງໃໝ່ (DEK). DEK ຖືກຫຸ້ມດ້ວຍ master key (KEK)
ແລະ ການອ້າງອີງຂອງ master key ຖືກເກັບຢູ່ຂ້າງມັນ (`key_ref`,
ຫຼື ການອ້າງອີງພາຍໃນຄ່າທີ່ຖືກຫຸ້ມ). ການປ່ຽນ master key
ຫຸ້ມ DEK ຄືນ. ມັນບໍ່ເຄີຍຖອກລະຫັດ ຫຼື ແອບລະຫັດຄືນ
ລະຫັດເຂົ້າເຖິງໃດໆ.

| ການຕັ້ງຄ່າ | ຄວາມໝາຍ |
| --- | --- |
| `QUIRE_MASTER_KEY` | 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` ແຕ່ລະ subsystem ຮັກສາກະແຈທີ່ມັນ
ສະແດງອອກຈາກ `QUIRE_SECRET_KEY`. ມັນເຮັດວຽກ, ໜ້າສຸຂະພາບ
ລະບົບສະແດງມັນເປັນ degraded, ແລະ ມັນຍັງອ່ານໄດ້ຫຼັງຈາກ
ທ່ານຕັ້ງ master key, ເຊິ່ງແມ່ນວິທີທີ່ການປ່ຽນຄັ້ງທຳອິດ
ຍ້າຍທຸກສິ່ງອອກຈາກມັນ. ໃຜກໍ່ທີ່ສາມາດອ່ານສະພາບແວດລ້ອມ
ຂອງຂະບວນການສາມາດຖອກລະຫັດລະຫັດເຂົ້າເຖິງທຸກໆອັນທີ່
ເກັບໄວ້ ດັ່ງນັ້ນການຕິດຕັ້ງການຜະລິດຄວນມີ master key,
ເກັບໄວ້ໃນຮ້ານຄວາມລັບ ແລະບໍ່ຢູ່ໃນ backup ດຽວກັນກັບ
ຖານຂໍ້ມູນ.

## ການປ່ຽນ <!--quire:rotating-->

ອາຍຸຂອງກະແຈສະແດງຢູ່ Platform console, Security, Master key, ແລະ
ເປັນ metric `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. ສົ່ງຊັ້ນເວັບ ແລະ worker ດ້ວຍການຕັ້ງຄ່າໃໝ່. ຄວາມລັບໃໝ່
   ຕອນນີ້ຖືກຫຸ້ມໄວ້ພາຍໃຕ້ `env:QUIRE_MASTER_KEY:v2`; ອັນເກົ່າ
   ຍັງເປີດຜ່ານກະແຈທີ່ຫຍັກລົບແລ້ວ.
4. ຂໍການປ່ຽນ, ພ້ອມເຫດຜົນທີ່ຈະຢູ່ໃນເສັ້ນການກວດກາ:
   - ໃນ console: Security, Master key, Rotate the master key; ຫຼື
   - ໃນ shell ທີ່ມີສະພາບແວດລ້ອມດຽວກັນ: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker ຫຸ້ມສ່ວນໜຶ່ງຕໍ່ນາທີ (ຕາຕະລາປັບ `platform.key_rotation`
   ຂອງ scheduler) ແລະ ສືບຕໍ່ຫຼັງການເລີ່ມລະບົບຄືນ. ເພື່ອ
   ສຳເລັດມັນໃນການນັ່ງດຽວ: `bun run kek:rotate run`. ຕິດຕາມມັນ
   ດ້ວຍ `bun run kek:rotate status`.
6. ເມື່ອບັນທຶກສະແດງວ່າການປ່ຽນສຳເລັດພ້ອມ **zero unresolved and
   zero failed**, ລຶບກະແຈທີ່ຫຍັກລົບອອກຈາກ
   `QUIRE_MASTER_KEY_RETIRED` ແລະ ສົ່ງຄືນ. ຈົນຮອດເວລານັ້ນ
   ຮັກສາມັນໄວ້: ຄ່າທີ່ມັນຍ້າຍບໍ່ໄດ້ຍັງຖືກຫຸ້ມໄວ້ພາຍໃຕ້
   ກະແຈເກົ່າ.

### ສິ່ງທີ່ງານນີ້ກວດເບິ່ງ <!--quire:what-the-job-walks-->

ຮ້ານເກັບທຸກໆແຫ່ງທີ່ຖືກຫຸ້ມ DEK: ອັນທີ່ຢູ່ໃນ `SEALED_STORES`
(`apps/worker/src/key-rotation.ts`). ຮ້ານເກັບຂອງຖານຂໍ້ມູນ
ຄວບຄຸມຖືກກວດເບິ່ງເທິງຖານຂໍ້ມູນຄວບຄຸມ; ຮ້ານເກັບຂອງ
ອົງການຖືກກວດເບິ່ງອົງການໜຶ່ງຄັ້ງພາຍໃຕ້ການປ້ອງກັນຂັ້ນ
ແຖວ, ໃນຖານຂໍ້ມູນໃດກໍ່ທີ່ຖືກອົງການນັ້ນ, ດັ່ງນັ້ນ tenant
ທີ່ຖືກຜູກກັບຖານຂໍ້ມູນສະເພາະຈະຖືກປ່ຽນໃນຖານຂໍ້ມູນນັ້ນ.
ການທົດສອບລົ້ມເມື່ອ schema ໄດ້ຖານກະແຈທີ່ຫຸ້ມເພີ່ມເຂົ້າມາ
ທີ່ລາຍຊື່ບໍ່ລະບຸຊື່, ແລະອີກອັນໜຶ່ງເມື່ອການທວດສອບ
ລະຫັດເຂົ້າເຖິງຈັດປະເພດຖານທີ່ຜະໜວກທີ່ລາຍຊື່ພາດ.

### ບັນທຶກ <!--quire:the-record-->

- `ops.key_rotation`: ແຖວໜຶ່ງຕໍ່ການປ່ຽນ, ພ້ອມເຫດຜົນຂອງມັນ,
  ໃຜຂໍມັນ, ສະຖານະຂອງມັນ ແລະ ລວມທັງໝົດຂອງມັນ (ຫຸ້ມຄືນ,
  ປັດຈຸບັນຢູ່ແລ້ວ, ບໍ່ສຳເລັດ, ລົ້ມແຫຼວ).
- `ops.key_rotation_progress`: ແຖວໜຶ່ງຕໍ່ຮ້ານເກັບ ແລະ scope ໜຶ່ງ
  ຄັ້ງທີ່ກວດແລ້ວ, ພ້ອມການອ້າງອີງກະແຈທີ່ມັນບໍ່ສາມາດອ່ານ
  ໄດ້ ແລະ ມີຈຳນວນຄ່ານັ່ງໃດຢູ່ພາຍໃຕ້ແຕ່ລະອັນ. ການປ່ຽນ
  ທີ່ສືບຕໍ່ຂ້າມສິ່ງເຫຼົ່ານີ້.
- ເສັ້ນການກວດກາຂອງເພລຟອມ: `platform/key_rotation_request`
  (ພ້ອມເຫດຜົນ), `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` (ຄ່າທີ່ການປ່ຽນຄັ້ງສຸດທ້າຍ
  ຍ້າຍບໍ່ໄດ້).

### ເມື່ອຄ່າບໍ່ສຳເລັດ <!--quire:when-values-are-unresolved-->

ຄ່າທີ່ບໍ່ສຳເລັດແມ່ນຄ່າທີ່ຖືກຫຸ້ມພາຍໃຕ້ການອ້າງອີງກະແຈ
ທີ່ການຕິດຕັ້ງນີ້ບໍ່ຖືກໄວ້, ຫຼືບໍ່ຢູ່ໃນຮູບແບບທີ່ຖານຂອງ
ມັນສັນຍາໄວ້. ບັນທຶກຄວາມຄືບໜ້າລະບຸການອ້າງອີງ (ຕົວຢ່າງ
`env:QUIRE_MASTER_KEY:v0 (unreadable)`). ກູ້ກະແຈນັ້ນຄືນເຂົ້າ
`QUIRE_MASTER_KEY_RETIRED` ແລະ ແລ່ນການປ່ຽນອີກຄັ້ງ, ຫຼື, ຖ້າ
ກະແຈຫາຍໄປຖາວ, ໃຫ້ຜູ້ບໍລິຫານຂອງອົງການນັ້ນໃສ່ລະຫັດ
ເຂົ້າເຖິງຄືນ: ມັນຈາກນັ້ນຖືກຜະໜວກພາຍໃຕ້ກະແຈປະຈຸບັນ.
ການປ່ຽນທີ່ລົ້ມແຫຼວສະແດງຂໍ້ຜິດພາດຂອງພວກມັນຢູ່ໃນ
ບັນທຶກ; ແກ້ເຫດຜົນ ແລະ ຂໍອີກຄັ້ງ.

## ກະແຈລາຍລານື້ <!--quire:signing-keys-->

ແຍກອອກຈາກ master key: ແຕ່ລະອົງການລາຍລານື້ OpenID Connect
tokens ແລະ ຂໍ້ຄວາມ LTI ຂອງຕົນດ້ວຍກະແຈ RSA ເອງ, ເຜີຍແຜ່
ຢູ່ `/.well-known/jwks.json`. ບໍ່ມີຫຍັງທີ່ນີ້ຕ້ອງການຜູ້ດຳເນີນ
ການ. ຕາຕະລາປັບລຳດັບຊົ່ວໂມງ `platform.signing_keys` ເຜີຍ
ແຜ່ຜູ້ສືບທອດເຈົ້າ 7 ມື້ກ່ອນທີ່ 90 ມື້ຂອງກະແຈປະຈຸບັນຈະ
ໝົດ, ໜຶ່ງອາທິດຕໍ່ມາຜູ້ສືບທອດເລີ່ມລາຍລານື້ ແລະ ກະແຈ
ເກົ່າກາຍເປັນກະແຈລຳລັບການປ່ຽນ, ແລະ 90 ມື້ຫຼັງຈາກ
ນັ້ນກະແຈເກົ່າຖືກລຶບ ແລະ ອອກຈາກຊຸດກະແຈ. ທຸກຂັ້ນຕອນ
ແມ່ນລາຍການ `platform/signing_key_advance` ໃນເສັ້ນການກວດກາ
ຂອງເພລຟອມ.

ເພື່ອແທນກະແຈຂອງອົງການກ່ອນເວລາ, ຕົວຢ່າງຫຼັງຈາກການ
ເປີດເຜີຍ:

- ໃນ console: Security, Master key, Publish a new signing key (ຕ້ອງການ
  `platform/keys_manage`); ຫຼື
- ໃນ shell ທີ່ມີສະພາບແວດລ້ອມຂອງ worker: `bun run kek:rotate signing-keys rotate
  --tenant <slug or id> --reason "Key exposed, INC-3310"`. `bun run kek:rotate
  signing-keys status` ລາຍຊື່ກະແຈຂອງແຕ່ລະອົງການຕາມຂັ້ນຕອນ.

ກະແຈໃໝ່ຖືກເຜີຍແຜ່ທັນທີ ແລະ ເລີ່ມລາຍລານື້ຫຼັງ 7 ມື້,
ເມື່ອກະແຈປະຈຸບັນປ່ຽນ. ໜຶ່ງອາທິດແມ່ນການຕັ້ງໃຈ: relying
parties ເກັບຊຸດກະແຈໄວ້ໃນ cache, ແລະຊ່ວງທີ່ທັບກັນສັ້ນ
ກວ່າຈະເຮັດໃຫ້ເຄື່ອງມືທຸກໆອັນລົ້ມແຫຼວທັນທີ. ກະແຈທີ່
ກຳລັງປ່ຽນຢູ່ໃນຊຸດກະແຈຕໍ່ອີກ 90 ມື້ເພື່ອໃຫ້ tokens ທີ່ມັນ
ລາຍລານື້ແລ້ວສືບຕໍ່ຜ່ານການກວດສອບ; ຖ້າການເປີດເຜີຍໝາຍ
ຄວາມວ່າມັນຕ້ອງຢຸດການໄວ້ເຊື່ອຖືໄວ້ໄວ້ກວ່ານັ້ນ ການລຶບ
ແຖວຂອງມັນເປັນການປ່ຽນແປງທີ່ເຮັດດ້ວຍການເຂົ້າເຖິງຖານ
ຂໍ້ມູນຂອງຜູ້ດຳເນີນການເອງພາຍໃຕ້ບັນທຶກການປ່ຽນແປງ
(ການເຂົ້າເຖິງແບບ break-glass ເປັນແຕ່ອ່ານ), ແລະ tokens ທີ່
ລາຍລານື້ດ້ວຍມັນຈາກນັ້ນລົ້ມການກວດສອບ. ການປ່ຽນທີ່ບັງ
ຄັບແມ່ນ `platform/signing_key_rotate` ໃນເສັ້ນການກວດກາ, ພ້ອມ
ເຫດຜົນ. Worker ຕ້ອງການການຕັ້ງຄ່າ `QUIRE_MASTER_KEY` ດຽວກັນ
ກັບຊັ້ນເວັບເພື່ອຫຸ້ມກະແຈໃໝ່; `bun run kek:rotate` ສຳລັບ master
key ຫຸ້ມກະແຈລາຍລານື້ຄືນພ້ອມສິ່ງອື່ນທັງໝົດ
(`oauth_signing_key` ຢູ່ໃນ `SEALED_STORES`).

## ການເຂົ້າເຖິງ production ແບບ break-glass <!--quire:break-glass-production-access-->

ບໍ່ມີໃຜຖືການເຂົ້າເຖິງຖາວອນກັບ production. ເມື່ອສິ່ງໃດບໍ່
ສາມາດລໍຖ້າໄດ້ ເຈົ້າຂອງອອກການອະນຸມັດແບບ break-glass:
Platform console, Security, Break-glass access.

- ການອະນຸມັດມີ scope (ອົງການໜຶ່ງ, ຫຼື platform registry),
  ເຫດຜົນຢ່າງໜ້ອຍ 20 ຕົວອັກສອນທີ່ລະບຸເຫດການ ຫຼື
  ເທິກເກັດ ແລະຊ່ວງເວລາ 5 ຫາ 240 ນາທີ. ມັນໝົດອາຍຸ
  ໂດຍຕົນເອງ: ມັນຖືກກວດສອບທຽບກັບເວລາໃນທຸກຖາອ້າງ.
- ມັນສາມາດອອກໃຫ້ເຈົ້າຂອງຜູ້ທີ່ອອກມັນ, ຫຼືໃຫ້ເຈົ້າ
  ອື່ນ (ຮູບແບບສອງຄົນ). ແຕ່ຄົນທີ່ມັນຖືກອອກໃຫ້ເທົ່າ
  ນັ້ນທີ່ສາມາດໃຊ້ມັນ. ການອອກຕ້ອງການ
  `platform/break_glass_issue` ແລະການໃຊ້ຕ້ອງການ
  `platform/break_glass_use`; ທັງສອງເປັນເຈົ້າຂອງເທົ່ານັ້ນ
  ໂດຍຄ່າເລີ່ມຕົ້ນ.
- ຖາອ້າງແລ່ນຜ່ານ gateway, ບໍ່ແມ່ນການເຂົ້າສູ່ຖານຂໍ້ມູນ:
  ແຕ່ອ່ານ, ທີ່ລະຄັ້ງ, ຖືກຈຳກັດໄວ້ຕໍ່ອົງການ ຫຼື platform
  registry, ພ້ອມ timeout 5 ວິນາທີ ແລະສູງສຸດ 500 ແຖວ.
  ຄ່າ binary ຖືກສະແດງຕາມຂະໜາດ.
- ເສັ້ນການກວດກາຂອງເພລຟອມບັນທຶກການອອກ (ພ້ອມເຫດ
  ຜົນ), ການຍົກເລີກ, ຖາອ້າງທຸກໆອັນກ່ອນທີ່ຈະແລ່ນ
  (`platform/break_glass_statement`, ອັນທີ່ຖືກປະຕິເສດພ້ອມ
  outcome `denied`) ແລະຜົນລັບທຸກໆອັນ
  (`platform/break_glass_result`). `ops.break_glass_statement`
  ເກັບ ids ຂອງລາຍການການກວດກາ ດັ່ງນັ້ນບັນທຶກການອອກ
  ຕິດກັບລາຍການການກວດກາຂອງມັນ.
- ການຂຽນບໍ່ຖືກສະເໜີ. ການປ່ຽນແປງທີ່ບໍ່ສາມາດລໍຖ້າ
  ສະບັບເຜີຍແຜ່ໃຊ້ການເຂົ້າເຖິງຖານຂໍ້ມູນຂອງຜູ້ດຳເນີນ
  ການເອງພາຍໃຕ້ບັນທຶກການປ່ຽນແປງຂອງຕົນ, ນອກເໜືອ
  ຜະລິດຕະພັນນີ້, ແລະບັນທຶກຄວນອ້າງເຫດການອ້າງອີງ
  ທີ່ໃຊ້ຢູ່ທີ່ນີ້.

ເຫດຜົນທີ່ບໍ່ອອກລະຫັດເຂົ້າຖານຂໍ້ມູນ: ການເຂົ້າສູ່ Postgres
ມີຊີວິດຍາວກວ່າເຊັນຊັນທີ່ຂໍມັນ, ຂ້າມການປ້ອງກັນຂັ້ນ
ແຖວທີ່ແອັບພັກພັງພາຢູ່, ແລະບໍ່ສາມາດຂຽນເຂົ້າເສັ້ນ
ການກວດກາຂອງຜະລິດຕະພັນນີ້ ດັ່ງນັ້ນຖາອ້າງຂອງມັນ
ຈະຖືກກວດກາແຕ່ເທົ່າທີ່ຄົນໄດ້ສົ່ງບັນທຶກເຊີບເວີອອກ.
Gateway ເຮັດໃຫ້ເສັ້ນການກວດກາກາຍເປັນຄຸນສົມບັດຂອງ
ການເຂົ້າເຖິງແທນທີ່ຈະເປັນການປະພຶດອ້ອມມັນ.

ເພື່ອຕອບຄຳຂໍການກວດກາ: ລາຍຊື່ການອະນຸມັດໃນໄລຍະເວລາ
(Break-glass access), ເປີດປະຫວັດຂອງການອະນຸມັດໜຶ່ງເພື່ອ
ຖາອ້າງ ແລະ ids ຂອງລາຍການການກວດກາ, ແລະອ່ານລາຍການ
ເຫຼົ່ານັ້ນເທິງເສັ້ນການກວດກາຂອງເພລຟອມ
(`bun run audit:verify --platform` ພິສູດວ່າເສັ້ນຄົບຖ້ວນ).

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