องค์กรไทยส่วนใหญ่ที่เปิด remote work หลังโควิดยังพึ่งพา SSL/IPsec VPN เป็นหลัก ทั้งที่ในวงการ cyber security ทั่วโลก VPN ถูกประกาศว่า "legacy" ตั้งแต่ปี 2021 และ Gartner คาดว่าภายในปี 2025 70% ของ remote access deployment ใหม่จะใช้ ZTNA แทน VPN (จากที่เคยน้อยกว่า 10% ในปี 2021) ตอนนี้ปี 2026 ตัวเลขจริงน่าจะใกล้เคียงคาดการณ์นั้น
VPN กับ ZTNA — เปรียบเทียบให้เห็นภาพ
ถ้า VPN คือ กุญแจห้องอาคารทั้งตึก เพียงล็อกอินเข้ามาแล้ว user มี route ไปทุก subnet ที่ network policy เปิดให้ ZTNA คือ กุญแจที่เปิดเฉพาะห้องที่ user มีสิทธิ์ ณ ช่วงเวลานั้น ตามเงื่อนไข identity + device posture + behavior ในเวลานั้นๆ
| มิติ | Traditional VPN | ZTNA |
|---|---|---|
| Default behavior | Allow LAN, block ที่เหลือ | Deny by default |
| Access scope | ทั้ง subnet หรือทั้ง LAN | เฉพาะแอป-เฉพาะ session |
| Identity model | Username + password (+ MFA) | Identity + device + context + risk |
| Re-authentication | ตอนเริ่ม session | Continuous ระหว่าง session |
| Lateral movement | ทำได้ถ้า credential หลุด | Segmented — แอปไม่เห็นกัน |
| Performance | ผ่าน hub-and-spoke, latency เพิ่ม | Direct-to-app, latency ต่ำกว่า |
VPN trust ผู้ใช้หลังประตูบ้าน ZTNA ไม่เชื่อใจใครแม้จะอยู่ในห้องนอน
ทำไม Cisco, Fortinet, Zscaler, Palo Alto ต่างผลักดัน ZTNA
แต่ละค่ายมีโซลูชันชื่อต่างกัน (Cisco Duo Network Gateway, Fortinet Universal ZTNA, Zscaler Private Access, Palo Alto Prisma Access) แต่หลักการตรงกัน:
- Identity-aware proxy — user ไม่ได้เข้า network จริงๆ แต่เข้าผ่าน broker ที่ตรวจตัวตน
- Device posture check — เครื่องมี EDR ทำงานอยู่ไหม patch ครบไหม disk encryption เปิดไหม
- App-level segmentation — Marketing เปิด CRM ได้ แต่ไม่เห็น File Server ของ Finance แม้แต่ ICMP
- Continuous evaluation — ถ้า user เริ่มดาวน์โหลดข้อมูลผิดปกติ session ถูก downgrade หรือ kill ทันที
ข้อควรพิจารณาก่อน migrate
ในมุมที่ได้เห็นโปรเจกต์ ZTNA migrate ทั้งสำเร็จและล้มเหลว มีจุดที่มัก underestimate:
1. Legacy app ที่ไม่มี modern auth
ระบบ ERP, AS400, accounting รุ่นเก่าหลายตัวยังต้อง bind กับ Active Directory ผ่าน LDAP ตรงๆ ไม่รองรับ SAML/OIDC ZTNA gateway บางตัวรองรับ legacy auth bridging แต่ต้องตั้งค่าระมัดระวัง ไม่งั้นกลายเป็นช่องโหว่ใหม่
2. Third-party / contractor access
VPN เก่ามักให้ guest VPN account อายุ 90 วัน วิธี ZTNA-friendly คือใช้ guest IdP แยก (เช่น Azure External ID, Okta Workforce + Customer Identity) แล้ว provision ต่อแอปแบบ time-bound — แต่ contractor หลายคนยังคุ้นกับ VPN GlobalProtect/AnyConnect การ change management สำคัญพอๆ กับ technical setup
3. Branch office ที่มี on-prem app เยอะ
ZTNA จาก SASE vendor (Zscaler, Cloudflare, Netskope) ทำงานดีกับ SaaS แต่ถ้า data center หลักยังอยู่ on-prem ต้องวาง connector appliance ในแต่ละ branch ไม่งั้น traffic จะวิ่งอ้อมโลก
4. Cost จริงสูงกว่าที่ใบเสนอราคา
License ZTNA คิดต่อ user/เดือน บางครั้งสูงกว่า VPN license หลายเท่า ต้องคิดรวม connector hardware, observability stack, identity provider upgrade, และ internal training เข้าไปด้วย ROI จริงมักมาจาก reduced breach cost ไม่ใช่ direct license saving
Migration strategy ที่ปฏิบัติได้จริง
Phased migration (แนะนำสำหรับองค์กรไทย)
- เดือน 1-2: เปิด ZTNA pilot สำหรับ 1-2 แอปที่ sensitive ที่สุด (เช่น HRIS, Finance ERP) ให้ executive team + IT admin
- เดือน 3-4: ขยายไปยัง back-office apps (HR portal, file share, ticketing) ให้ทุก department
- เดือน 5-6: รวม third-party contractor + branch office
- เดือน 7-12: Decommission VPN concentrator เก่า เก็บไว้แค่ break-glass
Parallel operation
รัน ZTNA และ VPN พร้อมกัน 6-12 เดือน ให้ user เลือกใช้ได้ — ดีตรงไม่ disruptive แต่ต้องวิเคราะห์ log สม่ำเสมอเพื่อไม่ให้ใครหลบไปใช้ VPN เพราะขี้เกียจตั้งค่า ZTNA
สรุปสำหรับผู้ตัดสินใจ
ZTNA ไม่ใช่ "ของใหม่ที่ดีกว่า VPN" แบบ marketing claim มันคือการเปลี่ยน trust model ขององค์กร ซึ่งต้องการ:
- Identity provider ที่แข็งแรง (Azure AD/Entra ID หรือ Okta พร้อม MFA บังคับ 100%)
- Asset inventory ที่ขึ้นกับ CMDB ที่อัปเดต
- ทีม SOC ที่อ่าน log identity + access ได้ทุกวัน
ถ้าสามสิ่งนี้ยังไม่พร้อม การ migrate ZTNA จะให้ผลตรงข้าม — security น้อยลง เพราะ policy ถูกตั้งหลวมๆ เพื่อให้ user ทำงานได้ ดังนั้นก่อนเซ็น PO ใหม่ ลองถามทีมตัวเองว่า "ถ้า IdP ของเราล่ม 30 นาที พนักงานยังทำงานได้ไหม" ถ้าตอบไม่ได้ — ฐานยังไม่พร้อม