SD-WAN กับ SASE ต่างกันอย่างไร และ Firewall ของสาขาย้ายไปอยู่ไหน

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

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

SD-WAN และ SASE คือสองคำตอบที่เครือข่ายส่วนใหญ่เลือกใช้ ทั้งสองคำถูกพูดถึงคู่กันบ่อยจนเหมือนเป็นตัวย่อเดียวกัน บทความนี้จะแยกทั้งสองออกจากกันทีละคำถาม โดยใช้ NIST SP 800-215 เป็นเอกสารอ้างอิงกลาง และใช้เอกสารของ vendor เองสำหรับรายละเอียดของผลิตภัณฑ์ครับ

ถาม: แบบเดิมมีปัญหาอะไร?

ไม่มีปัญหาเลยถ้าแอปยังอยู่ใน data center ปัญหาเริ่มเมื่อแอปไม่ได้อยู่ที่นั่นแล้วครับ

NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (พฤศจิกายน พ.ศ. 2565) ระบุปัญหานี้ไว้ตรง ๆ ในหัวข้อข้อจำกัดของ MPLS เครือข่าย MPLS เป็นเครือข่ายแยกต่างหาก จึงออกอินเทอร์เน็ตได้ผ่านจุดที่กำหนดไว้ไม่กี่จุดเท่านั้น NIST เปรียบว่าคล้ายปรากฏการณ์ hairpinning และชี้ว่าทำให้ latency ของแอปที่ไวต่อเวลาสูงขึ้น (SP 800-215 หัวข้อ 2.3) นอกจากนี้ยังชี้ว่าการใช้เทคโนโลยีที่ต่างออกไป ซึ่งมีอุปกรณ์และวิธีตั้งค่าของตัวเอง ทำให้การบริหารเครือข่ายซับซ้อนขึ้น

รัฐบาลสหรัฐฯ ก็เจอปัญหาเดียวกันในขนาดที่ใหญ่กว่ามาก โครงการ Trusted Internet Connections (TIC) ของ CISA มีมาตั้งแต่ปี พ.ศ. 2550 เพื่อรวมจุดเชื่อมต่อเครือข่ายของหน่วยงานรัฐบาลกลางให้เหลือน้อยลง ภายใต้บันทึก OMB M-19-26 หน่วยงานไม่จำเป็นต้องส่งทราฟฟิกผ่าน TIC access point อีกต่อไป หากมีทางเลือกอื่นแทน (TIC alternative) ใน TIC 3.0 Branch Office Use Case (version 2.0 เมษายน พ.ศ. 2566) CISA เขียนเป้าหมายไว้ชัดเจน คือประสิทธิภาพของแอปที่ดีขึ้น (latency, throughput, jitter) ต้นทุนที่ลดลงจากการใช้ลิงก์ส่วนตัวน้อยลง และประสบการณ์ที่ดีขึ้นของผู้ใช้ที่สาขา

BEFORE: backhaul through HQ                                     
                          ┌──────────┐                          
                          │   SaaS   │─────────────────┐        
                          └──────────┘                 │        
┌─────────┐                                       ┌────┴──────●┐
│ branch  │■──────────────────────────────────────│ HQ firewall│
└─────────┘                                       └────────────┘
                                                                
                                                                
AFTER: direct via a nearby SASE PoP                             
             ┌──────●┐    ┌──────────┐                          
             │ PoP   │────│   SaaS   │                          
             └───┬───┘    └──────────┘                          
                 │                                              
┌─────────┐      │                                ┌────────────┐
│ branch  │■─────┘                                │ HQ: private│
└─────────┘                                       └────────────┘
                                                                

ถาม: แล้ว SD-WAN ทำอะไรจริง ๆ?

แก่นของ SD-WAN คือให้สาขาใช้หลายลิงก์พร้อมกัน และตัดสินใจว่าแต่ละแอปควรใช้ลิงก์ไหนในตอนนั้น

NIST อธิบายว่า SD-WAN แยก control plane ออกจาก data plane ของเครือข่าย ทำให้กำหนด policy ด้าน access control, routing และลำดับความสำคัญของแอปได้จากศูนย์กลาง (SP 800-215 หัวข้อ 6) ในบรรดาเป้าหมายการออกแบบที่ NIST ระบุไว้ มีสองข้อที่สำคัญที่สุดสำหรับบทความนี้

