VLAN — แบ่งย่านที่ระดับ switch#

VLAN (Virtual LAN — เครือข่ายเสมือนภายในสายเดียวกัน) — เป็น feature ของ network switch ตัวที่ดีหน่อย (managed switch). switch ตัวเดียวกัน — port 1-8 = VLAN 10 (HR). port 9-16 = VLAN 20 (Finance). port 17-24 = VLAN 30 (Guest WiFi)

ลองนึกภาพ — สายไฟ LAN เดียวกัน แต่ switch ทำ logical separation — port ใน VLAN 10 คุยกันได้. port ใน VLAN 10 คุยกับ port ใน VLAN 20 ไม่ได้ — เว้นแต่จะผ่าน router/firewall

ทำไมต้องทำเป็น VLAN ไม่ใช่ switch แยกตัว? — เพราะ:

• ประหยัด — ใช้ switch ตัวเดียวกัน + สายเดียวกัน
• ยืดหยุ่น — ย้าย VLAN ของ port ได้ใน software ไม่ต้องเดินสายใหม่
• scalable — ออฟฟิศ 200 คน ใช้ VLAN ได้ 10-20 ย่านโดยไม่ต้องลงทุน hardware เพิ่ม

ภาษาคน — VLAN = เอาเชือกขึงแบ่งห้องในห้องโถง โดยไม่ต้องสร้างกำแพงจริงๆ. กำแพงเสมือน ที่ switch บังคับ

Subnet — แบ่งย่านที่ระดับ IP address#

Subnet (Subnetwork — เครือข่ายย่อย) — แบ่งที่ Layer 3 (IP layer). ทุกย่านมีช่วง IP ของตัวเอง

• HR = 192.168.10.0/24 (256 IPs)
• Finance = 192.168.20.0/24
• Server farm = 10.0.1.0/24
• DMZ = 10.0.99.0/24

ระหว่าง subnet — จะคุยกัน ต้องผ่าน router หรือ Layer 3 switch. ที่ตัวกลางนี้ — เราตั้ง ACL (Access Control List) หรือ firewall rule ได้ — ใครคุยกับใครได้บ้าง

โดยปกติของวงการ — VLAN กับ Subnet ผูกคู่กัน — VLAN 10 = Subnet 192.168.10.0/24 — เพื่อจัดการง่ายและให้ Layer 2 + Layer 3 สอดคล้อง

ทำไมแยก HR / Finance / R&D / Guest WiFi ออกจากกัน#

ลองนึก scenario ที่บริษัทไทยพบบ่อย — Guest WiFi ของลูกค้าที่มาประชุม — เครื่อง laptop ของลูกค้าติด malware. ถ้า Guest WiFi อยู่ VLAN เดียวกับ internal network — malware เริ่ม scan + กระโดดเข้า file server ของ Finance ทันที

ที่ถูกต้อง — Guest WiFi อยู่ VLAN แยก + Subnet แยก + ACL บอกว่าออก internet ได้อย่างเดียว ห้ามแตะ internal subnet ใดๆ. ลูกค้าใช้ WiFi ได้ — แต่แตะของบริษัทไม่ได้

หลักการเดียวกันใช้กับ:

• VoIP phone — แยก VLAN — ไม่ให้ phone ใน lobby ที่ไม่มี security เข้าถึง file server
• CCTV / IoT — แยก VLAN — กล้องวงจรปิดส่ง stream ไป NVR เท่านั้น ห้ามคุยกับ HR system
• Printer — แยก VLAN — printer มี firmware ที่ patch ยาก เป็นจุดเสี่ยง
• Server vs User — server อยู่คนละ subnet กับ user — ไม่ใช่ทุกคนต้องคุยกับ database server ตรงๆ

Layer 2 vs Layer 3 segmentation — ต่างกันยังไงในเชิงปฏิบัติ#

Layer 2 (VLAN) = แบ่งที่ switch — เร็ว — ใช้ทำ broadcast domain isolation — ป้องกัน broadcast storm + ARP poisoning ระหว่าง VLAN

Layer 3 (Subnet + Routing + ACL) = แบ่งที่ router/firewall — ช้ากว่านิดหน่อย — ใช้ทำ policy enforcement — ตั้ง rule ว่าใครคุยกับใครได้

