ไฟร์วอลล์แอปพลิเคชันเว็บแบบบริการ: WAF SaaS ทำงานอย่างไร และเมื่อใดควรโฮสต์เอง

คุณมีเว็บแอปอยู่บน VPS ล็อกการเข้าถึงแสดงความพยายามล็อกอินที่ /wp-admin คำขอที่มี UNION SELECT อยู่ใน query string และทราฟฟิกต่อเนื่องจากช่วง IP ของดาต้าเซ็นเตอร์ที่ไม่มีเหตุผลจะเข้ามาที่เว็บของคุณ คุณอยากกรองขยะที่เห็นชัดออกไปก่อนที่มันจะไปถึงแอปพลิเคชัน

นี่คือจังหวะที่คนส่วนใหญ่ได้รู้จักคำว่า WAF SaaS สำหรับผู้อ่านหลายคน "WAF" กับ "Cloudflare" คือสิ่งเดียวกัน เพราะ Cloudflare คือสิ่งที่พวกเขาเจอก่อน แต่มันไม่ใช่สิ่งเดียวกัน WAF SaaS คือหมวดหมู่หนึ่ง: ไฟร์วอลล์แอปพลิเคชันเว็บที่ส่งมอบจากคลาวด์ ซึ่งตรวจสอบทราฟฟิก HTTP ของคุณที่ขอบเครือข่ายของผู้ให้บริการก่อนส่งต่อไปยัง origin ของคุณ Cloudflare เป็นเพียงผลิตภัณฑ์หนึ่งในหมวดหมู่นั้น

บทความนี้จะพาไล่ดูว่า WAF SaaS ทำงานอย่างไร ผู้ให้บริการรายใหญ่คิดราคาเท่าไร มันล้มเหลวตรงไหนในทางปฏิบัติ และเมื่อใดที่การรัน WAF ของคุณเองบน VPS Linux เป็นตัวเลือกที่ดีกว่า

TL;DR (สรุปย่อ)

• WAF SaaS คือไฟร์วอลล์แอปพลิเคชันเว็บที่ส่งมอบจากคลาวด์ คุณกำหนดเส้นทางทราฟฟิกผ่านผู้ให้บริการ หรือผูก WAF เข้ากับรีซอร์สคลาวด์ที่รองรับ บริการจะประเมินคำขอ HTTP(S) ก่อนที่แอปพลิเคชันที่ได้รับการป้องกันจะจัดการกับมัน
• ผู้ให้บริการรายใหญ่ใช้รูปแบบราคากว้าง ๆ สามแบบ: ระดับการสมัครสมาชิก (Cloudflare และ Sucuri) การเรียกเก็บตามการใช้งาน (AWS WAF) และการเสนอราคาผ่านฝ่ายขาย (Imperva และ Fastly) ต้นทุนตามการใช้งานจะเพิ่มขึ้นตามจำนวนคำขอที่ประมวลผลและฟีเจอร์เสริม ขณะที่แผนแบบสมัครสมาชิกมักคาดการณ์ได้ง่ายกว่า
• มีคำวิจารณ์ WAF SaaS ที่มีการบันทึกไว้ และเราจะพูดถึงมันด้านล่าง คำวิจารณ์นั้นชี้ไปที่ความหน่วง ผลบวกลวง การบล็อกที่ไม่โปร่งใส และการส่งข้อมูลผ่านบุคคลที่สาม
• WAF ที่โฮสต์เองบน VPS เป็นตัวเลือกที่ใช้ได้จริง SafeLine และ BunkerWeb คือสองโปรเจกต์โอเพนซอร์สที่กำลังมาแรง ทั้งคู่ทำงานเป็นรีเวิร์สพร็อกซีอยู่หน้าแอปพลิเคชันของคุณ
• การไม่ใช้ WAF เลยอาจเป็นทางเลือกที่มีเหตุผลรองรับ เมื่อความปลอดภัยของแอปพลิเคชันเข้าที่แล้ว การเปิดรับความเสี่ยงถูกควบคุม การมอนิเตอร์เข้มแข็ง และความเสี่ยงที่เหลือถูกบันทึกและยอมรับไว้แล้ว

WAF SaaS ทำงานอย่างไร

