---
title: "ការបង្វិលសោ master និងសោហត្ថលេខា និងការចូលប្រើបំពេញអាសន្ន"
description: "បង្វិលសោ master ដែលការពារលិខិតសម្គាល់ដែលបានរក្សាទុក ហើយប្រើការចូលប្រើបំពេញអាសន្ន។"
image: "https://docs.quirelms.com/og.png"
---

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

# ការបង្វិលសោ master និងសោហត្ថលេខា និងការចូលប្រើបំពេញអាសន្ន

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

ការគ្រប់គ្រងក្នុង 21-compliance.md ផ្នែក 14 ដែលអ្នកសវនកម្មសុំតាមឈ្មោះ។ ទំព័រនេះជាដំណើរការ។ កំណត់ត្រាដែលវាផលិតជាភស្តុតាង។

## សោទាំងនេះ <!--quire:the-keys-->

លិខិតសម្គាល់ដែលបានរក្សាទុកនីមួយៗត្រូវបានបិទភ្ជិតជាមួយសោអ៊ីនគ្រីបទិន្នន័យថ្មី (DEK)។ DEK ត្រូវបានរុំដោយសោ master (KEK) ហើយយោងនៃសោ master ត្រូវបានរក្សាទុកនៅជាប់វា (`key_ref` ឬយោងខាងក្នុងតម្លៃដែលបានផ្គរ)។ ការបង្វិលសោ master រុំ DEK ឡើងវិញ។ វាមិនដែលឌិគ្រីប ឬអ៊ីនគ្រីបលិខិតសម្គាល់ឡើងវិញទេ។

| ការកំណត់ | អត្ថន័យ |
| --- | --- |
| `QUIRE_MASTER_KEY` | សោ master បច្ចុប្បន្ន៖ 32 បៃ base64។ សំណង់ថ្មីនីមួយៗត្រូវបានរុំក្រោមវា |
| `QUIRE_MASTER_KEY_VERSION` | ស្លាកកំណែរបស់វា។ `v1` នៅពេលមិនបានកំណត់។ បង្កើនវារាល់ពេលអ្នកផ្លាស់ប្តូរសោ |
| `QUIRE_MASTER_KEY_RETIRED` | សោមុនៗដែលបានរក្សាសំណង់អាចនៅតែស្ថិតក្រោម ជា `v1=<base64>,v0=<base64>`។ អាន មិនដែលសរសេរទេ |

ស្រទាប់ web worker និងពាក្យបញ្ជា `bun run kek:rotate` អានការកំណត់ទាំងបីដដែល។ ពួកគេត្រូវតែមានតម្លៃដដែលទាំងអស់ ឬមួយក្នុងចំណោមពួកគេមិនអាចបើកអ្វីដែលមួយផ្សេងបានបិទភ្ជិត។

គ្មាន `QUIRE_MASTER_KEY` ប្រព័ន្ធផ្សេងៗនីមួយៗរក្សាសោដែលវាបង្កើតពី `QUIRE_SECRET_KEY`។ នេះដំណើរការ។ ទំព័រសុខភាពប្រព័ន្ធបង្ហាញវាជាថយចុះ ហើយវានៅតែអាចអានបានបន្ទាប់ពីអ្នកកំណត់សោ master ដែលជារបៀបដែលការបង្វិលដំបូងផ្លាស់ប្តូរអ្វីៗចេញពីវា។ អ្នកណាដែលអាចអានបរិស្ថានដំណើរការអាចឌិគ្រីបលិខិតសម្គាល់ដែលបានរក្សាទុកទាំងអស់ ដូច្នេះការដំឡើងផលិតគួរតែមានសោ master ដែលរក្សាក្នុងហាងសំណង់ ហើយមិននៅក្នុងការបម្រុងទុកដដែលជាមួយមូលដ្ឋានទិន្នន័យ។

## ការបង្វិល <!--quire:rotating-->