ในเมืองที่ออกแบบดี — ใช้ทั้ง 2 ชั้นซ้อนกัน. VLAN แยกการชนกันของ traffic. Subnet + ACL บังคับ policy

มุมผู้บริหาร: ถ้าทีม IT บอกคุณว่า “เครือข่ายของเราเป็น flat network — ทุกเครื่องอยู่ subnet เดียวกัน” — นี่คือ red flag ระดับใหญ่ของ Part 4. flat network = โจรเข้าจุดเดียว เข้าถึงทุกระบบ. งบประมาณในการ migrate ไป segmented network สำหรับบริษัทขนาดกลาง — ไม่แพงเหมือนที่คิด — managed switch + firewall ตัวกลาง + reconfig DHCP + วาง VLAN plan — ทั่วไปอยู่ในงบหลักแสน-หลักล้านขึ้นกับขนาด. ROI = ลดความเสี่ยงของ ransomware lateral movement ที่ทั่วไปทำลายบริษัทใน 6-24 ชั่วโมง. เป็น basic hygiene ที่ทุกบริษัทควรมีตั้งแต่ขนาด 50 คนขึ้นไป

ทำไมต้องมี DMZ#

บริษัทคุณมีบริการที่ลูกค้าต้องเข้าถึงจาก internet:

• Web server ของบริษัท — ลูกค้าเข้าเว็บได้
• Email server (อาจจะใช้ SMTP relay) — รับ email ขาเข้า
• FTP server (ถ้ายังใช้) — partner upload file
• VPN gateway — พนักงาน remote work เข้ามา
• DNS server (สำหรับ public lookup ของ domain ของบริษัท)
• API gateway — external system เรียก API

service พวกนี้ — อยู่ internet ไม่ได้ (server ของบริษัท) — แต่ก็ อยู่ internal network ไม่ได้เช่นกัน เพราะถ้า web server โดน hack — โจรจะกระโดดจาก web server ไป database ภายใน + AD + file server ทันที

ทางแก้ — เปิดย่านกลาง = DMZ = ห้องรับแขก:

• Outside (Internet) → DMZ (public service) = อนุญาตให้เข้าได้ผ่าน port ที่ระบุ (80, 443, 25, ฯลฯ)
• DMZ → Inside (Internal network) = จำกัดสุดๆ — DMZ เริ่ม connection ไป internal ไม่ได้ตรงๆ. เว้นแต่ผ่าน proxy/API gateway ที่ออกแบบมาเฉพาะ
• Inside → DMZ = บางครั้งอนุญาต (admin push update). บางครั้งไม่อนุญาต (push ผ่าน CI/CD ที่อยู่ใน management network ต่างหาก)

DMZ architecture แบบคลาสสิค — Two-Firewall vs Single Firewall#

Single-Firewall DMZ (3-Leg Firewall) — firewall ตัวเดียว มี 3 interface: Outside / DMZ / Inside. ตั้ง rule ระหว่าง 3 ฝั่งใน firewall เดียวกัน. ประหยัด. แต่ถ้า firewall โดน hack = ระบบทั้งหมดเปิด

Two-Firewall DMZ (Sandwich) — firewall 2 ตัว — ตัวนอก (Internet → DMZ) + ตัวใน (DMZ → Internal). โจรต้อง bypass 2 firewall ที่ vendor ต่างกัน ถึงจะเข้า internal ได้. มาตรฐานของ Defense in Depth + Diversity (EP.04). แพงกว่าหน่อย — แต่ secure กว่าเยอะ

วงการ enterprise ของ bank / financial / government — ใช้ Two-Firewall + vendor ต่างกัน เป็นมาตรฐาน. เช่น firewall นอก = Palo Alto / firewall ใน = Fortinet — ถ้ามี zero-day ใน vendor หนึ่ง อีกตัวจะยังกัน

DMZ ปี 2026 — ยังจำเป็นไหม#

อ้าว — ในยุค cloud + microservice + zero trust — concept DMZ ดูเก่าๆ ใช่ไหม?

ใช่ + ไม่ใช่. Concept ของ DMZ — ยังจำเป็น — แต่ form เปลี่ยนไป:

• On-premise + datacenter เก่า — ยังใช้ DMZ classic
• Cloud-native — DMZ = public subnet ของ VPC (ที่ load balancer + web server อยู่). Private subnet = internal (ที่ database + internal service อยู่)
• Kubernetes — DMZ = Ingress namespace ที่มี service ที่เปิด LoadBalancer. internal service อยู่ namespace ที่ไม่เปิด LoadBalancer

