SASE Architecture and Cisco

 ပြီးခဲ့တဲ့ လပိုင်းလောက်က CCIE renewal လုပ်ဖို့ အစီအစဉ်ဆွဲရင်းက ကိုယ့် နံပါတ်လေးလဲ သက်တမ်းတိုးပြီး သားဖြစ် Cisco ရဲ့ Core Technology တွေ ထဲက Cisco Security Core Technologies တွေ ကို လေ့လာပြီးသားလဲ ဖြစ်  အောင် 350-701 Exam ဖြေ ဖို့ အတွက် အောက်ပါ အကြောင်းအရာတွေ ကို လေ့လာဖြစ်တယ် ဆိုပါတော့။

Cisco ASA Firewall

Cisco Firepower Next-Generation Firewall (NGFW)

Cisco SSL VPN (Cisco AnyConnect)

Cisco Identity Services Engine (ISE)

Cisco Advanced Malware Protection (AMP)

Cisco Umbrella for DNS security

Cisco Email Security Appliance (ESA)

Cisco Web Security Appliance (WSA)

Cisco Stealthwatch (SIEM)

Cisco Talos Threat Intelligence

Cisco SecureX Security Platform

Cisco Duo (Multi-Factor Authentication)

Cisco Adaptive Security Appliance (ASA) Software

Cisco Next-Generation Intrusion Prevention System (NGIPS)

Cisco Cloudlock (Cloud Security)

အပေါ် က အကြောင်းတွေ လေ့လာရင်းကနေ ခေါင်း ထဲ အတွေး နယ်ချဲ့ မိတာက Cisco ဟာ တခြား Vendor တွေ နဲ့ မတူပဲ ဘာလို့ များ အကုန်လုံး ကို စွတ်လုပ်နေလဲ ပေါ့။ 

နောက် အရင်က လေ့ လာ ဖူးတဲ့ အောက်က ခေါင်းစဉ်တွေ ကို ထည့်ပေါင်းကြည့် လိုက်တော့မှ  SASE ဆိုတာခေါင်းထဲ ထင်းကနဲ ပေါ် လာတော့ တယ်။

Cisco DNA

Cisco ISE

Cisco SD-WAN

Cisco ဟာ Secure Access Service Edge (SASE) လမ်းကြောင်းကို သွားနေတာ အတော် ခရီးပေါက် နေပြီဆိုတာပါပဲ။

ဘာလို့လဲ ဆိုတော့ SASE တခု ရှိရမယ့် 

Security

Flexibility

Speed

Cost-Effective

Better Performance

Simplicity

ဆိုတဲ့ အချက်တွေ အကုန်လုံးကို Cisco က စုစည်းလာတာ အပေါ် မှာ list ထုတ်ထားတဲ့ စာရင်းပါပဲ။

ကိုယ့်တယောက်ထဲ အမြင် အရ ဆိုရင် Cisco ရဲ့  Product တွေ ဟာ  Born-in Cloud vendor တွေ ရဲ့  Product တွေ လို Cloud ပေါ် မှာ ပေါ့ ပေါ့ ပါးပါး run နိုင်တဲ့ တနေ့ Cisco ဟာ အရင်က Networking လောက မှာ ထောင်ထောင် ထောင်ထောင် လုပ်နိုင်ခဲ့သလို Cloud ပေါ် မှာလဲ ဖြစ်လာနိုင်အုံးမယ်ထင်တာပါပဲ။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Crypto Shredding in Cloud Computing Data Security

ရုပ်ရှင်တွေထဲမှာ  SIM card, Microchip, Memory Chip စတာတွေ ကို Microwave Oven ထဲထည့်ပြီး ဖျက်ဆီးပစ်တာတို့ ၊

Hard Disk လို Storage device တွေ ကို Drilling Machine နဲ့ ထိုးဖောက်ပြီး ဖျက်ဆီးတာတို့၊ Crashing machine ထဲ ထည့်ပြီး တစစီ ချေမွ ပစ်တာတို့ ကို မြင်ဖူး ကြမှာပါ။

