นักพัฒนา SaaS รายหนึ่งพบว่าการเปิดใช้งาน Bot Fight Mode ของ Cloudflare สำหรับทุกโดเมนในบัญชีของเขา ทำให้ทราฟฟิก API หยุดชะงักไปนานถึงหนึ่งเดือน ส่งผลให้ลูกค้าที่ชำระเงินไม่สามารถใช้งานฟีเจอร์หลักของผลิตภัณฑ์ได้
ปัญหานี้ปรากฏขึ้นเมื่อนักพัฒนาสังเกตเห็นว่าตัวชี้วัดการใช้งาน (usage metrics) เริ่มคงที่อย่างกะทันหัน แม้ว่าจะมีผู้สมัครใช้งานใหม่เข้ามาเรื่อยๆ แต่จำนวนเซสชันที่ใช้งานอยู่ (active sessions) กลับไม่เติบโตขึ้น หลังจากใช้เวลาหลายสัปดาห์ในการเขียนโค้ดใหม่และดีบั๊ก (debugging) ก็พบว่าปุ่มเปิด/ปิดความปลอดภัยเพียงปุ่มเดียวคือต้นเหตุ: Bot Fight Mode ของ Cloudflare ได้ระบุว่า AWS Lambda endpoint ของตัว SaaS เองเป็นบอทที่ประสงค์ร้ายและทำการบล็อกมัน
การตั้งค่าเพียงจุดเดียวทำลายบริการทั้งระบบได้อย่างไร
สแต็ก (stack) ของนักพัฒนาพึ่งพาการเรียกใช้งานแบบ server-to-server โดยฟังก์ชัน Lambda ภายในจะส่งข้อมูลกลับไปยังโดเมนสาธารณะของ SaaS อย่างสม่ำเสมอ ซึ่งเป็นรูปแบบที่พบได้ทั่วไปในสถาปัตยกรรม micro-service สมัยใหม่ Bot Fight Mode จะทำการท้าทายหรือบล็อกคำขอ (requests) ที่ดูเหมือนโปรแกรมดึงข้อมูลอัตโนมัติ (automated scrapers) เพื่อปกป้องเว็บไซต์ที่เน้นเนื้อหาจากการถูกขโมยข้อมูล
เมื่อเปิดใช้งานโหมดนี้ในทุกโซน (zones) Cloudflare จะปฏิบัติกับคำขอขาออก (outbound request) ของ Lambda เสมือนเป็นไคลเอนต์อัตโนมัติอีกรายหนึ่ง คำขอนั้นไม่เคยไปถึงแอปพลิเคชัน และเนื่องจากการบล็อกเกิดขึ้นที่ edge ทูลตรวจสอบ (monitoring tools) ของ SaaS จึงไม่พบข้อผิดพลาดใดๆ ทราฟฟิกเพียงแค่หายไปเฉยๆ การใช้งาน CPU ของนักพัฒนาบน Cloudflare Workers พุ่งสูงขึ้น ทำให้เขาสงสัยว่าเป็นฝีมือของ scraper ภายนอกมากกว่าที่จะเป็น backend ของตัวเอง
หลังจากตรวจสอบล็อก (logs) ของ Cloudflare อย่างละเอียด เขาจึงเห็นรายการที่ถูกบล็อกโดย "Bot Fight Mode" ซึ่งตรงกับช่วง IP ของ Lambda เขาจึงปิดฟีเจอร์นี้ในโซนที่ได้รับผลกระทบ และทราฟฟิก API ก็กลับมาทำงานตามปกติ ทำให้ตัวชี้วัดการใช้งานกลับเข้าสู่สภาวะปกติ
ทำไมความผิดพลาดนี้จึงสำคัญต่อผู้ให้บริการ SaaS
- ผลิตภัณฑ์ที่เน้น API จำเป็นต้องมีช่องทาง server-to-server ที่เปิดกว้าง Bot Fight Mode ตั้งสมมติฐานว่าทราฟฟิกหลักคือคำขอจากเบราว์เซอร์ของมนุษย์เพื่อขอไฟล์ HTML, รูปภาพ หรือ static assets แพลตฟอร์ม SaaS ที่มีการเปิดใช้งาน API, webhooks หรือ internal callbacks อาจถูกจำกัดความเร็ว (throttled) หรือถูกบล็อกได้โดยไม่มีรหัสข้อผิดพลาด (error code) ปรากฏที่เลเยอร์ของแอปพลิเคชัน
- การตั้งค่าความปลอดภัยแบบครอบคลุม (Global) มักไม่เหมาะกับทุกเวิร์กโหลด (workload) การใช้การกำหนดค่า Cloudflare ชุดเดียวกับทุกโดเมนเป็นการปฏิบัติกับทุกไซต์เสมือนว่ามีโมเดลภัยคุกคาม (threat model) แบบเดียวกัน เว็บไซต์เนื้อหา, ฟอรัม และ backend ของ SaaS มีความต้องการด้านความปลอดภัยที่แตกต่างกันมาก
- ความล้มเหลวที่เงียบเชียบทำลายรายได้ ระบบแจ้งเตือน (alerting system) ของนักพัฒนาไม่ทำงานเพราะคำขอที่ถูกบล็อกไม่เคยไปถึงแอปพลิเคชัน มีเพียงการลดลงของตัวชี้วัดการมีส่วนร่วมของผู้ใช้ (user-engagement metrics) เท่านั้นที่บ่งบอกถึงปัญหา หากไม่มีการตรวจสอบล็อกที่ระดับ edge อย่างสม่ำเสมอ ปัญหาที่คล้ายกันนี้อาจค้างคาอยู่โดยไม่มีใครสังเกตเห็น
สิ่งที่นักพัฒนาสามารถทำได้เพื่อหลีกเลี่ยงชะตากรรมเดียวกัน
- ตรวจสอบโปรไฟล์ทราฟฟิกของแต่ละโซน ก่อนเปิดใช้งาน Bot Fight Mode ให้ระบุประเภทของคำขอที่โดเมนของคุณคาดหวัง: เบราว์เซอร์ของมนุษย์, การเรียก API, webhook callbacks หรือการเรียกใช้งานบริการภายใน หากสิ่งใดเป็นสิ่งจำเป็นสำหรับฟังก์ชันหลัก ให้ถือว่าโซนนั้นเป็นแบบ “API-first” และตั้งค่าการป้องกันบอทให้เหลือน้อยที่สุด
- ทดสอบการเปลี่ยนแปลงในสภาพแวดล้อมจำลอง (staged environment) Cloudflare อนุญาตให้คุณใช้การตั้งค่ากับซับโดเมนเดียวหรือโซนสำหรับทดสอบ (staging zone) ตรวจสอบให้แน่ใจว่าระบบอัตโนมัติที่ถูกต้องยังคงทำงานได้ก่อนที่จะเริ่มใช้งานการเปลี่ยนแปลงนั้นทั่วโลก
- ตรวจสอบล็อกที่ระดับ edge ให้เป็นส่วนหนึ่งของ observability stack ของคุณ ส่งล็อก firewall และ bot-mitigation ของ Cloudflare ไปยัง SIEM, Loki หรือบริการรวบรวมข้อมูลใดๆ เพื่อหาความสัมพันธ์ระหว่างการพุ่งสูงขึ้นของคำขอที่ถูกบล็อกกับการลดลงของตัวชี้วัดแอปพลิเคชัน เพื่อตรวจจับความล้มเหลวที่เงียบเชียบได้ตั้งแต่เนิ่นๆ
- ทำให้การตั้งค่าความปลอดภัยสามารถย้อนกลับได้ เตรียมแผนการ rollback ที่มีการบันทึกไว้ หากกฎใหม่ทำให้เกิดพฤติกรรมที่ไม่คาดคิด ให้ปิดการใช้งานก่อนและยืนยันการเปลี่ยนแปลงก่อนที่จะเสียเวลาไปกับการเขียนโค้ดเพื่อแก้ไขปัญหาเฉพาะหน้า
- ตั้งคำถามให้ถูกจุด แทนที่จะถามว่า “ฉันจะหยุด scraper ได้อย่างไร?” ให้ถามว่า “เครื่องมือนี้แก้ปัญหาเฉพาะเจาะจงที่ฉันกำลังเจออยู่หรือไม่?” ฟีเจอร์ความปลอดภัยที่บล็อก scraper อาจไม่ใช่คำตอบที่เหมาะสมสำหรับ SaaS ที่ต้องการการเข้าถึง API แบบเปิด
มุมมองในภาพรวม
Bot Fight Mode ยังคงมีประโยชน์สำหรับเว็บไซต์ที่ต้องการปกป้องเนื้อหาแบบ static จาก crawler ที่รุกราน ข้อเสียของมันคือความไม่สามารถแยกแยะระหว่าง scraper ที่เป็นอันตรายกับไคลเอนต์อัตโนมัติที่ถูกต้องซึ่งใช้รูปแบบ HTTP แบบเดียวกัน
บทสรุป
เมื่อคุณจัดการหลายโดเมนภายใต้บัญชี Cloudflare เดียวกัน ให้ปฏิบัติกับแต่ละโดเมนเสมือนเป็นโซนความปลอดภัยที่แยกจากกัน เปิดใช้งาน Bot Fight Mode เฉพาะในจุดที่ทราฟฟิกขับเคลื่อนโดยมนุษย์เท่านั้น สำหรับเวิร์กโหลด SaaS ที่เน้น API ให้ปิดการตั้งค่านี้ไว้หรือปรับแต่งด้วยกฎ firewall แบบกำหนดเอง การคลิกเพียงครั้งเดียวสามารถทำให้ทราฟฟิกที่ถูกต้องเงียบหายไปได้พอๆ กับการหยุด scraper