คำขอไปยัง example.com จะไปถึงขอบเครือข่ายของผู้ให้บริการก่อน เพราะ DNS ของคุณชี้ไปที่นั่น โหนดขอบจะสิ้นสุด TLS แจงคำขอ HTTP ส่งผ่านเอนจินกฎ แล้วจึงส่งต่อไปยัง origin ของคุณ บล็อกมัน ท้าทายมัน (CAPTCHA หรือการทดสอบ JavaScript) หรือจำกัดอัตราคำขอจากต้นทาง ถ้าส่งต่อไป แอปพลิเคชันของคุณจะเห็นคำขอนั้นราวกับว่ามาจาก IP ของผู้ให้บริการ โดย IP ของไคลเอนต์เดิมจะถูกส่งมาในเฮดเดอร์อย่าง X-Forwarded-For หรือ CF-Connecting-IP

ผลิตภัณฑ์ WAF SaaS จำนวนมากใช้รีเวิร์สพร็อกซีที่ผู้ให้บริการดูแล หรือการผสานที่ขอบเครือข่าย แต่ไม่ใช่ทุกบริการจะติดตั้งด้วยการเปลี่ยน DNS Cloudflare, Sucuri และ Fastly มักอยู่บนเส้นทางของคำขอที่ขอบเครือข่าย ส่วน AWS WAF จะถูกผูกกับ CloudFront หรือกับ รีซอร์ส AWS ที่รองรับ เช่น Application Load Balancer, API ใน API Gateway และ API ของ AppSync ไม่ว่ากรณีใด คำขอ HTTP(S) จะถูกประเมินก่อนที่แอปพลิเคชันที่ได้รับการป้องกันจะจัดการกับมัน

WAF ตรวจสอบข้อมูลชั้นที่ 7 เช่น เฮดเดอร์ของคำขอ พาธ query string เมธอด คุกกี้ และส่วนของเนื้อหาคำขอที่กำหนดค่าไว้ ส่วนไฟร์วอลล์เครือข่ายแบบดั้งเดิมตัดสินใจที่ชั้น 3 และ 4 เป็นหลัก โดยใช้ที่อยู่ โปรโตคอล และพอร์ต คู่มือเปรียบเทียบไฟร์วอลล์ฮาร์ดแวร์กับซอฟต์แวร์ของเรา อธิบายความแตกต่างในภาพกว้างไว้แล้ว

การป้องกันด้วย WAF แบบที่ผู้ให้บริการดูแลมักดึงจากแหล่งกฎสามแหล่ง:

• OWASP Core Rule Set (CRS) เป็นฐานโอเพนซอร์สสำหรับ ModSecurity และเอนจิน WAF ที่เข้ากันได้ ครอบคลุมประเภทการโจมตีทั่วไป เช่น SQL injection, cross-site scripting, command injection และ local file inclusion ผลิตภัณฑ์ที่สร้างบน ModSecurity มักมาพร้อม CRS ขณะที่ผู้ให้บริการคลาวด์จำนวนมากใช้กฎที่ตนดูแลเองแทน
• ชุดกฎที่ผู้ผลิตดูแลคือกฎเฉพาะของผู้ให้บริการที่พวกเขาคอยอัปเดตให้ทันสมัย "Managed Rules" ของ Cloudflare, "AWS Managed Rules" ของ AWS WAF และฟีดข่าวกรองภัยคุกคามของ Imperva ล้วนอยู่ในกลุ่มนี้
• กฎที่กำหนดเองคือกฎที่คุณเขียนขึ้นเอง "บล็อกคำขอไปยัง /admin ที่ไม่ได้มาจากช่วง IP นี้" "จำกัด /api/login ไว้ที่ 5 ครั้งต่อนาทีต่อ IP"

กฎตรวจจับ SQL injection อาจจับรูปแบบคุ้นตาอย่าง ' OR 1=1 -- ในพารามิเตอร์ query หรือในเนื้อหาคำขอ นั่นดักการสอดส่องแบบขี้เกียจได้ แต่ WAF ก็ยังพลาดเพย์โหลดที่ถูกอำพราง ช่องโหว่เชิงตรรกะ และคำขอที่เป็นอันตรายซึ่งดูเหมือนทราฟฟิกปกติของแอปได้อยู่ดี มันประเมินสัญญาณของคำขอที่สังเกตได้ ไม่ใช่เจตนาทางธุรกิจ

สิ่งที่มันป้องกันได้ พูดกันตรง ๆ:

• การโจมตีแบบ injection ที่เพย์โหลดตรงกับลายเซ็นที่รู้จัก
• ทราฟฟิกบอตจากสแกนเนอร์ที่รู้จัก
• รูปแบบการเดาสุ่มรหัสผ่านแบบง่าย ๆ
• DDoS แบบปริมาณมหาศาล เมื่อผู้ให้บริการมีระบบกรองทราฟฟิก DDoS ด้วย
• การใช้ API ในทางที่ผิดแบบพื้นฐาน

สิ่งที่มันทำไม่ได้:

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

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

WAF SaaS เทียบกับอุปกรณ์ในองค์กร และการโฮสต์เองบน VPS

ในปี 2026 มีรูปแบบการติดตั้ง WAF ที่พบบ่อยสามแบบ: WAF SaaS บนคลาวด์ (Cloudflare, AWS WAF, Fastly และรายอื่น ๆ), อุปกรณ์จริงหรืออุปกรณ์เสมือน (รวมถึงผลิตภัณฑ์ของ F5 และ Imperva) และซอฟต์แวร์ที่โฮสต์เองบน VPS หรือบนเซิร์ฟเวอร์ของคุณ

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

WAF SaaS บนคลาวด์

คุณกำหนดเส้นทางทราฟฟิกผ่านขอบเครือข่ายของผู้ให้บริการ หรือผูก WAF เข้ากับรีซอร์สคลาวด์ที่รองรับ ผู้ให้บริการดูแลกำลังตรวจสอบและการอัปเดตที่จัดการให้ ส่วนคุณเลือกกฎ สร้างนโยบายเฉพาะแอปพลิเคชัน และปรับข้อยกเว้น ตัวเลือกที่พบบ่อยได้แก่ Cloudflare, AWS WAF, Imperva, Sucuri และ Fastly

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

WAF แบบอุปกรณ์ในองค์กร

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

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

WAF ที่โฮสต์เองบน VPS ของคุณ

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

โปรเจกต์โอเพนซอร์สสองตัวที่กำลังมาแรงคือ SafeLine ซึ่งเป็น WAF โอเพนซอร์สที่ใช้เอนจินวิเคราะห์เชิงความหมายแทนการจับคู่ด้วย regex ล้วน ๆ และ BunkerWeb ซึ่งเป็น WAF บนฐาน NGINX ที่มาพร้อม ModSecurity ส่วนไลเซนส์ รูปแบบการติดตั้ง และการใช้ทรัพยากรของทั้งคู่ จะพูดถึงในหัวข้อการโฮสต์เองด้านล่าง

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

WAF SaaS เทียบกับ WAF ที่โฮสต์เองบน VPS ของคุณ

ตารางเปรียบเทียบด้านล่างเน้นความแตกต่างเชิงปฏิบัติที่ผู้ดูแลระบบต้องลงมือดูแลและตั้งงบประมาณ

ราคาของ WAF SaaS ในปี 2026

ราคาของ WAF SaaS มักผสมระหว่างระดับการสมัครสมาชิก ค่าใช้จ่ายตามการใช้งาน หรือการเสนอราคาผ่านฝ่ายขาย ราคาที่ประกาศต่อสาธารณะเทียบกันตรง ๆ ไม่ได้ เพราะผู้ให้บริการแต่ละรายจัดชุดกฎที่ดูแลให้ การควบคุมบอต การเก็บล็อก การซัพพอร์ต และฟีเจอร์ต้าน DDoS ต่างกันไป

AWS WAF ประกาศราคาแยกตามองค์ประกอบ ส่วน Cloudflare และ Sucuri ประกาศราคาแผนแบบบริการตนเอง ขณะที่ Imperva และ Fastly ใช้การตั้งราคาผ่านฝ่ายขายสำหรับผลิตภัณฑ์ WAF ที่เทียบเคียงกัน

ตรวจสอบเมื่อวันที่ 29 กรกฎาคม 2026: หน้าราคาแผนของ Cloudflare ระบุว่า Pro อยู่ที่ 20 ดอลลาร์ต่อเดือนเมื่อเรียกเก็บรายปี หรือ 25 ดอลลาร์เมื่อเรียกเก็บรายเดือน และ Business อยู่ที่ 200 ดอลลาร์ต่อเดือนแบบรายปี หรือ 250 ดอลลาร์แบบรายเดือน หน้าราคาไฟร์วอลล์ของ Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from ราคาของ AWS WAF as of the same date.

