Application Gateway ဆိုတာက Client application ကနေ Web App တွေဆီကို ပို့လိုက်တဲ့ Request တွေကို Manage လုပ်ပေးတဲ့ Service တစ်ခုပါ။
Application Gateway က Application Layer Routing ကိုအသုံးပြီးတော့ request လုပ်လာတဲ့ URL တွေ အပေါ်မူတည်ပြီးတော့ traffic တွေကို Backend မှာရှိတဲ့ Web Server Pool တွေဆီ Route လုပ်ပေးပါတယ်။ Backend ထဲမှာ အဓိကအားဖြင့် VM, VM Scale Sets, App Service, On-Premises Server တွေ အစရှိသဖြင့်ပါဝင်ပါတယ်။ အကယ်၍ Backend Pool ထဲက Server တွေမှာ Load Balance တွေကို အသုံးပြုထားမယ်ဆိုရင် Round Robin ကိုအသုံးပြုပြီး request traffic တွေကို Backend Pool ဆီပို့ပေးပါတယ်။
နောက်ထပ် Application Gateway က Session Stickiness ကို ထပ်ပံ့ပေးနိုင်တဲ့ အတွက်ကြောင့် Client request တွေက same session ဖြစ်နေခဲ့မယ်ဆိုရင် traffic တွေကို backend pool ထဲမှာရှိနေတဲ့ same server တွေဆီကိုပဲ route လုပ်ပေးပါတယ်။
နောက်တစ်ခုက Application Gateway မှာ Load Balancing ဘယ်လိုအလုပ်လုပ်လဲကြည့်ရအောင်။ Load Balancing က OSI Layer 7 (Application Layer) မှာ အလုပ်လုပ်ပြီးတော့ Application Gateway Rules တွေထဲမှာရှိတဲ့ routing parameter (hostname and paths) ကို အသုံးပြုပြီး request တွေကို Load-Balancing လုပ်ပေးပါတယ်။ Azure Load Balancer က request လုပ်လာတဲ့ target တွေရဲ့ IP Address တွေ အပေါ်မှာ မူတည်ပြီးတော့ traffic တွေကို distribute လုပ်ပေးပါတယ်။
Additional Features တွေအနေနဲ့ ထပ်ပြောရမယ်ဆိုရင်
1. Http, Https, Http/2 နှင့် Web Socket protocol တွေကို ထောက်ပံ့ပေးနိုင်ပါတယ်။
2. Web application တွေရဲ့ vulnerabilities (ယိုပေါက်) တွေကနေ တိုက်ခိုက်မှုဒဏ်ကို ကာကွယ်ပေးနိုင်ဖို့အတွက် Web Application Firewall (WAF) တွေကို အသုံးပြုလို့ရပါတယ်။
3. End-to-end request encryption
4. Web Traffic Load တွေရဲ့ ပြောင်းလဲမှု အပေါ်မှုတည်ပြီး လိုအပ်တဲ့ Capacity တွေကို အလိုအလျောက်ချိန်ဆပြီး Autoscaling လုပ်လို့ရပါတယ်။
Determine Application Gateway Routing
Client က Web Application request တွေကို Gateway ရဲ့ IP Address သို့မဟုတ် DNS Name တွေကိုပေးပို့ပါတယ်။ အဲ့ဒီအခါ Gateway က route request တွေနဲ့ ပတ်သက်ပြီး Backend Pool ထဲ့က Server တွေကို ရွေးချယ်ဖို့အတွက် သတ်မှတ်ထားတဲ့ Rule တွေကိုအသုံးပြုပြီး request တွေ ဘယ်လိုသွားသင့်လဲဆိုတာကို ဆုံးဖြတ်ပါတယ်။
နောက်တစ်ခုက Path Based Routing နှင့် Multiple Site Routing ရယ်ဆိုပြီးတော့ အဓိကအားဖြင့် Routing Traffic နှစ်မျိုးရှိပါသေးတယ်။
Path Based Routing
မတူညီတဲ့ Backend Pool ထဲက Server တွေကို မတူညီတဲ့ URL Path တွေနဲ့ လှမ်းပြီး request လုပ်တာမျိုးကို Path Based Routing လို့ခေါ်ပါတယ်။
ဥပမာ အားဖြင့် ပြောရမယ်ဆိုရင် - Video Streaming နဲ့ပတ်သက်ပြီး backend pool ထဲက Server တွေရဲ့ /video/* path ကို တိုက်ရိုက် request လုပ်မယ် ဒါမှမဟုတ် Image Retrieval နဲ့ပတ်သက်ပြီး /image/* path တွေကို တိုက်ရိုက် request တာမျိုးပါ။
Multiple Site Routing
တူညီတဲ့ Application Gateway Instance တွေမှာရှိတဲ့ Web Application တွေကို requset လုပ်တဲ့အခါမျိုးမှာ Multiple Site Routing ကို အသုံးပြုပါတယ်။ Multiple Site Configuration မှာ Application Gateway ရဲ့ IP Address တွေကို သက်ဆိုင်ရာ Site တစ်ခုချင်းဆီရဲ့ DNS Name (CNAMEs) တွေနဲ့ Register လုပ်ပေးရပါတယ်။ Application Gateway က Listener တွေကို seperate လုပ်ပြီးတော့ Site တစ်ခု ချင်းဆီအတွက် request တွေကို စောင့်ဆိုင်းပါတယ်။ မတူညီတဲ့ Backend Pool ထဲက Server တွေဆီ request တွေ route လုပ်ဖို့အတွက် မတူညီတဲ့ Rule တွေ အပေါ်မှုတည်ပြီး Listener ကို ဖြတ်ရပါတယ်။
ဥပမာ - http://contoso.com အတွက် Backend Pool ထဲက Server ကို request လုပ်ပြီး၊ http://fabrikam.com အတွက် အခြား Backend Pool ထဲက Server ဆီကို request လုပ်တာမျိုးပါ။
Multi-site Configuration ကို multi-tenant application အတွက် အသုံးပြုပါတယ်။
Tenant ဆိုတာက Virtual Machines အစုအဝေးတွေ သို့မဟုတ် Web Application တွေနဲ့ ပတ်သက်တဲ့ Resource တွေကို Host လုပ်ထားတာကိုခေါ်တာပါ။
Other Features
1. Redirection - Site တစ်ခုကနေ တစ်ခုကို Redirection လုပ်ပေးနိုင်ပါတယ်။ ဥပမာ - ကျွန်တော်ရဲ့ Site name က cracky.tech ဆိုပါဆို တကယ်လို့သာ cracky.tech site က Error တစ်ခုခုတက်ခဲ့ပြီး User တွေက အဲ့ Site ကို access လုပ်လို့မရတော့ရင် cracky.info site ဆီကို Redirect လုပ်လိုက်တာမျိုးပါ။ Site Redirection အပြင် Http ကနေ Https ကိုလည်း redirect လုပ်ပေးနိုင်ပါသေးတယ်။
2. Rewrite Http Headers - Http headers ကတော့ Client နဲ့ Server တွေရဲ့ Parameter Information တွေအပေါ်မှာ မူတည်ပြီးတော့ request and response တွေကို ခွင့်ပြုပေးပါတယ်။
3. Customer Error Pages - တကယ်လို Application Gateway ရဲ့ Default Error Page အစား ကိုယ်ပိုင် branding နဲ့ layout ကို အသုံးပြုပြီး custom error page တွေကို အသုံးပြုနိုင်ပါတယ်။
Setup Application Gateway Components
Application Gateway ဟာ Components ပေါင်းများစွာနဲ့ ပေါင်းစပ်ထားပြီးတော့ Backend Pool ထဲမှာ ရှိနေတဲ့ Web Server တွေကို Client တွေ request လှမ်းလုပ်တဲ့ အခါမျိုးမှာ အဲ့ဒီ Web Server တွေကို healthy ဖြစ်မဖြစ် စစ်ဆေးပြီးတော့ healthy ဖြစ်တဲ့ Web Server ဆီ Client တွေရဲ့ request တွေကို route လုပ်ပေးပါတယ်။
Application Gateway ရဲ့ Components တွေ အကြောင်း အောက်မှာ အသေးစိတ်ရှင်းပြထားပါတယ်။
Front-end IP Address
Client တွေရဲ့ request တွေကို Front-end IP ကနေ လက်ခံရရှိပါတယ်။ Application Gateway ကို Public IP, Private IP သို့မဟုတ် နှစ်ခုစလုံးနဲ့ configure လုပ်နိုင်ပါတယ်။ တစ်ခုရှိတာက Application Gateway မှာ Public IP ရော Private IP ရော တစ်ခုထက်ပိုလို့မရပါဘူး။
Listener
Application Gateway က incoming request တွေနဲ့ပတ်သက်ပြီး multiple listener တွေကို အသုံးပြုပါတယ်။ Listener က Host, IP Address, Protocol နှင့် Port တွေ ပေါင်းစပ်ထားသော Traffic များကို လက်ခံပါတယ်။ နောက်တစ်ခုက ကျွန်တော်တို့ သတ်မှတ်ထားတဲ့ Routing Rule တွေ အပေါ်မှာမူတည်ပြီးတော့ Client တွေရဲ့ request တွေကို Backend Pool ထဲက Server တွေဆီ Listener က Route လုပ်ပေးပါတယ်။ Listener မှာ Basic နှင့် Multisite ဆိုပြီးတော့ ရှိပါသေးတယ်။ Basic Listener ကတော့ Client request တွေနဲ့ပတ်သက်ပြီး URL ရဲ့ Path တစ်ခုထဲကိုသာ route လုပ်ပေးနိုင်ပေမယ့် Multisite Listener ကတော့ URL ရဲ့ hostname element တွေကိုပါ route လုပ်ပေးနိုင်ပါတယ်။
နောက်ဆုံးတစ်ခုအနေနဲ့ ထပ်ပြောရမယ်ဆိုရင် Application security အတွက် User တွေနဲ့ Application Gateway ကြားထဲမှာ SSL/TLS တွေကိုပါ Listener က handle လုပ်ပေးနိုင်ပါသေးတယ်။
Routing Rules
Routing Rule က Listener နှင့် Backend Pool ကြားထဲမှာ ရှိပါတယ်။ Client request တွေရဲ့ URL path element နှင့် hostname တွေကို သက်ဆိုင်ရာ Backend Pool ဆီကို ညွှန်ပေးပါတယ်။ Routing Rule တစ်ခု ဖန်တီးမယ်ဆိုရင် Http Setting တစ်ခုကို မဖြစ်မနေ သတ်မှတ်ပေးရပါမယ်။ အဓိကကတော့ Backend Pool ထဲက Server တွေနဲ့ Application Gateway ကြားထဲက traffic တွေကို encrypt လုပ်ဖို့အတွက်ပါ။ အခြားသော configuration information တွေအနေဖြင့် Protocol, Session Stickiness, Connection, Request Timeout နှင် Health Probes တို့ပါဝင်ပါသေးတယ်။
Backend Pool
Backend Pool ဆိုတာ Web Server တွေကို collection လုပ်ထားတာပါ။ Backend Pool configuration လုပ်တဲ့အခါ pool ထဲက Server တွေကို Client တွေ request လုပ်လို့ရဖို့အတွက် Web Server တိုင်းမှာ သက်ဆိုင်ရာ IP Address နဲ့ Port တွေရှိရပါမယ်။ Pool ထဲမှာ VM, VM Scale Set, Azure Web App, On-premises Server တွေ ထည့်သွင်းလို့ရပါတယ်။ ပြီးရင်တော့ Pool ထဲက Server တွေရဲ့ Workload တွေကို Balance ဖြစ်စေဖို့အတွက် Azure Load Balancer ဖြင့် associate လုပ်ပေးရပါတယ်။
Web Application Firewall
Web Application Firewall ဆိုတာ Listener က reach မလုပ်ခင် incoming request တွေကို handle လုပ်ဖို့အတွက် အသုံးပြုရတဲ့ optional component တစ်ခုပါ။ WAF က Open Web Application Security Project (OWASP) ပေါ်မှာ အခြေခံပြီး request တစ်ခုစီ တိုင်းမှာပါလာနိုင်တဲ့ common threats တွေကို စစ်ဆေးပါတယ်။ Common threats အချို့ကိုဖော်ပြပေးရမယ်ဆိုရင် SQL injection, Cross Site Scripting (XSS), Http request smuggling, Http response splitting, Remote file inclusion, Bots, Crawlers, Scanners, Http protocol violation နှင့် anomalies တို့ပဲဖြစ်ပါတယ်။
ဒီနေရာမှာ OWASP နှင့်ပတ်သက်ပြီး အနည်းငယ်ရှင်းပြပေးချင်ပါတယ်။
OWASP က attacks တွေနဲ့ ပတ်သက်ပြီး ရှာဖွေဖို့အတွက် ယျေဘုယျအားဖြင့် rule တွေ သတ်မှတ်ထားပါတယ်။ အဲ့ဒီ rule တွေကို Core Rule Set (CRS) လို့ခေါ်ပါတယ်။ Rule တွေ သတ်မှတ်ရတဲ့ အဓိက ရည်ရွယ်ချက်ကတော့ တဖြည်းဖြည်းတိုးတက် ပြောင်းလဲလာတဲ့ attack တွေရဲ့ ရှုပ်ထွေးမှုတွေကို ပြန်လည် သုံးသပ်ဖို့အတွက်ပဲ ဖြစ်ပါတယ်။ WAF မှာ CRS 2.2.9 နှင့် CRS 3.0 ရယ်ဆိုပြီးတော့ rule နှစ်ခုရှိပါတယ်။ CRS 3.0 က default rule ဖြစ်ပြီးတော့ တိကျသောချာတဲ့ attack တွေအတွက် လိုအပ်ခဲ့ရင် rule set တွေထဲက သက်ဆိုင်ရာ rule ကို ရွေးချယ်လို့ရတဲ့အတွက်ကြောင့် တော်တော်လေး အသုံးများပါတယ်။ နောက်ထပ်ဘာတွေ ထပ်ရှိသေးလဲဆိုရင် Firewall တွေကို မိမိစိတ်ကြိုက် customize လုပ်လို့ရတဲ့အပြင် Server တွေ overwhelming ဖြစ်ခြင်းကနေ ကာကွယ်ဖို့အတွက် Upload လုပ်တဲ့ message size တွေကို limit လုပ်နိုင်ပါတယ်။ Application Gateway မှာ WAF ကို အသုံးပြုမယ်ဆိုရင် gateway create လုပ်တဲ့ အခါမှာ သက်ဆိုင်ရာ WAF Tier တွေကို ရွေးပေးဖို့လိုအပ်ပါတယ်။
Health Probes
Health probes က Load-balancing အတွက် Backend Pool ထဲမှာ ဘယ် Server တွေရနိုင်လဲဆိုတာကို ဆုံးဖြတ်ပေးပါတယ်။ Application Gateway က Health Probe ကိုအသုံးပြုပြီး Client Request တွေကို Server တွေဆီပို့ပေးပါတယ်။ အဲ့ဒီအခါ Server တွေဆီကနေပြန်လာမယ် Http response status code တွေက 200 ကနေ 399 ကြားဖြစ်ခဲ့မယ်ဆိုရင် အဲ့ဒီ Server တွေကို Healthy ဖြစ်တယ်လို သတ်မှတ်ပါတယ်။ တကယ်လို့သာ ကျွန်တော်တို့အနေနဲ့ Application Gateway create လုပ်တဲ့အခါမှာ Health Probe ကို configure မလုပ်ခဲ့ဘူးဆိုရင် Default Probe က Backend Pool ထဲက Server တွေ Unavailable ဖြစ်လား မဖြစ်လား မဆုံးဖြတ်ခင် စက္ကန့် ၃၀ စောင့်ပါတယ်။
ကဲ အခုဆိုရင် Application Gateway နဲ့ ပတ်သက်ပြီး တော်တော်များများ သိသွားပြီမို့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါတော့မယ်။
အားလုံးပဲ Stay Safe, Take Care ပါ။
Thant Zin Phyo@Cracky(MCT)
