SASE (secure access service edge) คือการรวมเครือข่ายกับระบบรักษาความปลอดภัยเป็นบริการเดียวที่ให้บริการผ่านคลาวด์ ฝั่งเครือข่ายหลักคือ SD-WAN (เครือข่ายส่วนกว้างที่บริหารด้วยซอฟต์แวร์ ใช้เชื่อมสาขาและผู้ใช้เข้ากับแอป) ฝั่งความปลอดภัยมีบริการอย่าง secure web gateway (ตรวจและกรองการใช้เว็บ) cloud access security broker (ควบคุมการใช้บริการคลาวด์แบบ SaaS ซึ่งเป็นซอฟต์แวร์ที่เช่าใช้ผ่านอินเทอร์เน็ต) และ ZTNA (ให้ผู้ใช้เข้าถึงแอปภายในที่ไม่เปิดสู่สาธารณะเป็นรายแอป) ส่วน SSE (security service edge) คือเฉพาะครึ่งด้านความปลอดภัยของชุดนี้ ไม่รวมส่วนเครือข่าย ตาม NIST SP 800-215 Gartner เป็นผู้บัญญัติคำว่า SASE ในปี 2019 ส่วนคำว่า SSE มีสื่อสายเทคโนโลยีรายงานว่า Gartner เริ่มใช้ในปี 2021 ทั้งสองชื่อหมายถึงชุดบริการ ไม่ใช่ผลิตภัณฑ์ชิ้นเดียว ผู้ผลิตแต่ละรายจึงใส่ส่วนประกอบไม่เหมือนกัน บทความนี้อธิบายว่าข้างในมีอะไร SSE กับ SASE ต่างกันอย่างไร และแต่ละแบบเหมาะกับกรณีใด

คำว่า SASE และ SSE มาจากไหน

ในปี 2019 Gartner ใช้คำว่า SASE เรียกสถาปัตยกรรมที่รวมฟังก์ชันเครือข่ายกับความปลอดภัยเข้าด้วยกัน และให้บริการทั่วโลกผ่านคลาวด์ NIST SP 800-215 ชี้ว่าบริการแต่ละอย่างในชุดนี้ไม่ใช่ของใหม่ สิ่งที่ต่างคือส่งมอบรวมเป็นแพ็กเกจเดียว แทนที่จะเป็นอุปกรณ์แยกชิ้น คำว่า SSE ตามมาทีหลัง สื่อที่รายงานแผนที่นำทาง (roadmap) ปี 2021 ของ Gartner เรื่องการรวม SASE ระบุว่า Gartner แยกบริการความปลอดภัยออกมาเป็นหมวดของตัวเอง และ SSE ก็คือ SASE ที่ไม่มี SD-WAN ทั้งสองคำเป็นหมวดที่นักวิเคราะห์กำหนดขึ้น ไม่ใช่มาตรฐาน คำนิยามของผู้ผลิตแต่ละรายจึงอาจไม่ตรงกับของ Gartner

ข้างในมีอะไรบ้าง

คำอธิบายส่วนใหญ่มีแกนกลางร่วมกัน ดังนี้

  • SD-WAN (software-defined WAN): ส่วนเครือข่าย ทำหน้าที่เชื่อมสาขาและผู้ใช้เข้ากับแอปผ่านเครือข่ายแบบใดก็ได้ และกำหนดนโยบายการเลือกเส้นทางกับการเข้าถึงจากส่วนกลาง (NIST SP 800-215)
  • SWG (secure web gateway): ตรวจและกรองทราฟฟิกเว็บเพื่อหาภัยคุกคาม และบังคับใช้นโยบาย
  • CASB (cloud access security broker): บังคับใช้นโยบายระหว่างผู้ใช้กับบริการคลาวด์แบบ SaaS
  • ZTNA: ให้เข้าถึงแอปภายในเป็นรายแอป ดู ZTNA กับ VPN: เลือกแบบไหนให้เหมาะกับองค์กร
  • FWaaS (firewall as a service): ไฟร์วอลล์ที่ให้บริการบนคลาวด์ ใช้แทนอุปกรณ์ไฟร์วอลล์จริงได้บางส่วน
  • ส่วนเสริม: DLP (data loss prevention ระบบป้องกันข้อมูลสำคัญรั่วออกนอกองค์กร) browser isolation (เปิดเว็บในพื้นที่แยกจากเครื่องผู้ใช้) sandbox (พื้นที่แยกสำหรับทดลองรันไฟล์น่าสงสัย) และการประเมินความเสี่ยงอย่างต่อเนื่อง NIST ระบุว่าบริการด้านความปลอดภัยขั้นต่ำที่พบในข้อเสนอ SASE เชิงพาณิชย์ส่วนใหญ่ คือไฟร์วอลล์ SWG anti-malware IPS (ระบบป้องกันการบุกรุก) CASB และ DLP
