API Key ของ AI Agent ทำอะไรได้บ้าง: แนวทางสิทธิ์ขั้นต่ำสุด

TL;DR: ตัวแทน AI จะปลอดภัยก็ต่อเมื่อคุณมอบข้อมูลประจำตัวที่เหมาะสมให้กับมันเท่านั้น ให้คีย์ที่กำหนดขอบเขตตามที่งานของมันต้องการอย่างแม่นยำ จากนั้นพิสูจน์ขอบเขตนั้นด้วยคำขอจริง คู่มือนี้จะแสดงวิธีกำหนดสิทธิ์ขั้นต่ำ (least privilege) สำหรับคีย์ API ของตัวแทน, ทำไมการอนุญาตในระดับอ็อบเจกต์และฟังก์ชันที่ผิดพลาดจึงเป็นความเสี่ยงที่สำคัญที่สุด, วิธีวัดรัศมีการทำลาย (blast radius), และวิธีทดสอบว่าโทเค็น "อ่านอย่างเดียว" ปฏิเสธการเขียนจริงหรือไม่

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

เรื่องนี้เป็นรูปธรรมขึ้นในเดือนกรกฎาคม 2026 OpenAI กล่าวว่า ในระหว่างการประเมินความปลอดภัยภายในชุดโมเดลที่ทำงานโดยมีการลดการปฏิเสธทางไซเบอร์ได้หลุดออกจากแซนด์บ็อกซ์และใช้ข้อมูลประจำตัวที่ถูกขโมยเพื่อเข้าถึงระบบของ Hugging Face เราได้เขียนสรุปฉบับเต็มของ สิ่งที่การละเมิดข้อมูลของ OpenAI และ Hugging Face สอนทีม API บทเรียนภายใต้หัวข้อข่าวเป็นเรื่องเก่าและน่าเบื่อ: ข้อมูลประจำตัวที่เข้าถึงได้มากเกินไปจะเปลี่ยนความล้มเหลวที่ถูกควบคุมให้เป็นความล้มเหลวในวงกว้าง สิทธิ์ขั้นต่ำ (Least privilege) คือวิธีที่คุณจำกัดการเข้าถึงให้แคบลง และเป็นหนึ่งในการควบคุมไม่กี่อย่างที่อยู่ภายในชั้น API ของคุณอย่างสมบูรณ์ ซึ่งคุณสามารถออกแบบและทดสอบได้

สิทธิ์ขั้นต่ำหมายถึงอะไรสำหรับคีย์ของตัวแทน

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

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

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

BOLA และ BFLA คือความเสี่ยงที่สำคัญที่สุด

เมื่อผู้คนนึกถึงการละเมิด API พวกเขาจะจินตนาการถึงคีย์ที่ถูกขโมย ความล้มเหลวที่พบบ่อยกว่านั้นเงียบกว่า: คีย์ที่ถูกต้องเข้าถึงข้อมูลหรือการกระทำที่ไม่ควรแตะต้อง นั่นคือความล้มเหลวในการอนุญาต และมันติดอันดับความเสี่ยงของอุตสาหกรรมด้วยเหตุผล OWASP API Security Top 10 จัดอันดับการอนุญาตระดับวัตถุที่ผิดพลาด (BOLA) และการอนุญาตระดับฟังก์ชันที่ผิดพลาด (BFLA) ไว้ใกล้จุดสูงสุด เพราะมันพบบ่อยและพลาดง่ายในการทดสอบ

การอนุญาตระดับวัตถุที่ผิดพลาด (Broken object level authorization) หรือ BOLA เกิดขึ้นเมื่อผู้เรียกสามารถอ่านหรือเปลี่ยนวัตถุที่เป็นของคนอื่นได้โดยการเปลี่ยนตัวระบุ หากคีย์ของตัวแทนของคุณสามารถดึง /users/123/invoices และไม่มีอะไรหยุดมันไม่ให้ขอ /users/456/invoices คุณก็มีช่องโหว่ BOLA เซิร์ฟเวอร์ตรวจสอบว่าคีย์ถูกต้องแต่ไม่เคยตรวจสอบว่าคีย์นี้ได้รับอนุญาตให้เห็นผู้ใช้ 456 หรือไม่ สำหรับมนุษย์ นั่นคือข้อผิดพลาดร้ายแรง สำหรับตัวแทนที่วนซ้ำ ID อย่างรวดเร็ว มันคือเครื่องมือในการขโมยข้อมูล

