Dear reader, please download one of Myanmar unicode font and install it on your PC to see my blog well.Thanks.

Why Shared Responsibilities is important on Cloud?

ကျ တော် CompTIA CySA+ Course လေ့လာတုန်းက သင်တဲ့ ဆရာပြောတာလေးက On-Premise ထက်စာရင် Cloud Service Provider တွေရဲ့ Infra က ပို Secure ဖြစ်တယ်ဆိုတာပါပဲ။

တကယ်လဲမှန်ပါတယ်။

ဒါပေမယ့် Cloud Service ကိုသုံးပြီဆိုတာနဲ့ လိုက်နာရမယ့် Share Responsibilities ဆိုတာရှိပါတယ်။

အောက်ကပုံလေးကို ကြည့်လိုက်ရင် အကျဉ်းအားဖြင့် နားလည်ပါတယ်။



ပိုတိတိကျကျ သိချင်ရင် တော့ လိုက်နာရမယ့် Best Practice တွေကို အတိအကျလိုက်နာဖို့ လိုပါတယ်။

ကျ တော်တို့ Cloud ပေါ်တက်လာပြီး အလုပ် တွေ လုပ်ကြတဲ့ အခါ တော်တော်ကို ကြီးမားတဲ့ အမှားတွေ လုပ်ကြပါတယ်။

ဘာတွေလုပ်တာလဲ ဆိုရင် User Account တွေ ရဲ့ Role နဲ့ Policy ကို Identity Access Management မှာ သေချာ Control မလုပ်ကြပါဘူး။
Network Access Control List  မှာ ဘာလာလာ ပေးဝင်တဲ့ အလှူဒါန ရက် ရော ကြပါတယ်။
Security Group တွေ ကို လည်း Upstream , Downstream Security Group တွေနဲ့ Tag မလုပ်ကြပဲ NACL မှာ လို ဘာလာလာ ပေးဝင်တဲ့ အလှူမျိုး ထပ်လုပ်ကြပါတယ်။
ပိုဆိုးတာက တော့ Test EC2 Instance တွေကို Programmatic Access Key တွေ နဲ့ Public က နေ Access လှမ်းလုပ်လို့ရ အောင် လုပ်ထားတာမျိုးပါပဲ။
အလားတူ API Key, SSH Key စတာမျိုးတွေကို Limited Access လုပ်မထားတဲ့ Test EC2 Instance တွေမှာ သိမ်းထားတာပါပဲ။
S3 Bucket တွေကို အလှူပေးထားတာမျိုးတွေလည်း ပါသေးတာပေါ့။
ဒါတွေက လက် တွေ့မှာ အဖြစ်များ အ တွေ့များနေတဲ့ Human Error, Misconfiguration Error တွေပါပဲ။

ဒါမျိုးတွေက ကျ တော်တို့ချည်းပဲ ဖြစ် နေ လုပ် နေတာတော့ မဟုတ်ပြန်ဘူးဗျ။
ထင်သာမြင်သာတဲ့ ဖြစ်ရပ်တခုကို ဥပမာ အ နေနဲ့ ပြရမယ်ဆိုရင် လွန်ခဲ့ တဲ့ လပိုင်းလောက်က ဖြစ်သွားတဲ့ Imperva Security Breach ကိုပဲ အောက်က လင့်က နေ ဖတ်ကြည့်နိုင်ပါတယ်။

Imperva Data Breach Caused by Stolen AWS API Key

ဒီနေ့လို ခေတ်မှာ Scanning/Probing ဆိုတာ လူကိုယ်တိုင်က လုပ် နေစရာ မလိုတော့ပါဘူး။
ဒီတော့ ကိုယ့်က Test လုပ် နေတာပါဆိုပြီး ကိုယ့် Cloud Resource ကို လာသမျှ ပေးဝင်တဲ့ အလှူမျိုး လုပ်ထားလို့က တော့ လူတကာ ဝင် မွှေသွားတာ ခံရပြီး အခန့်မသင့်ရင် Priviliege Escalation, APT စတဲ့ အ မွှေစိန် တွေနဲ့ နဖူးတွေ့ ဒူးတွေ့ ရင်ဆိုင် ရမှာပါ။ ဒါတောင် ဒင်းတို့ ကိုယ့် Infra ထဲရှိနေတယ်ဆိုတာကို ၅ နှစ် လောက် နေမှ သိတာမျိုး ဖြစ်ချင်ဖြစ် နေမှာဗျ။

