Secure Web Gateway การย้ายระบบ: รายการตรวจสอบการเปลี่ยนระบบและการคืนค่า

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

บทความนี้เป็นส่วนหนึ่งของคู่มือความปลอดภัยระบบคลาวด์แบบไฮบริดสำหรับข้อมูลเฉพาะเกี่ยวกับBlue Coat , ProxySG และ Symantec Edge SWG โปรดดูที่Blue Coat และ ProxySG End of Life: Migration Planning.

ขั้นตอนที่ 1: การตรวจสอบสินค้า

ขั้นตอนที่ 1 จะบันทึกข้อมูลเกี่ยวกับโครงสร้างเกตเวย์ปัจจุบัน การจัดการทิศทางการจราจร การตรวจสอบตัวตน การตรวจสอบ TLS นโยบาย และการบูรณาการ ก่อนที่จะเริ่มงานออกแบบใดๆ

โครงสร้างพื้นฐาน

• ทุกเกตเวย์: รุ่น, เวอร์ชันซอฟต์แวร์, ตำแหน่ง, บทบาท และวันที่สิ้นสุดอายุการใช้งาน (สำหรับ ProxySG และ Edge SWGให้ตรวจสอบบทความเกี่ยวกับวงจรชีวิตของ Broadcom)
• ปริมาณการจราจรและอัตราผ่านสูงสุดต่อไซต์ พร้อมสัดส่วนการถอดรหัส TLS
• จำนวนผู้ใช้ต่อเว็บไซต์และสำหรับการเข้าถึงจากระยะไกล
• การเชื่อมต่อพร็อกซีแบบต่อเนื่องทั้งด้านต้นทางและปลายทาง, ระบบกระจายโหลด และการออกแบบระบบสำรอง

การควบคุมการจราจร

• การตั้งค่าพร็อกซีแบบชัดเจน ไฟล์ PAC และ WPAD
• จุดการสกัดกั้นที่โปร่งใส (WCCP, การกำหนดเส้นทางตามนโยบาย)
• อุโมงค์จากสาขา (IPsec, GRE)
• เอเจนต์บนอุปกรณ์ปลายทาง
• ข้อยกเว้นสำหรับการส่งตรงไปยังอินเทอร์เน็ต

อัตลักษณ์

• พื้นที่การยืนยันตัวตน (SAML, Kerberos/IWA, LDAP, ใบรับรองลูกค้า)
• การแมปกลุ่มที่ใช้ในนโยบาย
• การส่งข้อมูลที่ไม่ผ่านการตรวจสอบความถูกต้อง (เซิร์ฟเวอร์, IoT, OT) และวิธีการจัดการ

การตรวจสอบ TLS

• การตรวจสอบ CA, ตำแหน่งหลัก, วันหมดอายุ และวิธีการแจกจ่าย
• รายชื่อการข้ามขั้นตอนการถอดรหัส พร้อมเหตุผลและเจ้าของ

นโยบาย

• การส่งออกนโยบายแบบครบถ้วน รวมถึงลำดับกฎ หมวดหมู่ รายการที่กำหนดเอง และข้อยกเว้น
• กฎที่ไม่มีผลลัพธ์ใน 90 วันที่ผ่านมา (กฎที่อาจถูกยกเลิก)

การบูรณาการ

• การเชื่อมต่อของ ICAP กับ DLP, โปรแกรมป้องกันไวรัส และระบบแซนด์บ็อกซ์
• การส่งต่อบันทึกไปยัง SIEM และเครื่องมือรายงาน
• การติดตามและแจ้งเตือน

ขั้นตอนที่ 2: การออกแบบเป้าหมาย

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