Concept ยังเดิม — แต่ละบริษัทแค่เรียกชื่อต่างกัน + implement ต่างกัน. หลักการเดียวกัน — แยกของที่เปิดให้คนนอก ออกจากของที่ไม่เปิด

Anti-pattern คลาสสิค — DMZ ที่ไม่ใช่ DMZ จริง#

pattern ที่บริษัทไทยขนาดกลางติดบ่อย:

1. Web server วาง datacenter เดียวกับ database — ไม่มี DMZ — แค่ open port 80/443 ที่ firewall มาที่ web server เลย. web server share VLAN + Subnet กับ database. โจร hack web → ถึง database ใน 5 นาที
2. DMZ มีอยู่ — แต่ rule ระหว่าง DMZ ↔ Internal เปิดหมด — DMZ → DB อนุญาตทุก port. = DMZ ในนาม ไม่มีในความจริง
3. DMZ มี domain controller — เพื่อให้ web server authenticate ลูกค้า. โดนแล้ว = domain ถูก hijack ทั้งบริษัท

ที่ถูกต้อง — DMZ มีแค่ service ที่ต้อง public. Authentication ใช้ proxy → internal AD ผ่าน restricted protocol. Database อยู่ internal ไม่อยู่ DMZ. Logging ส่งจาก DMZ → SIEM ผ่าน one-way pipe

มุมผู้บริหาร: ถ้าทีม IT บอกว่า “web server กับ database อยู่ network เดียวกัน — ก็มันคุยกันต้องสะดวก” — นี่คือ architecture risk ที่ใหญ่ที่สุดของ Part 4. ในข่าวของวงการในรอบ 10 ปี — เคสที่ web server hack → database leak ทันที = น่าจะเกินครึ่งของ data breach ขนาดใหญ่. การลงทุนใน DMZ ที่ออกแบบดี — ราคาไม่แพง — แต่ลด blast radius ของเคสที่ติดบ่อยที่สุดในวงการ (web app vulnerability → data leak) มหาศาล. คำถามที่ board ควรถาม CIO — “ระหว่าง web server กับ database — มี network boundary ที่มีการ enforce rule ไหม? Audit trail ของ traffic ระหว่าง 2 ตัวนี้ดูได้ที่ไหน?” — ถ้า CIO ตอบไม่ได้ในวันเดียว = budget item ของไตรมาสหน้า

VPC คืออะไร#

VPC (Virtual Private Cloud — เครือข่ายส่วนตัวเสมือนบน cloud) — เป็น network ของคุณเอง บน infrastructure ของ cloud provider. AWS เรียก VPC. Azure เรียก VNet (Virtual Network). Google Cloud เรียก VPC. ทั้งหมด concept เดียวกัน

ลองนึก — AWS มี datacenter ขนาดมหาศาลทั่วโลก. คุณสร้าง VPC = กั้นย่านในเมือง AWS เป็นของคุณ. ใช้ IP range ที่คุณกำหนด (เช่น 10.0.0.0/16). ไม่มีบริษัทอื่นเห็น traffic ของคุณ — แม้จะอยู่ datacenter เดียวกัน

ภายใน VPC — แบ่งเป็น Subnet ได้:

• Public Subnet — มี route ออก internet ผ่าน Internet Gateway — ที่นี่วาง web server / load balancer / NAT gateway
• Private Subnet — ไม่มี route ตรงไป internet — ที่นี่วาง application server / database / internal cache
• Database Subnet — Subnet ภายใน Subnet — restrict ยิ่งกว่าเดิม — รับ traffic จาก application subnet เท่านั้น

นี่คือ DMZ pattern ของยุค cloud. Public Subnet = DMZ. Private Subnet = Internal

Security Group + NACL — ACL ของยุค cloud#

ใน VPC มี 2 layer ของ access control:

NACL (Network ACL — ACL ระดับ Subnet) — stateless — ตั้ง rule ที่ boundary ของ subnet — ทั้งขาเข้าและขาออกต้องตั้งแยกกัน. เหมือน firewall ระหว่าง subnet

Security Group — firewall ระดับ instance — stateful — ตั้ง rule ของ EC2 instance / RDS / Lambda แต่ละตัว. จำได้ว่า connection ไหนของจริง

