Galvenās atslēgas un paraksta atslēgu maiņa un ārkārtas piekļuve

Kontroli 21-compliance.md 14. sadaļā, ko auditors prasa pēc nosaukuma. Šī lapa ir kārtība; tās radītie ieraksti ir pierādījumi.

Atslēgas

Katrai saglabātajai akreditāciju datu kopai ir noslēgta ar svaigu datu šifrēšanas atslēgu (DEK). DEK ir ietīts galvenajā atslēgā (KEK), un galvenās atslēgas atsauce tiek glabāta blakus (key_ref vai atsauce iekš iepakotas vērtības). Galvenās atslēgas maiņa atkārtoti ietīt DEK. Tā nekad neatsifrē un neatsifrē no jauna akreditācijas datus.

Tīmekļa slānis, darbinīks un komanda bun run kek:rotate lasa tos pašus trīs iestatījumus. Tiem visiem jābūt ar vienādām vērtībām, citādi viens no tiem nevar atvērt to, ko cits bija noslēdzis.

Bez QUIRE_MASTER_KEY katra apakšsistēma patur atslēgu, ko tā izved no QUIRE_SECRET_KEY. Tas darbojas, Sistēmas veselības lapa to rāda kā pasliktinātu, un tā paliek lasāma arī pēc tam, kad esi iestatījis galveno atslēgu — tā pirmā maiņa pārvieto visu prom no tās. Ikviens, kas var lasīt procesa vidi, var atsifrēt katru saglabāto akreditāciju datu kopu, tāpēc produkcijas instalācijai jābūt galvenajai atslēgai, kas glabājas slepenību glabātuvē un ne tajā pašā dublējumā kur datubāze.

Maiņa

Atslēgas vecums ir redzams Platformas konsoles sadaļā Drošība, Galvenā atslēga, un kā metrika quire.secrets.master_key.age (dienas). Ikdienas grafiks platform.key_age (03:41 UTC) platformas audita ķēdī ieraksta atgādinājumu, kad atslēga sasniedz 365 dienas, un atkal ik pēc 30 dienām, līdz tā ir nomainīta. Mainiet pēc atgādinājuma un katru reizi, kad atslēga varētu būt bijusi pakļauta.

1. Ģenerējiet jaunu atslēgu: openssl rand -base64 32.
2. Iestatiet uz to QUIRE_MASTER_KEY un nākamo etiķeti QUIRE_MASTER_KEY_VERSION (v2). Pārvietojiet veco atslēgu uz QUIRE_MASTER_KEY_RETIRED kā v1=<old base64>. Paturiet abu kopiju kaut kur citur ārpus šī servera.
3. Izvietojiet tīmekļa slāni un darbinīku ar jaunajiem iestatījumiem. Jaunie noslēpumi tagad tiek ietīti zem env:QUIRE_MASTER_KEY:v2; vecie joprojām atveras caur atsaukto atslēgu.
4. Pieprasiet maiņu ar iemeslu, kas paliks izsekojamības ķēdī:
   • konsole: Drošība, Galvenā atslēga, Mainīt galveno atslēgu; vai
   • uz komandrindas ar to pašu vidi: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Darbinīks minūtē ietīt pa daļai (plānotāja grafiks platform.key_rotation) un atsāk pēc restarta. Lai to pabeigtu vienā reizē: bun run kek:rotate run. Vērojiet ar bun run kek:rotate status.
6. Kad ierāda rāda, ka maiņa pabeigta ar nulle neatrisinātu un nulle neizdevušos, noņemiet atsaukto atslēgu no QUIRE_MASTER_KEY_RETIRED un atkārtoti izvietojiet. Līdz tam paturiet to: vērtība, ko tā nevarēja pārvietot, joprojām ir ietīta zem vecās atslēgas.

Ko darbs apiet

Katru glabātuvi, kas glabā ietītu DEK: tās, kas ir SEALED_STORES (apps/worker/src/key-rotation.ts). Kontroldatubāzes glabātuves tiek apietas kontroldatubāzē; organizāciju glabātuves tiek apietas pa vienai organizācijai zem rindu līmeņa drošības, tajā datubāzē, kurā glabājas organizācija, tāpēc nomnieks, kas piesaistīts atsevišķai datubāzei, tiek mainīts tai datubāzei. Tests neizdodas, kad shēmā pievienota ietītās atslēgas kolonna, ko saraksts nesauc, un vēl viens — kad akreditācijas datu pārbaude klasificē noslēgtu kolonu, ko saraksts izlaiž.

Ieraksts

• ops.key_rotation: viena rinda katrai maiņai ar tās iemeslu, kurš to pieprasīja, tās stāvokli un tās kopsummas (atkārtoti ietīti, jau aktuāli, neatrisināti, neizdevušies).
• ops.key_rotation_progress: viena rinda katrai glabātuvei un tvērumam, tiklīdz tā ir apietas, ar atslēgu atsacēm, kuras tā nevarēja nolasīt, un cik vērtību bija zem katras. Atsākta maiņu tās izlaiž.
• Platformas audita ķēde: platform/key_rotation_request (ar iemeslu), viens platform/key_rotation_store katrai glabātuvei ar tā skaitļiem, un platform/key_rotation_complete vai platform/key_rotation_fail; platform/key_age_reminder atgādinājumam.
• Metrikas: quire.secrets.master_key.age un quire.secrets.rewrap.outstanding (vērtības, ko pēdējā maiņa nevarēja pārvietot).

Kad vērtības ir neatrisinātas

