Databricks: Giải pháp bảo mật phân quyền chi tiết cho AI/BI Dashboard khi nhúng vào ứng dụng

Thử thách

Việc nhúng Databricks AI/BI Dashboard vào một ứng dụng dành cho khách hàng tương đối đơn giản: kích hoạt tính năng nhúng, tạo một token có phạm vi giới hạn (scoped token) ở backend và hiển thị dashboard bằng client SDK. Hướng dẫn cơ bản, "Cách nhúng Databricks AI/BI Dashboards vào các ứng dụng dành cho khách hàng", sẽ hướng dẫn bạn quy trình này từ đầu đến cuối.

Câu hỏi khó hơn nằm ở khâu xác thực (authorization): sau khi dashboard được nhúng, người xem sẽ thấy những dòng dữ liệu nào? Một đối tác chỉ nên thấy dữ liệu của riêng họ, trong khi một nhóm nội bộ có thể chỉ được thấy dữ liệu theo khu vực của họ. Hướng dẫn này sẽ chỉ cho bạn cách thực thi các quy tắc đó.

Mô hình tham chiếu này kết hợp một số khả năng của Databricks: __aibi_external_value, bộ lọc dòng (row filters) và mặt nạ cột (column masks) của Unity Catalog, cùng các nhóm được đồng bộ hóa từ nhà cung cấp danh tính (IdP). Đây là một mô hình thiết kế, không phải là một tính năng đơn lẻ để kích hoạt.

Một bộ quy tắc, hai lộ trình thực thi

Cùng một bảng quyền truy cập (entitlements table) sẽ quản lý hai lộ trình: các dashboard nhúng được truy cập thông qua ứng dụng và các truy vấn SQL trực tiếp do người dùng Databricks thực hiện.

Một kịch bản cụ thể

Hãy xem xét một công ty sử dụng dashboard chung "Open Accounts Receivable (AR) Tasks" cho dữ liệu trên ba khu vực: Tây, Đông và Trung tâm. Dashboard này phục vụ hai đối tượng.

Năm người xem chia sẻ một tập dữ liệu, mỗi người thấy một phần dữ liệu khác nhau: Acme Ops, Bolt Partners, Core Logistics, Finance và một nhóm vận hành khu vực. Các ví dụ dưới đây tập trung vào Acme và Finance; các định danh partner_acme, finance_all và West đại diện cho các ví dụ đó. Acme thấy khu vực West với email bị che (masked), trong khi Finance thấy cả ba khu vực đầy đủ, cả hai đều từ cùng một dashboard đã xuất bản.

Một bảng, một view, một dashboard

Các quy tắc truy cập nằm ở một nơi duy nhất thay vì bị phân tán trên các dashboard hoặc truy vấn. Việc tạo mỗi dashboard cho mỗi khách hàng sẽ tạo ra các bản sao dễ bị lệch dữ liệu, trong khi việc lặp lại các bộ lọc trong mỗi truy vấn sẽ tạo ra cơ hội cho sai sót.

Mô hình này bao gồm ba đối tượng:

Trong hầu hết các triển khai, một hệ thống quyền truy cập thượng nguồn hoặc một bảng ánh xạ nhóm-đến-khu vực do ứng dụng sở hữu sẽ điền dữ liệu vào bảng này; nó không được chỉnh sửa thủ công cho từng người xem.

Điều này giúp tránh việc phải tạo dashboard riêng cho từng khách hàng và tránh lặp lại bộ lọc trong các truy vấn. Các quy tắc nằm trong một bảng có thể được truy vấn, kiểm toán và thay đổi mà không cần sửa đổi dashboard.

Được áp dụng cho từng người xem, view bảo mật chỉ trả về những gì người xem đó được phép thấy:

Acme (external_value = partner_acme): Chỉ khu vực West, email liên hệ bị che.

Finance (external_value = finance_all): Cả ba khu vực, email liên hệ đầy đủ.

Nguồn gốc của __aibi_external_value

Backend thiết lập giá trị này khi tạo token nhúng. Nó xác thực dưới danh nghĩa một service principal và yêu cầu Databricks cấp một token có phạm vi giới hạn với hai giá trị: external_viewer_id, dùng để định danh người xem phục vụ kiểm toán, và external_value, đại diện cho phạm vi truy cập của người xem. Databricks ký vào token này và người xem không thể sửa đổi giá trị nhúng, giá trị này được hiển thị với SQL của dashboard dưới dạng __aibi_external_value. Vì chứa thông tin xác thực của service principal, backend này là một thành phần phía máy chủ đáng tin cậy (không bao giờ là trình duyệt) và các thông tin xác thực đó được lưu trong trình quản lý bí mật (secrets manager) thay vì trong hệ thống quản lý mã nguồn.

Chi tiết quan trọng là danh tính nào thực thi truy vấn. Các truy vấn nhúng được thực thi dưới danh tính xuất bản (publishing identity) đã cấu hình, không phải danh tính Databricks của người xem.

