Encryption အယူအဆများ

အဆင့်မြင့် လုပ်ငန်းစီးဆင်းပုံ

• OpenAI မမြင်နိုင်သော မာစတာကီးတစ်ခုကို သင့် cloud တွင် သင် ထိန်းချုပ်ထားသည်

• OpenAI အသုံးပြုသည့် ဒေတာ encryption ကီးများ (DEK များ)ကို encrypt လုပ်ရန် သင့်မာစတာကီးကို အသုံးပြုသည်

• OpenAI သည် သိမ်းဆည်းထားစဉ် သင့်ဒေတာကို encrypt လုပ်ရန် DEK များကို အသုံးပြုသည်။ သင့်မာစတာကီးဖြင့် DEK တစ်ခုကို encrypt လုပ်ပြီး eDEK (encrypted DEK) တစ်ခု ထုတ်ပေးကာ ၎င်းကို သင့်ဒေတာနှင့်အတူ သိမ်းဆည်းထားသည်

• ဒေတာကို ဖတ်ရန် OpenAI သည် eDEK ကိုယူပြီး ၎င်းကို DEK အဖြစ် decrypt လုပ်ရန် သင့် KMS ထံ တောင်းဆိုကာ ထို့နောက် သင့်ဒေတာကို decrypt လုပ်သည်

EKM encryption မည်သို့ အလုပ်လုပ်သနည်း။

အသေးစိတ်အချက်အလက်များအတွက် ကျွန်ုပ်တို့၏ ဆောင်းပါးကို ကြည့်ပါ- OpenAI Enterprise Key Management (EKM) ခြုံငုံသုံးသပ်ချက်

OpenAI သည် ကျွန်ုပ်၏ DEK များကို သိမ်းဆည်းပါသလား။

မသိမ်းဆည်းပါ — သင့် KMS က ထုတ်ပေးသော encrypted DEK များ (eDEK များ) ကိုသာ ကျွန်ုပ်တို့ သိမ်းဆည်းသည်။ ဒေတာကို decrypt လုပ်ရန် eDEK ကို DEK အဖြစ် ပြန် decrypt လုပ်ပေးရန် သင့် KMS ထံ ကျွန်ုပ်တို့ တောင်းဆိုသည်။

OpenAI သည် ကျွန်ုပ်၏ DEK များကို cache ထားပါသလား။

ထားပါသည် — memory ထဲတွင်သာ ဖြစ်သည်။ ဒေတာ encrypt/decrypt တောင်းဆိုမှုတိုင်းတွင် သင့် KMS ကို မခေါ်ရစေရန် စွမ်းဆောင်ရည်အတွက် ဤသို့လုပ်ခြင်းဖြစ်သည်။ DEK များကို storage ထဲသို့ ဘယ်တော့မှ မရေးသိမ်းပါ။

Cloud ခွင့်ပြုချက်များ

ကျွန်ုပ်၏ KMS တွင် OpenAI မည်သည့် ခွင့်ပြုချက်များ ရရှိမည်နည်း။

သင်သတ်မှတ်ထားသော policy မှတစ်ဆင့် ကျွန်ုပ်တို့အား ပေးထားသည့် ခွင့်ပြုချက်များသာ ဖြစ်ပါသည်။ အနည်းဆုံး Encrypt/Decrypt လုပ်ဆောင်ချက်များကိုသာ ကျွန်ုပ်တို့ လိုအပ်ပါသည်။ ထို့အပြင် production ရည်ရွယ်ချက်အတွက် အသုံးပြုနေသော ရှိပြီးသားကီးများကို ပြန်လည်မသုံးဘဲ OpenAI အတွက် သင့် cloud KMS တွင် ကီးအသစ်တစ်ခု ဖန်တီးပါ။

ကျွန်ုပ်၏ KMS ကို ဝင်ရောက်အသုံးပြုရန် OpenAI သည် ဘယ်အချိန်တွင် ခွင့်ပြုချက်ရရှိသနည်း။

အောက်ပါအဆင့်အားလုံးကို ပြီးစီးထားရပါမည်-

