ZTNA กับ VPN เหมาะกับองค์กรแบบไหน

เมื่อต้องตัดสินใจว่าพนักงาน ผู้รับเหมา หรือแม้แต่ตัวคุณเองควรเข้าระบบภายในจากข้างนอกอย่างไร คำถามเรื่อง ZTNA vs VPN จะโผล่มาเร็วมาก ทั้งสองแนวทางสร้างเส้นทางที่ปลอดภัยไปยังสิ่งที่เป็นส่วนตัวเหมือนกัน ความต่างอยู่ที่ว่าเมื่ออยู่บนเส้นทางนั้นแล้ว คุณได้รับความไว้วางใจแค่ไหน VPN มักไว้ใจให้คุณเข้า "เครือข่าย" ส่วน ZTNA หรือ Zero Trust Network Access ไว้ใจให้เข้า "แอปพลิเคชัน" ทีละตัว

บทความนี้เขียนจากมุมของคนที่ต้องเลือกซื้อหรือวางระบบ ไม่ได้อธิบายแนวคิดซีโร่ทรัสต์ซ้ำ เพราะมีอธิบายไว้แล้วใน Zero Trust กับ VPN ต่างกันอย่างไร ที่นี่เราโฟกัสการตัดสินใจจริง คือแต่ละแบบให้สิทธิ์อะไร ต้องดูแลอย่างไร มีตัวอย่างบริษัทขนาดกลาง เช็กลิสต์ช่วยเลือก และเส้นทางย้ายระบบที่ไม่ทำให้งานสะดุด

ความต่างที่แท้จริง คือสิ่งที่คุณได้รับหลังเชื่อมต่อ

ถ้าตัดชื่อผลิตภัณฑ์ออกให้หมด ความต่างหลักอยู่ที่ "หน่วยของสิทธิ์การเข้าถึง"

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

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

ผลที่ตามมามี 2 อย่าง

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

NIST อธิบายรูปแบบนี้ไว้ในเอกสารสถาปัตยกรรมซีโร่ทรัสต์ โดยมีจุดตัดสินนโยบายและจุดบังคับใช้นโยบายคั่นระหว่างผู้ใช้กับทรัพยากรแต่ละตัว

VPN ให้สิทธิ์เข้าถึงในทางปฏิบัติอย่างไร

ควรพูดถึงฝั่ง VPN ให้เป็นรูปธรรม เพราะจุดอ่อนหลายอย่างเป็นเรื่องการปฏิบัติงานมากกว่าตัวเทคโนโลยี

การตั้งค่าทั่วไปประกอบด้วยเกตเวย์ที่มีที่อยู่สาธารณะ กลุ่มที่อยู่ภายในสำหรับผู้ใช้ระยะไกล และนโยบายไฟร์วอลล์ ขั้นตอนที่ทีมส่วนใหญ่ทำมีดังนี้

1. สร้างบัญชีผู้ใช้ มักผูกกับระบบไดเรกทอรีขององค์กร
2. แจกโปรไฟล์ไคลเอนต์หรือใบรับรองให้แต่ละเครื่อง
3. กำหนดว่าผู้ใช้ระยะไกลเข้าซับเน็ตภายในใดได้บ้าง
4. ตัดสินใจว่าจะส่งทราฟฟิกทั้งหมดผ่านอุโมงค์หรือเฉพาะทราฟฟิกของบริษัท
5. ทบทวนกฎเมื่อมีอะไรพัง และบ่อยครั้งไม่ทบทวนเลยหากไม่มีปัญหา

ขั้นตอนสุดท้ายคือจุดที่ปัญหาสะสม ผู้รับเหมาที่ต้องใช้ฐานข้อมูลแค่สองสัปดาห์ยังเข้าได้อยู่หนึ่งปีต่อมา เพราะไม่มีใครจดวันหมดอายุไว้ แล็ปท็อปของนักพัฒนาที่ซอฟต์แวร์เก่ามากก็ยังต่อได้ ตราบใดที่รหัสผ่านถูกต้อง VPN บังคับกฎที่แคบได้ดี แต่กฎที่แคบต้องอาศัยแรงดูแลสม่ำเสมอ

ข้อดีของ VPN คือเข้าใจง่าย มีอุโมงค์เดียว เกตเวย์เดียว และที่เดียวให้ดู แอปที่คุยผ่าน IP ได้ล้วนใช้งานได้ รวมถึงเครื่องพิมพ์ ซอฟต์แวร์เก่าเฉพาะทาง และไฟล์แชร์ที่คาดหวังว่าอยู่เครือข่ายเดียวกัน ถ้าอยากทบทวนว่าเส้นทางที่เข้ารหัสคืออะไร ดูได้ที่ อุโมงค์ VPN คืออะไร