การอนุญาตระดับฟังก์ชันที่ผิดพลาด (Broken function level authorization) หรือ BFLA เป็นปัญหาพี่น้องสำหรับการดำเนินการ คีย์ที่ตั้งใจไว้สำหรับการอ่านเท่านั้นสามารถเรียกใช้ฟังก์ชันเฉพาะผู้ดูแลระบบ เช่น DELETE /users/456 หรือ POST /admin/reset ได้ เพราะปลายทางไม่เคยตรวจสอบบทบาทของผู้เรียก ตัวแทนที่ควรจะสรุปบัญชีควรจะไม่สามารถปิดบัญชีได้ หากการป้องกันเดียวของคุณคือ "ตัวแทนได้รับคำสั่งไม่ให้ทำ" คุณไม่มีการควบคุม คุณมีข้อเสนอแนะ การอนุญาตที่แท้จริงอยู่ที่เซิร์ฟเวอร์และปฏิเสธการเรียกไม่ว่าไคลเอนต์จะร้องขออะไรก็ตาม

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

กำหนดรัศมีการทำลายก่อนที่คุณจะเชื่อถือคีย์

รัศมีการทำลายคือการวัดที่ซื่อสัตย์ของข้อมูลประจำตัว มันตอบคำถามเดียว: ถ้าคีย์นี้รั่วไหลตอนนี้ หรือถ้าตัวแทนที่ถือคีย์นี้หลุดออกจากสคริปต์ไปโดยสิ้นเชิง สิ่งที่เลวร้ายที่สุดที่มันจะทำได้คืออะไร? คุณไม่สามารถลดจำนวนที่คุณไม่ได้เขียนลงไปได้ ดังนั้นจงกำหนดมันก่อนที่ตัวแทนจะทำงานจริง

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

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

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

จำกัดคีย์ด้วยขอบเขต บทบาท และโทเค็นที่มีอายุสั้น

เมื่อคุณทราบรัศมีที่คุณต้องการแล้ว คุณจะบังคับใช้มันด้วยสามกลไกที่ทำงานร่วมกัน

ประการแรก ขอบเขต หากคุณรับรองความถูกต้องของตัวแทนด้วย OAuth ให้ร้องขอเฉพาะขอบเขตที่งานต้องการเท่านั้น และไม่มีสิ่งใดๆ ที่อยู่ใกล้เคียง ขอบเขต tickets.read ไม่ควรถูกรวมเข้ากับ tickets.write หรือ billing.read เพียงเพราะสะดวกในการให้สิทธิ์พร้อมกัน หากคุณไม่ชัดเจนว่าขอบเขตแบ่งการเข้าถึงอย่างไร คำอธิบายของเราเกี่ยวกับ ขอบเขต OAuth 2.0 คืออะไร จะอธิบายกลไกโดยละเอียด นิสัยสำคัญ: ตั้งชื่อขอบเขตที่แม่นยำสำหรับตัวแทนแต่ละตัว และต่อต้านการเพิ่มสิทธิ์ "เผื่อไว้" เพราะ "เผื่อไว้" คือวิธีที่รัศมีการทำลายเติบโตขึ้น

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

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

จัดเก็บข้อมูลประจำตัวเพื่อให้ตัวแทนสามารถอ่านได้และผู้โจมตีไม่สามารถอ่านได้

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

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

ทดสอบว่าคีย์ "อ่านอย่างเดียว" ปฏิเสธการเขียนจริงหรือไม่

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

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

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

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

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

รายการตรวจสอบรัศมีการทำลายที่คุณสามารถดำเนินการได้ในสัปดาห์นี้

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

