🔐 Natural language query ไม่ควรได้สิทธิ์มากกว่าคนที่ถาม

🔐 Natural language query ไม่ควรได้สิทธิ์มากกว่าคนที่ถาม

เวลาทีมเอา AI มาคุยกับ database จุดเสี่ยงไม่ใช่แค่ prompt แปล SQL ผิด แต่คือคำถามธรรมดาอาจดึง row ที่ผู้ใช้ไม่ควรเห็น ถ้า access control อยู่แค่ชั้นแอป

Google Cloud เพิ่มการรองรับ parameterized secure views ใน QueryData สำหรับแอปที่ใช้ natural language queries

ไอเดียคือแทนที่จะให้ QueryData แตะ base table ตรง ๆ เราสร้าง view ที่รับ parameter เช่น user หรือ customer identity แล้วให้ database กรองผลลัพธ์ตั้งแต่ชั้นข้อมูล

สิ่งที่ควรวางเป็น workflow:

• ใช้ service account หรือ database role ที่สิทธิ์ต่ำเท่าที่จำเป็น
• revoke สิทธิ์ตรงบน base table แล้ว grant เฉพาะ secure view
• ส่ง identity parameter เข้า view ทุกครั้งที่ query
• verify ว่าถ้าถาม base table ตรง ๆ ต้องโดนปฏิเสธ
• แยก log ของ query path ออกจากการวัดคุณภาพ prompt

ความหมายเชิงปฏิบัติ: ถ้าจะทำ chatbot หรือ agent ที่ตอบคำถามจากข้อมูลลูกค้า หลาย tenant หรือข้อมูล operation ภายใน ให้ถือว่า row-level boundary เป็นส่วนหนึ่งของ product design ไม่ใช่ของแต่งหลังบ้าน

ข้อจำกัดคือฟีเจอร์นี้ยังเป็น Preview และตัวอย่างของ Google อยู่บน Cloud SQL for MySQL พร้อมเงื่อนไขเวอร์ชัน/flag จึงควรทดสอบกับ schema, permission และ audit log จริงก่อนใช้ production

ลิงก์ต้นทางอยู่ในคอมเมนต์แรกครับ

ถ้าทีมคุณให้ AI ถาม database ได้แล้ว ตอนนี้ access boundary อยู่ตรงไหน: app layer, database layer หรือ prompt layer?

SynapTech AI ช่วยออกแบบ AI workflow และ data access guardrail ให้ใช้จริงได้ โดยยังตรวจสอบเส้นทางข้อมูลและสิทธิ์ได้ครบ

#AIEngineering #DataSecurity #GoogleCloud #Automation #SynapTechAI

---

📖 อ่านบทความเต็มบน Facebook | 🔔 ติดตาม SynapTech