Databricks Apps เปิดใช้ OBO ทั่วไป แอปดึงข้อมูลได้เท่าที่ผู้ใช้แต่ละคนมีสิทธิ์
Databricks เปิดให้ Databricks Apps ใช้การอนุญาตแบบ on-behalf-of-user ทั่วไปเมื่อ 7 ต.ค. 2026 แอปดึงข้อมูลด้วยสิทธิ์ของผู้ใช้ที่ล็อกอินตามกฎใน Unity Catalog
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที
สรุปประเด็นสำคัญ
- Databricks ประกาศในบล็อกวันที่ 7 ตุลาคม 2026 ว่าการอนุญาตแบบ on-behalf-of-user (OBO) ใน Databricks Apps พร้อมใช้งานทั่วไป (GA)
- แอปที่ใช้ OBO ทำงานด้วยตัวตนของผู้ใช้ที่ล็อกอิน Unity Catalog จึงบังคับใช้สิทธิ์เดิมของผู้ใช้ รวมถึง row filter และ column mask โดยไม่ต้องเขียนกฎซ้ำในโค้ดแอป
- เอกสารระบุ API scope ที่รองรับ 10 รายการ เช่น sql, genie, files และ sql:restricted-query ซึ่งรันได้เฉพาะคำสั่ง SQL แบบอ่านอย่างเดียว
- ถ้านักพัฒนาไม่เลือก scope แอปจะได้ค่าเริ่มต้น 2 รายการ ซึ่งอ่านได้แค่ข้อมูลตัวตนของผู้ใช้ ส่วนผู้ดูแล workspace จำกัด scope ที่ขอได้ หรือปิด OBO ทั้งหมดได้
- โทเคนของผู้ใช้ส่งผ่าน header x-forwarded-access-token ทีละคำขอ Databricks ย้ำว่าห้ามเก็บหรือบันทึกโทเคนลง log
Databricks ประกาศเมื่อวันที่ 7 ตุลาคม 2026 ให้การอนุญาตแบบ on-behalf-of-user (OBO) ใน Databricks Apps พร้อมใช้งานทั่วไป แอปข้อมูลและ AI ที่สร้างบนแพลตฟอร์มจึงดึงข้อมูลด้วยสิทธิ์ของผู้ใช้ที่ล็อกอินอยู่ และ Unity Catalog บังคับใช้การกรองแถวกับการปิดบังคอลัมน์ของผู้ใช้คนนั้นโดยอัตโนมัติ
Databricks Apps คือบริการสำหรับสร้างและ deploy แอปบนแพลตฟอร์ม Databricks โดยตรง ตั้งแต่แดชบอร์ดแบบโต้ตอบ เครื่องมือปฏิบัติงาน ไปจนถึงเอเจนต์ AI ที่องค์กรเขียนเอง ความสามารถใหม่ทำให้นักพัฒนาไม่ต้องเขียนกฎการเข้าถึงข้อมูลซ้ำในโค้ดของแอป
Databricks Apps มีตัวตนให้เลือกสองแบบ
เอกสารของ Databricks อธิบายว่าแอปแต่ละตัวมีตัวตนได้สองแบบ แบบแรกคือ app authorization ซึ่งใช้ service principal เฉพาะของแอป Databricks สร้างให้อัตโนมัติตอนสร้างแอปและลบทิ้งเมื่อลบแอป แบบนี้เหมาะกับงานเบื้องหลัง การอ่านค่าตั้งต้นที่ใช้ร่วมกัน หรือการบันทึกสถิติการใช้งาน แต่ผู้ใช้ทุกคนจะได้สิทธิ์ชุดเดียวกัน
แบบที่สองคือ user authorization หรือ OBO แอปใช้โทเคนของผู้ใช้ที่ Databricks ส่งมาใน header ชื่อ x-forwarded-access-token แล้วส่งต่อให้ตัวเชื่อม SQL ผลคือ query ทำงานด้วยสิทธิ์ของผู้ใช้ ถ้าตารางมี row filter ตามภูมิภาค แอปจะคืนเฉพาะแถวที่ผู้ใช้คนนั้นมีสิทธิ์เห็น และเมื่อผู้ดูแลแก้นโยบายใน Unity Catalog คำขอถัดไปของแอปก็ใช้กฎใหม่ทันที
| การทำงาน | ตัวตนที่ควรใช้ |
|---|---|
| query ข้อมูลที่ต้องกรองตามผู้ใช้ | OBO ด้วย scope sql:restricted-query |
| อ่านค่าตั้งต้นหรือ metadata ที่ใช้ร่วมกัน | service principal ของแอป |
| งานเบื้องหลังและงานบำรุงรักษา | service principal ของแอป |
| ผู้ใช้สั่งแก้ข้อมูลที่อยู่ภายใต้การกำกับ | OBO ด้วย scope ที่งานนั้นต้องใช้ |
API scope ของ Databricks Apps คือเพดานของสิ่งที่แอปทำแทนผู้ใช้ได้
แอปที่ใช้ OBO ต้องประกาศ API scope ว่าจะทำอะไรแทนผู้ใช้บ้าง เอกสารระบุ scope ที่รองรับ 10 รายการ ได้แก่ ai-functions, ai-gateway, apps, files, genie, model-serving, postgres, sql, vector-search และ sql:restricted-query ถ้าไม่เลือกเลย แอปจะได้ scope ค่าเริ่มต้น 2 รายการที่อ่านได้แค่ข้อมูลตัวตนและสิทธิ์ของผู้ใช้ ไม่ถึงข้อมูลหรือ compute
Databricks แนะนำให้แอปวิเคราะห์ข้อมูลแบบอ่านอย่างเดียวขอ sql:restricted-query แทน sql ซึ่งกว้างกว่า เพราะ scope นี้รันได้เฉพาะ SQL แบบอ่านอย่างเดียว บล็อกย้ำว่า scope เป็นเพดานความสามารถ ไม่ได้ให้สิทธิ์เข้าถึงข้อมูลเพิ่ม ผู้ใช้ยังต้องมีสิทธิ์ใช้ SQL warehouse และสิทธิ์ในตารางเอง ครั้งแรกที่ผู้ใช้เปิดแอป Databricks จะขอให้กดยินยอม scope ที่แอปขอ ยินยอมครั้งเดียวต่อแอปและชุด scope และเพิกถอนภายหลังได้
ผู้ดูแลกำหนดขอบเขตสูงสุดของ Databricks Apps ได้
ผู้ดูแล workspace กำหนดรายการ scope ที่นักพัฒนาขอได้ที่ Settings > Development > Apps ค่าเริ่มต้นคือ All APIs เลือกเฉพาะบาง scope ได้ หรือตั้งเป็น None เพื่อปิดการอนุญาตแบบผู้ใช้ทั้งหมด ผู้ดูแลระดับบัญชีเพิ่ม scope นอกรายการได้ ถ้าภายหลังเอา scope ออกจากรายการ แอปที่รันอยู่ยังทำงานต่อ แต่จะ start, deploy หรืออัปเดตไม่ได้จนกว่าจะเอา scope นั้นออก
ข้อจำกัดที่ควรรู้คือโทเคนของผู้ใช้ใช้ได้เฉพาะ workspace ที่แอปรันอยู่ ถ้าต้อง query SQL warehouse ใน workspace อื่น Databricks แนะนำให้ deploy แอปใน workspace นั้น หรือใช้ service principal ซึ่งจะเสียการแยกสิทธิ์รายบุคคล
ทำไมเรื่องนี้สำคัญ
แอปภายในองค์กรจำนวนมากต่อฐานข้อมูลด้วยบัญชีบริการที่มีสิทธิ์กว้าง แล้วเขียนเงื่อนไขกรองข้อมูลเองในโค้ด กฎจึงกระจายอยู่หลายที่และอาจไม่ตรงกับนโยบายกลาง ความเสี่ยงสูงขึ้นเมื่อแอปเหล่านี้กลายเป็นผู้ช่วย AI ที่ตอบคำถามจากข้อมูลลูกค้า OBO ให้ Unity Catalog เป็นจุดเดียวที่ตัดสินสิทธิ์ ต่อเนื่องจาก Cross-engine ABAC ที่ Databricks เพิ่งเปิดให้นโยบายเดียวกันมีผลกับเอนจินภายนอก
Databricks ระบุว่าเอเจนต์ AI ที่ deploy บน Databricks Apps ใช้รูปแบบเดียวกันได้ โดยต้องสร้าง client ที่ใช้สิทธิ์ผู้ใช้ภายในตัวจัดการคำขอแต่ละครั้ง ไม่ใช่ตอนเริ่มแอป
สิ่งที่องค์กรไทยควรทำ
- สำรวจแอปเดิม หาแอปบน Databricks Apps ที่ใช้ service principal อ่านข้อมูลส่วนบุคคลหรือข้อมูลที่ต้องแยกตามแผนก แล้วย้ายเส้นทางที่ต้องกรองตามผู้ใช้ไปใช้ OBO ให้การจำกัดการเข้าถึงข้อมูลส่วนบุคคลไปอยู่ที่นโยบายกลางจุดเดียว ตรวจสอบได้ง่ายกว่ากฎที่กระจายอยู่ในโค้ด
- ตั้งรายการ scope ก่อนทีมสร้างแอปเพิ่ม เช่น อนุญาตเฉพาะ sql:restricted-query สำหรับแอปวิเคราะห์ข้อมูล และเปิด scope อื่นเป็นรายกรณี
- แยก client ในโค้ดให้ชัด ใช้ service principal กับงานของแอป ใช้โทเคนผู้ใช้กับงานที่ต้องกรองตามผู้ใช้ และถ้าไม่มีโทเคนให้ปฏิเสธคำขอแทนการสลับไปใช้สิทธิ์ของแอป
- ห้ามเก็บโทเคน ไม่พิมพ์ ไม่บันทึกลง log และไม่เก็บข้ามคำขอ พร้อมให้มี peer review ทุกครั้งที่แก้โค้ดด้านสิทธิ์
- ทดสอบด้วยผู้ใช้หลายระดับสิทธิ์ แล้วทดสอบซ้ำทุกครั้งที่แก้นโยบายใน Unity Catalog
ติดตามข่าวด้าน Data Governance และแพลตฟอร์มข้อมูลอื่นได้ที่หมวดข้อมูล
คำถามที่พบบ่อย
การอนุญาตแบบ on-behalf-of-user ใน Databricks Apps คืออะไร?
เป็นรูปแบบที่ Databricks Apps ทำงานด้วยตัวตนของผู้ใช้ที่ล็อกอินอยู่ Databricks ส่งโทเคนของผู้ใช้ให้แอปในแต่ละคำขอ แล้วประเมินสิทธิ์ตามนโยบาย Unity Catalog ของผู้ใช้คนนั้น Databricks ประกาศให้พร้อมใช้งานทั่วไปเมื่อ 7 ตุลาคม 2026
OBO ต่างจากการให้แอปใช้ service principal อย่างไร?
เมื่อ Databricks Apps ใช้ service principal ของแอปเอง ผู้ใช้ทุกคนจะได้สิทธิ์ชุดเดียวกัน แอปจึงแยกข้อมูลตามตัวบุคคลไม่ได้ ส่วน OBO ใช้สิทธิ์ของผู้ใช้แต่ละคน เช่น ผู้จัดการภาคเห็นเฉพาะลูกค้าในภาคของตน ขณะที่ผู้บริหารระดับประเทศเห็นทุกภาค
API scope ใน Databricks Apps มีไว้ทำอะไร?
scope กำหนดเพดานว่าแอปบน Databricks Apps ทำอะไรแทนผู้ใช้ได้บ้าง เช่น sql:restricted-query ให้รันได้เฉพาะ SQL แบบอ่านอย่างเดียว scope ไม่ได้ให้สิทธิ์เข้าถึงข้อมูลเพิ่ม ผู้ใช้ยังต้องมีสิทธิ์ใน SQL warehouse และตารางใน Unity Catalog เอง และต้องกดยินยอมก่อนใช้แอปครั้งแรก
ผู้ดูแลระบบควบคุม OBO ใน Databricks Apps ได้อย่างไร?
ผู้ดูแล workspace กำหนดรายการ scope ที่นักพัฒนาขอได้ที่ Settings > Development > Apps ค่าเริ่มต้นคือ All APIs เลือกเฉพาะบาง scope ได้ หรือตั้งเป็น None เพื่อปิดการอนุญาตแบบผู้ใช้ แอปที่ขอ scope นอกรายการจะ deploy หรืออัปเดตไม่ได้จนกว่าจะเอาออก
แหล่งอ้างอิง
- Now GA: Building permission-aware Databricks Apps with on-behalf-of-user authorization — Databricks
- Configure authorization in a Databricks app — Databricks Documentation
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