NGFW, UTM และ WAF ต่างกันอย่างไร และเลือกอย่างไร

NGFW, UTM และ WAF มักถูกนำมาเทียบกัน เพราะทั้งสามถูกเรียกว่า "ไฟร์วอลล์" เหมือนกัน แต่แต่ละตัวปกป้องคนละส่วน Next-generation firewall (NGFW) คือไฟร์วอลล์รุ่นใหม่ที่ควบคุมทราฟฟิกตามแอปพลิเคชัน ผู้ใช้ และเนื้อหา ใช้ที่ขอบเครือข่ายหรือคั่นระหว่างส่วนต่าง ๆ ภายในเครือข่าย Unified threat management (UTM) คืออุปกรณ์ที่รวมไฟร์วอลล์กับฟังก์ชันความปลอดภัยอื่นอีกหลายอย่างไว้ในกล่องเดียว และจัดการผ่านคอนโซลเดียว Web application firewall (WAF) วางอยู่หน้าเว็บแอปพลิเคชันและกรองทราฟฟิก HTTP ซึ่งเป็นทราฟฟิกที่เบราว์เซอร์ใช้คุยกับเว็บ ทั้งสามไม่ได้เรียงเป็นบันไดที่ตัวถัดไปมาแทนตัวก่อนหน้า หลายองค์กรจึงต้องใช้มากกว่าหนึ่งอย่าง

แต่ละตัวคืออะไร

• NGFW (next-generation firewall): ไฟร์วอลล์ที่เพิ่มความเข้าใจระดับแอปพลิเคชันเข้ากับการกรองแบบเดิม NIST SP 800-215 ระบุว่าจุดเด่นของ NGFW คือการรับรู้ข้อมูลระดับแอปพลิเคชัน คือมองได้ทั้งชั้น 3 และ 4 (ที่อยู่ IP และพอร์ต) รวมถึงชั้น 7 (เนื้อหาของแอป) ความสามารถที่พบบ่อยคือ deep packet inspection หรือ DPI (การตรวจลึกลงไปถึงข้อมูลในแพ็กเก็ต) การถอดรหัสและตรวจ TLS (โปรโตคอลเข้ารหัสที่เว็บใช้) และ IPS (ระบบป้องกันการบุกรุกที่บล็อกการโจมตีได้) NGFW จะเป็นอุปกรณ์ ซอฟต์แวร์บน VM บนคลาวด์ หรือบริการคลาวด์ (FWaaS คือไฟร์วอลล์ที่ให้บริการผ่านคลาวด์) ก็ได้
• UTM (unified threat management): SP 800-215 อธิบายว่า UTM รวมไฟร์วอลล์ IPS VPN concentrator (อุปกรณ์รับการเชื่อมต่อ VPN จากผู้ใช้) แอนตี้ไวรัสที่เกตเวย์ การกรองเนื้อหา และ WAN load balancing (การกระจายทราฟฟิกไปหลายเส้นทางอินเทอร์เน็ต) ไว้ในอุปกรณ์เดียว โดยมักมีคอนโซลจัดการเดียว NIST SP 800-41 Rev. 1 ชี้ข้อแลกเปลี่ยนไว้ว่า ระบบเดียวทำให้จัดการง่ายขึ้น แต่ต้องมีทุกฟีเจอร์ที่ต้องการ และต้องมี CPU กับหน่วยความจำพอจะรันทุกหน้าที่พร้อมกัน
• WAF (web application firewall): OWASP อธิบายว่า WAF เป็นไฟร์วอลล์สำหรับแอปพลิเคชัน HTTP ที่ใช้ชุดกฎตรวจการสื่อสารแบบถาม-ตอบระหว่างผู้ใช้กับเว็บแอป WAF ปกป้องเว็บแอปเฉพาะตัว มักวางเป็น reverse proxy (ตัวกลางที่รับคำขอแทนแอป) อยู่หน้าแอป กฎของ WAF มุ่งไปที่การโจมตีที่พบบ่อย เช่น cross-site scripting หรือ XSS (การแทรกสคริปต์อันตรายลงในหน้าเว็บ) และ SQL injection (การแทรกคำสั่งฐานข้อมูลผ่านช่องกรอกข้อมูล)

