โมเดลที่ต้องท่องจำ#

Cloud มี 3 โมเดลหลัก — ระดับการรับผิดชอบของลูกค้าต่างกันตาม model:

IaaS (Infrastructure as a Service)

• Provider ให้: physical hardware, hypervisor, storage, networking
• ลูกค้าจัดการ: OS ขึ้นไป — patch OS, ติดตั้ง app, ดู security ของ app และ data
• ตัวอย่าง: AWS EC2, Azure VMs, GCP Compute Engine

PaaS (Platform as a Service)

• Provider ให้: hardware + OS + runtime + middleware
• ลูกค้าจัดการ: app และ data ขึ้นไป
• ตัวอย่าง: AWS Elastic Beanstalk, Azure App Service, Google App Engine

SaaS (Software as a Service)

• Provider ให้: ทุกชั้นถึง application
• ลูกค้าจัดการ: data + user access ของลูกค้าเอง
• ตัวอย่าง: Microsoft 365, Salesforce, Google Workspace

กฎทอง: ใน cloud ทุกระดับ ลูกค้ารับผิดชอบ data + access เสมอ#

ไม่ว่าจะ IaaS, PaaS, SaaS — data classification + access control + identity management เป็นของลูกค้า cloud provider ไม่ทำให้

นี่คือเหตุผลที่ cloud breach ส่วนใหญ่ — ไม่ใช่เพราะ provider พลาด แต่เพราะ customer misconfiguration:

• S3 bucket ตั้งเป็น public โดยไม่ตั้งใจ
• ไม่เปิด MFA ให้ admin account
• ไม่เปลี่ยน default password ของ database
• เปิด port ไว้ให้ทุก IP

Top Trap ของ Domain 5#

ข้อสอบ classic:

“องค์กรใช้ IaaS — ใครรับผิดชอบ patch OS?”

หลอก: Cloud provider จริง: Customer — ใน IaaS, customer รับผิดชอบ OS ขึ้นไป

อีกข้อ: “ใน SaaS ลูกค้ารับผิดชอบอะไรบ้าง?”

คำตอบ: data + user access management เป็นหลัก — application และ infrastructure เป็นของ provider

มุมผู้บริหาร: ความเข้าใจผิดที่แพง#

หลายองค์กรย้ายไป cloud โดยคิดว่า “security เป็นของ vendor” — ผลคือ:

• ไม่ลงทุน cloud security tooling
• ไม่ training ทีม IT เรื่อง cloud security
• ไม่มี cloud-specific incident response plan
• ไม่ทำ cloud configuration review

แล้วเมื่อเกิด breach — Verizon DBIR ทุกปีบอกตรงกัน — cloud misconfiguration เป็น top breach cause

Hypervisor — ระบบที่จัดการห้องทุกห้อง#

Virtualization = วาง OS หลายตัว (guest VMs) บน hardware ตัวเดียว ผ่านชั้นที่เรียก Hypervisor

ในมุมบ้าน — เปรียบเหมือนอาคารที่มีหลายห้อง ที่ทุกห้องใช้ระบบไฟฟ้าหลักร่วมกัน ระบบน้ำหลักร่วมกัน — ถ้าระบบหลักของอาคาร (hypervisor) มีปัญหา ทุกห้องได้รับผลกระทบ

Risk หลักของ Virtualization#

Hypervisor vulnerability

• ถ้า hypervisor มีช่องโหว่ — ทุก VM บนเครื่องนั้นเสี่ยงพร้อมกัน

VM Escape

• Attacker ใน guest VM “หลุด” ออกมาที่ hypervisor หรือ guest อื่น
• Worst case scenario ของ virtualization

Management console

• คอนโซลที่จัดการ VM ทั้งหมด — ถ้าโดน compromise = เข้าทุก VM
• ต้องมี MFA, restricted access, separate from production

Auditor มอง Virtualization ยังไง#

• Hypervisor patched + hardened ไหม
• Management console access เข้มงวดไหม (MFA, network restrictions)
• VM แต่ละตัว isolated จากกันจริงไหม
• Backup + DR ของ virtual environment

VLAN — ผนังที่เป็น Logical#

VLAN (Virtual LAN) = แบ่ง network logical โดยไม่ต้องใช้ cable แยก

ในมุมบ้าน — เปรียบเหมือนผนัง partition ในออฟฟิศ vs ผนังจริง — ดูเหมือนแยก แต่ถ้าทำไม่ดีอาจมีรู

VLAN Hopping#

ถ้า VLAN ตั้งผิด attacker ที่อยู่ใน VLAN A สามารถ “กระโดด” ไปยัง VLAN B ได้ — เข้าถึง network segment ที่ไม่ควรเข้าถึง

ข้อสอบ trap: “VLAN misconfiguration — attack ที่น่าจะเกิดที่สุด?”