1. သင်သည် OpenAI ၏ identity ကို အသိအမှတ်ပြုထားပြီးဖြစ်သည် (cloud provider အပေါ် မူတည်၍ trust policy၊ workload identity စသည်တို့မှတစ်ဆင့်)။

2. KMS ကို ဝင်ရောက်အသုံးပြုရန် policy တစ်ခုကို သင် ဖန်တီးထားပြီးဖြစ်သည်။

3. ထို policy ကို ဝင်ရောက်အသုံးပြုရန် ခွင့်ပြုချက်ကို OpenAI ၏ identity ထံ သင် ချထားပေးထားပြီးဖြစ်သည်။

ဤအဆင့်အားလုံး မလုပ်ဘဲ KMS ကိုသာ ဖန်တီးထားပါက OpenAI တွင် ဝင်ရောက်အသုံးပြုခွင့် မရှိပါ။

ကျွန်ုပ်၏ မာစတာကီးကို ကျွန်ုပ်၏ cloud ထဲတွင် သိမ်းထားရန် လိုပါသလား။

မလိုပါ — သင့်မာစတာကီးကို မည်သို့စီမံမည်ဆိုသည်မှာ သင့်ဆုံးဖြတ်ချက်ဖြစ်သည်။ Cloud က စီမံသော ဖြေရှင်းချက်ကို အသုံးပြုနိုင်သလို သင့်ကီးကို သီးခြားသိမ်းဆည်းထားသည့် ပြင်ပဖြေရှင်းချက်ကိုလည်း အသုံးပြုနိုင်သည်။ OpenAI သည် သင့် KMS ပေါ်ရှိ encrypt/decrypt လုပ်ဆောင်ချက်များကို ခေါ်ဆိုနိုင်ရန်သာ လိုအပ်ပါသည် — မာစတာကီးက encrypt/decrypt ကို အမှန်တကယ် မည်သို့လုပ်ဆောင်သည်ဆိုသည်မှာ ကျွန်ုပ်တို့အတွက် မမြင်နိုင်သော အကောင်အထည်ဖော်မှုအသေးစိတ်ဖြစ်သည်။

ကီးအသက်တာစက်ဝန်း

DEK/eDEK လှည့်ပြောင်းခြင်း (OpenAI က ထိန်းချုပ်သည်)

DEK/eDEK များကို ဘယ်နှစ်ကြိမ် လှည့်ပြောင်းသလဲ။

Encryption လမ်းကြောင်းတွင် ၂၄ နာရီတိုင်း (DEK/eDEK ကီးအတွဲကို တောင်းဆိုခြင်း)

Decryption ကီးလမ်းကြောင်းတွင် ၁ နာရီတိုင်း (DEK -> eDEK)

DEK ပြောင်းလဲသောအခါ ကျွန်ုပ် ဘာလုပ်ရန် လိုပါသလား။

မလိုပါ — DEK/eDEK လှည့်ပြောင်းခြင်းကို OpenAI အတွင်းတွင် လုပ်ဆောင်သည်။ သင့်မာစတာကီး ဆက်လက်မှန်ကန်နေသရွေ့ သင့်မာစတာကီးဖြင့် encrypt လုပ်ထားသော မည်သည့် eDEK မဆို DEK အဖြစ် ဆက်လက် decrypt လုပ်နိုင်ပြီး ထို DEK ကို သင့်ဒေတာ decrypt လုပ်ရန် အသုံးပြုသည်။

မာစတာကီး လှည့်ပြောင်းခြင်းနှင့် ရုပ်သိမ်းခြင်း (သင်က ထိန်းချုပ်သည်)

ကီးလှည့်ပြောင်းခြင်းနှင့် ကီးရုပ်သိမ်းခြင်း မည်မျှကြိမ် ဖြစ်ပွားသနည်း။

OpenAI သည် သင့်မာစတာကီးကို မြင်နိုင်ခြင်းမရှိသောကြောင့် ဤအရာကို သင်က သတ်မှတ်သည်။

ကီးလှည့်ပြောင်းခြင်းနှင့် ကီးရုပ်သိမ်းခြင်းတို့၏ ကွာခြားချက်မှာ အဘယ်နည်း။

