ZTNA กับ VPN: เลือกแบบไหนให้เหมาะกับองค์กร

ZTNA กับ VPN เป็นสองวิธีที่ให้คนเข้าถึงระบบขององค์กรจากภายนอก VPN (virtual private network) สร้างอุโมงค์เข้ารหัสให้อุปกรณ์เข้าไปอยู่ในเครือข่ายส่วนตัวขององค์กร ส่วน ZTNA (zero trust network access คือการเข้าถึงแบบไม่เชื่อใจโดยอัตโนมัติ) จะตรวจตัวตนผู้ใช้ อุปกรณ์ และบริบทก่อน แล้วจึงเชื่อมผู้ใช้กับเฉพาะแอปพลิเคชันที่ได้รับอนุญาต ZTNA เป็นส่วนด้านการเข้าถึงเครือข่ายของ Zero Trust Architecture และไม่ใช่ผลิตภัณฑ์ชิ้นเดียว ความหมายจึงต่างกันไปตามผู้ผลิตแต่ละราย องค์กรส่วนใหญ่ไม่เปลี่ยนในวันเดียว คำถามที่ใช้ได้จริงคือจะย้ายแอปไหนก่อน และจะจัดการกับ VPN ที่ยังต้องเหลืออยู่อย่างไร

VPN ทำอะไรได้ดี และติดขัดตรงไหน

NIST SP 800-215 อธิบายว่า VPN เป็นวิธีขยายการป้องกันแบบอิงขอบเขตเครือข่าย (perimeter-based คือป้องกันที่ขอบเครือข่ายแล้วเชื่อใจสิ่งที่อยู่ข้างใน) ให้ครอบคลุมเครือข่ายสาธารณะ โดยสร้างอุโมงค์ปลอดภัยด้วยโปรโตคอลอย่าง IPsec หรือ TLS เมื่ออุโมงค์เชื่อมต่อแล้ว ผู้ใช้จะเสมือนอยู่ในเครือข่ายภายใน และเข้าถึงได้ทุกอย่างที่เครือข่ายกับกฎไฟร์วอลล์อนุญาต โมเดลนี้เรียบง่ายและใช้ได้กับแอปเกือบทุกแบบ NCSC (หน่วยงานด้านความมั่นคงไซเบอร์ของสหราชอาณาจักร) จึงระบุประโยชน์จริงของ VPN ไว้ คือช่วยให้ระบบเก่าใช้งานจากระยะไกลได้ เพิ่มชั้นป้องกันอีกชั้น และบังคับให้ทราฟฟิกผ่านเครื่องมือเฝ้าระวัง

แนวทางชุดเดียวกันชี้ข้อจำกัดของ VPN ไว้ดังนี้

• การเข้าถึงระดับเครือข่าย: ผู้ใช้ที่เชื่อมต่อแล้วมักเข้าถึงได้ทุกอย่างที่เครือข่ายอนุญาต บัญชีที่ถูกขโมยเพียงบัญชีเดียวจึงอาจเปิดทางไปยังระบบมากกว่าที่ผู้ใช้ต้องใช้จริง ทั้งนี้ขึ้นกับการแบ่งส่วนเครือข่าย
• เกตเวย์ที่เปิดสู่อินเทอร์เน็ต: เซิร์ฟเวอร์ VPN ต้องเปิดสู่อินเทอร์เน็ต จึงตกเป็นเป้าหมายของผู้โจมตี เอกสารสรุปของ NSA และ CISA ปี 2021 เตือนเรื่องการขโมยข้อมูลรับรองการเข้าใช้ (credential) การรันโค้ดจากระยะไกล และการแย่ง session ส่วน NCSC ย้ำให้ติดแพตช์โดยเร็ว
• Hair-pinning (ทราฟฟิกต้องวนกลับ): NIST SP 800-215 ระบุว่าทราฟฟิกของผู้ใช้ VPN ที่จะไปใช้บริการคลาวด์ ต้องเข้ามาที่ขอบเครือข่ายองค์กรก่อน แล้วจึงวนออกอินเทอร์เน็ตอีกครั้ง ทำให้ทางเดินไกลขึ้นและ latency (ความหน่วง) สูงขึ้น
• ขนาดและการดูแล: VPN แบบ appliance (อุปกรณ์ฮาร์ดแวร์เฉพาะ) รองรับจำนวนผู้ใช้ได้จำกัด และการแจก client ให้บุคคลภายนอกจำนวนมากทำได้ยาก (NIST SP 800-215) นอกจากนี้ NCSC เตือนว่าหาก VPN ล่ม ทั้งองค์กรอาจทำงานไม่ได้

