Stack 9 ชั้น × 6 รูปแบบ — ใครดูแลชั้นไหน#

ก่อนเจาะรายตัว ขอวาง ภาพรวมทั้ง stack ที่ผู้บริหารต้องจำได้ก่อน. ทุก cloud certification ของโลก (AWS, Azure, GCP, CompTIA Cloud+) ใช้ table นี้ — เพราะมันเป็นภาษากลางที่ทำให้ “ใครดูแลอะไร” ชัดในรูปเดียว

ระบบใดๆ ในโลกประกอบด้วย 9 ชั้น (จากล่างขึ้นบน):

แต่ละ cloud model — ใครดูแลชั้นไหน (แดง = คุณดูแล, เขียว = vendor ดูแล, ฟ้า = แบ่งกัน):

🔴 = คุณ (customer) ดูแลเอง / 🟢 = vendor ดูแลให้ / 🔵 = แบ่งกัน

อ่านอย่างไร — เลื่อนสายตาจากซ้ายไปขวา = จากเช่าน้อยสุด (On-Prem) ไปเช่าเยอะสุด (SaaS) แดงจะค่อยๆ หายไปจากล่างขึ้นบน เห็นได้ชัดว่าเช่ายิ่งสูง vendor ดูแลให้ยิ่งมาก แต่ Data layer แดงตลอด ทุก model

FaaS — Application layer แบ่งกันยังไง? คุณเขียน function logic (business code) — vendor จัดการ scalability + parallelization + capacity planning + error handling + auto-retry ให้ทั้งหมด นี่คือ promise ของ Lambda / Cloudflare Workers

แกนแนวนอนของ table = Configurability ↔ Agility trade-off:

• ซ้ายสุด (On-Prem) — คุมได้ทุกชั้น, แต่ดูแลทุกชั้น
• ขวาสุด (SaaS) — คล่องตัวสุด, แต่คุมได้แค่ data
• ตรงกลาง — เลือกตาม trade-off

กฎทอง: ไม่ว่าจะ model ไหน — Data layer เป็นของคุณเสมอ. cloud vendor ไม่เคยรับผิดต่อข้อมูลที่คุณ upload, สิทธิ์ที่คุณ grant, password ที่คุณตั้ง

มุมผู้บริหาร: คำถามที่ board ควรถาม CIO ทุกระบบสำคัญ — “ระบบนี้อยู่ column ไหนของ table?” ถ้าตอบไม่ได้ทันที = ไม่รู้ว่าใครรับผิดเมื่อมี breach. และ “เราดูแล layer ใดของ stack จริงๆ?” — เพราะแต่ละ layer ที่อยู่ใต้คุณ = budget + headcount + risk ของบริษัทคุณ

ทีนี้มาเจาะแต่ละ model — เริ่มจากซ้ายสุดของ table

IaaS — ซื้อตึกเปล่า#

IaaS (Infrastructure-as-a-Service — โครงสร้างพื้นฐานที่ขายเป็นบริการ) — เหมือนเช่าตึกเปล่า. cloud provider ให้คุณแค่ server เปล่า + network เปล่า + storage เปล่า. คุณต้องเอา OS มาลง. ติดตั้ง database เอง. ติดตั้ง web server เอง. ทำ patching เอง. backup เอง. monitor เอง

ตัวอย่างที่คุณคุ้น — AWS EC2 (เครื่อง virtual server) / AWS S3 (storage เปล่า) / Azure Virtual Machines / Google Compute Engine

ลองนึกภาพ — คุณเช่า EC2 instance หนึ่งตัวบน AWS. AWS ให้คุณ — เครื่อง virtual + network + ระบบ hypervisor ที่รันเครื่อง virtual ของคุณ + data center ที่มีไฟ มีแอร์ มีกล้อง มียาม. AWS ดูแลของ AWS. ส่วนของคุณ — OS, patches, firewall rules บน OS, software ที่ลง, ข้อมูลในเครื่อง, ใครเข้าถึง SSH ได้ — คุณดูแลเอง

ถ้า hacker เข้าเครื่องคุณผ่าน SSH ที่คุณตั้งรหัสง่ายๆ → AWS ไม่รับผิด. นี่คือเรื่องของคุณ

ของ IaaS — ผู้เช่าต้องดูแลเยอะที่สุด. แต่ก็คุมได้ละเอียดที่สุด

PaaS — เช่าออฟฟิศพร้อมเฟอร์#

PaaS (Platform-as-a-Service — แพลตฟอร์มที่ขายเป็นบริการ) — เช่าออฟฟิศพร้อมเฟอร์นิเจอร์. cloud provider ให้คุณ — runtime พร้อมใช้ + database พร้อมใช้ + web server พร้อมใช้. คุณแค่เอา code ของคุณมาวาง — มันจะรันเอง

ตัวอย่าง — AWS Elastic Beanstalk / Heroku / Google App Engine / Azure App Service / AWS RDS (managed database)

คุณไม่ต้องลง OS. ไม่ต้อง patch OS. ไม่ต้อง config web server. ไม่ต้อง config database engine. provider ทำให้หมด. คุณแค่ — code + data + ใครเข้าได้บ้าง

แต่ — code คุณ + ข้อมูลในนั้น + IAM policy + secret ที่ hardcode ไว้ในโค้ด — ยังเป็นเรื่องของคุณ. ถ้าคุณเขียน SQL injection ลงไปในแอป — provider ไม่รับผิด. ถ้า API key ของคุณรั่ว — provider ไม่รับผิด

SaaS — เช่าโต๊ะใน co-working#

SaaS (Software-as-a-Service — ซอฟต์แวร์ที่ขายเป็นบริการ) — เช่าโต๊ะใน co-working. provider ให้คุณ — แอปพร้อมใช้ทั้งตัว. คุณแค่เปิดเบราว์เซอร์ login แล้วใช้

ตัวอย่างที่คุณใช้ทุกวัน — Gmail / Google Workspace / Microsoft 365 / Salesforce / Slack / Workday / Zoom / Notion

provider ดูแล — server, OS, database, application code, network, patching — ทุกอย่าง. คุณแค่ใช้