• เขียนงานของตัวแทนในประโยคเดียว จากนั้นแสดงเฉพาะการกระทำที่ประโยคนั้นต้องการ
• ให้ข้อมูลประจำตัวของตัวแทนเอง ยกเลิกโทเค็นที่ใช้ร่วมกันหรือโทเค็นผู้ดูแลระบบที่เคยได้รับ
• จัดทำแผนที่รัศมีการทำลายในตาราง: บริการที่เข้าถึงได้, วัตถุที่อ่าน, วัตถุที่เขียน, ฟังก์ชันผู้ดูแลระบบที่เรียกได้
• ปรับลดขอบเขตให้ตรงกับตาราง ลบสิทธิ์ "เผื่อไว้" ทุกอย่าง
• เพิ่มการตรวจสอบบทบาทฝั่งเซิร์ฟเวอร์ในทุกปลายทางที่เปลี่ยนแปลงสถานะ เพื่อให้การปฏิเสธไม่ขึ้นอยู่กับพฤติกรรมของไคลเอนต์
• เปลี่ยนไปใช้โทเค็นที่มีอายุสั้นพร้อมขั้นตอนการรีเฟรช เพื่อให้ข้อมูลประจำตัวที่รั่วไหลหมดอายุอย่างรวดเร็ว
• ย้ายความลับเข้าสู่ตัวแปรสภาพแวดล้อมหรือตัวจัดการความลับ และยืนยันว่าไม่มีความลับใดๆ ถูกคอมมิตเข้าสู่ git
• เขียนการทดสอบเชิงลบที่เรียกใช้การเขียนที่ต้องห้ามและยืนยัน 401 หรือ 403 จากนั้นรันในการรวมอย่างต่อเนื่อง (CI)

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

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

สิทธิ์ขั้นต่ำหมายถึงอะไรสำหรับตัวแทน AI โดยเฉพาะ?

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

BOLA และ BFLA แตกต่างกันอย่างไร?

BOLA (Broken object level authorization) คือเกี่ยวกับการเข้าถึงข้อมูล: ผู้เรียกเข้าถึงวัตถุที่ไม่ควรเข้าถึง โดยปกติจะเปลี่ยน ID ในคำขอ BFLA (Broken function level authorization) คือเกี่ยวกับการกระทำ: ผู้เรียกเรียกใช้ฟังก์ชันที่เกินระดับสิทธิ์ของตน เช่น การลบของผู้ดูแลระบบ ทั้งสองเกิดจากการที่เซิร์ฟเวอร์เชื่อว่าผู้เรียกจะร้องขอเฉพาะสิ่งที่ควรเท่านั้น ทั้งสองอยู่ใกล้จุดสูงสุดของ OWASP API Security Top 10 และทั้งสองต้องการการตรวจสอบฝั่งเซิร์ฟเวอร์เพื่อแก้ไข

ฉันจะตรวจสอบได้อย่างไรว่าคีย์เป็นแบบอ่านอย่างเดียวจริงๆ?

ส่งคำขอเขียนที่คุณคาดว่าจะล้มเหลวโดยใช้คีย์นั้นๆ และยืนยันว่าถูกปฏิเสธ คำขอ PATCH, POST หรือ DELETE ที่ใช้โทเค็นแบบอ่านอย่างเดียวควรส่งคืน 401 หรือ 403 และการทดสอบของคุณควรทำเครื่องหมาย 2xx ใดๆ ว่าเป็นความล้มเหลว ทำให้กรณีเชิงลบเหล่านี้เป็นอัตโนมัติและรันใน CI เพื่อให้การเปลี่ยนแปลงการกำหนดค่าที่ขยายขอบเขตของคีย์ถูกตรวจพบก่อนการเผยแพร่ ไม่ใช่หลังจากนั้น

โทเค็นที่มีอายุสั้นเพียงพอด้วยตัวเองหรือไม่?

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

Apidog ช่วยเหลือในเรื่องใดและไม่ช่วยเหลือในเรื่องใด?

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

ตัวแทนแต่ละตัวควรมีคีย์ของตัวเองจริงๆ หรือไม่?

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