# Databricks Apps เปิดใช้ OBO ทั่วไป แอปดึงข้อมูลได้เท่าที่ผู้ใช้แต่ละคนมีสิทธิ์

> Databricks เปิดให้ Databricks Apps ใช้การอนุญาตแบบ on-behalf-of-user ทั่วไปเมื่อ 7 ต.ค. 2026 แอปดึงข้อมูลด้วยสิทธิ์ของผู้ใช้ที่ล็อกอินตามกฎใน Unity Catalog

- ประเภท: ข่าว · หมวด: Data & Analytics
- เผยแพร่: 2026-10-08T14:52:00.000Z · อัปเดต: 2026-10-08T14:52:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/data/databricks-apps-on-behalf-of-user-authorization-ga/

## สรุปประเด็นสำคัญ

- 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 ที่งานนั้นต้องใช้ |

![หน้า Authorization ของ Databricks Apps แยกส่วน App authorization ที่ใช้ service principal กับ User authorization ที่แสดง scope เช่น sql:restricted-query](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-apps-on-behalf-of-user-authorization-ga/databricks-apps-authorization-tab.webp?v=feb51e9d) _(ภาพ: Databricks)_

## 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 เมื่อผู้ใช้เปิดแอปที่ใช้ OBO ครั้งแรก แสดงรายการสิทธิ์ เช่น Restrictive query using Databricks SQL](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-apps-on-behalf-of-user-authorization-ga/databricks-apps-obo-consent.webp?v=231f015b) _(ภาพ: Databricks)_

## ผู้ดูแลกำหนดขอบเขตสูงสุดของ Databricks Apps ได้

ผู้ดูแล workspace กำหนดรายการ scope ที่นักพัฒนาขอได้ที่ Settings > Development > Apps ค่าเริ่มต้นคือ All APIs เลือกเฉพาะบาง scope ได้ หรือตั้งเป็น None เพื่อปิดการอนุญาตแบบผู้ใช้ทั้งหมด ผู้ดูแลระดับบัญชีเพิ่ม scope นอกรายการได้ ถ้าภายหลังเอา scope ออกจากรายการ แอปที่รันอยู่ยังทำงานต่อ แต่จะ start, deploy หรืออัปเดตไม่ได้จนกว่าจะเอา scope นั้นออก

![หน้า Settings ของ Databricks ส่วน Apps ที่มีตัวเลือก Restrict OAuth scopes for apps to selected values ให้ผู้ดูแลเลือก scope ที่อนุญาต](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-apps-on-behalf-of-user-authorization-ga/databricks-apps-scope-allowlist.webp?v=c987c6af) _(ภาพ: Databricks)_

ข้อจำกัดที่ควรรู้คือโทเคนของผู้ใช้ใช้ได้เฉพาะ workspace ที่แอปรันอยู่ ถ้าต้อง query SQL warehouse ใน workspace อื่น Databricks แนะนำให้ deploy แอปใน workspace นั้น หรือใช้ service principal ซึ่งจะเสียการแยกสิทธิ์รายบุคคล

## ทำไมเรื่องนี้สำคัญ

แอปภายในองค์กรจำนวนมากต่อฐานข้อมูลด้วยบัญชีบริการที่มีสิทธิ์กว้าง แล้วเขียนเงื่อนไขกรองข้อมูลเองในโค้ด กฎจึงกระจายอยู่หลายที่และอาจไม่ตรงกับนโยบายกลาง ความเสี่ยงสูงขึ้นเมื่อแอปเหล่านี้กลายเป็นผู้ช่วย AI ที่ตอบคำถามจากข้อมูลลูกค้า OBO ให้ Unity Catalog เป็นจุดเดียวที่ตัดสินสิทธิ์ ต่อเนื่องจาก [Cross-engine ABAC](/data/databricks-cross-engine-abac-ga-unity-catalog/) ที่ 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 และแพลตฟอร์มข้อมูลอื่นได้ที่[หมวดข้อมูล](/data/)

## คำถามที่พบบ่อย

### การอนุญาตแบบ 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](https://www.databricks.com/blog/now-ga-building-permission-aware-databricks-apps-behalf-user-authorization) — Databricks
- [Configure authorization in a Databricks app](https://docs.databricks.com/aws/en/dev-tools/databricks-apps/auth) — Databricks Documentation