ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
AWS Shared Responsibility Model က 'security OF the cloud' (data center physical security, hardware — AWS တာဝန်) နဲ့ 'security IN the cloud' (data encryption, access control, patching guest OS — customer တာဝန်) ကို ခွဲခြားထားပါတယ် — customer ဘက်က တာဝန်ကို လျစ်လျူရှုလို့ မရပါဘူး။ Encryption at Rest (data disk ပေါ်မှာ encrypt) နဲ့ Encryption in Transit (data network ကူးရင်း encrypt, HTTPS/TLS) ၂ မျိုးလုံးကို production မှာ enable လုပ်ထားသင့်ပါတယ်။ Security Group (EC2 level, stateful — request ခွင့်ပြုရင် response auto-allow) နဲ့ Network ACL (subnet level, stateless — inbound/outbound ကို သီးခြားစီ ခွင့်ပြုရ) ကို layer ၂ ထပ်ပြီးသုံးရင် defense-in-depth ရရှိပါတယ်.
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
RDS database ကို create တဲ့အခါ 'Enable encryption' checkbox ကို ဖွင့်ထားရင် disk ပေါ်က data ကို encrypt ထားပေးပါတယ် (Encryption at Rest) — application ကနေ database ကို SSL/TLS connection string နဲ့ ချိတ်ဆက်ရင် Encryption in Transit ပါ ရရှိပါတယ်။ Production VPC မှာ Security Group (instance level) ကို tight ချထားပြီး, Network ACL (subnet level) ကို additional layer အနေနဲ့ suspicious IP range ကို block ဖို့ သုံးနိုင်ပါတယ်.
အတူတူ ကြည့်မယ်
AWS Well-Architected Security checklist (summary):
[ ] MFA enabled on root user and all IAM users with console access
[ ] IAM least-privilege policies (no wildcard * unless truly needed)
[ ] Encryption at rest enabled on S3/RDS/EBS
[ ] Encryption in transit (HTTPS/TLS) for all public endpoints
[ ] Security Groups scoped to minimum required ports/IPs
[ ] CloudTrail enabled (audit log of all API calls)
[ ] Billing alerts configuredAWS Shared Responsibility Model နှင့် defense-in-depth (Security Group + NACL) ကို ရှင်းပြနိုင်မည်။၅ မိနစ် စမ်းကြည့်
အထက်က checklist ကို ယခုအထိ create ခဲ့တဲ့ resource (EC2, RDS, S3) အားလုံးအပေါ် run ကြည့်ပါ — Fail ဖြစ်တဲ့ item ကို ရှာထုတ်ပြီး ပြင်ဆင်ကြည့်ပါ။
သတိလေးတစ်ချက်
Security ကို 'နောက်မှ ထည့်မယ်' ဆိုတဲ့ afterthought အနေနဲ့ မဆက်ဆံပါနှင့် — resource create တဲ့ ပထမနေ့ကတည်းက least-privilege, encryption, MFA ကို built-in အနေနဲ့ ထားသင့်ပါတယ်။