- Cloudflare ประกาศพัฒนา 'Firewall for AI' ซึ่งเป็นชั้นการป้องกันแบบใหม่ที่วางไว้หน้าโมเดลภาษาขนาดใหญ่ (Large Language Models, LLMs) เพื่อระบุการใช้งานในทางที่ผิด
- การใช้ LLM เป็นแอปพลิเคชันที่เชื่อมต่อกับอินเทอร์เน็ตก่อให้เกิดช่องโหว่รูปแบบใหม่ และอาจถูกผู้ไม่หวังดีนำไปใช้ประโยชน์ได้
- นอกจากช่องโหว่ที่ส่งผลต่อเว็บและ API แอปพลิเคชันแบบเดิมแล้ว ยังมีภัยคุกคามใหม่ที่เกิดจากลักษณะการทำงานของ LLM เอง
- Firewall for AI เป็นเว็บแอปพลิเคชันไฟร์วอลล์ (WAF) ขั้นสูงที่ออกแบบมาสำหรับแอปพลิเคชันที่ใช้ LLM โดยเฉพาะ พร้อมชุดเครื่องมือสำหรับตรวจจับช่องโหว่และมอบการมองเห็นให้เจ้าของโมเดล
ทำไม LLM จึงแตกต่างจากแอปพลิเคชันแบบดั้งเดิม?
- เมื่อมอง LLM ในฐานะแอปพลิเคชันที่เชื่อมต่ออินเทอร์เน็ต จะมีความแตกต่างหลักสองประการเมื่อเทียบกับเว็บแอปแบบดั้งเดิม
- ประการแรก วิธีที่ผู้ใช้โต้ตอบกับผลิตภัณฑ์แตกต่างกัน แอปแบบดั้งเดิมมีความเป็นเชิงกำหนด ขณะที่ LLM ไม่เป็นเชิงกำหนดและอิงกับภาษาธรรมชาติ
- ประการที่สอง วิธีที่ control plane ของแอปพลิเคชันโต้ตอบกับข้อมูลแตกต่างกัน ในแอปพลิเคชันแบบดั้งเดิม control plane (โค้ด) และ data plane (ฐานข้อมูล) แยกจากกันค่อนข้างชัดเจน แต่ใน LLM ข้อมูลสำหรับการฝึกกลายเป็นส่วนหนึ่งของตัวโมเดลเอง ทำให้ควบคุมการแบ่งปันข้อมูลผ่านพรอมป์ต์ของผู้ใช้ได้ยาก
ช่องโหว่ LLM ของ OWASP
- มูลนิธิ OWASP ได้เผยแพร่ 10 อันดับช่องโหว่ของ LLM ซึ่งเป็นกรอบแนวคิดที่มีประโยชน์สำหรับการคิดเรื่องการปกป้อง language model
- ภัยคุกคามบางส่วนคล้ายกับ OWASP Top 10 ของเว็บแอปพลิเคชัน แต่ก็มีภัยคุกคามที่เฉพาะเจาะจงกับ language model ด้วย
การปรับใช้งาน LLM
- ความเสี่ยงของ LLM แตกต่างกันไปตามรูปแบบการปรับใช้ ปัจจุบันมีแนวทางหลักอยู่ 3 แบบ
- Internal LLM (ภายใน): องค์กรพัฒนา LLM เพื่อช่วยพนักงานในการทำงานประจำวัน ซึ่งถือเป็นทรัพย์สินของบริษัทและไม่ควรให้บุคคลภายนอกพนักงานเข้าถึง ตัวอย่างเช่น AI copilot ที่ฝึกจากข้อมูลการขายและการโต้ตอบกับลูกค้าเพื่อสร้างข้อเสนอเฉพาะบุคคล หรือ LLM ที่ฝึกจากฐานความรู้ภายในซึ่งวิศวกรสามารถค้นหาได้
- Public LLM (สาธารณะ): LLM ที่บุคคลภายนอกองค์กรก็เข้าถึงได้ โซลูชันลักษณะนี้มักมีเวอร์ชันฟรีที่ทุกคนใช้งานได้ และมักฝึกจากความรู้ทั่วไปหรือความรู้สาธารณะ ตัวอย่างเช่น GPT ของ OpenAI หรือ Claude ของ Anthropic
- Product LLM (ผลิตภัณฑ์): ในมุมมองขององค์กร LLM อาจเป็นส่วนหนึ่งของผลิตภัณฑ์หรือบริการที่มอบให้ลูกค้า โดยทั่วไปเป็นโซลูชันแบบปรับแต่งที่โฮสต์เอง และสามารถใช้เป็นเครื่องมือที่โต้ตอบกับทรัพยากรของบริษัทได้ เช่น แชตบอตฝ่ายสนับสนุนลูกค้า หรือ Cloudflare AI Assistant
- ในทุกสถานการณ์ จำเป็นต้องปกป้องโมเดลจากการใช้งานในทางที่ผิด ปกป้องข้อมูลกรรมสิทธิ์ที่เก็บอยู่ในโมเดล และปกป้องผู้ใช้จากข้อมูลที่ผิดหรือเนื้อหาที่ไม่เหมาะสม
ไฟร์วอลล์สำหรับ AI
- Firewall for AI ของ Cloudflare ถูกวางใช้งานในลักษณะเดียวกับ WAF แบบดั้งเดิม โดยจะสแกนคำขอ API ที่มีพรอมป์ต์ LLM ทั้งหมดเพื่อตรวจจับรูปแบบและลายเซ็นของการโจมตีที่เป็นไปได้
- สามารถวางไว้หน้าโมเดลที่โฮสต์บนแพลตฟอร์ม Cloudflare Workers AI หรือโมเดลที่โฮสต์บนโครงสร้างพื้นฐานของบุคคลที่สาม และสามารถใช้งานร่วมกับ Cloudflare AI Gateway ได้
การป้องกันการโจมตีเชิงปริมาณ
- หนึ่งในภัยคุกคามที่ OWASP ระบุไว้คือ Model Denial of Service
- เช่นเดียวกับแอปพลิเคชันแบบดั้งเดิม การโจมตีแบบ DoS จะใช้ทรัพยากรมากเกินไปจนทำให้คุณภาพบริการลดลง หรือเพิ่มต้นทุนการดำเนินงานของโมเดล
- ความเสี่ยงนี้สามารถบรรเทาได้ด้วยการใช้นโยบาย rate limiting เพื่อควบคุมอัตราคำขอในแต่ละเซสชัน
การระบุข้อมูลอ่อนไหว
- กรณีใช้งานเกี่ยวกับข้อมูลอ่อนไหวมีอยู่ 2 แบบ โดยขึ้นอยู่กับว่าคุณเป็นเจ้าของโมเดลและข้อมูลเอง หรือกำลังพยายามป้องกันไม่ให้ผู้ใช้ส่งข้อมูลไปยัง Public LLM
- Sensitive Information Disclosure ตามที่ OWASP นิยามไว้ เกิดขึ้นเมื่อ LLM เปิดเผยข้อมูลลับในคำตอบโดยไม่ตั้งใจ ซึ่งอาจนำไปสู่การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต การละเมิดความเป็นส่วนตัว และการละเมิดความปลอดภัย
การป้องกันการใช้งานโมเดลในทางที่ผิด (Preventing Abuse)
- การใช้งานโมเดลในทางที่ผิดครอบคลุมหลายแนวทาง เช่น 'prompt injection' หรือการส่งคำขอเพื่อกระตุ้นให้เกิด hallucination หรือทำให้สร้างคำตอบที่ไม่ถูกต้อง ไม่น่าพอใจ ไม่เหมาะสม หรือไม่ตรงประเด็น
- Prompt injection คือความพยายามในการชักจูง language model ผ่านอินพุตที่สร้างขึ้นเป็นพิเศษ เพื่อทำให้ LLM ตอบสนองในแบบที่ไม่ได้ตั้งใจ
วิธีใช้งานไฟร์วอลล์สำหรับ AI
- ลูกค้าองค์กรที่ใช้ "Application Security Advanced" สามารถใช้ Advanced Rate Limiting และ Sensitive Data Detection ได้ทันที
- ฟีเจอร์ตรวจสอบพรอมป์ต์ของ Firewall for AI ยังอยู่ระหว่างการพัฒนา และมีแผนจะเปิดเบต้าให้ผู้ใช้ Workers AI ภายในไม่กี่เดือนข้างหน้า
1 ความคิดเห็น
ความเห็นบน Hacker News
แม้จะมีการอ้างว่า prompt injection กับการ jailbreak เป็นคนละอย่างกัน แต่ดูเหมือนว่าข้อถกเถียงนี้จะแพ้ไปแล้ว ตามบทความของ Cloudflare การใช้โมเดลในทางที่ผิดหมายถึงหมวดหมู่การใช้งานผิดที่กว้างกว่า ซึ่งรวมถึงแนวทางอย่าง prompt injection ด้วย prompt injection เกิดขึ้นเมื่อผู้พัฒนาเชื่อม prompt ที่กำหนดไว้กับอินพุตที่ไม่น่าเชื่อถือจากผู้ใช้ หากไม่มีการเชื่อมอินพุตที่เชื่อถือได้กับอินพุตที่ไม่น่าเชื่อถือ ก็ไม่ถือว่าเป็น prompt injection การแยกความต่างนี้สำคัญ และโมเดลที่ฝึกมาเพื่อรับมือการโจมตีแบบ jailbreak ทั่วไปก็น่าจะจับสิ่งนี้ได้ยาก
WAF (Web Application Firewall) เป็นทางออกชั่วคราวสำหรับบริการเว็บที่ทีมความปลอดภัยควบคุมหรือทำความเข้าใจไม่ได้ ความนิยมของมันลดลงเพราะปัญหาด้านประสิทธิภาพและความยากในการปรับแต่งเพื่อบล็อกทราฟฟิกที่เป็นอันตรายได้อย่างมีประสิทธิภาพ แนวทางแบบอิง WAF เป็นการยอมรับความไม่รู้และตำแหน่งของจุดอ่อน ส่วนการย้ายไปใช้โมเดลนั้นยังไม่ผ่านการพิสูจน์ และขัดกับแนวคิดอย่างการป้องกันตัวเองแบบตอบสนองของแอป
ฉันต้องการการป้องกันไม่ให้เว็บไซต์ของฉันถูกสแครปไปเพื่อใช้ฝึก AI แม้จะรู้สึกอยู่แล้วว่านี่เป็นการต่อสู้ที่แพ้ไปตั้งแต่ต้น แต่ก็ได้รู้ว่าคนที่ให้ความสำคัญกับความเป็นส่วนตัวก็คิดแบบเดียวกัน
เช่นเดียวกับผลิตภัณฑ์ส่วนใหญ่ของ Cloudflare ผลิตภัณฑ์นี้ก็ยิ่งมีประโยชน์มากขึ้นเมื่อมีลูกค้าใช้งานมากขึ้น และต้องใช้ความพยายามแบบแมนนวลต่อลูกค้าน้อยลง คุณค่าของ Cloudflare ไม่ได้อยู่ที่การตั้งค่าหรือการรับประกัน แต่อยู่ที่การมองเห็นการโจมตีที่คนอื่นทั้งหมดกำลังเห็นอยู่แทบจะเรียลไทม์ และการแพ็กสิ่งนั้นออกมาเป็นผลิตภัณฑ์
ผลิตภัณฑ์นี้ดูเป็นไอเดียที่ดีมาก เมื่อมันง่ายพอๆ กับการเพิ่มและเปิดไฟร์วอลล์ ก็ย่อมดึงความสนใจและการยอมรับได้ง่ายกว่าผลิตภัณฑ์ guardrail อื่นๆ ฉันสงสัยว่าไฟร์วอลล์สำหรับ LLM แบบทั่วไปจะมีประโยชน์ได้มากแค่ไหน และจะต้องหรือสามารถปรับแต่งให้เข้ากับโมเดลและกรณีใช้งานได้มากเพียงใด แต่ก็ดูเหมือนว่าจะจัดการได้ไม่ยาก
เท่าที่อ่านจากโพสต์นี้ Cloudflare กำลังเอาตัวเองไปพัวพันกับการเซ็นเซอร์และสงครามวัฒนธรรม ผู้ใช้แบบเสียเงินของ Cloudflare จะจ่ายเงินเพื่อผลักดันอคติทางการเมืองของตัวเองผ่าน Cloudflare ขณะที่ผู้ใช้ AI ก็จะกล่าวหา Cloudflare ว่าสนับสนุนการเซ็นเซอร์ Cloudflare อาจเข้าไปติดหล่มการต่อสู้ทางการเมืองโดยไม่จำเป็น
กำลังใช้ AI เพื่อกรองคำขออยู่หรือ? ถ้าใช่ นี่คงเป็นการจับคู่ที่สวรรค์สร้างมา!
[โน้มตัวเข้าหาไมค์] ส่วนผสมลับคือ regular expression
ฉันคิดมาสักพักแล้วว่าอยากทำอะไรบางอย่างในแนวคิดคล้ายกันสำหรับ smart payment credentials ในสถานการณ์ที่ LLM เป็นผู้ตัดสินใจว่าจะซื้อหรือไม่ซื้อ เพื่อป้องกันการใช้งาน LLM ในทางที่ผิด แนวคิดคือจะออกโทเคนใช้ครั้งเดียว (หรืออะไรทำนองนั้น) ก็ต่อเมื่อมีการร้องขอข้อมูลรับรองการชำระเงินผ่าน chain ที่ถูกต้องตามกฎหมายเท่านั้น ถ้ามีใครกำลังคิดเรื่องนี้อยู่ ฉันอยากคุยด้วย
ฉันคิดมานานแล้วว่าพวกเขาจะไล่ตามของใหญ่ชิ้นถัดไปทางการตลาดต่อไปเรื่อยๆ ก็ดี แบบนี้จะยิ่งเปิดพื้นที่ให้มีการแข่งขันมากขึ้นสำหรับบริษัทในตลาด CDN/DNS/WAF ที่ยังใส่ใจกับเรื่องแบบนั้นอยู่