ไฟร์วอลล์พัฒนามาอย่างไร

NIST SP 800-41 Rev. 1 (กันยายน 2009) เล่าพัฒนาการของไฟร์วอลล์ไว้เป็นลำดับ เริ่มจาก packet filtering (กรองตามที่อยู่และพอร์ต) ต่อมาเป็น stateful inspection (ติดตามสถานะของการเชื่อมต่อ) จากนั้นเป็น application firewall ที่ใช้การวิเคราะห์โปรโตคอลแบบ stateful (บางผู้ผลิตเรียกว่า deep packet inspection) เพื่อตรวจว่าแอปพลิเคชันทำงานผิดปกติหรือไม่ เช่น บล็อกไฟล์แนบที่เป็นไฟล์ปฏิบัติการ NIST ระบุด้วยว่าไฟร์วอลล์แบบนี้ไม่ใช่ระบบตรวจจับและป้องกันการบุกรุกเต็มรูปแบบ เอกสารปี 2009 ฉบับนี้ยังไม่ใช้คำว่า NGFW คำนี้ไปปรากฏในเอกสาร NIST รุ่นหลัง เช่น SP 800-215 (พฤศจิกายน 2022)

ในทางปฏิบัติ ชื่อเรียกเหล่านี้ทับซ้อนกัน ชื่อบนกล่องจึงไม่รับประกันว่าจะมีฟีเจอร์ครบตามที่คิด ควรเทียบที่ความสามารถและไลเซนส์ ไม่ใช่ชื่อผลิตภัณฑ์ ควรถามให้ชัดว่าฟังก์ชันใดรวมมาแล้ว ฟังก์ชันใดต้องซื้อ subscription (สิทธิ์ใช้งานแยก) เพิ่ม และเมื่อเปิดทุกฟีเจอร์พร้อมกันจะได้ throughput (ปริมาณทราฟฟิกที่อุปกรณ์รับได้) เท่าไร เรื่องสุดท้ายนี้ตรงกับข้อแลกเปลี่ยนด้านประสิทธิภาพที่ NIST กล่าวถึงสำหรับ UTM

WAF อยู่ตรงไหน

WAF แก้คนละปัญหากับสองตัวแรก NIST SP 800-41 Rev. 1 ระบุว่า HTTP ถูกโจมตีได้หลายวิธี จึงมี application firewall เฉพาะทางที่เรียกว่า web application firewall วางอยู่หน้าเว็บเซิร์ฟเวอร์ NIST เสริมว่าไฟร์วอลล์ประเภทนี้มักถูกมองว่าต่างจากไฟร์วอลล์แบบดั้งเดิมมาก ความต่างสรุปได้ว่า NGFW ตัดสินว่าผู้ใช้หรือแอปใดสื่อสารข้ามเครือข่ายได้หรือไม่ ส่วน WAF อ่านเนื้อหาของคำขอที่ส่งถึงเว็บแอปตัวหนึ่ง แล้วดูว่าคำขอนี้เข้าข่ายการโจมตีแอปนั้นหรือไม่

มีข้อจำกัดสองข้อที่ต้องจำ ข้อแรก OWASP ระบุว่าการปรับ WAF ให้เข้ากับแอปแต่ละตัวอาจต้องใช้ความพยายามมาก และต้องดูแลต่อเนื่องเมื่อแอปเปลี่ยน ข้อสอง ชุดกฎทั่วไปอาจแจ้งเตือนผิดพลาด (false positive) OWASP Core Rule Set (CRS) เป็นชุดกฎโอเพนซอร์สสำหรับ ModSecurity (เอนจิน WAF โอเพนซอร์ส) และ WAF ที่ใช้ร่วมกันได้ CRS นิยาม false positive ว่าคือกรณีที่ธุรกรรมที่ถูกต้องไปตรงกับกฎโดยผิดพลาด และระบุว่า paranoia level (ระดับความเข้มของกฎ) ยิ่งสูง ยิ่งจับการโจมตีได้มากขึ้น แต่ก็เกิด false positive มากขึ้นด้วย โดยมีทั้งหมด 4 ระดับ ถ้า WAF อยู่ในโหมดบล็อก false positive เหล่านี้จะบล็อกผู้ใช้จริง นอกจากนี้ WAF ไม่ได้แก้โค้ดที่มีช่องโหว่อยู่ด้านหลัง การแพตช์และการพัฒนาอย่างปลอดภัยจึงยังต้องมาก่อน