โดยปกติ — ใช้ ทั้ง 2 ซ้อนกัน:

• NACL = block IP range ทั้งช่วงที่ไม่ควรเข้า subnet (เช่น country block)
• Security Group = ระบุ exact instance + port ที่อนุญาต (เช่น web server SG → DB SG บน port 3306 เท่านั้น)

นี่คือ Defense in Depth ของยุค cloud — 2 ชั้นที่ vendor เดียวกัน แต่ scope ต่างกัน

VPC Peering + Transit Gateway — เมื่อมีหลาย VPC#

บริษัทขนาดกลาง-ใหญ่ในปี 2026 — มัก มี หลาย VPC — Production VPC / Staging VPC / Development VPC / Shared Services VPC (DNS, AD, monitoring) — แยกเพื่อ blast radius

VPC คุยกันไม่ได้ default — ต้องเชื่อม:

• VPC Peering — เชื่อม 2 VPC โดยตรง. ใช้ดีถ้ามี VPC ไม่กี่ตัว
• Transit Gateway — hub กลาง — ทุก VPC ต่อกับ hub. AWS recommend สำหรับองค์กรที่มี 5+ VPC

ใน traffic ระหว่าง VPC — ยังต้องผ่าน Security Group + NACL + route table — ไม่ใช่ peering แล้วเปิดทุกอย่างให้

Cloud-specific anti-patterns#

pattern ที่บริษัทไทยติดบ่อยตอน migrate ไป cloud:

1. Default VPC ที่ AWS สร้างให้ — ใช้ตามที่ default — ทุก subnet มี route ออก internet — = ทุก instance เป็น public ทันที. ที่ถูกต้อง = สร้าง VPC ของตัวเอง + กำหนด public/private subnet เอง
2. Security Group เปิด 0.0.0.0/0 บน port SSH (22) — โลก SSH เข้าได้ — ถูก brute force ในไม่กี่ชั่วโมง. ที่ถูกต้อง = SSH จาก bastion host / VPN เท่านั้น หรือใช้ Session Manager (AWS SSM)
3. Database เปิด public — RDS instance ใน public subnet + Security Group เปิดให้ application server ที่ public IP — = database ถ้าผ่าน firewall ก็ public. ที่ถูกต้อง = RDS ใน private subnet — Security Group อนุญาตเฉพาะ SG ของ application
4. ไม่ enable VPC Flow Logs — ไม่มี log ของ traffic ใน VPC — เกิดเรื่องตามไม่ได้

Cloud Security ของ 3 vendor#

• AWS: VPC + Security Group + NACL + WAF + Shield + GuardDuty
• Azure: VNet + NSG (Network Security Group) + ASG (Application Security Group) + Azure Firewall + DDoS Protection
• GCP: VPC + Firewall Rules + Cloud Armor

ศัพท์ต่าง — concept เดียวกัน — virtual segmentation ที่ enforce ผ่าน software-defined networking

มุมผู้บริหาร: สำหรับบริษัทไทยที่กำลัง migrate ไป cloud — VPC architecture ของวันแรก = ภาระของวันถัดๆ ไป. ถ้าวันแรกตั้ง VPC โดยไม่แยก public/private subnet — แก้ทีหลังต้องย้าย workload ทั้งหมด. คำแนะนำง่ายๆ — ก่อน migrate ให้ทำ workshop กับ cloud architect 2-3 วัน — วาด VPC plan ที่ครอบคลุม Production / Staging / Dev + Security Group baseline + NACL + Flow Log + Transit strategy. งบประมาณ — ค่าที่ปรึกษา cloud ที่ certify (AWS Solution Architect Pro / Azure Solutions Architect Expert) 2-3 วันก็พอ. ROI = ไม่ต้องทำใหม่ตอน scale + ไม่โดน auditor ตำหนิตอนทำ ISO 27017 (Cloud Security)

Microsegmentation คืออะไร#

Microsegmentation = policy ของแต่ละ service / workload — แทนที่จะ policy ของ subnet หรือ VLAN

ลองนึก — ในเมืองที่แบ่งเขตแบบเก่า — โจรเข้าเขต สีลม — เดินทุกตึกในสีลมได้. ในเมืองที่ microsegmented — โจรเข้าตึก A ในสีลมได้ — แต่ตึก B ในสีลมเดียวกัน ก็เข้าไม่ได้. ทุกตึกมี policy ของตัวเอง