Neatrisināta vērtība ir ietīta zem atslēgas atsaces, kuru šī instalācija nepatur, vai arī tā nav tajā formā, kuru sola tās kolonna. Progresa ieraksts nosauc atsaci (piemēram, env:QUIRE_MASTER_KEY:v0 (unreadable)). Atjaunojiet to atslēgu QUIRE_MASTER_KEY_RETIRED un palaidiet vēl vienu maiņu vai, ja atslēga ir beigusies uz visiem laikiem, ļaujiet organizācijas administratoram ievadīt akreditācijas datus no jauna: tad tie tiek noslēgti zem pašreizējās atslēgas. Neizdevušās maiņas savā ierādā rāda kļūdu; izlabojiet cēloni un pieprasiet atkārtoti.

Paraksta atslēgas

Atsevišķi no galvenās atslēgas: katra organizācija paraksta savus OpenID Connect žetonus un LTI ziņojumus ar savu RSA atslēgu, kas publicēta vietnē /.well-known/jwks.json. Neko no tā nevajag operatoram. Ikstundas grafiks platform.signing_keys publicē mantinieku septiņas dienas pirms tam, kad pašreizējās atslēgas deviņdesmit dienas beidzas, nedēļu vēlāk mantinieks sāk parakstīt un vecā atslēga kļūst par atsaukto, un deviņdesmit dienas pēc tam vecā atslēga tiek izdzēsta un pamet atslēgu kopu. Katrs solis ir platform/signing_key_advance ieraksts platformas audita ķēdī.

Lai organizācijas atslēgu aizstātu agrāk, piemēram, pēc noplūdes:

• konsoles sadaļā Drošība, Galvenā atslēga, Publicēt jaunu paraksta atslēgu (vajag platform/keys_manage); vai
• uz komandrindas ar darbinīka vidi: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status uzskaita katras organizācijas atslēgas pēc posma.

Jaunā atslēga tiek publicēta uzreiz un pēc septiņām dienām sāk parakstīt, kad pašreizējā atslēga atsakās. Nedēļa ir apzināta: paļaujošās puses kešo atslēgu kopu, un īsāks pārklājums uzreiz izslēgtu katru rīku. Atsauktā atslēga atslēgu kopā paliek vēl deviņdesmit dienas, lai jau tās parakstītie žetoni turpinātu pārbaudīties; ja noplūde nozīmē, ka tai jāpārstāj uzticēties agrāk, tās rindas dzēšana ir izmaiņa, ko veic ar paša operatora datubāzes piekļuvi zem izmaiņu ieraksta (ārkārtas piekļuve ir tikai lasāma), un ar to parakstītie žetoni tad neiziet pārbaudi. Spiesta maiņa ir platform/signing_key_rotate audita ķēdī ar iemeslu. Darbinīkam tādi paši QUIRE_MASTER_KEY iestatījumi kā tīmekļa slānim, lai ietītu jauno atslēgu; bun run kek:rotate galvenajai atslēgai atkārtoti ietīj arī paraksta atslēgas kopā ar pārējo (oauth_signing_key ir SEALED_STORES).

Ārkārtas piekļuve produkcijai

Nevienam nav pastāvīgas piekļuves produkcijai. Kad kaut kas nevar gaidīt, īpašnieks izdod ārkārtas piekļuves piešķīrumu: Platformas konsole, Drošība, Ārkārtas piekļuve.

• Piešķīrumam ir tvērums (viena organizācija vai platformas reģistrs), iemesls vismaz 20 rakstzīmju garumā, kas nosauc incidentu vai biļeti, un logs no 5 līdz 240 minūtēm. Tas beidzas pats: tas tiek pārbaudīts pret pulksteni katram paziņojumam.
• To var izdot īpašniekam, kas to izdod, vai citam īpašniekam (divu personu forma). To drīkst izmantot tikai persona, kurai tas izdots. Izdošanai vajag platform/break_glass_issue, bet izmantošanai — platform/break_glass_use; abas pēc noklusējuma ir tikai īpašniekam.
• Paziņojumi iet caur vārtiem, nevis uz datubāzes pieteikšanos: tikai lasāmi, pa vienam, ierobežoti organizācijai vai kontroles reģistram, ar piecu sekunžu laika limitu un ne vairāk kā 500 rindām. Binārās vērtības tiek rādītas pēc izmēra.
• Platformas audita ķēde reģistrē izdošanu (ar iemeslu), atsaukšanu, katru paziņojumu pirms tā izpildes (platform/break_glass_statement, noraidītie ar iznākumu denied) un katru rezultātu (platform/break_glass_result). ops.break_glass_statement glabā audita ierakstu ID, lai izdošanas ieraksts savienotos ar saviem audita ierakstiem.
• Ierakstīšana netiek piedāvāta. Izmaiņa, kas nevar gaidīt versiju, izmanto paša operatora datubāzes piekļuvi ar savu izmaiņu ierādu, ārpus šī produkta, un ierādā jāatsaucas uz šeit izmantoto incidenta atsauksmi.

Kāpēc neizdot akreditācijas datus datubāzei: Postgres pieteikšanās pārdzīvo sesiju, kas to pieprasīja, apiet rindu līmeņa drošību, uz kuru paļaujas lietotne, un nevar rakstīt šī produkta audita ķēdī, tāpēc tās paziņojumi tiktu auditorēti tikai tik, cik kāds būtu aizsūtījis servera žurnālu. Vārti padara izsekojamības ķēdi par piekļuves īpašību, nevis praksi ap to.

Lai atbildētu uz audita pieprasījumu: uzskaitiet piešķīrumus periodā (Ārkārtas piekļuve), atveriet piešķīruma vēsturi tā paziņojumiem un audita ierakstu ID un izlasiet tos ierakstus platformas audita ķēdī (bun run audit:verify --platform pierāda, ka ķēde ir neskarta).