Managed SASE ในประเทศไทย: 7 เกณฑ์เลือกผู้ให้บริการ พร้อม Checklist ก่อนตัดสินใจ
จัดทำโดย WIT Team | บทความเผยแพร่: 09 พฤศจิกายน 2569
Managed SASE (Managed Secure Access Service Edge) คือบริการที่ผู้ให้บริการภายนอกเข้ามาช่วยออกแบบ ติดตั้ง บริหารจัดการ และดูแลระบบ SASE อย่างต่อเนื่อง โดยมีขอบเขตการให้บริการและความรับผิดชอบตามที่ตกลงกันในสัญญา ช่วยให้องค์กรสามารถใช้เทคโนโลยีด้าน Network และ Cloud Security โดยไม่จำเป็นต้องบริหารทุกองค์ประกอบด้วยทีม IT ภายในเพียงอย่างเดียว
สำหรับองค์กรในประเทศไทย การเลือกผู้ให้บริการ Managed SASE ควรประเมิน 7 ปัจจัยสำคัญ ได้แก่
- Service Scope & Responsibility: ขอบเขตบริการและความรับผิดชอบระหว่างองค์กรกับผู้ให้บริการชัดเจนหรือไม่
- Technical Capability & Integration: มีความเชี่ยวชาญด้าน SASE และสามารถเชื่อมต่อกับระบบเดิมได้หรือไม่
- Network Performance in Thailand: รองรับคุณภาพการเชื่อมต่อจากสำนักงานและสาขาในประเทศไทยได้ดีเพียงใด
- Managed Operations & Support: มีทีมบริหารระบบ Monitoring และแก้ไขปัญหาที่พร้อมให้บริการจริงหรือไม่
- SLA & Service Continuity: มีข้อตกลงระดับบริการและแผนรองรับเหตุขัดข้องที่วัดผลได้หรือไม่
- PDPA & Data Governance: มีมาตรการจัดการข้อมูล การเข้าถึง Security Log และการส่งข้อมูลที่เหมาะสมหรือไม่
- TCO & Exit Strategy: มีโครงสร้างค่าใช้จ่ายโปร่งใส สามารถขยายบริการและเปลี่ยนผู้ให้บริการในอนาคตได้หรือไม่
ข้อพิจารณาสำคัญ: Managed SASE ที่ใช้แพลตฟอร์มเดียวกันอาจมีคุณภาพและขอบเขตบริการแตกต่างกัน เพราะผู้ให้บริการแต่ละรายมีรูปแบบการดูแลทีมงาน SLA และความรับผิดชอบไม่เหมือนกัน
องค์กรจึงควรพิจารณาทั้งความสามารถทางเทคนิคและคุณภาพการส่งมอบบริการ โดยใช้ Requirement Checklist, Request for Proposal (RFP) และ Proof of Concept (PoC) เป็นเครื่องมือสนับสนุนการตัดสินใจ
บทความนี้ WIT จะพาไปทำความเข้าใจสิ่งที่ควรตรวจสอบในข้อเสนอ Managed SASE สำหรับองค์กรในประเทศไทย พร้อมตารางประเมินผู้ให้บริการ และคำถามสำคัญที่ควรถามก่อนเซ็นสัญญา
Managed SASE คืออะไร? แตกต่างจากการซื้อ SASE Platform มาดูแลเองอย่างไร?
SASE (Secure Access Service Edge) เป็นสถาปัตยกรรมที่ผสานความสามารถด้าน Network Connectivity เช่น SD-WAN กับ Cloud-delivered Security เช่น Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA) และ Firewall as a Service (FWaaS)
ส่วน Managed SASE เป็น รูปแบบการส่งมอบและบริหารบริการ (Service Delivery Model) ที่เพิ่มผู้ให้บริการเข้ามาช่วยดูแลการดำเนินงาน
ความแตกต่างสำคัญจึงไม่ใช่เพียงฟังก์ชันของผลิตภัณฑ์ แต่เป็นคำถามว่า ใครเป็นผู้รับผิดชอบให้ระบบทำงานอย่างต่อเนื่อง ใครปรับปรุงนโยบาย และใครต้องดำเนินการเมื่อเกิดปัญหา
เปรียบเทียบ Self-managed SASE, Co-managed SASE และ Fully Managed SASE
| หัวข้อ | Self-managed | Co-managed | Fully Managed |
|---|---|---|---|
| การดูแลประจำวัน | ทีม IT ภายใน | แบ่งหน้าที่ร่วมกัน | ผู้ให้บริการเป็นหลัก |
| การตั้งค่าและเปลี่ยนนโยบาย | ทีม IT ภายใน | ตามบทบาทที่ตกลง | ผู้ให้บริการดำเนินการภายใต้การอนุมัติ |
| Monitoring | ทีม IT ภายใน | ทำร่วมกัน | ผู้ให้บริการตาม SLA |
| Incident Troubleshooting | ทีม IT ภายใน | ร่วมกันตรวจสอบ | ผู้ให้บริการเป็นผู้ดำเนินการหลักตามขอบเขต |
| Security Governance | องค์กร | องค์กรกำกับดูแล | องค์กรยังคงกำกับดูแล |
| เหมาะกับองค์กรที่ | มีทีม IT พร้อมดูแล | ต้องการแบ่งเบาภาระบางส่วน | ต้องการลดภาระ Operation อย่างมาก |
ตารางนี้เป็นการเปรียบเทียบรูปแบบบริการโดยทั่วไป ไม่ใช่ขอบเขตมาตรฐานที่ผู้ให้บริการทุกรายต้องปฏิบัติตาม
Fully Managed ไม่ได้หมายความว่าผู้ให้บริการสามารถตัดสินใจเปลี่ยน Security Policy สำคัญได้โดยไม่ต้องได้รับอนุมัติจากองค์กร
องค์กรยังควรเป็นเจ้าของนโยบายความปลอดภัย ความเสี่ยงทางธุรกิจ และการตัดสินใจที่มีผลกระทบต่อข้อมูลหรือระบบสำคัญ
สำหรับการเปรียบเทียบสถาปัตยกรรม SASE, VPN และ SD-WAN โดยละเอียด สามารถศึกษาเพิ่มเติมจากบทความ SASE vs VPN vs SD-WAN ต่างกันอย่างไร? ของ WIT
ก่อนเลือกผู้ให้บริการ Managed SASE องค์กรควรกำหนดความต้องการอะไรบ้าง?
หนึ่งในข้อผิดพลาดที่อาจเกิดขึ้นในการจัดซื้อ Managed SASE คือการเริ่มเปรียบเทียบราคาหรือชื่อผลิตภัณฑ์ โดยที่องค์กรยังไม่ได้กำหนดว่าต้องการให้ผู้ให้บริการรับผิดชอบงานใดบ้าง
ก่อนจัดทำ RFP องค์กรควรระบุข้อมูลพื้นฐานอย่างน้อย 4 ด้าน
1. Network & Application Landscape
จำนวนสำนักงานและสาขา ประเภท Internet Circuit ระบบที่อยู่ใน Data Center หรือ Cloud และแอปพลิเคชันที่มีความสำคัญต่อธุรกิจ
2. Identity & Access Requirements
จำนวนผู้ใช้งาน Remote User และ Third-party Vendor รวมถึงระบบ Identity Provider และ MFA ที่ใช้งานอยู่
3. Current Operational Pain Points
ปัญหาที่ทีม IT กำลังเผชิญ เช่น การติดตามเหตุขัดข้องใช้เวลานาน การเปลี่ยนนโยบายหลายสาขาซับซ้อน หรือมีผู้ดูแลระบบไม่เพียงพอสำหรับการให้บริการนอกเวลาทำการ
4. Target Service Outcomes
ผลลัพธ์ที่องค์กรต้องการ เช่น ลดระยะเวลาแก้ไขปัญหา เพิ่มความครอบคลุมด้าน Monitoring หรือปรับปรุงการเข้าถึงแอปพลิเคชันสำคัญจากสำนักงานสาขา
เมื่อกำหนดความต้องการได้ชัดเจน องค์กรจะสามารถนำข้อเสนอของผู้ให้บริการแต่ละรายมาเปรียบเทียบด้วยเกณฑ์เดียวกันได้อย่างมีประสิทธิภาพมากขึ้น
7 เกณฑ์สำคัญในการเลือกผู้ให้บริการ Managed SASE สำหรับองค์กรในประเทศไทย
1. Service Scope & Responsibility: ขอบเขตบริการและความรับผิดชอบชัดเจนหรือไม่?
เกณฑ์แรกที่ควรประเมินคือผู้ให้บริการรับผิดชอบงานใดบ้าง และมีงานใดที่ไม่ได้รวมอยู่ในสัญญา
เพราะคำว่า Managed Service อาจหมายถึงเพียงการติดตามสถานะและแจ้งเตือน หรืออาจรวมถึงการบริหาร Configuration, Change Management, Incident Response และ Performance Optimization ด้วย
องค์กรควรตรวจสอบ Service Scope อย่างน้อยดังนี้
- Initial Assessment และ Solution Design
- Installation และ Deployment
- Network และ Security Configuration Management
- Monitoring และ Alert Management
- Incident Troubleshooting และ Escalation
- Change Request และ Policy Update
- Configuration Backup และ Recovery
- Service Reporting และ Periodic Review
- Vendor Coordination และ Product Support
สิ่งสำคัญคือการแยกความรับผิดชอบระหว่างงานที่ผู้ให้บริการต้องดำเนินการเอง กับงานที่เพียงรับแจ้งและส่งต่อไปยังผู้ผลิตหรือ ISP
ตัวอย่างความเสี่ยงจาก Service Scope ที่ไม่ชัดเจน
เมื่อสาขาไม่สามารถเข้าถึงระบบ ERP ได้ ผู้ให้บริการ SASE อาจตรวจสอบแล้วพบว่า Cloud Platform ยังทำงานปกติ แต่ปัญหาเกี่ยวข้องกับ Internet Circuit หรือ DNS ภายในองค์กร
หากไม่ได้กำหนดขอบเขต End-to-End Troubleshooting ไว้ล่วงหน้า ทีม IT อาจต้องประสานงานผู้ให้บริการหลายรายด้วยตนเอง
เอกสารที่ควรขอ: Service Description, Statement of Work (SOW), Responsibility Matrix และรายการ Exclusions
คำถามที่ควรถาม: หากปัญหาเกี่ยวข้องกับทั้ง SASE Platform, ISP และระบบภายในองค์กร ใครเป็นผู้รับผิดชอบประสานงานจนสามารถระบุสาเหตุและส่งต่องานแก้ไขได้?
2. Technical Capability & Integration: มีความเชี่ยวชาญด้าน SASE และระบบองค์กรจริงหรือไม่?
ผู้ให้บริการ Managed SASE ควรมีความสามารถมากกว่าการติดตั้งและกำหนดค่าแพลตฟอร์ม แต่ต้องเข้าใจการเชื่อมโยง Network, Identity, Security และ Application
โดยเฉพาะองค์กรที่มี Hybrid Infrastructure ซึ่งอาจมีทั้ง Data Center, Public Cloud, Legacy Application และระบบเครือข่ายจากหลายผู้ผลิต
หัวข้อที่ควรประเมิน ได้แก่
- ความเชี่ยวชาญในการออกแบบ SASE Architecture
- ความสามารถในการเชื่อมต่อกับ WAN และ Firewall เดิม
- การทำงานร่วมกับ Active Directory หรือ Microsoft Entra ID
- การเชื่อมต่อ Identity Provider และ MFA
- ความเข้ากันได้กับ Private Application และ Legacy Protocol
- การกำหนด Security Policy ตามบทบาทและความเสี่ยง
- ความสามารถในการออกแบบ Migration และ Rollback Plan
ผู้ให้บริการควรสามารถอธิบายได้ว่า Application ใดเหมาะกับการย้ายมาใช้ SASE และมีระบบใดที่อาจต้องใช้แนวทางเชื่อมต่อเฉพาะ
ควรตรวจสอบประสบการณ์ของทีม Technical จากหลักฐานที่เหมาะสม เช่น ผลงานโครงการที่ได้รับอนุญาตให้อ้างอิง ประสบการณ์การติดตั้งในสภาพแวดล้อมที่ใกล้เคียง และความสามารถในการแก้ไขปัญหาระหว่าง PoC
เอกสารที่ควรขอ: Proposed Architecture, Integration Matrix, Migration Plan และ Technical Capability Profile
คำถามที่ควรถาม: สามารถแสดงขั้นตอนการเชื่อมต่อระบบเดิม พร้อมระบุข้อจำกัดทางเทคนิคและแนวทาง Rollback หาก Migration ไม่สำเร็จได้หรือไม่?
3. Network Performance in Thailand: รองรับการเชื่อมต่อจากประเทศไทยได้ดีเพียงใด?
คุณภาพการเชื่อมต่อจากประเทศไทยเป็นปัจจัยที่ควรพิสูจน์ด้วยการทดสอบจริง ไม่ใช่พิจารณาจากจำนวน Point of Presence (PoP) ทั่วโลกเพียงอย่างเดียว
แม้แพลตฟอร์ม SASE จะมีเครือข่ายครอบคลุมหลายภูมิภาค แต่ประสิทธิภาพจากสำนักงานในประเทศไทยยังขึ้นอยู่กับเส้นทาง ISP, Network Peering, การประมวลผล Security Traffic และตำแหน่งของแอปพลิเคชันปลายทาง
องค์กรควรทดสอบจากพื้นที่ใช้งานจริง เช่น
- สำนักงานใหญ่ในกรุงเทพฯ
- สำนักงานสาขาต่างจังหวัด
- พนักงานที่ทำงานจากบ้าน
- ระบบ ERP หรือ Application ภายใน Data Center
- SaaS Application ที่ใช้งานเป็นประจำ
ตัวชี้วัดที่ควรนำมาเปรียบเทียบ ได้แก่ Latency, Packet Loss, Jitter, Application Response Time และการเปลี่ยนเส้นทางเมื่อเกิดปัญหา
หากผู้ให้บริการระบุว่ามี PoP ในประเทศไทย ควรตรวจสอบว่าจุดให้บริการดังกล่าวรองรับความสามารถที่องค์กรต้องใช้จริงหรือไม่ และมีเงื่อนไขด้าน Traffic Routing อย่างไร
ไม่ควรสรุปว่า PoP ที่อยู่ใกล้ที่สุดจะให้ประสิทธิภาพดีที่สุดในทุกกรณี เพราะเส้นทางเครือข่ายและการตั้งค่าต่าง ๆ อาจส่งผลต่อประสบการณ์ใช้งาน
เอกสารที่ควรขอ: PoP Coverage, Network Design, Performance Test Report และ Failover Test Result
คำถามที่ควรถาม: สามารถทำ PoC จากสำนักงานในประเทศไทยโดยใช้ ISP และแอปพลิเคชันจริง พร้อมเปรียบเทียบผลก่อนและหลังการใช้งานได้หรือไม่?
4. Managed Operations & Support: ทีมดูแลระบบพร้อมให้บริการจริงหรือไม่?
การเลือก Managed SASE ต้องประเมินความพร้อมของทีม Operation และกระบวนการสนับสนุน ไม่ใช่พิจารณาเพียงคุณสมบัติของผลิตภัณฑ์
องค์กรควรตรวจสอบว่าใครเป็นผู้ดูแลระบบในแต่ละช่วงเวลา มีขั้นตอนรับเรื่องและแก้ไขปัญหาอย่างไร และสามารถประสานงานกับผู้ผลิตได้รวดเร็วเพียงใด
ประเด็นที่ควรประเมิน ได้แก่
Monitoring Capability
มีการตรวจสอบสถานะ Network, Security Service และ Application Connectivity ตามขอบเขตที่ตกลงไว้หรือไม่
Technical Support Availability
รองรับการแจ้งปัญหาผ่านช่องทางใดบ้าง และสามารถให้บริการในเวลาทำการหรือตลอด 24 ชั่วโมงตามที่องค์กรต้องการได้หรือไม่
Incident Handling
มีขั้นตอนจำแนกระดับความรุนแรง วิเคราะห์สาเหตุ แจ้งความคืบหน้า และ Escalation อย่างชัดเจนหรือไม่
Change Management
สามารถรองรับการเปลี่ยน Configuration หรือ Security Policy โดยมีขั้นตอนอนุมัติ การบันทึกการเปลี่ยนแปลง และการย้อนกลับเมื่อเกิดปัญหาหรือไม่
Service Review
มีรายงานประจำเดือนหรือการทบทวนบริการเป็นระยะ เพื่อประเมิน Performance, Incident และแนวทางปรับปรุงระบบหรือไม่
ควรให้ความสำคัญกับความแตกต่างระหว่าง
- 24/7 Monitoring: ระบบหรือทีมตรวจสอบสถานะตลอดเวลา
- 24/7 Incident Response: มีผู้รับผิดชอบตอบสนองและดำเนินการตามขั้นตอนเมื่อเกิดเหตุ
- 24/7 Technical Resolution Support: มีความสามารถในการวิเคราะห์และแก้ไขปัญหาภายใต้เงื่อนไขบริการที่กำหนด
ทั้งสามรูปแบบไม่จำเป็นต้องมีขอบเขตเท่ากัน
เอกสารที่ควรขอ: Support Model, Escalation Matrix, Incident Management Procedure และตัวอย่าง Monthly Service Report
คำถามที่ควรถาม: หากเกิด Critical Incident เวลา 02.00 น. ใครจะรับเรื่อง ใครวิเคราะห์ปัญหา และทีมใดสามารถดำเนินการแก้ไขได้จริง?
5. SLA & Service Continuity: มีข้อตกลงบริการที่ตรวจสอบและวัดผลได้หรือไม่?
SLA ของ Managed SASE ควรครอบคลุมมากกว่าค่า Availability ของ Cloud Platform แต่ต้องระบุคุณภาพการสนับสนุนและความรับผิดชอบเมื่อเกิดเหตุขัดข้องด้วย
องค์กรควรแยกการประเมิน SLA ออกเป็น 4 มิติ
| ประเภท SLA | สิ่งที่ควรตรวจสอบ |
|---|---|
| Platform Availability | ความพร้อมใช้งานของบริการ SASE Cloud และข้อยกเว้น |
| Incident Response | ระยะเวลาในการตอบรับและเริ่มดำเนินการตามระดับความรุนแรง |
| Service Restoration | เป้าหมายการกู้คืน ขั้นตอน Escalation และเงื่อนไขที่เกี่ยวข้อง |
| Change & Support | ระยะเวลารับคำขอเปลี่ยนแปลงและขอบเขต Technical Support |
ตัวอย่างเช่น ผู้ให้บริการอาจมี Availability SLA สำหรับ Cloud Platform แต่ไม่ได้รับประกันว่าสำนักงานสาขาจะสามารถใช้งาน Internet Circuit หรือ ERP ได้ตลอดเวลา เนื่องจากบริการเหล่านั้นอาจอยู่ภายใต้ผู้ให้บริการอีกฝ่ายหนึ่ง
ก่อนเซ็นสัญญาควรตรวจสอบด้วยว่า
- SLA วัดจากจุดใดและช่วงเวลาใด
- มีข้อยกเว้นสำหรับ Planned Maintenance หรือไม่
- กรณีผู้ผลิตหรือ ISP เกิดปัญหา ใครเป็นผู้ประสานงาน
- มีแผน Failover และ Business Continuity อย่างไร
- มีการทดสอบ Recovery Procedure หรือไม่
- หากไม่เป็นไปตาม SLA มีเงื่อนไข Service Credit หรือการชดเชยอย่างไร
องค์กรไม่ควรใช้ Service Credit เป็นมาตรการรองรับความเสียหายเพียงอย่างเดียว แต่ควรให้ความสำคัญกับความสามารถในการกู้คืนและลดผลกระทบต่อธุรกิจด้วย
เอกสารที่ควรขอ: SLA Matrix, Service Dependency Diagram, Incident Escalation Procedure และ Business Continuity Plan
คำถามที่ควรถาม: หากผู้ใช้งานไม่สามารถเข้าถึงระบบสำคัญได้ แต่ SASE Cloud ยังมีสถานะปกติ ผู้ให้บริการจะรับผิดชอบตรวจสอบและประสานงานในระดับใด?
6. PDPA & Data Governance: มีมาตรการดูแลข้อมูลและ Security Log อย่างเหมาะสมหรือไม่?
Managed SASE อาจเกี่ยวข้องกับการประมวลผลข้อมูลการใช้งานเครือข่าย ข้อมูลตัวตนผู้ใช้ และ Security Logs ซึ่งบางส่วนอาจเป็นข้อมูลส่วนบุคคลตามกฎหมายไทย
องค์กรจึงควรประเมินการบริหารจัดการข้อมูลตั้งแต่ก่อนเริ่มให้บริการ โดยเฉพาะหากมีการส่งต่อหรือเข้าถึงข้อมูลจากต่างประเทศ
หัวข้อสำคัญ ได้แก่
Data Location & Processing
ระบุว่าข้อมูล Traffic, Security Logs, User Identity และข้อมูลที่เกี่ยวข้อง ถูกประมวลผลหรือจัดเก็บในประเทศใดบ้าง
Data Access Control
ตรวจสอบว่าบุคลากรของผู้ให้บริการ ผู้ผลิต และผู้รับจ้างช่วงสามารถเข้าถึงข้อมูลประเภทใดได้บ้าง พร้อมหลักฐานการควบคุมสิทธิ์
Data Retention
กำหนดระยะเวลาเก็บรักษา Log การลบข้อมูล และการส่งออกข้อมูลตามความต้องการขององค์กร
Cross-border Data Transfer
หากมีการส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศ ต้องประเมินหลักเกณฑ์ตาม PDPA มาตรา 28 และ 29 รวมถึงประกาศที่เกี่ยวข้องและข้อยกเว้นที่อาจใช้ได้
Contractual Protection
ตรวจสอบความเหมาะสมของ Data Processing Agreement (DPA), Confidentiality Obligation, Security Measures และข้อกำหนดการแจ้งเหตุละเมิดข้อมูล
การมี PoP อยู่ในประเทศไทยไม่ได้หมายความว่าข้อมูลทั้งหมดจะถูกประมวลผลและจัดเก็บในประเทศไทยเสมอไป
ในทางกลับกัน การใช้ Cloud หรือ PoP ต่างประเทศก็ไม่ได้ถือว่าฝ่าฝืน PDPA โดยอัตโนมัติ แต่ต้องพิจารณาการประมวลผลและการโอนข้อมูลจริงตามหลักเกณฑ์ที่เกี่ยวข้อง
องค์กรควรให้ทีม Legal หรือ Data Protection Officer (DPO) ร่วมประเมินเงื่อนไขการใช้บริการก่อนลงนามในสัญญา
เอกสารที่ควรขอ: Data Flow Diagram, DPA, Subprocessor List, Data Retention Policy และ Security Control Documentation
คำถามที่ควรถาม: ข้อมูลและ Security Logs ขององค์กรถูกจัดเก็บที่ใด มีใครเข้าถึงได้บ้าง และสามารถลบหรือส่งออกข้อมูลเมื่อสิ้นสุดสัญญาได้อย่างไร?
7. TCO & Exit Strategy: ต้นทุนรวมโปร่งใสและเปลี่ยนผู้ให้บริการได้หรือไม่?
การเปรียบเทียบผู้ให้บริการ Managed SASE ควรพิจารณา Total Cost of Ownership (TCO) ตลอดอายุสัญญา รวมถึงต้นทุนที่อาจเกิดขึ้นเมื่อเพิ่มบริการหรือย้ายไปยังผู้ให้บริการรายอื่น
ค่าใช้จ่ายที่ควรตรวจสอบ เช่น
- SASE Platform License และ Subscription
- User License และ Branch License
- Managed Service Fee
- Installation และ Migration Fee
- SD-WAN Appliance หรือ Hardware
- Internet Circuit และ Bandwidth
- Premium Support หรือบริการนอกเวลาทำการ
- Log Retention และ Integration
- Professional Services และ Change Request
- ค่าใช้จ่ายในการเพิ่มสาขาหรือขยายจำนวนผู้ใช้งาน
ผู้ให้บริการควรแสดงรายละเอียดค่าใช้จ่ายที่รวมอยู่ในบริการ และรายการที่อาจมีค่าใช้จ่ายเพิ่มเติมอย่างชัดเจน
อีกประเด็นที่มักถูกมองข้ามคือ Exit Strategy หรือความสามารถในการย้ายออกจากบริการเมื่อสิ้นสุดสัญญา
องค์กรควรตรวจสอบว่า
- สามารถส่งออก Configuration และ Security Policy ได้ในรูปแบบใด
- สามารถเรียกคืน Log หรือข้อมูลที่องค์กรเป็นเจ้าของได้หรือไม่
- ต้องใช้ระยะเวลาและต้นทุนเท่าไรในการเปลี่ยนผู้ให้บริการ
- มีบริการ Transition Support หรือไม่
- ใครเป็นเจ้าของ Account, Configuration และเอกสารระบบ
- มีขั้นตอนยืนยันการลบข้อมูลหลังสิ้นสุดบริการอย่างไร
การวาง Exit Strategy ตั้งแต่ต้นช่วยลดความเสี่ยงจาก Vendor Lock-in และสนับสนุนความต่อเนื่องในการดำเนินธุรกิจ
เอกสารที่ควรขอ: Commercial Proposal, TCO Breakdown, License Terms, Renewal Conditions และ Exit Assistance Terms
คำถามที่ควรถาม: หากองค์กรขยายจาก 10 เป็น 30 สาขา หรือเปลี่ยนผู้ให้บริการในอนาคต ค่าใช้จ่ายและขั้นตอนการเปลี่ยนผ่านจะเป็นอย่างไร?
ตาราง RFP Checklist: เปรียบเทียบผู้ให้บริการ Managed SASE อย่างไรให้เป็นธรรม?
องค์กรสามารถใช้ตารางนี้เป็นกรอบเริ่มต้นสำหรับการประเมินผู้ให้บริการ Managed SASE โดยกำหนดน้ำหนักคะแนนจากความสำคัญของแต่ละปัจจัย
| เกณฑ์ประเมิน | หลักฐานที่ต้องขอ | น้ำหนักตัวอย่าง |
|---|---|---|
| 1. Service Scope | SOW, Service Catalog, Responsibility Matrix | 20% |
| 2. Technical Capability | Architecture, Integration Plan, Technical Experience | 15% |
| 3. Network Performance | PoP Details, Performance Test, Failover Test | 15% |
| 4. Managed Operations | Support Model, Escalation, Sample Report | 15% |
| 5. SLA & Continuity | SLA Matrix, Recovery Procedure, BCP | 15% |
| 6. PDPA & Governance | Data Flow, DPA, Data Retention Terms | 10% |
| 7. TCO & Exit Strategy | Cost Breakdown, Contract Terms, Exit Plan | 10% |
| รวม | 100% |
วิธีใช้ตาราง RFP เพื่อคัดเลือกผู้ให้บริการ
กำหนดคะแนนแต่ละเกณฑ์ตั้งแต่ 0–5 โดยใช้มาตรฐานเดียวกันกับผู้ให้บริการทุกราย
| คะแนน | คำอธิบาย |
|---|---|
| 0 | ไม่รองรับ หรือไม่มีข้อมูลประกอบ |
| 1 | รองรับได้น้อย มีข้อจำกัดสำคัญ |
| 2 | รองรับได้บางส่วน ยังมีช่องว่างที่ต้องแก้ไข |
| 3 | รองรับความต้องการหลักตามที่กำหนด |
| 4 | รองรับครบและมีหลักฐานตรวจสอบได้ |
| 5 | รองรับครบ มีผลทดสอบหรือหลักฐานที่น่าเชื่อถือ และมีความพร้อมในการส่งมอบ |
คำนวณคะแนนถ่วงน้ำหนักของแต่ละหัวข้อด้วยสูตร
คะแนนถ่วงน้ำหนัก = (คะแนนที่ได้รับ ÷ 5) × น้ำหนักของเกณฑ์
จากนั้นรวมคะแนนทั้ง 7 หัวข้อเพื่อเปรียบเทียบผู้ให้บริการ
ทั้งนี้ องค์กรควรแยก Mandatory Requirements ออกจากเกณฑ์ให้คะแนน เช่น ข้อกำหนดด้านความปลอดภัยที่ไม่สามารถยอมรับข้อยกเว้นได้ หรือความสามารถในการเชื่อมต่อกับระบบธุรกิจที่จำเป็น
หากผู้ให้บริการไม่ผ่านข้อกำหนดบังคับ ไม่ควรให้คะแนนด้านราคาเพียงอย่างเดียวมาชดเชยข้อจำกัดที่อาจทำให้โครงการไม่สามารถใช้งานได้จริง
หมายเหตุ: น้ำหนักและเกณฑ์คะแนนนี้เป็นตัวอย่างสำหรับการจัดทำ RFP ไม่ใช่มาตรฐานอุตสาหกรรมที่ใช้บังคับกับทุกองค์กร
Shared Responsibility: ใครต้องรับผิดชอบอะไรระหว่างองค์กรกับผู้ให้บริการ?
หนึ่งในความเสี่ยงของการใช้ Managed Service คือการเข้าใจว่าเมื่อมีผู้ให้บริการแล้ว ทุกหน้าที่ด้าน Security จะถูกโอนออกจากองค์กรทั้งหมด
ในความเป็นจริง ผู้ให้บริการสามารถรับผิดชอบการดำเนินงานตามสัญญาได้ แต่องค์กรยังต้องมีผู้รับผิดชอบด้าน Security Governance และการยอมรับความเสี่ยงทางธุรกิจ
ตัวอย่างการแบ่งหน้าที่แบบ RACI ระหว่างองค์กรกับ Managed SASE Provider มีดังนี้
| กิจกรรม | องค์กร | ผู้ให้บริการ |
|---|---|---|
| กำหนดนโยบายและระดับความเสี่ยงที่ยอมรับได้ | A/R | C |
| ออกแบบ Configuration ตาม Requirement | A | R |
| อนุมัติการเปลี่ยน Security Policy สำคัญ | A/R | C |
| ดำเนินการเปลี่ยน Configuration ที่อนุมัติแล้ว | A | R |
| Monitoring ตามขอบเขต Managed Service | I | A/R |
| วิเคราะห์และตอบสนอง Incident ภายใต้ขอบเขตบริการ | A | R |
| ประสานงานกับผู้ผลิต SASE | I | A/R |
| ประเมิน PDPA และข้อกำหนดทางกฎหมายขององค์กร | A/R | C |
| ทบทวนผลการให้บริการและความเสี่ยง | A/R | C |
ความหมายของ RACI
- R — Responsible: ผู้ปฏิบัติงาน
- A — Accountable: ผู้รับผิดชอบต่อผลลัพธ์หรือการตัดสินใจในกิจกรรมนั้น
- C — Consulted: ผู้ให้คำปรึกษาหรือข้อมูล
- I — Informed: ผู้ที่ต้องได้รับแจ้งข้อมูล
ตารางนี้เป็นตัวอย่างการแบ่งหน้าที่ในรูปแบบ Managed Service เท่านั้น ต้องปรับให้สอดคล้องกับรูปแบบสัญญา บุคลากร และอำนาจตัดสินใจของแต่ละองค์กร
สำหรับกิจกรรมที่เกี่ยวข้องกับ Cloud Platform หรือ ISP ภายนอก ควรระบุความรับผิดชอบของบุคคลที่สามเพิ่มเติมใน Responsibility Matrix ฉบับจริงด้วย
5 คำถามที่ต้องถามก่อนเซ็นสัญญา Managed SASE
นอกจากการประเมินเทคโนโลยีและคะแนน RFP แล้ว องค์กรควรถามคำถามต่อไปนี้เพื่อช่วยลดความเสี่ยงด้านการดำเนินงานในระยะยาว
1. เมื่อเกิดปัญหาข้ามระบบ ใครเป็นเจ้าของการประสานงานจนจบ?
ตรวจสอบว่าผู้ให้บริการจะทำหน้าที่เป็น Single Point of Contact หรือไม่ และมีขอบเขตประสานงานกับ ISP, Cloud Provider และผู้ผลิต SASE อย่างไร
2. Monitoring ตลอด 24 ชั่วโมงรวมการแก้ไขปัญหานอกเวลาทำการหรือไม่?
ขอรายละเอียด Incident Severity, Support Hours, Response Time และ Escalation Procedure เพื่อไม่ให้เกิดความเข้าใจคลาดเคลื่อนหลังเซ็นสัญญา
3. หากต้องเปลี่ยน Security Policy อย่างเร่งด่วน มีขั้นตอนอนุมัติและดำเนินการอย่างไร?
ควรกำหนด Emergency Change Process รวมถึงผู้มีอำนาจอนุมัติและการบันทึกการเปลี่ยนแปลง โดยไม่ทำให้ความเร็วในการแก้ปัญหากลายเป็นช่องว่างด้านความปลอดภัย
4. หากผู้ให้บริการหรือ SASE Cloud เกิดเหตุขัดข้อง องค์กรจะใช้งานระบบสำคัญต่อไปได้อย่างไร?
ขอให้แสดง Failover Design, Recovery Procedure และผลการทดสอบจริง รวมถึงระบุว่าระบบใดอาจได้รับผลกระทบ
5. เมื่อสิ้นสุดสัญญา องค์กรสามารถนำ Configuration, Log และข้อมูลของตนเองออกได้อย่างไร?
ตรวจสอบ Data Ownership, Data Export, Transition Support, Exit Fee และเงื่อนไขการลบข้อมูลหลังสิ้นสุดสัญญา
คำถามเหล่านี้ช่วยให้องค์กรประเมินคุณภาพของบริการที่ได้รับจริง ไม่ใช่เพียงคุณสมบัติของแพลตฟอร์มที่ระบุในเอกสารการขาย
ตัวอย่าง Use Case: เปรียบเทียบผู้ให้บริการ Managed SASE สำหรับองค์กรหลายสาขา
สมมติว่าองค์กรค้าปลีกแห่งหนึ่งมีสำนักงานใหญ่ในกรุงเทพฯ และมีสาขากระจายอยู่ในหลายจังหวัด โดยใช้ระบบ ERP ภายใน Data Center และ SaaS Application สำหรับการดำเนินงาน
องค์กรต้องการเปลี่ยนมาใช้ Managed SASE เพื่อลดความซับซ้อนในการดูแล Network และ Security แต่กำลังเปรียบเทียบผู้ให้บริการสองราย
ผู้ให้บริการ A: ค่าใช้จ่ายต่ำกว่า แต่ขอบเขตบริการจำกัด
ข้อเสนอมี SASE Platform, Basic Monitoring และ Technical Support ในเวลาทำการ แต่ไม่ได้รวมการเปลี่ยน Security Policy นอกเวลาทำการหรือการประสานงานกับ ISP
ผู้ให้บริการ B: ค่าใช้จ่ายสูงกว่า แต่มี Managed Operations ครอบคลุมกว่า
ข้อเสนอรวมการดูแล Configuration, Monitoring, Incident Escalation, Change Management และ Service Reporting ภายใต้ข้อตกลงที่ชัดเจน
องค์กรควรเลือกผู้ให้บริการรายใด?
ไม่สามารถสรุปได้จากราคาและรายการบริการเพียงอย่างเดียว
หากองค์กรมีทีม Network และ Security ภายในที่พร้อมดูแลระบบ ผู้ให้บริการ A อาจมีความเหมาะสม
แต่หากองค์กรต้องการลดภาระ Operation และมีสาขาที่ต้องเข้าถึงระบบสำคัญตลอดเวลา ผู้ให้บริการ B อาจตอบโจทย์มากกว่า หากผลการทดสอบและ SLA ผ่านเกณฑ์
วิธีตัดสินใจที่เหมาะสมคือกำหนด Requirement ให้ชัดเจน เปรียบเทียบ Service Scope ภายใต้มาตรฐานเดียวกัน และทำ PoC ก่อนลงนามในสัญญา
หมายเหตุ: กรณีผู้ให้บริการ A และ B เป็นตัวอย่างสมมติสำหรับอธิบายกระบวนการประเมิน ไม่ใช่การเปรียบเทียบบริษัทจริง
Proof of Concept: ก่อนเลือก Managed SASE ควรทดสอบอะไรบ้าง?
การทำ PoC ควรประเมินทั้งความสามารถของแพลตฟอร์มและคุณภาพการส่งมอบบริการ
สำหรับองค์กรในประเทศไทย ตัวอย่างหัวข้อทดสอบที่เหมาะสม ได้แก่
| รายการทดสอบ | เกณฑ์ประเมิน |
|---|---|
| Network Connectivity | การเชื่อมต่อจากสาขาและ Remote User ผ่าน ISP ที่ใช้จริง |
| Application Performance | Latency, Packet Loss และประสบการณ์ใช้งาน Application สำคัญ |
| Identity Integration | การทำงานร่วมกับ Identity Provider, MFA และ Access Policy |
| Security Policy | ความถูกต้องของการอนุญาตและปฏิเสธการเข้าถึง |
| Failover | การเปลี่ยนเส้นทางและการกู้คืนเมื่อ Network Path มีปัญหา |
| Incident Support | ขั้นตอนแจ้งเหตุ การรับเรื่อง และการประสานงาน |
| Change Management | ระยะเวลาดำเนินการและความถูกต้องของการเปลี่ยน Policy |
| Reporting | ความครบถ้วนของ Dashboard, Incident Log และ Service Report |
ควรกำหนดเกณฑ์ผ่านหรือไม่ผ่านก่อนเริ่ม PoC โดยอ้างอิงประสิทธิภาพของระบบเดิมและความต้องการของธุรกิจ
หากสามารถทดสอบได้ ควรมีสถานการณ์จำลองการขัดข้องและการเปลี่ยนนโยบาย เพื่อประเมินว่าผู้ให้บริการมีความพร้อมด้าน Operation จริงเพียงใด
PoC ที่ดีไม่ควรตอบได้เพียงว่าแพลตฟอร์มทำงานได้หรือไม่ แต่ควรแสดงให้เห็นว่าผู้ให้บริการสามารถดูแลระบบภายใต้สถานการณ์จริงได้ดีเพียงใด
WIT Perspective: Managed SASE ที่ดีต้องมี Service Accountability ไม่ใช่แค่เทคโนโลยีที่ดี
สำหรับองค์กรที่กำลังประเมิน Managed SASE ประเด็นสำคัญไม่ใช่การเลือกแพลตฟอร์มที่มีฟังก์ชันมากที่สุดเพียงอย่างเดียว แต่คือการกำหนดว่าองค์กรต้องการผลลัพธ์ด้าน Network, Security และ Service Operations อย่างไร
ผู้ให้บริการที่เหมาะสมควรสามารถแสดงให้เห็นถึงความเข้าใจในระบบเดิมขององค์กร ระบุขอบเขตความรับผิดชอบได้ชัดเจน และมีหลักฐานประกอบการประเมินทั้งด้าน Performance, Service Delivery และ Business Continuity
โดยเฉพาะองค์กรที่มีหลายสาขาในประเทศไทย การประเมินบริการควรครอบคลุมทั้งคุณภาพการเชื่อมต่อจากพื้นที่ใช้งานจริง การสนับสนุนเมื่อเกิดปัญหา และความพร้อมในการทำงานร่วมกับทีม IT ภายใน
Managed SASE จึงควรถูกประเมินในฐานะความสามารถในการส่งมอบและบริหารบริการระยะยาว ไม่ใช่เพียงการจัดซื้อ SASE License พร้อมบริการติดตั้ง
WIT (World Information Technology) ให้บริการด้าน Enterprise Networking, Cybersecurity Solutions, Solution Consulting และ System Integration สำหรับองค์กร รวมถึงนำเสนอเทคโนโลยี SASE เพื่อรองรับการเชื่อมต่อและความปลอดภัยของระบบ IT
องค์กรที่กำลังพิจารณา Managed SASE สามารถเริ่มจากการประเมิน Network Architecture และความต้องการด้าน Security เพื่อกำหนดขอบเขตบริการที่เหมาะสม ก่อนเปรียบเทียบข้อเสนอและพิจารณารูปแบบการบริหารจัดการร่วมกับผู้ให้บริการ
FAQ: คำถามที่พบบ่อยเกี่ยวกับการเลือกผู้ให้บริการ Managed SASE
Q1: Managed SASE คืออะไร?
Managed SASE คือรูปแบบบริการที่ผู้ให้บริการภายนอกช่วยออกแบบ ติดตั้ง และบริหารจัดการระบบ Secure Access Service Edge (SASE) โดยรวมความสามารถด้าน Network และ Cloud Security เข้ากับงาน Monitoring, Troubleshooting และการสนับสนุนด้าน Operation ตามขอบเขตที่ตกลงกัน
Q2: Managed SASE แตกต่างจากการซื้อ SASE License อย่างไร?
การซื้อ SASE License เป็นการจัดหาสิทธิ์ใช้งานแพลตฟอร์ม ส่วน Managed SASE เพิ่มบริการบริหารจัดการระบบ เช่น Configuration, Monitoring, Change Management และ Technical Support โดยรายละเอียดขึ้นอยู่กับ Service Scope และ SLA ของผู้ให้บริการ
Q3: องค์กรควรเลือก Fully Managed หรือ Co-managed SASE?
หากองค์กรมีทีม Network และ Security พร้อมดูแลบางส่วน Co-managed อาจเหมาะสม เพราะสามารถแบ่งหน้าที่กับผู้ให้บริการได้ แต่หากต้องการลดภาระ Operation อย่างมาก Fully Managed อาจตอบโจทย์กว่า ทั้งนี้ควรพิจารณาจากความพร้อมของบุคลากรและขอบเขตบริการที่ต้องการ
Q4: ผู้ให้บริการ Managed SASE ต้องมี PoP ในประเทศไทยหรือไม่?
ไม่จำเป็นเสมอไป แต่ควรมีเส้นทางเชื่อมต่อและประสิทธิภาพที่ตอบโจทย์ผู้ใช้งานในประเทศไทย องค์กรควรตรวจสอบ Latency, Application Performance, ISP Routing และ Failover จากพื้นที่ใช้งานจริง ไม่ควรพิจารณาจากตำแหน่ง PoP เพียงอย่างเดียว
Q5: Managed SASE จำเป็นต้องมีบริการ 24/7 หรือไม่?
ขึ้นอยู่กับความสำคัญของระบบและเวลาการดำเนินธุรกิจ หากองค์กรให้บริการตลอดเวลาอาจต้องการ Monitoring และ Incident Support แบบ 24/7 แต่ต้องตรวจสอบว่า SLA ครอบคลุมการแจ้งเตือน การวิเคราะห์ และการแก้ไขปัญหาในระดับใด
Q6: Managed SASE ช่วยให้องค์กรปฏิบัติตาม PDPA ได้หรือไม่?
Managed SASE สามารถสนับสนุนมาตรการรักษาความปลอดภัยและการควบคุมการเข้าถึงข้อมูลได้ แต่ไม่ได้รับประกันการปฏิบัติตาม PDPA โดยอัตโนมัติ องค์กรยังต้องตรวจสอบการประมวลผล Security Logs การส่งข้อมูลข้ามประเทศ สิทธิ์เข้าถึงข้อมูล และข้อกำหนดทางกฎหมายที่เกี่ยวข้อง
Q7: ควรเปรียบเทียบราคา Managed SASE อย่างไร?
ควรเปรียบเทียบ Total Cost of Ownership ตลอดอายุสัญญา ซึ่งรวม License, Managed Service Fee, Implementation, Hardware, Bandwidth, Support และค่าใช้จ่ายเมื่อขยายระบบ พร้อมตรวจสอบรายการที่ไม่รวมในข้อเสนอเพื่อหลีกเลี่ยงค่าใช้จ่ายเพิ่มเติมที่ไม่ได้วางแผนไว้
Q8: ต้องทำ PoC ก่อนเลือกผู้ให้บริการ Managed SASE หรือไม่?
สำหรับองค์กรที่มีระบบสำคัญหรือมีสาขาจำนวนมาก ควรทำ PoC เพื่อทดสอบ Network Performance, Security Policy, Integration และกระบวนการ Incident Support ในสภาพแวดล้อมจริง ก่อนตัดสินใจลงทุนและย้ายระบบ
Q9: หากมี SD-WAN หรือ Firewall อยู่แล้ว สามารถใช้ Managed SASE ได้หรือไม่?
สามารถประเมินการใช้งานร่วมกันได้ โดยขึ้นอยู่กับแพลตฟอร์ม ระบบเดิม และรูปแบบการเชื่อมต่อที่ต้องการ องค์กรอาจเลือกทำ Migration แบบเป็นระยะหรือใช้บางความสามารถร่วมกับระบบเดิม แต่ควรตรวจสอบข้อจำกัดและความรับผิดชอบในการบริหารระบบให้ชัดเจน
Q10: หากต้องการเปลี่ยนผู้ให้บริการ Managed SASE ในอนาคต ควรเตรียมอะไรบ้าง?
ควรกำหนด Exit Strategy ตั้งแต่เริ่มสัญญา โดยตรวจสอบ Data Ownership, การส่งออก Configuration และ Log, Transition Support, ระยะเวลาในการย้ายระบบ และเงื่อนไขการลบข้อมูล รวมถึงค่าใช้จ่ายที่อาจเกิดขึ้นเมื่อสิ้นสุดสัญญา
สรุป: เลือก Managed SASE Provider ต้องประเมินทั้งแพลตฟอร์มและความรับผิดชอบต่อบริการ
Managed SASE ช่วยให้องค์กรสามารถใช้เทคโนโลยี Network และ Cloud Security พร้อมบริการบริหารจัดการจากผู้ให้บริการภายนอก แต่ความสำเร็จไม่ได้ขึ้นอยู่กับแพลตฟอร์มเพียงอย่างเดียว
7 ปัจจัยที่ควรประเมินก่อนเลือกผู้ให้บริการ Managed SASE ได้แก่ Service Scope, Technical Capability, Network Performance, Managed Operations, SLA, PDPA และ TCO พร้อม Exit Strategy
สำหรับองค์กรในประเทศไทย ควรให้ความสำคัญกับการทดสอบ Network Performance จากพื้นที่ใช้งานจริง ความพร้อมของทีม Technical Support และข้อตกลงความรับผิดชอบเมื่อเกิดเหตุขัดข้อง
การจัดทำ RFP ที่มีเกณฑ์ชัดเจน ใช้ Responsibility Matrix และทดสอบ PoC ก่อนเซ็นสัญญา จะช่วยให้องค์กรเปรียบเทียบผู้ให้บริการได้อย่างเป็นระบบ และลดความเสี่ยงจากขอบเขตบริการที่ไม่สอดคล้องกับความต้องการในระยะยาว
ปรึกษา WIT เพื่อวางแนวทาง SASE และ Network Security สำหรับองค์กร
การเลือก SASE Platform และรูปแบบ Managed Service ควรเริ่มจากความเข้าใจโครงสร้าง Network และ Security ขององค์กร รวมถึงการประเมินข้อกำหนดด้าน Integration, Performance และการบริหารระบบ
WIT (World Information Technology) ให้บริการด้าน Cybersecurity และ Enterprise Networking สำหรับองค์กร พร้อมให้คำปรึกษาด้านสถาปัตยกรรมและการเลือกโซลูชันที่สอดคล้องกับระบบ IT และความต้องการทางธุรกิจ
หากองค์กรของคุณกำลังพิจารณา SASE หรือประเมินรูปแบบการดูแลระบบ Network และ Security สามารถติดต่อทีม WIT เพื่อหารือเกี่ยวกับความต้องการและแนวทางเลือกโซลูชันที่เหมาะสม
ติดต่อทีม WIT: https://www.wit.co.th/
References
- NIST — Guide to a Secure Enterprise Network Landscape (SP 800-215)
https://csrc.nist.gov/pubs/sp/800/215/final - NIST — Zero Trust Architecture (SP 800-207)
https://csrc.nist.gov/pubs/sp/800/207/final - UK National Cyber Security Centre — Choosing a Managed Service Provider
https://www.ncsc.gov.uk/guidance/choosing-a-managed-service-provider-msp - CISA — Modern Approaches to Network Access Security
https://www.cisa.gov/sites/default/files/2024-06/joint-guide-modern-approaches-to-secure-network-access-security-508c.pdf - สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล — หลักเกณฑ์การส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศตามมาตรา 28
https://gdcatalog.go.th/en/dataset/gdpublish-dataset-11-056 - สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล — หลักเกณฑ์การส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศตามมาตรา 29
https://data.go.th/th/dataset/dataset_11_0611