အ ပြောပဲ ရှိ တာ မဟုတ်ဘူးဗျာ။

မယုံရင် အောက်က လင့်တွေမှာ ကမ္ဘာတလွှားက Cyber Attack တွေရဲ့ Live ကို ကြည့်နိုင်ပါတယ်။ သက်ဆိုင်ရာ Vendor တွေရဲ့ Device Sensor တွေက ပို့ပေးတဲ့ အချက်အလက်ဆိုတော့ အတိအကျ တော့ မရနိုင်ဘူးပေါ့။

Live Cyber Threat Map by Checkpoint

Live Cyber Threat Map by Fortinet

FireEye Cyber Threat Map

Cyber Threat Live Map by Kaspersky

ဒါပါပဲ။

ကိုယ်တိုင်က AWS နဲ့ အဓိက လုပ်နေရလို့ AWS နဲ့ ယှဉ်ပြီး ပြောတာပါ။
ဒါတွေကို Cloud ပေါ်မှာ သတိထားသင့်ပါတယ်။

အ ပေါ်က အမှားမျိုးကို ခဏခဏ တွေ့ရသလို ကိုယ်တိုင်လဲ နဖူးတွေ့ ဒူးတွေ့ ကြုံဖူးတဲ့ အတွက် ကိုယ့်လို မဖြစ်ရ အောင် သတိထားနိုင်ကြ စေဖို့ ဒီစာရေးရင်း  ၂၀၁၉ ကို နှုတ်ဆက်လိုက်ပါပြီဗျာ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Infrastructure as code with Terraform on AWS

Netflix လို ထောင်နဲ့သောင်းနဲ့ ချီတဲ့ AWS Resource တွေကို Manually Manage လုပ်ဖို့ဆိုတာ အတော်ခက်ခဲပါတယ်။
Blue/Green Architecture လိုမျိုး Continuous Integration/Continuous Deployment လုပ်ဖို့ အတွက်ဆို ကျတော်တို့တွေ အရင်လို Manual လုပ်နေလို့မရပါဘူး။

Cloud Computing ခေတ်မှာ Resource တွေက ကြိုက်သလောက်သုံးကျသလောက် ရှင်းပုံစံနဲ့ သွားနေသလို။ Compute/Resource တခုခုကို Start/Stop လုပ်ရတာလဲ အရမ်းကို လွယ်ကူမြန်ဆန်လာပါတယ်။

ဒီတော့ ခုနောက်ပိုင်း Infrastructure as Code ဆိုတာ အရမ်းခေတ်စားလာတော့တာပေါ့။

Cloud ပေါ်မှာ Business Application တခုကို Distributed System, Micro-Service ပုံစံတွေ ဆောက်တဲ့ အခါ Resource တွေကို မြန်မြန်ဆန်ဆန်ဆောက်ပြီး စမ်းကြပါတယ်။ Staging, UAT လို မျိုးက အမြဲတမ်း Run ထားဖို့ မလိုပဲ လိုအပ်တဲ့ အခါမှ Resource တွေကို ချက်ချင်းဆောက်ပြီး Run and Test လုပ်နိုင်လာကြပါပြီ။

 ဒီတော့  လိုချင်တဲ့ Infrastructure မျိုးကို Code ရေး၊Template ထုတ်သိမ်းထားပြီး လိုအပ်တဲ့ အချိန်မှာ ကောက် Run လိုက်တဲ့အခါ အချိန်လဲကုန် သက်သာ အမှားကင်းတဲ့ Infra မျိုးရပြီး စမ်းလို့ရတာပေါ့။ စမ်းပြီး မလိုတော့တဲ့ အချိန်မှာလဲ Resource တွေကို Terminate လုပ်ပြီး ငွေကြေးကုန်ကျမှုကို ခြွေတာနိုင်ပါသေးတယ်။

ဒီအတွက် Infra as a code ဆိုတာဘာလဲ။ ဘယ်လိုမျိုးလဲဆိုတာ သိရအောင် အောက်က Youtube Video မှာ ကျတော်က Terraform ကို သုံးပြီး AWS ပေါ်မှာ VPC, Subnet နဲ့ EC2 Instance တွေကို အခြေခံ နမူနာ ဆောက်ပြထားပါတယ်။

https://youtu.be/dkJ1fr8-6h0

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Installing Python, Paramiko and Netmiko on Windows


