เซิร์ฟเวอร์ MCP ของคุณปลอดภัย แต่ระบบบัญชีแยกประเภทที่อยู่เบื้องหลังไม่ปลอดภัย

ในบทความที่เผยแพร่เมื่อไม่นานมานี้บน Unite.AI Gil Feig ได้เสนอ แนวปฏิบัติที่ดีที่สุด 6 ข้อสำหรับสร้างเซิร์ฟเวอร์ MCP ที่ปลอดภัย แนวปฏิบัติเหล่านี้เป็นคำแนะนำที่ดี และทุกคนที่นำเซิร์ฟเวอร์ MCP ออกใช้งานก็ควรปฏิบัติตาม คำแนะนำของเขาที่ให้แต่ละการเชื่อมต่อมี “บทบาทที่กำหนดสิทธิ์อย่างละเอียด โดยจำกัดสิทธิ์ไว้เฉพาะเท่าที่จำเป็น” นั้นถูกต้องอย่างยิ่ง แต่คำแนะนำนี้ก็มีสมมติฐานด้วยว่าระบบอีกฝั่งหนึ่งมีบทบาทที่กำหนดสิทธิ์ได้อย่างละเอียดเช่นกัน เรื่องนี้ชี้ให้เห็นถึงสมมติฐานที่กว้างกว่านั้น ซึ่งแทบไม่มีใครพูดถึง นั่นคือระบบที่อยู่เบื้องหลังเซิร์ฟเวอร์สามารถรักษาความปลอดภัยได้ในมาตรฐานเดียวกัน

แต่ในซอฟต์แวร์ธุรกิจ ระบบเหล่านั้นมักทำเช่นนั้นไม่ได้ ผมดูแลทีมวิศวกรรมที่พัฒนาชั้นการเชื่อมต่อซึ่งเชื่อมต่อกับระบบบัญชีและ ERP 32 ระบบ โดยมีเซิร์ฟเวอร์ MCP เป็นส่วนเสริมที่เลือกใช้ได้ เราพบอยู่เสมอว่าเอเจนต์ได้รับการยืนยันตัวตน กำหนดขอบเขตสิทธิ์ และบันทึกการทำงานไว้อย่างรัดกุมในฝั่งของเรา แต่กลับเขียนข้อมูลลงในระบบที่ไม่มีทางรู้เลยว่ามีเอเจนต์เข้ามาเกี่ยวข้อง

บทความนี้กล่าวถึงปัญหาอีกครึ่งหนึ่ง นั่นคือระบบต้นทางมีความสามารถอะไรบ้าง คุณควบคุมอะไรได้จากชั้นการเชื่อมต่อ และการควบคุมนั้นสิ้นสุดลงตรงไหน

จุดที่ข้อกำหนด MCP ส่งต่อการควบคุม

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

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

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

ระบบต้นทางมีความสามารถอะไรบ้าง

ต่อไปนี้คือภาพของระบบบัญชีและ ERP ทั้ง 32 ระบบที่เราเชื่อมต่อด้วย จากมุมมองของผู้พัฒนาระบบเชื่อมต่อ

หนึ่งในสามไม่มี OAuth เลย

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

อายุการใช้งานยาวนาน แต่เพิกถอนได้ยาก

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

และเมื่อข้อมูลประจำตัวถูกนำไปใช้แล้ว คำถามคือใครจะปิดการใช้งานได้ มาตรฐานสำหรับเรื่องนี้คือ การเพิกถอนโทเค็น OAuth (RFC 7009) ซึ่งมีมาตั้งแต่ปี 2013 แต่ระบบประมาณ 4 ใน 10 ระบบไม่มีวิธีทางเทคนิคให้ผู้พัฒนาระบบเชื่อมต่อเพิกถอนข้อมูลประจำตัวได้ ระบบที่ใช้คีย์ API ทุกระบบอยู่ในกลุ่มนี้ ทางเลือกเดียวที่เหลืออยู่คือขอให้ลูกค้าลบสิทธิ์การเข้าถึงด้วยตนเอง

ขอบเขตสิทธิ์หยาบเกินไป ไม่มีข้อมูลระบุตัวตนของเอเจนต์

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

สิ่งที่ชั้นการเชื่อมต่อบังคับใช้ได้