Đối với việc nhúng bên ngoài, Databricks khuyến nghị sử dụng quyền dữ liệu cá nhân và cấp cho service principal quyền truy cập dữ liệu riêng, để các truy vấn chạy dưới danh nghĩa service principal. (Việc xuất bản với quyền dữ liệu chia sẻ sẽ chạy các truy vấn dưới danh nghĩa thông tin xác thực của người xuất bản). Sau đó, view sẽ thu hẹp quyền truy cập đó cho từng người xem thông qua __aibi_external_value. Vì truy vấn chạy dưới danh nghĩa service principal, hàm is_account_group_member không thể xác định được người thực sự đang xem dashboard trên đường dẫn nhúng.

Chi tiết quan trọng là external_value không giới hạn ở ID đối tác. Nó có thể là bất kỳ phạm vi nào mà backend ký vào token, ví dụ: partner_acme cho một đối tác bên ngoài hoặc finance_all cho một nhóm nội bộ (tên nhóm của họ).

Vì bảng quyền truy cập chứa ID đối tác và tên nhóm trong cùng một cột, nên một dashboard, một view và một bộ lọc là đủ để bao quát cả hai.

Vì người xem không bao giờ thấy hoặc thiết lập giá trị đã ký, họ không thể thay đổi nó. Một phạm vi không xác định sẽ không khớp với bất kỳ dòng nào, tạo ra hành vi mặc định là từ chối (default-deny).

Cùng một view và cùng một bộ lọc (WHERE viewer_scope = __aibi_external_value) phục vụ cả hai đối tượng. Chỉ có nguồn gốc của phạm vi đó là khác nhau:

Cấp quyền cho nhóm, không phải cá nhân

Các tổ chức thường quản lý quyền truy cập thông qua các nhóm được đồng bộ hóa từ nhà cung cấp danh tính. Khi ai đó tham gia nhóm Finance trong Okta, quyền truy cập của họ sẽ tự động ánh xạ tới finance_all và không cần can thiệp vào bảng dữ liệu. Trong ví dụ này, finance_all ánh xạ tới mọi khu vực và ops_west ánh xạ tới khu vực West.

Làm thế nào để ứng dụng biết nhóm nào thuộc về người xem? Nó không thể dựa vào SQL trong quá trình nhúng, vì truy vấn chạy dưới danh nghĩa service principal và is_account_group_member sẽ kiểm tra sai danh tính. Ứng dụng phải phân giải các nhóm của người xem ở backend (nơi có thể nhìn thấy người xem) trước khi tạo token.

Một lựa chọn là chạy ứng dụng trên Databricks Apps với tính năng xác thực người dùng được kích hoạt.

Đối với người dùng nội bộ đã đăng nhập, nền tảng sẽ chuyển tiếp ngữ cảnh danh tính đáng tin cậy đến backend, bao gồm email của người xem và token on-behalf-of (OBO). Backend sử dụng token đó để gọi SCIM /Me dưới danh nghĩa người xem và đọc các nhóm của họ.

Cách tiếp cận này không yêu cầu quyền quản trị viên đối với service principal, vì người dùng đang tự đọc bản ghi của chính họ. Nó yêu cầu các phạm vi xác thực người dùng (user-authorization scopes), và tính năng Apps OBO vẫn đang trong quá trình hoàn thiện, vì vậy hãy kiểm tra nó với môi trường triển khai mục tiêu trước khi sử dụng.

Nếu không tìm thấy nhóm được cấp quyền, hãy thiết lập trạng thái từ chối (fail closed) và từ chối tạo token thay vì quay lại sử dụng danh tính rộng hơn như email thô.

Nếu một người xem thuộc nhiều nhóm được cấp quyền, hãy phân giải kết quả một cách xác định. Xác định thứ tự ưu tiên hoặc ánh xạ nhiều nhóm vào một phạm vi chuẩn trước khi tạo token, để cùng một người xem luôn nhận được quyền truy cập nhất quán.

Các đối tác bên ngoài đơn giản hơn. Vì không có danh tính Databricks, phạm vi của họ là một ID đối tác cố định được gán khi đăng nhập. Cùng một token, cùng một bộ lọc, không cần tra cứu.

Một hạn chế cần lưu ý khi thiết kế: một token đã ký chỉ mang một giá trị external_value duy nhất. Nếu một người xem thuộc nhiều nhóm với các quyền khác nhau, một token vẫn chỉ có thể đại diện cho một phạm vi. Đối với trường hợp phổ biến là một vai trò cho mỗi người, điều này hoàn toàn ổn.

Đối với trường hợp hợp nhất nhiều nhóm thực sự, hãy sử dụng một nhóm có toàn quyền hoặc lộ trình SQL trực tiếp bên dưới, nơi bộ lọc dòng có thể thực hiện lệnh OR trên mọi nhóm. Một phạm vi tổng hợp (như JSON) có thể được đóng gói vào external_value, nhưng khi đó việc phân tích cú pháp và so khớp sẽ chuyển vào SQL của tập dữ liệu và vẫn bị giới hạn bởi mức tải 1 KB.

Tăng cường các đảm bảo

Lọc dòng mang lại hành vi cơ bản: mỗi người xem chỉ thấy các dòng của riêng họ. Ba lớp bổ sung giúp củng cố các kiểm soát này và cả ba đều đọc từ cùng một bảng quyền truy cập.