Python နဲ့ပတ်သက်ပြီး Video Tutorial တွေ၊ Blog post တွေထဲမှာ ရှင်းပြထားတာက Program ကို Linux ပေါ်မှာ Run ပြတာပါပဲ။ ကိုယ်တွေလိုက်လုပ်ရင်လဲ Emulator, Simulator ပေါ်မှာတော့ Linux နဲ့ စမ်းတာပေါ့။ ဒါပေမယ့် ကျတော်တို့ ကြုံရတဲ့ ပြဿနာက တကယ့် Real World မှာ သုံးချင်တဲ့ အခါ လုပ်ငန်းခွင်သုံး တွေက Windows အများဆုံး ဖြစ်နေတာပါပဲ။
ဒီတော့ Network သမားတယောက်ရဲ့ Windows System ပေါ်မှာ Python နဲ့ သူ့ကို Run ဖို့ လိုအပ်တဲ့ Module တွေ ဘယ်လို Install လုပ်လဲ ဆိုတာကို ပြန်ဝေမျှချင်ပါတယ်။
ပထမဆုံး Python ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

ပြီးတာနဲ့ Anaconda ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

နောက်တဆင့်က Windows အတွက် Git ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

လိုတာတွေ Download လုပ်ပြီး Install လုပ်တဲ့ပြီး အခါ Anaconda ရဲ့ Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး အောက်က ပုံတွေမှာ ပြထားတဲ့ Command တခုချင်းစီ ရိုက်ထည့်ပြီး download and install လုပ်ပါ။
၁) Installing Paramiko
 

၂) Installing SCP

Anaconda နဲ့ အပေါ်က ၂ ခု လုပ်ပြီးတဲ့ အခါ Git Bash Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး Github က Netmiko Repo ကို clone လုပ်ယူပါ။ အောက်က ပုံမှာ ပြထားတဲ့ အတိုင်း Command တွေလိုက်ရိုက်ပြီး လုပ်သွားပါ။


ပြီးရင် အောက်ကပုံထဲက အတိုင်း Python Setup Script ကို install လုပ်ပါ။


အပေါ်က အဆင့်တွေကို ဘာပြဿနာမှ မရှိပဲ လုပ်ပြီးပြီဆိုရင် Command Prompt ဖွင့်ပြီး အောက်ကပုံထဲကလို Python ကို ဝင်ပြီး Paramiko နဲ့ Netmiko Module တွေ Import လုပ်ထားပြီး မပြီး စစ်နိုင်ပါတယ်။


ပုံထဲကလို တွေ့ပြီဆိုရင်တော့ Python Program တွေ သုံးဖို့ အဆင်သင့်ဖြစ်ပါပြီ။

Paramiko နဲ့ Netmiko ကို Windows မှာ ဘယ်လို Install လုပ်ရလဲ နဲ့ import netmiko , import paramiko တွေ run တိုင်း ပေါ်လာတဲ့ error တွေကြောင့် ခေါင်းကိုက်ရခြင်း ကင်းဝေးကြပါစေ။

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

What are AWS VPC Endpoints and when to use them?

ကျတော်တို့ အိုင်တီလောက မှာ least privilege access ဆိုတာ အရေးကြီးပါတယ်။

ဒါက On-premise မှာတင် သုံးဖို့ မဟုတ်ပဲ Cloud ပေါ်ထိ သက်ရောက်ပါတယ်။

ကျတော်တို့ AWS VPC တခုဆောက်တဲ့ အခါ Public, Private Subnet တွေထဲက Instance တခု သို့မဟုတ် များစွာသော Instance တွေအတွက် ကိုယ့် VPC အပြင်ဖက်မှာ ရှိတဲ့ AWS Service တွေရဲ့ API တွေကို Access လုပ်ဖို့ လိုပါတယ်။ ဥပမာ အနေနဲ့ Amazon S3 , DynamoDB နဲ့ Kinesis တို့လိုပေါ့။

ဒီအခါ မှာ ပုံမှန်ဆိုရင် ကိုယ့် VPC ထဲက Instance တွေက အပေါ်က Service API တွေကို Access လုပ်ဖို့ Internet ကိုထွက်ပြီး Access လုပ်ရမယ်ပေါ့။