ZTNA ต่างออกไปอย่างไร

NIST SP 800-207 อธิบายว่าคำขอแต่ละครั้งถูกตัดสินโดย policy engine และ policy administrator (ส่วนประเมินนโยบายและส่วนสั่งการ) จากนั้น policy enforcement point (PEP จุดที่บังคับใช้ผลตัดสิน) จะเปิดการเชื่อมต่อเฉพาะเมื่อผลคืออนุญาต NIST SP 800-215 อธิบาย ZTNA ว่าเป็นรูปแบบการไหลของทราฟฟิกภายใต้แนวคิด zero trust ประกอบด้วย client หรือเบราว์เซอร์ ตัวควบคุมที่ประเมินนโยบาย และเกตเวย์ที่บังคับใช้นโยบาย ผลที่ได้คือผู้ใช้เชื่อมต่อกับแอปทีละตัว ไม่ใช่เชื่อมเข้าทั้งเครือข่าย NIST SP 800-207 ยังระบุว่าทรัพยากรต้องเข้าถึงไม่ได้หากไม่ผ่าน PEP

NIST SP 800-207 อธิบายรูปแบบการติดตั้งหลักไว้สามแบบ

• Device agent/gateway: ลงซอฟต์แวร์ (agent) บนอุปกรณ์ และมีเกตเวย์อยู่หน้าทรัพยากรแต่ละตัว อุปกรณ์จะเชื่อมต่อได้ก็ต่อเมื่อได้รับอนุมัติแล้ว NIST ระบุว่าแบบนี้เหมาะกับองค์กรที่บริหารจัดการอุปกรณ์ได้เข้มแข็ง
• Resource portal: ไม่ต้องลง agent จึงยืดหยุ่นกว่าสำหรับ BYOD (อุปกรณ์ส่วนตัวที่นำมาใช้งาน) และพันธมิตร แต่องค์กรจะเห็นข้อมูลของอุปกรณ์น้อย และตรวจอุปกรณ์ได้เฉพาะตอนที่เชื่อมต่อเท่านั้น
• Enclave: เกตเวย์ตัวเดียวดูแลทรัพยากรทั้งกลุ่ม เช่น data center เหมาะกับแอปเก่าที่ตั้งเกตเวย์แยกรายตัวไม่ได้ แต่ข้อเสียคือป้องกันเป็นกลุ่ม ไม่ใช่ป้องกันรายทรัพยากร

ZTNA ไม่ได้จำกัดสิทธิ์ให้แคบโดยอัตโนมัติ

แค่ใช้ชื่อ ZTNA ก็ไม่ได้รับประกันว่าสิทธิ์จะแคบ ตัวอย่างคือเอกสารของ Microsoft สำหรับผลิตภัณฑ์ ZTNA ของตัวเอง ซึ่งมีโหมด Quick Access ที่เผยแพร่ช่วง IP address กว้าง ๆ เพื่อให้เข้าถึงได้เทียบเท่า VPN และเรียกโหมดนี้ว่าสะพานสำหรับการย้าย ก่อนจะย้ายแอปสำคัญไปเป็นการเข้าถึงรายแอป ภาพด้านล่างเรียงลำดับเพื่ออธิบายให้เห็นภาพเท่านั้น ไม่ใช่ผลการวัดจริง

