การนำ Model Context Protocol (MCP) มาใช้ช่วยเพิ่มขีดความสามารถใหม่ ๆ ให้กับแอปพลิเคชันที่ขับเคลื่อนด้วย AI แต่ก็สร้างความท้าทายด้านความปลอดภัยเฉพาะตัวที่เกินกว่าความเสี่ยงของซอฟต์แวร์ทั่วไป นอกจากความกังวลที่มีอยู่แล้ว เช่น การเขียนโค้ดอย่างปลอดภัย การให้สิทธิ์แบบน้อยที่สุด และความปลอดภัยในห่วงโซ่อุปทาน MCP และงาน AI ยังต้องเผชิญกับภัยคุกคามใหม่ ๆ เช่น การโจมตีด้วย prompt injection, การปลอมแปลงเครื่องมือ และการแก้ไขเครื่องมือแบบไดนามิก ความเสี่ยงเหล่านี้อาจนำไปสู่การรั่วไหลของข้อมูล การละเมิดความเป็นส่วนตัว และพฤติกรรมของระบบที่ไม่คาดคิดหากไม่ได้รับการจัดการอย่างเหมาะสม
บทเรียนนี้จะสำรวจความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับ MCP มากที่สุด เช่น การพิสูจน์ตัวตน การให้สิทธิ์ การอนุญาตเกินความจำเป็น การโจมตีแบบ prompt injection ทางอ้อม และช่องโหว่ในห่วงโซ่อุปทาน พร้อมทั้งให้คำแนะนำและแนวทางปฏิบัติที่สามารถนำไปใช้ได้จริงเพื่อบรรเทาความเสี่ยงเหล่านี้ คุณจะได้เรียนรู้วิธีใช้โซลูชันของ Microsoft เช่น Prompt Shields, Azure Content Safety และ GitHub Advanced Security เพื่อเสริมความแข็งแกร่งให้กับการใช้งาน MCP ของคุณ ด้วยการเข้าใจและนำควบคุมเหล่านี้ไปใช้ คุณจะช่วยลดความเป็นไปได้ของการถูกโจมตีและทำให้ระบบ AI ของคุณมีความน่าเชื่อถือและมั่นคงมากขึ้น
เมื่อจบบทเรียนนี้ คุณจะสามารถ:
- ระบุและอธิบายความเสี่ยงด้านความปลอดภัยเฉพาะตัวที่เกิดจาก Model Context Protocol (MCP) รวมถึง prompt injection, การปลอมแปลงเครื่องมือ, การอนุญาตเกินความจำเป็น และช่องโหว่ในห่วงโซ่อุปทาน
- อธิบายและนำควบคุมที่มีประสิทธิภาพมาใช้เพื่อลดความเสี่ยงด้านความปลอดภัยของ MCP เช่น การพิสูจน์ตัวตนที่แข็งแกร่ง การให้สิทธิ์แบบน้อยที่สุด การจัดการโทเค็นอย่างปลอดภัย และการตรวจสอบห่วงโซ่อุปทาน
- เข้าใจและใช้โซลูชันของ Microsoft เช่น Prompt Shields, Azure Content Safety และ GitHub Advanced Security เพื่อปกป้อง MCP และงาน AI
- ตระหนักถึงความสำคัญของการตรวจสอบข้อมูลเมตาของเครื่องมือ การติดตามการเปลี่ยนแปลงแบบไดนามิก และการป้องกันการโจมตีแบบ prompt injection ทางอ้อม
- รวมแนวปฏิบัติด้านความปลอดภัยที่ได้รับการยอมรับ เช่น การเขียนโค้ดอย่างปลอดภัย การเสริมความแข็งแกร่งของเซิร์ฟเวอร์ และสถาปัตยกรรม zero trust เข้าไปในการใช้งาน MCP เพื่อช่วยลดโอกาสและผลกระทบจากการถูกโจมตี
ระบบใด ๆ ที่เข้าถึงทรัพยากรสำคัญจะมีความท้าทายด้านความปลอดภัยโดยนัย ความท้าทายด้านความปลอดภัยโดยทั่วไปสามารถจัดการได้ด้วยการประยุกต์ใช้ควบคุมและแนวคิดพื้นฐานด้านความปลอดภัยอย่างถูกต้อง เนื่องจาก MCP เป็นโปรโตคอลที่เพิ่งถูกกำหนดขึ้นใหม่ ข้อกำหนดยังเปลี่ยนแปลงอย่างรวดเร็วและมีการพัฒนาอย่างต่อเนื่อง ในที่สุดควบคุมด้านความปลอดภัยภายในจะเติบโตและช่วยให้การรวมเข้ากับสถาปัตยกรรมความปลอดภัยขององค์กรและแนวปฏิบัติที่ได้รับการยอมรับทำได้ดียิ่งขึ้น
งานวิจัยที่เผยแพร่ใน Microsoft Digital Defense Report ระบุว่า 98% ของการละเมิดที่รายงานสามารถป้องกันได้ด้วยสุขอนามัยด้านความปลอดภัยที่เข้มงวด และการป้องกันที่ดีที่สุดต่อการละเมิดใด ๆ คือการทำให้สุขอนามัยด้านความปลอดภัยพื้นฐาน การเขียนโค้ดอย่างปลอดภัย และความปลอดภัยในห่วงโซ่อุปทานถูกต้องและเหมาะสม — แนวทางที่ผ่านการทดสอบและพิสูจน์แล้วเหล่านี้ยังคงมีผลมากที่สุดในการลดความเสี่ยงด้านความปลอดภัย
มาดูวิธีการบางอย่างที่คุณสามารถเริ่มจัดการความเสี่ยงด้านความปลอดภัยเมื่อนำ MCP มาใช้
Note: ข้อมูลต่อไปนี้ถูกต้อง ณ วันที่ 29 พฤษภาคม 2025 โปรโตคอล MCP กำลังพัฒนาอย่างต่อเนื่อง และการใช้งานในอนาคตอาจมีรูปแบบการพิสูจน์ตัวตนและควบคุมใหม่ ๆ สำหรับข้อมูลล่าสุดและคำแนะนำ กรุณาอ้างอิงที่ MCP Specification และที่เก็บโค้ด MCP GitHub repository รวมถึง security best practice page
ข้อกำหนด MCP เดิมสมมติว่าผู้พัฒนาจะเขียนเซิร์ฟเวอร์พิสูจน์ตัวตนเอง ซึ่งต้องมีความรู้เกี่ยวกับ OAuth และข้อจำกัดด้านความปลอดภัยที่เกี่ยวข้อง เซิร์ฟเวอร์ MCP ทำหน้าที่เป็น OAuth 2.0 Authorization Servers จัดการการพิสูจน์ตัวตนของผู้ใช้โดยตรง แทนที่จะมอบหมายให้บริการภายนอกเช่น Microsoft Entra ID ตั้งแต่วันที่ 26 เมษายน 2025 เป็นต้นมา ข้อกำหนด MCP ได้อัปเดตให้เซิร์ฟเวอร์ MCP สามารถมอบหมายการพิสูจน์ตัวตนของผู้ใช้ให้กับบริการภายนอกได้
- การกำหนดตรรกะการให้สิทธิ์ในเซิร์ฟเวอร์ MCP ผิดพลาดอาจนำไปสู่การเปิดเผยข้อมูลที่ละเอียดอ่อนและการใช้การควบคุมการเข้าถึงผิดพลาด
- การขโมยโทเค็น OAuth บนเซิร์ฟเวอร์ MCP ภายในเครื่อง หากถูกขโมย โทเค็นนั้นสามารถนำไปใช้แอบอ้างเป็นเซิร์ฟเวอร์ MCP และเข้าถึงทรัพยากรและข้อมูลจากบริการที่โทเค็น OAuth นั้นใช้ได้
Token passthrough ถูกห้ามอย่างชัดเจนในข้อกำหนดการให้สิทธิ์เพราะสร้างความเสี่ยงด้านความปลอดภัยหลายประการ เช่น:
เซิร์ฟเวอร์ MCP หรือ API ปลายทางอาจมีการใช้งานควบคุมความปลอดภัยสำคัญ เช่น การจำกัดอัตราการใช้งาน การตรวจสอบคำขอ หรือการตรวจจับทราฟฟิก ที่พึ่งพา token audience หรือข้อจำกัดอื่น ๆ ของข้อมูลรับรอง หากไคลเอนต์สามารถขอและใช้โทเค็นโดยตรงกับ API ปลายทางโดยไม่ผ่านการตรวจสอบอย่างถูกต้องจากเซิร์ฟเวอร์ MCP หรือไม่มั่นใจว่าโทเค็นออกให้กับบริการที่ถูกต้อง จะทำให้ควบคุมเหล่านี้ถูกข้ามไป
เซิร์ฟเวอร์ MCP จะไม่สามารถระบุหรือแยกแยะไคลเอนต์ MCP ได้เมื่อไคลเอนต์เรียกด้วยโทเค็นที่ออกโดยต้นทางซึ่งอาจเป็นข้อมูลที่เซิร์ฟเวอร์ MCP มองไม่เห็น บันทึกของเซิร์ฟเวอร์ทรัพยากรปลายทางอาจแสดงคำขอที่ดูเหมือนมาจากแหล่งที่ต่างกันและตัวตนที่ต่างจากเซิร์ฟเวอร์ MCP ที่ส่งต่อโทเค็นจริง ปัจจัยทั้งสองนี้ทำให้การสืบสวนเหตุการณ์ การควบคุม และการตรวจสอบทำได้ยากขึ้น หากเซิร์ฟเวอร์ MCP ส่งต่อโทเค็นโดยไม่ตรวจสอบคำอ้างสิทธิ์ (เช่น บทบาท สิทธิพิเศษ หรือ audience) หรือข้อมูลเมตาอื่น ๆ ผู้ไม่หวังดีที่มีโทเค็นที่ถูกขโมยสามารถใช้เซิร์ฟเวอร์เป็นพร็อกซีสำหรับการขโมยข้อมูลได้
เซิร์ฟเวอร์ทรัพยากรปลายทางมอบความเชื่อถือให้กับหน่วยงานเฉพาะ ความเชื่อนี้อาจรวมถึงสมมติฐานเกี่ยวกับแหล่งที่มา หรือลักษณะการทำงานของไคลเอนต์ การทำลายขอบเขตความเชื่อนี้อาจนำไปสู่ปัญหาที่ไม่คาดคิด หากโทเค็นถูกยอมรับโดยหลายบริการโดยไม่มีการตรวจสอบอย่างเหมาะสม ผู้โจมตีที่เจาะบริการหนึ่งได้สามารถใช้โทเค็นนั้นเพื่อเข้าถึงบริการอื่นที่เชื่อมต่อกันได้
แม้ว่าเซิร์ฟเวอร์ MCP จะเริ่มต้นเป็น “พร็อกซีบริสุทธิ์” ในวันนี้ อาจต้องเพิ่มควบคุมความปลอดภัยในภายหลัง การเริ่มต้นด้วยการแยก audience ของโทเค็นอย่างถูกต้องจะช่วยให้การพัฒนารูปแบบความปลอดภัยง่ายขึ้น
เซิร์ฟเวอร์ MCP ต้องไม่รับโทเค็นใด ๆ ที่ไม่ได้ออกให้กับเซิร์ฟเวอร์ MCP โดยเฉพาะ
- ตรวจสอบและเสริมตรรกะการให้สิทธิ์: ตรวจสอบการใช้งานการให้สิทธิ์ของเซิร์ฟเวอร์ MCP อย่างละเอียดเพื่อให้แน่ใจว่ามีเพียงผู้ใช้และไคลเอนต์ที่ตั้งใจเท่านั้นที่เข้าถึงทรัพยากรที่ละเอียดอ่อน สำหรับคำแนะนำเชิงปฏิบัติ ดูที่ Azure API Management Your Auth Gateway For MCP Servers | Microsoft Community Hub และ Using Microsoft Entra ID To Authenticate With MCP Servers Via Sessions - Den Delimarsky
- บังคับใช้แนวทางปฏิบัติการจัดการโทเค็นอย่างปลอดภัย: ปฏิบัติตาม แนวทางปฏิบัติที่ดีที่สุดของ Microsoft สำหรับการตรวจสอบและอายุของโทเค็น เพื่อป้องกันการใช้โทเค็นเข้าถึงผิดวิธีและลดความเสี่ยงจากการเล่นซ้ำหรือการขโมยโทเค็น
- ปกป้องการเก็บโทเค็น: เก็บโทเค็นอย่างปลอดภัยเสมอและใช้การเข้ารหัสเพื่อปกป้องข้อมูลทั้งขณะพักและขณะส่ง สำหรับคำแนะนำการใช้งาน ดูที่ Use secure token storage and encrypt tokens
เซิร์ฟเวอร์ MCP อาจได้รับสิทธิ์เกินความจำเป็นสำหรับบริการหรือทรัพยากรที่เข้าถึง เช่น เซิร์ฟเวอร์ MCP ที่เป็นส่วนหนึ่งของแอปพลิเคชัน AI ด้านการขายที่เชื่อมต่อกับคลังข้อมูลองค์กร ควรได้รับสิทธิ์เข้าถึงเฉพาะข้อมูลการขายเท่านั้น และไม่ควรเข้าถึงไฟล์ทั้งหมดในคลังข้อมูล การอ้างอิงกลับไปยังหลักการ least privilege (หนึ่งในหลักการความปลอดภัยที่เก่าแก่ที่สุด) ทรัพยากรใด ๆ ไม่ควรได้รับสิทธิ์เกินกว่าที่จำเป็นสำหรับการทำงานที่ตั้งใจไว้ AI นำความท้าทายเพิ่มขึ้นในพื้นที่นี้เพราะเพื่อให้มีความยืดหยุ่น อาจยากที่จะกำหนดสิทธิ์ที่แน่นอนที่จำเป็น
- การให้สิทธิ์เกินความจำเป็นอาจทำให้เกิดการขโมยข้อมูลหรือการแก้ไขข้อมูลที่เซิร์ฟเวอร์ MCP ไม่ควรเข้าถึงได้ ซึ่งอาจเป็นปัญหาด้านความเป็นส่วนตัวหากข้อมูลนั้นเป็นข้อมูลส่วนบุคคล (PII)
- ใช้หลักการ least privilege: ให้สิทธิ์กับเซิร์ฟเวอร์ MCP เฉพาะที่จำเป็นสำหรับการทำงานที่ต้องการเท่านั้น ตรวจสอบและอัปเดตสิทธิ์เหล่านี้อย่างสม่ำเสมอเพื่อให้แน่ใจว่าไม่เกินความจำเป็น สำหรับคำแนะนำเชิงลึก ดูที่ Secure least-privileged access
- ใช้การควบคุมการเข้าถึงแบบกำหนดตามบทบาท (RBAC): กำหนดบทบาทให้กับเซิร์ฟเวอร์ MCP ที่จำกัดอย่างเข้มงวดกับทรัพยากรและการกระทำเฉพาะ หลีกเลี่ยงการให้สิทธิ์กว้างหรือไม่จำเป็น
- ติดตามและตรวจสอบสิทธิ์: ติดตามการใช้สิทธิ์อย่างต่อเนื่องและตรวจสอบบันทึกการเข้าถึงเพื่อค้นหาและแก้ไขสิทธิ์ที่เกินความจำเป็นหรือไม่ได้ใช้งานอย่างรวดเร็ว
เซิร์ฟเวอร์ MCP ที่ถูกโจมตีหรือถูกแทรกแซงสามารถสร้างความเสี่ยงอย่างมากโดยการเปิดเผยข้อมูลลูกค้าหรืออนุญาตให้เกิดการกระทำที่ไม่ตั้งใจ ความเสี่ยงเหล่านี้มีความเกี่ยวข้องโดยเฉพาะในงาน AI และงานที่ใช้ MCP ซึ่งได้แก่:
- การโจมตีแบบ Prompt Injection: ผู้โจมตีฝังคำสั่งที่เป็นอันตรายไว้ใน prompt หรือเนื้อหาภายนอก ทำให้ระบบ AI ทำงานที่ไม่ตั้งใจหรือรั่วไหลข้อมูลที่ละเอียดอ่อน เรียนรู้เพิ่มเติมที่: Prompt Injection
- การปลอมแปลงเครื่องมือ (Tool Poisoning): ผู้โจมตีแก้ไขข้อมูลเมตาของเครื่องมือ (เช่น คำอธิบายหรือพารามิเตอร์) เพื่อเปลี่ยนพฤติกรรม AI อาจหลีกเลี่ยงการควบคุมความปลอดภัยหรือขโมยข้อมูล รายละเอียด: Tool Poisoning
- การโจมตีแบบ Cross-Domain Prompt Injection: คำสั่งอันตรายถูกฝังในเอกสาร เว็บเพจ หรืออีเมล แล้วถูกประมวลผลโดย AI ทำให้เกิดการรั่วไหลหรือการเปลี่ยนแปลงข้อมูล
- การแก้ไขเครื่องมือแบบไดนามิก (Rug Pulls): นิยามเครื่องมือสามารถเปลี่ยนแปลงหลังจากได้รับการอนุมัติจากผู้ใช้ นำไปสู่พฤติกรรมอันตรายใหม่โดยที่ผู้ใช้ไม่รู้ตัว
ช่องโหว่เหล่านี้เน้นความจำเป็นในการตรวจสอบอย่างเข้มงวด การติดตาม และควบคุมความปลอดภัยเมื่อรวมเซิร์ฟเวอร์ MCP และเครื่องมือต่าง ๆ เข้ากับสภาพแวดล้อมของคุณ สำหรับรายละเอียดเพิ่มเติม ดูแหล่งข้อมูลที่ลิงก์ไว้ข้างต้น
Indirect Prompt Injection (หรือที่รู้จักกันในชื่อ cross-domain prompt injection หรือ XPIA) เป็นช่องโหว่ร้ายแรงในระบบ AI สร้างเนื้อหา รวมถึงระบบที่ใช้ Model Context Protocol (MCP) ในการโจมตีนี้ คำสั่งที่เป็นอันตรายจะถูกซ่อนไว้ในเนื้อหาภายนอก เช่น เอกสาร เว็บเพจ หรืออีเมล เมื่อระบบ AI ประมวลผลเนื้อหานี้ อาจตีความคำสั่งฝังเหล่านี้เป็นคำสั่งของผู้ใช้ที่ถูกต้อง ส่งผลให้เกิดการกระทำที่ไม่ตั้งใจ เช่น การรั่วไหลของข้อมูล การสร้างเนื้อหาที่เป็นอันตราย หรือการเปลี่ยนแปลงปฏิสัมพันธ์กับผู้ใช้ สำหรับคำอธิบายอย่างละเอียดและตัวอย่างจริง ดูที่ Prompt Injection
รูปแบบอันตรายอย่างยิ่งของการโจมตีนี้คือ Tool Poisoning ซึ่งผู้โจมตีฝังคำสั่งอันตรายลงในข้อมูลเมตาของเครื่องมือ MCP (เช่น คำอธิบายหรือพารามิเตอร์ของเครื่องมือ) เนื่องจากโมเดลภาษาขนาดใหญ่ (LLMs) พึ่งพาข้อมูลเมตานี้ในการตัดสินใจเรียกใช้เครื่องมือที่เหมาะสม คำอธิบายที่ถูกแทรกแซงสามารถหลอกโมเดลให้เรียกใช้เครื่องมือที่ไม่ได้รับอนุญาตหรือหลีก
- OWASP Top 10
- OWASP Top 10 for LLMs
- GitHub Advanced Security
- Azure DevOps
- Azure Repos
- การเดินทางสู่การรักษาความปลอดภัยของซอฟต์แวร์ซัพพลายเชนที่ Microsoft
- Secure Least-Privileged Access (Microsoft)
- แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบและอายุของโทเค็น
- ใช้การเก็บโทเค็นอย่างปลอดภัยและเข้ารหัสโทเค็น (YouTube)
- Azure API Management ในฐานะเกตเวย์การยืนยันตัวตนสำหรับ MCP
- แนวปฏิบัติด้านความปลอดภัยที่ดีที่สุดของ MCP
- การใช้ Microsoft Entra ID เพื่อยืนยันตัวตนกับเซิร์ฟเวอร์ MCP
ถัดไป: บทที่ 3: การเริ่มต้น
ข้อจำกัดความรับผิดชอบ:
เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษาอัตโนมัติ Co-op Translator แม้ว่าเราจะพยายามให้ความถูกต้องสูงสุด โปรดทราบว่าการแปลอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาต้นทางควรถือเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ แนะนำให้ใช้บริการแปลโดยผู้เชี่ยวชาญมนุษย์ เราจะไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความที่ผิดพลาดที่เกิดจากการใช้การแปลนี้