แต่อ้าวอีกแล้ว — เรื่องของคุณยังเหลือ:

• ใครได้ login เข้าระบบ (identity + access) — เรื่องของคุณ
• ข้อมูลที่คุณ upload เข้าไป — เรื่องของคุณ
• share link ที่คุณ generate (เผลอแชร์เป็น public) — เรื่องของคุณ
• MFA เปิดไว้ไหม — เรื่องของคุณ
• ลูกค้าของคุณที่ใช้บริการ — บริษัทยังรับผิดต่อข้อมูลของลูกค้า — ไม่ใช่ Salesforce ที่รับผิดต่อลูกค้าของคุณ

FaaS — เช่าโต๊ะใช้เป็นชั่วโมง#

FaaS (Function-as-a-Service — ฟังก์ชันที่ขายเป็นบริการ) หรือที่เรียกว่า Serverless — เช่าโต๊ะใช้เป็นชั่วโมง. ไม่ใช้ไม่จ่าย

ตัวอย่าง — AWS Lambda / Google Cloud Functions / Azure Functions / Cloudflare Workers

คุณเขียน function เล็กๆ ทำงานเดียว เช่น “ตอนมีรูปอัพเข้า S3 — ให้ย่อรูปเป็น thumbnail”. provider จะรันให้ — ตอนมีคำขอเท่านั้น. ไม่มีคำขอ — ไม่เสียเงิน

scope ของความรับผิดของคุณ — เล็กลงอีก. แต่ — code ที่คุณเขียน + permission ที่ function นั้นได้รับ + ข้อมูลที่ function ผ่านมือ — ยังเป็นเรื่องของคุณ

Master เคยเขียนไว้ใน IT Foundation EP.04 ว่า — Serverless เหมือน Cloud Kitchen — คุณไม่มีร้าน ไม่มีเตา ไม่มีพนักงาน. แต่ตอนมี order — ครัวก็ลุกขึ้นทำให้. ทำเสร็จ — ปิดไฟ. ไม่มีค่าใช้จ่ายตอนไม่มีลูกค้า. FaaS คือ Cloud Kitchen ในมุม security

CaaS — ตู้คอนเทนเนอร์พร้อมโกดัง#

CaaS (Container-as-a-Service — คอนเทนเนอร์ที่ขายเป็นบริการ) — เป็นตัวกลางระหว่าง IaaS กับ PaaS. provider ให้คุณ — คลังเก็บตู้คอนเทนเนอร์ + ระบบเอาตู้เข้าออก. คุณ build container ของคุณเอง — แล้วเอามาใส่

ตัวอย่าง — AWS ECS / Fargate / Google Kubernetes Engine (GKE) / Azure Kubernetes Service (AKS) / AWS EKS

เรื่อง container เจาะลึกอีก EP เดียวครับ — EP.33 — Container + Kubernetes Security. EP นี้รู้แค่ว่ามันคืออะไรพอ

มุมผู้บริหาร: บริษัทไทยจำนวนมากตัดสินใจ “ขึ้น cloud” แบบเหมาโหล — ทั้งบริษัทย้ายขึ้น AWS หรือใช้ Microsoft 365 ทั้งหมด. ที่จริง — ระบบต่างประเภทเหมาะกับการเช่าต่างแบบ. ผู้บริหารที่ฉลาดในยุคนี้ไม่ถามว่า “ขึ้น cloud หรือไม่” — ถามว่า “ระบบไหนควรเช่าแบบไหน (IaaS / PaaS / SaaS / FaaS)?”

Public cloud — คอนโดที่มีผู้เช่าหลายร้อยห้อง#

Public cloud — เช่ากับ provider ใหญ่ ที่มีลูกค้าเป็นล้านราย. AWS / Microsoft Azure / Google Cloud Platform (GCP) — 3 รายใหญ่ของโลก. Alibaba Cloud ครองตลาดจีน. Oracle Cloud ครองตลาดที่มี Oracle DB เดิม

ภาพในใจ — คอนโดสูง 100 ชั้น ที่มีผู้เช่าเป็นล้านราย. ทุกห้องอยู่ในตึกเดียวกัน — แต่มีกำแพง + ประตูแยก. ผู้เช่าห้องข้างๆ คุณอาจเป็น บริษัทคู่แข่ง ก็ได้ — แต่เข้าห้องคุณไม่ได้

ข้อดี — ถูก (scale ใหญ่). ของพร้อมทันที. ของใหม่ๆ มาเร็ว ข้อเสีย — ของหลายอย่างถูกออกแบบ generic — ไม่ตรงกับ business เฉพาะของคุณ

Private cloud — บ้านพักหลังเดียวของบริษัท#

Private cloud — สร้าง cloud ของบริษัทเอง — แต่ใช้ technology แบบ cloud (virtualization + self-service + auto-scale). VMware vSphere + OpenStack เป็น stack ที่บริษัทใหญ่ใช้

ภาพในใจ — บ้านพักหลังเดียว ที่มีแต่ครอบครัวคุณอยู่. แพง. แต่คุมได้ละเอียดและเป็นส่วนตัวที่สุด

ใครใช้ — ธนาคาร, ราชการ, บริษัท defense — ที่มีข้อบังคับว่า data ห้ามออกนอกประเทศ / นอก data center ของตัวเอง

Community cloud — คอนโดของชมรม#

Community cloud = cloud ที่ใช้ร่วมกันใน กลุ่มที่มี concern เดียวกัน เช่น security, compliance, jurisdiction, sector

ภาพในใจ — คอนโดที่หลายบริษัทเป็นเจ้าของร่วมกัน เหมือนนิติบุคคลคอนโด ผู้เช่าทุกห้องอยู่ในวงการเดียวกัน (เช่นโรงพยาบาลทั้งกลุ่ม / ธนาคารทั้งกลุ่ม / หน่วยงานราชการทั้งกลุ่ม) ใช้ infrastructure ร่วมกัน แต่ คนนอกวงการเข้าไม่ได้

ตัวอย่างที่เจอจริง:

• AWS GovCloud — แยกออกจาก commercial AWS โดยสิ้นเชิง. ใช้ได้เฉพาะ US government agencies + contractors ที่ผ่านการตรวจสอบ
• Healthcare community cloud — โรงพยาบาลกลุ่มหนึ่งสร้าง cloud ร่วมกัน เพื่อ comply HIPAA — แชร์ infra + ค่าใช้จ่าย + audit ร่วมกัน
• Banking cloud สำหรับธนาคารกลุ่มหนึ่ง — comply PCI DSS ร่วมกัน
• EU Sovereign Cloud / Gaia-X — EU member states ร่วมกันสร้าง cloud federation ของ EU

Use case ที่เหมาะ:

• Regulatory compliance ร่วมกัน — แต่ละบริษัทเล็กเกินกว่าจะ comply เองทั้งหมด แต่รวมกัน — ทำได้
• Cost sharing — ของแพงในวงการ (HSM, dedicated network, third-party audit) — แบ่งจ่ายกัน
• Sector-specific control — มี governance framework ที่กลุ่มออกแบบเอง

เทียบกับ Private — Community share กับคนอื่นในวงการ (ไม่ใช่ single-tenant) → ถูกกว่า private เทียบกับ Public — Community limited เฉพาะวงการ → คุมได้มากกว่า public

ในมุม IS auditor — สิ่งที่ต้องตรวจในระดับ community cloud:

• Community governance — ใครตัดสินใจเรื่องนโยบาย? บริษัทไหนมีสิทธิ์ override?
• Access control ระหว่างสมาชิก — บริษัท A เข้าข้อมูลของบริษัท B ได้ไหม (ไม่ควรได้!)
• SLA terms — ตอนสมาชิกขัดแย้งกัน — ตัดสินยังไง
• Exit clause — ถ้าบริษัทใดอยากออกจาก community — ย้ายข้อมูลออกได้อย่างไร

มุมผู้บริหาร: Community cloud เป็นทางเลือกที่บริษัทไทยขนาดกลางในวงการเดียวกัน (โรงพยาบาล, สหกรณ์ออมทรัพย์, สมาคมธุรกิจ) น่าจะใช้มากกว่าที่ใช้กันจริงในปัจจุบัน ถ้า 10 โรงพยาบาลขนาดกลางรวมกัน อาจ comply HIPAA-equivalent ได้ที่ต้นทุน 1/10 ของแต่ละแห่งทำเอง แต่ต้องมี governance ที่ชัด ก่อนเริ่มครับ คนที่กลัวที่สุดคือ “ถ้าคู่แข่งในวงการเข้าถึงข้อมูลของเราได้?” คำตอบอยู่ที่ technical isolation + audit trail ที่ทุกฝ่ายเห็นได้

Hybrid cloud — บ้านหลัก + คอนโดสำรอง#

Hybrid cloud — บริษัทมีทั้ง private cloud (หรือ on-premise) + public cloud — แล้วเชื่อมโยงกัน

ภาพในใจ — บริษัทมี data center หลัก ที่กรุงเทพ — เก็บข้อมูลลับ + ระบบ core. มี AWS สำหรับเว็บไซต์ + mobile app + analytics. 2 ที่ — เชื่อมกันด้วย VPN หรือ AWS Direct Connect (สาย dedicated)

ข้อดี — เลือกถูกใจ. ข้อมูลลับเก็บในบ้าน. โหลดเยอะใช้ public scale. ข้อเสีย — เส้นแบ่งความรับผิดยุ่ง + ต้องบริหาร 2 ฝั่ง

Multi-cloud — เช่ากับหลายเจ้า#

Multi-cloud — บริษัทใช้ provider หลายเจ้า เช่น AWS + Azure + GCP พร้อมกัน

ทำไมใช้ — (1) ลด vendor lock-in. (2) ใช้ของถูกใจของแต่ละเจ้า — เช่น GCP เก่ง AI/ML, Azure เก่ง enterprise + AD integration, AWS เก่งของครบและของเยอะ. (3) Resilience — ถ้า AWS ล่ม ยังมี Azure

ที่หนัก — Shared Responsibility ของแต่ละเจ้าไม่เหมือนกัน. นโยบาย IAM ของ AWS ≠ Azure ≠ GCP. team ต้องเรียนรู้ 3 ระบบ. ความเสี่ยงด้าน complexity เพิ่มเยอะ

Sovereign cloud — คอนโดในเขตอธิปไตย#

Sovereign cloud (อธิปไตยทางข้อมูล) — concept ที่ใหม่ในรอบ 5 ปี. cloud ที่ อยู่ภายใต้กฎหมายของประเทศใดประเทศหนึ่งโดยเฉพาะ — ข้อมูลห้ามออกนอกประเทศ + รัฐบาลต่างประเทศบังคับ provider เปิดข้อมูลไม่ได้

ตัวอย่าง — EU Sovereign Cloud ของ Microsoft / Bleu (Microsoft + Capgemini + Orange) สำหรับฝรั่งเศส / AWS European Sovereign Cloud. ในไทย — NDID + GDCC (Government Data Center & Cloud) ของภาครัฐ + NT Cloud ของ National Telecom

ทำไมเรื่องนี้ระเบิดในปี 2024-2026 — เพราะ กฎหมาย US CLOUD Act ทำให้รัฐบาลอเมริกาขอข้อมูลจาก US provider ได้ — แม้ข้อมูลอยู่ใน data center นอกประเทศ. EU + ASEAN เลยเริ่มสร้าง alternative ของตัวเอง

มุมผู้บริหาร: ผู้บริหารบริษัทไทยที่ดูแลข้อมูลส่วนบุคคล / healthcare / การเงิน — ต้องเริ่มถามคำถามนี้แล้ว — “ถ้ารัฐบาลต่างประเทศบังคับให้ AWS / Azure / GCP เปิดข้อมูลของลูกค้าไทย — เกิดอะไรขึ้นกับบริษัทเราตามกฎหมายไทย?” คำตอบไม่ง่าย. ปี 2026-2030 ภาครัฐไทยมีแนวโน้มออกข้อบังคับ data residency เข้มขึ้น — เริ่มคิด architecture ที่ย้ายได้ตั้งแต่วันนี้