เรื่องทั้งหมดนี้ไม่ได้หมายความว่าเราต้องยอมแพ้ ระหว่างเอเจนต์กับระบบบัญชี คุณควบคุมได้แทบทุกอย่าง ดังนี้

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

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

จุดที่การควบคุมสิ้นสุดลง

สิ่งที่คุณทำไม่ได้คือขยายชั้นนี้ให้เลยขอบเขตของระบบออกไป เพราะจะเกิดปัญหาขึ้นสามประการ

การระบุผู้กระทำ

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

องค์กรส่วนใหญ่ก็ยังตามไม่ทันเรื่องนี้เช่นกัน จากการสำรวจของ Cloud Security Alliance มีผู้ตอบแบบสำรวจเพียง 28% ที่ระบุว่าสามารถติดตามการดำเนินการของเอเจนต์ย้อนกลับไปยังบุคคลหรือระบบได้อย่างน่าเชื่อถือในทุกสภาพแวดล้อม และ 44% ใช้หรือวางแผนจะใช้คีย์ API แบบคงที่สำหรับเอเจนต์

สิทธิ์เท่าที่จำเป็น

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

การเพิกถอนสิทธิ์

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

ทางออกที่นำไปใช้ได้จริง: สร้างผู้ใช้เฉพาะสำหรับเอเจนต์

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

วิธีนี้ใช้ได้กับทุกระบบที่อนุญาตให้สร้างผู้ใช้ และให้ประโยชน์สามประการที่ชั้นการผสานระบบทำให้ไม่ได้:

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

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

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

ทางออกเชิงโครงสร้าง: อัตลักษณ์ที่มอบหมายสิทธิ์

ในทางทฤษฎีมีทางออกที่ถูกต้องอยู่แล้ว นั่นคือ การแลกเปลี่ยนโทเค็น OAuth 2.0 (RFC 8693) ซึ่งแยกการสวมรอยเป็นบุคคลอื่นออกจากการรับมอบสิทธิ์ ในกรณีที่มีการมอบหมายสิทธิ์ เอเจนต์จะยังคงใช้อัตลักษณ์ของตนเอง และโทเค็นจะบันทึกว่าเอเจนต์กำลังดำเนินการแทนบุคคลหนึ่ง โดยใช้คำกล่าวอ้าง “act”

หากนำมาใช้กับงานบัญชี ก็จะหมายความว่า:

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

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

สิ่งที่ควรทำก่อนให้เอเจนต์เข้าถึงบัญชีแยกประเภท

หากคุณกำลังเชื่อมต่อเอเจนต์เข้ากับระบบบัญชีหรือ ERP ลองใช้รายการตรวจสอบสั้น ๆ นี้:

1. ตรวจสอบรูปแบบข้อมูลรับรองของแต่ละระบบปลายทาง ใช้ OAuth หรือคีย์แบบคงที่ ข้อมูลรับรองมีอายุการใช้งานนานเท่าใด มีการกำหนดขอบเขตสิทธิ์หรือไม่ และคุณเพิกถอนสิทธิ์ได้หรือไม่
2. สร้างชั้นควบคุมการเข้าถึงของคุณเองอยู่ดี ไม่ว่าระบบปลายทางจะรองรับอะไรบ้าง คุณก็ควรจัดการอัตลักษณ์แยกตามเอเจนต์ ขอบเขตสิทธิ์ การป้องกันการดำเนินการซ้ำ และการอนุมัติไว้ในฝั่งของคุณ
3. ใช้ผู้ใช้เฉพาะสำหรับเอเจนต์ทุกครั้งที่ระบบอนุญาต ยอมรับภาระงานในขั้นตอนเริ่มใช้งานและค่าลิขสิทธิ์ในฐานะต้นทุนของการระบุผู้กระทำ
4. จัดเก็บบันทึกการตรวจสอบของคุณเองโดยให้ตรวจพบการแก้ไขได้ สำหรับหลายระบบ นี่จะเป็นหลักฐานเพียงอย่างเดียวว่าเอเจนต์มีส่วนเกี่ยวข้อง
5. บันทึกความเสี่ยงที่ยังคงเหลือไว้ หากระบบไม่มีขอบเขตสิทธิ์และไม่สามารถเพิกถอนสิทธิ์ได้ ให้แจ้งเรื่องนี้แก่ลูกค้าและบันทึกไว้ในทะเบียนความเสี่ยงของคุณเองด้วย

ขอบเขตคือประเด็นสำคัญ

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

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