ကီးရုပ်သိမ်းခြင်းသည် ယခင်ကီးများဖြင့် encrypt လုပ်ထားသော ဒေတာကို ဝင်ရောက်အသုံးပြုခွင့် ဖယ်ရှားခြင်းဖြစ်သည်။ ကီးလှည့်ပြောင်းခြင်းသည် ကီးအသစ်ဖြင့် ဒေတာကို encrypt လုပ်သော်လည်း ယခင်ဒေတာကို ဖတ်ရှုအသုံးပြုခွင့် ဆက်လက်ထားရှိသည်။

ကျွန်ုပ်၏ မာစတာကီးကို ရုပ်သိမ်းလိုက်ပါက ဘာဖြစ်မည်နည်း။

ကီးတစ်ခုကို ရုပ်သိမ်းလိုက်ပါက သို့မဟုတ် ခွင့်ပြုချက်များကို ဖယ်ရှားလိုက်ပါက cache ထားသော ကီးများ သက်တမ်းကုန်သောအခါ အလုပ်နေရာသည် နောက်ဆုံးတွင် အလုပ်မလုပ်နိုင်တော့ပါ။ ထိုအချိန်တွင် OpenAI သည် သိမ်းဆည်းထားသော ဒေတာကို decrypt လုပ်နိုင်တော့မည်မဟုတ်သလို ဒေတာအသစ်ကိုလည်း encrypt လုပ်နိုင်တော့မည်မဟုတ်ပါ။ လက်တွေ့အားဖြင့် ဒေတာကို “ဖျက်စီး” လိုက်ခြင်းဖြစ်သည်။

ရုပ်သိမ်းခြင်းသည် မည်မျှမြန်မြန် အကျိုးသက်ရောက်သနည်း။

OpenAI သည် စွမ်းဆောင်ရည်နှင့် ခံနိုင်ရည်ရှိမှုအတွက် DEK များကို memory ထဲတွင် cache ထားသည်။ Cache ထားသော ကီးများ သက်တမ်းကုန်ပြီး ပြန်လည်အတည်ပြုမှု မအောင်မြင်သောအခါ ရုပ်သိမ်းခြင်းသည် ပုံမှန်အားဖြင့် တစ်နာရီအတွင်း အကျိုးသက်ရောက်သည်။

ရုပ်သိမ်းခြင်းကို ဘေးကင်းစွာ စမ်းသပ်နိုင်ပါသလား။

Production အလုပ်နေရာတွင် ရုပ်သိမ်းခြင်းကို စမ်းသပ်ခြင်းကို အကြံမပြုပါ၊ အကြောင်းမှာ ရှိပြီးသားဒေတာများကို အမြဲတမ်း ဝင်ရောက်အသုံးပြု၍ မရအောင် ဖြစ်စေမည်ဖြစ်သောကြောင့်ဖြစ်သည်။ သို့သော် သုံးစွဲသူများသည် အပြုအမူမှန်ကန်မှုကို အတည်ပြုရန်နှင့် မိမိတို့၏ ယုံကြည်မှုဆိုင်ရာ ခန့်မှန်းချက်များကို စစ်ဆေးရန် sandbox ပတ်ဝန်းကျင်တွင် ရုပ်သိမ်းခြင်းကို စမ်းသပ်နိုင်ပြီး စမ်းသပ်သင့်ပါသည်။

ကီးကို အမြဲတမ်း ရုပ်သိမ်းလိုက်ပါက ကီးအသစ်တစ်ခု ချိတ်ဆက်ပြီး အလုပ်နေရာကို ပြန်လည်ရယူနိုင်ပါသလား။

မရပါ။ ကီးပျောက်ဆုံးသွားသည်နှင့် ဒေတာကို ဒီဇိုင်းအားဖြင့် ပြန်လည်ရယူ၍ မရနိုင်တော့ပါ။ ဖြေရှင်းနိုင်သည့် တစ်ခုတည်းသောနည်းလမ်းမှာ အလုပ်နေရာအသစ်တစ်ခု စတင်ဖန်တီးခြင်းဖြစ်သည်။

ကီးပြောင်းလဲမှုများကြောင့် အလုပ်နေရာကို ဝင်ရောက်အသုံးပြု၍ မရတော့ပါက ဘာလုပ်သင့်သနည်း။

