SASE กับ VPN ต่างกันอย่างไร

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

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

SASE รวมอะไรไว้บ้าง พูดให้เข้าใจง่าย

SASE หรือ Secure Access Service Edge ถูกตั้งชื่อเป็น "รูปแบบ" มากกว่าเป็นผลิตภัณฑ์เดียว แนวคิดคือย้ายเครือข่ายและความปลอดภัยออกจากห้องเซิร์ฟเวอร์ในออฟฟิศ ไปเป็นบริการที่ทำงานในหลายจุดบนคลาวด์ใกล้ตัวผู้ใช้ ในทางปฏิบัติ บริการหนึ่งมักรวมบางส่วนหรือทั้งหมดของรายการนี้

• เครือข่ายพื้นที่กว้าง การเชื่อมระหว่างสาขา ศูนย์ข้อมูล และคลาวด์ มักใช้ SD-WAN ถ้าสนใจเฉพาะส่วนนี้ ก็มีการเปรียบเทียบกับ VPN แยกต่างหาก
• เกตเวย์เว็บที่ปลอดภัย กรองและตรวจสอบทราฟฟิกเว็บ บล็อกเว็บอันตรายที่รู้จัก และบังคับกฎการใช้งาน
• การควบคุมแอปคลาวด์ มองเห็นว่าพนักงานใช้แอปคลาวด์ตัวไหน และทำอะไรในนั้น
• การเข้าถึงแบบ Zero Trust ให้สิทธิ์รายแอป แทนที่จะให้ทั้งเครือข่าย
• ไฟร์วอลล์บนคลาวด์ กฎไฟร์วอลล์ที่ส่งมอบเป็นบริการ ไม่ใช่กล่องในตู้
• การป้องกันข้อมูลรั่วไหล กฎที่ตรวจจับเนื้อหาละเอียดอ่อนที่หลุดออกไปทางเบราว์เซอร์หรือการอัปโหลด

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

เส้นทางของทราฟฟิกต่างกันอย่างไร

วิธีที่ชัดที่สุดในการเข้าใจความต่างทางสถาปัตยกรรม คือตามดูแพ็กเก็ตหนึ่งตัว

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

VPN แบบแยกอุโมงค์ พนักงานเข้าระบบภายในผ่าน VPN ส่วนทราฟฟิกอื่นออกอินเทอร์เน็ตโดยตรง เร็วกว่าสำหรับเครื่องมือบนคลาวด์ แต่ไฟร์วอลล์ออฟฟิศไม่เห็นทราฟฟิกนั้นอีก การป้องกันจึงต้องย้ายไปอยู่ที่ตัวแล็ปท็อป แนวคิดนี้อธิบายไว้ใน การแยกอุโมงค์ (split tunneling) คืออะไร

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

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

ภาพรวมเปรียบเทียบเคียงข้างกัน

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

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

ตัวอย่างจริง บริษัทขนส่งระดับภูมิภาค

ลองนึกถึงบริษัทขนส่งที่มีสำนักงานใหญ่ 1 แห่ง คลังสินค้า 8 แห่ง พนักงาน 120 คน และคนขับที่ใช้โทรศัพท์มากขึ้นเรื่อย ๆ ระบบของบริษัทคือเครื่องมือจัดการการขนส่งบนคลาวด์ ชุดอีเมลและเอกสารบนคลาวด์ และระบบคลังสินค้ารุ่นเก่าที่ทำงานอยู่ในสำนักงานใหญ่

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

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

สิ่งที่เปลี่ยนในทางปฏิบัติ

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

สิ่งที่ไม่เปลี่ยน ถ้าระบบคลังสินค้าช้าอยู่แล้ว SASE ไม่ช่วยแก้ ถ้าบัญชีของคนขับถูกหลอกเอารหัสผ่าน SASE ช่วยจำกัดความเสียหายได้ แต่ป้องกันความผิดพลาดนั้นไม่ได้

สิ่งที่คุณต้องยอมแลก

การซื้อชุดรวมคือการแลกเปลี่ยน ควรรู้ให้ชัดว่าต้องเสียอะไร

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

ทั้งหมดนี้ไม่ได้ทำให้ SASE เป็นความคิดที่แย่ แต่ทำให้เป็นการตัดสินใจที่มีราคา

เมื่อ VPN ยังเป็นคำตอบที่ถูกต้อง

VPN ทั้งแบบเข้าระบบจากระยะไกลและแบบเชื่อมระหว่างสถานที่ ยังเหมาะสมเมื่อ

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

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

คำถามที่ควรถามผู้ให้บริการ

ถ้าตัดสินใจจะดูข้อเสนอ SASE ให้เตรียมรายการคำถามสั้น ๆ ไปถาม อย่าพึ่งแค่ชุดสไลด์

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

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

วิธีนำมาใช้ทีละขั้น โดยไม่ต้องเปลี่ยนทั้งหมดในครั้งเดียว

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

โมเดลความพร้อมซีโร่ทรัสต์ของ CISA ช่วยตัดสินว่าด้านไหนควรทำก่อน

ความผิดพลาดที่พบบ่อย

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

สรุป

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

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