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

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 (Virtual Machines), 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

โยงไปฝั่ง SDLC: การตัดสินใจเลือก *aaS model ไม่ได้เกิดตอน deployment — มันเกิดตั้งแต่ Phase 1 ของ SDLC ตอน Feasibility + Build vs Buy ดู CISA D3.25 — SDLC + Build vs Buy + Cloud Acquisition ที่ขยายภาพเป็น 6 models (On-Prem / IaaS / CaaS / PaaS / FaaS / SaaS) พร้อมตารางตัดสินใจ

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

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

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

• S3 bucket ตั้งเป็น public โดยไม่ตั้งใจ
• ไม่เปิด MFA (Multi-Factor Authentication / ยืนยันตัวตนหลายปัจจัย) ให้ 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 ก็บอกตรงกันว่า misconfiguration / error ติด top pattern ที่ทำให้เกิด breach ทุกปี — และในยุคที่ทุกอย่างขึ้น cloud, cloud misconfiguration คือหนึ่งในรูปแบบที่พบบ่อยที่สุด

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

Virtualization = วาง OS หลายตัว (guest VMs = Virtual Machines) บน 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 / Virtual Local Area Network) = แบ่ง 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 / Virtual Storage Area Network) คือ storage area network ที่เป็น virtual เอา local disk ของ server หลายตัวมาประกอบเป็น storage pool เดียวผ่าน software ไม่ต้องซื้อ SAN (Storage Area Network) hardware แยก

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

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

SAN vs VSAN — ต่างกันยังไง#

ในมุมบ้าน SAN เปรียบเหมือนห้องเก็บของรวมที่ตึกสร้างมาเพื่อเก็บของโดยเฉพาะ มีโครงสร้างของตัวเอง ต้องเดินสายไปต่อ ส่วน VSAN เปรียบเหมือนเอาตู้เก็บของของทุกห้องในตึกมารวมเป็น pool เดียวด้วย software ไม่ต้องสร้างห้องใหม่ ใช้ของที่มีอยู่แล้วให้คุ้ม

มุม auditor การย้ายจาก SAN เป็น VSAN ลด cost จริง แต่ต้อง verify ว่า replication policy ตั้งถูก ถ้า host ตาย data ของ VM นั้นยังอยู่ครบ ไม่ใช่ปล่อยตามค่า default แล้วเชื่อ vendor

Container vs VM#

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

ตัวอย่าง:

• Docker — สร้าง container
• Kubernetes (K8s) — 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 (Role-Based Access Control / คุม access ตาม role) ตั้งถูกไหม
• Network policy ระหว่าง container

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

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

5 deployment models ตาม NIST — รู้จัก Community cloud ด้วย#

หลายคนคุ้นกับ Public / Private / Hybrid / Multi-cloud แล้ว แต่ NIST นิยาม cloud ไว้ 5 deployment models ตัวที่หายไปจากบทสนทนาทั่วไปคือ Community cloud

Community cloud คือ cloud ที่หลายองค์กรที่อยู่ใน sector เดียวกัน (หรือมี compliance/governance ร่วมกัน) มา share infrastructure ด้วยกัน

ในมุมบ้าน เปรียบเหมือนคอนโดที่มีนิติบุคคลร่วมกันหลายตึกในโครงการเดียว ทุกตึกใช้กฎเดียวกัน ระบบ security เดียวกัน เพราะลูกบ้านเป็นกลุ่มที่มี profile คล้ายกัน (เช่น โครงการเฉพาะข้าราชการ หรือเฉพาะ professional บางสาย)

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

• AWS GovCloud / Azure Government สำหรับหน่วยงานรัฐบาลสหรัฐ + contractor ที่ต้องผ่าน FedRAMP
• Healthcare cloud consortium ของโรงพยาบาลที่ share infrastructure ที่ผ่าน HIPAA compliance
• Banking cloud กลุ่มธนาคารที่ share platform ที่ผ่าน PCI-DSS + central bank regulation
• Gaia-X (EU) federation ของ cloud provider ในยุโรปที่ยึด data sovereignty ของ EU เป็นหลัก

Use case ที่ทำให้ Community cloud เกิด:

• Regulatory pressure ตรงกัน สมาชิกในวงการเดียวกันต้อง comply เรื่องเดียวกัน share infrastructure ที่ pre-certified แล้วถูกกว่าทำเอง
• Cost sharing ลงทุน security ระดับสูงคนเดียวไม่คุ้ม แต่ 10 บริษัทช่วยกันออกได้
• Sector control ทุกคนในวงการอยากให้ governance เป็นของวงการ ไม่ใช่ของ vendor ภายนอก

เทียบกับ 4 models เดิม:

มุม IS auditor เวลาเจอ Community cloud ต้อง verify: (1) governance ของ community ตั้งยังไง ใครเป็นคนตัดสินเรื่อง security policy (2) สมาชิกใหม่เข้าได้ยังไง มี vetting ไหม ไม่ใช่ใครมาก็ join ได้ (3) SLA เป็นแบบ provider เดียวกับ public หรือมีข้อพิเศษของ community

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 (System and Organization Controls 2) Type II report หรือ certification (ISO 27001)

Incident investigation limitations

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

CDN — Risk และ Best Practice ที่ Auditor ต้องดู#

CDN (Content Delivery Network / เครือข่ายส่ง content) = บริการที่ cache content ขององค์กรไว้ที่ edge server ทั่วโลก เพื่อให้ user โหลดเร็วขึ้น (ใกล้กับตัวเอง = latency ต่ำ) — Cloudflare, Akamai, AWS CloudFront เป็นตัวอย่างที่คุ้นที่สุด

