የምስጠራ ጽንሰ-ሐሳቦች

ከፍተኛ-ደረጃ ፍሰት

• OpenAI ፈጽሞ የማያየውን ዋና ቁልፍ በcloudዎ ውስጥ እርስዎ ይቆጣጠራሉ

• ዋና ቁልፍዎ OpenAI የሚጠቀምባቸውን የውሂብ ምስጠራ ቁልፎች (DEKs) ለመኢንክሪፕት ይጠቀማል

• OpenAI ውሂብዎን በተከማቸበት ሁኔታ ለመኢንክሪፕት DEKዎችን ይጠቀማል። DEK በዋና ቁልፍዎ ይመሰጠራል፣ ይህም ከውሂብዎ ጋር የሚቀመጥ eDEK (የተመሰጠረ DEK) ያመነጫል

• ውሂቡን ለማንበብ፣ OpenAI eDEKን ይወስዳል፣ KMSዎ ወደ DEK እንዲዲክሪፕት ይጠይቃል፣ ከዚያም ውሂብዎን ይዲክሪፕት ያደርጋል

የEKM ምስጠራ እንዴት ይሰራል?

ለዝርዝር መረጃ እባክዎ ጽሑፋችንን ይመልከቱ፦ የOpenAI Enterprise Key Management (EKM) አጠቃላይ መግለጫ

OpenAI DEKዎቼን ያከማቻል?

አይ — በKMSዎ የሚፈጠሩትን የተመሰጠሩ DEKዎች (eDEKዎች) እናከማቻለን። ውሂቡን ለመዲክሪፕት፣ eDEKን ወደ DEK መልሶ እንዲዲክሪፕት ከKMSዎ እንጠይቃለን።

OpenAI DEKዎቼን cache ያደርጋል?

አዎ — በማህደረ ትውስታ ውስጥ ብቻ። ይህ በእያንዳንዱ የውሂብ encrypt/decrypt ጥያቄ ላይ KMSዎን እንዳንመታ ለአፈጻጸም ነው። DEKዎች ፈጽሞ ወደ ማከማቻ አይጻፉም።

የCloud ፈቃዶች

OpenAI በKMSዬ ላይ ምን ፈቃዶች ይኖሩታል?

በሚያዘጋጁት ፖሊሲ በኩል የሚሰጡን ፈቃዶች ብቻ። ቢያንስ Encrypt/Decrypt ክዋኔዎች ብቻ ያስፈልጉናል። እባክዎ ለምርት ዓላማ ያሉ ማናቸውንም ነባር ቁልፎች ከመልሰው መጠቀም ይልቅ፣ በcloud KMSዎ ውስጥ ለOpenAI አዲስ ቁልፍ ይፍጠሩ።

OpenAI KMSዬን ለመድረስ ፈቃዶችን መቼ ያገኛል?

እነዚህ ደረጃዎች ሁሉ ተወስደው መሆን አለባቸው፦

1. የOpenAIን ማንነት አውቀዋል (እንደ cloud አቅራቢው በtrust policy፣ workload identity ወዘተ በኩል)።

2. KMSን ለመድረስ ፖሊሲ ፈጥረዋል።

3. የOpenAIን ማንነት ፖሊሲውን ለመድረስ ፈቃድ መድበዋል።

እነዚህን ደረጃዎች ሁሉ ሳይወስዱ KMSን ብቻ ከፈጠሩ፣ OpenAI መዳረሻ አይኖረውም።

ዋና ቁልፌን በcloudዬ ውስጥ ማከማቸት አለብኝ?

አይ — ዋና ቁልፍዎን እንዴት እንደሚያስተዳድሩ የእርስዎ ምርጫ ነው። በcloud የሚተዳደር መፍትሔ ወይም ቁልፍዎ በተናጠል የሚቀመጥበት ውጫዊ መፍትሔ ሊኖርዎት ይችላል። OpenAI በKMSዎ ላይ encrypt/decrypt ክዋኔዎችን መጥራት ብቻ ያስፈልገዋል — ዋናው ቁልፍ encrypt/decryptን በተግባር እንዴት እንደሚያከናውን ለእኛ የማይታይ የአተገባበር ዝርዝር ነው።