ทาง technical — แทนที่จะใช้ firewall ที่ขอบของ VLAN/Subnet — เราใช้:

• Host-based firewall ที่ทุก server — iptables / Windows Defender Firewall / nftables
• Sidecar proxy — Envoy / Linkerd ที่ฝังข้าง service ทุกตัว
• Service Mesh — Istio / Linkerd ที่ enforce policy ระหว่าง service
• Identity-based policy — แทน IP-based — เช่น “service A (พิสูจน์ตัวตนด้วย certificate) คุยกับ service B ได้ บน port X” — ไม่อิง IP ที่อาจเปลี่ยน

Microsegmentation = หัวใจของ Zero Trust#

จำได้ไหมครับ EP.17 ที่เราคุยเรื่อง Zero Trust — “ไม่เชื่อใครจนกว่าจะพิสูจน์ + พิสูจน์ทุกครั้ง”

Zero Trust ที่ network level = Microsegmentation. ไม่มี trusted internal network — ทุก connection ระหว่าง service ต้อง authenticate + authorize ทุกครั้ง

นี่ flip mindset ของวงการที่อยู่กับ “perimeter security” (ป้อมยามขอบเมือง — Firewall ใน EP.27) — ตั้งแต่ปี 1990. ในปี 2026 — perimeter ยังจำเป็น แต่ ไม่เพียงพอ. ต้องเพิ่ม microsegmentation ภายใน

VLAN classic vs Microsegmentation — ต่างกันยังไง#

East-West vs North-South Traffic#

ศัพท์ที่ใช้บ่อยในเรื่อง segmentation:

• North-South Traffic = traffic ระหว่าง outside ↔ inside (ขึ้น-ลง ในแผนผัง network) — ป้องกันด้วย firewall ขอบเมือง + DMZ
• East-West Traffic = traffic ระหว่าง service ภายในเมือง (ซ้าย-ขวา) — ป้องกันด้วย microsegmentation

ในข้อมูล traffic ของ datacenter ทั่วไป — east-west = 70-80% ของ traffic ทั้งหมด. ในยุค microservice — เลขนี้สูงกว่านี้อีก. แต่ traditional security ส่วนใหญ่ลงทุนที่ north-south. = ที่บริษัทไทยส่วนใหญ่ — east-west = blind spot

Vendor ของ Microsegmentation#

• VMware NSX — สำหรับ VMware environment — host-based policy ผ่าน hypervisor
• Cisco Tetration (เปลี่ยนชื่อเป็น Cisco Secure Workload) — flow analytics + policy enforcement
• Illumio — host-based agent — แบ่ง policy ตาม label
• Guardicore (Akamai เข้าซื้อ) — เน้น east-west + ransomware containment
• Cloud-native: AWS VPC + Security Group + Service Mesh, Azure NSG, GCP Cloud Armor + Anthos Service Mesh

ของพวกนี้ — ไม่ใช่ของถูก. enterprise license บางตัวหลักล้านบาทต่อปีขึ้นไป. แต่สำหรับบริษัทที่มี crown jewel data + regulated industry — ROI ชัด

Microsegmentation ใน Kubernetes — Network Policy#

ถ้าบริษัทคุณใช้ Kubernetes (EP.33 จะคุยลึก) — Network Policy ของ Kubernetes คือ microsegmentation built-in

ตัวอย่าง policy:

• pod frontend คุยกับ pod backend ได้บน port 8080 เท่านั้น
• pod backend คุยกับ pod database ได้บน port 5432 เท่านั้น
• pod อื่น = block

นี่คือ microsegmentation ระดับ container — ที่ทุกบริษัทที่ใช้ Kubernetes ควรเปิด default-deny + เขียน policy เฉพาะที่ต้องการ. แต่ pattern ที่เจอบ่อย — ไม่เปิด NetworkPolicy เลย — = pod ทุกตัวคุยกันได้ทั้ง cluster