หลอก: DoS attack จริง: VLAN hopping — ผู้โจมตีเข้า network segment ที่ไม่ได้รับอนุญาต

VSAN, SDN#

VSAN (Virtual SAN) = storage area network ที่เป็น virtual

SDN (Software-Defined Networking) = แยก control plane ออกจาก data plane — สั่ง network ผ่าน software

SDN เปิดความ flexible สูง แต่ถ้า controller ของ SDN โดน compromise — controller ควบคุมทั้ง network

Container vs VM#

VM = OS เต็มตัวบน hypervisor (หนัก, สร้างนาน) Container = packaged app ที่ share OS kernel กับ host (เบา, สร้างเร็ว)

ตัวอย่าง:

• Docker — สร้าง container
• Kubernetes — orchestrate container หลายตัว

ในมุมบ้าน — ห้องเช่าชั่วคราวที่ประกอบและรื้อถอนได้ในนาที vs อพาร์ตเมนต์ถาวร — ความเร็วของ container สร้างความเสี่ยงด้าน security configuration ที่ติดตามยาก

Container Risks#

• Privileged containers — container ที่มี root access ของ host = container escape = host compromise
• Unpatched images — base image ที่มีช่องโหว่ — ทุก container ที่อิง image นั้นมีรู
• Registry security — image repository ที่ไม่มี control
• Inter-container communication — container คุยกันได้โดยไม่ control

Auditor มอง Container#

• Image scanning ก่อน deploy ไหม
• Privileged container มีไหม — มีเหตุผลไหม
• Kubernetes RBAC ตั้งถูกไหม
• Network policy ระหว่าง container

ข้อสอบ trap: “พบ privileged containers ใน production — กังวลอะไร?”

หลอก: Performance จริง: Container escape ที่อาจทำให้ host ทั้งเครื่องโดน compromise

Risk หลักของ Cloud#

Multi-tenancy

• ลูกค้าหลายราย share infrastructure เดียวกัน
• Risk: data bleed ระหว่าง tenant
• Mitigation: encryption + isolation guarantees ในสัญญา

Data jurisdiction / sovereignty

• ข้อมูลเก็บอยู่ในประเทศไหน
• PDPA (ไทย), GDPR (EU), CCPA (California) มีข้อกำหนดเฉพาะ
• Cloud provider ที่มี data center หลายประเทศ — ต้องระบุ region

Vendor lock-in

• ระบบที่ผูกกับ provider-specific service ย้ายยาก
• Mitigation: ใช้ open standards, multi-cloud strategy

Right to audit

• Cloud provider ใหญ่ไม่ค่อยให้ลูกค้าเข้าตรวจ
• ต้องพึ่ง SOC 2 Type II report หรือ certification (ISO 27001)

Incident investigation limitations

• เมื่อเกิด incident — log อยู่ในมือ provider
• Forensic investigation อาจจำกัดโดย provider’s terms

Cloud Migration Best Practices#

ก่อนย้าย:

• Define security requirements ก่อน เลือก provider
• Right to audit clause ในสัญญา
• Data classification + encryption strategy
• Identity strategy (federation, SSO)
• Exit strategy (ย้ายออกจากตรงนี้ยังไง)

ข้อสอบ trap: “best practice ที่ auditor verify ก่อน cloud migration?”

หลอก: เลือก provider ราคาต่ำสุด จริง: Security requirements ถูก define ก่อน migration + right to audit clause ในสัญญา

ปัญหา: “Bolt-on Security”#

แบบเก่า — สร้างระบบ → ก่อน deploy ค่อยเอา security มาตรวจ → พบช่องโหว่เยอะ → แก้ไม่ทัน → push ไป production

ค่าแก้ bug:

• ใน design phase = ฟรี
• ใน development = ราคา 1x
• ใน QA = ราคา 10x
• ใน production = ราคา 100x+ (รวม reputation damage)

DevSecOps — Shift Left#

DevSecOps = ผูก security เข้า SDLC ทุกขั้น ไม่ใช่ขั้นสุดท้าย

หลักการ:

• Security as code — security policies เป็น code ที่ version control ได้
• Automated security testing in CI/CD pipeline — SAST, DAST, dependency scanning ทุก build
• Shift left — หา bug ตั้งแต่ต้น
• Continuous monitoring — security ไม่จบที่ deploy

ในมุมบ้าน — ออกแบบบ้านให้ปลอดภัยตั้งแต่แรก ไม่ใช่สร้างเสร็จแล้วค่อยเอาระบบกันโจรมาติด

เชื่อม Domain 3#

DevSecOps อยู่ตรงเส้นเชื่อมระหว่าง Domain 3 (System Acquisition / Development) และ Domain 5 (Protection)

Domain 3 พูดเรื่องการสร้างระบบ — DevSecOps ฝัง security ไปในกระบวนการนั้น