• ใช้ transport อะไรก็ได้ เชื่อมผู้ใช้กับแอปผ่าน MPLS, broadband internet, 4G/LTE หรือ 5G
• รู้จักแอป (application awareness) เฝ้าดูทราฟฟิกแล้วเลือกเส้นทางที่ดีที่สุดในขณะนั้น ตามประเภทของทราฟฟิก ภาระของเครือข่าย และความสำคัญของแอปต่อธุรกิจ สิ่งนี้อาศัยการวัดค่าอย่าง latency, jitter และ packet loss รวมถึงการแยกได้ว่าแต่ละ flow เป็นของแอปไหน

นี่คือส่วนที่เป็น "สมอง" tunnel ระหว่างไซต์ (overlay) วิ่งอยู่บนลิงก์ที่มีอยู่ (underlay) และสมองเป็นตัวย้ายแอปไปมาระหว่างลิงก์

ถาม: "เลือกเส้นทางที่สุขภาพดีกว่า" ในผลิตภัณฑ์จริงหน้าตาเป็นอย่างไร?

เอกสารของ vendor ทำให้เห็นภาพชัดขึ้น Palo Alto Networks อธิบาย Prisma SD-WAN ว่าเป็น SD-WAN แบบ app-defined ที่ส่งมอบจากคลาวด์ และทำ virtualization ให้ transport หลายแบบรวมกันเป็น hybrid WAN ที่เป็นหนึ่งเดียว (unified hybrid WAN) เอกสารเรื่อง performance policy แสดงให้เห็นว่าการเลือกเกิดขึ้นอย่างไร

เอกสารยังระบุค่า threshold เริ่มต้นไว้ด้วย สำหรับ media apps คือ latency 150 ms, packet loss 2% และ jitter 40 ms ส่วนแอปอื่นทั้งหมดคือ latency 500 ms, packet loss 5% และ jitter 100 ms เมื่อเส้นทางใดผิด SLA การตอบสนองหลักคือย้าย flow ไปยังเส้นทางที่ยังผ่าน SLA รายละเอียดตรงนี้ควรอ่านให้ดีครับ ถ้าเป็นการละเมิด application metric จะย้ายเฉพาะ flow ใหม่ ถ้าเป็นการละเมิด link quality metric จะย้ายได้ทั้ง flow ใหม่และ flow ที่มีอยู่ซึ่งวิ่งบน VPN fabric ของ Prisma SD-WAN เอง (Fabric VPN) ตราบที่ยังอยู่ใน NAT boundary เดียวกัน หน้าเดียวกันยังอธิบายตัวเลือก line conditioning คือ forward error correction และ packet duplication สำหรับลิงก์ที่ทำ packet หาย

 BRANCH                                     SASE PoP    SaaS app
                                                                
                                                                
                                                                
             A broadband ▮▮▮▮▮ loss 0%                          
┌─────────┐   ──────■────────■─────\         ·······            
│ branch  │  /                      \\     ··       ··  ┌──────┐
│         │ /                         \\  ··SWG FWaaS · │      │
│[SD-WAN]●│■                            ──·────◆──────·─│ app  │
│         │ \                         ■/  · CASB ZTNA · │      │
│         │  \                      //     ··       ··  └──────┘
└─────────┘   ─────────────────────/         ·······            
             B LTE       ▮▮▮▮▯ loss 0%                          
                                                                
 SLA for this app: loss < 5%                                    
 new flows use: link A                                          
                                                                
 SD-WAN picks the path; the PoP inspects every flow             

รายละเอียดที่ว่า flow ใหม่กับ flow เดิมทำงานต่างกันได้นั้นมองข้ามง่าย ถ้า session ที่เปิดค้างไว้นานยังอยู่บนลิงก์ที่แย่ ขณะที่ session ใหม่ย้ายไปแล้ว ผู้ใช้จะเห็นแท็บหนึ่งค้าง ขณะที่อีกแท็บรีโหลดได้ปกติ การรู้ว่ากฎข้อไหนมีผลช่วยให้ไม่ต้องงงตอน troubleshoot ครับ

ถาม: แล้ว SASE เข้ามาตรงไหน?

SD-WAN แก้เรื่องเส้นทาง แต่ไม่ได้พูดถึงการตรวจเลย ถ้าทุกสาขามีลิงก์อินเทอร์เน็ตของตัวเองแล้ว ก็ยังต้องมีอะไรสักอย่างมาทำงานแทน Firewall ที่สำนักงานใหญ่ครับ

