การตรวจสอบ TLS แบบท้องถิ่นเทียบกับแบบคลาวด์: ข้อได้เปรียบและข้อเสียในการนำไปใช้
- การตรวจสอบ TLS จะถอดรหัส ตรวจสอบ และเข้ารหัสข้อมูลการสื่อสารใหม่ ดังนั้นข้อความแบบไม่เข้ารหัสจะปรากฏขึ้นชั่วคราวในทุกจุดที่กระบวนการนี้เกิดขึ้น
- การตรวจสอบในท้องถิ่นช่วยให้สามารถควบคุมข้อความธรรมดาและกุญแจในท้องถิ่นได้; ประเมินบริการที่ใช้บนคลาวด์และกระบวนการประมวลผลของบริการเหล่านั้นอย่างแยกกัน
- แนวทางของ NSA แนะนำให้ตรวจสอบแต่ละเซสชันเพียงครั้งเดียว ภายในเครือข่ายองค์กร โดยไม่ใช้พร็อกซีแบบต่อกัน
- เก็บรักษารายการข้อยกเว้นที่ได้รับการตรวจสอบแล้ว สำหรับแอปที่ถูกตรึง หมวดหมู่ที่เกี่ยวข้องกับความเป็นส่วนตัว และข้อมูลการรับส่งข้อมูลที่ผิดปกติระหว่างการตรวจสอบ
- Client Hello ที่เข้ารหัส ซึ่งเผยแพร่ใน RFC 9849 จำกัดความสามารถในการมองเห็นแบบพาสซีฟ และจำเป็นต้องมีการจัดการอย่างระมัดระวัง
การตรวจสอบ TLS (ที่มักยังเรียกว่าการตรวจสอบ SSL) คือกระบวนการดักจับเซสชัน TLS ถอดรหัสด้วยใบรับรองที่องค์กรเชื่อถือ ตรวจสอบเนื้อหา และเข้ารหัสใหม่ก่อนส่งต่อไปยังปลายทาง หากไม่มีกระบวนการนี้ เกตเวย์เว็บที่ปลอดภัย เครื่องมือ DLP และแซนด์บ็อกซ์จะเห็นเพียงข้อมูลเมตาของปลายทางเท่านั้น แต่หากมีกระบวนการนี้ พวกมันสามารถตรวจจับมัลแวร์ ป้องกันการรั่วไหลของข้อมูล และบังคับใช้นโยบายการใช้งานที่ยอมรับได้ภายในเซสชันที่เข้ารหัส
การตัดสินใจไม่ใช่ว่าจะตรวจสอบหรือไม่ แต่เป็นว่าจะตรวจสอบที่ไหน คู่มือนี้เปรียบเทียบการตรวจสอบ TLS แบบท้องถิ่นและแบบคลาวด์ ในด้านต่างๆ เช่น เส้นทางการถอดรหัส ความรับผิดชอบของใบรับรอง ข้อยกเว้น การบันทึกข้อมูล และการดำเนินงาน
บทความนี้เป็นส่วนหนึ่งของคู่มือความปลอดภัยของ Hybrid Cloud
วิธีการทำงานของ TLS inspection
การตรวจสอบ TLS ทำงานโดยให้พร็อกซีที่เชื่อถือได้ยุติเซสชันที่เข้ารหัสของลูกค้า ตรวจสอบเนื้อหา และเปิดเซสชันที่เข้ารหัสใหม่ไปยังปลายทาง
พร็อกซีทำหน้าที่เป็นเซิร์ฟเวอร์สำหรับไคลเอนต์ และทำหน้าที่เป็นไคลเอนต์สำหรับปลายทาง:
- ลูกค้าเริ่มเซสชัน TLS ไปยังเว็บไซต์หรือแอปพลิเคชัน
- พร็อกซีจะดักจับการเชื่อมต่อและแสดงใบรับรองสำหรับปลายทาง ซึ่งได้รับการลงนามโดยหน่วยงานออกใบรับรอง (CA) สำหรับการตรวจสอบภายในองค์กร ที่อุปกรณ์ลูกค้าเชื่อถือ
- พร็อกซีจะเปิดเซสชัน TLS ของตัวเองไปยังปลายทางที่แท้จริง และตรวจสอบความถูกต้องของใบรับรองของเซิร์ฟเวอร์นั้น
- ข้อมูลการสื่อสารระหว่างสองเซสชันจะถูกถอดรหัส ตรวจสอบ และเข้ารหัสใหม่
สิ่งนี้หมายความว่าพร็อกซีดังกล่าวถือครองกุญแจที่มีอำนาจสูงมาก และจัดการข้อความแบบไม่เข้ารหัสสำหรับทุกเซสชันที่ได้รับการตรวจสอบ คำแนะนำของ NSAเรื่อง “การจัดการความเสี่ยงจากการตรวจสอบ Transport Layer Security”แนะนำให้ลดการตรวจสอบดังกล่าวให้น้อยที่สุด: ดำเนินการตรวจสอบเพียงครั้งเดียวภายในเครือข่ายองค์กร และหลีกเลี่ยงการตรวจสอบซ้ำซ้อนโดยพร็อกซีส่งต่อหลายตัว คำเตือนก่อนหน้านี้ของ CISAเกี่ยวกับการดักจับ HTTPSได้เตือนว่าผลิตภัณฑ์ตรวจสอบที่ติดตั้งและใช้งานอย่างไม่ถูกต้องอาจทำให้ความปลอดภัยของ TLS อ่อนแอลงได้ เช่น การไม่สามารถตรวจสอบความถูกต้องของใบรับรองจากต้นทางได้อย่างเหมาะสม
การตรวจสอบ TLS แบบท้องถิ่นเทียบกับแบบคลาวด์: ภาพรวม
การตรวจสอบในระบบท้องถิ่นจะเก็บข้อความธรรมดาและกุญแจไว้บนโครงสร้างพื้นฐานของคุณ ส่วนการตรวจสอบบนคลาวด์จะย้ายข้อมูลเหล่านั้นไปยังจุดให้บริการของผู้ให้บริการ
| ปัจจัย | การตรวจสอบ TLS ในระบบท้องถิ่น (on-premises) | การตรวจสอบ TLS บนคลาวด์ |
|---|---|---|
| ที่ใดที่มีข้อความธรรมดา | อุปกรณ์ในศูนย์ข้อมูลหรือสาขาของคุณ | จุดเชื่อมต่อของผู้ให้บริการ |
| ใครเป็นผู้ถือกุญแจส่วนตัว CA สำหรับการตรวจสอบ | คุณ สามารถใช้ HSM ของตัวเองได้ (ตามความต้องการ) | ผู้ให้บริการ หรือคุณเองผ่านตัวเลือกกุญแจที่ได้รับการสนับสนุนจากผู้ให้บริการ |
| เหมาะที่สุดสำหรับ | ข้อมูลที่ได้รับการควบคุม, การจราจรภายใน, ผู้ใช้ในสถานที่, OT | ผู้ใช้จากระยะไกล, การส่งข้อมูลไปยัง SaaS โดยตรง |
| ความล่าช้าสำหรับผู้ใช้ในสถานที่ | ขึ้นอยู่กับความจุของระบบท้องถิ่นและเส้นทางข้อมูล | ขึ้นอยู่กับระยะทางของจุดเชื่อมต่อ (PoP) และระบบการกำหนดเส้นทาง |
| การวางแผนความจุ | จากคุณ; การถอดรหัสต้องใช้กำลังการคำนวณสูง | ของผู้ให้บริการ |
| ความพึ่งพาการเชื่อมต่อกับระบบภายนอก | ไม่จำเป็นสำหรับการบังคับใช้นโยบายเว็บในท้องถิ่น; แต่จำเป็นสำหรับบริการที่ใช้บนคลาวด์ เช่น การปกป้องข้อมูล | จำเป็น |
| ตำแหน่งของบันทึกและหลักฐาน | บันทึกข้อมูลท้องถิ่นสามารถปรับตั้งค่าได้; ส่วนข้อมูลหลักฐานจากบริการคลาวด์จะปฏิบัติตามนโยบายการเก็บข้อมูลของบริการนั้น | พื้นที่ผู้ให้บริการ (ขึ้นอยู่กับการตั้งค่า) |
| ความพยายามในการดำเนินงาน | การกำหนดขนาดอุปกรณ์, การติดตั้งแพตช์, วงจรชีวิตของใบรับรอง | การแจกจ่ายใบรับรอง, ข้อยกเว้น, การตั้งค่าผู้ให้บริการ |
องค์กรแบบไฮบริดส่วนใหญ่ใช้ทั้งสองวิธี: การตรวจสอบในท้องถิ่นสำหรับข้อมูลการสื่อสารที่เลือกไว้ซึ่งส่งผ่านสถานที่จริงและอยู่ภายใต้การกำกับดูแล และการตรวจสอบบนคลาวด์สำหรับผู้ใช้ระยะไกล ให้กำหนดจุดสิ้นสุด TLS (TLS termination) สำหรับแต่ละเส้นทาง และหลีกเลี่ยงการถอดรหัสซ้ำซ้อน รวมถึงในกรณีที่เกตเวย์ในท้องถิ่นส่งต่อข้อมูลการสื่อสารไปยังบริการที่ดำเนินการบนคลาวด์
เส้นทางการถอดรหัส
การออกแบบแบบไฮบริดทุกแบบควรกำหนดจุดสิ้นสุด TLS และจุดเข้ารหัสใหม่แต่ละจุด และหลีกเลี่ยงการตรวจสอบที่ซ้ำซ้อน
เส้นทางที่นิยมใช้ ได้แก่:
- ผู้ใช้ในสำนักงานที่เชื่อมต่อกับอินเทอร์เน็ต:ผ่านเกตเวย์ท้องถิ่น หรือผ่านช่องทางอุโมงค์ไปยังจุดให้บริการบนคลาวด์
- ผู้ใช้ระยะไกลที่เชื่อมต่อกับอินเทอร์เน็ต:จุดเชื่อมต่อบนคลาวด์ หรือส่งข้อมูลกลับไปยังเกตเวย์ท้องถิ่น
- จากผู้ใช้ไปยังแอปส่วนตัว:ตรวจสอบว่าเส้นทาง ZTNA ที่เลือกนั้นสนับสนุนการตรวจสอบ TLS หรือไม่ และอยู่ที่ใด
- เซสชันเบราว์เซอร์:การควบคุมระดับเบราว์เซอร์ที่สามารถดูเนื้อหาได้โดยไม่ต้องถอดรหัสจากเครือข่าย
- จุดปลายทาง:การตรวจสอบบนอุปกรณ์โดยใช้เอเจนต์
ความเสี่ยงในสภาพแวดล้อมแบบไฮบริดคือการถอดรหัสซ้ำโดยไม่ตั้งใจ สาขาอาจส่งข้อมูลผ่านพร็อกซีท้องถิ่น แล้วส่งต่อผ่านบริการคลาวด์ที่ทำการยุติ TLS อีกครั้ง ให้บันทึกขั้นตอนการตรวจสอบที่จำเป็นทุกขั้นตอน ป้องกันจุดเชื่อมต่อข้อความธรรมดาทุกจุด และกำจัดขั้นตอนที่ซ้ำซ้อนซึ่งเพิ่มความเสี่ยงหรือความซับซ้อนในการแก้ไขปัญหา
ความรับผิดชอบในการออกใบรับรอง
ความน่าเชื่อถือของการตรวจสอบ TLS ขึ้นอยู่กับความน่าเชื่อถือของใบรับรองที่อยู่เบื้องหลังเท่านั้น ดังนั้น จึงควรกำหนดเจ้าของที่ชัดเจนสำหรับแต่ละขั้นตอนในวงจรชีวิตของใบรับรอง:
- ตรวจสอบการสร้างและปกป้องใบรับรอง CAให้บันทึกไว้ว่ากุญแจส่วนตัวถูกเก็บไว้ที่ใด ใครสามารถเข้าถึงได้ และจำเป็นต้องใช้ HSM หรือไม่ ตรวจสอบการสนับสนุนการผสานรวม HSM สำหรับแต่ละเกตเวย์ท้องถิ่นหรือบริการคลาวด์ รวมถึงเวอร์ชันผลิตภัณฑ์ที่เกี่ยวข้อง; อย่าสมมติว่ามีการสนับสนุน
- การแจกจ่าย:วิธีที่ CA ถูกติดตั้งในระบบปฏิบัติการและพื้นที่เก็บข้อมูลความเชื่อถือของเบราว์เซอร์บนอุปกรณ์ที่ได้รับการจัดการ รวมถึงสิ่งที่เกิดขึ้นบนอุปกรณ์ที่ไม่ได้รับการจัดการ
- การหมุนเวียน.แผนงานและขั้นตอนการเปลี่ยน CA สำหรับการตรวจสอบโดยไม่หยุดการดำเนินงาน
- การตรวจสอบความถูกต้องในขั้นตอนต้นทางตรวจสอบให้แน่ใจว่าพร็อกซีจะปฏิเสธใบรับรองปลายทางที่ไม่ถูกต้อง หมดอายุ หรือถูกเพิกถอน แทนที่จะซ่อนข้อมูลเหล่านั้นจากผู้ใช้
- การสนับสนุนโปรโตคอลTLS 1.3 (RFC 8446) ควรได้รับการตรวจสอบโดยระบบเอง โดยไม่ลดระดับลง
ข้อยกเว้นด้านการจราจร
ไม่มีองค์กรใดควรถอดรหัสข้อมูลทั้งหมด ดังนั้นจึงควรจัดทำรายชื่อข้อยกเว้นที่บันทึกไว้อย่างชัดเจนและตรวจสอบเป็นประจำ:
| ประเภทข้อยกเว้น | เหตุผล | วิธีการจัดการทั่วไป |
|---|---|---|
| แอปพลิเคชันที่ได้รับการยืนยันด้วยใบรับรอง | การตรวจสอบทำให้การเชื่อมต่อถูกตัด | ข้ามตามจุดหมาย; ใช้การควบคุมตามชื่อเสียงและประเภท |
| หมวดหมู่ด้านสุขภาพ การเงิน และชีวิตส่วนตัว | สิทธิความเป็นส่วนตัวของพนักงาน ข้อกำหนดทางกฎหมาย และข้อกำหนดของคณะกรรมการแรงงาน | ข้ามขั้นตอนการถอดรหัส; แต่ยังคงบังคับใช้นโยบายหมวดหมู่ |
| การตรวจสอบความถูกต้องแบบ TLS และใบรับรองลูกค้า | Proxy ไม่สามารถแสดงใบรับรองลูกค้าได้ | ข้ามไป หรือใช้การส่งผ่านที่ได้รับการสนับสนุน |
| อัปเดตบริการและโปรโตคอล OT บางอย่าง | ความเสถียรและการสนับสนุนจากผู้จำหน่าย | ทางเลี่ยงตามจุดหมายปลายทางที่มีการจำกัดการเข้าถึง |
| QUIC และ HTTP/3 (RFC 9000) | พร็อกซีหลายตัวไม่สามารถตรวจสอบ QUIC ได้ | บล็อก QUIC เพื่อให้เบราว์เซอร์ใช้ TLS ผ่าน TCP แทน หรือตรวจสอบการสนับสนุนในตัว |
ตรวจสอบข้อยกเว้นทุกสามเดือน การข้ามข้อยกเว้นที่ล้าสมัยเป็นจุดบอดที่พบได้บ่อย
Client Hello ที่ถูกเข้ารหัส และผลกระทบที่เกิดขึ้น
Client Hello ที่ถูกเข้ารหัสจะซ่อนชื่อโฮสต์ปลายทางจากผู้สังเกตการณ์แบบพาสซีฟ ดังนั้น การมองเห็นที่อิงตาม SNI และการตัดสินใจบางประการเกี่ยวกับการบายพาสจึงจำเป็นต้องพิจารณาใหม่
Encrypted Client Hello ได้รับการเผยแพร่เป็นRFC 9849ในปี 2026 ECH ทำการเข้ารหัสส่วนหนึ่งของกระบวนการจับมือ TLS ที่ก่อนหน้านี้เปิดเผยชื่อโฮสต์ปลายทาง (Server Name Indication หรือ SNI) และสนามข้อมูลอื่น ๆ เครื่องมือแบบพาสซีฟที่ใช้การอ่าน SNI เพื่อจัดประเภทการจราจรจะสูญเสียความสามารถในการมองเห็นข้อมูลดังกล่าวสำหรับเว็บไซต์ที่เปิดใช้งาน ECH
พร็อกซีแบบชัดเจนที่ยุติการเชื่อมต่อ TLS อยู่ในสถานการณ์ที่ต่างออกไป เนื่องจากพวกมันสร้างเซสชันของตัวเองไปยังปลายทาง แม้กระนั้น ECH ก็มีผลกระทบต่อการดำเนินงาน:
- เบราว์เซอร์อาจส่งส่วนขยายที่คล้ายกับ ECH แม้เมื่อ ECH ไม่ได้ถูกใช้งาน ดังนั้นผลิตภัณฑ์ตรวจสอบจึงต้องจัดการกับส่วนขยายดังกล่าวอย่างถูกต้อง
- RFC ระบุว่า ในสภาพแวดล้อมองค์กรที่มีการจัดการ หนึ่งในวิธีการคือปิดใช้งาน ECH ผ่านนโยบายกลุ่ม และพึ่งพาให้เครื่องลูกข่ายปฏิบัติตามการตั้งค่าดังกล่าว
- การตัดสินใจเกี่ยวกับประเภทและชื่อเสียงที่ขึ้นอยู่กับ SNI สำหรับการรับส่งข้อมูลที่ถูกบายพาส จำเป็นต้องมีทางเลือกอื่น เช่น การควบคุมระดับ DNS หรือการตั้งค่าพร็อกซีอย่างชัดเจน
ตรวจสอบแผนการพัฒนา ECH ของผู้ให้บริการตรวจสอบของคุณ และพฤติกรรมในการทดสอบกับเวอร์ชันเบราว์เซอร์ปัจจุบัน
การบันทึก
บันทึกการตรวจสอบอาจประกอบด้วย URL ข้อมูลระบุตัวตน และหลักฐาน DLP ดังนั้นจึงจำเป็นต้องมีการตัดสินใจอย่างชัดเจนเกี่ยวกับเนื้อหา ตำแหน่ง และการเข้าถึงของบันทึกดังกล่าว:
- ข้อมูลในฟิลด์ใดจะถูกบันทึกสำหรับทราฟฟิกที่ถอดรหัสแล้วและทราฟฟิกที่ถูกบายพาส
- สถานที่เก็บรักษาบันทึก และว่าบันทึกดังกล่าวอาจถูกนำออกจากเขตอำนาจศาลได้หรือไม่
- ระยะเวลาการเก็บรักษาข้อมูล และผู้ที่สามารถเข้าถึงหลักฐานเนื้อหาแบบเต็มได้
- เหตุการณ์ใดถูกส่งต่อไปยัง SIEM
การตรวจสอบภายในประเทศช่วยให้การเก็บรักษาบันทึกและหลักฐานภายในประเทศเป็นไปอย่างสะดวกยิ่งขึ้น ส่วนการตรวจสอบบนคลาวด์จำเป็นต้องยืนยันภูมิภาคการเก็บรักษาบันทึกของผู้ให้บริการและระบบควบคุมการเข้าถึง ดูหัวข้อ“ความอธิปไตยของข้อมูล” ในส่วน “ความปลอดภัยของคลาวด์แบบไฮบริด”
การแลกเปลี่ยนระหว่างประสิทธิภาพการดำเนินงาน
ระบบตรวจสอบแบบท้องถิ่นแลกเปลี่ยนความพยายามในการดำเนินงานเพื่อความควบคุม ระบบตรวจสอบแบบคลาวด์แลกเปลี่ยนความควบคุมเพื่อความเรียบง่าย ส่วนระบบตรวจสอบแบบไฮบริดต้องการเครื่องยนต์นโยบายเดียวเพื่อทำงาน
การตรวจสอบในท้องถิ่นจำเป็นต้องกำหนดขนาดอุปกรณ์ให้เหมาะสมสำหรับการถอดรหัสในช่วงเวลาที่มีการใช้งานสูงสุด รักษาให้ระบบตรวจสอบได้รับการอัปเดตแพตช์อย่างสม่ำเสมอ และวางแผนการขยายความจุของฮาร์ดแวร์หรือระบบเสมือน ในทางกลับกัน การตรวจสอบในท้องถิ่นช่วยให้สามารถควบคุมข้อความธรรมดา กุญแจ และบันทึกข้อมูลของทราฟฟิกที่ผ่านการตรวจสอบในท้องถิ่นได้อย่างเต็มที่ นอกจากนี้ การบังคับใช้นโยบายสำหรับเว็บและแอปพลิเคชันส่วนตัวในท้องถิ่นจะยังคงดำเนินต่อไปแม้ในช่วงที่เครือข่าย WAN หรือระบบคลาวด์เกิดการขัดข้อง ในขณะที่บริการที่ใช้งานในระบบคลาวด์ของผู้จำหน่ายจะหยุดชั่วคราวจนกว่าการเชื่อมต่อจะกลับมาเป็นปกติ
การตรวจสอบบนคลาวด์ทำให้การวางแผนความจุและการอัปเดตเครื่องยนต์เป็นหน้าที่ของผู้ให้บริการ แม้ว่าจะยังคงต้องดำเนินการแจกจ่ายใบรับรอง การจัดการข้อยกเว้น และการปรับแต่งนโยบาย แต่ก็ก่อให้เกิดความพึ่งพาต่อความพร้อมใช้งานและความเชื่อมต่อของผู้ให้บริการ
การตรวจสอบแบบไฮบริดรวมทั้งสองระบบเข้าด้วยกัน แต่จะทำงานได้ดีเพียงเมื่อใช้เครื่องยนต์นโยบายเพียงตัวเดียวเท่านั้น หากเกตเวย์ในท้องถิ่นและเกตเวย์บนคลาวด์มีรายการข้อยกเว้นและกฎ DLP ที่ต่างกัน ผู้ใช้จะได้รับการปฏิบัติที่แตกต่างกันไปตามสถานที่
วิธีที่ Skyhigh ดำเนินการตรวจสอบระบบในสถานที่และบนคลาวด์
Skyhigh ตรวจสอบ TLS ในระบบท้องถิ่นเมื่อมีข้อกำหนดด้านความสอดคล้อง และในระบบคลาวด์สำหรับผู้ใช้ระยะไกล ภายใต้กฎนโยบายเดียว
Skyhigh Hybrid SSE Meshดำเนินการถอดรหัสและตรวจสอบ SSL/TLS แบบท้องถิ่นบนอุปกรณ์ขององค์กรเองเมื่อมีข้อกำหนดด้านความสอดคล้อง และในจุดให้บริการ (PoP) ของ Skyhigh Cloud สำหรับผู้ใช้ระยะไกล โดยใช้เครื่องยนต์นโยบายเดียวสำหรับทั้งสองระบบ นโยบายการป้องกันข้อมูล (Secure Web Gateway ) และการเข้าถึงแบบ Zero Trust (Zero Trust Access) ถูกบังคับใช้โดยตรงบนเกตเวย์ ในขณะที่นโยบายการปกป้องข้อมูลถูกนำไปใช้ใน Skyhigh Cloud สำหรับการรับส่งข้อมูลที่เกตเวย์ส่งต่อ การถอดรหัสการจราจรเว็บที่เกตเวย์ภายในองค์กรจะได้รับการตรวจสอบและเข้ารหัสใหม่ที่นั่น เพื่อบังคับใช้นโยบายเว็บในท้องถิ่น ในกรณีที่นโยบายใช้บริการที่นำไปใช้ในคลาวด์ เช่น การปกป้องข้อมูล เกตเวย์จะส่งการจราจรที่เกี่ยวข้องไปยังคลาวด์ Skyhigh ซึ่งนโยบายเดียวกันจะถูกนำไปใช้ Agentless Secure Browser Controls เพิ่มการตรวจสอบที่รองรับ WebSocket สำหรับการจราจร AI และการส่งข้อความในเซสชันเบราว์เซอร์
แหล่งข้อมูล
- NSA.การจัดการความเสี่ยงจากการตรวจสอบความปลอดภัยชั้นการส่งข้อมูล(พฤศจิกายน 2019).https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. “การดักจับ HTTPS ทำให้ความปลอดภัยของ TLS อ่อนแอลง” (คำเตือน TA17-075A, มีนาคม 2017).https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF.RFC 8446: โปรโตคอล Transport Layer Security (TLS) เวอร์ชัน 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF.RFC 9849: Client Hello ที่เข้ารหัสด้วย TLS. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF.RFC 9000: QUIC: ระบบการส่งข้อมูลแบบมัลติเพล็กซ์และปลอดภัยที่ใช้ UDP เป็นพื้นฐาน https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. “การนำระบบไฮบริดมาใช้กลายเป็นเรื่องที่ง่ายขึ้นด้วยแพลตฟอร์ม Skyhigh SSE” (3 ตุลาคม 2024).https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “การปรับปรุง Symantec EdgeSecure Web Gateway ให้ทันสมัยด้วย Skyhigh Hybrid SSE Mesh” (15 กรกฎาคม 2026).https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html