Мастер-кілт пен қол қою кілтін ауыстыру, сондай-ақ break-glass қолжетімділігі

Аудитор нақсынан атайтын 21-compliance.md құжатының 14-тармағындағы бақылаулар. Бұл бет — рәсім; оның шығаратын жазбалары — дәлелдер.

Кілттер

әр сақталған кілт жаңа деректер шифрлеу кілтімен (DEK) мөрленеді. DEK мастер-кілтпен (KEK) оралады, ал мастер-кілттің сілтемесі оның қасында сақталады (key_ref, немесе орам ішіндегі сілтеме). Мастер-кілтті ауыстыру DEK-терді қайта орады. Ол ешқашан кілтті ашпайды немесе қайта шифрлемейді.

Веб-деңгей, worker және bun run kek:rotate командасы сол үш параметрді оқиды. Олардың бәрінің мәндері бірдей болуы керек, әйтпесе олардың біреуі басқасы мөрлеген нәрсені аша алмайды.

QUIRE_MASTER_KEY болмаса, әр жүйелік бөлік QUIRE_SECRET_KEY-ден шығаратын кілтті ұстап қалады. Бұл жұмыс істейді, System health беті оны degraded көрсетеді, және сіз мастер-кілт орнатқаннан кейін оқыла береді — алғашқы ауыстыру бәрін осыдан ауыстыратын да осы. Процесс ортасын оқи алатын кез келген адам әр сақталған кілтті аша алады, сондықтан өндірістік орнатылымда мастер-кілт болуы керек — оны құпиялар қоймасында ұстаңыз және дерекқормен бір сақтық көшірмеде емес.

Ауыстыру

Кілт жасы Platform console, Security, Master key бөлімінде және quire.secrets.master_key.age метрикасы (күндер) түрінде көрінеді. Күнделікті platform.key_age кестесі (03:41 UTC) кілт 365 күнге жеткенде platform audit тізбегіне еске салу жазбасын жазады және оны ауыстырылғанға дейін әр 30 күн сайын қайталаяды. Еске салу бойынша және кілт ұшыраған кезде ауыстырыңыз.