• เป็นจุดพึ่งพาสำคัญใหม่: ตัวตัดสินนโยบายและจุดบังคับใช้จะกลายเป็นส่วนสำคัญของการทำงานทุกอย่าง NIST SP 800-207 เตือนเรื่อง DoS (การโจมตีให้ระบบใช้งานไม่ได้) และแนะนำให้โฮสต์ในคลาวด์ที่ปลอดภัยหรือทำสำเนาไว้หลายตำแหน่ง วิธีนี้ลดความเสี่ยงได้ แต่ไม่ได้ทำให้หมดไป
• บางแอปอาจไม่เข้ากัน: ก่อนสัญญาว่าจะย้ายเมื่อไร ให้ตรวจว่า ZTNA รองรับโปรโตคอลของแอปหรือไม่ รวมถึง UDP และทราฟฟิกที่เริ่มต้นจากฝั่งเซิร์ฟเวอร์
• ต้องรู้จักแอปของตัวเอง: นโยบายรายแอปต้องมีบัญชีรายการแอปเป็นฐาน Microsoft มีรายงาน application discovery (ค้นหาแอปที่มีการใช้งานอยู่) ไว้ช่วยในกรณีที่บัญชีรายการไม่ครบ
• ความเสี่ยงที่ endpoint ยังอยู่: เครื่องที่ถูกยึดแต่ผ่านการยืนยันตัวตนแล้ว ยังใช้แอปที่ตนมีสิทธิ์เข้าถึงในทางที่ผิดได้ ZTNA ช่วยจำกัดความเสียหาย แต่ไม่ได้ทำให้หมดไป
• ตำแหน่งประมวลผลและการเก็บ log: ควรถามผู้ผลิตว่าทราฟฟิกถูกประมวลผลที่ไหน และ log ถูกเก็บที่ไหน

เลือกแบบไหนดี

• แอปส่วนใหญ่อยู่บนคลาวด์หรือเป็น SaaS และมีผู้ใช้ระยะไกลหรือบุคคลภายนอกมาก: เริ่มที่ ZTNA NIST SP 800-207 ระบุว่ากระบวนการทำงานที่ใช้ทรัพยากรบนคลาวด์ หรือรองรับผู้ทำงานระยะไกล มักเป็นตัวเลือกแรกที่เหมาะจะเริ่ม และ client ขอใช้บริการคลาวด์ได้โดยตรง ไม่ต้องเข้ามาทาง VPN
• ระบบเก่า เครือข่ายภายในแบบแบน ลิงก์ site-to-site หรือโปรโตคอลที่ proxy รายแอปไม่ได้: ควรคง VPN ที่เสริมความแข็งแรงแล้วไว้ หรือใช้ enclave gateway เครือข่ายแบนคือเครือข่ายที่ไม่ได้แบ่งส่วนภายใน ส่วนลิงก์ site-to-site คือลิงก์ที่เชื่อมเครือข่ายสองแห่งเข้าหากัน NCSC ระบุว่า VPN ช่วยให้ระบบเก่าใช้งานจากระยะไกลได้
• ผู้รับเหมาและอุปกรณ์ที่องค์กรไม่ได้บริหาร: ให้เข้าผ่าน portal หรือแบบ agentless (ไม่ต้องลงซอฟต์แวร์บนเครื่อง) โดยจำกัดเฉพาะเว็บแอปที่จำเป็น และพิจารณา browser isolation (เปิดเว็บในสภาพแวดล้อมที่แยกจากเครื่องของผู้ใช้) ซึ่ง NIST เสนอเป็นมาตรการชดเชยเมื่อองค์กรมองเห็นอุปกรณ์ได้จำกัด
• ทีมเล็ก แอปไม่กี่ตัว: VPN ที่เสริมความแข็งแรง มี MFA (การยืนยันตัวตนหลายขั้นตอน) และแบ่งส่วนเครือข่ายอาจเพียงพอแล้ว ประโยชน์ของ ZTNA จะเพิ่มขึ้นเมื่อแอปและผู้ใช้เพิ่มขึ้น