มุมผู้บริหาร: Microsegmentation เป็น investment ระยะกลาง (12-24 เดือน) ที่ผู้บริหารต้อง endorse จากบนลงล่าง. เพราะมัน change ทาง culture — ทีมพัฒนาที่เคยคุยกันได้สบายๆ ต้องเขียน policy + ขอ approve + ทำ test ของ policy. ROI = ลด blast radius ของ ransomware ที่ทั่วไประบาดข้าม east-west traffic อย่างเร็วในไม่กี่ชั่วโมง. NotPetya ที่เราจะคุยในหัวข้อต่อไป — ระบาดทั่ว Maersk เพราะไม่มี microsegmentation. ถ้ามี — impact น่าจะลดได้ 80-90%. คำแนะนำ — เริ่มที่ Crown Jewel — server ที่เก็บข้อมูลสำคัญที่สุด 5-10 ตัว — ทำ microsegmentation รอบ ๆ ก่อน. ค่อยขยายไป tier 2 / tier 3 ในปีถัดๆ ไป

เคส 1: Target 2013 — โจรเข้าผ่าน HVAC vendor#

ปี 2013 ก่อนวันคริสต์มาส — Target retail chain ของอเมริกาขนาดใหญ่ — เกิด breach ที่ขโมยข้อมูล credit card ของลูกค้า 40 ล้านคน + ข้อมูลส่วนตัวอีก 70 ล้านคน. รวมราคาความเสียหาย $200M+

โจรเข้าได้ยังไง?

Step 1 — โจรส่ง phishing email ไปที่ Fazio Mechanical — บริษัท HVAC vendor ที่ดูแลระบบทำความเย็นของ Target. พนักงาน Fazio คลิก attachment ที่มี Citadel malware (variant ของ Zeus) — โจรขโมย credential ที่ Fazio ใช้เชื่อม Target

Step 2 — โจรใช้ credential ของ Fazio เข้า vendor portal ของ Target — portal ที่ vendor ใช้ส่งใบแจ้งหนี้ + ดูตารางบำรุงรักษา. ฟังก์ชันธรรมดา — ไม่มีอะไรเกี่ยวกับ payment

Step 3 — ตรงนี้คือจุดล้มเหลวของ Segmentation — vendor portal อยู่ใน network เดียวกับ POS system + payment processing. ไม่มี VLAN แยก. ไม่มี firewall ภายใน. โจรกระโดดจาก vendor portal → internal network → POS terminal → install BlackPOS malware ที่อ่าน credit card ตอน swipe

Step 4 — ดูดข้อมูลออกผ่าน FTP server ภายในของ Target (ที่ตั้งไว้ stage data) — ส่งออก internet ผ่าน drop server ในรัสเซีย. กิจกรรมนี้ใช้เวลาประมาณ 2 สัปดาห์ ตั้งแต่ Nov 27 ถึง Dec 15 2013

บทเรียนของ Target 2013 — โจรไม่ได้ break perimeter firewall ของ Target. โจรเข้าผ่าน vendor ที่มี trust relationship — ซึ่งเป็น weakness ที่ firewall ขอบเมืองไม่เห็น. แต่ที่ ทำให้ breach ใหญ่ขนาด 110 ล้าน record = flat internal network. ถ้า Target มี segmentation ที่ดี — vendor portal → POS network = ต้องผ่านกำแพง + rule + monitoring. โจรอาจจะติดอยู่ที่ vendor portal subnet โดย impact ไม่ลามถึง POS

เคสนี้ — เป็นเคสที่ ทุกตำราของ network security เรียน เพราะ illustrate ความสำคัญของ segmentation ที่ระดับ enterprise ได้ชัดที่สุด

เคส 2: Maersk + NotPetya 2017 — ระบาดทั่วโลกใน 7 นาที#

ปี 2017 มิถุนายน — NotPetya = malware ที่เริ่มจากการ supply-chain attack ของ M.E.Doc (software บัญชีของยูเครน). เครื่องที่ติด — ใช้ EternalBlue exploit ของ NSA (ที่หลุดออกมาจาก Shadow Brokers) + Mimikatz เพื่อขโมย credential — แล้วระบาดผ่าน SMB ใน network เดียวกัน

Maersk — บริษัท shipping ใหญ่ที่สุดในโลก — มี office ในยูเครน. เครื่องเดียวในยูเครนติด NotPetya. ในเวลา 7 นาที — malware ระบาดถึง เครื่องทั่วโลก ทั้ง 4,000 server + 45,000 workstation ของ Maersk

