စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ

စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ

ဘာမဆိုျဖစ္ႏုိင္တယ္။
software ဆိုတာေတြက ေလေပၚမွာ စိတ္ခ်ရေတာ႔တာမဟုတ္တာၾကာျပီ။ အလြယ္ေျပာရရင္ေတာ႔ အခ်င္းခ်င္းနားနားကပ္ေျပာတာကို အနားက တစ္ေယာက္က ၾကားရသလုိမ်ိဳး၊ သူတုိ႕ဟာသူတို႕ အထာနဲ႕ေျပာလုိ႕ (encrypted) ျဖစ္ေနလို႕ ခ်က္ခ်င္းသေဘာမေပါက္တာသာရိွတယ္။ အဲဒီအထာစကားကို နားလည္တဲ႔သူကို ၾကားခဲ႔တဲ႔စကားကို ျပန္ဖြင္႔ျပႏိုင္ရင္ နားလည္သြားႏုိင္တာနဲ႕ဆင္တယ္။

စင္ကာပူအစိုးရဝဘ္ဆုိဒ္မ်ား။
.gov.sg ေတြမွာ တူညီတာေတြ အမ်ားၾကီးရိွတယ္။ စင္ကာပူက အစိုးရမွာ မူဝါဒတစ္ခ်ိဳ႕ရိွတယ္။ ဥပမာ single sign-on သေဘာမ်ိဳးအတြက္သံုးတာေတြက တစ္ခုနဲ႕တစ္ခုခပ္ဆင္ဆင္ဆိုရမယ္။ Authentication အတြက္ေတာ႔ အဓိက Singpass ကိုသံုးတယ္။ SingPass ကို individual အေနနဲ႕သံုးတယ္ေျပာရမယ္။ စင္ကာပူမွာ လူတုိင္းနီးပါး SingPass ရိွတယ္။ အခြန္ေဆာင္ေဆာင္၊ အစိုးရနဲ႕ပတ္သက္တာဘာလုပ္လုပ္ SingPass က လိုသလိုျဖစ္ေနတယ္။ SingPass ကို Crimson Logic ဆိုတဲ႔ ကုမ္ပနီကေရးတယ္။ Singapore Government websites ေတြရဲ႕ ၉၀ ရာခုိင္ႏႈန္းေက်ာ္ဟာ SingPass authentication ေပၚမူတည္တယ္။ အေနာနမတ္စ္ ေတြဟာ ဒါေတြကို သိမွာပဲ။ စင္ကာပူမွာလည္း အေနာနမတ္စ္ေတြရိွေကာင္းရိွေနမွာကိုး။

SingPass သံုးဖုိ႕ API ကို အစိုးရ websites လုပ္တဲ႔ ရံုးတုိင္းနီးပါးမွာ ရိွတယ္ထင္တယ္။ အဲဒါေတြကလည္း system ေပၚမူတည္တဲ႔အတြက္ system တုိင္းမွာရိွတဲ႔ အားနည္းခ်က္ေတြရိွမွာပဲ။ ေနာက္ထပ္ Authentication ႏွစ္ခုက EASY(e-Services Authorisation System) နဲ႕၊ ကုမ္ပနီေတြအတြက္သံုးတဲ႔ UEN နဲ႕ Login ဝင္တာေတြပဲ။

ေနာက္တစ္ခုက RSA keying လို႕ေခၚတယ္။ ဘဏ္ေတြမွာ 2-factor သံုးသလိုမ်ိဳး၊ စင္ကာပူမွာ အစိုးရ ဝက္ဘ္ဆုိထ္စ္ေတြမွာသံုးတယ္။ first layer provider ေတြထဲမွာေတာ႔ NCS က ေစ်းကြက္ရွယ္ရာေတာ္ေတာ္ရထားတယ္။ medinet.gov.sg ဆိုတာမ်ိဳးပဲ။ အဲဒီကေနမွတစ္ဆင္႔ government network ထဲေနာက္တစ္ဆင္႔ဝင္လုိ႕ရတယ္။ secured channel လုပ္လုိက္တာနဲ႕တူတယ္။ ျပီးေတာ႔ encrypted url ထပ္လုပ္တယ္။ ဆိုလုိတာကေတာ႔ ပထမအဆင္႔ကိုေဖာက္ျပီးမွ ဒုတိယအဆင္႔ကိုေရာက္မယ္။ အဲဒီပထမအဆင္႔ log-in server ကမွသာ ဝန္ၾကီးဌာနအသီးသီးရဲ႕ system ေတြကို သြားႏုိင္တယ္။ အဲဒီမွာ firewall setting ေတြရိွတယ္။ ဆိုလုိတာကေတာ႔ အဲဒါေတြဟာ မိန္းဂိတ္ေပါက္ဝေတြပဲ။ ဒီကေနမွျဖတ္သန္းဝင္ေရာက္ႏုိင္မယ္။ ေနာက္ထပ္ ၾကားေပါက္တစ္ခုေတာ႔ရိွေသးတယ္။ အစိုးရရံုးေတြမွာ ရံုးက အုိင္ပီနဲ႕ဆိုရင္ေတာ႔ production server ကို တိုက္ရိုက္ဖြင္႔ေပးထားတာရိွတယ္။ အဲဒါေတြကေတာ႔ first level authentication ကို bypass လုပ္ႏုိင္တယ္။

