Databricks: Cách vận hành Genie Agents trên cả dữ liệu cấu trúc và tài liệu mà vẫn đảm bảo quản trị

Việc xây dựng một agent để tự động hóa các tác vụ kinh doanh đơn giản có thể rất dễ dàng. Nhưng để tạo ra một agent thực sự hiểu doanh nghiệp của bạn và tuân thủ các quy định quản trị dữ liệu hiện có lại khó hơn nhiều.

Trong một thời gian dài, các đội ngũ phải sử dụng các hệ thống riêng biệt để phân tích dữ liệu có cấu trúc và phi cấu trúc, thường mất hàng tuần chỉ để kết nối hai loại dữ liệu này. Bằng cách cho phép phân tích trực tiếp từ các bảng và tệp phi cấu trúc, Genie Agents đơn giản hóa kiến trúc này, cho phép bạn làm nền tảng (grounding) cho một agent duy nhất với cả dữ liệu có cấu trúc và phi cấu trúc.

Khi bạn hợp nhất dữ liệu này, một câu hỏi quan trọng nảy sinh: nếu một agent có quyền truy cập vào mọi thứ, điều gì ngăn cản nó tiết lộ thông tin sai lệch cho sai người?

Tin tốt là với Databricks, câu trả lời đã nằm sẵn trong nền tảng quản trị dữ liệu mà bạn đang có. Các cơ chế Unity Catalog mà bạn tin dùng hiện nay (đồng bộ danh tính, quyền đối tượng, ABAC, bộ lọc hàng và mặt nạ cột) tự động quản lý Genie Agents mà không cần thêm bất kỳ thiết lập nào. Sự kế thừa liền mạch này dựa trên một chiến lược quản trị được kiến trúc tốt, điều mà chúng ta sẽ khám phá chi tiết.

Để hiện thực hóa các khái niệm này, chúng ta sẽ đi qua các kịch bản sử dụng ví dụ từ Brickstore, một nhà bán lẻ gạch toàn cầu giả định, làm điểm tham chiếu.

Hợp đồng quản trị: Genie Agents chạy với thông tin xác thực của người dùng cuối

Nguyên tắc kiến trúc cốt lõi rất đơn giản: Genie Agents chạy với thông tin xác thực của người dùng cuối. Unity Catalog thực thi quản trị theo mặc định, đảm bảo rằng quyền truy cập vào các bảng và volume được gắn trực tiếp với danh tính và quyền hạn hiện có của người dùng cuối.

Điều này rất quan trọng, vì nhiều hệ thống tự phát triển cấp quyền truy cập rộng rãi cho các agent và dựa vào prompt engineering để lọc kết quả ở tầng mô hình. Điều này thực sự biến LLM thành vành đai bảo mật của bạn—một canh bạc nguy hiểm, vì các mô hình có thể bị thao túng hoặc vượt qua. Việc nói với kiểm toán viên rằng "Tôi đã thêm các hướng dẫn yêu cầu không hiển thị dữ liệu hạn chế" không phải là một biện pháp kiểm soát quản trị có thể bảo vệ được.

Với khung quản trị được nêu trong bài viết này, Unity Catalog, chứ không phải mô hình, vẫn là vành đai bảo mật của bạn, giống như cách nó hoạt động trên phần còn lại của Databricks. Mặc dù Genie xác định cách truy vấn dữ liệu, nó không thể trả về một bản ghi mà người dùng cuối không được phép xem, vì mọi câu trả lời đều được lọc ở tầng dữ liệu trước khi nó rời khỏi Lakehouse.

Bước 0: Bắt đầu với danh tính: Automatic Identity Management (AIM) và Just-in-Time (JIT) provisioning

Nền tảng kiến trúc bắt đầu bằng việc đảm bảo danh tính doanh nghiệp của bạn vừa chính xác vừa cập nhật.

Kiểm soát truy cập về cơ bản chỉ đáng tin cậy khi các danh tính mà chúng đánh giá đáng tin cậy. Một chính sách quy định "thành viên của brickstore_apac chỉ được xem các đơn hàng APAC" sẽ trở nên vô nghĩa nếu tư cách thành viên nhóm của bạn trong Databricks là một bản sao cũ kỹ, được duy trì thủ công từ nhà cung cấp danh tính (IdP).

Automatic Identity Management cho Microsoft Entra ID và Okta giúp thu hẹp khoảng cách đó. Khi được kích hoạt, người dùng, nhóm, tư cách thành viên nhóm và service principal sẽ tự động đồng bộ từ các nhà cung cấp danh tính đó vào Databricks mà không cần ứng dụng SCIM. Tính năng Just-in-time provisioning luôn được bật, vì vậy một người dùng chưa từng đăng nhập vào Databricks sẽ được cấp quyền ngay lần đăng nhập đầu tiên và mang theo các tư cách thành viên nhóm hiện có của họ.

Dưới đây là quy trình từng bước:

Lợi ích là quản trị mang tính liên tục, không phải là thiết lập tại một thời điểm. Khi một nhân viên chuyển từ APAC sang AMER, IdP sẽ di chuyển họ giữa các nhóm, quá trình đồng bộ sẽ lan truyền thay đổi đó, và câu hỏi tiếp theo họ đặt ra cho Genie sẽ trả về chế độ xem AMER — mà không ai cần phải gửi ticket hay thực hiện thay đổi đối với Genie Agent. Khi nhân viên rời công ty, họ bị hủy kích hoạt khỏi IdP và quyền truy cập của họ vào mọi Genie Agent sẽ bị xóa ngay lập tức.

Bước 1: Làm nền tảng cho dữ liệu có cấu trúc và kiểm soát bốn tầng truy cập

Khi danh tính đã được thiết lập đúng cách, giờ đây chúng ta có thể tập trung vào những gì họ được phép xem. Đối với dữ liệu có cấu trúc, một Genie Agent có thể truy cập bất kỳ tài sản dữ liệu nào trong Unity Catalog—bảng, view, materialized view, metric view, streaming table và thậm chí cả foreign table được liên kết từ các hệ thống bên ngoài.

Ví dụ, Delta table là các dữ kiện (facts) và chiều (dimensions). Tại Brickstore, đó là brickstore.sales.orders (mọi đơn hàng, với khu vực và email khách hàng) và brickstore.sales.products (danh mục gạch). Metric Views là tầng ngữ nghĩa được quản trị nằm bên trên — chúng mã hóa các định nghĩa về chỉ số kinh doanh của bạn (ví dụ: "doanh thu thuần" nghĩa là gì, "gạch đã bán" được tính như thế nào, cái gì được tính là "gạch bán chạy nhất") một lần, trong YAML, để mọi người tiêu dùng đều tính toán chúng theo cùng một cách.

Bên trên các tài sản đó là bốn tầng kiểm soát truy cập mà mọi người thường nhầm lẫn với nhau:

Tầng

Câu hỏi cần giải đáp

Cơ chế

Quyền đối tượng (Object Privileges)

Ai có mức độ truy cập nào đối với tài nguyên nào?

GRANT SELECT trên catalog/schema/table

Kiểm soát truy cập dựa trên thuộc tính (ABAC)

Chính sách nào áp dụng, và cho cái gì?

Các chính sách dựa trên thẻ (tag) được quản trị, gắn một lần và lan truyền (ví dụ: bất kỳ cột nào có thẻ "PII" chỉ khả dụng với một số nhóm nhất định)

Bộ lọc hàng (Row filters)

Người dùng có quyền truy cập vào những hàng nào?

Hàm do người dùng định nghĩa (UDF) bằng SQL đánh giá từng hàng tại thời điểm truy vấn (các hàng mà hàm trả về FALSE sẽ bị loại khỏi kết quả truy vấn)

Mặt nạ cột (Column Masks)

Những cột nào cần được che giấu và bằng cách nào?

SQL UDF nhận giá trị cột làm đầu vào và trả về giá trị gốc hoặc phiên bản đã che giấu

Quyền đối tượng là tầng truy cập đầu tiên: nếu không có SELECT, Genie không thể truy vấn bảng thay mặt cho người dùng cuối. Nhưng cấp quyền truy cập vào một bảng không có nghĩa là bạn cần cấp toàn bộ bảng đó. Bạn xếp chồng các bộ lọc hàng và mặt nạ cột lên trên các quyền đó, để một quản lý khu vực có thể truy vấn bảng đơn hàng trong khi chỉ thấy các hàng thuộc khu vực của họ và không bao giờ thấy email khách hàng thô. Các kiểm soát hàng và cột đó dựa trên chính các nhóm mà quyền của bạn đã sử dụng — ví dụ như is_account_group_member('brickstore_apac'). ABAC, tiếp theo đây, không thay thế bất kỳ điều nào trong số này; nó chỉ là một cách để đính kèm các bộ lọc và mặt nạ tương tự theo chính sách thay vì thực hiện từng bảng một.

ABAC: định nghĩa chính sách một lần, để nó tự lan truyền

Cách cũ để thực hiện bảo mật hàng và cột là thực hiện theo từng bảng: viết một bộ lọc hàng, đính kèm vào bảng orders; viết một mặt nạ cột, đính kèm vào bảng khác; lặp lại mãi mãi. Nó vẫn phù hợp với logic đơn lẻ, nhưng trên hàng trăm bảng, đó là một cấu hình dễ xảy ra sai sót.

Các chính sách ABAC, hiện đã có sẵn (GA) trong Unity Catalog cùng với các thẻ được quản trị và phân loại dữ liệu tự động, sẽ đảo ngược điều đó. Bạn gắn thẻ dữ liệu nhạy cảm bằng các thẻ được quản trị (các cặp khóa/giá trị ở cấp tài khoản, được kiểm soát truy cập như pii:email), và bạn viết một chính sách duy nhất nói rằng "bất cứ nơi nào thẻ này xuất hiện, hãy áp dụng bảo vệ này". Các bảng mới sẽ kế thừa sự bảo vệ ngay khi chúng được gắn thẻ, vì vậy không cần phải làm việc trên từng bảng.

Một mặt nạ cột + Chính sách ABAC bảo vệ mọi cột email trong catalog, chỉ trong một câu lệnh: