AWS က ပေးတဲ့ သင်ခန်းစာ
A true story of how I accidentally caused a production server mishap at my company
Intro
DevOps မဟုတ်ပေမယ့်လည်း အခုအလုပ်မှာက sysadmin မခန့်ထားလို့ မျက်ရည်စက်လက်နဲ့ပဲ server ပိုင်းကိုင်ရတယ်။ အလုပ်ဝင်ပြီး ၁လအကြာ project နဲ့လည်း ရင်းနှီးစလည်းပြုနေပြီ၊ assign တွေရေးရတာလည်း အီလာလို့ server optimization လုပ်မယ်လို့အကြောင်းပြပြီး AWS ကို ဝင်ကလိရာကနေ ဒီဇတ်လမ်းလေး စတော့တာပါပဲ။
The Calm before the Storm
Services တွေက maintenance မလုပ်တာ တော်တော်ကြာပြီ။ Route53, S3 နဲ့ CloudFront က မလိုတဲ့ဟာတွေ ဖျက်တယ်။ EC2 servers တွေကို အစကနေပြန် build လုပ်တယ်၊ instance type တွေကို T2 ကနေ T3/T4 ပြောင်းတယ်။ Security policy နဲ့ platform version တွေ upgrade လုပ်တယ်၊ တော်တော်စုံစုံပဲ။ လုပ်ပြီး ပြန်စမ်းကြည့်သမျှကလည်း အဆင်ပြေနေတော့ ပျော်ရွှင်နေတာပဲ။
It Caught the Attention of AWS Team
အဲလိုလုပ်နေရင်းနဲ့ပဲ AWS ကနေ “Irregular activity in your AWS account…bla bla…” ဆိုပြီး message ရောက်လာတော့တာပဲ။ နာရီပိုင်းအတွင်းမှာကို activity စုံတာရယ်၊ Aussie မှာ သုံးနေကျ root account မို့ new location detect ဖြစ်လို့လည်း ပါမယ်။
ဖတ်ကြည့်လိုက်တော့လည်း password change ဖို့၊ CloudTrail တစ်ချက်ဝင်ကြည့်ဖို့ ဘာညာဆိုတော့ အဲလောက်ကြီး အလေးထားမနေဘူး။ AWS support team ကနေလည်း ၃ခါလောက် ဆက်တိုက်ပို့တယ်။ “I don’t give a fuck” ဆိုပြီး ဆက်လုပ်နေတာပဲ။
Things Get Serious…
ဖြစ်ချင်တော့ EBS production ရဲ့ instance type ကို upgrade လုပ်နေတုန်း account ကို restrict လုပ်ချလိုက်တယ်။ New instance ကိုလည်း ပြောင်းမသွားဘူး၊ old instance ကိုလည်း rollback ပြန်ဆင်းလို့မရဘူး။ “This account is currently blocked and not recognized as a valid account. Please contact….” ဆိုပြီး ပြတော့တာပဲ။
အဲဒိအချိန်မှာ world wide users ၃သောင်းကျော်ရှိတဲ့ production server က ထိုးရပ်၊ ငါတော့ စောက်ပြဿနာတက်ပြီဟေ့ဆိုပြီး ခေါင်းကိုကြိမ်းထွက်သွားတာပဲ။ သေချာအာရုံစိုက်လိုက်ရင် နားထင်က သွေးကြောတွေ တဒုတ်ဒုတ်နဲ့ခုန်နေတာတောင် သတိထားမိလောက်မယ်။
Security Checkup with AWS Team
စောနက EBS ကလွဲလို့ ကျန်တဲ့ services တွေတော့ အကုန်ဆက်အလုပ်လုပ်နေတယ်။ ဒါပေမယ့် modify လုပ်လို့မရသလို new instance လည်း ပေးမဆောက်ဘူး။ အဲတော့ ဘာမှဆက်လုပ်လို့မရပဲ လုံးဝ jam ဖြစ်နေပြီ။
အဲမှာ google အားကိုး၊ forum တွေလည်း အသည်းအသန်လိုက်ဖတ်၊ AWS ကိုလည်း email ပို့၊ AWS support service မှာလည်း စကားသွားပြောပေါ့။ အဲမှာ တိုက်ဆိုင်တာလား၊ policy အရလားတော့ မသိ၊ ကိုယ်ရေးတဲ့ comment ကို နာရီနဲ့ချီတဲ့အထိ လုံးဝ reply မပြန်ဘူး။ နောက်ဆုံး account owner ဖြစ်တဲ့ founder ကို သွားပင့်ရတယ်၊ အဲကျတော့ မိနစ်ပိုင်းနဲ့ ပြန်တယ်။ နောက်သူတို့မေးတဲ့ဟာတွေ သေချာပြန်ဖြေပေးရတယ်။
The Recovery Stage
Security questions တွေ အကုန်ဖြေပြီးတောင် account ပြန်ပွင့်ဖို့က ကြာဦးမယ်လို့ ခန့်မှန်းမိတယ်။ အဲမှာစဥ်းစားမိတာက လက်ရှိ staging server ကို production နေရာခဏသုံးဖို့ပဲ။ Route53 မှာ staging server နဲ့ production dns record ကို route ပေးမယ်၊ .env တွေလဲမယ်၊ staging url ကို access denied လုပ်မယ် စသည် steps တွေ အကုန်ချရေးတာပဲ။
Server swap ရတာ risk တော့များတယ်၊ ဒါပေမယ့် နောက်ဆုံးမှာအလုပ်ဖြစ်သွားတယ်။ အဲတာတောင် AWS team က မပိတ်ပါစေနဲ့ဆိုပြီး ရင်တမမနဲ့ လုပ်ရတာ။ ဒါတောင် configuration တွေလွဲပြီး queue worker တွေ ရပ်နေလို့ နည်းနည်းကွိုင်လိုက်သေးတယ်။
Final Thought — The Lesson Learn
သင်ခန်းစာရတာတော့ AWS team က email တွေလာလို့ရှိရင် သေချာဖတ်ဖို့ပဲ။ အမှန်အတိုင်းပြောရရင် security အဲလောက်ကျပ်မယ်မှန်း မထင်ထားဘူး။ Production server ထိနေလို့ မြန်မြန်လုပ်ပေးဖို့ပြောတာတောင် သူတို့ process အတိုင်း ပုံမှန်ပဲသွားတယ်။ စဖြစ်တဲ့နေ့ကနေ full access ပြန်ရတဲ့အထိ ၂ရက်ခွဲလောက်ကြာသွားတယ်။
ပြီးတော့ staging server အရန်ထားတာ testing အတွက်တင်မဟုတ်ပဲ ခုလိုကိစ္စတွေမှာ အရေးပေါ်သုံးလို့ရတယ်ဆိုတာ သိသွားတယ်။ တစ်ခုရှိတာ server swap တဲ့အခါသတိတော့ကြီးကြီးထားပေါ့၊ အခန့်မသင့်ရင် ကိုယ့် database တစ်ခုလုံးပြောင်သွားမယ်။