Imperva และ Fastly ไม่ได้ประกาศราคา WAF แบบบริการตนเองที่เทียบตรง ๆ ได้ ดังนั้นให้ถือว่าทั้งคู่เป็นตัวเลือกแบบติดต่อฝ่ายขาย แทนที่จะไปเชื่อตัวเลขประมาณการจากบุคคลที่สาม

หน้าราคาของ AWS WAF ระบุค่าใช้จ่ายพื้นฐานไว้ที่ 5 ดอลลาร์ต่อ web ACL ต่อเดือน, 1 ดอลลาร์ต่อกฎหรือกลุ่มกฎต่อเดือน และ 0.60 ดอลลาร์ต่อคำขอที่ประมวลผลหนึ่งล้านรายการ อาจมีค่าใช้จ่ายเพิ่มสำหรับกำลังประมวลผลเสริม การตรวจเนื้อหาคำขอที่ใหญ่ขึ้น การใช้ CAPTCHA หรือ Challenge กลุ่มกฎระดับพรีเมียม และการควบคุมการฉ้อโกงหรือบอต ทราฟฟิกโจมตีจึงทำให้บิลสูงขึ้นได้ แต่จะมากแค่ไหนขึ้นกับปริมาณ ระยะเวลา และฟีเจอร์ที่เปิดใช้ กฎแบบอิงอัตราคำขอช่วยปกป้องแอปพลิเคชัน แต่ไม่ได้ทำให้คำขอที่ WAF ประมวลผลไปแล้วกลายเป็นของฟรี

จุดที่ WAF SaaS ยังไปไม่ถึง

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

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

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

ข้อจำกัดข้อที่สองคือภาระด้านประสิทธิภาพ การทดสอบประสิทธิภาพ ModSecurity ปี 2023 วัดได้ว่าการอัปโหลดไฟล์เล็ก 9,462 ไฟล์ใช้เวลา 7.36 วินาทีเมื่อเปิด CRS เทียบกับ 4.55 วินาทีเมื่อปิด ทรูพุตลดจาก 2,079 เหลือ 1,285 คำขอต่อวินาที ขณะที่ CPU สูงสุดของ nginx ขึ้นจาก 8 % เป็น 73 % นี่เป็นการทดสอบคอนฟิกเดียวและเวิร์กโหลดเดียว จึงควรมองว่าเป็นหลักฐานว่าการตรวจสอบมีต้นทุน ไม่ใช่สัดส่วนสำหรับคำนวณขนาดที่ใช้ได้ทุกกรณี

ข้อจำกัดข้อที่สามคือเส้นทางของข้อมูล ทุกคำขอ HTTP รวมถึงเนื้อหาคำขอ ล้วนวิ่งผ่านโครงสร้างพื้นฐานของผู้ให้บริการ สำหรับแอปพลิเคชันที่จัดการข้อมูลส่วนบุคคล ธุรกรรมการเงิน หรือข้อมูลทางการแพทย์ นี่คือคำถามเรื่องอธิปไตยของข้อมูลที่จับต้องได้ แอปพลิเคชันที่โฮสต์ในสหภาพยุโรปแต่ส่งคำขอของลูกค้าผ่านผู้ให้บริการ WAF ในสหรัฐฯ ย่อมมีร่องรอยการตรวจสอบที่ต้องอธิบายหนักกว่า และมีข้อสัญญาเพิ่มอีกไม่กี่ข้อที่ต้องยอมรับ เมื่อเทียบกับแอปเดียวกันที่ใช้รีเวิร์สพร็อกซีซึ่งโฮสต์เองบน VPS ในเขตอำนาจศาลเดียวกัน

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

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

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

เมื่อใดที่การโฮสต์ WAF เองจึงสมเหตุสมผล

การโฮสต์เองได้เปรียบในสามสถานการณ์ และเสียเปรียบในอีกสามสถานการณ์ เริ่มจากฝั่งที่ได้เปรียบก่อน

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

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

แผน Free ของ Cloudflare อาจเป็นจุดเริ่มต้นที่ใช้ได้จริงสำหรับทีมขนาดเล็กถึงกลางที่ใช้ DNS หรือ CDN ของเขาอยู่แล้ว และยอมรับโมเดลการตรวจทราฟฟิกนั้นได้ ส่วนการโฮสต์เองจะน่าสนใจขึ้นเมื่อเส้นทางของข้อมูล การควบคุมกฎโดยตรง หรือต้นทุนโครงสร้างพื้นฐานที่คาดการณ์ได้ สำคัญกว่าการลดงานดูแลให้เหลือน้อยที่สุด