အဲ့ဒါမျိုး ကို Data Destruction လုပ်တယ်လို့ ခေါ် ပါတယ်။

Electric Value အနေနဲ့ Storage Device တွေ ထဲမှာ ကျန်နေတဲ့ Data တွေ ကို သံလိုက်လှိုင်း သုံးပြီး ဖျက်ဆီးတာမျိုးကို ကျတော့  Degaussing လုပ်တယ်လို့ ခေါ် ပါတယ်။

Paper ပေါ် က Data မျိုးကျတော့ မီးရှို့ တာတို့၊ Shredder သုံးပြီး ဖျက်ဆီးတာတို့ လုပ်ကြတာပေါ့။

ဒီ အပေါ် က လုပ်ငန်းစဉ်တွေ က On-Premise Infrastructure တွေ မှာ Data Security Policy အရ လုပ်ရတဲ့ လုပ်ငန်းစဉ် တွေ ပါ။  Data တွေ ကို Encryption လုပ်ထားပြီး သား ကို‌တောင် Physically ဖျက်ဆီး ပစ်ရပါတယ်။

Cloud Computing ခေတ်ရောက်လာတော့ Data Dispersion ဆိုတာ ကြီး ကြောင့် Data Security Policy ကို အမှားအယွင်းမရှိ လိုက်နာဖို့ ခက်ခဲလာပါတယ်။

Cloud Service Provider တွေ ဟာ သူတို့ ပေးထားတဲ့ Service Level Agreement ကြောင့် Cloud Service အသုံးပြု သူ တွေ ရဲ့ Data ကို Region ပေါင်းများစွာ မှာ Replicate လုပ်ထားကြ ရပါတယ်။

အဲ့လို Replicate လုပ်ထားတာကိုပဲ Data Dispersion လို့ ခေါ် တာပါ။

ဒီအခါမှာ အသုံးပြုတဲ့ အဖွဲ့အစည်းတွေ အနေနဲ့  Cloud Service Provider ရဲ့  Resource မှာ သိမ်းထားတဲ့ Data တွေ က ကမ္ဘာအရပ်ရပ်မှာ ရှိတဲ့ Data Center တွေ ဆီမှာ ရောက်နေပါတယ်။

ဒီအတွက် လက်ရှိ Cloud Service Provider ကို ဆက်လက်အသုံးမပြု ပဲ နောက် တခု ပြောင်း သုံး ဖို့ အခြေ အနေ ကြုံ လာတဲ့ အခါ Data Security Policy အရ Data တွေ ကျန်မနေ ခဲ့ အောင် Destruction လုပ်ဖို့ အခက်တွေ့ ကြ ရပါတယ်။ CSP တွေအနေနဲ့ Shared Storage Pool တွေ ကို Physical Destruction လုပ်မှာ မဟုတ် သလို၊ Dedicated Storage Pool တွေ ကို Destruction လုပ်တယ် မလုပ်ဖူး ဆိုတာကို ယုံကြည်ထားလို့ လဲ မရပြန်ပါဘူး။

ဒီအခါမှာ Crypto Shredding ဆိုတာဟာ အရေး ပါလာပါတယ်။

Crypto Shredding ကို Cryptographic Shredding လို့လဲ ခေါ် ကြပါသေးတယ်။

အလုပ်လုပ်ပုံကတော့ Storage device တခုမှာ ရှိနေတဲ့ Data ကို Encryption Algorithm တခု သုံးပြီး Encrypt လုပ်ပါတယ်။ Decrypt ပြန် လုပ် လို့ ရတဲ့ Key ကို နောက် တကြိမ် တခါ ထပ်ပြီး Encrypt လုပ်ပြီး ရလာတဲ့ Decryption Key ကို ဘယ်နေရာ မှာ မှ သိမ်းမထားပဲ ဖျက်ဆီးပစ်တာပါ။