ZTNA ให้สิทธิ์เข้าถึงในทางปฏิบัติอย่างไร

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

ทั้งสองรูปแบบมีลำดับคร่าว ๆ ดังนี้

1. ผู้ใช้ล็อกอินผ่านระบบตัวตนขององค์กร พร้อมการยืนยันหลายขั้นตอน
2. โบรกเกอร์ตรวจสภาพอุปกรณ์ เช่น เปิดการเข้ารหัสดิสก์ไว้หรือไม่ และอัปเดตระบบปฏิบัติการแล้วหรือยัง
3. นโยบายตัดสินว่าผู้ใช้คนนี้ บนอุปกรณ์เครื่องนี้ ในเวลานี้ เข้าแอปนี้ได้หรือไม่
4. มีการสร้างการเชื่อมต่อชั่วคราวเฉพาะแอปผ่านคอนเนคเตอร์ ทำให้ตัวแอปเองไม่ต้องเปิดพอร์ตขาเข้า
5. เซสชันถูกบันทึก และยุติจากส่วนกลางได้

จุดน่าสนใจคือแอปซ่อนจากอินเทอร์เน็ตได้โดยไม่ต้องเปิดเกตเวย์ VPN ไว้ ราคาที่ต้องจ่ายคือมีคนต้องเขียนนโยบายทีละแอป และแอปที่ไม่เข้ากับโมเดลนี้ต้องหาทางอ้อม

เปรียบเทียบเคียงข้างกันสำหรับผู้ตัดสินใจซื้อ

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

แถวสุดท้ายควรอ่านอย่างจริงจัง ZTNA ไม่ได้กำจัดจุดล้มเหลวจุดเดียว แต่ย้ายมันไปที่อื่น ถ้าระบบตัวตนล่ม ไม่มีใครเข้าได้ ในขณะที่ VPN ที่มีบัญชีท้องถิ่นอาจยังใช้ได้

ตัวอย่างจริง บริษัทออกแบบ 60 คน

ลองนึกถึงเอเจนซี่ออกแบบที่มีพนักงาน 60 คน 30 คนมาออฟฟิศเกือบทุกวัน 20 คนทำงานระยะไกลเต็มเวลา และอีก 10 คนเป็นฟรีแลนซ์ที่เข้า ๆ ออก ๆ ระบบของบริษัทมีเครื่องมือจัดการโปรเจกต์บนคลาวด์ ไฟล์เซิร์ฟเวอร์ในออฟฟิศ แอปบัญชีบนเซิร์ฟเวอร์เล็ก ๆ และรีโมตเดสก์ท็อปไปยังเครื่องเรนเดอร์แรง ๆ สองเครื่อง

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

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

ใช้ทั้งสองอย่าง เอเจนซี่เก็บ VPN ขนาดเล็กไว้สำหรับไฟล์เซิร์ฟเวอร์และเครื่องมือรุ่นเก่า จำกัดให้กลุ่มเล็ก ๆ บนแล็ปท็อปที่บริษัทดูแล ส่วนที่เหลือย้ายไปเป็นการเข้าถึงแบบรายแอป กฎของ VPN เหลือน้อยและตรวจทานง่าย ส่วนกลุ่มเสี่ยงสูงอย่างฟรีแลนซ์ไม่ต้องแตะ VPN เลย

ตัวอย่างนี้ไม่ได้พิเศษอะไร ผลลัพธ์แบบผสมพบบ่อย เพราะองค์กรจริงมักมีแอปอย่างน้อยหนึ่งตัวที่ไม่เข้ากับโมเดลใหม่

เช็กลิสต์ช่วยตัดสินใจ

ตอบคำถามเหล่านี้ตามจริง รูปแบบของคำตอบสำคัญกว่าข้อใดข้อหนึ่ง