ทำไมเร็วขนาดนั้น — Flat global network. Maersk มี internal network ที่ทั่วโลกของบริษัทต่อกันแบบที่ malware เดินไปเครื่องไหนก็ได้ที่อยู่ใน domain เดียวกัน

ผลลัพธ์:

• เครื่องเกือบทั้งหมด encrypt ไม่สามารถกู้คืน (NotPetya ไม่ใช่ ransomware จริง — มัน wiper — เข้ารหัสแล้วทำลายกุญแจ — ไม่มีทาง decrypt)
• กิจการ shipping ทั่วโลก หยุด 10 วัน
• ผู้ผลิตในยุโรปไม่สามารถส่งสินค้า
• Maersk ต้อง reinstall AD ทั่วโลก จาก single AD server ที่บังเอิญ offline ตอน NotPetya ระบาด (เครื่องที่กานา — power cut ทำให้ไม่ติด)
• ความเสียหาย ~$300M ของ Maersk เพียงผู้เดียว
• ทั่วโลก ~$10B (FedEx, Merck, ฯลฯ ก็โดน)

บทเรียนของ Maersk — Single flat network ระดับ global = single point of failure. ถ้า Maersk มี regional segmentation + microsegmentation รอบ critical service (AD, file server, ERP) — ความเสียหายอาจจำกัดที่ยุโรปตะวันออก หรือเฉพาะ workstation network. ในข่าวที่ถัดมาเล่า — Maersk rebuild network ใหม่ทั้งหมดด้วย segmentation strategy หลังเหตุการณ์

เคส 3: Equifax 2017 — Flat network ที่ขยาย breach ของ 147 ล้านคน#

ปี 2017 — Equifax = บริษัท credit bureau ใหญ่ที่สุดในอเมริกา — เกิด breach ที่ขโมยข้อมูลส่วนตัว (ชื่อ + Social Security Number + วันเกิด + ที่อยู่) ของ 147 ล้านคน. ราคาความเสียหายรวมประมาณ $1.4B + ค่าปรับ$700M+ จาก FTC + state AG

โจรเข้าได้ยังไง — เริ่มจาก Apache Struts CVE-2017-5638 ที่ยังไม่ patch บน web application หนึ่ง — ที่เปิดให้ลูกค้า dispute credit. โจร RCE web server ในวันที่ 13 พฤษภาคม

ที่ทำให้เคสนี้ใหญ่ = flat internal network:

• จาก web server ที่ hack — โจรกระโดดเข้า internal network ทันที (ไม่มี DMZ-to-internal restriction)
• ใน internal — มี 76 database ที่เก็บข้อมูลส่วนตัว — คุยกันได้ทุกตัว
• โจรไป scan + dump 51 database ใช้เวลา 76 วัน — โดยที่ Equifax ไม่รู้ตัว
• ใน 76 วันนั้น โจรดึง data ผ่าน encrypted channel ที่ certificate ของ traffic monitoring tool หมดอายุ = monitoring ตาบอด

บทเรียนของ Equifax — มี 3 ปัญหาซ้อนกัน:

1. Patch management พลาด (CVE-2017-5638 มี patch ก่อน breach 2 เดือน)
2. Flat internal network — web server กระโดดถึง 76 database ได้
3. Monitoring ไม่ทำงาน (certificate หมดอายุ — ไม่มี alert)

ถ้า Equifax มี microsegmentation — web server → database = ต้องผ่าน rule + log + alert. โจรอาจจะติดอยู่ที่ web server subnet โดยอ่าน database ที่อนุญาตเฉพาะรายการ + ไม่ใช่ทั้ง 51 database

Pattern คลาสสิคที่ 3 เคสบอกตรงกัน#

ทั้ง 3 เคส — Target / Maersk / Equifax — มี pattern เหมือนกัน:

1. Perimeter ไม่ได้พัง — โจรเข้าผ่าน vendor / patch ไม่ทัน / phishing — ไม่ได้ break firewall ขอบเมือง
2. Internal เป็น flat / under-segmented — เมื่อโจรเข้าได้ที่จุดหนึ่ง — เดินทั่วได้
3. ความเสียหายขยายผ่าน east-west traffic = ระดับ enterprise — ไม่ใช่ระดับ user เดียว

ในวงการ — มีคำที่เรียก mindset ใหม่หลังเคสพวกนี้ — “Assume Breach” (จำได้ไหมครับ EP.05) + “Zero Trust Network” + “Microsegmentation by Default”. Defender ทั่วโลกเปลี่ยน mindset หลัง 2017 — แต่บริษัทไทยส่วนใหญ่ยังไม่ตามทัน