Hack တယ္ဆိုတဲ႔ေနရာမွာလည္း web ကေန hack တာက ခက္ခဲပင္ပန္းတဲ႔နည္းလမ္းလို႕ဆုိရမယ္ထင္တယ္။ attack ေတာ္ေတာ္မ်ားမ်ားဟာ os level ေတြေလာက္ကိုပစ္မွတ္ထားကုန္ၾကတာေတြ႕ပါတယ္။ cloud server မွာ Host ထားတာကိုေတာင္ down လုနီးပါးျဖစ္သြားတာ ဟိုတစ္ေလာကပဲၾကားလုိက္ပါေသးတယ္။ ရိုးရိုး စက္စုတ္ေလးေတြဆိုရင္ေတာ႔ ဝပ္စင္းျပီး ျပန္ေတာင္မတက္ေတာ႔ဘူး။ DB ကို ဦးတည္ျပီး တိုက္ခိုက္တာေတြလည္း အလြယ္နည္းေတြရိွပါတယ္။ ဥပမာ FAQ တို႕၊ Feedback တို႕အတြက္ကို main database မွာမ်ား table အေနနဲ႕ထားလိုက္ရင္ေတာ႔ အန္တရာယ္အလြန္ၾကီးသြားတတ္ပါတယ္။ network layer မွာ attack လုပ္တာေတြကလည္း ရိုးရွင္းထိေရာက္ပါတယ္။ ဆာဗာေတြအားလံုး CPU 100%  ျဖစ္ေအာင္လုပ္တာတုိ႕၊ Switch ေတြ၊ Routers ေတြ match ျဖစ္ေအာင္မသံုးထားတဲ႔ Data Center ထဲအထိ သာသာယာယာေလးဝင္လာတာတုိ႕ျဖစ္တတ္ပါတယ္။ ဟိုတေလာက PA ဆိုတဲ႔ အစုိးရစနစ္တုိက္ခိုက္ခံလုိက္ရပါေသးတယ္။ အရင္ေရးတဲ႔သူေတြေရာ၊ အခုလက္ရိွ ထိန္းသိ္မ္းေနတဲ႔သူေတြပါ အေမးျမန္းခံထိပါတယ္။

ေနာက္တစ္ခုက Shine portal ဆိုတာ ရိွပါတယ္။ NCS ကေနလုပ္ထားတာပါ။ အစိုးရစစ္စစ္လုပ္ငန္းေတြဆိုရင္ အဲဒီကေနပဲသြားဖုိ႕ အစိုးရရဲ႕ ဆုိက္ဘာလံုျခံဳေရးမူထဲမွာပါပါတယ္။ သူတုိ႕ရဲ႕ standard sets ေတြရိွပါတယ္။ အဲဒါေတြကို လုိက္နာရပါတယ္။ email ပို႕ဖုိ႕ကအစ၊ web service သံုးရင္လည္း service တစ္ခုခ်င္းစီလုိက္ ပုိက္ဆံေပးရတဲ႔ central web service system ကေနသာ ျဖတ္သန္းသြားလာဖုိ႕ဆိုတဲ႔ စည္းကမ္းေတြရိွပါတယ္။ security certificate ေတြကိုလည္း အဆင္႔ဆင္႔လုိက္နာၾကရတာေတြရိွပါတယ္။ သုိ႕ေသာ္လည္း ဧည္႕ဆုိးဆိုတာေတာ႔ ဧည္႕စာရင္းတုိင္ရတဲ႔လမ္းဘက္က ဘယ္လာပါ႔မလဲဗ်ာ။