မျှော်မှန်းထားသော ဖြေရှင်းနည်းမှာ အလုပ်နေရာအသစ်တစ်ခု ဖန်တီးခြင်းဖြစ်သည်။ KMS ကို အပ်ဒိတ်လုပ်ခြင်းဖြင့် ရှိပြီးသားဒေတာကို ပြန်လည်ရယူနိုင်မည်မဟုတ်ပါ။

CMEK အသုံးပြုခြင်းကို ရပ်တန့်ရန် ဆုံးဖြတ်ပါက backout plan က ဘာလဲ။

လက်ရှိတွင် backout plan မရှိပါ။ အလုပ်နေရာတစ်ခုကို CMEK ဖြင့် ဖန်တီးပြီးသည်နှင့် ဆက်စပ်ဒေတာအားလုံးကို customer-managed keys ဖြင့် encrypt လုပ်ထားပြီး ထိုကီးများမရှိဘဲ ဝင်ရောက်အသုံးပြု၍ မရနိုင်ပါ။ CMEK အသုံးပြုမှုကို ရပ်တန့်ရန် တစ်ခုတည်းသောနည်းလမ်းမှာ အလုပ်နေရာအသစ်တစ်ခု ဖန်တီးခြင်းဖြစ်သည် — ရှိပြီးသား encrypted ဒေတာသည် အမြဲတမ်း ဝင်ရောက်အသုံးပြု၍ မရနိုင်ဘဲ ဆက်ရှိနေမည်ဖြစ်သည်။

ကျွန်ုပ်၏ မာစတာကီးကို လှည့်ပြောင်းပါက ဘာဖြစ်မည်နည်း။

Encryption အတွက် cryptographic material အသစ် ထုတ်ပေးမည်ဖြစ်သောကြောင့် encryption တောင်းဆိုမှုအသစ်များသည် ကီးအသစ်ကို အသုံးပြုမည်ဖြစ်သည်။ သို့သော် KMS သတ်မှတ်အမှတ်အသား (ARN သို့မဟုတ် ကီးအမည်) သည် မပြောင်းလဲဘဲ ဆက်ရှိနေသည်၊ ဒေတာဟောင်းများကိုလည်း decrypt လုပ်နိုင်ဆဲဖြစ်သည်။ Cloud provider အများအပြားသည် အလိုအလျောက် ကီးလှည့်ပြောင်းခြင်းကို ပေးထားပါသည် (AWS, GCP, Azure)။

ကျွန်ုပ်၏ မာစတာကီးကို လှည့်ပြောင်းသည့်အခါ OpenAI သည် ဒေတာဟောင်းများကို ပြန်လည် encrypt လုပ်ပါသလား။

မလုပ်ပါ။ Cryptographic material အသစ်ကို ဒေတာအသစ် encrypt လုပ်ရန်သာ အသုံးပြုမည်ဖြစ်သည်။

ကီးလှည့်ပြောင်းခြင်း သို့မဟုတ် ကီးရုပ်သိမ်းခြင်း အကျိုးသက်ရောက်ရန် မည်မျှကြာသနည်း။

၁ နာရီ။ အကြောင်းမှာ DEK/eDEK များကို memory ထဲတွင် cache ထားပြီး ၎င်း entry များကို သင့် KMS ဖြင့် နာရီတိုင်း ပြန်လည်အတည်ပြုသောကြောင့်ဖြစ်သည်။

KMS သတ်မှတ်အမှတ်အသား ပြောင်းခြင်း

KMS သတ်မှတ်အမှတ်အသား ပြောင်းခြင်းသည် ကီးရုပ်သိမ်းခြင်းလား သို့မဟုတ် ကီးလှည့်ပြောင်းခြင်းလား။

ကီးရုပ်သိမ်းခြင်း ဖြစ်ပါသည်။ ကီးတစ်ခုသည် အခြားကီးဖြင့် encrypt လုပ်ထားသော ဒေတာကို decrypt မလုပ်နိုင်ပါ။