สรุป 6 deployment models เทียบกัน#

ทิศทาง 1 — On-prem → Cloud (most common)#

ทิศทางที่เจอบ่อยที่สุด — ย้ายจาก data center ของตัวเอง ขึ้น public cloud. มี 3 strategy ย่อย:

• Lift-and-shift — ยกระบบเดิมขึ้นตรงๆ. ทำเร็วสุด แต่ไม่ได้ประโยชน์ cloud-native (ยังจ่ายแบบ on-prem)
• Refactor — ปรับ code บางส่วน — เปลี่ยน database เป็น managed service, เปลี่ยน server เป็น container
• Rebuild — เขียนใหม่แบบ cloud-native ตั้งแต่ต้น. ได้ประโยชน์สูงสุด แต่ใช้เวลาและทรัพยากรเยอะ

ทิศทาง 2 — Cloud → Cloud (vendor migration)#

ย้ายจาก cloud หนึ่งไปอีก cloud — AWS → Azure, Azure → GCP, GCP → AWS. เกิดบ่อยขึ้นในปี 2024-2026 เพราะ:

• Multi-cloud strategy — บางส่วนย้ายเพื่อกระจาย risk
• เปลี่ยน vendor — สัญญาเดิมหมด + cloud อื่นเสนอ deal ดีกว่า
• Acquisition — บริษัทใหญ่ที่ใช้ AWS ซื้อบริษัทเล็กที่ใช้ Azure — ต้อง consolidate

ปัญหาที่เจอ — vendor lock-in ที่ลึกกว่าที่คิด. ของที่ดูเหมือนมาตรฐาน (database, message queue, identity) — แต่ละ vendor มี API ที่ไม่เข้ากัน. การย้ายจริง — มักใช้เวลา 12-24 เดือน + budget เกิน estimate 2-3 เท่า

ทิศทาง 3 — Cloud → On-prem (Repatriation)#

ทิศทางที่ ผู้บริหารไทยไม่ค่อยพูดถึง แต่ระดับโลกเริ่มเห็นบ่อยขึ้นเรื่อยๆ คือ ย้ายจาก cloud กลับมา on-prem

drivers ที่ผลักให้ repatriate:

• Cost overrun — bill cloud โตจนเกินงบ. โดยเฉพาะ workload ที่ predictable + ใช้ resource สม่ำเสมอ (ไม่ใช่ spike)
• Data sovereignty — กฎหมายใหม่บังคับให้ข้อมูลอยู่ในประเทศ
• Performance — latency-sensitive workload ที่ cloud network ทำได้ไม่ดีพอ
• Vendor lock-in concern — ไม่อยากผูกธุรกิจไว้กับ provider เดียวระยะยาว

เคสจริงระดับโลก:

• Dropbox 2017 — ย้าย storage workload จาก AWS กลับมา data center ของตัวเอง. ประหยัด 75 ล้านเหรียญ ใน 2 ปี. แต่ต้องสร้างทีม infrastructure ใหม่
• 37signals / Basecamp 2023 — ย้ายระบบ Basecamp + HEY กลับจาก cloud มา on-prem. CEO ออกมาเขียน blog ว่า cloud bill ไม่สมเหตุสมผลกับ workload ของบริษัท

challenge ของการ repatriate:

• Skill gap — ทีม cloud-native หลายปี — ลืมวิธีดูแล hardware แล้ว
• Capex investment — ต้องลงทุน server + data center ใหม่ — กลับมาเป็น balance sheet item
• Refactor cloud-only services — Lambda, DynamoDB, SQS — ไม่มี on-prem equivalent ตรงตัว ต้องเขียนใหม่

มุมผู้บริหาร: อย่าออกแบบ architecture แบบ “เข้า cloud แล้วเข้าตลอดไป” ออกแบบให้ ย้ายได้ทั้ง 3 ทิศทาง ใช้ open standards (Kubernetes แทน proprietary container service, PostgreSQL แทน DynamoDB ถ้าทำได้) ค่า “exit option” นี้ดูเหมือนแพงตอนต้น แต่ในวันที่ provider ขึ้นราคา 30% หรือกฎหมายเปลี่ยน มันคือ leverage ในการเจรจา ครับ

Security OF the cloud vs Security IN the cloud#

AWS เขียนเอาไว้ตรงๆ ใน documentation ของตัวเอง — สั้นๆ แต่ทรงพลัง:

• AWS รับผิดชอบ “Security OF the cloud” — ความปลอดภัยของ ตัว cloud เอง (data center, hypervisor, hardware, network ภายใน, physical security)
• Customer รับผิดชอบ “Security IN the cloud” — ความปลอดภัย ของสิ่งที่ลูกค้าเอาขึ้นไปบน cloud (OS, applications, data, configurations, IAM, network traffic)

ภาพในใจง่ายที่สุด — เจ้าของคอนโดดูแลตึก. ผู้เช่าดูแลของในห้องตัวเอง

ถ้าตึกถล่มเพราะโครงสร้าง — เจ้าของคอนโดผิด. ถ้ามีโจรเข้าห้องเพราะคุณลืมล็อกประตู — คุณผิด. ถ้ามีน้ำท่วมเพราะท่อรั่วในห้องคุณ — คุณซ่อม. ถ้าลิฟต์เสีย — เจ้าของซ่อม

ฟังดูเข้าใจง่ายใช่ไหมครับ? แต่พอแปลงเป็น cloud — คนงง

ตารางความรับผิดในแต่ละ service model#

ลองนึกตารางในใจ — แถวคือ layer ของระบบ (จากล่างขึ้นบน) — เสาคือ service model:

สังเกตให้ดีครับ — 3 แถวล่างสุด — Data / Identity / Configuration — ลูกค้ารับผิดทุก model เสมอ. ทุกแบบเช่า — ทุก cloud — ทุก provider