អាយុសោបង្ហាញលើ Platform console, Security, Master key ហើយជាម៉ែត្រ `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. ដាក់ស្តារស្រទាប់ web និង 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 រុំចំណុំមួយក្នុងមួយនាទី (កាលវិភាគ `platform.key_rotation` របស់ scheduler) ហើយបន្តបន្ទាប់ពីការចាប់ផ្តើមឡើងវិញ។ ដើម្បីបញ្ចប់វាក្នុងអង្គឯងមួយ៖ `bun run kek:rotate run`។ តាមដានវាជាមួយ `bun run kek:rotate status`។
6. នៅពេលកំណត់ត្រាបង្ហាញថាការបង្វិលបានបញ្ចប់ជាមួយ **zero unresolved និង 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`៖ ជួរមួយក្នុងមួយឃ្លាំង និងវិស័យនៅពេលបានដើរ ជាមួយយោងសោដែលវាមិនអាចអានបាន និងប៉ុន្មានតម្លៃស្ថិតក្រោមនីមួយៗ។ ការបង្វិលដែលបានបន្តរំលងទាំងនេះ។
- ខ្សែសវនកម្មប្រព័ន្ធ៖ `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-->

ដាច់ពីសោ master៖ អង្គការនីមួយៗហត្ថលេខាថូខេន OpenID Connect និងសារ LTI របស់វាជាមួយសោ RSA ផ្ទាល់ ដែលបានផ្សាយនៅ `/.well-known/jwks.json`។ គ្មានអ្វីនៅទីនេះត្រូវការអ្នកប្រតិបត្តិករទេ។ កាលវិភាគរាល់ម៉ោង `platform.signing_keys` ផ្សាយអ្នកបន្តបួនថ្ងៃមុននឹងសោបច្ចុប្បន្ន 90 ថ្ងៃរបស់វាអស់។ មួយសប្តាហ៍ក្រោយមកអ្នកបន្តចាប់ផ្តើមហត្ថលេខា ហើយសោចាស់ក្លាយជាកំពុងដក។ 90 ថ្ងៃបន្ទាប់មកសោចាស់ត្រូវបានលុប ហើយចេញពីបញ្ជីសោ។ ជំហាននីមួយៗជាធាតុ `platform/signing_key_advance` លើខ្សែសវនកម្មប្រព័ន្ធ។

ដើម្បីជំនួសសោរបស់អង្គការមួយមុនពេល ឧទាហរណ៍បន្ទាប់ពីការប៉ះពាល់៖

- ក្នុងកុងសូល៖ 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` រាយសោរបស់អង្គការនីមួយៗតាមដំណាក់ការ។

សោថ្មីត្រូវបានផ្សាយភ្លាមៗ ហើយចាប់ផ្តើមហត្ថលេខាបន្ទាប់ពីបួនថ្ងៃ នៅពេលសោបច្ចុប្បន្នដក។ សប្តាហ៍នេះត្រូវបានគិតពិចារណា៖ ភាគីដែលពឹងផ្អែកផ្ទុកបញ្ជីសោ ហើយគម្លាតខ្លីជាងបរាជ័យឧបករណ៍ទាំងអស់ក្នុងពេលតែមួយ។ សោដែលកំពុងដកនៅតែស្ថិតក្នុងបញ្ជីសោ 90 ថ្ងៃបន្ថែមទៀត ដូច្នេះថូខេនដែលវាបានហត្ថលេខារួចនៅតែផ្ទៀងផ្ទាត់បាន។ បើការប៉ះពាល់មានន័យថាវាត្រូវឈប់ទទួលទុកចិត្តមុនពេល ការលុបជួររបស់វាជាការផ្លាស់ប្តូរដែលបានធ្វើជាមួយការចូលដំណើរការមូលដ្ឋានទិន្នន័យផ្ទាល់របស់អ្នកប្រតិបត្តិករក្រោមកំណត់ត្រាផ្លាស់ប្តូរ (ការចូលប្រើបំពេញអាសន្នតែអាន) ហើយថូខេនដែលបានហត្ថលេខាជាមួយវាបន្ទាប់មកបរាជ័យការផ្ទៀងផ្ទាត់។ ការបង្វិលដែលត្រូវបានបង្ខំជា `platform/signing_key_rotate` ក្នុងខ្សែសវនកម្ម ជាមួយមូលហេតុ។ worker ត្រូវការការកំណត់ `QUIRE_MASTER_KEY` ដដែលជាមួយស្រទាប់ web ដើម្បីរុំសោថ្មី។ `bun run kek:rotate` សម្រាប់សោ master រុំសោហត្ថលេខាឡើងវិញជាមួយអ្វីៗផ្សេងទាំងអស់ (`oauth_signing_key` ស្ថិតក្នុង `SEALED_STORES`)។

## ការចូលផលិតបំពេញអាសន្ន <!--quire:break-glass-production-access-->

គ្មានអ្នកណាកាន់ការចូលអចិន្រ្តៃយ៍ទៅកាន់ផលិតទេ។ នៅពេលមានអ្វីមិនអាចរង់ចាំបាន ម្ចាស់មួយរូបចេញការអនុញ្ញាតបំពេញអាសន្ន៖ Platform console, Security, Break-glass access។