รูปแบบที่พบบ่อยคือใช้ทั้งสองอย่างควบคู่กันช่วงหนึ่ง โดยใช้ ZTNA กับผู้ใช้และแอปส่วนใหญ่ และเก็บ VPN ที่แข็งแรงไว้สำหรับข้อยกเว้น ซึ่งจะค่อย ๆ ลดลงตามเวลา NCSC ระบุว่าเมื่อใช้ zero trust ครบถ้วนแล้ว VPN แทบไม่เหลือประโยชน์ เป้าหมายจึงเป็นการเลิกใช้ VPN ทีละข้อยกเว้น หากต้องการรวมความปลอดภัยด้านเว็บและคลาวด์ไว้ในบริการเดียวกัน ให้ดู SASE และ SSE คืออะไร ใช้เมื่อไรจึงเหมาะ ซึ่งมักรวม ZTNA ไว้ด้วย

ย้ายจาก VPN สู่ ZTNA ตามลำดับ

ลำดับที่ช่วยลดความเสี่ยงเริ่มจากรู้ก่อนว่าองค์กรใช้อะไรอยู่จริง แล้วแก้พื้นฐานด้านตัวตนและอุปกรณ์ จากนั้นทดลองกับกลุ่มเล็ก ใช้ควบคู่กับ VPN และสุดท้ายค่อย ๆ จำกัดสิทธิ์ให้แคบลงตามข้อมูลการใช้งานจริง ลำดับนี้ตรงกับ NIST SP 800-207 ที่แนะนำให้เริ่มจากกระบวนการธุรกิจที่ความเสี่ยงต่ำก่อน แล้วค่อยขยาย บทความ MFA แบบไหนปลอดภัยกว่ากัน ช่วยเลือกวิธียืนยันตัวตนสำหรับขั้นที่สอง

ถ้าต้องคง VPN ไว้ ให้เสริมความแข็งแรง

• เลือกผลิตภัณฑ์ที่ยึดมาตรฐาน: เอกสารสรุปของ NSA และ CISA ปี 2021 แนะนำให้เลือก VPN ที่ยึดมาตรฐานเปิด แทนผลิตภัณฑ์ที่ใช้เทคโนโลยีเฉพาะของผู้ผลิตรายเดียว
• ติดแพตช์ให้เร็ว: NCSC ย้ำว่าบริการ VPN เปิดสู่อินเทอร์เน็ต และแนวทางด้านอุปกรณ์ขอบเครือข่าย (edge device) ปี 2025 ที่ CISA ร่วมเผยแพร่ ก็ครอบคลุม VPN gateway ด้วย
• ใช้ IPsec และใบรับรอง: NCSC แนะนำ IPsec ยอมรับ TLS VPN ได้ และให้ใช้ใบรับรอง (certificate) แทน pre-shared key (รหัสลับที่ตั้งร่วมกันล่วงหน้า)
• ส่งทราฟฟิกทั้งเครื่องผ่าน VPN ไม่ใช้ split tunnelling: split tunnelling คือการให้ทราฟฟิกบางส่วนออกอินเทอร์เน็ตโดยไม่ผ่าน VPN NCSC แนะนำให้ใช้ client ที่มากับระบบปฏิบัติการ และตั้งให้เชื่อมต่อแบบบังคับและอัตโนมัติ
• เพิ่ม MFA และเลือกชนิดที่ทนต่อฟิชชิง (phishing) เมื่อทำได้
• ทดสอบกรณีล้มเหลว: NCSC แนะนำให้ทดสอบความทนทานของ VPN และวางทางสำรองไว้

ขั้นแรกที่ทำได้ทันที

• ทำบัญชีรายชื่อผู้ใช้ VPN: ระบุว่าใครใช้ อยู่กลุ่มไหน และเมื่อต่อ VPN แล้วแต่ละกลุ่มเข้าถึงอะไรได้บ้างตามกฎไฟร์วอลล์
• จัดอันดับแอปสิบตัวแรก: จัดตามจำนวนผู้ใช้และความสำคัญ แล้วแยกว่าตัวไหนเป็นเว็บหรือ SaaS ซึ่งย้ายง่ายที่สุด
• ตรวจ VPN gateway: ดูเวอร์ชัน สถานะการติดแพตช์ และว่า MFA ครอบคลุมผู้ใช้ครบหรือไม่
• ปิดบัญชีและสิทธิ์ที่ไม่ได้ใช้: ช่วยลดสิ่งที่ผู้โจมตีนำไปใช้ได้ ไม่ว่าจะย้ายไป ZTNA หรือไม่
• เลือกโครงการนำร่อง: หนึ่งแอป หนึ่งกลุ่มผู้ใช้ เช่น ผู้รับเหมา

