Phân quyền trong Power BI cho người dùng là một phần quan trọng trong cả quy trình ứng dụng dữ liệu trong doanh nghiệp. Bởi nó ảnh hưởng đến bảo mật dữ liệu và giải quyết các vấn đề chia sẻ, truyền đạt thông tin trong doanh nghiệp. Trong bài viết này, chúng ta sẽ tìm hiểu chi tiết hơn về hai cách ứng dụng dynamic RLS để phân quyền trong Power BI.
Các nội dung chính
1. Row-level security (RLS) là gì?
Định nghĩa
RLS cho phép người quản lý của tổ chức hạn chế quyền xem các dòng thông tin trong báo cáo đối với một số người xem. Trong các bài viết trước đây, chúng ta đã được biết về định nghĩa, cách phân biệt giữa RLS tĩnh và RLS động (dynamic RLS) và một số cách áp dụng RLS trong thực tế.
Về cơ bản, RLS tĩnh dễ hiểu và dễ thực hành, nhưng chỉ nên sử dụng khi quy mô người xem báo cáo thấp, sự thay đổi phân quyền không thường xuyên. RLS động có thể ứng dụng trong khá nhiều trường hợp với số người xem báo cáo nhiều, thường xuyên có sự biến động nhân sự và phân quyền xem.
Ngoài việc sử dụng RLS, chúng ta còn có khái niệm Object-level security (OLS). Thay vì hạn chế số dòng thông tin người xem báo cáo có thể tiếp cận, OLS sẽ hạn chế số trường thông tin người xem có thể tiếp cận. Việc kết hợp giữa RLS và OLS sẽ giúp báo cáo của doanh nghiệp đạt được mức bảo mật cao, tránh bị rò rỉ thông tin tới các đối tượng không liên quan.
Một số ứng dụng của RLS
Bảo mật dữ liệu là một vấn đề đáng suy ngẫm đối với bất kì doanh nghiệp, tổ chức nào, ở bất kì quy mô nào. Đơn giản nhất như thông tin về số doanh thu một nhân viên sales đã đạt được trong tháng, thông tin này chỉ nên được hiển thị cho chính nhân viên đó và quản lí của họ. Phức tạp hơn thì chúng ta có thông tin cá nhân của khách hàng – một thông tin nhạy cảm và không phải bất kì một nhân sự nào trong công ty cũng được quyền xem, thậm chí là các nhân sự cấp cao. Thông tin tài chính hay doanh thu của doanh nghiệp cũng cần hạn chế số người có thể truy cập. Tất cả dữ liệu đều cần được phân quyền xem, để hạn chế tối đa những rủi ro về danh tiếng, vận hành,…
Việc phân quyền trong Power BI thủ công cho từng user bằng cách sử dụng RLS tĩnh chỉ áp dụng được trong trường hợp công ty/tổ chức chỉ có một số ít nhân sự. Một bài toán mới được đặt ra, khi công ty/tổ chức của chúng ta có 100 nhân sự, hoặc thậm chí 1000 nhân sự đều cần được phân quyền xem báo cáo, chúng ta cần xử lý như thế nào?
Trong bài viết này, chúng ta sẽ tìm hiểu chi tiết hơn về hai cách ứng dụng dynamic RLS để phân quyền trong Power BI, có thể giải quyết được bài toán đã đặt ra.
2. Dynamic Row-level Security cho từng account Power BI trong danh sách
Bài toàn được đặt ra cho phần này là: Giả sử chúng ta có một bảng danh sách nhân viên sales, mỗi nhân viên sales được gán cho một SalesPersonID. Có một bảng ghi lại các giao dịch với khách hàng, mỗi giao dịch do một nhân viên sales thực hiện. Hàng ngày, nhân viên sales cần vào xem báo cáo để biết doanh thu đến từ các khách hàng của nhân viên đó. Người quản lý cần phân quyền theo từng account của nhân viên sales để mỗi account nhân viên chỉ có thể xem được doanh thu của mình trên báo cáo.
Chúng ta có bảng có tên “User”, là bảng nhân viên bao gồm tên, ID của sales, và email để truy cập vào Power BI Service để xem báo cáo:
Và bảng giao dịch tên “Transaction”, bao gồm các thông tin giao dịch như ngày tháng, ID của giao dịch, ID của sales, doanh thu:
Thực hiện import 2 bảng này vào Power BI, chúng ta có model dữ liệu như sau:
Theo model này, mỗi khi thực hiện lọc trên bảng user, chọn 1 salesperson_id, bảng transaction cũng được lọc theo ID sales đó và chỉ hiện thị các thông tin do ID sales đó quản lý.
Như vậy, hướng giải quyết cho bài toán này cũng tương tự cơ chế trên: Khi 1 sales sử dụng account của mình để đăng nhập và xem báo cáo trên power BI service, báo cáo đó sẽ nhận dạng account của sales. Báo cáo sử dụng account vừa nhận dạng được để lọc trên bảng User, và nhận được kết quả là ID của sales đó. Báo cáo tiếp tục sử dụng ID của sales và lọc trên bảng transaction để lấy được những dòng thông tin do sales đó quản lý.
Từ định hướng trên, đầu tiên chúng ta thực hiện lấy account của người đang xem báo cáo bằng cách sử dụng hàm USERPRINCIPALNAME ().
Lưu ý là khi sử dụng hàm này, Power BI Desktop sẽ hiển thị giá trị là tên PC/laptop của người đang mở báo cáo, không phải account đang đăng nhập trên Power BI Desktop. Khi publish báo cáo lên Power BI Service, hàm sẽ hiển thị account đăng nhập như bình thường.
Chúng ta trực quan hóa một bảng như sau:
Mục tiêu của chúng ta là: với sales có ID là 8 và account là ****pm@datapot.vn, sales này chỉ có thể xem 1 dòng doanh thu của mình là 223,868,680.45.
Chúng ta vào Modeling > Manage Roles
Trong bảng mới hiện ra, chúng ta chọn Create và đặt tên cho Roles tùy nhu cầu. Ở đây đặt là userview.
Trong cột Tables, chúng ta click vào dấu 3 chấm cạnh user > Add filter > Chọn cột chứa email đăng nhập của sales.
Lúc này, trong phần Table filter DAX expression hiển thị như sau:
Chúng ta thay đổi ”Value” thành USERPRINCIPALNAME() và nhấn Save.
Chúng ta Save báo cáo và publish lên Power BI Service. Do người xem chỉ có thể xem báo cáo trên Power BI Service, chúng ta cần thêm 1 bước chỉnh sửa/thêm thành viên vào role ”Userview” trên Power BI Service.
Cần lưu ý rằng: Với người xây dựng và publish báo cáo, người này sẽ có thể xem tất cả dữ liệu mà không bị ảnh hưởng bởi việc phân quyền này. Do đó, khi xem báo cáo trên Power BI Desktop và Power BI Service bằng account của người xây dựng báo cáo, chúng ta không thấy có hiện tượng phân quyền. Trong ví dụ này, người viết sử dụng account ***tn@datapot.vn để xây dựng báo cáo nên khi publish, người viết có thể xem được tất cả thông tin, dù người viết cũng có sales ID là 9 và chỉ có 1 dòng hiển thị doanh thu.
Tiếp tục với ví dụ, sau khi publish lên Power BI Service, chúng ta nhận thấy trong Workspace hiển thị 1 file report và 1 file dataset.
Click dấu 3 chấm trong file Dataset và chọn Security.
Chúng ta nhận thấy có roles userview đã được tạo từ Power BI Desktop. Trong phần members, chúng ta sẽ add những email hoặc group workspace cần được share quyền xem báo cáo. Người viết add email *****pm@datapot.vn để kiểm tra.
Sau khi add email và save role, chúng ta thấy phần () bên cạnh userview đã hiển thị số email được add vào role này. Chúng ta có thể test quyền xem báo cáo bằng cách chuột phải vào userview, chọn test as role như hình.
Chúng ta có thể biết được mình đang xem báo cáo bằng role nào trong phần header báo cáo, dòng Now viewing as. Trên môi trường test này, người viết đang đăng nhập bằng account ***tn@datapot.vn, vì vậy báo cáo chỉ hiển thị phần doanh thu của account đó.
Chúng ta có thể test từng account chi tiết hơn bằng cách chọn Userview > nhập email cần test > apply.
Ví dụ đổi sang email ****pm@datapot.vn, báo cáo sẽ hiển thị đúng phần doanh thu của account đó. Trên dòng Now viewing as cũng sẽ đổi sang tên của account đang test.
3. Dynamic RLS cho account Power BI thuộc các bộ phận khác nhau trong một công ty
Bài toán này cũng tương tự như trên, nhưng nâng cấp hơn ở một số điểm: Vẫn là sales có ID 8 và account xem báo cáo là ****pm@datapot.vn, và sales này lại thuộc bộ phận SalesR3. Người quản lý thấy rằng mỗi sales của mỗi bộ phận cần phải xem được doanh thu của tất cả các sales khác trong bộ phận của mình, để so sánh doanh thu của mình với các thành viên cùng bộ phận. Người quản lý sẽ cần phân quyền trong Power BI như thế nào?
Chúng ta vẫn có bảng User như trên:
Bảng Transaction ghi lại giao dịch của khách hàng và sales phụ trách, có thêm 1 cột là DeptID, là bộ phận Sales làm việc.
Bảng Dept bao gồm DeptID và tên bộ phận
Bảng Group bao gồm DeptID và SalesPersonID, dùng để tra cứu Sales nào thuộc về bộ phận nào.
Chúng ta thực hiện import các bảng dữ liệu vào Power BI Desktop và modeling data.
Bảng dept đóng vai trò bảng trung gian giữa bảng group và bảng transaction, vì mối quan hệ giữa bảng transaction và bảng group là mối quan hệ many-to-many, vậy nên để tránh làm data model trở nên phức tạp, khó kiểm soát, chúng ta tạo ra bảng dept trung gian và tạo mối quan hệ 1-many với 2 bảng còn lại.
Cơ chế hoạt động của model này như sau: Khi user mở báo cáo, Power BI sẽ ghi nhận account của user đó và lọc ra salesperson_id tương ứng. Báo cáo tự động sử dụng salesperson_id đó để lọc trên bảng group và lấy ra deptID tương ứng. Sau đó, báo cáo sử dụng DeptID này để lọc trên bảng transaction và lấy ra những dòng thông tin do DeptID này quản lý.
Mục tiêu của chúng ta là phân quyền cho tất cả những SalesPersonID thuộc 1 DeptID có thể xem được thông tin thuộc về DeptID đó, ví dụ như trong trường hợp này, chúng ta muốn các SalesPersonID thuộc DeptID 3 có thể xem được thông tin của cả Dept:
Vào Modeling > Manage Roles
Tương tự ví dụ 1, tạo Roles > đặt tên là userview.
Trong phần Tables, chọn transaction và nhập hàm sau vào Table filter DAX expression:
[deptID]
IN CALCULATETABLE (
VALUES ( dept[DeptID] ),
FILTER ( 'group', RELATED ( user[account] ) = USERPRINCIPALNAME () )
)Phân tích hàm trên, chúng ta có:
FILTER ( 'group', RELATED ( user[account] ) = USERPRINCIPALNAME () ) Báo cáo ghi nhận account đang đăng nhập xem báo cáo (trong bảng user), từ đó tìm thấy SalesPersonID của account đó và lọc sang bảng Group. Bảng Group lúc này chỉ chứa những dòng do SalesPersonID đó quản lí.
Ví dụ: account đăng nhập là ****pm@datapot.vn, báo cáo ghi nhận account này và tìm thấy SalesPersonID tương ứng là 8.
Báo cáo lọc sang bảng Group, lấy được DeptID là 3.
CALCULATETABLE (
VALUES ( dept[DeptID] ),
FILTER ( 'group', RELATED ( user[account] ) = USERPRINCIPALNAME () )
)Lúc này, bảng Group chỉ còn chứa những dòng do SalesPersonID đó quản lí. Chúng ta tạo ra 1 bảng ảo chỉ có 1 cột là DeptID không trùng lặp vừa tìm được.
[deptID]
IN CALCULATETABLE (
VALUES ( dept[DeptID] ),
FILTER ( 'group', RELATED ( user[account] ) = USERPRINCIPALNAME () )
)Bộ lọc sau cùng của chúng ta trên bảng Transaction là những DeptID tương ứng với SalesPersonID đang truy cập xem báo cáo.
Sau khi save bộ lọc, chúng ta publish báo cáo và thực hiện các bước phân quyền trong Power BI service như ví dụ 1.
Kết quả như sau: với sales dùng account ****pm@datapot.vn, sales này thuộc DeptID 3 nên mặc dù sales này dùng account cá nhân vẫn có thể xem được thông tin của cả DeptID 3.
Tham khảo:
- Dynamic Row Level Security with Power BI Made Simple
- What Do You Need to Implement Dynamic Row-Level Security in Power BI?
- Row-Level Security 101: The Basics of Row-Level Security
- Dynamic Row-Level Security for Manager Level in Power BI? | RLS In Power BI Ep4 | BI Consulting Pro
Ngoài ra, tôi cũng có những bài hướng dẫn thực hành sử dụng các tính năng khác trong Power BI mà bạn có thể tìm hiểu tại đây.