ေနာက္တစ္ခုက အစိုးရေတြဟာ အေျပာင္းအလဲတစ္ခုတစ္ခုအတြက္ အခ်ိန္ေတာ္ေတာ္ယူတယ္။ အဲဒါဟာ တျခားေနရာမွာေတာ႔ ေကာင္းရင္ေကာင္းမယ္။ software အတြက္ေတာ႔ သိပ္မေကာင္းလွဘူး။ Java upgrade ကို ၁.၄ ေတြ အမ်ားၾကီးရိွတယ္။  အဲဒါေတြကို 1.7 ကိုေျပာင္းတယ္။ 2013 ေလာက္မွ ညီညီညာညာ တေပ်ာ္တပါးေျပာင္းၾကတာ။ 1.7 မွာလည္း သူ႕ျပႆနာနဲ႕သူရိွတယ္။ java update ေတြဟာ ျပႆနာရွင္းဖုိ႕ ထုတ္ေနတာကို နားမလည္တဲ႔သူက နားမလည္ဘူး။ တစ္ခ်ိဳ႕ကေတာ႔ နားလည္ပါရဲ႕ သို႕ေသာ္လည္း web server ေတြ၊ app server ေတြက ေနာက္ဆံုးထုတ္ေတြနဲ႕ တစ္ခ်က္တစ္ခ်က္ ခ်က္ခ်င္း သဟဇာတမျဖစ္ေတာ႔ မျပင္ၾကဘူး။ known issue ကို မျပင္ရင္ေတာ႔ ကိုယ္႔ေသတြင္းကို ကိုယ္႔လက္နဲ႕တူးသြားတာမ်ိဳးျဖစ္တတ္တယ္။ Web Logic patch ေတြဆိုလည္း update လုပ္ခ်င္မွ လုပ္တာေတြ႕တယ္။ Strut 2 မွာ vulnerable ရိွတယ္ဆိုတာ ဟိုတစ္ေလာက email ပို႕တယ္။ အမွန္ေတာ႔အဲဒါေတြအတြက္ security team ေတြက ေစာင္႔ၾကည္႕ေလ႔လာေနရမွာ။ vendor ေတြအားကိုးလုိ႕ကေတာ႔ ဘာမွျဖစ္လာမယ္မထင္ဘူး။ Java နဲ႕ေရးထားတဲ႔ application အေဟာင္းေတြ ေတာ္ေတာ္မ်ားမ်ားဟာ ေတာ္ေတာ္ေလး outdated ျဖစ္ေနျပီ။ Spring သံုးတဲ႔ application ေတြမွာလည္း spring security မသံုးၾကတာမ်ားတယ္။ အမ်ားဆံုးအတြဲအစပ္ကေတာ႔ Struts/Spring/Oracle/Weblogic အဲဒါပဲ။ အဲဒီမွာမွ clustering ခပ္စုတ္စုတ္ေလးတစ္ခုေလာက္ပါမယ္။ App1/App2 လုပ္ထားမယ္။ (မစြံတာမ်ားတယ္။) System အေဟာင္းေတြဆိုရင္ sftp ကေန file upload ေတြေတာင္ပါေသး။ အဲဒါမ်ိဳးေတြက မသမာတဲ႔သူနဲ႕ေတြ႕ရင္ အန္တရာယ္သိပ္မ်ားတယ္။ data file uploading ေတြဟာ UI မွာလုိ စစ္ထားေဆးထားတာ မပါတာမ်ားတယ္။ vendor ခ်င္းနားလည္မႈနဲ႕လုပ္စားေနၾကသလုိျဖစ္ေနတယ္။

SingPass မွာလည္း username က FIN/IC no. ဆိုေတာ႔ အဲဒီ အယ္လ္ဂိုရစ္သမ္ကို သိရင္ အလြယ္ေလးပဲ။ အေရွ႕ဆံုးတစ္လံုး၊ ေနာက္ဆံုးတစ္လံုး။ checksum ကို ဘယ္အယ္လ္ဂိုရသမ္နဲ႕စစ္ဆိုတာမ်ိဳးရိွတယ္။ ဒါမွလည္း system ေတြမွာ NRIC လက္ခံတဲ႔အခါ valid ျဖစ္၊မျဖစ္ စစ္ေပးႏုိင္မွာကိုး။

