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 ของตัวเอง

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 ที่ย้ายได้ตั้งแต่วันนี้

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 ชั่วโมง) แค่ก้าวเดียว

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