Junior Developer တွေအတွက် Security Practices

project တခုစရေးတော့မယ်ဆိုရင် junior ဘဝမှာ ဘယ်သူမှ သိပ်စဥ်းစားလေ့မရှိတဲ့ကိစ္စက security ပဲ။ ကိုယ်တိုင်လည်း ငယ်ရာက ကြီးလာတာပဲမို့ အဲဒါနဲ့ပတ်သက်ပြီး အပြစ်မတင်ရက်ပါဘူး။ ဒါပေမယ့် security ဆိုတာ software ရေးလို့ပြီးသွားလို့ user တွေစသုံးမယ်ဆိုကာမှ နောက်ကလိုက်ထည့်ရမယ့်အရာမဟုတ်ပဲ စစချင်း application နဲ့ system design မှာကတည်းက ကြိုစဥ်းစားလုပ်ခဲ့ရမှာမျိုးဖြစ်တယ်။

အင်္ဂလိပ်တွေက လူတယောက်ကို အမြင်ကတ်ရင် စာလုံး အဖြတ်အရပ် သင်ပေးလိုက်ပါလို့ပြောတယ်။ ဘယ်တော့မှ သူ့မျက်လုံးထဲက ထုတ်လို့ရမှာ မဟုတ်တော့လို့။ software engineering မှာဆိုရင် အဲဒါက security ဖြစ်လောက်တယ်။ security ကိုတခါလောက်ပဲ အလေးထားလုပ်ဖူးလိုက်ပြီးရင် နောက်ကျ secure မဖြစ်တဲ့ system တွေမြင်ရတိုင်း မျက်စိစပါးမွှေးစူးနေတော့မှာ။

Security အကြောင်း ပြောတဲ့အခါ ကျွန်တော်ကတော့ မြင်ရလွယ်အောင် အလွှာလိုက်ဖြတ်ပြီး ပြောပြလေ့ရှိတယ်။ ဒီထဲကမှ common ဖြစ်ပြီး လိုက်လုပ်ရတာ မခက်တဲ့ checklist လေးတွေကို ရွေးပြောပြမယ်။

1) development အဆင့်မှာ ဒါတွေလုပ်စေချင်တယ်။

code စရေးပြီဆိုတည်းက bad practice တွေကို သတိထားပါ။ OOP သုံးတဲ့အခါ access modifier တွေ ဥပမာ private နဲ့ public တွေကိုသေချာသုံးတာမျိုး။ input တွေကို သေချာ validate နဲ့ sanitize လုပ်ပါ။ database statement တွေကို named parameter တွေသုံးပါ။ error handling သေချာ လုပ်ပါ။ condition တွေကို switch တို့၊ when တို့နဲ့ ဖမ်းတဲ့အခါ default မှာဖြစ်လာနိုင်တဲ့ edge case တွေကို သေချာစဥ်းစားပါ။ concurrent code တွေရေးတဲ့အခါမှာ deadlock မဖြစ်စေဖို့ mutex တွေ semaphore တွေကိုသေချာစိစစ်တာ memory ကိုကိုယ်တိုင် manage လုပ်တဲ့အခါ memory leak မဖြစ်စေဖို့နဲ့ dangling pointer တွေကို ဂရုစိုက်ပါ။

3rd party library တွေသုံးတဲ့အခါ documentation သေချာဖတ်ပါ။ security hot fix တွေထွက်လာရင် ကိုယ်ပါ version လိုက်မြှင့်ပါ။ semvar (major.minor.patch) ပုံစံမှာ ကိုယ်က major version တခု ဥပမာ 2.7.5 ကနေ 3.0.12 ကိုတင်ပြီဆိုရင် breaking change တွေပါလာပြီဆိုတဲ့ သဘောဖြစ်တာမို့ changelog သေချာလိုက်ဖတ်ပြီး ပြင်သင့်တာပြင်ပါ။

