എൻക്രിപ്ഷൻ ആശയങ്ങൾ
ഉയർന്ന തലത്തിലുള്ള പ്രവാഹം
OpenAI ഒരിക്കലും കാണാത്ത ഒരു മാസ്റ്റർ കീ നിങ്ങളുടെ ക്ലൗഡിൽ നിങ്ങൾ നിയന്ത്രിക്കുന്നു
OpenAI ഉപയോഗിക്കുന്ന ഡാറ്റ എൻക്രിപ്ഷൻ കീകൾ (DEK-കൾ) എൻക്രിപ്റ്റ് ചെയ്യാൻ നിങ്ങളുടെ മാസ്റ്റർ കീ ഉപയോഗിക്കുന്നു
വിശ്രമാവസ്ഥയിലുള്ള നിങ്ങളുടെ ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്യാൻ OpenAI DEK-കൾ ഉപയോഗിക്കുന്നു. ഒരു DEK നിങ്ങളുടെ മാസ്റ്റർ കീ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുകയും ഒരു eDEK (എൻക്രിപ്റ്റ് ചെയ്ത DEK) സൃഷ്ടിക്കപ്പെടുകയും അത് നിങ്ങളുടെ ഡാറ്റയ്ക്കൊപ്പം സംഭരിക്കപ്പെടുകയും ചെയ്യുന്നു
ഡാറ്റ വായിക്കാൻ, OpenAI eDEK എടുത്ത് അത് DEK ആക്കി ഡീക്രിപ്റ്റ് ചെയ്യാൻ നിങ്ങളുടെ KMS-നോട് അഭ്യർത്ഥിക്കുകയും തുടർന്ന് നിങ്ങളുടെ ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യുകയും ചെയ്യുന്നു
EKM എൻക്രിപ്ഷൻ എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്.
വിശദമായ വിവരങ്ങൾക്ക് ഞങ്ങളുടെ ലേഖനം കാണുക: OpenAI എന്റർപ്രൈസ് കീ മാനേജ്മെന്റ് (EKM) അവലോകനം
OpenAI എന്റെ DEK-കൾ സംഭരിക്കുന്നുണ്ടോ.
ഇല്ല - നിങ്ങളുടെ KMS സൃഷ്ടിക്കുന്ന എൻക്രിപ്റ്റ് ചെയ്ത DEK-കൾ (eDEK-കൾ) ആണ് ഞങ്ങൾ സംഭരിക്കുന്നത്. ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യാൻ, eDEK വീണ്ടും DEK ആക്കി ഡീക്രിപ്റ്റ് ചെയ്യാൻ ഞങ്ങൾ നിങ്ങളുടെ KMS-നോട് അഭ്യർത്ഥിക്കുന്നു.
OpenAI എന്റെ DEK-കൾ കാഷ് ചെയ്യുന്നുണ്ടോ.
ഉണ്ട് - മെമ്മറിയിൽ മാത്രം. ഓരോ ഡാറ്റ എൻക്രിപ്റ്റ്/ഡീക്രിപ്റ്റ് അഭ്യർത്ഥനയ്ക്കും നിങ്ങളുടെ KMS-നെ സമീപിക്കുന്നത് ഒഴിവാക്കി പ്രകടനം മെച്ചപ്പെടുത്താനാണിത്. DEK-കൾ ഒരിക്കലും സ്റ്റോറേജിലേക്ക് എഴുതപ്പെടുന്നില്ല.
ക്ലൗഡ് അനുമതികൾ
എന്റെ KMS-ൽ OpenAI-ക്ക് എന്ത് അനുമതികളുണ്ടാകും.
നിങ്ങൾ സജ്ജമാക്കിയ പോളിസിയിലൂടെ ഞങ്ങൾക്ക് അനുവദിക്കുന്ന അനുമതികൾ മാത്രം. ഞങ്ങൾക്ക് കുറഞ്ഞത് Encrypt/Decrypt പ്രവർത്തനങ്ങൾ മാത്രം മതി. പ്രൊഡക്ഷൻ ആവശ്യങ്ങൾക്കുള്ള നിലവിലുള്ള കീകൾ വീണ്ടും ഉപയോഗിക്കുന്നതിന് പകരം OpenAI-ക്കായി നിങ്ങളുടെ ക്ലൗഡ് KMS-ൽ ഒരു പുതിയ കീ സൃഷ്ടിക്കുക.
എന്റെ KMS ആക്സസ് ചെയ്യാനുള്ള അനുമതികൾ OpenAI-ക്ക് എപ്പോൾ ലഭിക്കും.
ഈ എല്ലാ ഘട്ടങ്ങളും പൂർത്തിയായിരിക്കണം:
നിങ്ങൾ OpenAI-യുടെ ഐഡന്റിറ്റി അംഗീകരിച്ചിരിക്കുന്നു (ക്ലൗഡ് പ്രൊവൈഡറിനെ ആശ്രയിച്ച് ട്രസ്റ്റ് പോളിസി, വർക്ലോഡ് ഐഡന്റിറ്റി തുടങ്ങിയവ വഴി).
KMS ആക്സസ് ചെയ്യുന്നതിനായി നിങ്ങൾ ഒരു പോളിസി സൃഷ്ടിച്ചിരിക്കുന്നു.
പോളിസി ആക്സസ് ചെയ്യാനുള്ള അനുമതി OpenAI-യുടെ ഐഡന്റിറ്റിക്ക് നിങ്ങൾ നൽകിയിരിക്കുന്നു.
ഈ എല്ലാ ഘട്ടങ്ങളും ചെയ്യാതെ നിങ്ങൾ KMS മാത്രം സൃഷ്ടിച്ചാൽ, OpenAI-ക്ക് ആക്സസ് ഉണ്ടാകില്ല.
എന്റെ മാസ്റ്റർ കീ എന്റെ ക്ലൗഡിൽ തന്നെ സൂക്ഷിക്കണമോ.
വേണ്ട - നിങ്ങളുടെ മാസ്റ്റർ കീ എങ്ങനെ മാനേജ് ചെയ്യണമെന്ന് നിങ്ങൾക്കാണ് തീരുമാനിക്കാം. നിങ്ങളുടെ കീ വേറിട്ട് സൂക്ഷിക്കുന്ന ക്ലൗഡ്-നിയന്ത്രിത പരിഹാരമോ ബാഹ്യ പരിഹാരമോ നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം. നിങ്ങളുടെ KMS-ൽ encrypt/decrypt പ്രവർത്തനങ്ങൾ വിളിക്കാനാകുക മാത്രമാണ് OpenAI-ക്ക് വേണ്ടത്; മാസ്റ്റർ കീ യഥാർത്ഥത്തിൽ encrypt/decrypt ചെയ്യുന്നത് എങ്ങനെയെന്നത് ഞങ്ങൾക്ക് ദൃശ്യമല്ലാത്ത നടപ്പാക്കൽ വിശദാംശമാണ്.
കീ ലൈഫ്സൈക്കിൾ
DEK/eDEK റൊട്ടേഷൻ (OpenAI നിയന്ത്രിക്കുന്നത്)
DEK-കൾ/eDEK-കൾ എത്ര ഇടവേളകളിലാണ് റൊട്ടേറ്റ് ചെയ്യുന്നത്.
എൻക്രിപ്ഷൻ പാതയിൽ ഓരോ 24 മണിക്കൂറിലും (DEK/eDEK കീ ജോഡി അഭ്യർത്ഥിക്കുന്നു)
ഡീക്രിപ്ഷൻ കീ പാതയിൽ ഓരോ 1 മണിക്കൂറിലും (DEK -> eDEK)
DEK മാറുമ്പോൾ ഞാൻ എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ടോ.
ഇല്ല - DEK/eDEK റൊട്ടേഷൻ OpenAI-ക്കുള്ളിൽ തന്നെ നടക്കുന്നു. നിങ്ങളുടെ മാസ്റ്റർ കീ സാധുവായി തുടരുന്നിടത്തോളം, നിങ്ങളുടെ മാസ്റ്റർ കീ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത ഏത് eDEK-കളെയും DEK ആക്കി തുടർന്നും ഡീക്രിപ്റ്റ് ചെയ്യാം. തുടർന്ന് അത് നിങ്ങളുടെ ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യാൻ ഉപയോഗിക്കുന്നു.
മാസ്റ്റർ കീ റൊട്ടേഷനും റദ്ദാക്കലും (നിങ്ങൾ നിയന്ത്രിക്കുന്നത്)
കീ റൊട്ടേഷനും കീ റദ്ദാക്കലും എത്ര ഇടവേളകളിലാണ് നടക്കുന്നത്.
നിങ്ങളുടെ മാസ്റ്റർ കീയിലേക്ക് OpenAI-ക്ക് ദൃശ്യതയില്ലാത്തതിനാൽ ഇത് നിങ്ങൾ തന്നെയാണ് നിർണ്ണയിക്കുന്നത്.
കീ റൊട്ടേഷനും കീ റദ്ദാക്കലും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്.
കീ റദ്ദാക്കൽ പഴയ കീകൾ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റയിലേക്കുള്ള ആക്സസ് നീക്കം ചെയ്യുന്നു. കീ റൊട്ടേഷൻ പുതിയ കീ ഉപയോഗിച്ച് ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്യുന്നു, എന്നാൽ പഴയ ഡാറ്റയിലേക്കുള്ള വായനാ ആക്സസ് നിലനിർത്തുന്നു.
ഞാൻ എന്റെ മാസ്റ്റർ കീ റദ്ദാക്കിയാൽ എന്ത് സംഭവിക്കും.
ഒരു കീ റദ്ദാക്കുകയോ അനുമതികൾ നീക്കം ചെയ്യുകയോ ചെയ്താൽ, കാഷ് ചെയ്ത കീകളുടെ കാലാവധി തീരുന്ന മുറയ്ക്ക് വർക്ക്സ്പേസ് ഒടുവിൽ പ്രവർത്തനരഹിതമാകും. അപ്പോൾ OpenAI-ക്ക് സംഭരിച്ച ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യാനോ പുതിയ ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്യാനോ ഇനി കഴിയില്ല. പ്രായോഗികമായി, ഡാറ്റ “ഷ്രെഡ്” ചെയ്യപ്പെട്ടതുപോലെയാണ്.
റദ്ദാക്കൽ എത്ര വേഗത്തിൽ പ്രാബല്യത്തിൽ വരും.
പ്രകടനത്തിനും പ്രതിരോധക്ഷമതയ്ക്കുമായി OpenAI DEK-കൾ മെമ്മറിയിൽ കാഷ് ചെയ്യുന്നു. കാഷ് ചെയ്ത കീകളുടെ കാലാവധി തീർന്ന് വീണ്ടും സാധൂകരിക്കൽ പരാജയപ്പെട്ടാൽ, സാധാരണയായി ഒരു മണിക്കൂറിനകം റദ്ദാക്കൽ പ്രാബല്യത്തിൽ വരും.
റദ്ദാക്കൽ സുരക്ഷിതമായി പരീക്ഷിക്കാനാകുമോ.
പ്രൊഡക്ഷൻ വർക്ക്സ്പേസിൽ റദ്ദാക്കൽ പരീക്ഷിക്കുന്നത് ശുപാർശ ചെയ്യുന്നില്ല, കാരണം അത് നിലവിലുള്ള ഡാറ്റയെ സ്ഥിരമായി ആക്സസ് ചെയ്യാനാവാത്തതാക്കും. എന്നാൽ ശരിയായ പെരുമാറ്റം പരിശോധിക്കാനും വിശ്വാസാനുമാനങ്ങൾ സാധൂകരിക്കാനും ഉപഭോക്താക്കൾക്ക് സാൻഡ്ബോക്സ് പരിസ്ഥിതിയിൽ റദ്ദാക്കൽ പരീക്ഷിക്കാം, പരീക്ഷിക്കണം.
ഒരു കീ സ്ഥിരമായി റദ്ദാക്കിയാൽ, പുതിയ കീ അറ്റാച്ച് ചെയ്ത് വർക്ക്സ്പേസ് വീണ്ടെടുക്കാനാകുമോ.
ഇല്ല. കീ നഷ്ടപ്പെട്ടുകഴിഞ്ഞാൽ, രൂപകൽപ്പന പ്രകാരം തന്നെ ഡാറ്റ തിരിച്ചെടുക്കാനാവില്ല. ഒരു പുതിയ വർക്ക്സ്പേസ് തുടങ്ങുക മാത്രമാണ് പരിഹാരം.
കീ മാറ്റങ്ങൾ കാരണം ഒരു വർക്ക്സ്പേസ് ആക്സസ് ചെയ്യാനാവാത്തതായാൽ എന്ത് ചെയ്യണം.
പ്രതീക്ഷിക്കുന്ന പരിഹാരം ഒരു പുതിയ വർക്ക്സ്പേസ് സൃഷ്ടിക്കുകയെന്നതാണ്. KMS അപ്ഡേറ്റ് ചെയ്താൽ നിലവിലുള്ള ഡാറ്റ വീണ്ടെടുക്കാനാവില്ല.
CMEK ഉപയോഗിക്കുന്നത് നിർത്താൻ ഞങ്ങൾ തീരുമാനിച്ചാൽ ബാക്കൗട്ട് പദ്ധതി എന്താണ്.
നിലവിൽ ബാക്കൗട്ട് പദ്ധതി ഒന്നുമില്ല. CMEK ഉപയോഗിച്ച് ഒരു വർക്ക്സ്പേസ് സൃഷ്ടിച്ചുകഴിഞ്ഞാൽ, ബന്ധപ്പെട്ട എല്ലാ ഡാറ്റയും ഉപഭോക്താവ് നിയന്ത്രിക്കുന്ന കീകൾ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു, അവ ഇല്ലാതെ ആക്സസ് ചെയ്യാനാവില്ല. CMEK ഉപയോഗം നിർത്താനുള്ള ഏക മാർഗം ഒരു പുതിയ വർക്ക്സ്പേസ് സൃഷ്ടിക്കുകയാണ് — നിലവിലുള്ള എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റ സ്ഥിരമായി ആക്സസ് ചെയ്യാനാവാത്തതായിരിക്കും.
ഞാൻ എന്റെ മാസ്റ്റർ കീ റൊട്ടേറ്റ് ചെയ്യുമ്പോൾ എന്ത് സംഭവിക്കും.
എൻക്രിപ്ഷനായി പുതിയ ക്രിപ്റ്റോഗ്രാഫിക് മെറ്റീരിയൽ സൃഷ്ടിക്കപ്പെടും. അതിനാൽ പുതിയ എൻക്രിപ്ഷൻ അഭ്യർത്ഥനകൾ പുതിയ കീ ഉപയോഗിക്കും. എന്നാൽ KMS ഐഡന്റിഫയർ (ARN അല്ലെങ്കിൽ കീ നാമം) അതേപടി തുടരും, പഴയ ഡാറ്റ ഇപ്പോഴും ഡീക്രിപ്റ്റ് ചെയ്യാനാകും. അനേകം ക്ലൗഡ് പ്രൊവൈഡർമാർ ഓട്ടോമാറ്റിക് കീ റൊട്ടേഷൻ വാഗ്ദാനം ചെയ്യുന്നു (AWS, GCP, Azure).
ഞാൻ എന്റെ മാസ്റ്റർ കീ റൊട്ടേറ്റ് ചെയ്യുമ്പോൾ OpenAI പഴയ ഡാറ്റ വീണ്ടും എൻക്രിപ്റ്റ് ചെയ്യുമോ.
ഇല്ല. പുതിയ ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്യാൻ മാത്രമേ പുതിയ ക്രിപ്റ്റോഗ്രാഫിക് മെറ്റീരിയൽ ഉപയോഗിക്കൂ.
കീ റൊട്ടേഷനോ കീ റദ്ദാക്കലോ പ്രാബല്യത്തിൽ വരാൻ എത്ര സമയം എടുക്കും.
1 മണിക്കൂർ. കാരണം DEK/eDEK-കൾ മെമ്മറിയിൽ കാഷ് ചെയ്യപ്പെടുന്നു, കൂടാതെ ഈ എൻട്രികൾ നിങ്ങളുടെ KMS ഉപയോഗിച്ച് ഞങ്ങൾ മണിക്കൂറിൽ ഒരിക്കൽ വീണ്ടും സാധൂകരിക്കുന്നു.
KMS ഐഡന്റിഫയർ മാറ്റൽ
KMS ഐഡന്റിഫയർ മാറ്റുന്നത് കീ റദ്ദാക്കലാണോ കീ റൊട്ടേഷനാണോ.
കീ റദ്ദാക്കൽ. മറ്റൊരു കീ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റ ഒരു കീയ്ക്ക് ഡീക്രിപ്റ്റ് ചെയ്യാനാവില്ല.
ഒരു ChatGPT വർക്ക്സ്പേസിനായി എന്റെ KMS ഐഡന്റിഫയർ മാറ്റാൻ OpenAI എന്നെ സഹായിക്കുമോ.
ഉദ്ദേശ്യം നിങ്ങളുടെ കീ റദ്ദാക്കലാണെന്ന് നിങ്ങൾ സ്ഥിരീകരിച്ചാൽ, ChatGPT വർക്ക്സ്പേസിനായി ഇത് ചെയ്യാൻ ഞങ്ങൾക്ക് നിങ്ങളെ സഹായിക്കാം. KMS ARN അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ പഴയ ഡാറ്റ ആക്സസ് ചെയ്യാനാവാത്തതായിരിക്കും. അതിനാൽ മാറ്റത്തിന് ശേഷം ആക്സസ് ചെയ്യാനാവാത്തതും ആക്സസ് ചെയ്യാനാവുന്നതുമായ ഡാറ്റയുടെ മിശ്രിതം നിങ്ങൾക്ക് ഉണ്ടായിരിക്കും.
ഒരു API പ്രോജക്റ്റിനായി എന്റെ KMS ഐഡന്റിഫയർ മാറ്റാൻ OpenAI എന്നെ സഹായിക്കുമോ.
നിങ്ങൾ API ഉപയോഗിക്കുന്നുവെങ്കിൽ, പ്രോജക്റ്റുകൾ ആർക്കൈവ് ചെയ്യാനും പുതിയത് സൃഷ്ടിക്കാനും API എളുപ്പമാക്കുന്നു. അതിനാൽ, ഡാറ്റ എങ്ങനെയും ആക്സസ് ചെയ്യാനാവാത്ത ആ പ്രോജക്റ്റ് ആർക്കൈവ് ചെയ്ത്, OpenAI-യിൽ ഒരു പുതിയ EKM കോൺഫിഗ് രജിസ്റ്റർ ചെയ്ത്, പുതിയ KMS കീ ഉപയോഗിച്ച് ഒരു പുതിയ API പ്രോജക്റ്റ് സൃഷ്ടിക്കുക.
എന്റെ KMS ഐഡന്റിഫയർ ഞാൻ തന്നെ പതിവായി മാറ്റാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ എന്ത് ചെയ്യും.
നിങ്ങൾ സാധാരണയായി നിങ്ങളുടെ കീ പതിവായി റദ്ദാക്കാൻ ആഗ്രഹിക്കില്ലെന്നതിനാൽ ഇത് ശുപാർശ ചെയ്യുന്നില്ല. എങ്കിലും, KMS കീ അലീയാസ് പിന്തുണയ്ക്കുന്ന ഒരു ക്ലൗഡ് പ്രൊവൈഡർ നിങ്ങൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ ഇത് ചെയ്യാൻ കഴിയും (AWS ഉദാഹരണം). ആ KMS കീ അലീയാസ് OpenAI-യിൽ രജിസ്റ്റർ ചെയ്യാം. തുടർന്ന് കീ റദ്ദാക്കൽ നടപ്പാക്കാൻ, നിങ്ങളുടെ ക്ലൗഡ് പ്രൊവൈഡറിൽ അലീയാസ് ചൂണ്ടുന്ന അടിസ്ഥാന KMS ഐഡന്റിഫയർ നിങ്ങൾക്ക് ഏതുസമയത്തും മാറ്റാം.
Beta vs. GA പെരുമാറ്റം
പ്രൊഡക്ഷനിൽ എൻക്രിപ്ഷൻ beta ഉപയോഗിക്കുമ്പോൾ അറിയപ്പെടുന്ന അപകടസാധ്യതകളോ സിസ്റ്റം-തല മാറ്റങ്ങളോ ഉണ്ടോ.
beta പരിസ്ഥിതി പ്രവർത്തനപരമായി GA-യ്ക്ക് തുല്യമാണ്, മൈഗ്രേഷൻ ഘട്ടങ്ങൾ പ്രതീക്ഷിക്കുന്നില്ല. പ്രധാന അപകടസാധ്യത, അപൂർണ്ണമായ കോഡ് പാതകൾ കാരണം ചില എഡ്ജ്-കേസ് ഫീച്ചറുകൾക്ക് എൻക്രിപ്റ്റ് ചെയ്ത ഉള്ളടക്കം ഇതുവരെ പിന്തുണയ്ക്കാനാകാത്തതായിരിക്കാം എന്നതാണ്. ഇവ അപൂർവമാണ്, സജീവമായി പരിഹരിച്ചുകൊണ്ടിരിക്കുകയാണ്. ഈ സാധ്യതയുള്ള പ്രശ്നങ്ങൾ ഉണ്ടായാലും ഡാറ്റ പൂർണ്ണമായി എൻക്രിപ്റ്റ് ചെയ്യുകയും സംരക്ഷിക്കുകയും ചെയ്തിരിക്കുന്നു.
beta-യിൽ നിന്ന് GA-യിലേക്ക് മൈഗ്രേഷൻ ഘട്ടങ്ങളുണ്ടാകുമോ.
ഇല്ല. എൻക്രിപ്ഷൻ beta ഉപയോഗിക്കുന്ന വർക്ക്സ്പേസുകൾ ഉപയോക്തൃ നടപടി ഒന്നുമില്ലാതെ GA-യിൽ സ്വയമേവ പിന്തുണയ്ക്കപ്പെടും.
കൂടുതൽ സാങ്കേതിക വിശദാംശങ്ങൾ
എൻവലപ്പ് എൻക്രിപ്ഷനും അനുമതികളും
EKM-നായി OpenAI-ക്ക് GenerateDataKey അനുമതികൾ നൽകേണ്ടതുണ്ടോ.
ഇല്ല. നിങ്ങളുടെ KMS കീയിൽ OpenAI-ക്ക് Encrypt, Decrypt അനുമതികൾ മാത്രം ആവശ്യമാണ്. EKM ഇന്റഗ്രേഷനായി GenerateDataKey അനുമതി ആവശ്യമില്ല.
ഉപഭോക്തൃ ഡാറ്റയ്ക്ക് OpenAI എൻവലപ്പ് എൻക്രിപ്ഷൻ ഉപയോഗിക്കുന്നുണ്ടോ.
ഉണ്ട്. OpenAI ഒരു എൻവലപ്പ് എൻക്രിപ്ഷൻ മാതൃക ഉപയോഗിക്കുന്നു:
ഉപഭോക്തൃ KMS: കീ എൻക്രിപ്ഷൻ കീകൾ (KEK-കൾ) മാനേജ് ചെയ്യുന്നു. OpenAI ഒരിക്കലും KEK-കൾ കാണുകയോ സംഭരിക്കുകയോ ചെയ്യുന്നില്ല.
OpenAI ഇൻഫ്രാസ്ട്രക്ചർ: ഡാറ്റ എൻക്രിപ്ഷൻ കീകൾ (DEK-കൾ) സൃഷ്ടിക്കുകയും മാനേജ് ചെയ്യുകയും ചെയ്യുന്നു. സംഭരണത്തിന് മുമ്പ് ഓരോ DEK-യും നിങ്ങളുടെ KEK ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു (റാപ്പ് ചെയ്യപ്പെടുന്നു).
ഡാറ്റ പ്രവാഹം:
ഉപഭോക്തൃ ഡാറ്റ DEK ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു.
ആ DEK നിങ്ങളുടെ KEK ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുകയും ഒരു eDEK ഉണ്ടാകുകയും ചെയ്യുന്നു.
eDEK എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റയ്ക്കൊപ്പം സംഭരിക്കപ്പെടുന്നു.
ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യാൻ, OpenAI നിങ്ങളുടെ KMS-നോട് eDEK ഡീക്രിപ്റ്റ് ചെയ്യാൻ അഭ്യർത്ഥിച്ച് DEK വീണ്ടെടുക്കുകയും ഉള്ളടക്കം ഡീക്രിപ്റ്റ് ചെയ്യുകയും ചെയ്യുന്നു.
KMS-ന് KEK-കളും DEK-കളും രണ്ടും മാനേജ് ചെയ്യാൻ അനുവദിക്കുന്നതിന് പകരം OpenAI ഈ മാതൃക തെരഞ്ഞെടുത്തത് എന്തുകൊണ്ട്.
രണ്ട് പൊതുവായ എൻവലപ്പ് എൻക്രിപ്ഷൻ സമീപനങ്ങളുണ്ട്:
KMS നിയന്ത്രിക്കുന്ന KEK-കളും DEK-കളും:
നേട്ടങ്ങൾ: നടപ്പാക്കൽ ലളിതമാണ്, എൻക്രിപ്ഷൻ ഇൻഫ്രാസ്ട്രക്ചർ പരിപാലിക്കേണ്ടതില്ല.
പ്രതികൂലതകൾ: ഓരോ എൻക്രിപ്ഷൻ/ഡീക്രിപ്ഷൻ അഭ്യർത്ഥനയും KMS-ലേക്ക് പോകുന്നതിനാൽ ലേറ്റൻസിയും ചെലവും കൂടുകയും ഒറ്റ പരാജയബിന്ദു ഉണ്ടാകുകയും ചെയ്യുന്നു.
KMS നിയന്ത്രിക്കുന്ന KEK-കൾ / OpenAI നിയന്ത്രിക്കുന്ന DEK-കൾ (ഞങ്ങളുടെ സമീപനം):
നേട്ടങ്ങൾ: ലേറ്റൻസിയും ചെലവും ഗണ്യമായി കുറയും, സ്കെയിലബിലിറ്റിയും വിശ്വാസ്യതയും മെച്ചപ്പെടും, ഭാഗിക KMS തടസ്സങ്ങളിലുമെല്ലാം പ്രവർത്തനം തുടരും (DEK കാഷ് TTL വരെ).
പ്രതികൂലതകൾ: OpenAI-യുടെ ഭാഗത്തെ നടപ്പാക്കൽ അല്പം കൂടുതൽ സങ്കീർണ്ണമാണ്.
ഉപഭോക്താക്കൾക്ക് പ്രവർത്തന അപകടസാധ്യതയും ചെലവും കുറയ്ക്കുന്നതിനൊപ്പം ശക്തമായ സുരക്ഷാ ഉറപ്പുകൾ നൽകാൻ ഈ രൂപകൽപ്പന OpenAI-യെ സഹായിക്കുന്നു.
DEK-കൾ എത്ര ഇടവേളകളിലാണ് റൊട്ടേറ്റ് ചെയ്യുന്നത്.
ഓരോ DEK-യും ഏകദേശം ഓരോ 60 മിനിറ്റിലും റൊട്ടേറ്റ് ചെയ്യപ്പെടുന്നു. ഇത് സമയപരമായ വേർതിരിവ് നൽകുന്നു — ഏതെങ്കിലും വിധത്തിൽ ഒരു DEK സുരക്ഷിതത്വം നഷ്ടപ്പെട്ടാലും, ആഘാതം ആ ഒരു മണിക്കൂർ കാലയളവിൽ എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റയിലേക്ക് മാത്രം പരിമിതപ്പെടും.
KMS അഭ്യർത്ഥന വോളിയവും നിരീക്ഷണക്ഷമതയും
ഉപയോക്തൃ സന്ദേശങ്ങളുടെ എണ്ണത്തേക്കാൾ വളരെ കുറച്ച് KMS അഭ്യർത്ഥനകളാണ് ഞങ്ങൾ കാണുന്നത്. ഈ സംഖ്യകൾ പൊരുത്തപ്പെടേണ്ടതുണ്ടോ.
ഇല്ല, അവ നേരിട്ട് ബന്ധപ്പെടുകയില്ല.
പ്രകടന കാരണങ്ങളാൽ OpenAI DEK-കൾ മെമ്മറിയിൽ കാഷ് ചെയ്യുന്നതിനാൽ, ഒരു DEK ഡീക്രിപ്റ്റ് ചെയ്യേണ്ടപ്പോൾ മാത്രമേ KMS കോളുകൾ ഉണ്ടാകൂ — ഓരോ എൻക്രിപ്ഷൻ അല്ലെങ്കിൽ ഡീക്രിപ്ഷൻ പ്രവർത്തനത്തിലും അല്ല. ഫലമായി, നിങ്ങൾ പ്രതീക്ഷിക്കേണ്ടത്:
ഉപയോക്തൃ ഇടപെടലുകളേക്കാൾ കുറച്ച് KMS അഭ്യർത്ഥനകൾ.
കാഷ് ചെയ്ത DEK-കളുടെ കാലാവധി തീരുമ്പോഴോ (ഏകദേശം ഓരോ മണിക്കൂറിലും) പഴയ എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റ ആക്സസ് ചെയ്യേണ്ടിവരുമ്പോഴോ അപ്പോഴപ്പോഴുള്ള ഉയർച്ചകൾ.
ഒരു ഉപയോക്താവ് ദീർഘകാല സംഭാഷണം തുടരുകയും പഴയ DEK-കൾ ലോഡ് ചെയ്യേണ്ടിവരികയും ചെയ്യുന്നതുപോലെ, ചരിത്ര ഡാറ്റ വീണ്ടെടുക്കുമ്പോൾ അധിക കോളുകൾ.
KMS അഭ്യർത്ഥനകളുടെ കൃത്യമായ എണ്ണം കാഷിംഗ് നില, ഉപയോക്തൃ പെരുമാറ്റം, ഡാറ്റ ആക്സസ് പാറ്റേണുകൾ, സംഭാഷണ ദൈർഘ്യം എന്നിവയെ ആശ്രയിക്കുന്നു. അതിനാൽ അത് സന്ദേശ വോളിയവുമായി നേരിട്ട് ബന്ധപ്പെടുകയില്ല.