Ротација на главен клуч и клуч за потпишување и пристап во итни случаи

Контролите во 21-compliance.md оддел 14 по кои ревизорот прашува по име. Оваа страница е постапката; записите што ги произведува се доказот.

Клучеви

Секоја зачувана потврда се запечатува со свеж клуч за шифрирање податоци (DEK). DEK се завиткува со главниот клуч (KEK), и референцата на главниот клуч се чува покрај неа (key_ref или референцата внатре во пакувана вредност). Ротацијата на главниот клуч повторно ги завиткува DEK-овите. Таа никогаш не дешифрира ниту повторно шифрира потврда.

Веб-слојот, работникот и командата bun run kek:rotate ги читаат истите три поставки. Тие мора да ги имаат истите вредности, инаку една од нив не може да го отвори она што другата го запечатила.

Без QUIRE_MASTER_KEY секој подсистем го задржува клучот што го изведува од QUIRE_SECRET_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. Побарајте ја ротацијата, со причината што ќе остане во трагот на ревизијата:
   • во конзолата: Безбедност, Главен клуч, Ротирај го главниот клуч; или
   • на шел со истата средина: 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). Продавниците на контролната база се обиколуваат на контролната база; продавниците на организацијата се обиколуваат по една организација истовремено под безбедност на ниво на ред, во која било база што ја држи организацијата, така што закупецот врзан за посебна база се ротира во таа база. Тест не успева кога шемата добива колона со завиткан клуч што списокот не го наведува, а друг кога прегледот на потврди класификува запечатена колона што списокот ја пропушта.

Записот

• 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 во низата за ревизија на платформата.

За да го замените клучот на организацијата порано, на пример по изложеност:

• во конзолата: Безбедност, Главен клуч, Објави нов клуч за потпишување (бара 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).

Производен пристап во итни случаи

Никој не држи постојан пристап до производството. Кога нешто не може да чека, сопственикот издава доделување за итни случаи: Конзола на платформата, Безбедност, пристап во итни случаи.

• Доделувањето има опсег (една организација или регистарот на платформата), причина од најмалку 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 ги чува идентификаторите на записите за ревизија, така што записот за издавање се поврзува со неговите записи за ревизија.
• Записите не се нудат. Промена што не може да чека издание го користи сопствениот пристап на операторот до базата на податоци под сопствен запис за промена, надвор од овој производ, и записот треба да се повикува на референцата за инцидент користена овде.

Зошто да не се издаваат потврди за база на податоци: најавувањето во Postgres преживува ја сесијата што го побарала, заобиколува ја безбедноста на ниво на ред на која апликацијата се потпира и не може да запишува во низата за ревизија на овој производ, така што неговите изјави би се ревизирале само доколку некој го испорачал дневникот на серверот. Мостот го прави трагот на ревизија својство на пристапот, а не пракса околу него.

За да одговорите на барање за ревизија: наведете ги доделувањата во периодот (Пристап во итни случаи), отворете ја историјата на доделување за неговите изјави и идентификаторите на записите за ревизија и прочитајте ги тие записи во низата за ревизија на платформата (bun run audit:verify --platform докажува дека низата е целосна).