ChatGPT အလုပ်နေရာတစ်ခုအတွက် ကျွန်ုပ်၏ KMS သတ်မှတ်အမှတ်အသားကို ပြောင်းရာတွင် OpenAI က ကူညီနိုင်ပါသလား။

သင့်ရည်ရွယ်ချက်မှာ ကီးကို ရုပ်သိမ်းရန်ဖြစ်ကြောင်း အတည်ပြုပါက ChatGPT အလုပ်နေရာတစ်ခုအတွက် ဤလုပ်ငန်းကို ကျွန်ုပ်တို့ ကူညီနိုင်ပါသည်။ KMS ARN ကို အပ်ဒိတ်လုပ်သောအခါ ယခင်ဒေတာများသည် ဆက်လက် ဝင်ရောက်အသုံးပြု၍ မရနိုင်သောကြောင့် ပြောင်းလဲပြီးနောက် ဝင်ရောက်မရသော ဒေတာနှင့် ဝင်ရောက်နိုင်သော ဒေတာတို့ ရောနှောနေမည်ဖြစ်ကြောင်း သတိပြုပါ။

API ပရောဂျက်တစ်ခုအတွက် ကျွန်ုပ်၏ KMS သတ်မှတ်အမှတ်အသားကို ပြောင်းရာတွင် OpenAI က ကူညီနိုင်ပါသလား။

API ကို အသုံးပြုနေပါက API သည် ပရောဂျက်များကို archive လုပ်ခြင်းနှင့် အသစ်ဖန်တီးခြင်းကို လွယ်ကူစေသောကြောင့် ဒေတာကို မူလကတည်းက ဝင်ရောက်အသုံးပြု၍ မရတော့သည့် ပရောဂျက်ကို archive လုပ်ပြီး၊ EKM config အသစ်ကို OpenAI တွင် မှတ်ပုံတင်ကာ KMS ကီးအသစ်ဖြင့် API ပရောဂျက်အသစ်တစ်ခု ဖန်တီးပါ။

ကျွန်ုပ်၏ KMS သတ်မှတ်အမှတ်အသားကို ကိုယ်တိုင် ပုံမှန်ပြောင်းလိုပါက မည်သို့လုပ်ရမည်နည်း။

သင့်ကီးကို ပုံမှန်ရုပ်သိမ်းလိုမည် မဟုတ်နိုင်သောကြောင့် ဤနည်းလမ်းကို အကြံမပြုပါ။ သို့သော် KMS ကီး alias ကို ပံ့ပိုးသော cloud provider ကို အသုံးပြုပါက ဤသို့လုပ်နိုင်ပါသေးသည် (AWS ဥပမာ)။ ထို KMS ကီး alias ကို OpenAI တွင် မှတ်ပုံတင်နိုင်ပြီး ထို့နောက် သင့် cloud provider ပေါ်တွင် ကီးရုပ်သိမ်းခြင်း ပြုလုပ်ရန် alias က ညွှန်ပြနေသော အခြေခံ KMS သတ်မှတ်အမှတ်အသားကို အချိန်မရွေး အစားထိုးပြောင်းလဲနိုင်သည်။

Beta နှင့် GA အပြုအမူ

Encryption beta ကို production တွင် အသုံးပြုသောအခါ သိထားသော အန္တရာယ်များ သို့မဟုတ် စနစ်အဆင့် ပြောင်းလဲမှုများ ရှိပါသလား။

Beta ပတ်ဝန်းကျင်သည် လုပ်ဆောင်ချက်အရ GA နှင့် တူညီပြီး migration အဆင့်များ မလိုအပ်ဟု မျှော်မှန်းထားသည်။ အဓိကအန္တရာယ်မှာ code path မပြည့်စုံသေးခြင်းကြောင့် edge-case feature အချို့က encrypted content ကို မပံ့ပိုးနိုင်သေးခြင်းဖြစ်သည်။ ဤအရာများသည် ရှားပါးပြီး တက်ကြွစွာ ဖြေရှင်းနေဆဲဖြစ်သည်။ ဤဖြစ်နိုင်ခြေရှိသော ပြဿနာများ ရှိနေစေကာမူ ဒေတာသည် အပြည့်အဝ encrypt လုပ်ထားပြီး ကာကွယ်ထားပါသည်။