ဒါကို ကျတော်တို့က မလိုချင်ဘူးဗျာ။ အကောင်းဆုံး အကြောင်းပြချက်တချို့ကို ပြရမယ်ဆိုရင် လုံခြုံရေးအရရယ်၊ Latency , Speed နဲ့ Bandwidth အသုံးပြုမှုတွေပေါ့။ ဒါတွေကြောင့် ကျတော်တို့က ကိုယ့် VPC ထဲက Instance တွေ Internet ပေါ်တက်ပြီး S3 တို့ဘာတို့ကို Access လုပ်စရာ မလိုပဲ သုံးဖို့ AWS VPC Endpoint ဆိုတာ ပေါ်လာတာပေါ့။

AWS VPC Endpoint မှာ
- Gateway VPC Endpoint နဲ့
- Interface VPC Endpoint ဆိုပြီး နှစ်မျိုးရှိပါတယ်။

Gatway VPC Endpoint ကတော့ ရှင်းပါတယ်။ တခုထက်ပိုတဲ့ Instance တွေ VPC အပြင်က Service API တွေကို သုံးချင်တဲ့ အခါ သုံးတာပေါ့။

အောက်က ပုံမှာလို Subnet 2 က Instance တွေ S3 ကို Access လုပ်သလိုမျိုးပေါ့။


Interface VPC Endpoint ကတော့ အောက်ကပုံထဲကလို Subnet 1 က Instance တခုထဲ အတွက် သုံးတာမျိုးဗျ။



VPC Endpoint ကို သုံးလိုက်ရင် လိုတာထက်ပြီး Access ပေးရတဲ့ VPC Peering တွေလဲ မသုံးပဲနေလို့ရတယ်။

သူ့ကို တခြား AWS Service တွေလိုပဲ Identity Access Management သုံးပြီး Role, Policy တွေ နဲ့ Access Control လုပ်နိုင်ပါသေးတယ်။

ဒါကတော့ VPC Endpoint တွေအကြောင်း ယေဘုယျ ရှင်းပြတာပါ။
ပိုပြီး အသေးစိတ်သိချင်ရင်တော့ အောက်က AWS Website ရဲ့ VPC Endpoint FAQ page မှာ လေ့လာနိုင်ပါတယ်။

https://aws.amazon.com/vpc/faqs/

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Automating Web Application Firewall Creation in AWS

Web Application Firewall တခု မှာ ဝင်လာတဲ့ Web Request Traffic ကို စစ်ဖို့

-          - Conditions
-          - Rules
-          - Web Access List
-          - Default Action ဆိုပြီး အစိတ်အပိုင်း (၄) ပိုင်းပါပါတယ်။
Conditions မှာတော့ Cross-Side Scripting, Geo Match, IP Blacklist, SQL Injection, Packet Size Constraint နဲ့ Regular String Match စတာတွေ ပါပြီး၊ Conditions ပေါင်း များစွာကို ပေါင်းပြီး condition တခုအနေနဲ့ configure လုပ်ထားနိုင်ပါတယ်။

Rule မှာတော့ အပေါ်က Conditions တွေကို ထပ်ပေါင်းပြီး configure လုပ်နိုင်ပါသေးတယ်။
Web Access List ကျတော့မှ Rule တွေကို Top-Down ပုံစံ configure လုပ်ရတာပါ။

နောက်ဆုံး Default Action ဆိုတာကတော့ ကျတော်တို့ Firewall တို့ရဲ့ ထုံးစံအတိုင်း Implicit Deny/Permit ကို သတ်မှတ်ပေးရတာပါ။

ဒီတော့ Web Application Firewall တခုလုပ်တော့မယ်ဆိုရင် အပေါ်က အချက်တွေ တခုချင်းစီကို Configure လုပ်ရပါတယ်။
အဲ့ဒီလို လုပ်တဲ့ အခါ ကိုယ့် Web Application တခုချင်းစီအတွက် Condition, Rule, Access List တွေ setup လုပ်ရတာ အတော်ကို အချိန်ယူပါတယ်။
တခုထက်ပိုများတဲ့ Web Application တွေအတွက်ဆိုရင် ပိုဆိုးတာပေါ့။

ဒီတော့ အချိန်ကုန်သက်သာအောင် AWS ပေါ်မှာ  Open Web Application Security Project (OWASP) ရဲ့ Top Ten WAF Rules နဲ့ AWS WAF ကို CloudFormation သုံးပြီး  ဘယ်လို Auto Implementation လုပ်လဲ ဆိုတာ ပြပါမယ်။

ပထမဆုံး လိုတာကတော့ OWASP Top Ten WAF Rule တွေပါတဲ့ YAML Template ကို အောက်က လင့်မှာ Download လုပ်ပါ။