INFOGRAPHIC
SASE ประกอบด้วยอะไร และ SSE คือส่วนไหน
SASE
SSE คือส่วนความปลอดภัย ส่วน FWaaS แล้วแต่ผู้ผลิต
SD-WAN
ส่วนเครือข่าย: สาขาและเส้นทาง
SWG
กรองและตรวจทราฟฟิกเว็บ
CASB
ควบคุมนโยบายและข้อมูลบน SaaS
ZTNA
เข้าถึงแอปภายในเป็นรายแอป
FWaaS
ไฟร์วอลล์บนคลาวด์

นิยามของแต่ละที่ต่างกันตรงขอบเขต รายงานเรื่องนิยามของ Gartner ระบุว่า SWG, CASB และ ZTNA เป็นส่วนที่ SSE ต้องมี ส่วน Zscaler และ Palo Alto Networks นับ FWaaS เป็นส่วนหนึ่งของ SSE ด้วย Fortinet และ Check Point อธิบาย SSE จากสิ่งที่ปกป้อง คือเว็บ คลาวด์ และแอปภายใน Microsoft เรียกข้อเสนอของตนว่าโซลูชัน Security Service Edge ประกอบด้วย Entra Internet Access (secure web gateway) และ Entra Private Access (ZTNA) โดยจับคู่กับ Defender for Cloud Apps ซึ่งทำหน้าที่เป็น CASB ข้อสรุปที่ใช้ได้จริงคือ ให้ขอรายการส่วนประกอบเป็นลายลักษณ์อักษรจากทุกผู้ผลิต พร้อมระบุว่าส่วนไหนต้องซื้อไลเซนส์แยก

ทราฟฟิกไหลอย่างไร

บริการ SASE หรือ SSE ไม่ส่งทราฟฟิกของผู้ใช้ระยะไกลย้อนกลับไปสำนักงานใหญ่ก่อน แต่ให้ผู้ใช้และสาขาเชื่อมต่อกับจุดให้บริการ (point of presence หรือ PoP) ที่อยู่ใกล้ ซึ่งผู้ให้บริการเป็นผู้ดูแล NIST SP 800-215 อธิบายว่าเครื่องผู้ใช้ สาขา และแอปเชื่อมต่อกับ PoP ของผู้ให้บริการ โดยมักมี security agent (โปรแกรมที่ติดตั้งบนเครื่องผู้ใช้) ช่วยนำทราฟฟิกไปยัง PoP จากนั้น PoP จะตรวจตัวตน อุปกรณ์ และนโยบาย แล้วส่งทราฟฟิกต่อไปยังอินเทอร์เน็ต บริการ SaaS หรือแอปภายใน วิธีนี้หลีกเลี่ยงปัญหา hair-pinning (ทราฟฟิกต้องอ้อมไปผ่านศูนย์กลางก่อนถึงปลายทาง) ที่ NIST อธิบายไว้กรณีเข้าถึงด้วย VPN แต่ต้องแลกกับการพึ่งพาเครือข่ายของผู้ให้บริการ