Beta မှ GA သို့ ပြောင်းရန် migration အဆင့်များ ရှိမည်လား။

မရှိပါ။ Encryption beta ကို အသုံးပြုနေသော အလုပ်နေရာများသည် အသုံးပြုသူဘက်မှ မည်သည့်လုပ်ဆောင်ချက်မျှ မလိုဘဲ GA တွင် အလိုအလျောက် ပံ့ပိုးပေးမည်ဖြစ်သည်။

ထပ်ဆောင်း နည်းပညာအသေးစိတ်များ

Envelope Encryption နှင့် ခွင့်ပြုချက်များ

EKM အတွက် OpenAI ကို GenerateDataKey ခွင့်ပြုချက်များ ပေးရန် လိုအပ်ပါသလား။

မလိုအပ်ပါ။ OpenAI သည် သင့် KMS ကီးပေါ်တွင် Encrypt နှင့် Decrypt ခွင့်ပြုချက်များသာ လိုအပ်ပါသည်။ EKM ပေါင်းစည်းအသုံးပြုမှုအတွက် GenerateDataKey ခွင့်ပြုချက် မလိုအပ်ပါ။

OpenAI သည် သုံးစွဲသူဒေတာအတွက် envelope encryption ကို အသုံးပြုပါသလား။

အသုံးပြုပါသည်။ OpenAI သည် envelope encryption မော်ဒယ်ကို အသုံးပြုသည်-

• သုံးစွဲသူ KMS- Key Encryption Keys (KEK များ)ကို စီမံသည်။ OpenAI သည် KEK များကို မမြင်ရသလို သိမ်းဆည်းထားခြင်းလည်း မရှိပါ။

• OpenAI Infrastructure- Data Encryption Keys (DEK များ)ကို ထုတ်လုပ်ပြီး စီမံသည်။ DEK တစ်ခုစီကို သိမ်းဆည်းမီ သင့် KEK ဖြင့် encrypt (wrap) လုပ်သည်။

• ဒေတာစီးဆင်းမှု-

  • သုံးစွဲသူဒေတာကို DEK ဖြင့် encrypt လုပ်သည်။

  • ထို DEK ကို သင့် KEK ဖြင့် encrypt လုပ်ပြီး eDEK တစ်ခု ထုတ်ပေးသည်။

  • eDEK ကို encrypt လုပ်ထားသော ဒေတာနှင့်အတူ သိမ်းဆည်းထားသည်။

  • ဒေတာကို decrypt လုပ်ရန် OpenAI သည် eDEK ကို decrypt လုပ်ရန် သင့် KMS ထံ တောင်းဆိုပြီး DEK ကို ရယူကာ အကြောင်းအရာကို decrypt လုပ်သည်။

KMS ကို KEK များနှင့် DEK များ နှစ်မျိုးလုံး စီမံခိုင်းမည့်အစား OpenAI သည် ဤမော်ဒယ်ကို ဘာကြောင့် ရွေးချယ်ခဲ့သနည်း။

အများသုံး envelope encryption နည်းလမ်းနှစ်မျိုးရှိပါသည်-

KMS က စီမံသော KEK များနှင့် DEK များ-

အားသာချက်များ- အကောင်အထည်ဖော်ရ လွယ်ကူပြီး encryption infrastructure ကို ထိန်းသိမ်းရန် မလိုပါ။

အားနည်းချက်များ- encryption/decryption တောင်းဆိုမှုတိုင်း KMS ကို သွားရောက်ခေါ်ဆိုရသဖြင့် latency နှင့် ကုန်ကျစရိတ် တိုးလာပြီး single point of failure ဖြစ်ပေါ်စေသည်။

KMS က စီမံသော KEK များ / OpenAI က စီမံသော DEK များ (ကျွန်ုပ်တို့၏ နည်းလမ်း)-

အားသာချက်များ- latency နှင့် ကုန်ကျစရိတ်ကို သိသိသာသာ လျှော့ချနိုင်ခြင်း၊ scalability နှင့် reliability ပိုကောင်းခြင်း၊ KMS တစ်စိတ်တစ်ပိုင်း ပြတ်တောက်မှုများအတွင်း ဆက်လက်လည်ပတ်နိုင်ခြင်း (DEK cache TTL အထိ)။

