---
title: "Master key আৰু signing key rotation, আৰু break-glass access"
description: "Master key আৰু signing key ঘূৰাওক; emergency access-ও বুজক।"
image: "https://docs.quirelms.com/og.png"
---

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

# Master key আৰু signing key rotation, আৰু break-glass access

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

Auditor-এ নাম লৈ বিচৰা control-সমূহ 21-compliance.md-ৰ section 14-ত। এই পৃষ্ঠাত পদ্ধতি; ইয়াৰ ফলত সৃষ্টি হোৱা record-সমূহেই প্ৰমাণ।

## Key-সমূহ <!--quire:the-keys-->

প্ৰতিটো সংৰক্ষিত credential নতুন data encryption key (DEK)-ৰে seal হয়। Master key (KEK)-এ DEK wrap কৰে আৰু master key-ৰ reference কাষতে (`key_ref`, অথবা packed value-ৰ ভিতৰৰ reference) সংৰক্ষিত থাকে। Master key rotate কৰিলে DEK পুনৰ wrap হয়। Credential কেতিয়াও decrypt বা re-encrypt নহয়।

| Setting | অৰ্থ |
| --- | --- |
| `QUIRE_MASTER_KEY` | বৰ্তমান master key: 32 byte, base64। প্ৰতিটো নতুন secret ইয়াৰ তলত wrap হয় |
| `QUIRE_MASTER_KEY_VERSION` | ইয়াৰ version label। Unset হ’লে `v1`। Key সলনি কৰোঁতে সদায় বৃদ্ধি কৰক |
| `QUIRE_MASTER_KEY_RETIRED` | আগৰ key, যাৰ তলত secret এতিয়াও থাকিব পাৰে, `v1=<base64>,v0=<base64>` ৰূপে। Read হয়, লিখা নহয় |

Web tier, worker আৰু `bun run kek:rotate` command-এ একে তিনিটা setting পঢ়ে। সকলোতে একে value লাগিব, নহ’লে এটাই seal কৰা বস্তু আনটোৱে খুলিব নোৱাৰে।

`QUIRE_MASTER_KEY` নাথাকিলে প্ৰতিটো subsystem-এ `QUIRE_SECRET_KEY`ৰ পৰা derivation কৰা key ব্যৱহাৰ কৰি থাকে। ই চলে, System health page-এ degraded দেখুৱায় আৰু master key ছেট কৰাৰ পিছতো পঢ়িব পৰা থাকে—প্ৰথম rotation-এ সকলো ইয়াৰ পৰা আঁতৰায়। Process environment পঢ়িব পৰা যিকোনো ব্যক্তিয়ে প্ৰতিটো সংৰক্ষিত credential decrypt কৰিব পাৰে; সেয়ে production installation-ত master key secret store-ত ৰাখক, database-ৰ একে backup-ত নহয়।

## Rotate <!--quire:rotating-->

Platform console-ৰ Security, Master key-ত আৰু `quire.secrets.master_key.age` metric-ত (দিন) key-ৰ বয়স দেখা যায়। Daily `platform.key_age` schedule-এ (03:41 UTC) key 365 দিন হ’লে platform audit chain-ত reminder লিখে, আৰু rotate নকৰালৈ প্ৰতিটো 30 দিনৰ মূৰে মূৰে লিখে। Reminder পালে আৰু key প্ৰকাশ পোৱাৰ আশংকা হ’লে rotate কৰক।

