Գլխավոր և ստորագրող բանալիների պտտում և արտակարգ հասանելիություն

21-compliance.md փաստաթղթի 14-րդ բաժնի վերահսկիչ մեխանիզմները, որոնց աուդիտորները դիմում են ըստ անվան։ Այս էջը ընթացակարգն է, իսկ դրա ստեղծած գրառումները՝ ապացույցները։

Բանալիներ

Յուրաքանչյուր պահված հավատարմագիր կնքվում է թարմ տվյալների կոդավորման բանալիով (DEK)։ DEK-ը փաթեթավորվում է գլխավոր բանալիով (KEK), իսկ գլխավոր բանալու հղումը պահվում է դրա կողքին (key_ref կամ փաթեթավորված արժեքի ներսի հղումը)։ Գլխավոր բանալին պտտելիս DEK-ները նորից են փաթեթավորվում։ Հավատարմագիրը երբեք չի ապակոդավորվում կամ կրկին կոդավորվում։

Վեբ շերտը, աշխատողը և bun run kek:rotate հրամանը կարդում են նույն երեք կարգավորումները։ Դրանց բոլորի արժեքները պետք է համընկնեն, այլապես մեկը չի կարող բացել մյուսի կնքած տվյալները։

Առանց QUIRE_MASTER_KEY-ի յուրաքանչյուր ենթահամակարգ շարունակում է օգտագործել QUIRE_SECRET_KEY-ից ստացված բանալին։ Դա աշխատում է, System health էջում ցուցադրվում է վատթարացած վիճակ, և արժեքները մնում են ընթեռնելի գլխավոր բանալի սահմանելուց հետո։ Առաջին պտտմամբ ամեն ինչ հին բանալուց տեղափոխվում է։ Գործընթացի միջավայրն ընթերցող ցանկացած անձ կարող է ապակոդավորել բոլոր պահված հավատարմագրերը, ուստի արտադրական տեղադրումը պետք է ունենա գլխավոր բանալի՝ գաղտնիքների պահոցում, տվյալների բազայի պահուստային պատճենից առանձին։

Պտտում

Բանալու տարիքը երևում է Platform վահանակի 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, կամ
   • նույն միջավայրն ունեցող shell-ում՝ 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 token-ներն ու LTI հաղորդագրությունները ստորագրում է իր RSA բանալիով, որը հրապարակվում է /.well-known/jwks.json հասցեում։ Օպերատորի միջամտություն պետք չէ։ Ժամային platform.signing_keys ժամանակացույցը հաջորդ բանալին հրապարակում է ընթացիկի իննսուն օրվա լրանալուց յոթ օր առաջ։ Մեկ շաբաթ անց նորը սկսում է ստորագրել, իսկ հինը դառնում է հանման փուլում։ Դրանից իննսուն օր անց հինը ջնջվում և հեռացվում է բանալիների հավաքածուից։ Յուրաքանչյուր քայլ գրանցվում է հարթակի աուդիտի շղթայում որպես platform/signing_key_advance։

Կազմակերպության բանալին ավելի վաղ փոխարինելու համար, օրինակ՝ արտահոսքից հետո՝

• վահանակում՝ Security, Master key, Publish a new signing key (պահանջում է platform/keys_manage), կամ
• աշխատողի միջավայրն ունեցող shell-ում՝ bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310"։ bun run kek:rotate signing-keys status հրամանը թվարկում է յուրաքանչյուր կազմակերպության բանալիներն ըստ փուլի։

Նոր բանալին հրապարակվում է անմիջապես և սկսում ստորագրել յոթ օր անց, երբ ընթացիկ բանալին դուրս է գալիս գործածությունից։ Շաբաթվա դադարը դիտավորյալ է․ վստահող կողմերը պահում են բանալիների հավաքածուն, իսկ ավելի կարճ համընկնումը միանգամից կխափանի բոլոր գործիքները։ Դուրս բերվող բանալին մնում է հավաքածուում ևս իննսուն օր, որպեսզի դրանով արդեն ստորագրված token-ները շարունակեն ստուգվել։ Եթե արտահոսքի պատճառով այն ավելի շուտ պետք է դադարի վստահելի լինելուց, դրա տողի ջնջումը օպերատորի՝ սեփական տվյալների բազայի հասանելիությամբ և փոփոխության գրառման ներքո կատարվող գործողություն է (արտակարգ հասանելիությունը միայն կարդալու համար է)․ այդ բանալիով ստորագրված token-ներն այլևս չեն անցնի ստուգումը։ Հարկադրական պտտումը գրանցվում է աուդիտի շղթայում որպես 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-ը հաստատում է շղթայի ամբողջականությունը)։