Non-Human Database Access · Agent

MCP Endpoint คือ Database Client และต้องกำกับดูแลแบบเดียวกัน

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

Infozense Knowledge Engineering · CIO · CISO · Head of Data · ~6 นาที

นี่คือบท Agent ของชุดบทความ Non-Human Database Access โดย Infozense ใจความสำคัญในบรรทัดเดียว: MCP Endpoint ผูกอยู่กับ Connection ของฐานข้อมูล การควบคุมทุกอย่างที่คุณต้องการจึงต้องเป็นคุณสมบัติของ Connection นั้น ซึ่งทำให้ Connection กลายเป็นจุดบังคับใช้นโยบาย ไม่ใช่แค่ Bookmark อีกต่อไป อ่านภาพรวมทั้งหมดได้ในบทหลัก

สิบนาที

คนในทีมข้อมูลของคุณอยากให้ผู้ช่วย AI เข้ามาช่วยงานรายงาน เขาเปิด Connection ฐานข้อมูลขึ้นมา ติ๊กช่อง Enable MCP กด Save แล้วคัดลอก Configuration ที่ระบบสร้างให้ไปวางในเครื่องมือของเขา รวมเวลาทั้งหมดราวสิบนาที ไม่มีคำขอเปลี่ยนแปลง ไม่มีการทบทวนสถาปัตยกรรม ไม่มีอะไรที่จะไปปรากฏในวาระการประชุม CAB

สิ่งที่เพิ่งเกิดขึ้นไม่ใช่ “การเชื่อม AI เข้ากับระบบ” แต่คือ Production เพิ่งได้ Client ตัวใหม่

สมมติฐานที่อยู่ใต้การควบคุมทั้งหมดตลอดยี่สิบปี

การควบคุมการเข้าถึงฐานข้อมูลทุกอย่างที่องค์กรของคุณใช้อยู่ ตั้งอยู่บนสมมติฐานเดียวกันว่าปลายทางอีกด้านคือมนุษย์

Single Sign-On ตั้งอยู่บนสมมติฐานว่ามีคนมายืนยันตัวตน การขอสิทธิ์ผ่านระบบ Ticket ตั้งอยู่บนสมมติฐานว่ามีคนยื่นคำขอและมีอีกคนอนุมัติ การทบทวน Session ตั้งอยู่บนสมมติฐานว่าทุก Session มีชื่อเจ้าของ หลักการ Four-Eyes บน Production ตั้งอยู่บนสมมติฐานว่ามีสายตาสองคู่ และการ Recertify สิทธิ์ตามรอบ ตั้งอยู่บนสมมติฐานว่ามีหัวหน้างานที่ตอบได้ว่าคนคนนี้ยังต้องใช้สิทธิ์นี้อยู่หรือไม่

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

นี่ไม่ใช่ปัญหาใหม่ — Cron Job และ ETL Pipeline ของคุณได้รับการยกเว้นจากการควบคุมเหล่านี้มาอย่างเงียบ ๆ หลายปีแล้ว สิ่งที่ใหม่คือการยกเว้นนั้นกำลังครอบคลุมถึงสิ่งที่แต่ง Query ขึ้นมาเองได้

อ่านรายการเครื่องมือที่มันเปิดให้

ถ้าตัดกรอบการเล่าเรื่องออกไป แล้วดูว่า Endpoint นี้เปิดอะไรให้กับสิ่งที่มาเชื่อมต่อ เอกสารของผู้พัฒนาระบุความสามารถไว้ว่า ดูข้อมูล Datasource, แสดงรายการ Catalog, แสดงรายการ Schema, แสดงรายการ Table, ดูรายละเอียด Table ทั้งหมดรวมถึง DDL — คอลัมน์ Constraint Index และ Comment — และสั่งรัน SQL โดยคืนผลลัพธ์เป็น CSV

การสำรวจ Schema และการรัน Query ได้อย่างอิสระ นั่นไม่ใช่การเชื่อมต่อ แต่คือ Database Client ที่ไม่มีมนุษย์อยู่ด้วย

ข้อนี้ไม่ได้เขียนขึ้นเพื่อตำหนิการออกแบบ การสร้าง Database Client คือสิ่งที่ถูกต้องแล้ว ความผิดพลาดอยู่ฝั่งเรา — เราจัดประเภทมันเป็นฟีเจอร์ AI แล้วส่งเข้ากระบวนการกำกับดูแล AI ทั้งที่ควรจัดประเภทเป็น Database Client บน Production และส่งเข้ากระบวนการที่กำกับดูแลสิ่งนั้น

จุดที่เปลี่ยนวิธีออกแบบทั้งหมด

รายละเอียดสำคัญอยู่ตรงนี้ และเป็นจุดที่คนอ่านผ่านได้ง่ายที่สุด Endpoint ผูกอยู่กับ Connection แต่ละ Connection มี Endpoint ของตัวเอง มี Token ของตัวเอง และต้องตั้งค่าแยกกัน

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

ตลอดยี่สิบปีที่ผ่านมา Connection ที่บันทึกไว้เป็นแค่ความสะดวก เป็น Bookmark ที่มีรหัสผ่านติดมาด้วย เป็นสิ่งที่นักพัฒนาสร้างขึ้นโดยไม่ต้องคิด คัดลอกข้ามเครื่อง และตั้งชื่อว่า “prod-copy-2” ขอบเขตความปลอดภัยอยู่ที่อื่นทั้งหมด — อยู่ในกระบวนการอนุมัติ อยู่ที่ผู้ตรวจสอบ และอยู่ที่ข้อเท็จจริงง่าย ๆ ว่ามนุษย์พิมพ์ได้เร็วในระดับหนึ่งเท่านั้น