• Data = ข้อมูลที่คุณ upload ขึ้นไป — provider จะรู้ได้ยังไงว่าควรเก็บอะไร ไม่เก็บอะไร, ใครเข้าถึงได้บ้าง, ลบเมื่อไหร่
• Identity = ใครได้ login เข้า account ของคุณ — provider จะรู้ได้ยังไงว่าใครคือพนักงานของคุณ ใครเป็น admin
• Configuration = ตั้งค่ายังไง — เปิด public ไหม, encrypt ไหม, logging เปิดไหม

3 อย่างนี้ — ไม่มีทาง outsource ให้ใครได้. ใครก็ตามที่บอกว่า “ใช้ cloud = ปลอดภัย” — เขายังไม่เคยอ่านตารางนี้

ทำไมบริษัทไทยอ่านผิด#

pattern คลาสสิคของวงการที่เจอบ่อยที่สุด:

(1) “เราใช้ AWS แล้ว = secure” — ผิด. AWS secure เฉพาะส่วนของ AWS. ส่วนของคุณ — คุณยังต้องดูแลเอง

(2) “AWS มี SOC 2 / ISO 27001 — เราเลย compliant ด้วย” — ผิด. ความ compliant ของ AWS = infrastructure compliant. application + data + config ของคุณ — ต้อง audit แยกต่างหาก

(3) “ใช้ S3 ก็ encrypt อยู่แล้ว” — ผิดครึ่ง. S3 encrypt at rest (โดย default ในปัจจุบัน) — แต่ถ้าคุณตั้ง bucket policy เป็น public — ใครก็ดาวน์โหลดได้ (encrypt หรือไม่ encrypt ไม่ช่วย)

(4) “RDS managed = ปลอดภัย” — ผิด. RDS ดูแล OS + database engine ให้. แต่ — schema ที่ vulnerable ต่อ SQL injection, password ของ database ที่ hardcode ในแอป, security group ที่เปิด 0.0.0.0/0 — ทั้งหมดคุณรับผิดเอง

(5) “ใช้ SaaS หมดแล้ว — ไม่ต้องมีทีม security” — ผิดมหันต์. SaaS เปลี่ยน profile ความเสี่ยง — ไม่ได้ลบ. ความเสี่ยงเปลี่ยนจาก “patching” เป็น “identity + configuration + integration”. เลิกมี EDR ใน server แต่ต้องมี CASB + SSPM มาแทน

มุมผู้บริหาร — Shared Responsibility ที่ผู้บริหารต้องทำให้เป็น routine

ในที่ประชุมบริหารทุกไตรมาส — ควรมีคำถามมาตรฐาน 3 ข้อสำหรับทุกระบบ cloud ที่ใช้: (1) “ระบบ X ใช้ cloud ของใคร — IaaS / PaaS / SaaS?” (2) “เส้นแบ่งความรับผิดเขียนเป็นเอกสารและทบทวนล่าสุดเมื่อไหร่?” (3) “team ไหนของบริษัทเป็นเจ้าของส่วนที่เรารับผิดชอบ — และ team นั้นมีคนพอไหม?” — ถ้าตอบไม่ได้ทั้ง 3 ข้อ — แปลว่ามีระบบที่ไม่มีใครดูแลในส่วนที่เป็นความรับผิดของบริษัท. และ ความเงียบนี้ — จะระเบิดในเวลาที่ไม่คาดคิด

Misconfiguration — ความเสี่ยง #1 ของ cloud#

รายงานของวงการ — Verizon DBIR 2024 + IBM Cost of a Data Breach 2024 + ENISA Threat Landscape — ตรงกันว่า Misconfiguration = สาเหตุ #1 ของ cloud breach. แซง phishing ในบาง category แล้ว

Misconfiguration = ตั้งค่าผิด — เผลอเปิด public, ตั้ง permission กว้างเกิน, ลืม encrypt, ลืมเปิด logging

ทำไมเรื่องนี้หนักใน cloud — เพราะ cloud มี config นับพันตัว และเปลี่ยนได้ผ่าน API หรือ console ในวินาทีเดียว. ใน on-premise — กว่าจะตั้งค่า server ผิดให้เห็นจาก internet — ต้องเดินผ่านหลายชั้น (firewall + NAT + router). ใน cloud — คลิกเดียวเปลี่ยน private bucket เป็น public ได้ — ใน 5 วินาที

S3 Public Buckets — ห้องเก็บของที่ลืมล็อก#

S3 (Amazon Simple Storage Service — ระบบเก็บไฟล์ของ AWS) = ตู้เก็บไฟล์ขนาดยักษ์ของ AWS. บริษัทใช้เก็บทุกอย่าง — backup, log, รูปภาพ, vdo, customer data, source code

ถ้าคุณตั้ง bucket policy = public — ใครก็ดาวน์โหลดได้ผ่าน URL ตรงๆ. ไม่ต้อง login. ไม่ต้องมี IAM key

เคสจริงที่กลายเป็นข่าวระดับโลก:

Verizon S3 leak 2017 — partner ของ Verizon (NICE Systems) ตั้ง S3 bucket เป็น public. ข้อมูลลูกค้า 6 ล้านราย — เบอร์โทร, รหัส PIN ของบัญชี — รั่วออกมาทั้งหมด. ใครก็ดาวน์โหลดได้

Accenture S3 leak 2017 — บริษัทที่ปรึกษาระดับโลก. ตั้ง S3 buckets 4 ตัวเป็น public โดยไม่ตั้งใจ. 137 GB ของ enterprise data รั่ว — รวมถึง credential ที่เข้าระบบของลูกค้าระดับ Fortune 500 ได้

ในเคสทั้งหมด — ไม่มี hacker เก่งๆ. ไม่มี zero-day. ไม่มี APT. แค่ — คนตั้งค่าผิด + ไม่มีใคร audit

Over-permissive IAM — กุญแจที่ให้กว้างเกินไป#

IAM (Identity and Access Management) ของ cloud — มี granularity ละเอียดมาก. ตั้งได้ว่า user คนนี้ทำอะไรได้บ้าง — กับ resource ไหน — ใน region ไหน — ตอนไหน

ปัญหาคลาสสิค — team ใหม่ๆ ไม่อยากตั้งให้ละเอียด เลยให้ * (ทุกอย่าง):

1
{
2
  "Effect": "Allow",
3
  "Action": "*",
4
  "Resource": "*"
5
}