የቁልፍ የህይወት ዑደት

የDEK/eDEK ማዞር (በOpenAI የሚቆጣጠር)

DEK/eDEK በምን ያህል ጊዜ ይዞራሉ?

በምስጠራ መንገድ ላይ በየ24 ሰዓቱ (የDEK/eDEK ቁልፍ ጥንድ ሲጠየቅ)

ለዲክሪፕሽን ቁልፍ መንገድ (DEK -> eDEK) በየ1 ሰዓቱ

DEK ሲቀየር ምንም ማድረግ አለብኝ?

አይ — የDEK/eDEK ማዞር በOpenAI ውስጥ ይከናወናል። ዋና ቁልፍዎ ትክክለኛ እስከሆነ ድረስ፣ በዋና ቁልፍዎ የተመሰጠሩ ማናቸውም eDEKዎች ወደ DEK መዲክሪፕት መደረጋቸውን መቀጠል ይችላሉ፣ ከዚያም ያ DEK ውሂብዎን ለመዲክሪፕት ይጠቀማል።

የዋና ቁልፍ ማዞር እና መሻር (በእርስዎ የሚቆጣጠር)

ቁልፍ ማዞር እና ቁልፍ መሻር በምን ያህል ጊዜ ይከሰታሉ?

OpenAI ወደ ዋና ቁልፍዎ እይታ ስለሌለው፣ ይህ በእርስዎ ይወሰናል።

በቁልፍ ማዞር እና በቁልፍ መሻር መካከል ያለው ልዩነት ምንድን ነው?

ቁልፍ መሻር በቀድሞ ቁልፎች የተመሰጠረ ውሂብ ላይ ያለውን መዳረሻ ያስወግዳል። ቁልፍ ማዞር ውሂብን በአዲስ ቁልፍ ይመሰጥራል፣ ግን ወደ ቀድሞ ውሂብ የንባብ መዳረሻን ያቆያል።

ዋና ቁልፌን ከሻርኩ ምን ይሆናል?

ቁልፍ ከተሻረ ወይም ፈቃዶች ከተወገዱ፣ በcache ውስጥ ያሉ ቁልፎች ጊዜያቸው ሲያልቅ የስራ ቦታው ቀስ በቀስ የማይሰራ ይሆናል። በዚያ ጊዜ፣ OpenAI የተከማቸ ውሂብን መዲክሪፕት ማድረግ ወይም አዲስ ውሂብ መኢንክሪፕት ማድረግ ከእንግዲህ አይችልም። በተግባር፣ ውሂቡ “የተቆራረጠ” ይሆናል።

መሻር በምን ያህል ፍጥነት ተግባራዊ ይሆናል?

OpenAI ለአፈጻጸምና ለጽናት DEKዎችን በማህደረ ትውስታ ውስጥ cache ያደርጋል። መሻር በተለምዶ በአንድ ሰዓት ውስጥ፣ በcache ውስጥ ያሉ ቁልፎች ጊዜያቸው ሲያልቅና ዳግም ማረጋገጥ ሲከሽፍ ተግባራዊ ይሆናል።

መሻርን በደህና መሞከር ይቻላል?

በምርት የስራ ቦታ ውስጥ መሻርን መሞከር አይመከርም፣ ምክንያቱም ነባር ውሂብን በቋሚነት የማይደረስበት ያደርገዋል። ነገር ግን ደንበኞች ትክክለኛ ባህሪን ለማረጋገጥና የእምነት ግምቶቻቸውን ለማጽደቅ በsandbox አካባቢ ውስጥ መሻርን መሞከር ይችላሉ (እና መሞከር አለባቸው)።

ቁልፍ በቋሚነት ከተሻረ፣ አዲስ ቁልፍ በማያያዝ የስራ ቦታውን መመለስ ይቻላል?