ဖြစ်နိုင်ရင် unit test case တွေရေးပြီး TDD စတိုင်သွားစေချင်တယ်။ TDD ဘာလဲမသိရင် ရှေ့မှာရေးခဲ့ဖူးတာရှိတယ်။ အောက်ဆုံးမှာ link တွေထည့်ထားပေးမယ်။ တကယ်လို့ ကိုယ့် organization ကသာ အချိန်ရရင် BDD စတိုင်လ် integration test တွေပါလုပ်စေချင်တယ်။ မျက်လုံးထဲ မြင်အောင် ပြောရရင် unit test က ရေးနေတာမှန်ရဲ့လားဆိုတာကို စစ်တာဖြစ်ပြီးတော့ BDD test တွေကကျ ရေးရမယ့် feature အမှန်ကို ရေးနေရဲ့လားလို့ စစ်တာပေါ့လေ။

2) integration အဆင့်ရောက်ရင် ဒါတွေလုပ်စေချင်တယ်။

ဒီအဆင့်မှာ အဓိကက CI/CD pipeline ရှိရမယ်။ developer တွေက integration branch ဆီ code တွေမကြာခဏ push နေရမယ်။ Git က Decentralized VCS ဖြစ်တာမလို့ central server မလိုအပ်ဘူး ဒါပေမယ့် GitHub, BitBucket စသဖြင့် cloud repository တခုခုမှာ repository ဆောက်ပြီး central repository ပါလို့သဘောတူပြီး သုံးကြတယ်။ အဲဒီ repo မှာ access control ကိုသေချာပိတ်ထားဖို့ လိုအပ်တယ်။ ဥပမာ main branch ကိုဘယ်သူကမှတိုက်ရိုက် push ခွင့်မရှိဘူးဆိုတာမျိုး။

CI pipeline မှာ UnitTest တွေ run ဖို့၊ code ထဲသုံးထားမိတဲ့ package တွေထဲ Known CVE ရှိတာတွေ ပါသလား စစ်ဖို့နဲ့ ကိုယ်ရေးထားတဲ့ code ကို standard formatting လုပ်တာ နောက်ပြီး security vulnerability ပါသလား သိရဖို့ quality check တွေလုပ်တာ ဒါတွေမမေ့သင့်ဘူး။ အရေးကြီးဆုံးက database password တွေ၊ API key တွေနဲ့ secret တွေက ဘယ်တော့မှ code ထဲရှိမနေတာ သေချာဖို့ လုပ်ရမယ်။

Containerization လုပ်တဲ့အခါ image တွေကို သေချာ sign ထိုးရမယ်။ ဒါမှ container runtime ပေါ်ရောက်တဲ့အခါမှာ ဒီ image တွေရဲ့ integrity, authenticity ကိုအာမခံနိုင်မယ်။ တကယ်လို့ Kubernetes သုံးတယ်ဆိုရင်ကိုယ့် Helm Chart တွေမှာ syntax ပြဿနာ security ပြဿနာတွေပါလားသိရဖို့ စစ်ရမယ်။ Linux capability တွေအလွန်အကျူးပေးထားမိလား စစ်ရမယ်။ CD pipeline ကလည်း development server, staging စသဖြင့် အဆင့်ဆင့် test ပြီး promote လုပ်သွားပေးနိုင်ရမယ်။ လုံလောက်အောင် မစစ်ထားရသေးတဲ့ ဘယ် code မျိုးကိုမှ production server ဆီယူမသွားရဘူး။

3) Transport အလွှာမှာ ဒါတွေလုပ်စေချင်တယ်။

