---
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/kn/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>` ಆಗಿ. ಓದಲಾಗುತ್ತದೆ, ಎಂದಿಗೂ ಬರೆಯಲ್ಪಡುವುದಿಲ್ಲ |

ವೆಬ್ ಹಂತ, ವರ್ಕರ್ ಮತ್ತು `bun run kek:rotate` ಆದೇಶವು ಅದೇ ಮೂರು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಓದುತ್ತವೆ.
ಅವು ಎಲ್ಲವೂ ಅದೇ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದು ಇನ್ನೊಂದು ಮುಚ್ಚಿದ್ದನ್ನು
ತೆರೆಯಲಾಗದು.

`QUIRE_MASTER_KEY` ಇಲ್ಲದೆ ಪ್ರತಿ ಉಪವ್ಯವಸ್ಥೆಯೂ `QUIRE_SECRET_KEY` ನಿಂದ ತಾನು ಪಡೆಯುವ ಕೀ
ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಸಿಸ್ಟಮ್ ಆರೋಗ್ಯ ಪುಟವು ಅದನ್ನು ಕುಸಿದಿದೆ ಎಂದು
ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಮಾಸ್ಟರ್ ಕೀ ಹೊಂದಿಸಿದ ನಂತರ ಅದು ಓದಲು ಉಳಿಯುತ್ತದೆ, ಇದೇ ಮೊದಲ
ರೊಟೇಶನ್ ಎಲ್ಲವನ್ನೂ ಅದರಿಂದ ಹೊರಗೆ ಕರೆದೊಯ್ಯುವ ವಿಧಾನ. ಪ್ರಕ್ರಿಯಾ ಪರಿಸರವನ್ನು ಓದಬಲ್ಲ ಯಾರೂ
ಪ್ರತಿ ಸಂಗ್ರಹಿತ ಪರಿಚಯಪತ್ರವನ್ನೂ ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಉತ್ಪಾದನಾ ಸ್ಥಾಪನೆಯು ಒಂದು
ಮಾಸ್ಟರ್ ಕೀ ಹೊಂದಿರಬೇಕು, ಒಂದು ರಹಸ್ಯ ಅಂಗಡಿಯಲ್ಲಿ ಇಡಲ್ಪಟ್ಟು ಡೇಟಾಬೇಸ್‌ನದೇ ಅದೇ ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ
ಅಲ್ಲ.

## ರೊಟೇಟ್ ಮಾಡುವುದು <!--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. ಹೊಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ವೆಬ್ ಹಂತ ಮತ್ತು ವರ್ಕರ್ ಡಿಪ್ಲಾಯ್ ಮಾಡಿ. ಹೊಸ ರಹಸ್ಯಗಳು ಈಗ
   `env:QUIRE_MASTER_KEY:v2` ಅಡಿಯಲ್ಲಿ ಸುತ್ತಲ್ಪಟ್ಟಿವೆ; ಹಳೆಯವು ಇನ್ನೂ ನಿವೃತ್ತ ಕೀ ಮೂಲಕ
   ತೆರೆಯುತ್ತವೆ.
4. ಆಡಿಟ್ ಹಾದಿಯಲ್ಲಿ ಇರಲಿಕ್ಕಿರುವ ಕಾರಣದೊಂದಿಗೆ ರೊಟೇಶನ್ ವಿನಂತಿಸಿ:
   - ಕನ್ಸೋಲ್‌ನಲ್ಲಿ: Security, Master key, ಮಾಸ್ಟರ್ ಕೀ ರೊಟೇಟ್ ಮಾಡಿ; ಅಥವಾ
   - ಅದೇ ಪರಿಸರದ ಶೆಲ್‌ನಲ್ಲಿ: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. ವರ್ಕರ್ ನಿಮಿಷಕ್ಕೆ ಒಂದು ಸ್ಲೈಸ್ ಮತ್ತೆ ಸುತ್ತುತ್ತದೆ (ಶೆಡ್ಯೂಲರ್‌ನ `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`) ನಲ್ಲಿನವು. ನಿಯಂತ್ರಣ ಡೇಟಾಬೇಸ್ ಅಂಗಡಿಗಳನ್ನು
ನಿಯಂತ್ರಣ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸುತ್ತಲಾಗುತ್ತದೆ; ಸಂಸ್ಥಾ ಅಂಗಡಿಗಳನ್ನು ಸಾಲು-ಮಟ್ಟದ ಭದ್ರತೆಯಡಿಯಲ್ಲಿ
ಒಂದು ಸಂಸ್ಥೆಯನ್ನು ಒಂದೊಂದಾಗಿ, ಸಂಸ್ಥೆ ಹೊಂದಿರುವ ಯಾವ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿದೆಯೋ ಅಲ್ಲಿ ಸುತ್ತಲಾಗುತ್ತದೆ,
ಆದ್ದರಿಂದ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್‌ಗೆ ಬಂಧಿಸಲ್ಪಟ್ಟ ಟೆನಂಟ್ ಅನ್ನು ಅದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ರೊಟೇಟ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಪಟ್ಟಿಯು ಹೆಸರಿಸದ ಒಂದು ಸುತ್ತಲ್ಪಟ್ಟ-ಕೀ ಕಾಲಮ್ ಸ್ಕೀಮಾದಲ್ಲಿ ಸೇರಿದಾಗ ಒಂದು ಪರೀಕ್ಷೆ ವಿಫಲವಾಗುತ್ತದೆ,
ಮತ್ತು ಪರಿಚಯಪತ್ರ ಪರಿಶೀಲನೆಯು ಪಟ್ಟಿ ತಪ್ಪಿಸಿದ ಮುಚ್ಚಲ್ಪಟ್ಟ ಕಾಲಮ್ ವರ್ಗೀಕರಿಸಿದಾಗ ಇನ್ನೊಂದು
ವಿಫಲವಾಗುತ್ತದೆ.

### ದಾಖಲೆ <!--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-->

ಮಾಸ್ಟರ್ ಕೀಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ: ಪ್ರತಿ ಸಂಸ್ಥೆಯೂ ತನ್ನದೇ ಆದ RSA ಕೀಯೊಂದಿಗೆ ತನ್ನ OpenID
Connect ಟೋಕನ್‌ಗಳು ಮತ್ತು LTI ಸಂದೇಶಗಳಿಗೆ ಸಹಿ ಹಾಕುತ್ತದೆ, `/.well-known/jwks.json`
ನಲ್ಲಿ ಪ್ರಕಟಿಸಲ್ಪಡುತ್ತದೆ. ಇಲ್ಲಿ ಯಾರಿಗೂ ಸಂಚಾಲಕನ ಅಗತ್ಯವಿಲ್ಲ. ಗಂಟಾವಾರಿ `platform.signing_keys`
ವೇಳಾಪಟ್ಟಿಯು ಪ್ರಚಲಿತ ಕೀಯ ತೊಂಬತ್ತು ಮುಗಿಯುವ ಒಂದು ವಾರದ ಮೊದಲು ಒಂದು ಉತ್ತರಾಧಿಕಾರಿಯನ್ನು
ಪ್ರಕಟಿಸುತ್ತದೆ, ವಾರದ ನಂತರ ಉತ್ತರಾಧಿಕಾರಿ ಸಹಿ ಮಾಡಲು ಆರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ಕೀ ನಿವೃತ್ತಿ
ಹೊಂದುತ್ತದೆ, ಮತ್ತು ಅದರ ನಂತರ ತೊಂಬತ್ತು ದಿನಗಳ ನಂತರ ಹಳೆಯ ಕೀ ಅಳಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಕೀ ಸೆಟ್‌ನಿಂದ
ಹೊರಹೋಗುತ್ತದೆ. ಪ್ರತಿ ಹಂತವೂ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಡಿಟ್ ಸರಪಳಿಯಲ್ಲಿ ಒಂದು
`platform/signing_key_advance` ನಮೂದು.

ಒಂದು ಸಂಸ್ಥೆಯ ಕೀಯನ್ನು ಬೇಗ ಬದಲಾಯಿಸಲು, ಉದಾಹರಣೆಗೆ ಒಂದು ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ನಂತರ:

- ಕನ್ಸೋಲ್‌ನಲ್ಲಿ: Security, Master key, ಹೊಸ ಸಹಿ ಕೀ ಪ್ರಕಟಿಸಿ
  (`platform/keys_manage` ಬೇಕು); ಅಥವಾ
- ವರ್ಕರ್‌ನ ಪರಿಸರದ ಶೆಲ್‌ನಲ್ಲಿ: `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`. ಹೊಸ ಕೀ ಸುತ್ತಲು ವರ್ಕರ್‌ಗೆ ವೆಬ್ ಹಂತದಂತೆಯೇ ಅದೇ
`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/break_glass_statement`, ನಿರಾಕರಿಸಲ್ಪಟ್ಟವು
  `denied` ಫಲಿತಾಂಶದೊಂದಿಗೆ) ಮತ್ತು ಪ್ರತಿ ಫಲಿತಾಂಶವನ್ನೂ (`platform/break_glass_result`)
  ದಾಖಲಿಸುತ್ತದೆ. `ops.break_glass_statement` ಆಡಿಟ್ ನಮೂದು id ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ,
  ಆಗ ಮಂಜೂರಿನ ದಾಖಲೆಯು ಅದರ ಆಡಿಟ್ ನಮೂದುಗಳಿಗೆ ಸೇರುತ್ತದೆ.
- ಬರೆಯುವಿಕೆಗಳನ್ನು ನೀಡಲಾಗುವುದಿಲ್ಲ. ಒಂದು ಬಿಡುಗಡೆಗಾಗಿ ಕಾಯಲಾಗದ ಬದಲಾವಣೆಯು ತನ್ನದೇ ಬದಲಾವಣಾ
  ದಾಖಲೆಯಡಿಯಲ್ಲಿ ಸಂಚಾಲಕನ ಸ್ವಂತ ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶ ಬಳಸುತ್ತದೆ, ಈ ಉತ್ಪನ್ನದ ಹೊರಗೆ, ಮತ್ತು
  ದಾಖಲೆಯು ಇಲ್ಲಿ ಬಳಸಿದ ಘಟನಾ ಉಲ್ಲೇಖವನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕು.

ಡೇಟಾಬೇಸ್ ಪರಿಚಯಪತ್ರಗಳನ್ನು ನೀಡದಿರಲು ಏಕೆ: Postgres ಲಾಗಿನ್ ಅದನ್ನು ಕೇಳಿದ ಸೆಷನ್‌ಗಿಂತ
ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅವಲಂಬಿಸಿರುವ ಸಾಲು-ಮಟ್ಟದ ಭದ್ರತೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ,
ಮತ್ತು ಈ ಉತ್ಪನ್ನದ ಆಡಿಟ್ ಸರಪಳಿಗೆ ಬರೆಯಲಾಗದು, ಆದ್ದರಿಂದ ಅದರ ಹೇಳಿಕೆಗಳನ್ನು ಯಾರಾದರೂ ಸರ್ವರ್
ಲಾಗ್ ಕಳುಹಿಸಿದ ಮಟ್ಟಿಗೆ ಮಾತ್ರ ಆಡಿಟ್ ಮಾಡಲಾಗುತ್ತದೆ. ಗೇಟ್‌ವೇ ಆಡಿಟ್ ಹಾದಿಯನ್ನು ಅದರ ಸುತ್ತಲಿನ
ಅಭ್ಯಾಸವಲ್ಲ, ಪ್ರವೇಶದ ಗುಣವಾಗಿ ಮಾಡುತ್ತದೆ.

ಒಂದು ಆಡಿಟ್ ವಿನಂತಿಗೆ ಉತ್ತರಿಸಲು: ಆ ಅವಧಿಯ ಮಂಜೂರುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ (Break-glass access),
ಅದರ ಹೇಳಿಕೆಗಳು ಮತ್ತು ಆಡಿಟ್ ನಮೂದು id ಗಳಿಗಾಗಿ ಒಂದು ಮಂಜೂರಿನ ಇತಿಹಾಸ ತೆರೆಯಿರಿ, ಮತ್ತು ಆ
ನಮೂದುಗಳನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಡಿಟ್ ಸರಪಳಿಯಲ್ಲಿ ಓದಿ (`bun run audit:verify --platform` ಸರಪಳಿ
ಅಕ್ಷತವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ).

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