1. แอปของคุณอยู่ที่ไหน ถ้าส่วนใหญ่อยู่บนคลาวด์หรือมีหน้าเว็บ ZTNA เข้ากันได้ดี ถ้าส่วนใหญ่เป็นโปรแกรมเดสก์ท็อปรุ่นเก่าที่ต้องการอยู่เครือข่ายเดียวกัน VPN ง่ายกว่า
2. มีระบบตัวตนกลางพร้อมการยืนยันหลายขั้นตอนหรือยัง ZTNA ตั้งสมมติฐานว่ามี ถ้ายังไม่มี ให้แก้ก่อน ไม่ว่าจะเลือกโมเดลไหน แนวทางเรื่องการยืนยันหลายขั้นตอนของ CISA เป็นจุดเริ่มต้นที่ดี
3. อธิบายงานของแต่ละคนเป็นรายแอปได้ไหม ถ้าระบุได้คร่าว ๆ ว่าแต่ละทีมใช้เครื่องมือห้าตัวไหน นโยบายรายแอปก็ทำได้จริง ถ้าไม่มีใครรู้ สุดท้ายก็ต้องเปิดทุกอย่างอยู่ดี
4. ใครคือผู้ใช้ที่เสี่ยงที่สุด ผู้รับเหมา ผู้ขาย และพนักงานที่ใช้อุปกรณ์ที่ไม่ได้ดูแล ได้ประโยชน์สูงสุดจากสิทธิ์ที่แคบ
5. จ่ายค่าแรงแอดมินต่อเดือนได้กี่ชั่วโมง ZTNA ใช้แรงเยอะตอนแรก ส่วน VPN กระจายแรงออกไปแล้วปล่อยให้กฎเสื่อมสภาพ
6. ถ้าบัญชีหนึ่งถูกขโมย จะเสียหายแค่ไหน ถ้าตอบว่า "ไม่มาก เพราะแยกส่วนไว้แล้ว" VPN ก็น่าจะเพียงพอ ถ้าตอบว่า "เสียหมด" ควรให้ความสำคัญกับสิทธิ์ที่แคบลงก่อน
7. มีข้อกำหนดด้านการทบทวนสิทธิ์หรือไม่ บันทึกระดับแอปทำให้การทบทวนง่ายขึ้น

ถ้าคำตอบส่วนใหญ่เป็นคลาวด์ เว็บ ระบบตัวตนดี และข้อมูลละเอียดอ่อน ให้เอนไปทาง ZTNA ถ้าเป็นระบบเก่า ทีมเล็ก และเซิร์ฟเวอร์ออฟฟิศตัวเดียว VPN ที่ดูแลดีก็เป็นตัวเลือกที่สมเหตุสมผล

ย้ายจาก VPN ไปสู่ ZTNA โดยไม่ให้งานสะดุด

การตัดเปลี่ยนแบบกะทันหันคือวิธีที่เร็วที่สุดที่จะทำให้ทุกคนเข้าระบบไม่ได้ในเช้าวันจันทร์ แนวทางทีละขั้นนิ่มนวลกว่ามาก

1. ทำบัญชีรายการ ไล่ดูแอปภายในทุกตัว โปรโตคอลที่ใช้ และใครต้องใช้ รายการนี้คือผลงานที่มีค่าที่สุดของโครงการ
2. ปรับ VPN ให้รัดกุมก่อน เปลี่ยนจากสิทธิ์ทั้งซับเน็ตเป็นแยกตามกลุ่ม ลบบัญชีที่ไม่ตรงกับคนจริงแล้ว ขั้นนี้ลดความเสี่ยงได้ทันที และได้นโยบายที่นำไปใช้ต่อ
3. ทดลองกับแอปความเสี่ยงต่ำ เผยแพร่แอปบนเว็บหนึ่งตัวผ่าน ZTNA ให้ทีมหนึ่งใช้หนึ่งเดือน
4. ย้ายผู้รับเหมาก่อน เพราะเสี่ยงสุดและให้สิทธิ์ผ่านเบราว์เซอร์ได้ง่ายสุด
5. ย้ายส่วนที่เหลือตามกลุ่มแอป เก็บ VPN ไว้สำหรับสิ่งที่ทดสอบแล้วไม่ผ่าน
6. ทบทวนทุกไตรมาส ลบนโยบายเก่า นโยบายที่ไม่มีใครดูก็เสื่อมเหมือนกฎไฟร์วอลล์

โมเดลความพร้อมซีโร่ทรัสต์ของ CISA ช่วยประเมินว่าตอนนี้อยู่ตรงไหนบนเส้นทางนี้ เพราะอธิบายเป็นระดับขั้น ไม่ได้บังคับให้กระโดดครั้งเดียว

ข้อจำกัดและความผิดพลาดที่ควรเลี่ยง

ZTNA ไม่ใช่ป้ายวิเศษ ระวังเรื่องเหล่านี้

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

ขณะเดียวกัน ความผิดพลาดฝั่ง VPN ก็ยังคุ้นเคย เช่น ใช้บัญชีร่วมทั้งทีม ไม่ตั้งวันหมดอายุให้ผู้รับเหมา และไม่เคยอัปเดตเกตเวย์ คำแนะนำด้านความปลอดภัยการทำงานทางไกลของ NIST รวบรวมวิธีปฏิบัติที่ดีไว้ใช้ได้กับทั้งสองแนวทาง

แล้วบุคคลทั่วไปและทีมเล็กอยู่ตรงไหน

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

สรุป

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

ถ้าสิ่งที่คุณต้องการคือ VPN ส่วนตัวง่าย ๆ สำหรับอุปกรณ์ของคุณเอง ไม่ใช่ระบบเข้าถึงขององค์กร คุณสามารถดูหน้าราคาได้ตามสบาย