---
title: "Master və imza açarlarının dəyişdirilməsi, fövqəladə giriş"
description: "Saxlanmış etimadnamələri qoruyan master açarı dəyişin və fövqəladə girişdən istifadə edin."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/az/llms.txt
> Use this file to discover all available pages before exploring further.
# Master və imza açarlarının dəyişdirilməsi, fövqəladə giriş
Auditorun adını çəkərək tələb etdiyi nəzarətlər 21-compliance.md sənədinin 14-cü bölməsindədir. Bu səhifədə prosedur, onun yaratdığı qeydlərdə isə sübutlar verilir.
## Açarlar
Saxlanmış hər etimadnamə yeni məlumat şifrələmə açarı (DEK) ilə möhürlənir. DEK master açarla (KEK) bükülür və master açarın istinadı yanında (`key_ref` və ya paketlənmiş dəyərin daxilindəki istinad) saxlanılır. Master açarın dəyişdirilməsi DEK-ləri yenidən bükür. Etimadnamə heç vaxt açılmır və yenidən şifrələnmir.
| Parametr | Mənası |
| --- | --- |
| `QUIRE_MASTER_KEY` | Cari master açar: 32 bayt, base64. Hər yeni secret onun altında bükülür |
| `QUIRE_MASTER_KEY_VERSION` | Versiya etiketi. Boşdursa `v1`. Açarı dəyişəndə artırın |
| `QUIRE_MASTER_KEY_RETIRED` | Secret-lərin hələ də altında ola biləcəyi əvvəlki açarlar, `v1=,v0=` kimi. Oxunur, yazılmır |
Web qatı, worker və `bun run kek:rotate` əmri eyni üç parametri oxuyur. Hamısında dəyərlər eyni olmalıdır, yoxsa biri digərinin möhürlədiyini aça bilməz.
`QUIRE_MASTER_KEY` olmadıqda hər alt sistem `QUIRE_SECRET_KEY`-dən törətdiyi açardan istifadə etməyə davam edir. Bu işləyir, System health səhifəsi vəziyyəti zəifləmiş göstərir, master açarı təyin etdikdən sonra da oxumaq mümkündür; ilk dəyişiklik hər şeyi həmin açardan çıxarır. Proses mühitini oxuya bilən hər kəs istənilən saxlanmış etimadnaməni aça bilər; buna görə istehsal quraşdırmasında master açarı secret anbarında saxlayın, verilənlər bazasının ehtiyat nüsxəsi ilə eyni yerdə yox.
## Dəyişdirmə
Açarın yaşı Platform konsolu, Security, Master key bölməsində və `quire.secrets.master_key.age` metrikində (günlərlə) göstərilir. Gündəlik `platform.key_age` cədvəli (03:41 UTC) açar 365 günə çatanda platformanın audit zəncirinə xatırlatma yazır, dəyişdirilənədək hər 30 gündən bir təkrar edir. Xatırlatma aldıqda və açarın sızmış ola biləcəyi istənilən vaxt dəyişdirin.
1. Yeni açar yaradın: `openssl rand -base64 32`.
2. `QUIRE_MASTER_KEY`-i ona, `QUIRE_MASTER_KEY_VERSION`-ı növbəti etiketə (`v2`) təyin edin. Köhnə açarı `QUIRE_MASTER_KEY_RETIRED` daxilində `v1=` kimi saxlayın. Hər ikisinin surətini bu hostdan başqa yerdə saxlayın.
3. Yeni parametrlərlə web qatını və worker-i yerləşdirin. Yeni secret-lər indi `env:QUIRE_MASTER_KEY:v2` altında bükülür; köhnələr retired açarla açılır.
4. Audit izində görünəcək səbəblə dəyişdirmə sorğusu yaradın:
- konsolda: Security, Master key, Rotate the master key; və ya
- eyni mühitli shell-də: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker dəqiqədə bir hissəni yenidən bükür (scheduler-in `platform.key_rotation` cədvəli) və yenidən başladıqdan sonra davam edir. Hamısını bir dəfəyə bitirmək üçün `bun run kek:rotate run` işlədin. `bun run kek:rotate status` ilə vəziyyətə baxın.
6. Qeyd dəyişdirmənin **həll olunmamış və uğursuz element olmadan** bitdiyini göstərəndə `QUIRE_MASTER_KEY_RETIRED`-dən köhnə açarı silib yenidən yerləşdirin. O vaxtadək saxlayın: köçürə bilmədiyi dəyər hələ də köhnə açarla bükülü ola bilər.
### Tapşırığın əhatə dairəsi
Bükülmüş DEK saxlayan bütün anbarlar: `SEALED_STORES` daxilində göstərilənlər (`apps/worker/src/key-rotation.ts`). İdarəetmə bazasındakı anbarlar idarəetmə bazasında skan edilir; təşkilat anbarları sətir səviyyəli təhlükəsizliklə, həmin təşkilatın yerləşdiyi bazada bir təşkilat-bir dəfə gəzilir; buna görə ayrılmış bazaya bağlanmış tenant da həmin bazada dəyişdirilir. Sxemə siyahıda olmayan bükülmüş açar sütunu əlavə edilərsə test, etimadnamə yoxlaması siyahının ötürdüyü möhürlü sütun tapsa başqa test uğursuz olur.
### Qeyd
- `ops.key_rotation`: hər dəyişdirməyə bir sətir: səbəb, sorğu edən, vəziyyət və yekunlar (yenidən bükülüb, artıq cari, həll olunmamış, uğursuz).
- `ops.key_rotation_progress`: gəzilmiş hər anbar və əhatə üçün bir sətir; oxuna bilməyən açar istinadları və hər birinin altında neçə dəyər olduğu. Davam etdirilən dəyişdirmə bunları ötürür.
- Platform audit zənciri: səbəblə `platform/key_rotation_request`, saylarla hər anbar üçün `platform/key_rotation_store`, həmçinin `platform/key_rotation_complete` və ya `platform/key_rotation_fail`; xatırlatma üçün `platform/key_age_reminder`.
- Metriklər: `quire.secrets.master_key.age` və `quire.secrets.rewrap.outstanding` (son dəyişdirmənin köçürə bilmədiyi dəyərlər).
### Dəyərlər həll olunmadıqda
Həll olunmamış dəyər quraşdırmanın saxlamadığı açar istinadı ilə bükülüb və ya sütunun gözlədiyi quruluşda deyil. İrəliləyiş qeydi istinadı göstərir, məsələn, `env:QUIRE_MASTER_KEY:v0 (unreadable)`. Həmin açarı `QUIRE_MASTER_KEY_RETIRED`-ə qaytarıb yenidən dəyişdirmə başladın; açar həmişəlik itibdirsə, təşkilat administratoru etimadnaməni yenidən daxil etsin: cari açarla möhürlənəcək. Uğursuz dəyişdirmələrin xətası qeyddə göstərilir; səbəbi düzəldib yenidən sorğu verin.
## İmza açarları
Master açardan ayrıdır: hər təşkilat OpenID Connect tokenlərini və LTI mesajlarını öz RSA açarı ilə imzalayır; açar `/.well-known/jwks.json` ünvanında dərc edilir. Burada operator müdaxiləsi tələb olunmur. Saatlıq `platform.signing_keys` cədvəli cari açarın 90 günü tamamlanmazdan yeddi gün əvvəl yenisini dərc edir; bir həftə sonra yenisi imzalamağa başlayır, köhnə isə dəyişdirilmə mərhələsinə keçir; 90 gün keçdikdən sonra köhnə silinir və açar dəstindən çıxır. Hər addım platforma audit zəncirində `platform/signing_key_advance` qeydi yaradır.
Məsələn, açar sızdıqdan sonra təşkilatın açarını vaxtından əvvəl dəyişmək üçün:
- konsolda: Security, Master key, Publish a new signing key (`platform/keys_manage` tələb edir); və ya
- worker-in mühiti ilə shell-də: `bun run kek:rotate signing-keys rotate
--tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate
signing-keys status` hər təşkilatın açarlarını mərhələyə görə siyahıya alır.
Yeni açar dərhal dərc olunur və cari açar istifadədən çıxandan yeddi gün sonra imzalamağa başlayır. Həftəlik gözləmə qəsdəndir: etibar edən sistemlər açar dəstini keşləyir, daha qısa üst-üstə düşmə bütün alətləri eyni vaxtda sıradan çıxarar. Köhnə imzaladığı tokenlər yoxlana bilsin deyə istifadədən çıxan açar daha 90 gün dəstdə qalır; sızma səbəbindən daha tez etibarsız etmək lazımdırsa, onun sətrini operator öz verilənlər bazası girişi və dəyişiklik qeydi ilə silir (fövqəladə giriş yalnız oxumadır), nəticədə onun imzaladığı tokenlərin yoxlanması uğursuz olur. Məcburi dəyişdirmə platforma audit zəncirində səbəbi ilə `platform/signing_key_rotate` kimi qeydə alınır. Yeni açarı bükmək üçün worker-də `QUIRE_MASTER_KEY` parametrləri web qatı ilə eyni olmalıdır; master açar üçün `bun run kek:rotate` digər açarlarla yanaşı imza açarlarını da yenidən bükür (`oauth_signing_key` `SEALED_STORES` daxilindədir).
## İstehsalda fövqəladə giriş
Heç kimin istehsal mühitinə daimi girişi yoxdur. Gözləyə bilməyən hal olduqda owner fövqəladə giriş icazəsi verir: Platform console, Security, Break-glass access.
- İcazənin əhatəsi (bir təşkilat və ya platform reyestri), hadisə və ya tapşırıq nömrəsini göstərən ən azı 20 simvolluq səbəb və 5–240 dəqiqəlik müddəti olur. Hər sorğuda saatla yoxlanılır və müddət bitdikdə özü başa çatır.
- İcazə verən owner özünə və ya başqa owner-ə (iki nəfərlik qayda) verə bilər. Yalnız verildiyi şəxs istifadə edə bilər. Vermək üçün `platform/break_glass_issue`, istifadə etmək üçün `platform/break_glass_use` lazımdır; standartda hər ikisi yalnız owner üçündür.
- Bəyanatlar verilənlər bazası girişindən yox, gateway-dən keçir: yalnız oxuma, eyni anda bir sorğu, təşkilat və ya idarəetmə reyestri ilə məhdud, beş saniyəlik vaxt limiti və ən çox 500 sətir. İkili dəyərlər ölçüsü ilə göstərilir.
- Platforma audit zənciri verilməni (səbəbi ilə), ləğvi, icra edilməzdən əvvəl hər bəyanatı (`platform/break_glass_statement`; rədd edilənlərdə nəticə `denied`) və hər cavabı (`platform/break_glass_result`) qeydə alır. `ops.break_glass_statement` audit yazılarının ID-lərini saxlayır, buna görə icazə qeydi audit yazılarına bağlanır.
- Yazma əməliyyatı təklif edilmir. Buraxılışı gözləyə bilməyən dəyişiklik bu məhsuldan kənarda operatorun öz verilənlər bazası girişi və dəyişiklik qeydi ilə edilir; qeyddə burada istifadə olunan hadisə istinadı olmalıdır.
Verilənlər bazası etimadnaməsi niyə verilmir: Postgres girişi onu istəyən sessiyadan uzun yaşayır, tətbiqin güvəndiyi sətir səviyyəli təhlükəsizliyi aşır və məhsulun audit zəncirinə yaza bilmir; buna görə bəyanatlar yalnız server jurnalı göndərilərsə auditə düşər. Gateway audit izini girişin öz xüsusiyyətinə çevirir, ətrafında görülən tədbirə yox.
Audit sorğusuna cavab vermək üçün dövrdəki icazələri (Break-glass access) siyahıya alın, bəyanatları və audit yazısı ID-lərini görmək üçün icazənin tarixçəsini açın, sonra platforma audit zəncirində həmin yazıları oxuyun (`bun run audit:verify --platform` zəncirin bütövlüyünü təsdiqləyir).
Source: https://docs.quirelms.com/az/ops/key-rotation/index.mdx