เปรียบเทียบแบบเคียงข้างกัน

• เลือก NGFW เมื่อ ต้องควบคุมทราฟฟิกตามแอปและผู้ใช้ ไม่ว่าจะที่ขอบเครือข่าย ระหว่างส่วนต่าง ๆ ของเครือข่าย หรือในดาต้าเซนเตอร์ และต้องการ IPS กับการตรวจ TLS ด้วย
• เลือก UTM เมื่อ สำนักงานสาขาหรือทีมเล็กต้องการหลายฟังก์ชันในกล่องเดียวที่จัดการง่าย และปริมาณทราฟฟิกอยู่ในระดับที่กล่องรับได้ แม้เปิดทุกฟีเจอร์พร้อมกัน
• เลือก WAF เมื่อ เปิดเว็บแอปหรือ API สู่อินเทอร์เน็ต โดยเฉพาะระบบที่แพตช์ไม่ทันหรือไม่ได้พัฒนาเอง
• ใช้ร่วมกันเมื่อ องค์กรให้บริการเว็บแอปสาธารณะเอง ให้วาง NGFW หรือ UTM ที่ขอบเครือข่าย และวาง WAF ไว้หน้าชั้นเว็บ

ติดตั้ง WAF โดยไม่ทำให้เว็บล่ม

ความผิดพลาดที่พบบ่อยที่สุดคือเปิดโหมดบล็อกตั้งแต่วันแรก ไฟล์คอนฟิกที่ ModSecurity แนะนำตั้งค่า rule engine (ส่วนที่ใช้ชุดกฎตรวจทราฟฟิก) เป็นโหมด detection-only (ตรวจและแจ้งเตือนอย่างเดียว ไม่บล็อก) ตั้งแต่ต้น พร้อมคอมเมนต์ว่าช่วยลดโอกาสที่ระบบจะหยุดชะงักหลังติดตั้ง แนวคิดนี้ใช้ได้กับ WAF ทุกตัว ทั้งแบบเชิงพาณิชย์และบนคลาวด์ คือสังเกตดูก่อน แล้วค่อยบังคับใช้

ข้อควรระวัง

• ใช้ WAF แทนการแพตช์: WAF ช่วยลดความเสี่ยงระหว่างที่แก้แอป แต่ไม่ได้แก้โค้ดที่มีช่องโหว่
• ซื้อ UTM เพราะดูแค่รายการฟีเจอร์ แล้วมองข้ามประสิทธิภาพ: NIST เตือนว่าระบบเดียวต้องมี CPU และหน่วยความจำพอสำหรับทุกหน้าที่ ควรทดสอบโดยเปิดการตรวจทุกอย่างพร้อมกัน
• ไม่วางแผนเรื่อง TLS inspection: ทราฟฟิกที่เข้ารหัสจะตรวจเนื้อหาไม่ได้ถ้าไม่ถอดรหัสก่อน ซึ่งนำไปสู่คำถามเรื่องใบรับรอง ความเป็นส่วนตัว กฎหมาย และประสิทธิภาพ ควรกำหนดขอบเขตและข้อยกเว้นให้ชัดก่อนเปิดใช้
• บล็อกตั้งแต่วันแรก: ชุดกฎทั่วไปทำให้เกิด false positive ที่บล็อกผู้ใช้จริง ควรเริ่มด้วยการตรวจจับอย่างเดียว
• ลืมว่ากฎล้าสมัยได้: OWASP ระบุว่าการตั้งค่า WAF ต้องดูแลต่อเมื่อแอปเปลี่ยน ควรทบทวนหลังปล่อยเวอร์ชันใหม่ทุกครั้ง
• เข้าใจว่าชื่อ "NGFW" บนกล่องแปลว่าฟีเจอร์เปิดใช้อยู่: ไลเซนส์ subscription และนโยบายที่เปิดใช้จริงต่างหากที่กำหนดว่าได้รับการป้องกันแค่ไหน

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