INFOGRAPHIC
เส้นทางของทราฟฟิกเมื่อผ่านบริการ SASE หรือ SSE
01
ผู้ใช้หรือสาขา
ต่อผ่าน agent หรืออุโมงค์
02
PoP ใกล้สุด
จุดบริการของผู้ให้บริการ
03
ตรวจนโยบาย
ตัวตน อุปกรณ์ เนื้อหา
04
ปลายทาง
เว็บ SaaS หรือแอปภายใน

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

  • ขอบเขต: SSE ครอบคลุมเฉพาะบริการความปลอดภัย ส่วน SASE เพิ่มชั้นเครือข่าย (SD-WAN) เข้าไปด้วย
  • สิ่งที่ต้องเปลี่ยน: SSE วางซ้อนบนเครือข่ายและการเลือกเส้นทางที่มีอยู่เดิมได้ ส่วน SASE ต้องปรับโครงสร้าง WAN ด้วย เช่น การเชื่อมสาขา จึงเป็นโครงการที่ใหญ่กว่า Palo Alto Networks ระบุว่า SSE ไม่ได้ดูแลเรื่องการปรับประสิทธิภาพเครือข่ายหรือการเลือกเส้นทาง
  • ความเร็วในการเห็นผล: Zscaler ระบุว่า SSE ติดตั้งได้เร็วกว่า SASE และ Palo Alto Networks อธิบายแนวทางที่เริ่มจาก SSE แล้วค่อยเพิ่ม SD-WAN ทีหลัง ทั้งสองรายขายทั้งสองแบบ จึงควรอ่านเป็นมุมมองของผู้ขาย ระยะเวลาจริงขึ้นกับจำนวนสาขา สัญญาเดิม และทักษะของทีม
  • ใครเป็นเจ้าของ: SSE มักเป็นหน้าที่ของทีมความปลอดภัย ส่วน SASE ต้องให้ทีมเครือข่ายกับทีมความปลอดภัยออกแบบและดูแลร่วมกัน

แต่ละแบบเหมาะกับกรณีใด

  • ผู้ใช้ส่วนใหญ่ทำงานระยะไกลหรือแบบ hybrid ใช้ SaaS มาก และไม่ต้องการเปลี่ยน WAN: เริ่มที่ SSE (SWG, CASB, ZTNA) CISA และหน่วยงานพันธมิตรแนะนำให้องค์กรเคลื่อนไปสู่ Zero Trust (แนวคิดที่ไม่เชื่อใจใครโดยอัตโนมัติ ต้องตรวจสอบทุกครั้ง) SSE หรือ SASE เพื่อให้มองเห็นกิจกรรมในเครือข่ายได้มากขึ้น
  • มีหลายสาขา และใกล้ถึงรอบต่อสัญญา MPLS หรือ SD-WAN: พิจารณา SASE เพื่อให้เครือข่ายกับความปลอดภัยย้ายไปพร้อมกัน NIST SP 800-215 ระบุว่า MPLS (วงจรเช่าที่เชื่อมสาขากับศูนย์กลาง) ออกอินเทอร์เน็ตได้ผ่านจุดที่จำกัดเท่านั้น จึงทำให้ latency (ความหน่วง) สูงขึ้น
  • มี SD-WAN ที่ใช้งานได้ดีอยู่แล้ว: เลือก SSE ก่อน แล้วตรวจว่าทำงานร่วมกับ SD-WAN เดิมได้ ไม่ต้องเปลี่ยนทั้งสองอย่าง
  • สำนักงานเล็ก ระบบส่วนใหญ่อยู่ในองค์กร มีผู้ใช้ระยะไกลน้อย หรือมีเครือข่ายที่แยกออกไป เช่น OT (เครือข่ายระบบควบคุมการผลิต): อาจยังไม่ต้องใช้บริการ edge บนคลาวด์ ไฟร์วอลล์ที่ดูแลดีอาจเพียงพอ ดู NGFW, UTM และ WAF เปรียบเทียบ