အားနည်းချက်များ- OpenAI ဘက်တွင် အကောင်အထည်ဖော်မှု အနည်းငယ်ပိုရှုပ်ထွေးသည်။

ဤဒီဇိုင်းကြောင့် OpenAI သည် သုံးစွဲသူများအတွက် လည်ပတ်မှုအန္တရာယ်နှင့် ကုန်ကျစရိတ်ကို အနည်းဆုံးဖြစ်စေ하면서 ခိုင်မာသော လုံခြုံရေးအာမခံချက်များ ပေးနိုင်သည်။

DEK များကို ဘယ်နှစ်ကြိမ် လှည့်ပြောင်းသလဲ။

DEK တစ်ခုစီကို ခန့်မှန်းခြေအားဖြင့် မိနစ် ၆၀ တိုင်း လှည့်ပြောင်းသည်။ ဤနည်းဖြင့် အချိန်ကာလအလိုက် သီးခြားကာကွယ်မှု ပေးနိုင်သည် — DEK တစ်ခုသည် တစ်နည်းနည်းဖြင့် ထိခိုက်ခံရပါကပင် သက်ရောက်မှုသည် ထိုတစ်နာရီအတွင်း encrypt လုပ်ထားသော ဒေတာများအထိသာ ကန့်သတ်မည်ဖြစ်သည်။

KMS တောင်းဆိုမှု ပမာဏနှင့် စောင့်ကြည့်နိုင်မှု

KMS တောင်းဆိုမှုအရေအတွက်သည် အသုံးပြုသူမက်ဆေ့ဂျ်အရေအတွက်ထက် များစွာနည်းနေသည်ကို တွေ့ရပါသည်။ ဤအရေအတွက်များ တူညီသင့်ပါသလား။

မတူညီပါ၊ တိုက်ရိုက်ဆက်စပ်မည်မဟုတ်ပါ။

OpenAI သည် စွမ်းဆောင်ရည်အတွက် DEK များကို memory ထဲတွင် cache ထားသောကြောင့် KMS ခေါ်ဆိုမှုများကို encryption သို့မဟုတ် decryption လုပ်ဆောင်ချက်တိုင်းတွင် မလုပ်ဘဲ DEK တစ်ခုကို decrypt လုပ်ရန် လိုအပ်သောအခါမှသာ ပြုလုပ်သည်။ ထို့ကြောင့် သင် မျှော်လင့်သင့်သည်မှာ-

• အသုံးပြုသူ အပြန်အလှန်လုပ်ဆောင်မှုများထက် KMS တောင်းဆိုမှုများ နည်းပါမည်။

• Cache ထားသော DEK များ သက်တမ်းကုန်သောအခါ (တစ်နာရီခန့်တိုင်း) သို့မဟုတ် ယခင် encrypt လုပ်ထားသော ဒေတာကို ဝင်ရောက်ရန် လိုအပ်သောအခါ တစ်ခါတစ်ရံ အမြင့်ဆုံးတက်မှုများ ဖြစ်နိုင်သည်။

• အသုံးပြုသူတစ်ဦးက ကြာမြင့်နေသော စကားဝိုင်းတစ်ခုကို ဆက်လက်အသုံးပြုပြီး ယခင် DEK များကို တင်ရန် လိုအပ်သည့်အခါကဲ့သို့ သမိုင်းကြောင်းဒေတာကို ရယူသောအခါ ထပ်ဆောင်းခေါ်ဆိုမှုများ ရှိနိုင်သည်။

KMS တောင်းဆိုမှု အရေအတွက်အတိအကျသည် cache အခြေအနေ၊ အသုံးပြုသူအပြုအမူ၊ ဒေတာဝင်ရောက်မှုပုံစံများနှင့် စကားဝိုင်းအရှည်တို့အပေါ် မူတည်သောကြောင့် မက်ဆေ့ဂျ်ပမာဏနှင့် တိုက်ရိုက်ဆက်စပ်မည်မဟုတ်ပါ။