• กำหนดว่าแต่ละไซต์และกลุ่มผู้ใช้จะได้รับการตรวจสอบที่ใด: ในสถานที่จริง, บนคลาวด์ หรือแบบไฮบริด
• กำหนดวิธีการจัดการการส่งข้อมูลสำหรับแต่ละกรณี: พร็อกซีแบบชัดเจนหรือ PAC สำหรับเครือข่ายที่ได้รับการจัดการ, ตัวแทนหรือการควบคุมผ่านเบราว์เซอร์สำหรับผู้ใช้ที่เคลื่อนที่, และอุโมงค์เครือข่ายสำหรับสาขา
• ยืนยันตำแหน่งการตรวจสอบ TLS เพื่อให้แต่ละโฟลว์ถูกถอดรหัสเพียงครั้งเดียว คำแนะนำของ NSA แนะนำให้ทำการตรวจสอบเพียงครั้งเดียวภายในเครือข่ายองค์กร และหลีกเลี่ยงการตรวจสอบซ้ำซ้อนจากพร็อกซีที่เชื่อมต่อกัน (NSA)
• ความจุสำหรับอัตราผ่านสูงสุดหลังการถอดรหัส พร้อมทั้งการขยายตัว
• ออกแบบระบบให้มีความพร้อมใช้งานสูงและพฤติกรรมเมื่อเกิดข้อผิดพลาด
• กำหนดสถานที่เก็บรักษาบันทึกและหลักฐาน DLP
• วางแผนการนำระบบ CA ใหม่มาใช้หรือการโอนระบบ CA ที่มีอยู่ และยืนยันว่าระบบสนับสนุนการเก็บรักษาคีย์ รวมถึงการบูรณาการ HSM ที่จำเป็น

ขั้นตอนที่ 3: การแปลนโยบาย

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

• กำหนดกฎต้นทางแต่ละข้อให้สอดคล้องกับกฎปลายทางที่เทียบเท่า หรือทำเครื่องหมายเพื่อยกเลิก
• จัดหมวดหมู่ URL ของแผนที่ระหว่างผู้ขายต่าง ๆ และวิเคราะห์ความแตกต่างสำหรับหมวดหมู่ที่มีผลกระทบสูง
• สร้างรายชื่อที่กำหนดเอง รายชื่อที่อนุญาต และรายชื่อที่ถูกบล็อกใหม่
• แปลกฎที่ขึ้นอยู่กับกระบวนการยืนยันตัวตน และยืนยันการกำหนดกลุ่ม
• สร้างวิธีการหลีกเลี่ยงการถอดรหัสขึ้นใหม่ และตรวจสอบแต่ละวิธีเพื่อพิจารณาว่ายังจำเป็นอยู่หรือไม่
• แทนที่การส่งต่อ DLP ที่ใช้ ICAP ด้วยบริการคุ้มครองข้อมูลของแพลตฟอร์มเองเมื่อเป็นไปได้ โดยตรวจสอบให้แน่ใจว่ากระบวนการตรวจสอบเกิดขึ้นที่ใด หรือตั้งระบบการเชื่อมต่อใหม่
• บันทึกทุกการเปลี่ยนแปลงและทุกกฎที่ถูกยกเลิก พร้อมทั้งระบุเหตุผล โดยปฏิบัติตามกระบวนการควบคุมการเปลี่ยนแปลงการตั้งค่าของคุณ (NISTSP 800-128อธิบายถึงวิธีการจัดการการตั้งค่าที่เน้นด้านความปลอดภัย)

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

ขั้นตอนที่ 4: การเตรียมการคืนค่า

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

ทริกเกอร์การย้อนกลับ(ตัวอย่าง)

• การตรวจสอบความถูกต้องที่ล้มเหลวเกินระดับที่กำหนดไว้
• แอปพลิเคชันที่สำคัญต่อธุรกิจไม่สามารถใช้งานได้เกินระยะเวลาที่ตกลงกันไว้
• ตั๋วบริการช่วยเหลือที่มีค่าสูงกว่าค่าพื้นฐานที่กำหนดไว้หลายเท่า
• ยืนยันว่ามาตรการควบคุมความปลอดภัยไม่ได้ถูกนำไปใช้

กลไกการคืนค่า

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

ขั้นตอนที่ 5: โครงการนำร่อง

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

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

ขั้นตอนที่ 6: การทดสอบ

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

ขั้นตอนที่ 7: การเปลี่ยนระบบแบบค่อยเป็นค่อยไป

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

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

ขั้นตอนที่ 8: การรับมอบและยกเลิกการใช้งาน

ขั้นตอนที่ 8 ยืนยันว่าเกณฑ์การรับยอมรับได้ถูกปฏิบัติตามแล้ว จากนั้นจึงยกเลิกการใช้งานเกตเวย์ ใบรับรอง และสัญญาเดิม

เกณฑ์การยอมรับ(ตัวอย่าง)

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

ถอนการใช้งาน

