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.

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=<old base64> 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 <slug or id> --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).