SafeLine และ BunkerWeb

มี WAF โอเพนซอร์สที่โฮสต์เองได้อยู่สองตัวที่ควรรู้จัก

SafeLine ใช้สัญญาอนุญาต GPL-3.0 ติดตั้งด้วย Docker Compose และสร้างขึ้นบนการวิเคราะห์เชิงความหมาย แทนที่จะเป็นชุดกฎ CRS ล้วน ๆ รีโพซิทอรีของ SafeLine รายงานอัตราตรวจจับ 71.65 % ผลบวกลวง 0.07 % และความแม่นยำโดยรวม 99.45 % ในโหมด Balance จากการประเมิน 33,669 ตัวอย่างที่โครงการทำเอง ตัวเลขเหล่านี้เป็นการวัดของผู้ดูแลโครงการ ไม่ใช่การเทียบวัดโดยอิสระ และไม่ควรนำไปสรุปเกินชุดทดสอบชุดนั้น

อ่าน

วิธีติดตั้ง SafeLine WAF บน Linux VPS

BunkerWeb ใช้สัญญาอนุญาต AGPL-3.0 และใช้ NGINX อยู่เบื้องหลัง มันผสาน ModSecurity เข้ากับ OWASP Core Rule Set และรองรับการติดตั้งหลายรูปแบบ ทั้ง Linux, Docker, Swarm และ Kubernetes

กำหนดขนาดของทั้งสองโปรเจกต์จากปริมาณคำขอที่วัดได้จริง การป้องกันที่เปิดใช้ งานประมวลผล TLS และระยะเก็บล็อก สำหรับการติดตั้ง SafeLine ที่ทราฟฟิกน้อย 2 vCPU และแรม 4 GB เป็นจุดเริ่มต้นที่เผื่อไว้พอสมควร และสูงกว่าขั้นต่ำสำหรับการติดตั้ง คู่มือเริ่มต้นใช้งาน BunkerWeb ฉบับปัจจุบัน แนะนำอย่างน้อย 2 vCPU และแรม 8 GB สำหรับการทดสอบหรือมีบริการไม่กี่ตัว และ 4 vCPU กับแรม 16 GB สำหรับสภาพแวดล้อมโปรดักชันที่ต้องปกป้องหลายบริการ ส่วนพื้นที่จัดเก็บขึ้นกับอัตราการเขียนล็อกและระยะเก็บเป็นหลัก ให้วัดเอาจริง แทนที่จะไปสัญญาเป็นจำนวนเดือนตายตัว

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

คุณเป็นคนดูแล WAF เอง นั่นแปลว่าโครงสร้างพื้นฐานข้างใต้ก็เป็นความรับผิดชอบของคุณด้วย ทั้งความพร้อมใช้งาน แพตช์ความปลอดภัย ใบรับรอง TLS การสำรองข้อมูล การหมุนล็อก การมอนิเตอร์ กำลังรองรับ และการกู้คืน ให้ทดสอบพฤติกรรมตอนระบบล้มอย่างละเอียดพอ ๆ กับที่ทดสอบกฎการกรอง เพื่อไม่ให้ WAF กลายเป็นจุดล้มเหลวจุดเดียวของทั้งระบบ

อ่าน

วิธี Secure Linux VPS: 20 วิธีรักษาความปลอดภัย VPS Server

กรอบการตัดสินใจ

มีอยู่สี่ทาง: แผนฟรีของ Cloudflare, WAF SaaS บนคลาวด์แบบเสียเงิน, WAF ที่โฮสต์เองบน VPS และการไม่ใช้ WAF เลย เงื่อนไขที่ทำให้เลือกแต่ละทางนั้นต่างกัน

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

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

เลือก WAF ที่โฮสต์เองเมื่อเงื่อนไขการโฮสต์เองที่ว่ามาข้างต้นเข้าเงื่อนไข และทีมของคุณดูแลพร็อกซีตัวนั้นได้อย่างน่าเชื่อถือ SafeLine และ BunkerWeb คือสองโปรเจกต์ที่ควรประเมินเป็นอันดับแรก

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

บทสรุป

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