• ลบเกตเวย์เก่าออกจากไฟล์ PAC, การกำหนดเส้นทาง และ DNS
• หากมีการเปลี่ยน CA สำหรับการตรวจสอบแล้ว ให้ยกเลิกและลบ CA สำหรับการตรวจสอบเดิมออกจากอุปกรณ์
• จัดเก็บบันทึกเก่าตามนโยบายการเก็บรักษาข้อมูล
• ลบข้อมูลจากอุปกรณ์ฮาร์ดแวร์อย่างปลอดภัยและกำจัดทิ้ง
• ปิดสัญญาใบอนุญาตและสัญญาบริการ

กรอบเวลาทั่วไป

ระยะเวลาดำเนินการขึ้นอยู่กับขนาดของทรัพย์สินและความซับซ้อนของกรมธรรม์

องค์กรที่มีสำนักงานเพียงแห่งเดียวสามารถดำเนินการย้ายระบบเสร็จสิ้นภายในไม่กี่สัปดาห์ ส่วนองค์กรขนาดใหญ่ที่มีหลายสำนักงานมักดำเนินการติดตั้งระบบแบบคู่ขนานและนำระบบมาใช้ตามขั้นตอนเป็นระยะๆ ภายในระยะเวลา 6 ถึง 12 เดือน ตามข้อมูลจาก Skyhigh Security.

Skyhigh ช่วยสนับสนุนการย้ายระบบ SWG อย่างไร

Skyhigh สนับสนุนการย้ายระบบ SWG ด้วยการติดตั้งแบบขนาน การนำเข้านโยบาย CPL ที่ได้รับการตรวจสอบแล้ว และรูปแบบการติดตั้งที่ยืดหยุ่น

Skyhigh Hybrid SSE Meshติดตั้งร่วมกับเกตเวย์ที่มีอยู่ เพื่อให้สามารถตรวจสอบความถูกต้องของนโยบายกับข้อมูลการรับส่งข้อมูลแบบขนานก่อนการเปลี่ยนระบบ Skyhigh จะแปลงนโยบาย CPL ของBlue Coat ที่มีอยู่ให้เป็นรูปแบบใหม่ในคอนโซลนโยบายแบบรวมผ่านกระบวนการนำเข้าที่ได้รับการตรวจสอบความถูกต้อง และนโยบายจะถูกสร้างขึ้นในคอนโซลคลาวด์ของ Skyhigh นโยบายสำหรับเว็บและแอปพลิเคชันส่วนตัวสามารถบังคับใช้บนเกตเวย์ในสถานที่ ส่วนข้อมูลการรับส่งข้อมูลที่ต้องการการปกป้องข้อมูลที่ดำเนินการผ่านคลาวด์จะถูกส่งต่อไปยังคลาวด์ของ Skyhigh ผู้ใช้ระยะไกลจะได้รับการให้บริการผ่านจุดให้บริการบนคลาวด์ (PoP) Skyhigh SWG สามารถทำงานได้ทั้งในสถานที่จริง (on-premises), แบบไฮบริด หรือบนคลาวด์ ดังนั้นการย้ายระบบจึงไม่จำเป็นต้องเปลี่ยนแปลงรูปแบบการติดตั้งโปรแกรมการปรับปรุงระบบป้องกันเนื้อหา(Blue Coat )จะเพิ่มการสนับสนุนบริการและส่วนลดเชิงพาณิชย์สำหรับลูกค้าที่ตรงตามเงื่อนไข

แหล่งข้อมูล

1. NSA.การจัดการความเสี่ยงจากการตรวจสอบความปลอดภัยชั้นการส่งข้อมูล(พฤศจิกายน 2019).https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. NISTSP 800-128: คู่มือการจัดการการกำหนดค่าของระบบข้อมูลที่เน้นด้านความปลอดภัย https://csrc.nist.gov/pubs/sp/800/128/upd1/final
3. Broadcom.การยุติการสนับสนุนและวงจรชีวิตผลิตภัณฑ์สำหรับ Edge SWG (ProxySG) และ Advanced Secure Gateway(KB 151102).https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
4. 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
5. Skyhigh Security. “การนำระบบไฮบริดมาใช้กลายเป็นเรื่องที่ง่ายขึ้นด้วยแพลตฟอร์ม Skyhigh SSE” (3 ตุลาคม 2024).https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html