NIST อธิบายว่าคำว่า "secure access service edge" (SASE) ถูกตั้งขึ้นโดย Gartner ในปี พ.ศ. 2562 สำหรับสถาปัตยกรรมที่รวมฟังก์ชันด้าน networking และ security เข้าด้วยกัน แล้วส่งมอบเป็นบริการบนคลาวด์ในระดับโลก องค์กรเข้าถึงบริการนั้นผ่านจุด point of presence (PoP) NIST ย้ำประเด็นหนึ่งที่ลืมกันง่าย คือบริการที่อยู่ใน SASE ไม่ใช่ของใหม่ เพียงแค่ส่งมอบรวมกันเป็นแพ็กเกจเดียวแทนที่จะแยกเป็นหลายผลิตภัณฑ์ (SP 800-215 หัวข้อ 6) บริการขั้นต่ำที่ NIST พบในข้อเสนอเชิงพาณิชย์ส่วนใหญ่คือ firewall, secure web gateway, anti-malware, IPS, CASB และ DLP

บทความอธิบายของ Palo Alto เองนิยาม SASE ว่าเป็นสถาปัตยกรรมแบบ cloud-native ที่รวม SD-WAN เข้ากับฟังก์ชันด้าน security และแจกแจงองค์ประกอบไว้ดังนี้

• SWG (secure web gateway): URL filtering, SSL decryption, application control และการตรวจจับภัยคุกคามสำหรับทราฟฟิกเว็บ
• FWaaS (firewall as a service): next-generation firewall ที่ส่งมอบจากคลาวด์ NIST เองก็ระบุ "a cloud service (FWaaS)" เป็นหนึ่งในรูปแบบการติดตั้ง NGFW (SP 800-215 หัวข้อ 3)
• CASB (cloud access security broker): มองเห็นและควบคุม SaaS ทั้งที่องค์กรอนุมัติและไม่ได้อนุมัติ NIST เล่าที่มาไว้ว่า CASB รุ่นแรกเน้นค้นหา shadow IT ส่วนรุ่นปัจจุบันบังคับใช้ policy และ DLP กับแอปบนคลาวด์
• ZTNA (zero trust network access): บังคับใช้ policy ตามตัวตน (identity-based) และตามแอป (application-based) พร้อมตรวจสอบอย่างต่อเนื่อง จึงให้สิทธิ์เข้าถึงเฉพาะแอป ไม่ใช่ทั้งเครือข่าย

พูดง่าย ๆ คือ SD-WAN เลือกถนน ส่วน SASE ย้ายด่านตรวจออกจากสถานที่ของเราไปไว้ที่ PoP บนคลาวด์ที่อยู่ใกล้ครับ

ถาม: Prisma Access กับ Zscaler อธิบายโมเดลของตัวเองอย่างไร?

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

Prisma Access (Palo Alto Networks) อธิบายตัวเองว่าเป็นบริการที่ให้ความปลอดภัยที่สม่ำเสมอแก่ remote networks และ mobile users เอกสารแบ่งโมเดลเป็นการเชื่อมต่อสามแบบ

• Remote networks: สาขาเชื่อมผ่าน IPsec tunnel จาก Palo Alto NGFW หรือจากอุปกรณ์ third-party ที่ทำ IPsec ได้ รวมถึง SD-WAN Palo Alto ติดตั้ง Firewall บนคลาวด์ไว้ปกป้องไซต์เหล่านั้น จึงไม่ต้องดูแล Firewall ที่ทุกไซต์
• Mobile users: แอป GlobalProtect สร้าง tunnel แบบ IPsec หรือ SSL หรือให้ endpoint ใช้ explicit proxy ผ่าน PAC file
• Service connections: การเชื่อมกลับไปที่สำนักงานใหญ่หรือ data center เพื่อเข้าถึงทรัพยากรภายใน เช่น ระบบ authentication ที่อยู่ on-premises Palo Alto แนะนำให้สร้างไว้เสมอ

Zscaler แบ่งงานออกเป็นสองบริการ Zscaler Internet Access (ZIA) ดูแลทราฟฟิกอินเทอร์เน็ตและ SaaS โดยมี Public Service Edge เป็น gateway แบบ inline ที่ตรวจทราฟฟิกทั้งสองทิศทาง ซึ่ง Zscaler ระบุว่าติดตั้งอยู่ใน data center ของตัวเองทั่วโลก และมี Central Authority เป็นที่เก็บ policy และค่าตั้งค่าทั้งหมด ส่วน Zscaler Private Access (ZPA) ดูแลแอปภายใน โดยมี App Connector ขนาดเล็กวางไว้ข้างแอปและเชื่อมต่อแบบขาออกเท่านั้น แอปจึงไม่ต้องรับการเชื่อมต่อจากอินเทอร์เน็ต Zscaler ใช้คำว่า "application access does not require network access"

เอกสารของ ZIA ระบุวิธีส่งต่อทราฟฟิก (traffic forwarding) เข้าสู่บริการไว้หลายวิธี ได้แก่ Zscaler Client Connector, GRE tunnel, IPsec tunnel, PAC file, proxy chaining, Cloud Connector และ Branch Connector และ Zscaler แนะนำให้ใช้หลายวิธีผสมกันแทนการเลือกวิธีเดียว

มีรายละเอียดด้านการออกแบบข้อหนึ่งที่ควรรู้ ถ้า Public Service Edge ของ ZIA ติดต่อ Central Authority ไม่ได้ จะสลับเข้าสู่ Safe mode โดยยังบังคับใช้ policy ที่ cache ไว้ต่อไป และถ้าดึง policy ของผู้ใช้คนใดไม่ได้ ก็จะใช้ URL policy เริ่มต้นแทน การอ่านว่าบริการทำงานอย่างไรเมื่อบางส่วนของมันมีปัญหา บอกอะไรเราได้มากกว่ารายการฟีเจอร์ครับ

 USER                 CLOUD BROKER             PRIVATE NETWORK  
                                             ┌┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
                    ┌──────────────┐         ┆                  
┌────────┐          │    broker  ● │         ┆ ┌─────────┐      
│  user  │          │              │ outbound┆ │connector│      
│        │◆─────────┼──────────────┼═════◂═══╪◂│         │      
│ +agent │          │              │         ┆ │         │      
└────────┘          │ [ ] user     │         ┆ └───┬─────┘      
                    │ [ ] device   │         ┆     │            
                    │ [ ] policy   │         ┆     └─ app A     
                    └──────────────┘         ┆                  
                                             ┆      ✗ app B     
 decision: pending                           ┆                  
 inbound ports open: none                    ┆      ✗ app C     
                                             ┆                  
                                             └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
 the connector dials out; the broker stitches one session       
 access to one app, not to the network                          

ถาม: แปลว่า Firewall ที่สาขาหายไปเลยหรือเปล่า?

ไม่เสมอไปครับ และมาตรฐานก็ไม่ได้บอกแบบนั้น Branch Office Use Case ของ CISA เขียนไว้ในหัวข้อ resilience ว่าหน่วยงานควรพิจารณาว่าบริการไหนรวมไว้ที่ศูนย์กลางได้ และบริการไหนควรติดตั้งที่สาขา โดยชั่งน้ำหนักเรื่อง availability, compliance, ต้นทุน, การบริหารจัดการ และระดับความเสี่ยงที่ยอมรับได้ (TIC 3.0 Branch Office Use Case)

ในความเห็นของผม นี่คือจุดที่อุปกรณ์ที่ไซต์ยังมีประโยชน์อยู่ครับ

• ทราฟฟิกที่ไม่เคยออกนอกอาคาร PoP บนคลาวด์เห็นเฉพาะสิ่งที่ถูกส่งไปหามันเท่านั้น การแบ่ง segment ระหว่างอุปกรณ์ภายใน เช่น โน้ตบุ๊กของผู้ใช้ เครื่องพิมพ์ กล้อง หรือระบบอาคาร ต้องบังคับใช้ที่ไซต์ NIST อธิบายการแยกภายในแบบนี้ไว้ในหัวข้อ microsegmentation (SP 800-215 หัวข้อ 5.1)
• ลิงก์ที่ล่ม ถ้า tunnel ไป PoP ล่มทุกเส้น ต้องตัดสินใจไว้ล่วงหน้าว่าสาขาจะ fail closed (ไม่มีอินเทอร์เน็ต) หรือ fail open (ออกอินเทอร์เน็ตตรงโดยไม่ผ่านการตรวจ)
• กฎที่ต้องควบคุมในพื้นที่ บางสภาพแวดล้อมที่มีข้อกำกับต้องการจุดตรวจหรือการเก็บ log แบบที่บริการคลาวด์ที่ใช้ร่วมกันอาจรองรับไม่ได้