555+ ครับ — เคสพวกนี้ผมเล่าให้ฟังเพราะ — ถ้าผู้บริหารยังคิดว่า “เรามี firewall ก็พอ” — แสดงว่ามองไม่เห็น 80% ของ landscape ของ network security ในปี 2026

มุมผู้บริหาร: หลังเคส Target 2013 — วงการ retail + finance ทั่วโลกลงทุนใน vendor risk management + internal segmentation มหาศาล. หลัง NotPetya 2017 — shipping + manufacturing ลงทุนใน regional segmentation + isolated AD per region. หลัง Equifax 2017 — credit bureau + financial data company ลงทุนใน database microsegmentation + east-west monitoring. คำถามสำหรับ board — บริษัทเราอยู่ industry ไหน → industry นั้นมีเคส landmark อะไร → เราเรียนรู้จากเคสนั้นแล้วหรือยัง? — ถ้าคำตอบคือ “ไม่รู้” หรือ “ยังไม่ได้คุย” = agenda item ของ board meeting ครั้งหน้า. เคสจากต่างประเทศ — เป็น free lesson ที่ราคาแพงมากของคนอื่น — เราไม่ต้องจ่ายอีกครั้ง

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

ข้อแรก — flat network = single point of compromise. ถ้า internal network ของบริษัทคุณเป็น flat — โจรเข้าจุดเดียว = ถึงทุกระบบ

นี่คือคำที่ผมอยากให้คุณเอาไปคิดที่สุดของ EP นี้ครับ. ในยุค 1990-2000 — flat network OK เพราะ perimeter เป็นทุกอย่าง. ในปี 2026 — perimeter ทะลุได้ทุกวัน จาก phishing / vendor compromise / zero-day / insider mistake. ถ้า internal ไม่มี กำแพง = breach 1 ครั้ง = breach ทั้งบริษัท

Action plan สำหรับบริษัทไทยขนาดกลาง:

1. ทำ Network Diagram ที่อัปเดต — รู้ก่อนว่ามี subnet/VLAN อะไรบ้าง + ใครคุยกับใคร. ถ้าไม่มี = ขั้นแรกของไตรมาสนี้
2. ตรวจว่ามี DMZ จริงไหม — web/email/VPN server อยู่ subnet แยก จาก database/AD/file server. ถ้าไม่ — highest priority
3. แยก Guest WiFi + IoT + VoIP ออกจาก internal network — บังคับด้วย VLAN + ACL — งบไม่แพง
4. ที่ cloud — review VPC design ของทุก environment — public/private subnet ถูกต้องไหม + Security Group restrictive ไหม + Flow Log เปิดไหม
5. เริ่ม Microsegmentation รอบ Crown Jewel — 5-10 server ที่สำคัญที่สุด — ทำ host-based firewall + allow list policy
6. monitor East-West Traffic — ลงทุนใน tool ที่เห็น traffic ภายใน — ไม่ใช่แค่ขอบเมือง

ทั้ง 6 ข้อ — ส่วนใหญ่ทำได้ในงบของบริษัทขนาดกลาง — แต่ต้องวางแผนเป็นปี

ข้อสอง — Segmentation ลด Blast Radius — เป็น control ที่ ROI สูงที่สุดในยุค ransomware

ลองคิดเป็นเงินครับ. ransomware ในปี 2024-2026 — ของ Sophos / IBM Cost of a Data Breach Report — บริษัทที่โดน ransomware ที่ไม่มี segmentation → mean cost = $4.5M+ (ค่าไถ่ + downtime + recovery). บริษัทที่มี segmentation ดี → mean cost =$1.2M (เพราะ blast radius จำกัด)

ส่วนต่าง $3M+ ต่อเคส. การลงทุนใน segmentation ที่ดี — ทั่วไปอยู่ในงบหลักแสนถึงหลายล้าน — เทียบกับ damage ที่เคสเฉลี่ย = ROI ชัดที่สุดในวงการ security

ในตลาด cyber insurance ของไทยปี 2025 — บริษัทที่มี proven network segmentation + microsegmentation evidence → ได้ premium discount 15-30%. นี่คือ financial value ที่จับต้องได้ทันที