ဘယ် application တွေကဘယ် endpoint တွေကို ခေါ်လို့ရမလဲဆိုတာ သေချာ သတ်မှတ်ပါ။ DDoS ကနေ ကာကွယ်ဖို့ service တခုချင်းစီမှာ rate limiting ထည့်ပါ client တွေမှာလည်း circuit breaker ထည့်ပါ။ Cloud Provider တွေရဲ့ backbone internet ကွန်ယက်ကြီးက ဘယ်လောက်ပဲ secure ဖြစ်ပါတယ် ပြောပြော ကိုယ့်ရဲ့ service တွေအချင်းချင်းကြား connection တွေကို TLS နဲ့ encrypt လုပ်ပါ။ cluster အပြင်ဖက် egress ကိုထွက်တဲ့အခါမှာလည်း TLS မဟုတ်တဲ့ destination တွေကို outbound မပေးပဲ ပိတ်ပါ။ Ingress အတွက် application တွေရှေ့မှာ proxy ခံရမှာဖြစ်သလို certificate တွေကိုလည်းသက်တမ်းမကုန်ခင် rotate လုပ်ပေးဖို့လိုတယ်။

4) Server Environment မှာဒါတွေလုပ်စေချင်တယ်။

server ပေါ်ရောက်လာမယ့် image artifact တွေကယုံကြည်ရတဲ့ source ကလာတာဟုတ်မဟုတ် စစ်ရမယ်။ သုံးခွင့်ရှိတဲ့ image တွေကို whitelist လုပ်ထားရမယ်။ Node တွေအတွက် attack surface သေးတဲ့ OS မျိုးကို ရွေးသုံးသင့်တယ်။ ဥပမာ Amazon ရဲ့ Bottlerocket ပေါ့။ သူက container တွေ run ဖို့ရည်ရွယ်တဲ့ package manager မပါပဲ immutable OS ပုံစံ။ အရေးကြီးတဲ့ service တွေ ဥပမာ payment processor လိုမျိုးတွေကို audit compliance အတိုင်း hardened လုပ်ထားတဲ့ Node တွေပေါ်မှာပဲ schedule လုပ်နိုင်ဖို့အတွက် ပြင်ဆင်ထားရမယ်။

နောက် sensitive data တွေကို encrypt မလုပ်ပဲနဲ့ disk ပေါ်ဘယ်တော့ မရေးမိဖို့ တတ်နိုင်သလောက် ရှောင်ရှားရမယ်။ ဖြစ်နိုင်ရင် memory ပေါ်မှာပဲ ထားပါ။ sensitive data တွေကိုလည်း Central Server တခုခု (AWS Secrets Manager, HashiCorp's Vault) ကနေ အမြဲတမ်း rotate လုပ်ပေးဖို့ လိုတယ်။ Log နဲ့ metrics တွေကို central server တခုဆီပို့ပါ။ လိုအပ်ရင် analysis လုပ်ပြီး မြင်နေကျ ပုံမှန်မဟုတ်တဲ့ anormaly တွေကို စောစော detect လုပ်နိုင်ရမယ်။

5) Network မှာဒီအချက်တွေ ဂရုစိုက်စေချင်တယ်။

အင်တာနက်ကနေ တိုက်ရိုက် inbound access မလိုအပ်တဲ့ စက်တိုင်းကို private subnet ထဲပို့ပါ။ database တွေ node တွေ queue တွေစသဖြင့် ဒါတွေမျိုးကို public subnet ထဲမထားရပါဘူး။ Firewall နဲ့ NACL တွေကို သေချာ configure လုပ်ပါ။ CDN သုံးပါ။ performance ကိုပိုကောင်းစေသလို security ဖက်က ကြည့်ရင်လည်း DDoS ဖို့အများကြီး ပိုခက်သွားစေတယ်။

ဒါပါပဲ။ ဒီအချက်တွေလုပ်ဖြစ်ရင်ကို တော်တော်လေး solid ဖြစ်သွားလိမ့်မယ်။ bonus ၂ ချက်လောက် ထပ်ပြောရမယ်ဆိုရင် service တခုချင်းစီအတွက်လည်း IAM permission တွေကို တတ်နိုင်သလောက် အနည်းဆုံး ပေးဖို့နဲ့ လိုအပ်လာရင် security breach ကိုစောစောသိရအောင် monitoring နဲ့ alerting တွေသေချာဆင်ထားဖို့ ဖြစ်လိမ့်မယ်။