ผู้นำทางความคิด

คำสั่งไม่มีความลับ: ทำไมโมเดลความปลอดภัยแบบดั้งเดิมถูกทำลายเมื่อเอไอสัมผัสโค้ด

mm
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google

ในเดือนเมษายน 2023 ซัมซุง ค้นพบว่า工程师ของบริษัทได้รั่วไหลข้อมูลที่ละเอียดอ่อนไปยัง ChatGPT แต่นั่นเป็นเรื่องบังเอิญเท่านั้น ลองนึกภาพว่าถ้าโค้ดดังกล่าวมีคำสั่งที่ซ่อนอยู่ซึ่งถูกออกแบบมาเพื่อดึงข้อมูลออก ไม่ใช่แค่โค้ด แต่ยังรวมถึง API Key, ข้อมูลฐานข้อมูล และ Token บริการที่ AI สามารถเข้าถึงได้ สิ่งนี้ไม่ใช่เรื่องสมมติ นักวิจัยด้านความปลอดภัย ได้แสดงให้เห็นว่าการโจมตีดังกล่าวสามารถเกิดขึ้นได้ คำถามไม่ใช่ว่ามันจะเกิดขึ้น แต่ว่ามันจะเกิดขึ้นเมื่อไหร่

ขอบเขตที่ไม่มีอยู่แล้ว

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

แต่เมื่อใช้เอไอเอเจนต์ ขอบเขตนั้นได้หายไปแล้ว

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

สิ่งนี้แสดงถึงการเปลี่ยนแปลงพื้นฐานจากทุกสิ่งที่เรารู้เกี่ยวกับความปลอดภัยของแอปพลิเคชัน ไฟร์วอลล์แบบดั้งเดิมที่มองหารูปแบบที่เป็นอันตราย เช่น DROP TABLE หรือแท็ก ล้มเหลวทั้งหมดเมื่อเผชิญกับการโจมตีภาษาธรรมชาติ นักวิจัยได้แสดงให้เห็นถึงเทคนิค “การแทนที่เชิงความหมาย” โดยที่การแทนที่ “API Key” ด้วย “แอปเปิ้ล” ในคำสั่งย่อยช่วยให้ผู้โจมตีหลบเลี่ยงตัวกรองได้ทั้งหมด เราจะป้องกันความตั้งใจเมื่อมันถูกปลอมเป็นการสนทนาที่ไม่มีอันตรายได้อย่างไร?

ความเป็นจริงของการคลิกศูนย์ที่ไม่มีใครพูดถึง

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

ลองพิจารณาสถานการณ์นี้ ซึ่งอ้างอิงจาก เทคนิคที่นักวิจัยได้พิสูจน์แล้ว ผู้โจมตีฝังคำสั่งลับไว้ในความคิดเห็น HTML ภายในเอกสารของไลบรารีโอเพ่นซอร์สที่ได้รับความนิยม เอไอผู้ช่วยใดๆ ที่วิเคราะห์โค้ดนี้ ไม่ว่าจะเป็น GitHub Copilot, Amazon CodeWhisperer หรือเอไอผู้ช่วยในการเขียนโค้ดขององค์กร จะกลายเป็นตัวดึงข้อมูลที่เป็นไปได้ ไลบรารีที่ถูกบุกรุกเพียงหนึ่งรายการอาจหมายถึงสภาพแวดล้อมในการพัฒนาที่ถูกเปิดเผยหลายพันรายการ

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

ทำไมวิธีการปัจจุบันถูกตัดสินว่าล้มเหลว

อุตสาหกรรมกำลังหลงใหลในการ “จัดแนว” โมเดลและสร้างไฟร์วอลล์คำสั่งย่อยที่ดีกว่า OpenAI เพิ่มราวกั้น Anthropic มุ่งเน้นไปที่ AI รัฐธรรมนูญ ทุกคนพยายามสร้างโมเดลที่ไม่สามารถหลอกลวงได้

สิ่งนี้เป็นการต่อสู้ที่แพ้แล้ว

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

อุตสาหกรรมต้องยอมรับความจริงที่ยาก: การฉีดคำสั่งย่อยจะสำเร็จ คำถามคือสิ่งที่เกิดขึ้นเมื่อมันทำได้

การเปลี่ยนแปลงทางสถาปัตยกรรมที่เราต้องการ