บ่อยครั้งอุปกรณ์ที่ไซต์จะเล็กลงเหลือแค่ SD-WAN edge ที่มี Firewall พื้นฐาน ส่วนการตรวจหนัก ๆ ไปเกิดที่ PoP แบบนี้เหมาะหรือไม่ขึ้นกับแต่ละไซต์

ถาม: ควรถามอะไรก่อน migrate?

checklist ที่ผมอยากได้คำตอบก่อนย้ายสาขามีดังนี้ครับ

1. แอปไหนไปทางไหน? แยกรายการ SaaS, อินเทอร์เน็ต และแอปภายในออกจากกัน แอปภายในเป็นตัวตัดสินว่าต้องมี service connection, App Connector หรืออะไรทำนองนั้นหรือไม่
2. policy เหมือนกันทุกเส้นทางหรือไม่? CISA เรียกเรื่องนี้ว่า policy enforcement parity ถ้าใช้ลิงก์สำรองหรือ SD-WAN ลำดับความสำคัญของเส้นทางและลำดับการทำงานของฟังก์ชัน security ควรให้การป้องกันเท่ากันทุกเส้นทาง ผู้โจมตีจะได้เลือกเส้นทางที่ตรวจน้อยกว่าไม่ได้ (TIC 3.0 Branch Office Use Case)
3. SLA แบบไหนย้าย flow แบบไหน? ทำความรู้จักค่าเริ่มต้น (ดู threshold ของ Prisma SD-WAN ข้างบน) แล้วตัดสินใจว่าแอปไหนควรได้ค่าที่เข้มกว่า
4. ส่งทราฟฟิกด้วยวิธีไหน: tunnel, agent หรือ proxy? แต่ละวิธีเห็นทราฟฟิกต่างกัน PAC file ครอบคลุมเฉพาะแอปที่รู้จัก proxy
5. ถ้าพังจะเกิดอะไรขึ้น? tunnel ล่ม PoP ติดต่อไม่ได้ บริการ policy ติดต่อไม่ได้ เขียนพฤติกรรมที่คาดไว้แล้วทดสอบใน change window
6. log ไปที่ไหน? ตรวจให้แน่ใจว่า log จาก PoP ไปถึง SIEM CISA ขอให้หน่วยงานนำ telemetry จากสาขาและคลาวด์เข้าเครื่องมือ situational awareness
7. อะไรยังอยู่ที่ไซต์? เขียนการแบ่ง segment แบบ east-west ที่สาขายังต้องมีไว้ให้ชัด

สรุปสั้น ๆ

SD-WAN ตอบคำถามว่า "ไปถนนไหน" โดยวัดแต่ละลิงก์แล้วย้ายแอปไปยังลิงก์ที่ผ่าน SLA ส่วน SASE ตอบคำถามว่า "ด่านตรวจอยู่ที่ไหน" โดยย้าย secure web gateway, Firewall, CASB และ ZTNA ไปเป็นบริการบนคลาวด์ที่มี PoP อยู่ใกล้ผู้ใช้ Firewall ไม่ได้หายไป ส่วนใหญ่ย้ายขึ้นคลาวด์ และส่วนที่เล็กลงยังอยู่ที่ขอบของแต่ละไซต์ครับ

แหล่งอ้างอิง

• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (หน้าเผยแพร่)
• NIST SP 800-215, ฉบับเต็ม (PDF)
• CISA, Trusted Internet Connections (TIC)
• CISA, TIC 3.0 Branch Office Use Case, version 2.0 (PDF, เมษายน พ.ศ. 2566)
• Palo Alto Networks, What is SASE?
• Palo Alto Networks, Prisma SD-WAN documentation
• Palo Alto Networks, Prisma SD-WAN performance policy
• Palo Alto Networks, Prisma Access documentation
• Palo Alto Networks, Prisma Access remote networks
• Palo Alto Networks, Prisma Access mobile users
• Palo Alto Networks, Prisma Access service connections
• Zscaler, Understanding the Zscaler Cloud Architecture for Internet & SaaS
• Zscaler, Understanding Public Service Edges for Internet & SaaS
• Zscaler, Choosing Traffic Forwarding Methods
• Zscaler, What Is Private Access?