ወደ ይዘቱ ዝለል

የዋናና የፊርማ ቁልፎችን ማሽከርከር፣ እና የአደጋ ጊዜ መዳረሻ

የተቀመጡ ምስክርነቶችን የሚጠብቀውን ዋና ቁልፍ ያሽከርክሩና የአደጋ ጊዜ መዳረሻን ይጠቀሙ።

ይህ በ21-compliance.md ክፍል 14 ውስጥ ኦዲተሮች በስም የሚጠይቋቸው ቁጥጥሮች ናቸው። ይህ ገጽ ሂደቱን ይዘረዝራል፤ በሂደቱ የሚፈጠሩ መዝገቦች ማስረጃዎች ናቸው።

ቁልፎቹ

እያንዳንዱ የተቀመጠ ምስክርነት በአዲስ የውሂብ ምስጠራ ቁልፍ (DEK) ይዘጋል። DEKው በዋና ቁልፉ (KEK) ይጠቀለላል፤ የዋና ቁልፉ ማጣቀሻም ከእሱ ጎን ይቀመጣል (በkey_ref ወይም በታሸገ እሴት ውስጥ)። ዋና ቁልፉን ማሽከርከር DEKዎቹን እንደገና ይጠቀልላል። ምስክርነትን አይፈታም ወይም እንደገና አይመስጥርም።

ቅንብር ትርጉም
QUIRE_MASTER_KEY የአሁኑ ዋና ቁልፍ፤ 32 ባይት፣ base64። አዲስ ሚስጥር ሁሉ በእሱ ይጠቀለላል
QUIRE_MASTER_KEY_VERSION የስሪት ምልክት፤ ካልተቀመጠ v1 ነው። ቁልፉን በቀየሩ ጊዜ ሁሉ ያሳድጉት
QUIRE_MASTER_KEY_RETIRED ሚስጥሮች አሁንም ሊጠቀለሉባቸው የሚችሉ አሮጌ ቁልፎች፣ ለምሳሌ v1=<base64>,v0=<base64>። ለማንበብ ብቻ ነው፣ አይጻፍበትም

የድር ክፍሉ፣ worker እና bun run kek:rotate ትእዛዝ ተመሳሳይ ሶስቱን ቅንብሮች ያነባሉ። እሴቶቹ ተመሳሳይ መሆን አለባቸው፤ ካልሆነ አንዱ ሌላው የዘጋውን መክፈት አይችልም።

QUIRE_MASTER_KEY ከሌለ እያንዳንዱ ንዑስ ስርዓት ከQUIRE_SECRET_KEY የሚያወጣውን ቁልፍ ይጠቀማል። ይህ ይሰራል፤ የSystem ጤና ገጽ ግን እንደተቀነሰ ያሳያል። ዋና ቁልፍ ከተቀመጠ በኋላም ውሂቡ ሊነበብ ይችላል፤ የመጀመሪያው ማሽከርከር ሁሉንም ከዚያ ቁልፍ የሚያወጣበት ዘዴ ይህ ነው። የሂደቱን environment ማንበብ የሚችል ማንም የተቀመጡትን ምስክርነቶች ሊፈታ ይችላል፤ ስለዚህ በምርት አካባቢ ዋና ቁልፉ በሚስጥር ማከማቻ ውስጥ መሆንና ከውሂብ ጎታ ምትኬ ጋር አለመቀመጥ አለበት።

ማሽከርከር

የቁልፉ ዕድሜ በPlatform console፣ Security፣ Master key ላይ እና በquire.secrets.master_key.age ሜትሪክ (ቀናት) ይታያል። ዕለታዊው platform.key_age መርሐግብር ቁልፉ 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. በaudit trail ውስጥ የሚቀመጠውን ምክንያት በመጥቀስ ማሽከርከሩን ይጠይቁ፦
    • በconsole፦ Security፣ Master key፣ Rotate the master key፤ ወይም
    • ተመሳሳይ environment ባለው shell፦ bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"።
  5. worker በ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)። የመቆጣጠሪያ ውሂብ ጎታ ማከማቻዎች በዚያው ውሂብ ጎታ ውስጥ ይመረመራሉ፤ የድርጅት ማከማቻዎች ግን በድርጅት አንድ በአንድ፣ row-level security ስር፣ ድርጅቱ ባለበት ውሂብ ጎታ ውስጥ ይከናወናሉ፤ በተለየ ውሂብ ጎታ ላይ የተመደበ ተከራይም በዚያው ይሽከረከራል። ስኪማው በዝርዝሩ ያልተጠቀሰ የታሸገ ቁልፍ አምድ ካከለ ሙከራ ይወድቃል፤ የምስክርነት ግምገማውም የተዘለለ የታሸገ አምድ ካገኘ ሌላ ሙከራ ይወድቃል።

