Негизги килит жана кол коюу килиттерин алмаштыруу, жана бузуу айнеги менен кирүү

21-compliance.md документинин 14-бөлүмүндөгү контролдор, аларды аудитор аты менен сурайт. Бул бет — процедура; ал түзгөн жазуулар — далил.

Килттер

Ар бир сакталган купуялык маалымат жаңы маалыматтык шифрлөө килити (DEK) менен мөөрлөнөт. DEK негизги килит (KEK) менен ороп, негизги килиттин референси анын жанында сакталат (key_ref, же түйүлгөн маалыматтын ичиндеги референс). Негизги килитти алмаштыруу DEK’терди кайра оройт. Ал эч качан купуялык маалыматты шифрлөөдөн чыгарбайт же кайра шифрлөбөйт.

Веб катмары, жумушчу жана bun run kek:rotate буйругу ошол эле үч жөндөөнү окуйт. Алардын баарында бирдей мааны болушу керек, болбосо алардын бири башкысы мөөрлөгөндү ача албайт.

QUIRE_MASTER_KEY болбосо ар бир подсистема QUIRE_SECRET_KEY’ден алган килитин сактап калат. Бул иштейт, System health бети аны кемиген деп көрсөтөт, жана негизги килитти койгондон кийин да ал окулууну улантат — биринчи алмаштыруу баарын андан алып кеткенде дал ушундай болот. Процесстин чөйрөсүн окуй алган каалаган адам ар бир сакталган купуялык маалыматты шифрлөөдөн чыгара алат, ошондуктан өндүрүш орнотуусунда негизги килит болушу керек, аны сыр кампасында сактайт жана маалымат базасы менен бирдей камдык көчүрмөдө эмес.

Алмаштыруу

Килиттин жашы 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, Rotate the 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’тен кетирилген килитти чыгарып, кайра жайгаштырыңыз. Ошого чейин аны кармаңыз: ал жылдыра албаган мааны мурунку килиттин астында оролуп турат.

Жумуш эмнөөрдү кыдырат

Оролгон DEK бардык кампа: SEALED_STORES’тагылар (apps/worker/src/key-rotation.ts). Башкы маалымат базасы кампалары башкы маалымат базасында кыдырылат; уюм кампалары бир уюмдан маалымат базасында, сап деңгээлинде коргоо астында кыдырылат, анткени айырмаланган маалымат базасына бекитилген tenant ошол маалымат базасында алмаштырылат. Тест тизмеде аталбаган оролгон килит колонкасы пайда болгондо ийгиликсиз болот, жана купуялык кароосу тизмеден калган мөөрлөнгөн колонканы классификациялабаса дагы бири ийгиликсиз болот.

Жазуу

• 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 (акыркы алмаштыруу жылдыра албаган маанылар).

Маанылар чечилбесе

Чечилбеген мааны бул орнотууда жок килит референсинин астында оролгон, же анын колонкасы убада кылган түрдө эмес. Прогресс жазуусу референсти атайт (мисалы env:QUIRE_MASTER_KEY:v0 (unreadable)). Ошол килитти QUIRE_MASTER_KEY_RETIRED’ке калыбына келтирип, дагы бир алмаштырууну иштетиңиз, же килит түбөлүккө жоголгон болсо, уюмдун администратору купуялык маалыматты кайра киргизсин: анда ал азыркы килиттин астында мөөрлөнөт. Ийгиликсиз алмаштыруулар жазууда катасын көрсөтөт; себебин түзөтүп, кайра сураныңыз.

Кол коюу килиттери

Негизги килиттен айрыма: ар бир уюм өзүнүн OpenID Connect токендерин жана LTI каттарын өзүнүн RSA килити менен кол коёт, ал /.well-known/jwks.json жеринде жарыяланат. Бул жерде оператор керек эмес. Саатына бир жолу platform.signing_keys жумушу азыркы килиттин токсон күнү бүтөөрүнө жети мурун мураскор жарыялайт, бир жумадан кийин мураскор кол коюуну баштайт жана эски килит кетирилүүгө өтөт, андан токсон кийин эски килит өчүрүлүп, килит тобунан чыгат. Ар бир адым платформа аудит чынжырындагы platform/signing_key_advance жазуусу.

Уюмдун килитин мурдараак алмаштыруу үчүн, мисалы ачылгандан кийин:

• консольдо: Security, Master key, Publish a new signing 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 ар бир уюмдун килиттерин баскычы боюнча тизмелейт.

Жаңы килит дароо жарыяланат жана жети кийинки күнү кол коюуну баштайт, ал учурда азыркы килит кетет. Бир жума ойлонулган: ишенүүчү тараптар килит топтомун кэштейт, ал эми кыскараак өбөлгө бардык куралды бир учурда ийгиликсиз кылат. Кетирилип жаткан килит дагы токсон күн килит тобунда калат, ошондо аны мурун кол койгон токендер текшериле берет; ачылуу аны эртерээк ишенбөөгө тийиштирип жаткан болсо, анын сабын өчүрүү — өзгөртүү жазуусунун астында оператордун өзүнүн маалымат базасына кирүүсү менен жасалган өзгөрүү (бузуу айнеги менен кирүү окуу гана), андан кийин аны менен кол коюлган токендер текшерүүдөн өтпөйт. Мажбурлап алмаштыруу чынжырдагы platform/signing_key_rotate, себеби менен. Жумушчу жаңы килитти ороп алуу үчүн веб катмары менен бирдей QUIRE_MASTER_KEY жөндөөлөрүн талап кылат; негизги килит үчүн bun run kek:rotate кол коюу килиттерин башка баары менен чогуу кайра оройт (oauth_signing_key SEALED_STORES’та).

Өндүрүшкө бузуу айнеги менен кирүү

Эч ким өндүрүшкө туруктуу ууксатка ээ эмес. Бир нерсе күтө албаганда, ээ бузуу айнеги укугун чыгарат: 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 чынжыр бүтүн экенин далилдейт).