အခုနေျပာခဲ႔တဲ႔ Struts တို႕၊ Spring တို႕လို MVC framework  ေတြက အလကားေပးတာေတြပါ။ အဲဒီေတာ႔ source ကိုလည္း ၾကည္႕လုိ႕ရပါတယ္။ Framework တစ္ခုခ်င္းစီမွာ သူ႕အားသာခ်က္၊ သူ႕အားနည္းခ်က္နဲ႕ပါပဲ။ စနစ္တက်မသံုးရင္ loophole ျဖစ္တတ္ပါတယ္။ ဂ်ာဗားေပၚကာစတုန္းက applet ေတြစိတ္ခ်ရတယ္၊စိတ္ခ်ရတယ္လုပ္ေနရာက applet ခ်င္း session sharing လုပ္ေနတဲ႔ ျပႆနာကို ေစာေစာသိလုိက္လို႕ ျပႆနာသိပ္မၾကီးက်ယ္ဘဲ ျငိမ္းသြားဖူးတယ္။ web ေပၚမွာေတာ႔ ဘာမွ စိတ္ခ်ရတယ္မရိွပါဘူး။ ဖ်က္လိုဖ်က္စီးမလုပ္ခ်င္တဲ႔သူေတြ မဖ်က္လို႕၊ မပ်က္တာပဲရိွတယ္။ NASA က web ကို စမ္းသပ္ျပီးေတာ႔ စိတ္တုိင္းမက်လို႕ လူေတြသံုးဖုိ႕ေပးလုိက္တာဆုိေတာ႔ စကတည္းက အေျခခံျပႆနာေလးေတြရိွျပီးသား။ protocol ေတြက ကိုယ္ျပင္လုိ႕ရတာမဟုတ္ဘူး။ web architecture အတိုင္းရိွျပီးသားကို သံုးၾကရတာ။ browser ေတြကို ႏုိင္နင္းတဲ႔သူမ်ားၾကေတာ႔လည္း လုိသလို ဖ်ားေယာင္းႏုိင္ျပန္ေရာ။

တိုက္ခိုက္ခံရရင္ recovery အတြက္ Contingency Plan ရိွဖုိ႕အင္မတန္အေရးၾကီးပါတယ္။ အထူးသျဖင္႔ database ေတြပါပဲ။ က်န္တာေတြက ျပန္တက္လာေအာင္ တစ္နည္းနည္းနဲ႕ၾကံစည္လုိ႕ရေသးတယ္။ confidential data ေတြ ေပါက္ၾကားသြား၊ ပ်က္သြားရင္ေတာ႔ အစိုးရအေနနဲ႕လည္း အင္မတန္အထိနာႏုိင္တယ္။ တစ္ခ်ိဳ႕စနစ္ေတြမွာ ရံုးတြင္းမွာပဲ ေနာက္ေရြးေကာက္ပြဲအတြက္ အမတ္ေနရာေပးဖုိ႕ ရည္ရြယ္ထားျပီးသားလူေတြစာရင္းတုိ႕ဘာတုိ႕ရိွတတ္ေသးတယ္ဆိုေတာ႔ ဒါေတြလည္းပါသြားလို႕မျဖစ္ဘူး။ database ေတြကလည္း size ေပၚမူတည္ျပီး backup လုပ္ရတာၾကာတယ္။ port ေတြ ip ေတြကို trusted ကပဲ access လုပ္ႏုိင္ေအာင္ ဘယ္ေလာက္လုပ္ထားလုပ္ထား ေရွ႕နားက အကာအရံေတြ၊ မီးတံတုိင္းေတြျပိဳျပီဆိုရင္ေတာ႔ သူ႕မွာလည္း မစြမ္းသာေတာ႔ဘူး၊ရန္သူ႕လက္က်ရတာပဲ။

ဒါေတြကို တန္ျပန္ႏုိင္ဖုိ႕ ရုရွနဲ႕တရုတ္က geek ေတြကို စင္ကာပူအစိုးရက ေမြးစားဦးမယ္ထင္မိတယ္။ မၾကာခင္မွာ DSTA ရဲ႕အသံုးစားရိတ္၊ စင္ကာပူမွာ ယာယီစစ္မႈထမ္းရင္း ေသဆံုးတဲ႔စာရင္း၊ ဆီမီးအစိုးရကုမ္ပနီမ်ားအၾကားသေဘာတူညီမႈ၊ ဝန္ထမ္းအသံုးစားရိတ္၊ အီးအာရ္ပီ ေန႕စဥ္အျမတ္ေငြ၊ အစိုးရတစ္ဖက္လွည္႕လုပ္ငန္းမ်ားျဖစ္ေသာ MRT, singapore POOLS  ေတြရဲ႕ အျမတ္ေငြ၊ CPF စီမံခန္႕ခြဲေရးမူဝါဒ၊ အစိုးရ၏ ဘဏ္လုပ္ငန္းအေပၚစည္းၾကပ္မႈေတြကို ၾကားရင္ၾကားရမယ္။

ဘာေတြဆက္ျဖစ္ဦးမလဲဆုိတာေတာ႔ ကိုယ္႔ဟာကိုယ္ထုိင္ၾကည္႕တာ ပိုေကာင္းပါတယ္။ ဘာမွမျဖစ္ဘဲလည္း ျငိမ္းခ်င္ျငိမ္းသြားမွာ။ ဖုန္းေရႊအစြမ္းနဲ႕ကယ္တင္သြားတာမ်ိဳးမျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ဒီမွာလည္း အဲဒါေတြကို ယံုၾကည္ပါဘိသနဲ႕။                    ။

Regards,
သုည