መዝገቡ

  • ops.key_rotation፦ በእያንዳንዱ ማሽከርከር ምክንያቱን፣ የጠየቀውን ሰው፣ ሁኔታውንና ድምሮቹን (እንደገና የተጠቀለሉ፣ አሁኑኑ ያሉ፣ ያልተፈቱ፣ የወደቁ) የያዘ አንድ ረድፍ።
  • ops.key_rotation_progress፦ አንድ ማከማቻና ወሰን ከተመረመሩ በኋላ አንድ ረድፍ፤ ሊነበቡ ያልቻሉ የቁልፍ ማጣቀሻዎችንና በእያንዳንዱ ስር የነበሩ እሴቶችን ብዛት ይይዛል። የቀጠለ ማሽከርከር እነዚህን ይዘላል።
  • Platform audit chain፦ 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 የአሁኑ ቁልፍ 90 ቀን ከመሙላቱ ሰባት ቀን በፊት ተተኪ ቁልፍ ያትማል። ከሳምንት በኋላ ተተኪው መፈረም ይጀምራል፣ አሮጌውም ወደ ጡረታ ይገባል፤ ከ90 ቀን በኋላ አሮጌው ይሰረዛልና ከቁልፍ ስብስቡ ይወገዳል። እያንዳንዱ ደረጃ በplatform audit chain ውስጥ platform/signing_key_advance ይመዘገባል።

የድርጅት ቁልፍን ቀድሞ ለመተካት፣ ለምሳሌ ከተጋለጠ፦

  • በconsole፦ 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 የድርጅቶቹን ቁልፎች በደረጃቸው ያሳያል።

አዲሱ ቁልፍ ወዲያውኑ ይታተማል፣ ከሰባት ቀን በኋላም መፈረም ይጀምራል፣ የአሁኑ ቁልፍም በዚያን ጊዜ ወደ ጡረታ ይገባል። ይህ የሳምንት ጊዜ ሆን ተብሎ ተቀምጧል፤ ተቀባይ አካላት የቁልፍ ስብስቡን cache ውስጥ ያቆያሉ፣ አጭር መደራረብ ሁሉንም መሣሪያዎች በአንድ ጊዜ ያቋርጣል። የጡረታ ቁልፉ የፈረማቸው ቶከኖች እንዲረጋገጡ በስብስቡ ውስጥ ተጨማሪ 90 ቀን ይቆያል። መጋለጡ ከዚያ በፊት እንዳይታመን ካስፈለገ ረድፉን በኦፕሬተሩ የራሱ የውሂብ ጎታ መዳረሻ በለውጥ መዝገብ መሠረት ይሰርዙ (break-glass መዳረሻ ለማንበብ ብቻ ነው)፤ በእሱ የተፈረሙ ቶከኖች ከዚያ በኋላ ማረጋገጫ አያልፉም። የግድ ማሽከርከሩ ምክንያቱን ጨምሮ በaudit chain ውስጥ platform/signing_key_rotate ይመዘገባል። አዲሱን ቁልፍ ለመጠቅለል worker ከድር ክፍሉ ጋር ተመሳሳይ QUIRE_MASTER_KEY ቅንብሮች ይፈልጋል። ዋና ቁልፉን የሚያሽከረክረው bun run kek:rotate ትእዛዝ የፊርማ ቁልፎችንም ከሁሉም ጋር ይጠቀልላል (oauth_signing_key በSEALED_STORES ውስጥ ነው)።