ยุคนั้นจบแล้ว Connection กลายเป็นจุดบังคับใช้นโยบาย ในขณะที่องค์กรส่วนใหญ่ยังคงปฏิบัติกับมันเหมือน Bookmark

เพราะฉะนั้น จง Provision Connection ไม่ใช่ Provision Agent

ผลที่ตามมาในทางปฏิบัติคือการเปลี่ยนกรอบคำถาม และเป็นการเปลี่ยนที่ปลดล็อกงาน

เลิกถามว่า “Agent ตัวนี้ควรทำอะไรได้บ้าง” คำถามนั้นไม่มีคำตอบที่บังคับใช้ได้จริง เพราะคำตอบไปอยู่ใน Prompt และ Prompt ไม่ใช่การควบคุมการเข้าถึง

ให้ถามแทนว่า Grant อะไรอยู่หลัง Connection นี้ คำถามนี้มีคำตอบที่ชัดเจน ทดสอบได้ ตรวจสอบย้อนหลังได้ และถูกบังคับใช้โดย Database Engine ไม่ใช่โดยความร่วมมือของโมเดล

ซึ่งแปลว่างานที่ต้องทำคืองาน Database Engineering แบบธรรมดา

  • สร้าง Role เฉพาะสำหรับแต่ละ Workload ไม่ใช้บัญชี “แอปพลิเคชัน” ร่วมกัน
  • ระบุ Grant อย่างชัดเจน — Schema ไหน Table ไหน คอลัมน์ไหน
  • ตั้ง Read-Only ที่ระดับ Role ซึ่ง Engine เป็นผู้บังคับใช้ แทนการพึ่งการตั้งค่าที่อยู่สูงขึ้นไปในกองซ้อน
  • ตั้ง Statement Timeout และเพดานจำนวนแถว เพื่อไม่ให้ Query ที่ไม่ระวังกลายเป็น Incident
  • หนึ่ง Connection ต่อหนึ่งงาน ไม่ใช่ Connection เดียวชื่อ “AI” ที่สะสม Grant ไปเรื่อย ๆ จนเข้าถึงได้ทุกอย่าง

ขอบเขตความเสียหายของ Agent เท่ากับ Grant ที่อยู่หลัง Connection ของมันพอดี ไม่มากกว่าและไม่น้อยกว่านั้น นี่เป็นข่าวดี เพราะมันเปลี่ยนปัญหาใหม่ที่ดูน่ากลัวให้กลายเป็นปัญหาที่ DBA ของคุณแก้เป็นมานานแล้ว เพียงแต่นำไปใช้กับผู้ใช้งานประเภทที่พวกเขายังไม่เคยเจอ

คำถามที่เรายังตอบไม่ได้ และขอบอกตามตรง

เราไม่พบเอกสารที่ระบุถึงโหมด Read-Only การจำกัด Query หรือการกำหนดนโยบายระดับแถวและคอลัมน์บนตัว MCP Endpoint เอง และเรายังไม่ได้ทดสอบรุ่นที่ต้องใช้ License เพื่อยืนยันในทางใดทางหนึ่ง กรุณาตรวจสอบกับเวอร์ชันที่คุณใช้อยู่ก่อนนำไปพึ่งพา

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

จงสร้างหลักประกันไว้ที่ชั้นซึ่งลืมไม่ได้

ภาพที่กว้างกว่านั้น

Agent เป็นกรณีที่มองเห็นได้ชัด แต่ไม่ใช่ทั้งหมดของเรื่อง ช่องว่างเดียวกันนี้พาดผ่านทุก Connection ที่ไม่ใช่มนุษย์ซึ่งคุณมีอยู่ — ETL Job ที่ Credential ไม่เคยหมุนเวียนมาตั้งแต่ปี 2023, Service Account สำหรับงานรายงานที่สะสมสิทธิ์เขียนไว้โดยไม่มีใครถอนออก, และ Pipeline ที่ต่อเข้า Production ด้วย Connection ที่ยังติดป้ายว่า Development อยู่

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

แบบทดสอบที่ไม่สบายใจนัก

เลือกฐานข้อมูลที่สำคัญที่สุดสามตัวของคุณ แล้วถามว่าทุก Identity ที่ไม่ใช่มนุษย์ซึ่งเชื่อมต่ออยู่ อ่านอะไรได้บ้างในตอนนี้ และแก้ไขอะไรได้บ้างในตอนนี้

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

การทำแผนที่นั้นใช้เวลาสองสัปดาห์ เป็นงานแบบ Read-Only ทั้งหมด และไม่ต้องซื้อ License ใด ๆ

ตรวจสอบการเข้าถึงฐานข้อมูลโดยผู้ใช้ที่ไม่ใช่มนุษย์

ตอนนี้ Pipeline, Job และ Agent ของคุณทำอะไรได้บ้างบน Production?

เราทำแผนที่ทุก Identity ที่ไม่ใช่มนุษย์ซึ่งแตะฐานข้อมูลของคุณ ว่าแต่ละตัวเข้าถึงอะไรได้ แก้ไขอะไรได้ และตัวไหนถือ Credential ที่ไม่เคยหมดอายุ เป็นงาน Read-Only ใช้เวลาสองสัปดาห์ ไม่ต้องใช้ License

ขอรับการตรวจสอบ →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand

dbvr และ DBeaver เป็นเครื่องหมายการค้าของ DBeaver Corporation Infozense เป็นตัวแทนจำหน่าย DBeaver อย่างเป็นทางการ และเป็นบริษัทที่ปรึกษาอิสระ