CDN เป็น cloud service ก็จริง แต่ risk ต่างจาก cloud storage หรือ compute มาก เพราะ CDN ทำหน้าที่ distribute content ออกไปข้างนอก เลย attack surface กว้างกว่าเยอะ

CDN Security Risks ที่ CRM ระบุ

CDN Best Practices ที่ CRM แนะนำ

Trap ของ CDN

Cloud migration จริงๆ มี 3 ทิศทาง ไม่ใช่ทางเดียว#

เวลาคนพูดคำว่า “cloud migration” ส่วนใหญ่นึกถึงทิศทางเดียวคือ on-prem ขึ้น cloud จบ แต่จริงๆ migration มี 3 ทิศทาง และทิศทางที่ 3 กำลังกลับมาเป็นกระแสในยุคนี้ครับ

1. On-prem → Cloud (ทิศทางที่คุ้นที่สุด)

แบ่งย่อยตามระดับความลึก:

• Lift-and-shift ยก VM ขึ้นไปวางบน cloud IaaS เลย ไม่แก้ architecture อะไร เร็วสุด แต่ไม่ได้ใช้ประโยชน์ cloud
• Refactor / re-platform ปรับให้ใช้ managed service บางตัว (เช่น DB ใช้ RDS แทน self-managed) เริ่มประหยัด
• Rebuild / cloud-native เขียนใหม่หมดเป็น microservice + container + serverless ใช้ cloud เต็มประสิทธิภาพ แต่ลงทุนเยอะสุด

2. Cloud → Cloud (vendor migration / multi-cloud strategy)

ย้ายจาก provider หนึ่งไปอีก provider หรือกระจายไปหลาย provider พร้อมกัน เหตุผลปกติคือ ราคา feature set ใหม่ หรือเหตุผลเชิงกลยุทธ์ที่อยาก hedge vendor lock-in

3. Cloud → On-prem (Repatriation) ทิศทางย้อนกลับที่กำลังมา

หลายปีแรกของยุค cloud ทุกคนพูดเป็นเสียงเดียวกันว่า “อนาคตทุกอย่างต้องอยู่บน cloud” พอผ่านมา 10+ ปี บางบริษัทเริ่มย้ายกลับ on-prem หรือไป colocation แทน

Case ที่ถูกอ้างบ่อยที่สุด:

• Dropbox (2016-2017) ย้าย workload หลักออกจาก AWS ไป infrastructure ของตัวเอง รายงานว่าประหยัดได้ราว 75 ล้านดอลลาร์ในช่วง 2 ปี
• 37signals / Basecamp (2023) David Heinemeier Hansson ประกาศย้ายออกจาก cloud เพราะ cost ที่บานปลาย เขียน blog ชุดอธิบาย thesis “leaving the cloud”

Drivers ที่ทำให้คนพิจารณา repatriation:

• Cost overrun bill cloud โตเร็วกว่ารายได้ พอ scale ถึงระดับหนึ่งของตัวเองคุ้มกว่า
• Data sovereignty ลูกค้า / regulator บังคับว่า data ต้องอยู่ในประเทศ / control เอง
• Performance latency-sensitive workload ที่ cloud public ทำไม่ได้ดีพอ
• Vendor lock-in fatigue ผูกกับ proprietary service ของ provider จนต่อรองอะไรไม่ได้

Challenges ของการ repatriate:

• Skill gap ทีมเคยชินกับ cloud มา 5-10 ปี อาจไม่มีคนที่ดูแล physical infra เป็น
• Capex กลับมา ต้องลงทุน hardware + data center / colocation ใหม่ เปลี่ยน opex กลับเป็น capex
• Refactor cloud-only service ถ้าระบบใช้ managed service ของ provider (เช่น DynamoDB, BigQuery, Lambda) ย้ายออกแปลว่าต้อง rebuild ส่วนนั้น

มุม IS auditor ที่เกี่ยวข้องคือ exit strategy ที่ควรถูก define ตั้งแต่ตอน migrate เข้า cloud ไม่ใช่นึกขึ้นมาได้ตอนอยากออก

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 (Development + Security + Operations) = ผูก security เข้า SDLC (Software Development Lifecycle) ทุกขั้น ไม่ใช่ขั้นสุดท้าย

หลักการ:

• Security as code — security policies เป็น code ที่ version control ได้
• Automated security testing in CI/CD (Continuous Integration / Continuous Deployment) pipeline — SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), 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 เข้าไปในกระบวนการนั้น

Cloud + Virtualization deep#

• Cloud deployment models + 9 CSA Top Threats + SRM SLA negotiation + CSPM → cybersec EP.32 — Cloud Shared Responsibility (เพิ่มรอบนี้)
• Cloud stack anatomy + Type-1/Type-2 hypervisor + Container security + SDN → cybersec EP.32.5 — Cloud Stack Anatomy
• Container/Kubernetes security + 7 benefits + 5 limitations → cybersec EP.33 — Container + Kubernetes
• DevSecOps + OS Hardening framework (CIS/STIG) + MAST + Fuzz testing + 6 benefits → cybersec EP.34 — DevSecOps (เพิ่มรอบนี้)
• SDN 3 planes + SD-WAN vs SDN distinction + ZTNA → cybersec EP.37 — Remote Work + ZTNA
• PVC vs SVC Virtual Circuits + VLAN Static/Dynamic + VSAN deep → cybersec EP.26.5 — Network Anatomy

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 5: Section 5.8 Cloud and Virtualized Environments