- ការអនុញ្ញាតមានវិស័យ (អង្គការមួយ ឬបញ្ជីប្រព័ន្ធ) មូលហេតុយ៉ាងតិច 20 តួអក្សរដែលដាក់ឈ្មោះហេតុការណ៍ ឬសំណើ និងបង្អួចពី 5 ដល់ 240 នាទី។ វាផុតកំណត់ដោយខ្លួនឯង៖ វាត្រូវបានពិនិត្យប្រឆាំងនឹងនាឡិកាលើសេចក្តីថ្លែងនីមួយៗ។
- វាអាចត្រូវបានចេញឱ្យម្ចាស់ដែលចេញវា ឬឱ្យម្ចាស់ផ្សេង (ទម្រង់ពីរនាក់)។ តែមនុស្សដែលវាត្រូវបានចេញឱ្យប៉ុណ្ណោះអាចប្រើវា។ ការចេញត្រូវការ `platform/break_glass_issue` ហើយការប្រើត្រូវការ `platform/break_glass_use`។ ទាំងពីរជាម្ចាស់តែប៉ុណ្ណោះតាមលំនាំដើម។
- សេចក្តីថ្លែងដំណើរការតាម gateway មិនមែនលើការចូលមូលដ្ឋានទិន្នន័យទេ៖ តែអាន មួយក្នុងពេលតែមួយ កំណត់ទៅអង្គការ ឬបញ្ជីត្រួតពិនិត្យ ជាមួយការផុតកំណត់ប្រាំវិនាទី និងយ៉ាងច្រើន 500 ជួរ។ តម្លៃ Binary ត្រូវបានបង្ហាញតាមទំហំ។
- ខ្សែសវនកម្មប្រព័ន្ធកត់ត្រាការចេញ (ជាមួយមូលហេតុ) ការដក សេចក្តីថ្លែងនីមួយៗមុនវាដំណើរការ (`platform/break_glass_statement` ដែលបដិសេធជាមួយលទ្ធផល `denied`) និងលទ្ធផលនីមួយៗ (`platform/break_glass_result`)។ `ops.break_glass_statement` កាន់ id ធាតុសវនកម្ម ដូច្នេះកំណត់ត្រាការចេញភ្ជាប់ទៅធាតុសវនកម្មរបស់វា។
- ការសរសេរមិនត្រូវបានផ្តល់ទេ។ ការផ្លាស់ប្តូរដែលមិនអាចរង់ចាំកំណែប្រើការចូលមូលដ្ឋានទិន្នន័យផ្ទាល់របស់អ្នកប្រតិបត្តិករក្រោមកំណត់ត្រាផ្លាស់ប្តូរផ្ទាល់របស់វា ក្រៅផលិតផលនេះ ហើយកំណត់ត្រាគួរតែយោងលេខសំគាល់ហេតុការណ៍ដែលបានប្រើនៅទីនេះ។

ហេតុអ្វីមិនចេញលិខិតសម្គាល់មូលដ្ឋានទិន្ន័យ៖ ការចូល Postgres នៅសល់អាយុជាង session ដែលសុំវា កំណត់ផ្លូវសុវត្ថិភាពជួរដេកដែលកម្មវិធីពឹងផ្អែក ហើយមិនអាចសរសេរទៅខ្សែសវនកម្មនៃផលិតផលនេះបានទេ ដូច្នេះសេចក្តីថ្លែងរបស់វានឹងត្រូវបានសវនកម្មតែដល់អ្នកណាបានផ្ញើកំណត់ត្រាម៉ាស៊ីនបម្រើប៉ុណ្ណោះ។ gateway ធ្វើឱ្យផ្លូវសវនកម្មជាគុណសមត្ថិភាពនៃការចូល ជំនួសការអនុវត្តជុំវិញវា។

ដើម្បីឆ្លើយសំណើសវនកម្ម៖ រាយការអនុញ្ញាតក្នុងរយៈពេល (Break-glass access) បើកប្រវត្តិនៃការអនុញ្ញាតមួយសម្រាប់សេចក្តីថ្លែង និង id ធាតុសវនកម្ម ហើយអានធាតុទាំងនោះលើខ្សែសវនកម្មប្រព័ន្ធ (`bun run audit:verify --platform` បញ្ជាក់ថាខ្សែនៅតែគង់វង់)។

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