နောက် တနည်းကတော့ ဒုတိယအကြိမ် Encrypt လုပ်တဲ့ အခါမှာ Decryption Key မပါပဲ Encrypt လုပ်လိုက်တာပါ။ ဒီနည်းကို သုံးတာ ကျတော့ အိုင်တီ သမား လက်ရှိ သက်တမ်းအထိ မတွေ့ ဖူးသေးပါဘူး။

ဒီလိုလုပ်ခြင်း အားဖြင့် Data Dispersion ကြောင့် ဖြစ် လာနိုင်တဲ့ Data Security Weakness တွေ ကို ကာကွယ်ပြီး သား ဖြစ်သွားပါတယ်။

Crypto Shredding ကို Cloud Computing ကို အသုံးပြု နေရတဲ့ အိုင်တီ သမားတွေ အနေ နဲ့  အတိအကျ လိုက်နာဖို့  အထူးလိုပါတယ်။

Cloud Resource တခု ဆောက်ပြီ ဆိုတာနဲ့  Encryption Algorithm သုံးပြီး Data in Transit/Motion, Data in use နဲ့ Data at rest တို့ကို Encrypt လုပ်ကို လုပ်ရမှာ ပဲ ဖြစ်ပါတယ်။

မလုပ်ထားရင်တော့ CSP ရဲ့  Data Dispersion ကြောင့်  နောင် တချိန်မှာ ဥရောပလို GDPR policy မျိုး က ကိုယ်ရော ကိုယ့်အလုပ်လုပ်နေတဲ့ အဖွဲ့ အစည်းရော ဒုက္ခ ပေး ဖို့ ဖြစ်လာမှာပါ။

ကျေးဇူးတင်ပါတယ်။

ပျော် ရွှင် ပါ စေ။

(Be knowledgeable, pass it on then)

Demystifying Service Principal (SP) and Managed Identity (MI)

Azure Cloud Architect တွေ ခေါင်း အစားရဆုံး ကတော့ ဘယ်အချိန်မှာ Service Principal  (SP) ကိုသုံးပြီး ဘယ်အချိန်မှာ Managed Identity (MI) ကို သုံးမလဲ ဆိုတာပါပဲ။

တကယ်က SP နဲ့  MI ရဲ့  နောက်ကွယ်က အလုပ်လုပ်ပုံ အမှန်တရားက အတူတူပါပဲ။

ကျတော် တို့ အရင် On-Premise AD တွေ သုံးတုန်းကဆိုရင် Application တွေ Service တွေ မှာ သုံးဖို့ Service Account ဆိုတာ Create လုပ်ပြီး သုံးကြ ရပါတယ်။

အဲဒီမှာ ပြဿနာက AD account တွေ ရဲ့ ထုံးစံ အရ Password Expiry Date ရှိနေတာပါပဲ။ Non-expired လုပ်ထားရင်လဲ Security အရ non-compliance ဖြစ်တဲ့ အတွက် ထားမရပါဘူး။

ဒီတော့ Password renew လုပ်ရတဲ့ Integrate လုပ်ထားတဲ့ Application, Service တွေ မှာ Password update လုပ်ရပါတယ်။

ဒီအခါမှာ Application, Network, System နဲ့ Infra သမားတို့ ထုံးစံ အတိုင်း ဘယ်နေရာ တွေမှာ Account ကို သုံးထားလဲ အကုန်မသိတဲ့ အခါ Production down တဲ့ impact မျိုးတွေ ကြုံ ရတာပါပဲ။

Azure Cloud မှာတော့ ဒီပြဿနာကို ဖြေရှင်း ဖို့ Service Principal (SP) နဲ့ Managed Identity (MI) ဆို တာ ရှိလာပါတယ်။