አይ። ቁልፉ ከጠፋ በኋላ፣ ውሂቡ በንድፍ ደረጃ መመለስ የማይቻል ነው። ብቸኛው መፍትሔ አዲስ የስራ ቦታ ማስጀመር ነው።

በቁልፍ ለውጦች ምክንያት የስራ ቦታ የማይደረስበት ከሆነ ምን ማድረግ አለብን?

የሚጠበቀው መፍትሔ አዲስ የስራ ቦታ መፍጠር ነው። KMSን ማዘመን ነባር ውሂብን አይመልስም።

CMEKን መጠቀም ለማቆም ከወሰንን የመመለሻ ዕቅድ ምንድን ነው?

በአሁኑ ጊዜ የመመለሻ ዕቅድ የለም። አንዴ የስራ ቦታ በCMEK ከተፈጠረ፣ ተያያዥ ውሂብ ሁሉ በደንበኛ-የሚተዳደሩ ቁልፎች ይመሰጠራል እና ያለእነሱ መድረስ አይቻልም። የCMEK አጠቃቀምን ለማቋረጥ ብቸኛው መንገድ አዲስ የስራ ቦታ መፍጠር ነው — ነባር የተመሰጠረ ውሂብ በቋሚነት የማይደረስበት ሆኖ ይቀራል።

ዋና ቁልፌን ስዞር ምን ይሆናል?

ለምስጠራ አዲስ ክሪፕቶግራፊያዊ ቁሳቁስ ይፈጠራል፣ ስለዚህ አዲስ የምስጠራ ጥያቄዎች አዲሱን ቁልፍ ይጠቀማሉ። ነገር ግን፣ የKMS መለያው (ARN ወይም የቁልፍ ስም) እንዳለ ይቆያል እና የቆየ ውሂብ አሁንም መዲክሪፕት ማድረግ ይቻላል። ብዙ የcloud አቅራቢዎች ራስ-ሰር የቁልፍ ማዞር ያቀርባሉ (AWS፣ GCP፣ Azure)።

ዋና ቁልፌን ስዞር OpenAI የቆየ ውሂብን ዳግም ይመሰጥራል?

አይ። አዲሱ ክሪፕቶግራፊያዊ ቁሳቁስ አዲስ ውሂብን ለመኢንክሪፕት ብቻ ይጠቀማል።

ቁልፍ ማዞር ወይም ቁልፍ መሻር ተግባራዊ ለመሆን ምን ያህል ጊዜ ይወስዳል?

1 ሰዓት። ምክንያቱም DEK/eDEKዎቹ በማህደረ ትውስታ ውስጥ cache ይደረጋሉ፣ እኛም እነዚህን ግቤቶች ከKMSዎ ጋር በየሰዓቱ ዳግም እናረጋግጣለን።

የKMS መለያን መቀየር

የKMS መለያን መቀየር ቁልፍ መሻር ነው ወይስ ቁልፍ ማዞር?

ቁልፍ መሻር። አንድ ቁልፍ በሌላ ቁልፍ የተመሰጠረ ውሂብን መዲክሪፕት ማድረግ አይችልም።

OpenAI ለChatGPT የስራ ቦታ የKMS መለያዬን እንድቀይር ሊረዳኝ ይችላል?

ዓላማው ቁልፍዎን መሻር መሆኑን ካረጋገጡ፣ ለChatGPT የስራ ቦታ ይህን እንዲያደርጉ ልንረዳዎ እንችላለን። የKMS ARN ሲዘመን፣ የቆየ ውሂብ የማይደረስበት ሆኖ እንደሚቀር ያስተውሉ፤ ስለዚህ ከለውጡ በኋላ የማይደረስበትና የሚደረስበት ውሂብ ተቀላቅሎ ይኖርዎታል።

OpenAI ለAPI ፕሮጀክት የKMS መለያዬን እንድቀይር ሊረዳኝ ይችላል?