የምርት አካባቢ የአደጋ ጊዜ መዳረሻ

ማንም ሰው በምርት አካባቢ ቋሚ መዳረሻ የለውም። ጉዳዩ መጠበቅ በማይችልበት ጊዜ ባለቤት የአደጋ ጊዜ ፈቃድ ይሰጣል፦ Platform console፣ Security፣ Break-glass access።

  • ፈቃዱ ወሰን አለው (አንድ ድርጅት ወይም platform registry)፣ አደጋውን ወይም ቲኬቱን በሚጠራ ቢያንስ 20 ቁምፊ ያለው ምክንያት፣ እና ከ5 እስከ 240 ደቂቃ የሚቆይ ጊዜ። በራሱ ያበቃል፤ እያንዳንዱ መግለጫ ሲፈጸም ሰዓቱ ይፈተሻል።
  • ለፈቃዱን ለሰጠው ባለቤት ወይም ለሌላ ባለቤት (የሁለት ሰው ሂደት) ሊሰጥ ይችላል። የተሰጠው ሰው ብቻ ሊጠቀምበት ይችላል። መስጠት platform/break_glass_issue፣ መጠቀምም platform/break_glass_use ይፈልጋል፤ በነባሪ ሁለቱም ለባለቤቶች ብቻ ናቸው።
  • መግለጫዎች በውሂብ ጎታ መግቢያ ሳይሆን በgateway ይሄዳሉ፤ ለማንበብ ብቻ፣ አንድ በአንድ፣ በድርጅቱ ወይም በመቆጣጠሪያ መዝገቡ ውስጥ ብቻ፣ ከፍተኛው 5 ሰከንድና 500 ረድፎች። ሁለትዮሽ እሴቶች በመጠናቸው ይታያሉ።
  • Platform audit chain ፈቃዱን መስጠት (ምክንያቱን ጨምሮ)፣ መሻር፣ ከመፈጸሙ በፊት እያንዳንዱን መግለጫ (platform/break_glass_statement፣ የተከለከሉት ከውጤት denied ጋር) እና እያንዳንዱን ውጤት (platform/break_glass_result) ይመዘግባል። ops.break_glass_statement የaudit መዝገቦችን መለያዎች ይይዛል፤ የፈቃድ መዝገቡም ከእነዚያ ጋር ሊገናኝ ይችላል።
  • ጽሁፍ ማድረግ አይፈቀድም። እስከሚቀጥለው ልቀት መጠበቅ የማይችል ለውጥ በኦፕሬተሩ የራሱ የውሂብ ጎታ መዳረሻ ስር፣ ከዚህ ምርት ውጭ ባለው የለውጥ መዝገብ ይከናወናል። መዝገቡ እዚህ የተጠቀሰውን የአደጋ መለያ መጥቀስ አለበት።

ለምን የውሂብ ጎታ ምስክርነት አንሰጥም፦ የPostgres መግቢያ ክፍለ ጊዜው ከጠየቀው በላይ ይቆያል፣ መተግበሪያው የሚመረኮዝበትን row-level security ያልፋል፣ በዚህ ምርት የaudit ሰንሰለት ላይም መጻፍ አይችልም፤ ስለዚህ መግለጫዎቹ የአገልጋይ ሎግ እስኪላክ ድረስ ብቻ ይመዘገባሉ። Gateway ኦዲት መኖሩን በመዳረሻው ራሱ ያረጋግጣል።

የኦዲት ጥያቄን ለመመለስ፦ በወቅቱ የተሰጡትን ፈቃዶች በBreak-glass access ይዘርዝሩ፤ የፈቃዱን ታሪክ የመግለጫዎቹንና የaudit መዝገቦቹን መለያዎች ለማየት ይክፈቱ፤ ከዚያ በplatform audit chain ላይ እነዚያን መዝገቦች ያንብቡ (bun run audit:verify --platform ሰንሰለቱ እንዳልተነካ ያረጋግጣል)።

ዳሰሳ

ለመፈለግ ይተይቡ…

↑↓ ዳስስ↵ ምረጥEsc ዝጋ