แปลว่า — user นี้ทำได้ทุกอย่างกับทุก resource. ถ้า credential ของ user คนนี้รั่ว — hacker เป็นเจ้าของ AWS account ของคุณทันที

หลักการที่ถูกคือ Least Privilege (ให้สิทธิ์น้อยที่สุดที่ทำงานได้) — แต่บริษัทไทยส่วนใหญ่ไม่ทำ. เพราะตั้งยาก + ทำให้ developer ทำงานช้า

SSRF — Server-Side Request Forgery#

SSRF (Server-Side Request Forgery — การปลอมคำขอที่ฝั่ง server) — ช่องโหว่ที่ทำให้ hacker สั่ง server ของคุณ ให้ส่ง request ไปที่ URL ที่ hacker เลือก

ทำไมเรื่องนี้หนักใน cloud — เพราะ cloud มี metadata service ที่ทุก EC2 instance access ได้ผ่าน URL พิเศษ — http://169.254.169.254. URL นี้คืน credential ของ role ที่ instance นั้นมี

ถ้า web app บน EC2 มีช่องโหว่ SSRF → hacker สั่ง app ให้ดึง http://169.254.169.254/latest/meta-data/iam/security-credentials/ → ได้ credential ของ role → ใช้ credential นั้น access AWS resources ทั้งหมดที่ role นั้นมีสิทธิ์

IMDSv1 vs IMDSv2 — ทำไมเรื่องนี้สำคัญ#

IMDS (Instance Metadata Service) มี 2 version:

• IMDSv1 — เก่า. ขอ metadata ได้ผ่าน HTTP GET ธรรมดา. vulnerable ต่อ SSRF
• IMDSv2 — ใหม่. ต้อง — (1) ส่ง PUT request เพื่อขอ token ก่อน — (2) ใช้ token แนบในทุก GET. ป้องกัน SSRF ได้ เพราะ web app ทั่วไปทำ PUT ไม่ได้ผ่านช่องโหว่ SSRF

AWS แนะนำให้ disable IMDSv1 ตั้งแต่ปี 2020 — แต่ปี 2026 ก็ยังมีบริษัทที่ยังไม่เปลี่ยน เพราะ legacy code

เคสคลาสสิค — Capital One 2019#

ทีนี้รวมทุกอย่างที่ผ่านมาในเคสเดียว — Capital One Breach 2019. เคสที่กลายเป็น textbook example ของ cloud breach

ลำดับเรื่อง:

(1) Capital One เป็นธนาคารใหญ่ของอเมริกา. ใช้ AWS หนัก (2) มี WAF (Web Application Firewall) ตัวหนึ่ง — mis-configured. ทำให้ web app มีช่องโหว่ SSRF (3) อดีตพนักงาน AWS ชื่อ Paige Thompson — รู้ว่ามีช่องโหว่นี้ (4) เธอใช้ช่องโหว่ SSRF — สั่ง server ของ Capital One ให้ดึง credential จาก IMDSv1 (ที่ Capital One ยังเปิดอยู่) (5) Credential ที่ได้ — เป็นของ role ที่ over-permissive — มีสิทธิ์อ่าน S3 bucket ทุกตัว (6) เธอใช้ credential นั้น — ดาวน์โหลด S3 buckets ที่มีข้อมูลลูกค้า 106 ล้านราย (7) Capital One ไม่รู้ — จนกว่า Paige โพสต์บน GitHub ในเดือนกรกฎาคม 2019. มีคนเห็นและแจ้ง Capital One. Capital One แจ้ง FBI

ค่าปรับ + ค่าเสียหาย — 80 ล้านเหรียญ จาก OCC (US bank regulator) + 190 ล้านเหรียญ จาก class action settlement. รวม 270+ ล้านเหรียญ

เคสนี้รวม 4 cloud-specific risks ในเคสเดียว — Misconfiguration (WAF) + SSRF (web app) + IMDSv1 (legacy) + Over-permissive IAM (role). ทุก risk — ป้องกันได้ — ถ้ามี CSPM + CIEM + WAF tuning + IAM review ที่ทำเป็น routine

Code Spaces 2014 — บริษัทที่ตายใน 12 ชั่วโมง#

อีกเคสที่หนักไม่แพ้กัน — แต่ในมุมที่ต่างกัน — Code Spaces 2014

Code Spaces เป็น startup ที่ทำ code hosting + project management บน AWS. มีลูกค้าหลายพันราย

ลำดับ:

(1) Hacker ขโมย credential ของ AWS root account (วิธีไม่ชัดเจน — น่าจะเป็น phishing) (2) Hacker login เข้า AWS console (3) Hacker เรียกค่าไถ่ — โอนเงินมา ไม่อย่างนั้นจะลบทุกอย่าง (4) Code Spaces ปฏิเสธ — และพยายามเข้า account เพื่อกู้ (5) Hacker เห็นว่า Code Spaces พยายามต่อต้าน — เลย ลบทุกอย่างใน AWS account — EC2 instances, EBS volumes, S3 buckets, snapshots, AMIs — ทุกอย่าง (6) Code Spaces — ไม่มี backup ออกนอก AWS — ตายภายใน 12 ชั่วโมง

บทเรียน — (1) MFA สำหรับ root account = mandatory. (2) 3-2-1 backup rule ใช้กับ cloud ด้วย — backup ต้องอยู่นอก provider ที่เก็บข้อมูลหลัก. (3) AWS account = single point of failure — บริษัทขึ้นกับมัน 100%

มุมผู้บริหาร: Capital One ใหญ่กว่าบริษัทไทยส่วนใหญ่ — ยังโดน. Code Spaces เล็กกว่าบริษัทไทยหลายเจ้า — ก็โดน. ขนาดบริษัทไม่ช่วยอะไรกับเรื่อง cloud security — สิ่งที่ช่วยคือ routine. คำถามที่ผู้บริหารควรถามทุกเดือน — “เรามี backup ที่อยู่นอก cloud provider หลักของเราไหม?” ตอบไม่ได้ = อยู่ห่างจากความเสี่ยงระดับ Code Spaces (บริษัทที่หายไปใน 12 ชั่วโมง) แค่ก้าวเดียว