ถ้าการโฮสต์เองตรงกับความต้องการของคุณ ให้เริ่มจาก Linux VPS ในภูมิภาคเดียวกับ origin นอกจากนี้ Cloudzy ยังมีการติดตั้งจากมาร์เก็ตเพลสในคลิกเดียวสำหรับ SafeLine และสำหรับ BunkerWeb เพื่อให้คุณเริ่มทดสอบได้เลยโดยไม่ต้องประกอบสแตกพื้นฐานเอง

คำถามที่พบบ่อย

WAF as a service คืออะไร?

WAF as a service คือไฟร์วอลล์แอปพลิเคชันเว็บที่ส่งมอบจากคลาวด์ ทราฟฟิกเดินทางไปถึงบริการนี้ผ่านการกำหนดเส้นทางด้วย DNS หรือรีเวิร์สพร็อกซี ผ่านการผสานที่ขอบเครือข่าย หรือผ่านการผูกกับรีซอร์สคลาวด์ที่รองรับ ผู้ให้บริการดูแลกำลังตรวจสอบและการอัปเดตที่จัดการให้ ส่วนคุณเลือกนโยบาย ปรับข้อยกเว้น และเพิ่มกฎเฉพาะแอปพลิเคชันของคุณเอง

Cloudflare เป็น WAF หรือไม่?

ใช่ Cloudflare ให้ความสามารถแบบ WAF โดยเป็นส่วนหนึ่งของแพลตฟอร์มขอบเครือข่ายที่กว้างกว่านั้น ซึ่งรวม DNS, CDN และการป้องกัน DDoS ด้วย แผนฟรีจะได้ Cloudflare Free Managed Ruleset ส่วนชุดกฎที่กว้างกว่า การควบคุมต่าง ๆ การวิเคราะห์ และความสามารถจัดการบอต ขึ้นกับแผนที่เลือกและส่วนเสริม

WAF ฟรีของ Cloudflare เพียงพอไหม?

ขึ้นอยู่กับพื้นที่เสี่ยงของแอปพลิเคชัน กฎที่ต้องใช้ ความต้องการด้านการเก็บล็อกและระยะเก็บ การควบคุม API หรือบอต ความต้องการด้านซัพพอร์ต และระดับที่คุณทนผลบวกลวงได้ Free Managed Ruleset อาจเป็นพื้นฐานที่ใช้ได้ แต่การยืนยันตัวตน การชำระเงิน หรือข้อมูลที่มีกฎหมายกำกับ ไม่ได้แปลว่าต้องไปอยู่ที่แผนเสียเงินแผนใดแผนหนึ่งโดยอัตโนมัติ ให้เทียบข้อจำกัดของฟีเจอร์ ณ ปัจจุบัน แล้วตรวจสอบกับโมเดลภัยคุกคามของคุณเอง

WAF ต่างจากไฟร์วอลล์ทั่วไปอย่างไร?

ไฟร์วอลล์เครือข่ายแบบดั้งเดิมกรองทราฟฟิกโดยอาศัยข้อมูลชั้นที่ 3 และ 4 เป็นหลัก ได้แก่ ที่อยู่ โปรโตคอล และพอร์ต ส่วน WAF ประเมินคำขอ HTTP(S) ที่ชั้นที่ 7 รวมถึงเฮดเดอร์ พาธ พารามิเตอร์ และเนื้อหาคำขอที่กำหนดค่าไว้ ผลิตภัณฑ์ความปลอดภัยยุคใหม่อาจทำให้เส้นแบ่งนี้พร่าเลือน แต่การควบคุมทั้งสองยังคงเสริมกัน ไม่ใช่ใช้แทนกัน

WAAP คืออะไร และต่างจาก WAF อย่างไร?

WAAP ย่อมาจาก Web Application and API Protection ขอบเขตของมันกว้างกว่า WAF แบบดั้งเดิม โดยผู้ขายมักรวมกฎ WAF เข้ากับการค้นหาหรือบังคับใช้นโยบาย API การจัดการบอต และการควบคุม DDoS หรือการใช้งานในทางที่ผิดที่ชั้นแอปพลิเคชัน ชุดที่ได้จริงต่างกันไปตามผู้ให้บริการ ดังนั้นอย่ามอง WAAP ว่าเป็นชุดฟีเจอร์มาตรฐานตายตัว

ถ้าเฟรมเวิร์กของผมตรวจสอบข้อมูลนำเข้าอยู่แล้ว ยังต้องมี WAF ไหม?

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