1. Жаңа кілтті жасаңыз: openssl rand -base64 32.
2. QUIRE_MASTER_KEY параметріне оны, ал QUIRE_MASTER_KEY_VERSION параметріне келесі белгіні (v2) қойыңыз. Ескі кілтті QUIRE_MASTER_KEY_RETIRED параметріне v1=<old base64> түрінде ауыстырыңыз. Екеуінің көшірмесін осы хосттан басқа жерде сақтаңыз.
3. Веб-деңгей мен worker-ді жаңа параметрлермен орналастырыңыз. Жаңа құпиялар енді 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. Worker минутына бір бөлігін қайта орап отырады (scheduler-дің 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 audit тізбегі: 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 ішіне қалпына келтіріп, тағы бір ауыстыру жүргіңіз, немесе кілт мәңгі жоғалған болса, ұйым әкімшісінен кілтті қайта енгізіңіз: сонда ол ағымдағы кілтпен мөрленеді. Сәтсіз ауыстырулар қатесін жазбада көрсетеді; себебін түзетіп, қайта сұраңыз.

Қол қою кілттері

Мастер-кілттен бөлек: әр ұйым өзінің RSA кілтімен OpenID Connect токендеріне және LTI хабарламаларына қол қояды, ол /.well-known/jwks.json мекенжайында жарияланады. Мұнда оператор қажет емес. Сағаттық platform.signing_keys кестесі ағымдағы кілттің тоқсан күні бітпей тұрып жеті күн бұрын ізбасарды жариялайды, бір аптадан кейін ізбасар қол қоюды бастайды және ескі кілт retiring күйіне өтеді, одан кейін тоқсан күннен соң ескі кілт жойылып, кілттер жиынтығынан кетеді. әр қадам platform audit тізбегіндегі platform/signing_key_advance жазбасы.

Ұйым кілтін мерзімінен бұрын ауыстыру үшін, мысалы ұшырағаннан кейін:

• консольде: Security, Master key, Publish a new signing key (platform/keys_manage қажет); немесе
• worker-дің ортасы бар shell-де: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status әр ұйымның кілттерін сатысы бойынша тізеді.

Жаңа кілт бірден жарияланады және жеті күннен кейін, ағымдағы кілт зейнетке шыққанда, қол қоюды бастайды. Апта ойластырылған: сенім әріптестері кілттер жиынтығын кэштейді, ал қысқарақ қабаттасу барлық құралды бірден сәтсіз етеді. Зейнетке шыққан кілт тағы тоқсан күн кілттер жиынтығында қалады, сондықтан ол қол қойған токендер әлі расталып отырады; ұшырау оны ертерек сенімсіз деп тануды талап ететін болса, жолын жою — өзгеріс жазбасының астында оператордың өз дерекқор қолжетімділігімен жасалады (break-glass қолжетімділігі тек оқуға арналған), және онымен қол қойылған токендер содан кейін расталудан өтпейді. Мәжбүрлі ауыстыру аудит тізбегіндегі platform/signing_key_rotate болып, себебімен бірге тізіледі. Worker жаңа кілтті орау үшін веб-деңгейдегідей сол QUIRE_MASTER_KEY параметрлерін қажет етеді; мастер-кілт үшін bun run kek:rotate басқа бәрімен бірге қол қою кілттерін де қайта орайды (oauth_signing_key SEALED_STORES ішінде).

Өндірістік break-glass қолжетімділігі

Ешкім өндіріске тұрақты қолжетімділік ұстамайды. Бірде күте алмайтын кезде иеленуші break-glass рұқсатын береді: Platform console, Security, Break-glass access.

• Рұқсаттың ауқымы бар (бір ұйым немесе платформа реестрі), оқиға немесе тикетті атайтын кемінде 20 таңбалы себеп және 5-тен 240 минутқа дейінгі терезе. Ол өзінен-өзі жарамсыз болады: әр операцияда сағатпен тексеріледі.
• Ол берілетін иеленушіге немесе басқа иеленушіге берілуі мүмкін (екі адамдық түрі). Оған берілген адам ғана пайдалана алады. Беру үшін platform/break_glass_issue, пайдалану үшін platform/break_glass_use қажет; екеуі әдепкіде тек иеленушіге.
• Операциялар дерекқор кіруінен емес, шлюз арқылы орындалады: тек оқу, бір-бірден, ұйымға немесе басқару реестріне шектелген, бес секундтық уақыт шегімен және кемінде 500 жолмен. Бинарлық мәндер өлшемімен көрсетіледі.
• Platform audit тізбегі берілуді (себебімен бірге), қайтарылуын, орындалғанға дейінгі әр операцияны (platform/break_glass_statement, қабылданбағандары denied нәтижесімен) және әр нәтижені (platform/break_glass_result) жазады. ops.break_glass_statement аудит жазба id-лерін ұстайды, сондықтан берілу жазбасы аудит жазбаларына қосылады.
• Жазу ұсынылмайды. Шығарылымды күте алмайтын өзгеріс өзгеріс жазбасының астында өзінің дерекқор қолжетімділігін пайдаланады, бұл өнімнің сыртында, ал жазба осы жерде қолданылған оқиға сілтемесіне сілтеуі керек.

Неге дерекқор кілттерін бермейміз: Postgres кіруі сұраған сессиядан ұзақ өмір сүреді, қолданба сүйенетін қатар қатарлы қауіпсіздікті бұзады және бұл өнімнің аудит тізбегіне жаза алмайды, сондықтан оның операциялары тек біреу сервер журналын жібергенге дейін ғана аудиттеледі. Шлюз аудит тізбегін әрекеттің қасындағы емес, оның өзіне тән қасиет етеді.

Аудит сұранысына жауап беру үшін: кезеңдегі рұқсаттарды тізіңіз (Break-glass access), рұқсаттың операциялары мен аудит жазба id-лері үшін тарихын ашыңыз және сол жазбаларды platform audit тізбегінде оқыңыз (bun run audit:verify --platform тізбекті бүтін екенін дәлелдейді).