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

Master key আৰু signing key ঘূৰাওক; emergency access-ও বুজক।

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

Key-সমূহ

প্ৰতিটো সংৰক্ষিত 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

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 কৰক।

নতুন key সৃষ্টি কৰক: openssl rand -base64 32।
QUIRE_MASTER_KEYক নতুন key আৰু QUIRE_MASTER_KEY_VERSIONক পৰৱৰ্তী label (v2) দিয়ক। পুৰণি key-টো QUIRE_MASTER_KEY_RETIREDত v1=<old base64> হিচাপে ৰাখক। এই host-ৰ বাহিৰত দুয়োটাৰ copy ৰাখক।
নতুন setting-সহ web tier আৰু worker deploy কৰক। নতুন secret এতিয়া env:QUIRE_MASTER_KEY:v2ৰ তলত wrap হয়. retired key-ৰে পুৰণিবোৰ এতিয়াও খোলে।
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"।
Worker-এ প্ৰতি মিনিটত এটা অংশ পুনৰ wrap কৰে (scheduler-ৰ platform.key_rotation schedule) আৰু restart-ৰ পিছত পুনৰ চলে। একেলগে শেষ কৰিবলৈ bun run kek:rotate run। bun run kek:rotate statusৰে চাওক।
Record-ত শূন্য unresolved আৰু শূন্য failedসহ সম্পূৰ্ণ দেখালে QUIRE_MASTER_KEY_RETIREDৰ পৰা retired key আঁতৰাই পুনৰ deploy কৰক। তেতিয়ালৈ ৰাখক: স্থানান্তৰ কৰিব নোৱাৰা value এতিয়াও পুৰণি key-ৰ তলত wrap হৈ আছে।

Job-এ কি scan কৰে

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

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 হ’লে

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

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

কাৰো 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 অক্ষত বুলি প্ৰমাণ কৰে)।