လွယ်လွယ်ပြောရရင် Shared Responsibility Model ဆိုတာ Cloud သုံးတဲ့အခါ လုံခြုံရေးတာဝန်ကို Cloud ကုမ္ပဏီနဲ့ သုံးတဲ့သူတို့ နှစ်ဖက် ခွဲဝေယူရတဲ့ သဘောတူညီချက်ပါ။ Cloud ကုမ္ပဏီက အခြေခံအဆောက်အအုံကို လုံခြုံအောင် လုပ်ပေးတယ်၊ သုံးတဲ့သူက ကိုယ့်ရဲ့ Data နဲ့ Setting တွေကို လုံခြုံအောင် လုပ်ရတယ်။ “Cloud ပေါ်ရောက်သွားပြီဆိုတော့ လုံခြုံပြီ” လို့ ထင်လိုက်ရင် အဲဒါက အမှားကြီးပါ။
ကျွန်တော် ဒါကို တိုက်ခန်းငှားနေတာနဲ့ ယှဉ်ပြီး နားလည်သွားတယ်။ တိုက်ခန်းပိုင်ရှင်က အဆောက်အအုံရဲ့ တံခါး၊ လုံခြုံရေးဝန်ထမ်း၊ မီးသတ်စနစ်တို့ကို တာဝန်ယူတယ်။ ဒါပေမယ့် သင့်အခန်းရဲ့ တံခါးကို သော့ခတ်ဖို့၊ သင့်ပစ္စည်းတွေကို သေချာ သိမ်းဖို့က သင့်တာဝန်ပါ။ အခန်းတံခါးဖွင့်ထားပြီး ပစ္စည်းပျောက်သွားရင် “ပိုင်ရှင်က လုံခြုံရေးမလုပ်ပေးလို့” လို့ ပြောလို့မရဘူး။ Cloud ကလည်း အဲဒီအတိုင်းပါပဲ။
ဘယ်သူက ဘာကို တာဝန်ယူလဲ?
တာဝန်ခွဲတာကို အလွှာအလိုက် ကြည့်ရင် ရှင်းပါတယ်။ AWS, Google Cloud, Azure တို့လို ကုမ္ပဏီတွေက ဒီပုံစံနဲ့ ရှင်းပြလေ့ရှိပါတယ်။
Cloud ကုမ္ပဏီ (Provider) ရဲ့ တာဝန် — “Security OF the Cloud” လို့ ခေါ်ပါတယ်။
Data Center အဆောက်အအုံရဲ့ လုံခြုံရေး၊ လျှပ်စစ်မီး၊ အအေးပေးစနစ်
Server တွေရဲ့ Hardware ကို ထိန်းသိမ်းတာ
Network အခြေခံအဆောက်အအုံကို ကာကွယ်တာ
Virtualization Software (Hypervisor) ကို လုံခြုံအောင် လုပ်တာ
သုံးတဲ့သူ (Customer) ရဲ့ တာဝန် — “Security IN the Cloud” လို့ ခေါ်ပါတယ်။
ကိုယ့်ရဲ့ Data ကို ကုဒ်နဲ့ ဖုံးတာ (Encryption)
ဘယ်သူက ဘာကို ဝင်ကြည့်လို့ရလဲဆိုတဲ့ Permission တွေ သတ်မှတ်တာ
Password တွေ၊ API Key တွေကို လုံခြုံအောင် သိမ်းတာ
ကိုယ်သုံးတဲ့ App တွေရဲ့ Setting တွေကို မှန်မှန်ကန်ကန် ချိန်တာ
OS နဲ့ Software Update တွေကို လုပ်တာ (ကိုယ်တိုင် Server ငှားထားရင်)
အရေးကြီးတဲ့ အချက်က သုံးတဲ့ Service အမျိုးအစားပေါ်မူတည်ပြီး တာဝန်ခွဲတဲ့မျဉ်းက ရွေ့သွားတာပါ။
Service အမျိုးအစားအလိုက် တာဝန်က ဘယ်လိုပြောင်းလဲ?
Cloud ဆိုတာ ဘာလဲဆိုတဲ့ Post မှာ IaaS, PaaS, SaaS ဆိုတာ ပြောခဲ့ဖူးပါတယ်။ အဲဒီ အမျိုးအစားအလိုက် တာဝန်က ဒီလိုပြောင်းပါတယ်။
IaaS (ဥပမာ AWS EC2, VPS) — ကုမ္ပဏီက Hardware အထိပဲ တာဝန်ယူတယ်။ OS, App, Data အားလုံး သင့်တာဝန်ပါ။ တိုက်ခန်းအလွတ်ငှားပြီး ပရိဘောဂအားလုံး ကိုယ်တိုင်ဝယ်ရသလိုပေါ့။
PaaS (ဥပမာ Heroku, Google App Engine) — ကုမ္ပဏီက OS နဲ့ Runtime အထိ တာဝန်ယူတယ်။ သင်က ကိုယ့် Code နဲ့ Data ကိုပဲ တာဝန်ယူရတယ်။ ပရိဘောဂပါတဲ့ အခန်းငှားသလိုပေါ့။
SaaS (ဥပမာ Gmail, Google Drive, Dropbox) — ကုမ္ပဏီက အရာရာနီးပါး တာဝန်ယူတယ်။ သင်က Password ကို လုံခြုံအောင်ထားတာ၊ ဘယ်သူနဲ့ File တွေကို Share လဲဆိုတာကိုပဲ တာဝန်ယူရတယ်။ Hotel မှာ တည်းသလိုပေါ့၊ အခန်းသန့်ရှင်းရေးကအစ Hotel ကလုပ်ပေးတယ်၊ ဒါပေမယ့် အခန်းတံခါး သော့ခတ်ဖို့ကတော့ သင့်တာဝန်ပဲ။
ဒါကြောင့် SaaS သုံးနေရင်တောင် သင့်တာဝန်က လုံးဝ ပျောက်မသွားပါဘူး။ Gmail သုံးနေရင် Google က Server တွေကို လုံခြုံအောင် လုပ်ပေးတယ်၊ ဒါပေမယ့် သင့် Password ကို သူများသိသွားရင် အဲဒါ သင့်တာဝန်ပါ။
တကယ့်လက်တွေ့မှာ ဘာအမှားတွေဖြစ်တတ်လဲ?
Cloud မှာ ဖြစ်တဲ့ လုံခြုံရေးပြဿနာအများစုက Provider ရဲ့ အမှားကြောင့် မဟုတ်ဘဲ Customer ဘက်က Setting မှားတာကြောင့် ဖြစ်ပါတယ်။ အဖြစ်အများဆုံးတွေက ဒါတွေပါ။
Storage Bucket ကို Public ဖွင့်ထားမိတာ — AWS S3 Bucket ကို Public ထားလိုက်မိလို့ Data တွေ Internet ပေါ်မှာ ပေါ်သွားတာ သတင်းတွေမှာ ခဏခဏ ကြားရပါတယ်။ ဒါက Provider ရဲ့ အမှား မဟုတ်ဘူး၊ သုံးတဲ့သူက Setting မှားတာပါ။
API Key ကို Code ထဲမှာ ထည့်ပြီး GitHub ပေါ် တင်မိတာ — Environment Variable အကြောင်း ရေးခဲ့တုန်းက ဒါကို သတိပေးခဲ့ဖူးပါတယ်။
Admin Permission ကို လူတိုင်းကို ပေးထားမိတာ — တစ်ယောက်ရဲ့ အကောင့် ချိုးဖောက်ခံရတာနဲ့ System တစ်ခုလုံး ပျက်သွားတယ်။
Backup မလုပ်ထားမိတာ — Provider က Server ကို လုံခြုံအောင် လုပ်ပေးပေမယ့် သင့် Data ကို ဖျက်မိရင် ပြန်ယူဖို့က သင့်တာဝန်ပါ။ Backup 3-2-1 Rule အကြောင်းလည်း အရင်က ရေးခဲ့ဖူးပါတယ်။
ကိုယ့်အတွက် လက်တွေ့ကျတဲ့ အချက်တွေက ဒါတွေပါ။
Cloud Service သုံးတိုင်း သူ့ရဲ့ Shared Responsibility စာမျက်နှာကို တစ်ခါလောက် ဖတ်ကြည့်ပါ။ ဘယ်အပိုင်းက သင့်တာဝန်လဲဆိုတာ ရှင်းရှင်းလင်းလင်း ရေးထားပါတယ်။
Permission ကို အနည်းဆုံးလိုအပ်သလောက်ပဲ ပေးပါ။ “အားလုံးကို Admin ပေးထားလိုက်ရင် လွယ်တယ်” ဆိုတာ အန္တရာယ်အကြီးဆုံးအလေ့အကျင့်ပါ။
Setting တွေကို ပုံမှန်စစ်ပါ။ အထူးသဖြင့် Storage နဲ့ Database တွေက Public ဖြစ်နေလား၊ မဖြစ်ဘူးလား စစ်ပါ။
Cloud က မှော်ဆန်တဲ့ လုံခြုံရေးသေတ္တာမဟုတ်ပါဘူး။ အဆောက်အအုံကြီးကို သူတို့ စောင့်ရှောက်ပေးတယ်၊ အခန်းတံခါးကို သင် သော့ခတ်ရတယ်။ ဒီခွဲခြားမှုကို သိထားရင် Cloud ပေါ်က သင့် Data က တကယ်လုံခြုံပါလိမ့်မယ်။ 🙂
