ข้อมูลเป็นพิษคืออะไร?

ทีมรักษาความปลอดภัยทุกทีมได้รับการฝึกฝนให้ตรวจสอบโค้ดขณะที่กำลังเผยแพร่ แต่แทบไม่มีทีมใดได้รับการฝึกฝนให้ตรวจสอบข้อมูลขณะที่ข้อมูลเข้ามา และจุดบอดนี้เองที่เป็นเป้าหมายของการโจมตีด้วยการปนเปื้อนข้อมูล (Data Poisoning) เมื่อโมเดลที่ถูกปนเปื้อนไปถึงขั้นตอนการใช้งานจริง ช่องโหว่นั้นไม่เคยปรากฏในการตรวจสอบโค้ดเลย แต่มันอยู่ในชุดข้อมูลที่ไม่มีใครตรวจสอบเมื่อหลายเดือนก่อน

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

ความหมายของการปนเปื้อนข้อมูล #

การโจมตีด้วยการปนเปื้อนข้อมูล (Data poisoning) คือการจงใจเปลี่ยนแปลงข้อมูลที่ใช้ในการฝึกฝน ปรับแต่ง หรือสร้างพื้นฐานของโมเดล AI เพื่อให้โมเดลเรียนรู้สิ่งที่ผิดพลาด ทำงานในแบบที่ผู้โจมตีต้องการ หรือรั่วไหลข้อมูลที่ไม่ควรเปิดเผย แทนที่จะโจมตีโมเดลหลังจากการใช้งาน ผู้โจมตีจะโจมตีข้อมูลดิบที่ใช้สร้างโมเดลนั้น

แนวคิดหลักเบื้องหลังการโจมตีด้วยข้อมูลที่เป็นอันตรายนั้นเรียบง่ายและน่าสะพรึงกลัว: โมเดล AI จะน่าเชื่อถือได้ก็ต่อเมื่อข้อมูลที่มันใช้เรียนรู้นั้นน่าเชื่อถือ หากข้อมูลนั้นเสียหาย มีอคติ หรือถูกวางกับดักไว้ก่อนเริ่มการฝึกฝน การตรวจสอบโค้ด การทดสอบ หรือการตรวจสอบการทำงานในขั้นตอนต่อไปจะไม่สามารถตรวจจับข้อบกพร่องที่ซ่อนอยู่ได้ เพราะโมเดลจะทำงานตามที่ได้รับการสอน (อย่างเป็นอันตราย) ทุกประการ

การปนเปื้อนข้อมูลด้วย AI เทียบกับช่องโหว่ของซอฟต์แวร์แบบดั้งเดิม #

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

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

การโจมตีด้วยการปนเปื้อนข้อมูลทำงานอย่างไร? #

การโจมตีด้วยการปนเปื้อนข้อมูลมักเกิดขึ้นในรูปแบบใดรูปแบบหนึ่งต่อไปนี้:

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

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

ผู้โจมตีสามารถทำลายโมเดล AI ได้อย่างไร ก่อนที่มันจะเขียนโค้ดแม้แต่บรรทัดเดียว? #

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

นี่คือสิ่งที่ทำให้การโจมตีข้อมูล AI ด้วยการปนเปื้อนแตกต่างอย่างสิ้นเชิงจากช่องโหว่ที่ทีมรักษาความปลอดภัยแอปพลิเคชันได้รับการฝึกฝนให้ค้นหา โมเดลที่มีช่องโหว่จะดูเหมือนกับโมเดลที่ไม่มีช่องโหว่ในส่วนเปรียบเทียบโค้ด มันผ่านการตรวจสอบ pull request การตรวจสอบนั้นทำได้โดยการคอมไพล์ ปรับใช้ และตอบคำถามส่วนใหญ่ได้อย่างถูกต้อง จนกระทั่งเงื่อนไขเฉพาะที่ผู้โจมตีสร้างขึ้นปรากฏขึ้นในระบบการผลิต ในเวลานั้น คำถามจะไม่ใช่ "โค้ดส่วนไหนที่ทำให้เกิดสิ่งนี้" อีกต่อไป แต่เป็น "ข้อมูลอะไรที่ทำ และมันย้อนกลับไปไกลแค่ไหน"

เหตุใดการโจมตีข้อมูล AI ด้วยการปนเปื้อนจึงกลายเป็นประเด็นสำคัญที่เพิ่มมากขึ้น? #