1. নতুন key সৃষ্টি কৰক: `openssl rand -base64 32`।
2. `QUIRE_MASTER_KEY`ক নতুন key আৰু `QUIRE_MASTER_KEY_VERSION`ক পৰৱৰ্তী label (`v2`) দিয়ক। পুৰণি key-টো `QUIRE_MASTER_KEY_RETIRED`ত `v1=<old base64>` হিচাপে ৰাখক। এই host-ৰ বাহিৰত দুয়োটাৰ copy ৰাখক।
3. নতুন setting-সহ web tier আৰু worker deploy কৰক। নতুন secret এতিয়া `env:QUIRE_MASTER_KEY:v2`ৰ তলত wrap হয়. retired key-ৰে পুৰণিবোৰ এতিয়াও খোলে।
4. Audit trail-ত থকা কাৰণসহ rotation request কৰক:
   - console-ত: Security, Master key, Rotate the master key; অথবা
   - একে environment-সহ shell-ত: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`।
5. Worker-এ প্ৰতি মিনিটত এটা অংশ পুনৰ wrap কৰে (scheduler-ৰ `platform.key_rotation` schedule) আৰু restart-ৰ পিছত পুনৰ চলে। একেলগে শেষ কৰিবলৈ `bun run kek:rotate run`। `bun run kek:rotate status`ৰে চাওক।
6. Record-ত **শূন্য unresolved আৰু শূন্য failed**সহ সম্পূৰ্ণ দেখালে `QUIRE_MASTER_KEY_RETIRED`ৰ পৰা retired key আঁতৰাই পুনৰ deploy কৰক। তেতিয়ালৈ ৰাখক: স্থানান্তৰ কৰিব নোৱাৰা value এতিয়াও পুৰণি key-ৰ তলত wrap হৈ আছে।

### Job-এ কি scan কৰে <!--quire:what-the-job-walks-->

Wrapped DEK থকা প্ৰতিটো store: `SEALED_STORES`ৰ তালিকা (`apps/worker/src/key-rotation.ts`)। Control database-ৰ store control database-ত scan হয়; organisation store-সমূহ row-level security-ৰ অধীনত এটাকৈ organisation অনুসৰি, সংগঠন থকা যিকোনো database-ত scan হয়। সেয়ে dedicated database-ত pinned tenant-ও তাতেই rotate হয়। Schema-ত তালিকাই নাম নিদিয়া wrapped-key column যোগ হ’লে এটা test বিফল হয়; আন এটা test-ত credential review-এ তালিকাই নধৰা sealed column চিনাক্ত কৰিলে বিফল হয়।

### Record <!--quire:the-record-->

- `ops.key_rotation`: প্ৰতিটো rotation-ৰ এটা row, কাৰণ, request কৰা ব্যক্তি, অৱস্থা আৰু total (পুনৰ wrapped, আগতেই বৰ্তমান, unresolved, failed)-সহ।
- `ops.key_rotation_progress`: scan হোৱা প্ৰতিটো store আৰু scope-ৰ এটা row; পঢ়িব নোৱাৰা key reference আৰু প্ৰতিটোৰ তলত থকা value-ৰ সংখ্যা। পুনৰ আৰম্ভ কৰা rotation-এ এইবোৰ skip কৰে।
- Platform audit chain: `platform/key_rotation_request` (কাৰণসহ), count-সহ প্ৰতিটো store-ৰ বাবে এটা `platform/key_rotation_store` আৰু `platform/key_rotation_complete` অথবা `platform/key_rotation_fail`; reminder-ৰ বাবে `platform/key_age_reminder`।
- Metric: `quire.secrets.master_key.age` আৰু `quire.secrets.rewrap.outstanding` (শেষ rotation-এ স্থানান্তৰ কৰিব নোৱাৰা value)।

### Value unresolved হ’লে <!--quire:when-values-are-unresolved-->

Unresolved value এনে key reference-ৰ তলত wrap হৈছে যিটো installation-ত নাই, অথবা ইয়াৰ column-এ আশা কৰা format-ত নাই। Progress record-এ reference নাম দিয়ে, উদাহৰণ `env:QUIRE_MASTER_KEY:v0 (unreadable)`। সেই key `QUIRE_MASTER_KEY_RETIRED`ত পুনৰ ৰাখি আন এটা rotation চলাওক; key চিৰদিনৰ বাবে হেৰালে organisation-ৰ প্ৰশাসকক credential পুনৰ দিয়াব, তেতিয়া বৰ্তমান key-ৰ তলত seal হয়। Failed rotation-এ record-ত error দেখুৱায়; কাৰণ সমাধান কৰি পুনৰ request কৰক।

## Signing key <!--quire:signing-keys-->

Master key-ৰ পৰা পৃথক: প্ৰতিটো প্ৰতিষ্ঠানে নিজৰ RSA key-ৰে OpenID Connect token আৰু LTI message স্বাক্ষৰ কৰে, `/.well-known/jwks.json`ত প্ৰকাশিত। ইয়াত operator-ৰ কোনো কাম নাই। Hourly `platform.signing_keys` schedule-এ বৰ্তমান key-ৰ 90 দিন হোৱাৰ সাত দিন আগতে successor প্ৰকাশ কৰে; এসপ্তাহ পিছত successor-এ sign কৰিবলৈ আৰম্ভ কৰি পুৰণিটো retiring হয়; তাৰ 90 দিন পিছত পুৰণি key delete হৈ key set-ৰ পৰা যায়। প্ৰতিটো step platform audit chain-ৰ `platform/signing_key_advance` entry।

উদাহৰণস্বৰূপে 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`-এ প্ৰতিটো প্ৰতিষ্ঠানৰ key stage অনুসৰি তালিকাভুক্ত কৰে।

নতুন key লগে লগে প্ৰকাশ হয় আৰু সাত দিনৰ পিছত sign কৰিবলৈ আৰম্ভ কৰে, যেতিয়া বৰ্তমান key retire হয়। এসপ্তাহ ৰখাৰ কাৰণ আছে: relying party-এ key set cache কৰে; overlap কম হ’লে সকলো tool একেলগে বিফল হয়। আগতেই sign কৰা token verify হৈ থাকিবলৈ retiring key আৰু 90 দিন key set-ত থাকে.  Exposure-ৰ বাবে ইয়াক সোনকালে trust নকৰা প্ৰয়োজন হ’লে operator-ৰ নিজা database access-ৰে change record-ৰ অধীনত row delete কৰিব লাগিব (break-glass access read only); তাৰ পিছত ইয়াৰে sign কৰা token verification-ত বিফল হয়. Forced rotation `platform/signing_key_rotate` audit chain-ত থাকে, কাৰণ নতুন key wrap কৰিবলৈ worker-ৰ `QUIRE_MASTER_KEY` setting web tier-ৰ সৈতে একে হ’ব লাগিব; Master key-ৰ `bun run kek:rotate`-এ আন সকলোৰে সৈতে signing key-ও পুনৰ wrap কৰে (`oauth_signing_key` `SEALED_STORES`ত আছে)।

## Production break-glass access <!--quire:break-glass-production-access-->

কাৰো production-ত স্থায়ী access নাই। কিবা অপেক্ষা কৰিব নোৱাৰিলে owner-এ break-glass grant দিয়ে: Platform console, Security, Break-glass access।

- Grant-ৰ scope (এটা প্ৰতিষ্ঠান অথবা platform registry), incident বা ticket নাম দিয়া অন্ততঃ 20 character-ৰ কাৰণ, আৰু 5ৰ পৰা 240 মিনিটৰ window থাকে। ই নিজে expire হয়: প্ৰতিটো statement-ত clock-ৰ সৈতে পৰীক্ষা হয়।
- Grant দিয়া owner-এ নিজেই পাব পাৰে অথবা আন owner-এ পাব পাৰে (two person form)। কেৱল যাক দিয়া হৈছে তেওঁ ব্যৱহাৰ কৰিব পাৰে। দিয়াৰ বাবে `platform/break_glass_issue` আৰু ব্যৱহাৰৰ বাবে `platform/break_glass_use` লাগে; ডিফল্টভাৱে দুয়ো কেৱল owner-ৰ বাবে।
- Statement database login-ত নহয়, gateway-ৰে চলে: read-only, এটাকৈ, প্ৰতিষ্ঠান বা control registry-ৰ ভিতৰত সীমিত, পাঁচ ছেকেণ্ডৰ timeout আৰু সৰ্বাধিক 500 row। Binary value-ৰ আকাৰ দেখুওৱা হয়।
- Platform audit chain-এ issue (কাৰণসহ), revoke, চলাৰ আগতে প্ৰতিটো statement (`platform/break_glass_statement`; নাকচ কৰাবোৰৰ ফল `denied`) আৰু প্ৰতিটো result (`platform/break_glass_result`) record কৰে। `ops.break_glass_statement`ত audit entry ID থাকে, সেয়ে issue record-এ audit entry-ৰ সৈতে join হয়।
- Write operation দিয়া নহয়। Release-ৰ বাবে অপেক্ষা কৰিব নোৱাৰা পৰিৱৰ্তন product-ৰ বাহিৰত operator-ৰ নিজা database access আৰু change record-ৰে কৰিব লাগে; record-ত ইয়াত ব্যৱহাৰ কৰা incident reference লিখিব লাগে।

Database credential কিয় নিদিয়ে: Postgres login-ৰ মেয়াদ ইয়াক বিচৰা session-তকৈ দীঘল, application-এ নিৰ্ভৰ কৰা row-level security পাৰ হৈ যায় আৰু এই product-ৰ audit chain-ত লিখিব নোৱাৰে। গতিকে server log ship কৰালৈকেহে ইয়াৰ statement audit হয়। Gateway-এ audit trail-টো access-ৰ গুণ কৰে, access-ৰ কাষৰ প্ৰক্ৰিয়া নহয়।

Audit request-ৰ উত্তৰ দিবলৈ: সেই সময়ৰ grant তালিকাভুক্ত কৰক (Break-glass access), statement আৰু audit entry ID-ৰ বাবে grant-ৰ history খোলক আৰু platform audit chain-ত সেই entry পঢ়ক (`bun run audit:verify --platform`-এ chain অক্ষত বুলি প্ৰমাণ কৰে)।

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