ယခုတေလာအြန္လိုင္းမွာစိန္ေခၚသံေတြ ပြဲၾကမ္းေနသည္။ ISISအဖြဲ႕၀င္တုိ႔က
ဥေရာပႏိုင္ငံမ်ားအား CyberAttack လုပ္ဖို႔ဟန္ျပင္ေနသလို Anonymous
အဖြဲ႕သားေတြကလည္း ISIS အဖြဲ႕ေတြကိုအတိအလင္းစစ္ ေၾကညာလိုက္ပါသည္။
အြန္လိုင္းဆုိေသာေနရာသည္ အေနမတတ္လွ်င္ ၾကားညႇပ္ႏိုင္သလို
မိမိအားတုိက္႐ိုက္ထိခိုက္မႈမ်ားရွိႏိုင္သည္။ ထိုသို႔ မထိခိုက္ရေလေအာင္
မည္သို႔ေရွာင္ရွားၾကမည္နည္း။
* Facebook, Google, Microsoft Account မ်ားႏွင့္ခ်ိတ္၍ Log in ၀င္ျခင္း *
ဤဘက္ႏွစ္မ်ားတြင္ေခတ္စားလာသည္မွာ Social Login ျဖစ္သည္။ အခ်ဳိ႕ Website မ်ား၀င္ဖူးလွ်င္ သိပါလိမ့္မည္။ မိမိသြားလိုေသာေနရာသို႔ တိုက္႐ိုက္၀င္ခြင့္မျပဳဘဲ Facebook account မွတစ္ဆင့္ ၀င္ပါဟုဆိုျခင္းမ်ဳိးပင္။ ထုိကိစၥအတြက္ မိမိ၀င္မည့္ Website တြင္ User Name ႏွင့္ Password အသစ္လုပ္စရာမလို။ Facebook Username ႏွင့္ Password ရွိလွ်င္ ကိစၥၿပီးသည္။ Facebook ကို အသံုးအမ်ားဆံုးျဖစ္ေသာ္လည္းယခုအခါ Google, Micorsoft, Twitter User Name ႏွင့္ Password တုိ႔ကိုပင္ ဤကဲ့သို႔ခ်ိတ္ဆက္ အသံုးျပဳလာသည္။
အေပၚယံအားျဖင့္ၾကည့္လွ်င္ User Name ႏွင့္ Password တစ္ပံုတစ္ ေခါင္းႀကီး သံုးစရာမလိုေသာေၾကာင့္အဆင္ေျပသည္ဟုထင္စရာရွိသည္။ လူမႈကြန္ရက္ Account တစ္ခုရွိလွ်င္ ယင္း၏ User Name ႏွင့္ Password တုိ႔ကိုခြင့္ျပဳေသာWebsite ေပါင္းစံုကို တြဲခ်ိတ္ထားရန္သာလိုသည္။ ဥပမာအားျဖင့္ဆုိေသာFacebook ထဲသုိ႔ Login ၀င္ထားၿပီးျဖစ္လွ်င္ Facebook Account ခြင့္ျပဳေသာWebsite ေပါင္းစံုကိုအသာအယာ၀င္႐ံုသာရွိပါေတာ့သည္။ အံ့အားသင့္စရာေကာင္းသည္။ သို႔ေသာ္ လံုၿခံဳစိတ္ခ်ရပါမည္ လား။
ဤေမးခြန္းကို Yes or No တိတိပပအေျဖေပးဖုိ႔ခက္သည္။ အမ်ားထင္သည္ထက္ ပို၍႐ႈပ္ေထြးေသာေၾကာင့္ ျဖစ္သည္။ ဂ႐ုတစိုက္အလုပ္လုပ္တတ္သူျဖစ္လွ်င္ အဆင္ေျပမည္။ သို႔ေသာ္လက္လြတ္စပယ္လုပ္လွ်င္ အႏၲရာယ္ရွိႏိုင္သည္။ လူမႈကြန္ရက္ျဖင့္ ထုိသုိ႔ခ်ိတ္ဆက္ထားေသာ Website တစ္ခုကို ပထမဆံုးအႀကိမ္ကလစ္ေခါက္သည့္အခါ မိမိအသံုးျပဳသည့္လူမႈကြန္ရက္ကို အေထာက္အပံ့ျပဳေသာ Page သို႔ Redirect လုပ္ခံရပါမည္။ ထုိေနရာသို႔ေရာက္သည့္အခါ မိမိသံုးသည့္ လူမႈကြန္ရက္ Account အား ထုိေနရာမွေန၍ လွမ္းၾကည့္ခြင့္ျပဳမည္လားဟု ေမးပါမည္။ ယင္းလုပ္ငန္းစဥ္ကို OAuth ဟူေသာလမ္းေၾကာင္းမွတစ္ဆင့္ေဆာင္ရြက္ ပါသည္။
ဥပမာ Weeklynews.com အား၀င္ရာတြင္ Facebook Account ျဖင့္ ၀င္မည္ဆုိပါစို႔။ ယင္းwebsite က OAuth ထံသို႔ သံုးစြဲသူ၏ Account ၾကည့္ခြင့္ေတာင္းလႊာအားေပးပို႔ပါမည္။ ထုိအခါ Facebook Page သို႔ေရာက္ပါမည္။ မိမိ၏ Facebook Account အားweeklynew.com အား ၾကည့္ခြင့္ျပဳရန္ဆႏၵရွိ၊ မရွိေမးပါမည္။ ခြင့္ျပဳလုိက္လွ်င္ Facebookသည္ မိမိ၏ Account ဆုိင္ရာအေသးစိတ္အခ်က္ႏွင့္ Element မ်ားကို ၾကည့္ခြင့္ ရပါမည္။ Facebook သည္ Weeklynew.com ထံသို႔ မိမိ၏ Account Information ႏွင့္ မိမိခ်ိတ္လိုေသာ API မ်ားစာရင္းတုိ႔ပါ၀င္သည့္ token တစ္ခုကိုေပးပို႔ပါမည္။
ယင္းေနာက္ပိုင္းတြင္ မိမိ Facebook ကိုခ်ိတ္ေနသမွ်ကာလပတ္လံုးယင္း Account ႏွင့္တြဲခ်ိတ္ထားေသာ Site မ်ားသည္ မိမိအားအလိုအေလ်ာက္ခြဲျခားသိရွိၿပီး သူတုိ႔၏ Serviceမ်ားကိုသံုးခြင့္ျပဳပါမည္။ password ျဖည့္သြင္းၿပီး၀င္ရန္မလိုပါ။ OAuthသည္ မိမိ၏လူမႈကြန္ရက္ Account ႏွင့္ပတ္သက္ေသာ password သို႔မဟုတ္ Login Detail ကိုယင္းSite မ်ားသို႔ ေပးပို႔ျခင္းမရွိပါ။ ထုိ႔ေၾကာင့္ ယင္းSite မ်ားမွတစ္ဆင့္ Facebook Account အားလွမ္း၍ အပိုင္စီးရန္မျဖစ္ႏိုင္ပါ။ ထုိ႔ေၾကာင့္ တစ္စိတ္တစ္ပိုင္းအဆင္ေျပသည္ဟုဆိုရပါမည္။ သို႔ေသာ္ အြန္လုိင္းျပစ္မႈမ်ားတြင္ မိမိပါ၀င္ပတ္သက္သြားႏုိင္ေျခရွိေနပါသည္။
မည္သို႔ပတ္သက္သြားသနည္း။ ကနဦးတြင္ မိမိခြင့္ျပဳထားေသာ Site သည္ လူမႈကြန္ရက္မွရရွိေသာ Account ၾကည့္႐ႈခြင့္အားလက္ထဲတြင္ ထိန္းသိမ္းထားသည္။ အဆုိပါၾကည့္႐ႈခြင့္ Tokenသည္ လူမႈကြန္ရက္ Account Settingထဲသို႔ မိမိကိုယ္တုိင္၀င္ၿပီး ျပန္လည္မ႐ုပ္သိမ္းသေရြ႕ အတည္ျဖစ္သည္။ လူမႈကြန္ရက္ထဲသို႔၀င္ၿပီး မိမိေပးထားေသာ Site Permission မ်ားအား အခါအားေလ်ာ္စြာစစ္ေဆးျခင္းသည္ ေကာင္းေသာ စိတ္ကူးစိတ္သန္းျဖစ္သည္။ Site တစ္ခုအား မိမိလံုး၀မသံုးေတာ့ဟုဆိုလွ်င္ ယင္းအတြက္ေပးထားသည့္ လူမႈကြန္ရက္ Account ၾကည့္႐ႈခြင့္အား လံုး၀႐ုတ္သိမ္းသင့္သည္။
Site Loginသည္ သက္ဆုိင္ရာလူမႈကြန္ရက္ Account ႏွင့္ ခ်ိတ္ဆက္ေနသည္။ ထိုခ်ိတ္ဆက္မႈသည္ Link အျဖစ္ရွိေနပါမည္။ ယင္း Link အား မည္သူအသံုးျပဳေနသည္ကို ခြင့္ျပဳခ်က္ရထားသည့္ Site က တိက်စြာသိေနပါမည္။ ထုိ႔ေၾကာင့္ မိမိႏွင့္ပတ္သက္သည့္ Data မ်ားအား စုေဆာင္းရာရင္းျမစ္တစ္ခုအျဖစ္အသံုးျပဳႏုိင္သည္။ အြန္လုိင္းေပၚတြင္ကိုယ္ေပ်ာက္သြားလိုသူမ်ားအတြက္ ယင္းသို႔လူမႈကြန္ရက္ Account ႏွင့္တြဲခ်ိတ္ထားျခင္းကကိုယ္ေပ်ာက္ရန္အခြင့္အေရးကိုဆံုး႐ံႈးသြားေစသည္။ ထုိ႔ျပင္ Site Permission လုပ္ေဆာင္ခ်က္သည္ မိမိ၏လူမႈကြန္ရက္ Account အား အ တုိင္းထက္အလြန္ၾကည့္ခြင့္ရွိေနသည္။ Agreement Page ကို မ်ားစြာဂ႐ုမထားဟုဆိုလွ်င္ FacebookPost မ်ားကိုပင္ ခ်ိတ္ဆက္ထားရာWebsite မွ ေန၍ Facebookမ်ားလွမ္းတင္ခြင့္လည္းရွိေနသည္။
မိမိကိုယ္စား Facebook တြင္ Post မ်ားတင္ခြင့္ရွိေနျခင္းသည္ အႏၲရာယ္မ်ားလွသည္။ Twitter အတြက္လည္းအလားတူျဖစ္သည္။ အျခားသူမ်ားေနာက္သို႔ Follow လုပ္ျခင္း၊ Tweet မ်ားအလိုအေလ်ာက္ပို႔ျခင္းတုိ႔သည္ ဘ၀င္က်စရာမေကာင္းလွပါ။ Site Permission ေပးျခင္းသည္ Site တစ္ခုမွေန၍ Hack ခံရ႐ံံုျဖင့္ က်န္သည့္ Site မ်ားပါမလံုၿခံဳေတာ့သည့္သေဘာျဖစ္သည္။ ထုိ႔ေၾကာင့္ မိမိယံုၾကည္စိတ္ခ်ရသည့္ Site ကိုသာ Permission ေပးသင့္သည္။ အြန္လုိင္းေပၚတြင္ရွိသမွ် Website တုိင္းသည္ တရား၀င္တည္ရွိမႈကို ရာႏႈန္းျပည့္အာမခံႏုိင္သည္မဟုတ္၍ Permissionေပးရာတြင္ အထူးသတိထားသင့္ပါသည္။
* Browser Password Manager *
Browser အေတာ္မ်ားမ်ားတြင္ Built-in Password Manager ပါသည္။ Website တစ္ခုသို႔အ၀င္တြင္ User Name ႏွင့္ Password ႐ိုက္ထည့္ၿပီးသည့္အခါ ယင္းကို Browser ကမွတ္ေပးထားရမည္လားဟု လာေမးပါသည္။ အလုပ္လြယ္သြားသည္ေတာ့မွန္သည္။ သို႔ရာတြင္ လံုၿခံဳစိတ္ခ်ရမႈအပုိင္းကိုၾကည့္လွ်င္ Dedicated Password Manager ေလာက္ လံုၿခံဳမႈမရွိဟုဆိုရပါ မည္။ Browser Password Manager သည္ Password မ်ားကို Encrypt လုပ္ၿပီး Hard Driver ေပၚတြင္ သိုေလွာင္ထားပါသည္။
မိမိ၏ Browser သည္ Password Sync ကိုခြင့္ျပဳလွ်င္ ယင္း Encrypted ဖုိင္သည္ Encrypted Form ပံုစံျဖင့္ မိမိ Share လုပ္ထားေသာ Service သို႔ တက္သြားပါမည္။ Sync လုပ္ငန္းစဥ္တြင္အသံုးျပဳေသာ Password ကာင္းေကာင္းရွိေနသမွ် Sync လုပ္ငန္းစဥ္အဆင္ေျပေနပါမည္။ Browser အေျခခံ Password Manager မ်ား၏အားနည္းခ်က္မွာ မိမိ၏ PC သို႔မဟုတ္ Mobile Device ထံသို႔ ၀င္သံုးခြင့္ရွိေနသူမ်ားသည္ ကြန္ပ်ဴတာပညာအနည္းငယ္တတ္လွ်င္ ယင္း Password မ်ားကိုၾကည့္ႏုိင္ခြင့္ရေနျခင္းျဖစ္သည္။ ထိုသို႔ ၾကည့္ျခင္းအတြက္ တုိက္ဆုိင္စစ္ေဆးမႈ တစ္စံုတစ္ရာျပဳလုပ္ခံရျခင္းမရွိပါ။
* အျခားေသာ Internet Device မ်ားႏွင့္ Security *
အင္တာနက္ခ်ိတ္ေသာ Device အေတာ္မ်ားမ်ားသည္ Router Firewall ေအာက္တြင္ရွိေနသည္ျဖစ္၍ မ်ားေသာအားျဖင့္လံုၿခံဳမႈရွိသည္။ အင္တာနက္ခ်ိတ္ဆက္ထားေသာ Device အေတာ္မ်ားမ်ားသည္ Service မ်ားေဆာင္ရြက္ေပးမႈမရွိျခင္းကလည္းလံုျခံဳမႈအတြက္ေကာင္းသည္။ သို႔ေသာ္ ယခုအခါတြင္ မိုဘိုင္း, Device တို႔သည္ PC အငယ္စားျဖစ္လာ၍ Email Worm မ်ား ၊ Trojamမ်ား ၀င္ႏုိင္ေျခရွိသည့္ျပင္ Hack လုပ္ႏုိင္ေသာ Service မ်ားရွိလာပါသည္။ မိုဘုိင္းဖုန္းအထူးသျဖင့္ Android ဖုန္းမ်ားတြင္ OS Update မေပးျခင္းသည္ လံုၿခံဳမႈကိုအားနည္းေစေသာအေၾကာင္းမ်ားျဖစ္သည္။ ထုိ႔ေၾကာင့္ Android ဖုန္းအေဟာင္း မ်ားတြင္ Virus Signature Update လုပ္ႏုိင္ေသာ Antivirus တစ္ခုကိုမျဖစ္မေန သံုးသင့္ပါသည္။
NetGuide Journal (Every Wednesday)
https://www.facebook.com/officialnetguidejournal
* Facebook, Google, Microsoft Account မ်ားႏွင့္ခ်ိတ္၍ Log in ၀င္ျခင္း *
ဤဘက္ႏွစ္မ်ားတြင္ေခတ္စားလာသည္မွာ Social Login ျဖစ္သည္။ အခ်ဳိ႕ Website မ်ား၀င္ဖူးလွ်င္ သိပါလိမ့္မည္။ မိမိသြားလိုေသာေနရာသို႔ တိုက္႐ိုက္၀င္ခြင့္မျပဳဘဲ Facebook account မွတစ္ဆင့္ ၀င္ပါဟုဆိုျခင္းမ်ဳိးပင္။ ထုိကိစၥအတြက္ မိမိ၀င္မည့္ Website တြင္ User Name ႏွင့္ Password အသစ္လုပ္စရာမလို။ Facebook Username ႏွင့္ Password ရွိလွ်င္ ကိစၥၿပီးသည္။ Facebook ကို အသံုးအမ်ားဆံုးျဖစ္ေသာ္လည္းယခုအခါ Google, Micorsoft, Twitter User Name ႏွင့္ Password တုိ႔ကိုပင္ ဤကဲ့သို႔ခ်ိတ္ဆက္ အသံုးျပဳလာသည္။
အေပၚယံအားျဖင့္ၾကည့္လွ်င္ User Name ႏွင့္ Password တစ္ပံုတစ္ ေခါင္းႀကီး သံုးစရာမလိုေသာေၾကာင့္အဆင္ေျပသည္ဟုထင္စရာရွိသည္။ လူမႈကြန္ရက္ Account တစ္ခုရွိလွ်င္ ယင္း၏ User Name ႏွင့္ Password တုိ႔ကိုခြင့္ျပဳေသာWebsite ေပါင္းစံုကို တြဲခ်ိတ္ထားရန္သာလိုသည္။ ဥပမာအားျဖင့္ဆုိေသာFacebook ထဲသုိ႔ Login ၀င္ထားၿပီးျဖစ္လွ်င္ Facebook Account ခြင့္ျပဳေသာWebsite ေပါင္းစံုကိုအသာအယာ၀င္႐ံုသာရွိပါေတာ့သည္။ အံ့အားသင့္စရာေကာင္းသည္။ သို႔ေသာ္ လံုၿခံဳစိတ္ခ်ရပါမည္ လား။
ဤေမးခြန္းကို Yes or No တိတိပပအေျဖေပးဖုိ႔ခက္သည္။ အမ်ားထင္သည္ထက္ ပို၍႐ႈပ္ေထြးေသာေၾကာင့္ ျဖစ္သည္။ ဂ႐ုတစိုက္အလုပ္လုပ္တတ္သူျဖစ္လွ်င္ အဆင္ေျပမည္။ သို႔ေသာ္လက္လြတ္စပယ္လုပ္လွ်င္ အႏၲရာယ္ရွိႏိုင္သည္။ လူမႈကြန္ရက္ျဖင့္ ထုိသုိ႔ခ်ိတ္ဆက္ထားေသာ Website တစ္ခုကို ပထမဆံုးအႀကိမ္ကလစ္ေခါက္သည့္အခါ မိမိအသံုးျပဳသည့္လူမႈကြန္ရက္ကို အေထာက္အပံ့ျပဳေသာ Page သို႔ Redirect လုပ္ခံရပါမည္။ ထုိေနရာသို႔ေရာက္သည့္အခါ မိမိသံုးသည့္ လူမႈကြန္ရက္ Account အား ထုိေနရာမွေန၍ လွမ္းၾကည့္ခြင့္ျပဳမည္လားဟု ေမးပါမည္။ ယင္းလုပ္ငန္းစဥ္ကို OAuth ဟူေသာလမ္းေၾကာင္းမွတစ္ဆင့္ေဆာင္ရြက္ ပါသည္။
ဥပမာ Weeklynews.com အား၀င္ရာတြင္ Facebook Account ျဖင့္ ၀င္မည္ဆုိပါစို႔။ ယင္းwebsite က OAuth ထံသို႔ သံုးစြဲသူ၏ Account ၾကည့္ခြင့္ေတာင္းလႊာအားေပးပို႔ပါမည္။ ထုိအခါ Facebook Page သို႔ေရာက္ပါမည္။ မိမိ၏ Facebook Account အားweeklynew.com အား ၾကည့္ခြင့္ျပဳရန္ဆႏၵရွိ၊ မရွိေမးပါမည္။ ခြင့္ျပဳလုိက္လွ်င္ Facebookသည္ မိမိ၏ Account ဆုိင္ရာအေသးစိတ္အခ်က္ႏွင့္ Element မ်ားကို ၾကည့္ခြင့္ ရပါမည္။ Facebook သည္ Weeklynew.com ထံသို႔ မိမိ၏ Account Information ႏွင့္ မိမိခ်ိတ္လိုေသာ API မ်ားစာရင္းတုိ႔ပါ၀င္သည့္ token တစ္ခုကိုေပးပို႔ပါမည္။
ယင္းေနာက္ပိုင္းတြင္ မိမိ Facebook ကိုခ်ိတ္ေနသမွ်ကာလပတ္လံုးယင္း Account ႏွင့္တြဲခ်ိတ္ထားေသာ Site မ်ားသည္ မိမိအားအလိုအေလ်ာက္ခြဲျခားသိရွိၿပီး သူတုိ႔၏ Serviceမ်ားကိုသံုးခြင့္ျပဳပါမည္။ password ျဖည့္သြင္းၿပီး၀င္ရန္မလိုပါ။ OAuthသည္ မိမိ၏လူမႈကြန္ရက္ Account ႏွင့္ပတ္သက္ေသာ password သို႔မဟုတ္ Login Detail ကိုယင္းSite မ်ားသို႔ ေပးပို႔ျခင္းမရွိပါ။ ထုိ႔ေၾကာင့္ ယင္းSite မ်ားမွတစ္ဆင့္ Facebook Account အားလွမ္း၍ အပိုင္စီးရန္မျဖစ္ႏိုင္ပါ။ ထုိ႔ေၾကာင့္ တစ္စိတ္တစ္ပိုင္းအဆင္ေျပသည္ဟုဆိုရပါမည္။ သို႔ေသာ္ အြန္လုိင္းျပစ္မႈမ်ားတြင္ မိမိပါ၀င္ပတ္သက္သြားႏုိင္ေျခရွိေနပါသည္။
မည္သို႔ပတ္သက္သြားသနည္း။ ကနဦးတြင္ မိမိခြင့္ျပဳထားေသာ Site သည္ လူမႈကြန္ရက္မွရရွိေသာ Account ၾကည့္႐ႈခြင့္အားလက္ထဲတြင္ ထိန္းသိမ္းထားသည္။ အဆုိပါၾကည့္႐ႈခြင့္ Tokenသည္ လူမႈကြန္ရက္ Account Settingထဲသို႔ မိမိကိုယ္တုိင္၀င္ၿပီး ျပန္လည္မ႐ုပ္သိမ္းသေရြ႕ အတည္ျဖစ္သည္။ လူမႈကြန္ရက္ထဲသို႔၀င္ၿပီး မိမိေပးထားေသာ Site Permission မ်ားအား အခါအားေလ်ာ္စြာစစ္ေဆးျခင္းသည္ ေကာင္းေသာ စိတ္ကူးစိတ္သန္းျဖစ္သည္။ Site တစ္ခုအား မိမိလံုး၀မသံုးေတာ့ဟုဆိုလွ်င္ ယင္းအတြက္ေပးထားသည့္ လူမႈကြန္ရက္ Account ၾကည့္႐ႈခြင့္အား လံုး၀႐ုတ္သိမ္းသင့္သည္။
Site Loginသည္ သက္ဆုိင္ရာလူမႈကြန္ရက္ Account ႏွင့္ ခ်ိတ္ဆက္ေနသည္။ ထိုခ်ိတ္ဆက္မႈသည္ Link အျဖစ္ရွိေနပါမည္။ ယင္း Link အား မည္သူအသံုးျပဳေနသည္ကို ခြင့္ျပဳခ်က္ရထားသည့္ Site က တိက်စြာသိေနပါမည္။ ထုိ႔ေၾကာင့္ မိမိႏွင့္ပတ္သက္သည့္ Data မ်ားအား စုေဆာင္းရာရင္းျမစ္တစ္ခုအျဖစ္အသံုးျပဳႏုိင္သည္။ အြန္လုိင္းေပၚတြင္ကိုယ္ေပ်ာက္သြားလိုသူမ်ားအတြက္ ယင္းသို႔လူမႈကြန္ရက္ Account ႏွင့္တြဲခ်ိတ္ထားျခင္းကကိုယ္ေပ်ာက္ရန္အခြင့္အေရးကိုဆံုး႐ံႈးသြားေစသည္။ ထုိ႔ျပင္ Site Permission လုပ္ေဆာင္ခ်က္သည္ မိမိ၏လူမႈကြန္ရက္ Account အား အ တုိင္းထက္အလြန္ၾကည့္ခြင့္ရွိေနသည္။ Agreement Page ကို မ်ားစြာဂ႐ုမထားဟုဆိုလွ်င္ FacebookPost မ်ားကိုပင္ ခ်ိတ္ဆက္ထားရာWebsite မွ ေန၍ Facebookမ်ားလွမ္းတင္ခြင့္လည္းရွိေနသည္။
မိမိကိုယ္စား Facebook တြင္ Post မ်ားတင္ခြင့္ရွိေနျခင္းသည္ အႏၲရာယ္မ်ားလွသည္။ Twitter အတြက္လည္းအလားတူျဖစ္သည္။ အျခားသူမ်ားေနာက္သို႔ Follow လုပ္ျခင္း၊ Tweet မ်ားအလိုအေလ်ာက္ပို႔ျခင္းတုိ႔သည္ ဘ၀င္က်စရာမေကာင္းလွပါ။ Site Permission ေပးျခင္းသည္ Site တစ္ခုမွေန၍ Hack ခံရ႐ံံုျဖင့္ က်န္သည့္ Site မ်ားပါမလံုၿခံဳေတာ့သည့္သေဘာျဖစ္သည္။ ထုိ႔ေၾကာင့္ မိမိယံုၾကည္စိတ္ခ်ရသည့္ Site ကိုသာ Permission ေပးသင့္သည္။ အြန္လုိင္းေပၚတြင္ရွိသမွ် Website တုိင္းသည္ တရား၀င္တည္ရွိမႈကို ရာႏႈန္းျပည့္အာမခံႏုိင္သည္မဟုတ္၍ Permissionေပးရာတြင္ အထူးသတိထားသင့္ပါသည္။
* Browser Password Manager *
Browser အေတာ္မ်ားမ်ားတြင္ Built-in Password Manager ပါသည္။ Website တစ္ခုသို႔အ၀င္တြင္ User Name ႏွင့္ Password ႐ိုက္ထည့္ၿပီးသည့္အခါ ယင္းကို Browser ကမွတ္ေပးထားရမည္လားဟု လာေမးပါသည္။ အလုပ္လြယ္သြားသည္ေတာ့မွန္သည္။ သို႔ရာတြင္ လံုၿခံဳစိတ္ခ်ရမႈအပုိင္းကိုၾကည့္လွ်င္ Dedicated Password Manager ေလာက္ လံုၿခံဳမႈမရွိဟုဆိုရပါ မည္။ Browser Password Manager သည္ Password မ်ားကို Encrypt လုပ္ၿပီး Hard Driver ေပၚတြင္ သိုေလွာင္ထားပါသည္။
မိမိ၏ Browser သည္ Password Sync ကိုခြင့္ျပဳလွ်င္ ယင္း Encrypted ဖုိင္သည္ Encrypted Form ပံုစံျဖင့္ မိမိ Share လုပ္ထားေသာ Service သို႔ တက္သြားပါမည္။ Sync လုပ္ငန္းစဥ္တြင္အသံုးျပဳေသာ Password ကာင္းေကာင္းရွိေနသမွ် Sync လုပ္ငန္းစဥ္အဆင္ေျပေနပါမည္။ Browser အေျခခံ Password Manager မ်ား၏အားနည္းခ်က္မွာ မိမိ၏ PC သို႔မဟုတ္ Mobile Device ထံသို႔ ၀င္သံုးခြင့္ရွိေနသူမ်ားသည္ ကြန္ပ်ဴတာပညာအနည္းငယ္တတ္လွ်င္ ယင္း Password မ်ားကိုၾကည့္ႏုိင္ခြင့္ရေနျခင္းျဖစ္သည္။ ထိုသို႔ ၾကည့္ျခင္းအတြက္ တုိက္ဆုိင္စစ္ေဆးမႈ တစ္စံုတစ္ရာျပဳလုပ္ခံရျခင္းမရွိပါ။
* အျခားေသာ Internet Device မ်ားႏွင့္ Security *
အင္တာနက္ခ်ိတ္ေသာ Device အေတာ္မ်ားမ်ားသည္ Router Firewall ေအာက္တြင္ရွိေနသည္ျဖစ္၍ မ်ားေသာအားျဖင့္လံုၿခံဳမႈရွိသည္။ အင္တာနက္ခ်ိတ္ဆက္ထားေသာ Device အေတာ္မ်ားမ်ားသည္ Service မ်ားေဆာင္ရြက္ေပးမႈမရွိျခင္းကလည္းလံုျခံဳမႈအတြက္ေကာင္းသည္။ သို႔ေသာ္ ယခုအခါတြင္ မိုဘိုင္း, Device တို႔သည္ PC အငယ္စားျဖစ္လာ၍ Email Worm မ်ား ၊ Trojamမ်ား ၀င္ႏုိင္ေျခရွိသည့္ျပင္ Hack လုပ္ႏုိင္ေသာ Service မ်ားရွိလာပါသည္။ မိုဘုိင္းဖုန္းအထူးသျဖင့္ Android ဖုန္းမ်ားတြင္ OS Update မေပးျခင္းသည္ လံုၿခံဳမႈကိုအားနည္းေစေသာအေၾကာင္းမ်ားျဖစ္သည္။ ထုိ႔ေၾကာင့္ Android ဖုန္းအေဟာင္း မ်ားတြင္ Virus Signature Update လုပ္ႏုိင္ေသာ Antivirus တစ္ခုကိုမျဖစ္မေန သံုးသင့္ပါသည္။
NetGuide Journal (Every Wednesday)
https://www.facebook.com/officialnetguidejournal