ပြီးရင်
- AWS Management Console ကို သွားပြီး Login ဝင်ပါ။
- CloudFormation ကို သွားပါ။ အရင်က ဖွင့်မထားဘူးရင် Search မှာ ရှာလို့ရပါတယ်။


- Create stack ကို နှိပ်ပါ။


-      Template is ready ကို နှိပ်ပြီး Template Source နေရာမှာ S3 URL ကနေ ပဲ ယူ မလား။ Download လုပ်ထားတဲ့ YAML Template ကိုပဲ သုံးမလားရွေးပါ။


စမ်းချင်တာဆိုရင် တော့ အပေါ်မှာ ပြောခဲ့ တဲ့ လင့်ကိုပဲ S3 URL မှာ ထည့်လိုက်ရင် ရပါတယ်။
Customize လုပ်ချင်ရင်တော့ YAML Template ကို ပြင်ပြီးတော့မှ Upload လုပ်ပြီး Next နှိပ်ပါ။
-          Stack Name, Prefix နဲ့ WAF ကို ဘယ်မှာထားချင်တာလဲ  (Global လား Regional လား) စတာတွေကို မိမိ လိုချင်တဲ့ အတိုင်း ထည့်ပြီး Next နှိပ်ပါ။


-          Stack Name, Tagging တွေနဲ့ IAM Role တွေ နဲ့ တခြား မိမိ Customize လုပ်ချင်တဲ့ Setting တွေရှိရင် ထည့်ပြီး Next နှိပ်ပါ။

-         
နောက်ဆုံး အဆင့်မှာတော့ ကိုယ့် WAF က ကိုယ်လိုချင်တဲ့ Setting တွေအတိုင်း ဟုတ်မဟုတ် စစ်ပြီး Create Stack ကို နှိပ်ပြီး Stack Creation ပြီးတဲ့ အထိစောင့်ပါ။
-          

၁၅ မိနစ်ကနေ မိနစ် ၃၀ အတွင်းမှာ WAF ရလာပါလိမ့်မယ်။
ဒါဆို ရင် ပုံမှန် အတိုင်း Manual ဆောက်မယ်ဆိုရင် ၃ နာရီလောက်ကြာနိုင်မယ့် Web Application Firewall ကို CloudFormation နဲ့ ဆောက်လိုက်တဲ့ အခါ နာရီဝက်လောက်နဲ့ ပြီးသွားတာကို တွေ့ရမှာပဲ ဖြစ်ပါတယ်။

 

ဒါက ကျတော် Demo အနေနဲ့ အလွယ်ဆုံး အရိုးရှင်းဆုံး လုပ်ပြတာပါ။
တကယ်လို့ ပိုမိုပြည့်စုံပြီး တိကျတဲ့ OWASP Top (10) Base WAF တခု လိုချင်ရင်တော့ YAML Template ကို မိမိစိတ်ကြိုက်ပြင်ပြီး တော့မှ Stack လုပ်ပေါ့။ တခုသိထားရမှာက WAF နဲ့ သူ့ရဲ့ အစိတ်အပိုင်းတွေက Create လုပ်ပြီးသွားရင် ပြန်ပြင်လို့ မရပါဘူး။ နာမည်လေးတောင် ပြင်လို့မရပါဘူး။ ဖျက်လို့ပဲ ရပါတယ်။ ဒါကြောင့် Create မလုပ်ခင် မိမိစိတ်ကြိုက် သေချာ ပြင်ပါလို့ အကြံပေးချင်ပါတယ်။
နောက်ဆုံး တခု ပြောချင်တာက WAF က AWS မှာ Free မဟုတ်ပါဘူး။ Free-Tier သမားတွေ သတိထားဖို့ပါ။ Create လုပ်ပြီးတာနဲ့ Rule တခုစီအတွက် ပိုက်ဆံ စ ကောက်တာပါ။ စမ်းချင်ရင်တော့ မြန်မြန်စမ်းပြီး မြန်မြန်ဖျက်ဖို့ မမေ့ပါနဲ့။ မေ့ရင်တော့ ကိုယ့်ဒေါသနဲ့ ကိုယ်ပေါ့ဗျာ။

Screenshot လေးတွေ သေးပြီး မမြင်ရရင် တပုံချင်းစီ ကလစ်နှိပ်ပြီးကြည့်ပါဗျာ။
ပုံအကြီးတွေတင်ရင် Blog Template နဲ့ မဆန့်လို့ပါ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)







Contact Form for ictformyanmar.com

Name

Email *

Message *