การปนเปื้อนข้อมูล AI ไม่ใช่ปัญหาเชิงทฤษฎีอีกต่อไปแล้ว แต่ได้รับการยอมรับอย่างเป็นทางการแล้ว LLM04: การปนเปื้อนของข้อมูลและแบบจำลอง ใน OWASP Top 10 สำหรับแอปพลิเคชัน LLM ภัยคุกคามนี้อยู่ในอันดับต้น ๆ เคียงข้างการฉีดข้อมูลแบบทันทีและความเสี่ยงในห่วงโซ่อุปทาน ซึ่งเป็นหนึ่งในภัยคุกคามที่สำคัญที่สุดของยุค AI แบบสร้างสรรค์ มีสามแนวโน้มที่ผลักดันให้ภัยคุกคามนี้อยู่ในความสนใจของทีมรักษาความปลอดภัยทุกทีมมากขึ้น:

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

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

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

การตรวจจับและการป้องกันการโจมตีด้วยการปนเปื้อนข้อมูล #

เนื่องจากการโจมตีด้วยข้อมูลที่เป็นอันตรายเกิดขึ้นตั้งแต่ต้นทางของตัวแบบ ดังนั้นการป้องกันจึงต้องเริ่มต้นจากต้นทางเช่นกัน:

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

• รู้จักชุดข้อมูลทุกชุดใน pipeline. คุณไม่สามารถตรวจสอบความเสี่ยงจากการได้รับสารพิษในชุดข้อมูลที่คุณไม่รู้ว่ามีอยู่ การค้นหาชุดข้อมูลสำหรับการฝึกอบรม การประเมิน และการเรียกใช้ข้อมูลอย่างต่อเนื่องคือแนวป้องกันด่านแรก

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

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

Xygeni ช่วยลดช่องโหว่การโจมตีด้วยข้อมูลที่เป็นอันตรายได้อย่างไร? #

การป้องกันการโจมตีด้วยข้อมูลที่เป็นอันตรายเริ่มต้นด้วยการมองเห็นภาพรวม ซึ่งเป็นสิ่งที่องค์กรส่วนใหญ่ขาดไป ไซเกนีระบบ AI Inventory ของ s ค้นหาทรัพย์สิน AI ทุกชิ้นอย่างต่อเนื่องทั่วทั้งระบบ SDLCรวมถึงชุดข้อมูลที่อยู่เบื้องหลัง ได้แก่ ข้อมูลฝึกฝน ชุดข้อมูลประเมินผล และแหล่งข้อมูล RAG หรือแหล่งข้อมูลการดึงข้อมูล และแมปข้อมูลเหล่านั้นลงในกราฟความสัมพันธ์แบบเรียลไทม์ที่วิ่งจากชุดข้อมูลไปยังโมเดลไปยังปลายทาง ไปยังเอเจนต์ไปยังเซิร์ฟเวอร์ MCP ไปยังเครื่องมือเขียนโค้ด กราฟนั้นเองที่เปลี่ยนผลลัพธ์ของโมเดลที่น่าสงสัยให้กลายเป็นคำถามที่ตรวจสอบได้: ชุดข้อมูลใดที่ป้อนข้อมูลนี้ และมันมาจากไหน

นอกจากสินค้าคงคลังนั้นแล้ว ไซเกนียังมีสินค้าอื่นๆ อีกด้วย ความปลอดภัยของ AI ตรวจจับจุดอ่อนของเวกเตอร์และการฝังข้อมูล รวมถึงบริบทที่ปนเปื้อนในการค้นหาและ RAG pipelines จัดเรียงให้ตรงกับ OWASP จัดอันดับ 10 อันดับแรกสำหรับการสมัครเรียน LLM แทนที่จะเชื่อมั่นว่าแหล่งข้อมูลการฝึกฝนและการดึงข้อมูลของโมเดลนั้นปลอดภัย Xygeni กลับมองว่าแหล่งข้อมูลเหล่านั้นเป็นส่วนหนึ่งของช่องโหว่การโจมตี เช่นเดียวกับที่มันมองโค้ด ส่วนประกอบต่างๆ และ... pipelineหากคุณไม่สามารถตอบคำถามได้ในขณะนี้ว่า “ข้อมูลใดที่ใช้ฝึกโมเดลนี้ และเราสามารถพิสูจน์ได้หรือไม่” นั่นคือช่องว่างที่ควรแก้ไขก่อนที่เหตุการณ์ข้อมูลปนเปื้อนใน AI จะบีบให้ต้องถามคำถามนี้

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