API እየተጠቀሙ ከሆነ፣ API ፕሮጀክቶችን ማህደር ማድረግና አዳዲስ መፍጠር ቀላል ያደርጋል፤ ስለዚህ ውሂቡ በማንኛውም ሁኔታ የማይደረስበትን ፕሮጀክት ማህደር ያድርጉ፣ አዲስ የEKM ውቅር ከOpenAI ጋር ያስመዝግቡ፣ እና በአዲሱ KMS ቁልፍ አዲስ የAPI ፕሮጀክት ይፍጠሩ።

የKMS መለያዬን በራሴ በመደበኛነት መቀየር ከፈለግሁስ?

ቁልፍዎን በመደበኛነት መሻር ምናልባት ስለማይፈልጉ፣ ይህ አይመከርም። ነገር ግን፣ የKMS ቁልፍ aliasን የሚደግፍ የcloud አቅራቢ ከተጠቀሙ አሁንም ይህን ማድረግ ይችላሉ (የAWS ምሳሌ)። ያንን የKMS ቁልፍ alias ከOpenAI ጋር ማስመዝገብ ይችላሉ፣ ከዚያም ቁልፍ መሻር ለማውጣት በcloud አቅራቢዎ ላይ aliasው የሚያመለክተውን መሠረታዊ የKMS መለያ በማንኛውም ጊዜ መቀየር ይችላሉ።

የቤታ እና GA ባህሪ

የምስጠራ ቤታን በምርት ውስጥ ሲጠቀሙ የታወቁ አደጋዎች ወይም የስርዓት-ደረጃ ለውጦች አሉ?

የቤታ አካባቢው በተግባር ከGA ጋር ተመሳሳይ ነው፣ እና የmigration ደረጃዎች አይጠበቁም። ዋናው አደጋ አንዳንድ የedge-case ባህሪያት ባልተሟሉ የcode መንገዶች ምክንያት የተመሰጠረ ይዘትን ገና ላይደግፉ መቻላቸው ነው። እነዚህ አልፎ አልፎ የሚከሰቱ ሲሆኑ በንቃት እየተፈቱ ነው። እነዚህ ሊኖሩ የሚችሉ ችግሮች ቢኖሩም፣ ውሂብ ሙሉ በሙሉ የተመሰጠረና የተጠበቀ ነው።

ከቤታ ወደ GA የmigration ደረጃዎች ይኖራሉ?

አይ። የምስጠራ ቤታን የሚጠቀሙ የስራ ቦታዎች ያለ ማንኛውም የተጠቃሚ እርምጃ በGA ውስጥ በራስ-ሰር ይደገፋሉ።

ተጨማሪ ቴክኒካዊ ዝርዝሮች

Envelope Encryption እና ፈቃዶች

ለEKM የGenerateDataKey ፈቃዶችን ለOpenAI መስጠት አለብን?

አይ። OpenAI በKMS ቁልፍዎ ላይ Encrypt እና Decrypt ፈቃዶችን ብቻ ይፈልጋል። የGenerateDataKey ፈቃድ ለEKM ውህደት አስፈላጊ አይደለም።

OpenAI ለደንበኛ ውሂብ envelope encryption ይጠቀማል?

አዎ። OpenAI የenvelope encryption ሞዴል ይጠቀማል፦

• የደንበኛ KMS፦ የቁልፍ ምስጠራ ቁልፎችን (KEKs) ያስተዳድራል። OpenAI KEKዎችን ፈጽሞ አያይም ወይም አያከማችም።

• የOpenAI መሠረተ ልማት፦ የውሂብ ምስጠራ ቁልፎችን (DEKs) ያመነጫል እና ያስተዳድራል። እያንዳንዱ DEK ከመከማቸቱ በፊት በKEKዎ ይመሰጠራል (ይጠቀለላል)።

• የውሂብ ፍሰት፦

  • የደንበኛ ውሂብ በDEK ይመሰጠራል።

  • ያ DEK በKEKዎ ይመሰጠራል፣ ይህም eDEK ያመነጫል።

  • eDEK ከተመሰጠረው ውሂብ ጎን ይቀመጣል።

  • ውሂብን ለመዲክሪፕት፣ OpenAI eDEKን እንዲዲክሪፕት ከKMSዎ ይጠይቃል፣ DEKን ያገኛል፣ እና ይዘቱን ይዲክሪፕት ያደርጋል።

