มิติใหม่ของ ‘Firewall’ (2)
ตอนที่แล้วผมได้อธิบายภาพรวมของไฟร์วอลล์ที่ได้รับการออกแบบให้รองรับการใช้งาน AI รวมถึงประเด็นความแตกต่างระหว่าง LLMs และแอพพลิเคชันแบบเดิมกันไปแล้ว
สัปดาห์นี้เราจะมาเจาะลึกเรื่องช่องโหว่ของ LLMs ที่ผู้เชี่ยวชาญได้สรุปรายการช่องโหว่ของ LLMs เพื่อช่วยในการวางมาตรการรักษาความปลอดภัยสำหรับโมเดลภาษา
และเช่นเดียวกันกับ web app ช่องโหว่บางอย่างสามารถจัดการได้ตั้งแต่ขั้นตอนการออกแบบ พัฒนา และฝึกโมเดล ตัวอย่างเช่น Training Data Poisoning (การใส่ข้อมูลที่มีช่องโหว่ลงในชุดข้อมูลที่ใช้ฝึกโมเดลใหม่ และเมื่อโมเดลเปิดใช้งานก็จะเผยแพร่ข้อมูลผิดๆ เหล่านั้นลงไป)
ช่องโหว่ในห่วงโซ่อุปทาน และ การออกแบบปลั๊กอินที่ไม่ปลอดภัยก็เป็นภัยจากการติดตั้งซอฟต์แวร์เสริมของบุคคลที่สาม
สุดท้าย การจัดการสิทธิ์และการอนุญาตถือว่าสำคัญมากในกรณีของ Excessive Agency ที่โมเดลซึ่งไม่ได้ถูกจำกัดอาจสามารถดำเนินการบางอย่างโดยไม่ได้รับอนุญาตภายในระบบหรือโครงสร้างพื้นฐานขององค์กรได้
LLM deployments มี 3 รูปแบบหลัก
Internal LLMs : องค์กรมีการพัฒนา LLMs เพื่อช่วยในการทำงานของพนักงาน เช่น AI assistant ที่ฝึกจากข้อมูลยอดขายและการพูดคุยกับลูกค้าเพื่อใช้ในการออกแบบข้อเสนอเฉพาะ หรือโมเดลที่ฝึกจากฐานข้อมูลภายในเพื่อให้วิศวกรใช้งาน
Public LLMs : โมเดลที่บุคคลทั่วไปสามารถเข้าถึงได้ โดยมักจะมีเวอร์ชันให้ใช้ฟรี และได้รับการฝึกจากข้อมูลสาธารณะ เช่น GPT ของ OpenAI หรือ Claude ของ Anthropic
Product LLMs : จากมุมขององค์กร LLMs อาจเป็นส่วนหนึ่งของผลิตภัณฑ์หรือบริการที่มอบให้ลูกค้า เช่น แชท- บอทช่วยเหลือลูกค้า หรือ AI Assistant มักจะเป็นโมเดลที่โฮสต์เองและปรับแต่งให้เข้ากับข้อมูลภายใน
หากพิจารณาจากมุมมองด้านความเสี่ยง ความแตกต่างระหว่าง Product LLMs กับ Public LLMs อยู่ที่ว่า “ใคร” รับผลกระทบเมื่อเกิดการโจมตี
กล่าวคือ Public LLMs เป็นภัยต่อข้อมูล เพราะข้อมูลใดก็ตามที่ไปอยู่ในโมเดลอาจถูกเข้าถึงโดยบุคคลทั่วไป บริษัทหลายแห่งจึงแนะนำไม่ให้พนักงานใช้ข้อมูลลับใน prompt สำหรับบริการเหล่านี้
Product LLMs อาจกลายเป็นภัยต่อทรัพย์สินทางปัญญาของบริษัท หากมีการฝึกโมเดลด้วยข้อมูลภายใน ไม่ว่าจะโดยตั้งใจหรือไม่ก็ตาม
ไฟร์วอลล์ ที่รองรับ AI ถูกใช้งานในลักษณะเดียวกับ Web Application Firewall (WAF) แบบเดิม โดยจะทำการสแกนทุกคำขอ API ที่มี LLM prompt เพื่อตรวจจับรูปแบบและลายเซ็นที่อาจบ่งบอกถึงการโจมตี โดยสามารถติดตั้งไว้ด้านหน้าของโมเดลที่โฮสต์บนโครงสร้างพื้นฐานของผู้ให้บริการ
การป้องกันการโจมตีแบบ Volumetric - Model Denial of Service (Model DoS) คือ การโจมตีแบบ DoS เกิดจากการใช้ทรัพยากรของระบบมากเกินไป และการป้อนข้อมูลของผู้ใช้งานมีความไม่แน่นอนสูง ส่งผลให้คุณภาพการให้บริการลดลง หรือเพิ่มต้นทุนในการดำเนินการของโมเดลอย่างมีนัยสำคัญ
ทำให้การโจมตีลักษณะนี้อาจส่งผลเสียรุนแรงต่อระบบ แต่ความเสี่ยงนี้สามารถลดลงได้ด้วยการใช้นโยบายจำกัดอัตราการร้องขอซึ่งควบคุมจำนวนคำขอในแต่ละ session ของผู้ใช้งาน
นอกจากนี้ยังสามารถใช้งาน Rate Limiting และ Advanced Rate Limiting เพื่อจัดการจำนวนคำขอที่อนุญาตให้เข้าถึงโมเดล โดยการตั้งอัตราคำขอสูงสุดจาก IP address หรือ API key ต่อ 1 session
Sensitive Data Detection : การเปิดเผยข้อมูลสำคัญ เกิดขึ้นเมื่อ LLM เปิดเผยข้อมูลลับโดยไม่ตั้งใจในคำตอบที่ส่งกลับ ทำให้เกิดการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต การละเมิดความเป็นส่วนตัว หรือช่องโหว่ด้านความปลอดภัยแนวทางในการป้องกันคือการเพิ่มการตรวจสอบความถูกต้องของ prompt อย่างเข้มงวดและการระบุว่ามีข้อมูลส่วนบุคคลที่สามารถระบุตัวบุคคลได้ (PII) หลุดออกจากโมเดลหรือไม่
ตัวอย่างเช่น เมื่อโมเดลถูกฝึกด้วยฐานข้อมูลของบริษัทซึ่งอาจมีข้อมูลสำคัญอย่าง หมายเลขประกันสังคม, โค้ดภายในองค์กร เป็นต้น
สัปดาห์หน้า เราจะมาตามกันต่อเรื่องการตรวจจับข้อมูลสำคัญที่มีการใช้งานอยู่ 2 รูปแบบว่ามีอะไรบ้างและบทสรุปของ Firewall ที่รองรับ AI กันในตอนที่ 3 ครับ