หากต้องการดูว่าการเข้าถึงเครือข่ายขององค์กรอยู่ตรงไหนเมื่อเทียบกับช่องว่างด้านอื่นของ zero trust ลองใช้ แบบประเมินตนเอง และใช้ การแบ่งส่วนเครือข่าย เพื่อลดสิ่งที่ผู้ใช้ VPN เข้าถึงได้ระหว่างที่กำลังย้าย

ข้อผิดพลาดที่พบบ่อย

• มองว่า ZTNA คือ VPN ที่เปลี่ยนชื่อ: ถ้าเผยแพร่ซับเน็ตทั้งช่วง (ช่วงที่อยู่ IP ของเครือข่ายหนึ่งวง) แล้วเรียกว่า ZTNA ผู้ใช้ก็ยังเข้าถึงได้กว้างแบบไม่แบ่งส่วนเหมือนเดิม
• ย้ายทุกอย่างพร้อมกัน: ถ้าจุดตัดสินใจหรือเกตเวย์มีปัญหา ทุกคนจะเข้าใช้งานไม่ได้พร้อมกัน
• ไม่สนใจสัญญาณตัวตนและอุปกรณ์: นโยบายดีได้เท่ากับสัญญาณที่ป้อนให้ ดังนั้นต้องมี MFA และข้อมูลสถานะของอุปกรณ์
• ปล่อย VPN เก่าเปิดค้างไว้: เกตเวย์ที่ไม่มีใครดูแลยังเป็นเส้นทางโจมตีได้ ควรปิดหรือจำกัดการใช้งานเมื่อย้ายแอปแล้ว
• ข้ามเรื่องความพร้อมใช้งาน: ควรวางทางสำรอง และบัญชีฉุกเฉิน (break-glass account) ไว้สำหรับวันที่ผู้ให้บริการขัดข้อง
• ลืมบุคคลภายนอกและอุปกรณ์ที่ไม่ได้บริหาร: คนกลุ่มนี้ต้องมีเส้นทางเข้าใช้งานที่ต่างจากพนักงาน และมีข้อจำกัดเข้มกว่า

เกตเวย์ VPN เปิดสู่อินเทอร์เน็ต จึงควรจัดลำดับการ patch ด้วยข้อมูลการถูกโจมตีจริง ดู CVSS, EPSS และ CISA KEV: จัดลำดับการแก้ช่องโหว่อย่างไร

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-207: Zero Trust Architecture: นิยาม องค์ประกอบ และรูปแบบการติดตั้ง
• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape: ข้อจำกัดของการเข้าถึงด้วย VPN รวมถึงเนื้อหาเรื่อง ZTNA, SDP และ SASE
• NCSC: Zero trust architecture design principles: หลักการออกแบบ zero trust ของสหราชอาณาจักร
• NCSC: Virtual private networks (VPNs): ประโยชน์ ความเสี่ยง และการตั้งค่า VPN ที่แนะนำ
• CISA and NSA: Guidance on Selecting and Hardening VPNs (2021): ประกาศที่เผยแพร่เอกสารสรุปเรื่องการเลือกและเสริมความแข็งแรงให้ VPN
• CISA and partners: Modern Approaches to Network Access Security (2024): เสนอให้ย้ายไปสู่ Zero Trust, SSE และ SASE
• CISA and partners: guidance on edge devices (2025): แนวทางป้องกันอุปกรณ์ขอบเครือข่าย รวมถึง VPN gateway
• Microsoft Learn: VPN replacement with Quick Access: ตัวอย่างเอกสารจากผู้ผลิต โดยย้ายแบบเทียบเท่า VPN ก่อน แล้วค่อยจำกัดให้แคบลงเป็นรายแอป
• Zscaler: What is ZTNA?: ตัวอย่างมุมมองของผู้ผลิตรายหนึ่งเรื่อง ZTNA เทียบกับ VPN ควรอ่านโดยตระหนักว่าเป็นข้อกล่าวอ้างของผู้ขาย