Service Prinicpal ဆိုတာက Create လုပ်လိုက်တာနဲ့ ID နဲ့ Credential ဆိုတာ ရလာပြီး၊ ရလာတဲ့ ID, Credential ကို Azure Keyvault လို Key, Secret Management Service တခုခုမှာ သိမ်းထားရပါတယ်။

ပြီး မှ Service Principal (SP) ကို Keyvault မှာ Role Base Access Control ပေးပြီး ပြန် သုံးရတာပါ။

SP ကို ဘယ်မှာ သုံးသင့်လဲ ဆိုတော့ AzureDevOps, Ansible, Terraform လို Automation Tools တွေ , Third Party Application, Enterprise Application တွေ မှာ Integrate လုပ်ပြီး Token Base Authenticaion တွေ နဲ့ သုံးသင့်ပါတယ်။

Managed Identity (MI) မှာ တော့ System-Assigned နဲ့ User-Assigned ဆိုပြီး နှစ်မျိုး ရှိပါတယ်။

System-Assigned ဆိုတာကတော့ Resource တခုမှာ ID တခု Assigned လုပ်ထားတာ ဖြစ်ပြီး Resource မရှိတော့ တာနဲ့ ID လဲ မရှိတော့ပါဘူး။

User-Assigned ကတော့ Azure AD မှာ Create လုပ်ပြီး Resource တွေ မှာ Assign ပြန်လုပ်ပြီး သုံးရတာပါ။

MI ရဲ့ ထူးခြား ချက်က Credential ကို မသိရတာပါပဲ။ ဒါကြောင့် ပဲ သူ့ အတွက် Credential ကို Azure Keyvault လို Secret Management Service တခုခုမှာ သွားသိမ်းစရာ မလိုတော့ပါဘူး။

သူကတော့ Azure Resource တွေ နဲ့ Link လုပ်ပြီး သုံးရတဲ့ အမျိုးအစားပါ။

ဥပမာ Azure File Share service ကို သုံးမယ့် Server VM တွေ အတွက် User-Assigned Storage Account Access MI တခု Create လုပ်ပြီး Server VM အားလုံးမှာ assign လုပ်တာမျိုးပေါ့။ 

အနှစ်ချုပ် ရမယ်ဆိုရင် ...

Service Prinicipal ကို Applications, Third Party Tools, Automation Tools တွေမှာ Integrate လုပ်ပြီး သုံးရမှာ ဖြစ်ပါတယ်။

သူ့ ကို သုံးမယ်ဆိုရင် Credential အတွက် Secret Key Management Service တခုခုလိုအပ်ပြီး၊ အနည်းငယ် ရှုပ်ထွေး ပြီး ပိုများ တဲ့ RBAC အဆင့်တွေ ကို အသုံးပြု ဖို့ လိုအပ်ပါတယ်။

Managed Identity ကို တော့ Azure Resource တွေ နဲ့ Link လုပ်ပြီး သုံးရမှာ ဖြစ်ပါတယ်။

သူ့ကို သုံးမယ်ဆိုရင်တော့ User-Assigned MI က‌တော့ Recommend ဖြစ်ပေမယ့် ကိုယ့် Architecture ပေါ် မူတည်ပြီး System-Assigned MI ကို လဲ သုံးသင့်ရင် သုံးရမှာပဲ ဖြစ်ပါတယ်။ System-Assigned ရဲ့ Life Cycle ကတော့ Resource ရဲ့ Life Cycle နဲ့ အတူတူပဲ ရှိတာကိုတော့ သတိချပ်ဖို့လိုပါတယ်။

ဒီလောက်ဆို SP နဲ့ MI အကြောင်း တီးမိခေါက်မိလောက်ပြီ ထင်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

Stalkerware not Spyware

Stalkerware ဆိုတာ လူတယောက်ချင်းစီ က သူတို့ စောင့်ကြည့်ချင်တဲ့ သူတွေကို တိတ်တဆိတ် စောင့်ကြည့်ဖို့ သုံးတဲ့ Application တခုပဲ ဆိုပါတော့။

 သူက ဘာတွေလုပ်လဲ ဆိုရင် ...