ข้อดีและข้อจำกัด

  • ข้อดี - นโยบายเดียวใช้ได้ทุกที่: NIST SP 800-215 ระบุประโยชน์ของ SASE ไว้ว่า ใช้นโยบายความปลอดภัยชุดเดียวกับผู้ใช้ทุกคนไม่ว่าอยู่ที่ใด ดูภาพรวมได้จากแดชบอร์ดเดียว และมีอุปกรณ์ที่ต้องดูแลน้อยลง
  • ข้อดี - มองเห็นการใช้งาน: ทราฟฟิกเว็บและ SaaS ผ่านจุดเดียว จึงช่วยให้เห็นเครื่องมือที่ไม่ได้รับอนุญาตด้วย รวมถึงเครื่องมือ AI ดู Shadow AI: ความเสี่ยงและการรับมือ
  • ข้อจำกัด - ผู้ให้บริการอยู่บนเส้นทางทราฟฟิก: ทราฟฟิกต้องพึ่งประสิทธิภาพและความพร้อมใช้งานของ PoP Check Point ระบุความกังวลเรื่องประสิทธิภาพจากการส่งทราฟฟิกผ่านสถาปัตยกรรมแบบรวมศูนย์ ส่วน NIST SP 800-207 ชี้ว่าการทำสำเนา enforcement point (จุดบังคับใช้นโยบาย) ไว้หลายจุดช่วยลดความเสี่ยงได้ แต่ไม่ทำให้หมดไป
  • ข้อจำกัด - การเชื่อมกับระบบเก่าและระบบในองค์กร: Check Point จัดให้การเชื่อมกับระบบที่มีอยู่เดิม และข้อกำหนดด้านกฎระเบียบบนคลาวด์ เป็นความท้าทายอย่างหนึ่งของการติดตั้ง
  • ข้อจำกัด - การตรวจทราฟฟิกที่เข้ารหัสและความเป็นส่วนตัว: ต้องตัดสินใจว่าจะตรวจอะไร ยกเว้นอะไร และใครดู log ได้บ้าง รวมถึงข้อมูลถูกประมวลผลที่ไหน หากต้องคำนึงถึง PDPA (กฎหมายคุ้มครองข้อมูลส่วนบุคคล)
  • ข้อจำกัด - ไลเซนส์และการผูกติดผู้ผลิต: ส่วนประกอบแต่ละอย่างอาจแยกไลเซนส์ ตัวอย่างเช่น Microsoft ระบุในเอกสารว่าบริการส่วนใหญ่ใช้ไลเซนส์แบบคิดตามจำนวนผู้ใช้

นำไปใช้อย่างไรให้เสี่ยงน้อย

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

INFOGRAPHIC
ลำดับนำ SSE หรือ SASE ไปใช้
1
ทำแผนที่ผู้ใช้ แอป และทราฟฟิก
ดูว่าอยู่ที่ไหนและผ่านอะไรบ้าง
2
เลือกขอบเขต
SSE อย่างเดียว หรือ SASE ที่มี SD-WAN
3
ทดลองกับกลุ่มเดียว
วัด latency และดูว่าอะไรใช้ไม่ได้
4
ย้ายเว็บและ SaaS ก่อน แล้วแอปภายใน
เลิกใช้ proxy และกฎ VPN ตามลำดับ
5
เตรียมเส้นทางสำรอง
บัญชีฉุกเฉิน และทางออกเมื่อผู้ให้บริการล่ม