OpenAI KMS ሁለቱንም KEK እና DEK እንዲያስተዳድር ከመፍቀድ ይልቅ ይህን ሞዴል ለምን መረጠ?

ሁለት የተለመዱ የenvelope encryption አቀራረቦች አሉ፦

በKMS የሚተዳደሩ KEK እና DEK፦

ጥቅሞች፦ አተገባበሩ ቀላል ነው፣ የምስጠራ መሠረተ ልማት ማቆየት አያስፈልግም።

ጉዳቶች፦ እያንዳንዱ የምስጠራ/ዲክሪፕሽን ጥያቄ KMSን ይመታል፣ ይህም መዘግየትንና ወጪን ይጨምራል፣ እንዲሁም አንድ የውድቀት ነጥብ ያስገባል።

በKMS የሚተዳደሩ KEK / በOpenAI የሚተዳደሩ DEK (የእኛ አቀራረብ)፦

ጥቅሞች፦ በጣም ዝቅተኛ መዘግየትና ወጪ፣ የተሻለ መስፋፋትና አስተማማኝነት፣ እንዲሁም በከፊል የKMS መቋረጦች ጊዜ ቀጣይ ክዋኔ (እስከ DEK cache TTL ድረስ)።

ጉዳቶች፦ በOpenAI በኩል ትንሽ የበለጠ ውስብስብ አተገባበር።

ይህ ንድፍ OpenAI ለደንበኞች የክዋኔ አደጋንና ወጪን በመቀነስ ጠንካራ የደህንነት ዋስትናዎችን እንዲሰጥ ያስችለዋል።

DEKዎች በምን ያህል ጊዜ ይዞራሉ?

እያንዳንዱ DEK በግምት በየ60 ደቂቃው ይዞራል። ይህ ጊዜያዊ መነጠልን ይሰጣል — DEK በሆነ መንገድ ቢጋለጥ እንኳ፣ ተፅዕኖው በዚያ የአንድ ሰዓት መስኮት ውስጥ በተመሰጠረ ውሂብ ብቻ ይገደባል።

የKMS ጥያቄ መጠን እና ታይነት

ከተጠቃሚ መልዕክቶች ብዛት በጣም ያነሱ የKMS ጥያቄዎችን እናያለን። እነዚህ ቁጥሮች መመሳሰል አለባቸው?

አይ፣ በቀጥታ አይዛመዱም።

OpenAI ለአፈጻጸም ምክንያቶች DEKዎችን በማህደረ ትውስታ ውስጥ cache ስለሚያደርግ፣ የKMS ጥሪዎች የሚደረጉት DEK መዲክሪፕት ማድረግ ሲያስፈልግ ብቻ ነው — በእያንዳንዱ የምስጠራ ወይም ዲክሪፕሽን ክዋኔ ላይ አይደለም። በዚህ ምክንያት፣ የሚከተለውን መጠበቅ አለብዎ፦

• ከተጠቃሚ መስተጋብሮች ያነሱ የKMS ጥያቄዎች።

• በcache ውስጥ ያሉ DEKዎች ጊዜያቸው ሲያልቅ (በግምት በየሰዓቱ) ወይም የቆየ የተመሰጠረ ውሂብ መደረስ ሲያስፈልግ አልፎ አልፎ የሚታዩ ጭማሪዎች።

• ታሪካዊ ውሂብ ሲወሰድ፣ ለምሳሌ ተጠቃሚ ረጅም ጊዜ የቀጠለ ውይይትን ሲቀጥልና የቆዩ DEKዎች መጫን ሲኖርባቸው፣ ተጨማሪ ጥሪዎች።

ትክክለኛው የKMS ጥያቄዎች ብዛት በcache ሁኔታ፣ በተጠቃሚ ባህሪ፣ በውሂብ መዳረሻ ንድፎች እና በውይይት ርዝመት ላይ ይመሰረታል፤ ስለዚህ ከመልዕክት መጠን ጋር በቀጥታ አይዛመድም።