Mobile Phone, Tablet, Computer တွေကနေ တယောက်နဲ့ တယောက် ဆက်သွယ်မှု (Phone Call, Chat, Messaging) တွေ ကို စောင့်ကြည့်တာ။

လက်ရှိ ဘယ်နေရာ ရောက် နေလဲ နဲ့ အရင်နေ့တွေက ဘယ်တွေသွားခဲ့လဲ (GPS location data) ဆိုတာကို စောင့်ကြည့် အသိပေးတာ။

Device ထဲက File, Photo လို အချက်အလက် တခုခု ပြောင်းသွားတာနဲ့ Stalkerware ရဲ့ Main Server ဆီကို update data ပို့ပေးတာ။ (ဥပမာ။ Photo ထဲမှာ ဓာတ်ပုံ အသစ်တွေ ရောက်လာရင် Server ဆီကို ပို့ပြီး သိမ်းလိုက်တာမျိုး။)

နာမည်ကြီး Stalkerware App တွေ ထဲက “Cerberus” , “Reptillicus” ဆိုတဲ့ App နှစ်ခုဆိုရင် WhatsApp, Telegram, Text Message တွေကို တောင် ဝင်ဖတ်နိုင်တယ်တဲ့။ Photo, Video တွေကို လဲ ဝင်ကြည့်နိုင်တယ်တဲ့ဗျ။

Stalkerware App တွေကို ကိုယ့် Device ထဲကို သွင်းဖို့ဆိုရင် Physical access ရှိမှ သွင်းလို့ရမှာ ဖြစ်ပြီး။ သွင်းယူမယ့်သူက ရင်းနှီးတဲ့သူလဲ ဖြစ်နိုင်သလို၊ မိမိကိုယ်တိုင်လဲ ဖြစ်နိုင်နေပါတယ်။

ဥပမာ - Car Blackbox, IP base CCTV App လိုမျိုးတွေပါပဲ။

ကိုယ်မသိပဲ Stalkerware သွင်းခံထားရလား သိနိုင်တဲ့ ပုံစံတွေကတော့

-     -  Device Battery မြန်မြန်ကုန်တာ

-     -  Device က ခဏလေးသုံးတာနဲ့ ပူလာတာ။ အပူမြန်လာတာ။

-      - ကိုယ်မသိတဲ့၊ မြင်ဖူးနေကြ မဟုတ်တဲ့ Process တွေ run နေတာ။

-     -  Mobile Data usage လိုတာထက် ပိုများနေတာ။

-     -  Device က တခါတခါ ကိုယ်မလုပ်ရပါပဲ သူ့ဖာသာ သူ restart ကျကျသွားတာ။

-      - တချို့ App တွေမှာ အရင် ကိုယ်ပေးထားတဲ့ Permission ထက် ပိုရနေတာ။ (ဥပမာ - GPS location permission ကို off ထားပေမယ့် ပြန်ကြည့်တဲ့ အခါ on နေတာမျိုးပေါ့။)

နောက်ထပ် အသေးစိပ် စစ်ဆေးနိုင်တာကတော့ Device Profile တွေမှာ ကိုယ်မသွင်းထားပဲ ရောက်နေတဲ့ Profile တွေရှိနေလား ဆိုတာ စစ်တာ။

ကိုယ်မရင်းနှီးတဲ့ App တွေ ရှိနေလား စစ်တာမျိုး။ (ဒါကတော့ Cerberus လို Stealth Mode မှာ အလုပ်လုပ်တဲ့ App မျိုးအတွက် သိဖို့ ခက်မှာပါ။)

