กำไร:
- ความสามารถในการแยกการรับรองความถูกต้องและการอนุญาต และใช้การอนุญาตขั้นต่ำกับ RBAC/ABAC
- ความสามารถในการหลีกเลี่ยงความเสี่ยงพร็อกซีแบบผสมโดยการรันโมเดลในบริบทของผู้ใช้
- ความสามารถในการจัดเก็บและหมุนเวียนคีย์ API ด้วยระบบการจัดการความลับ
ส่วนสำคัญของการโจมตีระบบ AI เริ่มต้นด้วยการ "หลอกลวง" โมเดล แต่เริ่มต้นด้วยคีย์ API ที่ถูกขโมยหรือบัญชีที่ได้รับอนุญาตมากเกินไป การรักษาความปลอดภัยชั้นนี้มาจากการรักษาความปลอดภัยของข้อมูลแบบคลาสสิก แต่เพิ่มความเสี่ยงใหม่ในบริบทของ AI: โมเดลเรียกใช้การดำเนินการในนามของบุคคลอื่น บัญชีบริการเข้าถึงข้อมูลทั้งหมด การรั่วไหลของคีย์ไปยัง GitHub ในหน่วยนี้ เราจะได้เรียนรู้วิธีจำกัดการเข้าถึงระบบ AI ด้วยการตรวจสอบสิทธิ์ การอนุญาต (RBAC/ABAC) การอนุญาตขั้นต่ำ และการจัดการความลับ
ความแตกต่างระหว่างการรับรองความถูกต้องและการอนุญาต
คำสองคำนี้มักสับสน:
- การรับรองความถูกต้อง: "คุณเป็นใคร" — การพิสูจน์ว่าผู้ใช้/บริการคือสิ่งที่พวกเขาอ้างว่าเป็นจริงๆ (รหัสผ่าน โทเค็น ใบรับรอง MFA)
- การอนุญาต: "คุณทำอะไรได้บ้าง" — กำหนดทรัพยากร/การดำเนินการที่ฝ่ายที่ได้รับการตรวจสอบสิทธิ์สามารถเข้าถึงได้
ความละเอียดอ่อนที่สำคัญในระบบ AI คือ: เมื่อแบบจำลองกำลังทำงานในนามของผู้ใช้ โมเดลนั้นทำงานโดยได้รับอนุญาตจากผู้ใช้นั้นหรือกับบัญชีบริการที่กว้างขวางหรือไม่ อย่างหลังเป็นอันตราย — เนื่องจากโมเดลที่ถูกหลอกโดยการฉีดจะสามารถเข้าถึงบัญชีบริการได้อย่างสมบูรณ์
ข้อควรระวัง: ปัญหา "รองสับสน": ผู้ใช้ที่มีอำนาจต่ำเข้าถึงข้อมูลทางอ้อมซึ่งเขาไม่สามารถเข้าถึงได้โดยการจ้างโมเดลที่มีอำนาจสูง โมเดลควรดำเนินการภายในบริบทของอำนาจของผู้ใช้เสมอ ไม่ใช่อำนาจในวงกว้างของเขาเอง
อาร์แบค และเอแบค
- RBAC (การควบคุมการเข้าถึงตามบทบาท): การเข้าถึงขึ้นอยู่กับบทบาทของผู้ใช้ บทบาท "ผู้เชี่ยวชาญด้านการสนับสนุน" สามารถอ่านบันทึกของลูกค้าได้ แต่ไม่สามารถลบออกได้ เรียบง่ายและเป็นเรื่องธรรมดา
- ABAC (การควบคุมการเข้าถึงตามคุณลักษณะ): การเข้าถึงขึ้นอยู่กับคุณลักษณะ: แผนกของผู้ใช้ ป้ายความเป็นส่วนตัวของข้อมูล เวลาของวัน เครือข่ายที่มาของคำขอ ละเอียดมากขึ้นแต่ซับซ้อนมากขึ้น
องค์กรส่วนใหญ่เริ่มต้นด้วย RBAC และเจาะลึกถึง ABAC สำหรับข้อมูลที่ละเอียดอ่อน หลักทั่วไปสำหรับ AI: โมเดลควรกรองทุกตัวแทนที่เรียกใช้และข้อมูลทั้งหมดที่เข้าถึงตามบทบาท/คุณลักษณะของผู้ใช้ที่ส่งคำขอ
ทีละขั้นตอน: การใช้อำนาจขั้นต่ำ
- ใช้สินค้าคงคลัง โมเดลเรียกใช้เครื่องมืออะไร เข้าถึงข้อมูลใดบ้าง แสดงรายการทั้งหมด
- ปรับการเข้าถึงแต่ละครั้ง “ผู้ช่วยคนนี้จำเป็นต้องมีสิทธิ์ในการลบจริง ๆ เหรอ?” มิฉะนั้นให้ถอดออก
- ค่าเริ่มต้นแบบอ่านอย่างเดียว โมเดลควรจะสามารถอ่านได้โดยค่าเริ่มต้น ต้องมีการเขียน/ลบโทเค็นขอบเขตแคบแยกกัน
- ย้ายบริบทของผู้ใช้ โทรหารถยนต์โดยได้รับอนุญาตจากผู้ใช้ ไม่ใช่ด้วยบัญชีบริการ
- หนังสือรับรองอายุสั้น ใช้โทเค็นอายุสั้นและต่ออายุอัตโนมัติแทนคีย์ที่มีอายุยาวนาน
การจัดการความลับ
ข้อมูลลับคือข้อมูลรับรองที่ต้องเป็นความลับ เช่น คีย์ API รหัสผ่าน โทเค็น หรือใบรับรอง อุบัติเหตุที่พบบ่อยที่สุดในโปรเจ็กต์ AI คือเมื่อคีย์ API ของผู้ให้บริการโมเดลถูกฝังอยู่ในโค้ดและรั่วไหลไปยัง Version Control (Git)
การสมัครที่ถูกต้อง:
- ไม่เคยฝังคีย์ในโค้ด ใช้ตัวแปรสภาพแวดล้อมหรือระบบการจัดการความลับ (บริการที่เก็บคีย์ที่เข้ารหัสและควบคุมการเข้าถึง)
- การหมุน: ต่ออายุคีย์ตามช่วงเวลาปกติ (เช่น ทุก 90 วัน) หากสงสัยว่ามีการรั่วไหล ให้ยกเลิกทันที
- การลดขอบเขต: สวิตช์แต่ละตัวมีเพียงบริการที่จำเป็นและการอนุญาตที่จำเป็นเท่านั้น
- การตรวจสอบ: บันทึกผู้ที่ใช้กุญแจ เมื่อใด และที่ไหน
เทมเพลตที่คัดลอกได้สี่แบบ
พรอมต์การควบคุมการเข้าถึงการตรวจสอบ:
สำหรับแต่ละเครื่องมือในรายการเครื่องมือด้านล่าง ให้ประเมิน:- จำเป็นต้องใช้เครื่องมือนี้เพื่อปฏิบัติงานของผู้ช่วยคนนี้หรือไม่? (ใช่/ไม่ใช่) - อ่านอย่างเดียวหรือเขียน/ลบ? - เครื่องมือนี้ถูกเรียกด้วยสิทธิ์ของผู้ใช้หรือบัญชีบริการหรือไม่ ทำเครื่องหมายรายการที่ไม่จำเป็นหรือได้รับอนุญาตมากเกินไปเป็น "REMOVE/REDACT"<tools>{{ tool_list }}</tools>
พรอมต์การสแกนความลับรั่วไหล:
ค้นหาทุกสิ่งที่อาจเป็นความลับแบบฮาร์ดโค้ดในข้อมูลโค้ดต่อไปนี้: คีย์ API, รหัสผ่าน, โทเค็น, สตริงการเชื่อมต่อ, คีย์ส่วนตัว ระบุแถวและประเภทให้กับแต่ละรายการ COPY ค่าลงใน response;mask (อักขระ 4 ตัวแรก + ***)<code>{{ source }}</code>
กฎการตัดสินใจที่มีอำนาจน้อยที่สุด:
เมื่อมีคำขอเครื่องมือ/การเข้าถึงใหม่มาถึง ให้ถาม:1. งานนี้สามารถทำได้โดยไม่ต้องเข้าถึงนี้หรือไม่? -> ถ้าใช่: ปฏิเสธ2. อ่านอย่างเดียวเพียงพอหรือไม่? -> ถ้าใช่: ให้สิทธิ์ในการเขียน3. สามารถจำกัดขอบเขตให้แคบลงเหลือแหล่งเดียวได้หรือไม่ -> ถ้าใช่: daratคำตอบเริ่มต้นคือ "ไม่"; การเข้าถึงได้มาด้วยเหตุผล
การแจ้งเตือนปฏิทินหมุนเวียน:
สำหรับแต่ละความลับ ให้บันทึก: เจ้าของ วันที่สร้าง วันหมดอายุ ขอบเขต รายงานคีย์ใด ๆ ที่เกิน 90 วันหรือไม่ได้ใช้เป็นเวลา 30 วันในฐานะ "ผู้สมัครการหมุนเวียน/การยกเลิก"
พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง
วิธีการที่ไม่ดี
แนวทางที่แข็งแกร่ง
โมเดลเข้าถึงข้อมูลทั้งหมดด้วยบัญชีบริการเดียว
โมเดลเข้าถึงโดยมีสิทธิ์ของผู้ใช้ที่ทำการร้องขอ
คีย์ API ถูกฝังอยู่ในโค้ด แต่ไม่มีการเปลี่ยนแปลง
การหมุนเวียนในเครื่องมือจัดการข้อมูลลับที่สำคัญ 90 วัน
อำนาจในการ "ทำทุกอย่าง" อย่างกว้างๆ แก่ผู้ช่วย
ค่าเริ่มต้นแบบอ่านอย่างเดียว เขียนให้แคบลง
การเข้าถึงจะไม่ได้รับการตรวจสอบ
การตรวจสอบและการเพิกถอนการเข้าถึงเป็นประจำ
มินิเคสสามอัน
กรณีที่ 1 — ข้อมูลพร็อกซีผสมรั่วไหล ผู้ช่วยภายในทำงานกับบัญชีบริการที่สามารถเข้าถึงบันทึกของพนักงานทั้งหมด ผู้ใช้ฝึกงานเข้าถึงข้อมูลที่ปกติเขาจะไม่เห็นโดยพูดว่า "สรุปตารางเงินเดือนผู้บริหาร"; เพราะโมเดลตั้งคำถามในบริบทของอำนาจในวงกว้างของตัวเอง ไม่ใช่ของผู้ใช้ เมื่อปรับบริบทของผู้ใช้ให้ย้ายแล้ว เด็กฝึกงานก็สามารถดึงบันทึกที่มีเพียงเขาหรือเธอเท่านั้นที่มองเห็นได้
กรณีที่ 2 — กุญแจรั่ว, ใบเรียกเก็บเงิน 190,000 TL ใน 2 สัปดาห์ นักพัฒนาฝังคีย์ API ของโมเดลไว้ในสคริปต์ตัวช่วยและพุชไปยังที่เก็บข้อมูลสาธารณะ บอทพบกุญแจภายใน 40 นาทีและใช้มันเป็นเวลาสองสัปดาห์ บิลมียอดถึง 190,000 TL เมื่อคีย์ถูกย้ายไปยัง Secret Manager ซึ่งเชื่อมต่อกับการหมุน และเพิ่มการสแกนที่เก็บข้อมูล เหตุการณ์จะไม่เกิดขึ้นอีก
กรณีที่ 3 — ค่าเริ่มต้นแบบอ่านอย่างเดียวป้องกันการขัดจังหวะ ผู้ช่วย DevOps ได้รับคำสั่ง "รีเซ็ตฐานข้อมูลที่ใช้งานจริง" ผ่านการสั่งงานพร้อมท์ อย่างไรก็ตาม ผู้ช่วยได้รับเพียงโทเค็นแบบอ่านอย่างเดียวเท่านั้น การเขียน/ลบอยู่ในขั้นตอนที่ได้รับอนุมัติแยกต่างหาก คำสั่งถูกปฏิเสธโดยมีข้อผิดพลาดในการอนุญาต และเหตุการณ์ถูกบันทึกเป็นสัญญาณเตือน ไม่มีข้อมูลสูญหาย
เคล็ดลับ: ทำให้ "ไม่" เป็นคำตอบเริ่มต้นสำหรับคำขอเข้าถึงใหม่ การเข้าถึงคือสิ่งที่ได้มาจากการให้เหตุผล การให้ทุกคนกว้างๆ แล้วลดน้อยลงนั้นแทบไม่เคยเกิดขึ้นเลย และความเสี่ยงก็สะสม
ข้อผิดพลาดทั่วไป
- ใช้งานโมเดลด้วยบัญชีบริการขนาดใหญ่และสูญเสียบริบทของผู้ใช้ (พร็อกซีผสม)
- การฝังคีย์ API ในโค้ดและรั่วไหลไปยังการควบคุมเวอร์ชัน
- ไม่หมุนกุญแจเลย ("ใช้งานอยู่ ห้ามแตะ")
- ให้สิทธิ์การเขียน/ลบแก่ผู้ช่วยตามค่าเริ่มต้น
- ให้สิทธิ์การเข้าถึงเพียงครั้งเดียวและไม่เคยพิจารณาใหม่
- ทำให้การรับรองความถูกต้องสับสนกับการอนุญาตและสมมติว่า "เขาเข้าสู่ระบบแล้ว เขาสามารถเข้าถึงทุกสิ่งได้"
โดยสรุป
- การรับรองความถูกต้องคือคำถามว่า "คุณเป็นใคร" การอนุญาตคือคำถามว่า "คุณทำอะไรได้บ้าง" ใน AI ทั้งสองอย่างจะต้องดำเนินการในบริบทของผู้ใช้
- โมเดลควรดำเนินการโดยได้รับอำนาจจากผู้ใช้ที่ทำการร้องขอ ไม่ใช่ด้วยอำนาจในวงกว้างของตนเอง (หลีกเลี่ยงความเสี่ยงจากเอเจนซี่ผสม)
- เริ่มต้นด้วย RBAC เจาะลึกด้วย ABAC ในข้อมูลที่ละเอียดอ่อน กำหนดให้สิทธิ์ขั้นต่ำเป็นค่าเริ่มต้น
- อย่าฝังความลับไว้ในโค้ด เก็บไว้ในเครื่องมือจัดการความลับ จำกัดให้แคบลงและหมุนเวียนตามปกติ
- ค่าเริ่มต้นแบบอ่านอย่างเดียวและการเขียนแบบแคบจะจำกัดผลกระทบของการฉีดอย่างมาก
งานสมัคร
แสดงรายการเครื่องมือและข้อมูลทั้งหมดที่ผู้ช่วย AI ของคุณเข้าถึง ตอบคำถามสามข้อสำหรับแต่ละข้อ: (1) จำเป็นจริงๆ หรือไม่? (2) อ่านอย่างเดียวเพียงพอหรือไม่ (3) มันทำงานในบริบทของผู้ใช้หรือไม่? จากนั้นค้นหาความลับที่ฮาร์ดโค้ดทั้งหมด (ผ่านพร้อมท์การสแกนด้านบน) และเขียนแผนการหมุนเวียนสำหรับแต่ละคีย์ที่คุณพบ ลบการอนุญาตที่ไม่จำเป็นอย่างน้อยหนึ่งรายการ
รายการตรวจสอบ
- [ ] โมเดลทำงานในบริบทสิทธิ์ของผู้ใช้ที่ทำการร้องขอ
- [ ] การเข้าถึงเครื่องมือและข้อมูลถูกจำกัดให้แคบลงเหลือเพียงหลักการมีสิทธิ์น้อยที่สุด
- [ ] การเขียน/ลบแยกจากอ่านอย่างเดียว รับรองความถูกต้อง และแคบ
- [ ] ไม่มีความลับใดถูกฝังอยู่ในรหัส มันถูกเก็บไว้ในผู้จัดการความลับ
- [ ] มีกำหนดการหมุนเวียนและขั้นตอนการยกเลิกคีย์
- [ ] การเข้าถึงได้รับการตรวจสอบเป็นประจำ