CSA Top Threats — 9 risks ที่ทุก cloud audit ต้องเช็ก#

ที่ผ่านมาเราดูเคสจริง 2-3 เคส. แต่วงการมี taxonomy กลางที่ทำให้คุยกันได้ — Cloud Security Alliance (CSA) Top Threats. ทุก IS auditor + cloud architect ใช้ list นี้เป็น checklist

ที่น่าสนใจของ list นี้ — 6 ใน 9 risks (1, 3, 4, 5, 7, 8) — เกิดจากฝั่งลูกค้า ไม่ใช่ provider. ตรงกับสิ่งที่เราคุยตั้งแต่ต้น EP — ความรับผิด — แบ่ง — ไม่ได้โอน

มุมผู้บริหาร: ถ้าจะตั้ง cloud audit program ของบริษัท — เริ่มจาก list นี้. ทุกไตรมาส — เช็กว่าระบบหลักของบริษัทอยู่ในสถานะอย่างไรกับ 9 risks นี้. ระบบไหนตอบไม่ได้ครบทั้ง 9 ข้อ = ระบบที่ยังไม่มีคนเป็นเจ้าของ cloud risk

SLA negotiation — ของที่ต้องเขียนใน contract ก่อนเซ็น#

อีกเรื่องที่ผู้บริหารไทยเซ็น cloud contract แบบไม่อ่าน — SLA (Service Level Agreement). ในมุมลูกค้า — SLA = สัญญา. ของที่ไม่ได้เขียนใน SLA = ไม่มีสิทธิ์เรียกร้อง

ก่อนเซ็น SLA — checklist ที่ต้องอ่าน + ต่อรอง:

• Uptime guarantee — 99.9% ≠ 99.99%. ดูตัวเลขจริง:
  • 99.9% = downtime ~43 นาที / เดือน
  • 99.99% = downtime ~4.3 นาที / เดือน
  • 99.999% = downtime ~26 วินาที / เดือน
  • ระบบที่ทำเงินทุกนาที (e-commerce, trading) — 99.9% ไม่พอ
• Downtime credit / penalty — เมื่อ provider ไม่ถึง SLA — ได้คืนเท่าไหร่? มาตรฐานวงการ ~10% credit ต่อ 1% ที่พลาด
• Maintenance window — pre-announced (รู้ล่วงหน้า) vs unscheduled (ไม่นับเป็น downtime). ต่อรองให้ pre-announced ไม่นับเป็น downtime เฉพาะถ้าแจ้งล่วงหน้า 72 ชม.
• Performance SLO — ไม่ใช่แค่ uptime — แต่ API response time, throughput, error rate. uptime 99.9% แต่ API ตอบช้า 30 วินาที = ใช้ไม่ได้
• Data sovereignty — region ที่ data อยู่, replication ไปที่ไหนได้บ้าง, ห้าม replicate ออกประเทศไหม
• Right to audit — ขอ SOC 2 report, ISO 27001 cert, หรือ independent audit ได้ไหม. provider ใหญ่มักให้แค่ report — ไม่ให้ on-site audit
• Exit clause — ของสำคัญที่สุดในมุมผู้บริหาร:
  • Data export format — ได้ข้อมูลคืนในรูปแบบที่ใช้ต่อได้ไหม (ไม่ใช่ proprietary format)
  • Transition assistance — provider ช่วย migrate ไปที่อื่นนานเท่าไหร่
  • Data escrow — มี third-party เก็บสำเนาไหม กรณี provider เจ๊ง
• Liability cap — ปกติ cap ที่ 12 เดือนของค่าบริการ. ถ้าเป็นระบบ critical — ต่อรองให้สูงขึ้น
• Incident notification — provider ต้องแจ้งภายในกี่ชั่วโมงหลัง detect breach. มาตรฐานวงการ ~72 ชม. — แต่กฎหมาย PDPA / GDPR บังคับลูกค้าแจ้ง regulator ภายใน 72 ชม. — ถ้า provider แจ้งช้ากว่านี้ ลูกค้าผิดกฎหมาย
• Subprocessor disclosure — provider ต้องเปิดเผยรายชื่อ third party ที่จ้างต่อ (sub-cloud, CDN, SMS gateway, email service). ถ้า provider เปลี่ยน sub — ต้องแจ้งล่วงหน้า

มุมผู้บริหาร: ก่อนเซ็น cloud contract — เอา legal + IT + compliance มานั่งโต๊ะเดียวกัน อ่าน SLA ด้วยกัน. ถ้าใน 10 ข้อข้างบน มีอะไรที่ตอบไม่ได้ — อย่าเพิ่งเซ็น. provider ใหญ่มักไม่ยอมแก้ template — แต่บริษัทขนาดที่บอกเขาว่า “เราพร้อมเดินออก” — ได้แก้บางข้อเสมอ. โดยเฉพาะ exit clause + incident notification — 2 ข้อที่ต่อรองได้แน่นอน

CSPM — Cloud Security Posture Management#

CSPM = ตรวจ configuration ของ cloud ทั้งหมด — บอกว่ามีอะไร mis-configured

ภาพในใจ — ผู้ตรวจการ ที่เดินรอบคอนโด — ดูว่าผู้เช่าทุกห้องล็อกประตูไหม, เปิดหน้าต่างทิ้งไว้ไหม, มีน้ำท่วมใต้อ่างไหม. ถ้าเจอ — รายงาน

ตัวอย่าง — Wiz / Prisma Cloud / Lacework / Microsoft Defender for Cloud / AWS Security Hub

CIEM — Cloud Infrastructure Entitlement Management#

CIEM = ตรวจ IAM ของ cloud — ใครมีสิทธิ์อะไร — สิทธิ์ไหนไม่ได้ใช้

ภาพในใจ — ผู้ตรวจการกุญแจ ที่ดูว่าใครถือกุญแจอะไรบ้าง — และกุญแจไหนที่ผู้เช่าไม่ได้ใช้มา 6 เดือนแล้ว — ควรเก็บคืน