သက်ဆိုင်ရာ App Store တွေရဲ့ Protect လုပ်ထားတဲ့ App တွေကိုပဲ သုံးတာမျိုးပေါ့။ (ဒါကလဲ ခက်ပါတယ်။ Stalkerware တွေက illegal app တွေ ဖြစ်မနေသေးလို့ပါ။ ဘာလို့လဲ ဆိုတော့ Children Monitor လိုမျိုးအတွက် ဖြစ်နေလို့ လောလောဆယ်ထိ Legal ဖြစ်နေသေးတာပါ။)

ဒီတော့ Stalkerware တွေ က မိမိရဲ့  Privacy ကို တနည်းတဖုံနဲ့ ချိုးဖောက်နေတယ်ဆိုတာကို သတိထားမိလောက်ပြီလို့ ယူဆပါတယ်။

တယောက်ယောက်က ကိုယ့် Device ထဲကို ရည်ရွယ်ချက်နဲ့ သွင်းထားပေမယ့် သွင်းထားတဲ့ သူ အပြင် Stalkerware App နဲ့ သူ့ Server ရဲ့ လုံခြုံရေးပိုင်း အားနည်းလို့ Hacker တွေ ထိန်းချုပ်တာ ခံရပြီဆိုရင်တော့ မမျှော်လင့်ထားတဲ့ ဆိုးကျိုးတွေနဲ့ ရင်ဆိုင်ကြရမှာပါ။

အားလုံးပဲ Stalkerware App များရန်မှ ပါးပါးနပ်နပ်နဲ့ ရှောင်နိုင်ကြပါစေ။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

 

 

 

 

How we should think like StepN developer on move2earn apps?

၂၀၂၁ ခုနှစ်၊ နိုဝင်ဘာလ မှာ အိုင်ဒီယာတူပြီး စျေးကွက်ထဲမှာ ရှိပြီးသား Application တွေ နဲ့ မတူပဲ တမူ ထူးခြားတဲ့ Web 3.0 Blockchain အခြေပြု “StepN” ဆိုတဲ့ Move to Earn Application တခု ထွက်ပေါ်လာခဲ့ပါတယ်။ 

ဒီ App ဟာ အရင်ရှိပြီးသားတွေ နဲ့ မတူတာကတော့ အသုံးပြုသူက Runner Shoes, Jogger Shoes, Walking Shoes ဆိုတဲ့ NFT ဖိနပ်တွေ ဝယ်ပြီးလေ့ကျင့်ခန်းလုပ်ရတာပါ။ 

လေ့ကျင့်ခန်း လုပ်သလောက် GST token ပြန်ရပြီး ရလာတဲ့ Token တွေကို ပြန်ရောင်းခြင်းဖြင့် ဝင်ငွေရစေတာပါ။ လူလဲ ကျန်းမာ၊ ဝင်ငွေလဲ ရ‌ပေါ့။ 

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

အဲဒီအထဲက Technical Challenge တွေ အကြောင်းကို ကျတော်လဲ ပုံစံတူ Application တခုလုပ်ရင်းက စံနမူနာယူရင်း နဲ့ တခြားကျတော်နဲ့ ရင်ဘတ်ချင်း တူတဲ့သူတွေ ဖတ်မိအောင် ပြန်ဖောက်သည်ချလိုက်ပါတယ်။ StepN App Developer တွေ အနေနဲ့ Technical Challenge 3 ခုကို ဖြေရှင်းခဲ့ရပါတယ်တဲ့။ 

Technical Challenge 1 – Proof of Movement (POM) 