คำถามที่ควรถามผู้ผลิตทุกราย ได้แก่

  • ราคาที่เสนอรวมส่วนประกอบอะไรบ้าง และส่วนไหนต้องซื้อไลเซนส์เพิ่ม
  • PoP ตั้งอยู่ที่ไหนบ้าง และถ้า PoP ใดล่มจะเกิดอะไรขึ้น
  • การเชื่อมต่อแอปภายในรองรับโปรโตคอลอะไรบ้าง รวมถึง UDP หรือไม่
  • ตรวจทราฟฟิกที่เข้ารหัสอย่างไร และยกเว้นอะไรได้บ้าง
  • ส่ง log เข้า SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) ขององค์กรได้หรือไม่ และเก็บ log ไว้นานเท่าใด
  • ถ้า SSE กับ SD-WAN มาจากคนละผู้ผลิต จะทำงานร่วมกันอย่างไร
  • ส่งออกนโยบายแล้วย้ายไปใช้ที่อื่นได้หรือไม่

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

  • ทำแผนที่ทราฟฟิก: ดูว่าทราฟฟิกไปยัง SaaS และอินเทอร์เน็ตมีสัดส่วนเท่าใดเมื่อเทียบกับไปยัง data center ผู้ใช้และสาขาอยู่ที่ไหน และตอนนี้ VPN กับ proxy รับทราฟฟิกอะไรอยู่บ้าง
  • ตรวจเครื่องมือที่ซ้ำซ้อน: ทำบัญชีรายการไลเซนส์ VPN, proxy, ไฟร์วอลล์, CASB และ SD-WAN พร้อมวันครบสัญญา องค์กรอาจมีส่วนประกอบของ SSE อยู่แล้วบางส่วน
  • นิยามปัญหาก่อน: ชี้ให้ชัดว่าปัญหาคือการเข้าถึงจากระยะไกล การกรองเว็บ การควบคุมข้อมูลใน SaaS หรือการเชื่อมสาขา
  • เขียนข้อกำหนดและเงื่อนไขการย้ายออก: ทำให้เสร็จก่อนนัดดูเดโมกับผู้ผลิตรายใด
  • เลือกโครงการนำร่อง: เลือกหนึ่งกลุ่ม เช่น ผู้รับเหมาที่ทำงานระยะไกล หรือหนึ่งสาขา

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

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

  • ซื้อตามตัวย่อ: คำว่า SASE หรือ SSE ในใบเสนอราคาไม่ได้บอกว่าแพ็กเกจนั้นมีอะไรรวมอยู่บ้าง
  • เริ่มผิดจุด: เริ่มที่ SD-WAN ทั้งที่ปัญหาอยู่ที่ความปลอดภัย หรือเริ่มที่ความปลอดภัยทั้งที่ปัญหาอยู่ที่เครือข่าย ควรเลือกตามปัญหาที่ต้องแก้
  • ลืมทางออก: นโยบายอาจย้ายไปใช้ที่อื่นไม่ได้ จึงควรถามตั้งแต่ต้น
  • มองข้ามประสบการณ์ผู้ใช้: ทดสอบ latency จากสถานที่จริงและกับแอปจริงก่อนขยาย
  • ข้ามเรื่องความพร้อมใช้งาน: ไม่มีเส้นทางสำรองเมื่อผู้ให้บริการขัดข้อง
  • เปลี่ยนทุกอย่างพร้อมกัน: การย้ายเป็นระลอกทำให้แก้ปัญหาได้ง่ายกว่า
INFOGRAPHIC
ข้อผิดพลาดกับแนวปฏิบัติที่ควรทำ

ข้อผิดพลาด

  • ซื้อตามตัวย่อ SASE หรือ SSE
  • เปลี่ยนทุกอย่างในครั้งเดียว
  • ไม่มีทางสำรองเมื่อผู้ให้บริการล่ม

แนวปฏิบัติ

  • ขอรายการส่วนประกอบและไลเซนส์เป็นเอกสาร
  • นำร่องกลุ่มเล็กแล้วขยายเป็นระลอก
  • ทดสอบทางสำรองและบัญชีฉุกเฉิน

DLP เป็นหนึ่งในบริการที่มักมาพร้อม SSE และทำงานที่จุดตรวจทราฟฟิก ดูข้อจำกัดและแนวทางใช้ใน DLP (Data Loss Prevention) คืออะไร และความเสี่ยง Shadow AI

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