ตัวอย่าง — Wiz / Sonrai / Ermetic (โดน Tenable ซื้อ) / Microsoft Entra Permissions Management

CWPP — Cloud Workload Protection Platform#

CWPP = ปกป้อง workload ของ cloud — EC2 instance, container, function — ขณะรัน

ภาพในใจ — EDR แบบ cloud-native — ตรวจสิ่งผิดปกติในเครื่อง / container / function ขณะทำงาน

ตัวอย่าง — Wiz / Aqua Security / Sysdig / CrowdStrike Falcon for Cloud

CNAPP — Cloud-Native Application Protection Platform#

CNAPP = รวม CSPM + CIEM + CWPP ไว้ใน platform เดียว. concept ที่เกิดขึ้นปี 2021 จาก Gartner

ภาพในใจ — ระบบรักษาความปลอดภัยแบบ all-in-one สำหรับ cloud — รวม config audit + IAM audit + runtime protection + container scanning

ตัวอย่าง — Wiz / Prisma Cloud (Palo Alto) / Lacework / Microsoft Defender for Cloud / CrowdStrike Falcon Cloud Security

CASB / SSPM — สำหรับ SaaS#

อ้าว — ยังไม่จบ. ของพวกบนเป็นของ IaaS / PaaS เป็นหลัก. SaaS มีของแยก:

• CASB (Cloud Access Security Broker) = ยามที่ยืนระหว่างพนักงานกับ SaaS app — ดูว่าใครใช้ SaaS ตัวไหน, upload ข้อมูลอะไรบ้าง. ใช้คุมเรื่อง Shadow IT (พนักงานใช้ SaaS ที่บริษัทไม่อนุญาต)
• SSPM (SaaS Security Posture Management) = CSPM แต่ของ SaaS — ตรวจ config ของ Salesforce / Microsoft 365 / Slack / GitHub ว่ามี share link เป็น public ไหม, MFA เปิดทุก user ไหม

สรุปอย่างง่าย#

ที่บริษัทไทยควรรู้ — vendor ไหนๆ ก็จะเรียกของตัวเองเป็น CNAPP ในปี 2026. คำว่า CNAPP ตอนนี้กลายเป็น marketing term มากกว่า technical category. เวลาเลือก vendor — ดู feature ที่ครอบคลุมจริง — ไม่ใช่คำย่อ

มุมผู้บริหาร: บริษัทไทยขนาดกลางหรือเล็ก — อย่าเพิ่งซื้อ CNAPP ราคาแพง. เริ่มจากของฟรี/built-in ของ provider ก่อน — AWS Security Hub + IAM Access Analyzer / Azure Defender for Cloud free tier / GCP Security Command Center. ของพวกนี้ครอบคลุมความเสี่ยง 80% ของบริษัททั่วไป. ค่อยเพิ่ม commercial CNAPP เมื่อ environment ซับซ้อนขึ้น (multi-cloud, > 1,000 resources)

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — “ใช้ AWS / Azure / GCP = ปลอดภัย” คือคำที่อันตรายที่สุดในห้องประชุมบริหารในปี 2026. Provider ปลอดภัยในส่วนของ provider. ส่วนของบริษัทคุณ — ยังเป็นของคุณ. ในทุกการประชุม cloud strategy — เอกสาร Shared Responsibility Matrix ของระบบนั้น ต้องอยู่บนโต๊ะ. ระบบไหนไม่มีเอกสาร — คือระบบที่ไม่มีใครรู้ว่าใครรับผิด

ข้อสอง — Cloud security ไม่ใช่เรื่องของการซื้อ CNAPP แพงๆ — แต่เป็นเรื่องของ routine 3 อย่าง. (1) MFA ทุก admin account + ทำให้เป็นการบังคับใช้ระดับนโยบาย. (2) Configuration audit รายเดือน — เริ่มจากเครื่องมือฟรีของ provider เอง (AWS Security Hub / Defender for Cloud / Security Command Center). (3) Backup ที่อยู่นอก cloud provider หลัก — เพื่อกู้ได้ถ้าโดน account compromise. 3 อย่างนี้ทำได้ — ป้องกันความเสี่ยงระดับ Code Spaces / Capital One ได้ 80%+

อีกอย่างที่ผมอยากให้คุณคิดในมุมยาว — ปี 2024-2026 มี trend ที่เกี่ยวข้องกับ Sovereign cloud + data residency เพิ่มขึ้น. ภาครัฐไทยกำลังศึกษา PDPA enforcement ที่เข้มขึ้น + ข้อบังคับเรื่อง critical infrastructure (พ.ร.บ. ไซเบอร์ 2562). ที่ตอนนี้ใช้ AWS Singapore สบายๆ — ในอนาคต อาจต้องย้ายมา GDCC หรือ regional cloud ที่อยู่ในเขตอำนาจกฎหมายไทย. architecture ที่ออกแบบให้ย้ายได้ง่าย — มีค่ามาก

ทีนี้ — ใน cloud ที่เราคุยกันใน EP นี้ — ผมพูดถึง EC2 instance, VM, server บน IaaS, container บน CaaS. แต่ในยุคปัจจุบัน — ระบบส่วนใหญ่ไม่ได้รันบน VM เปล่าๆ แล้ว. ระบบรันบน container — กล่องเล็กๆ ที่ห่อ app ไว้พร้อมกับทุกอย่างที่ต้องการ — แล้วก็เคลื่อนย้ายได้ไปที่ไหนก็ได้

ใน เมืองที่ของมีค่า ของเรา — ภาพต่อไปคือ warehouse ที่มีตู้คอนเทนเนอร์เป็นพันตู้. คุณรู้ไหมว่า Tesla เคยถูก cryptojack เพราะ Kubernetes dashboard ของบริษัท — เปิดไว้บน internet โดยไม่มี password? EP หน้าจะพาคุณรู้จัก — Container และ Kubernetes — เครื่องมือที่เปลี่ยนวิธีบริษัททำงาน แต่ก็เปลี่ยนหน้าตาของความเสี่ยงไปด้วย

→ EP.33 — Container + Kubernetes Security: ตู้คอนเทนเนอร์ใน warehouse