Running Application, Wearable Gadget တွေ မှာ အသုံးပြုသူတွေ မှန်မှန်ကန်ကန် သုံးနေလား၊ လိမ်ညာသုံးနေလား ဆိုတာကို စစ်ဖို့ anti-cheating system ဆိုတာ ထည့်မထားပါဘူး။ ဘာလို့ ထည့်မထားတာလဲ ဆိုတော့ မလိုအပ်လို့ပါ။ ဒါပေမယ့် တနေ့ကို ခြေလှမ်း ဘယ်နှစ်လှမ်း၊ အကွာအဝေး ဘယ်လောက် ရောက်အောင် လျှောက်နိုင်ရင် ဘာပေးမယ် ညာပေးမယ်ဆိုတဲ့ Incentive/Reward Program တွေ ပါလာတဲ့ အခါမှာ အဲ့လို စစ်ဆေးတဲ့ စနစ် မပါတာဟာ လူတွေ လိမ်ညာဖို့ ဖြစ်လာတာပါပဲ။ ဒီအတွက် Proof of Movement ဆိုတာကို ထည့်သွင်းစဉ်းစားကြရပါတယ်။ ဒီပြဿနာကို ပြေလည်အောင် ရှင်းဖို့က Developer တွေဟာ Gravity Sensor အပါအဝင် 

 · The linear acceleration sensor 

 · The significant motion sensor 

 · The accelerometer 

 · The gyroscope sensor 

 · The step detector sensor 

 · The step counter 

 စတာတွေကို အသုံးပြုပြီး ဖြေရှင်းကြရပါတယ်။ Sensor တွေ ဘာလို့ ဒီလောက် အများကြီး သုံးဖို့လိုလဲ ဆိုတာကို Sensor တခုချင်းစီ ရှင်းမပြတော့ပါဘူး။ မြင်သာနိုင်ဖို့ အောက်မှာ Gravity Sensor ကနေ 3D ပုံစံနဲ့ ရလာတဲ့ Wavepattern တွေကို ပြထားပါတယ်။ Mobile Phone ကို လက်ထဲကိုင်ထားပြီး လှုပ်နေတာရယ်၊ ဘောင်းဘီ ရှေ့အိတ်ထဲ ထည့်ပြီး သွားတာရယ် နဲ့ ရှပ် အင်္ကျီ အိတ်ကပ် ထဲ ထည့်ပြီးသွားတာရယ်မှာ Wavepattern တွေ က ဆင်တူနေတာကို တွေ့မှာပါ။

ဒါကြောင့် များပြားလှတဲ့ Sensor တွေရဲ့ အကူအညီ နဲ့ ပိုပြီးတိကျ တဲ့ ရလာဒ် ရဖို့ Three Factor Authentication Process ကို အသုံးပြုကြရပါတယ်။ Three Factor Authentication Process ဆိုတာက Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ လူရဲ့ လှုပ်ရှားပုံ ကို pattern ကို စစ်တဲ့ mobile motion matches human movement wavelength၊ Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ Mobile device က ရတဲ့ ခြေလှမ်း အရေအတွက် mobile motion matches mobile step counter၊ Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ GPS လမ်းကြောင်း mobile motion matches GPS track သုံးခု က ရတဲ့ အချက်အလက်ကို အသုံးချ တာ ကို ဆိုလိုတာပါ။ 

Technical Challenge 2 – Proof of Distance 