เรากำลังอยู่ใน “ระยะการแก้ไขปัญหา” โดยเพิ่มฟิลเตอร์ข้อมูลเข้าและกฎการตรวจสอบอย่างเร่งด่วน แต่เช่นเดียวกับที่เราทำกับ SQL injection ในที่สุด เราได้เรียนรู้ว่าการป้องกันการฉีด SQL ต้องการการปรับเปลี่ยนคำถามแบบพารามิเตอร์ ไม่ใช่การหลบหนีจากสตริงที่ดีกว่า เราต้องการวิธีแก้ปัญหาเชิงสถาปัตยกรรมสำหรับความปลอดภัยของเอไอ

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

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

  1. การยืนยันตัวตนโดยใช้ตัวตนเฉพาะที่สามารถตรวจสอบได้ (ไม่ใช่ความลับที่เก็บไว้)

  2. รับข้อมูลประจำตัวแบบ Just-In-Time ที่ใช้ได้เฉพาะสำหรับงานนั้นเท่านั้น

  3. มีข้อมูลประจำตัวหมดอายุอัตโนมัติภายในไม่กี่วินาทีหรือนาที

  4. ไม่เก็บหรือแม้แต่ “เห็น” ความลับที่มีอายุการใช้งานยาว

มีการเข้าใกล้ที่เกิดขึ้น AWS IAM บทบาทสำหรับบัญชีบริการ, Google’s Workload Identity, HashiCorp Vault’s dynamic secrets และวิธีแก้ปัญหาแบบกำหนดเอง เช่น Akeyless’s Zero Trust Provisioning ทั้งหมดนี้ชี้ไปที่อนาคตที่ไม่มีความลับของเรา

สภาพแวดล้อมการพัฒนาในปี 2027

ภายในสามปี ไฟล์ .env จะตายแล้วในการพัฒนาที่เพิ่มเอไอ API Key ที่มีอายุการใช้งานยาวที่อยู่ในตัวแปรสภาพแวดล้อมจะถูกมองว่าเป็นของโบราณที่น่าอาย เช่นเดียวกับรหัสผ่านที่อยู่ในข้อความธรรมดา

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

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

ทางเลือกที่เราต้องเผชิญ

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

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

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

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

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

OWASP ได้ระบุการฉีดคำสั่งย่อยเป็นอันตรายอันดับ 1 ใน Top 10 สำหรับแอปพลิเคชัน LLM NIST กำลังพัฒนาแนวทาง เกี่ยวกับสถาปัตยกรรม Zero Trust กรอบงานมีอยู่แล้ว คำถามเดียวคือความเร็วในการใช้งานเทียบกับการพัฒนาการโจมตี

ชีวประวัติ: Refael Angel เป็นผู้ร่วมก่อตั้งและ CTO ของ Akeyless โดยที่เขาพัฒนาเทคโนโลยีการเข้ารหัส Zero-Trust ที่ได้รับการจดสิทธิบัตรของบริษัท นักวิศวกรซอฟต์แวร์ที่มีประสบการณ์สูงด้านการเข้ารหัสลับและความปลอดภัยบนคลาวด์ Refael เคยทำงานเป็น Senior Software Engineer ที่ศูนย์วิจัยและพัฒนาของ Intuit ในอิสราเอล โดยที่เขาสร้างระบบจัดการคีย์เข้ารหัสในคลาวด์สาธารณะและออกแบบบริการการยืนยันตัวตนเครื่องจักร เขาได้รับวิทยาศาสตรบัณฑิตสาขาวิทยาการคอมพิวเตอร์จาก Jerusalem College of Technology ซึ่งเขาสำเร็จการศึกษาเมื่ออายุ 19 ปี

Refael Angel คือ Co-Founder และ CTO ของ Akeyless โดยที่เขาพัฒนาเทคโนโลยีการเข้ารหัส Zero-Trust ที่ได้รับสิทธิบัตรของบริษัท เขาเป็นนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์สูงและมีความเชี่ยวชาญในด้านการเข้ารหัสและการรักษาความปลอดภัยบนคลาวด์ Refael เคยทำงานเป็น Senior Software Engineer ที่ Intuit’s R&D center ในอิสราเอล โดยที่เขาพัฒนาระบบจัดการคีย์เข้ารหัสในสภาพแวดล้อมคลาวด์สาธารณะและออกแบบบริการการยืนยันตัวตนเครื่อง เขาได้รับ B.Sc. ในสาขาวิทยาการคอมพิวเตอร์จาก Jerusalem College of Technology ซึ่งเขาสำเร็จการศึกษาเมื่ออายุ 19 ปี