• ทำรายการสิ่งที่เปิดสู่อินเทอร์เน็ต: เว็บแอป API พอร์ทัล VPN พร้อมระบุเจ้าของของแต่ละรายการ
• ตรวจว่าไฟร์วอลล์ปัจจุบันตรวจอะไรได้จริง: ดูว่า application control (การคุมตามแอป) IPS และ TLS inspection มีไลเซนส์และเปิดใช้งานอยู่หรือไม่
• เลือกเว็บแอปสาธารณะหนึ่งตัว แล้วรัน WAF ในโหมด detection-only สักสองสามสัปดาห์ จากนั้นทบทวนการแจ้งเตือน
• จดข้อยกเว้นทั้งหมด: ทั้งกฎ พอร์ต หรือแอปที่เปิดไว้ "ชั่วคราว"
• ซ้อมการเปลี่ยนกฎ ในห้องทดลองก่อน ดู Network & Cyber Security Simulator: ประเภทและการใช้งาน

หากต้องการดูว่ามาตรการเหล่านี้อยู่ตรงไหนในภาพรวมความปลอดภัยขององค์กร ลองใช้ แบบประเมินตนเอง เมื่อไฟร์วอลล์เป็นส่วนหนึ่งของการออกแบบที่ใหญ่ขึ้น อ่านต่อได้ที่ Segmentation และ Micro-segmentation: เริ่มโดยไม่ทำระบบล่ม และ Zero Trust Architecture: องค์ประกอบและแผนเริ่มต้น โดย NIST SP 800-207 ระบุว่า NGFW เป็นหนึ่งในอุปกรณ์ที่ทำหน้าที่ policy enforcement point (จุดบังคับใช้นโยบายการเข้าถึง) ได้ ส่วนไฟร์วอลล์ที่ให้บริการผ่านคลาวด์ อยู่ในเรื่องที่อธิบายไว้ใน SASE และ SSE

WAF ช่วยกรองคำขออันตรายบางแบบ แต่ไม่แทนการแก้โค้ด ดูรายการความเสี่ยงของเว็บแอปใน OWASP Top 10 สำหรับเว็บแอป

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

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy: ประเภทของไฟร์วอลล์ รวมถึง UTM และ WAF (กันยายน 2009 ก่อนที่คำว่า NGFW จะแพร่หลาย)
• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape: คำอธิบายของ UTM, NGFW, WAF และ WAAP (การป้องกันเว็บแอปและ API) (พฤศจิกายน 2022)
• NIST SP 800-207: Zero Trust Architecture: กล่าวถึง NGFW ในบทบาท policy enforcement point
• OWASP: Web Application Firewall: นิยามของ WAF และความพยายามที่ต้องใช้ในการปรับแต่ง
• OWASP ModSecurity: โครงการเอนจิน WAF โอเพนซอร์ส
• ModSecurity: modsecurity.conf-recommended: คอนฟิกที่แนะนำ ซึ่งเริ่มต้นด้วยโหมด DetectionOnly
• OWASP CRS: False positives and tuning: สาเหตุที่เกิด false positive และวิธีใช้ rule exclusion (การยกเว้นกฎเฉพาะจุด)
• OWASP CRS: Paranoia levels: ข้อแลกเปลี่ยนระหว่างการตรวจจับกับ false positive
• OWASP Top Ten: เอกสารสร้างความตระหนักเรื่องความเสี่ยงของเว็บแอปพลิเคชัน