အကွာအဝေး အမှန်ကို ရဖို့ကို Step Counter နဲ့ GPS track ကနေ ရနိုင်ပါတယ်။ အဓိက ပြဿနာက Step Counter ကို လွယ်လွယ်ရနိုင်ပေမယ့် GPS က ရတဲ့ အချက်အလက်က ရာနှုန်းပြည့် မမှန်တာပါပဲ။ သစ်ပင်အောက်တို့ ၊ အဆောက်အအုံ တခုခုထဲ ရောက်နေတဲ့ Mobile Device ရဲ့ GPS data ဟာ မမှန်နိုင်ပါဘူး။ စမ်းသပ်ချက်တွေ အရကတော့ အခန်းတခုရဲ့ စားပွဲ‌ပေါ်မှာ တင်ထားတဲ့ Mobile Device ရဲ့ GPS data က အချိန်ကြာလေလေ နေရာ ရွေ့နေလေပါပဲ။ အပြင်မှာ ဆိုရင် ၃ မီတာကနေ မီတာ ၂၀ ထိတောင် ရွေ့နေတတ်ပါတယ်တဲ့။ ဒီ အခြေအနေကို GPS Drifting လို့ ခေါ်ပါတယ်။ GPS က Quality အနေနဲ့ လဲ Degrade ဖြစ်ပါသေးတယ်။ GPS Signal ပျောက်သွားတတ်တာ မျိုး ကြုံဖူးကြမှာပါ။ အဲ့လို ဖြစ်တဲ့ အခါ Re-route/ Re-calculate ပြန်လုပ်ရပါတယ်။ မျဉ်းဖြောင့်အတိုင်း သွားနေတာ မဟုတ်ပဲ အကွေ့ အကောက်နဲ့ သွားနေရင်း GPS Signal ပျောက်သွား တဲ့ အခါ Signal loss ဖြစ်သွားတဲ့ နေရာကနေ ပြန်ပေါ်လာတဲ့ နေရာ Point ၂ ခု ကို GPS က မျဉ်းဖြောင့် အတိုင်း ပြန်တွက်ပါတယ်။ ဒီအခါမှာ မှန်ကန်တိကျ တဲ့ အကွာအဝေးကို မရတော့ပါဘူး။ 

ဒါကို GPS Degrading ဖြစ်တယ်လို့ ခေါ်ပါတယ်။ မြင့်မားတဲ့ အဆောက်အဉီး တွေ ကြားထဲ ရောက်တဲ့ အခါမှာ GPS Signal တွေက Bounce ဖြစ်တတ်ပါသေးတယ်တဲ့။ အဲ့လိုဖြစ်တဲ့ အခါ Track Distance တွေက ၂ ဆ ၃ ဆ ထိ တက်သွားတတ်ပါတယ်။ အဲ့လို အခြေအနေကို GPS Bounce လို့‌ခေါ်ပါတယ်။ ဒီ GPS ပြဿနာတွေကို GPS drift corrective, environmental factor canceling နဲ့ player route planning algorithms တွေကို သုံး ပြီး ရှင်းကြပါတယ်။  

Technical Challenge 3 – Hack Prevention 

နောက်ဆုံး တခုကတော့ Android Emulator လို Mobile OS Emulator တွေသုံးပြီး Hack တာကို ရှင်းကြတာပါ။ User Experience ကို ထိခိုက်စေတဲ့ Captcha လိုဟာတွေ သုံးပြီး ဖြေရှင်းဖို့ ကြိုးစားတာတောင် မရခဲ့ပါဘူး။ နောက်ဆုံးမှာတော့ Machine Learning ကို သုံးပြီး ရှင်းခဲ့ရပါတယ်တဲ့။ ကဲ ဒါကတော့ StepN Developer တွေ နဲ့ အားကျနမူနာ ယူစရာကောင်းတဲ့ သူတို့ ရဲ့ Technical Challenge တွေကို ဖြေရှင်းကြပုံပါ။ 

တခြား Design Challenge အပါအဝင် Server, Storage, Communication စတာတွေ အများကြီး ကို ဖြေရှင်းကြရပါသေးတယ်။ 

ကျတော်က တော့ ကျန်တာတွေ ထက် အပေါ်က Technical Challenge ၃ ခုကို အရမ်းသဘောကျလို့ ဖတ်မှတ် စရာ တခုအနေနဲ့ မှတ်တမ်းတင်ထားလိုက်တာပါ။ 

အသေးစိတ် ဖတ်ချင်ရင်တော့ အောက်က လင့်မှာ သွားဖတ်ကြည့်နိုင်ပါတယ်။ https://stepnofficial.medium.com/how-did-we-build-the-worlds-first-move2earn-nft-game-in-four-months-fde4d13dfb18 

 ကျေးဇူးတင်ပါတယ်။ 

 ပျော်ရွှင်ပါစေဗျာ။ 

(Be knowledgeable, pass it on then)