Power BI 8 — Quản trị, bảo mật & triển khai

Đây là bài khép lại series Power BI chuyên sâu. Sau khi đã đi qua tổng quan nền tảng, mô hình dữ liệu, DAX, chế độ lưu trữ & refresh và thiết kế báo cáo, câu hỏi cuối cùng — và cũng là câu hỏi khó nhất — không còn là "làm sao vẽ đẹp" mà là: làm sao đưa Power BI vào vận hành trong tổ chức một cách an toàn, có kiểm soát và bền vững?

Một nền tảng BI cho ngân hàng cần: đúng người thấy đúng dữ liệu, thay đổi được kiểm soát qua DEV/TEST/PROD, dữ liệu được refresh đúng giờ, và ban quản trị nhìn được ai đang dùng gì. Bài này gói các mảnh đó lại.

1. Workspace & vai trò — đơn vị tổ chức cơ bản

Trong Power BI Service, workspace là ranh giới cộng tác và bảo mật đầu tiên. Mọi thứ (semantic model, report, dashboard, dataflow, pipeline...) đều nằm trong một workspace. Việc thiết kế workspace tốt là nền móng của quản trị.

Bốn vai trò trong workspace

Nguyên tắc least privilege: mặc định gán Viewer, nâng lên Contributor cho người thực sự phát triển, giữ Member/Admin cho số ít. Nên gán vai trò cho security group (Entra ID) thay vì từng cá nhân — quản lý tập trung và tránh "mồ côi quyền" khi người rời tổ chức.

Tách workspace theo nhóm/chủ đề

Đừng dồn mọi thứ vào một workspace. Chia theo miền nghiệp vụ (Tín dụng, Huy động, Rủi ro, Marketing...) hoặc theo vòng đời (mỗi môi trường một workspace — xem mục pipeline). Một mô hình phổ biến cho doanh nghiệp:

• Workspace shared datasets (semantic model dùng chung, được chứng thực).
• Workspace reports theo từng phòng ban, kết nối tới shared dataset.

Certified vs Promoted datasets

Power BI cho phép endorse (chứng thực) semantic model:

• Promoted: bất kỳ Contributor nào cũng có thể đánh dấu "đây là model đáng tin".
• Certified: chỉ nhóm được tenant admin uỷ quyền mới cấp — đây là dấu "vàng" báo hiệu nguồn sự thật chính thức. Trong ngân hàng, chỉ những model đã qua kiểm định chất lượng dữ liệu mới nên được Certified.

2. Vòng đời & triển khai — Deployment Pipelines

Sửa trực tiếp trên báo cáo production là công thức của tai nạn. Power BI cung cấp Deployment Pipelines để chuẩn hoá luồng DEV → TEST → PROD.

Ba stage mặc định

Pipeline mặc định có 3 stage — Development, Test, Production — mỗi stage gắn với một workspace riêng. Bạn có thể tuỳ biến số lượng stage (2–10) và tên gọi tuỳ nhu cầu tổ chức. Khi deploy từ stage này sang stage kế tiếp, Power BI sao chép nội dung, tráo các tham số theo môi trường và ghi log thao tác.

Deployment rules & tham số theo môi trường

Điểm cốt lõi: DEV, TEST, PROD thường không dùng cùng nguồn. Deployment rules cho phép khai báo giá trị khác nhau cho mỗi stage — connection string, tên database, hoặc parameter — mà không phải sửa file gốc.

Thực hành tốt: đặt server/database thành parameter trong Power Query, rồi dùng deployment rule để mỗi stage tự nạp đúng giá trị. Một mẹo hay là chỉ import ít dòng ở DEV/TEST (tăng tốc phát triển) và full ở PROD, điều khiển bằng chính parameter đó.

Tách shared dataset khỏi thin report

Kiến trúc quản trị tốt: một semantic model dùng chung (được Certified), và nhiều "thin report" chỉ chứa trực quan hoá, kết nối live tới model đó. Lợi ích:

• Một nơi định nghĩa measure → tránh mỗi báo cáo tính "doanh số" một kiểu.
• Đổi logic một lần, mọi report hưởng lợi.
• Phân quyền RLS tập trung ở model, không rải rác.

Source control — Git integration (Fabric)

Deployment Pipelines quản lý thăng cấp giữa các môi trường, còn Fabric Git integration quản lý lịch sử phiên bản & review code. Git integration nối một workspace Fabric với repo Azure DevOps hoặc GitHub, lưu mỗi artifact dưới dạng file text.

• PBIP (Power BI Project): thay vì một file .pbix nhị phân, Desktop lưu report và semantic model thành các file text trong cấu trúc thư mục — diff được, merge được.
• TMDL (Tabular Model Definition Language): định dạng text kiểu YAML mô tả semantic model, thân thiện với diff/merge trong Git, thay cho JSON nhúng trong PBIX.

Thực tiễn doanh nghiệp 2025–2026 thường dùng cả hai: Git integration cho source control + pull-request review, và Deployment Pipelines cho luồng thăng cấp có kiểm soát. (Có thể tự động hoá bằng thư viện Microsoft-backed fabric-cicd.)

3. Bảo mật dữ liệu — RLS & OLS

Phân quyền workspace kiểm soát ai vào được report. Nhưng trong cùng một report, một cán bộ chi nhánh Hà Nội không được thấy số liệu chi nhánh TP.HCM. Đó là việc của RLS/OLS — bảo mật ở tầng dữ liệu, ngay trong model.

RLS — Row-Level Security (lọc theo dòng)

RLS gồm hai phần: định nghĩa role và gắn DAX filter lên bảng. Có hai kiểu:

a) Static RLS — mỗi role một bộ lọc cố định. Phù hợp khi số nhóm ít và ổn định.

-- Role "ChiNhanh_HaNoi" (minh hoạ)
-- Áp dụng lên bảng DimChiNhanh
[TenChiNhanh] = "Hà Nội"

Nhược điểm: mỗi chi nhánh một role → hàng chục role, khó bảo trì.

b) Dynamic RLS — một role duy nhất lọc khác nhau cho từng người dựa trên bảng ánh xạ người dùng và hàm USERPRINCIPALNAME(). Đây là cách phổ biến nhất ở quy mô lớn.

-- Role "ChiNhanhTheoNguoiDung" (minh hoạ)
-- Áp dụng lên bảng ánh xạ DimUserChiNhanh
[Email] = USERPRINCIPALNAME()

Với thiết lập trên: bảng DimUserChiNhanh (Email ↔ MãChiNhanh) được lọc còn đúng các dòng của người đang đăng nhập; nhờ quan hệ lan truyền tới bảng fact, người dùng chỉ thấy dữ liệu chi nhánh của mình. Thêm một cán bộ mới không cần sửa model — chỉ cần thêm một dòng vào bảng ánh xạ.

Vài lưu ý quan trọng:

• USERPRINCIPALNAME() trên Power BI Service trả về email của người đăng nhập trình duyệt; trên Desktop trả về tài khoản máy (domain\user) — nên hành vi khác nhau khi test.
• Sau khi publish, phải gán thành viên vào role ở phía Service (thường gán security group).
• Dùng tính năng "Test as role" để kiểm thử, nhưng với dynamic RLS và người dùng khách bên ngoài, hãy test với tài khoản thật vì "Test as role" dùng chính danh tính của bạn.

OLS — Object-Level Security (ẩn bảng/cột)

RLS lọc dòng; OLS ẩn hẳn bảng hoặc cột khỏi một số role. Ví dụ: ẩn cột LuongCanBo hoặc bảng ChiPhiRuiRo với nhóm không được phép. Khi bị OLS chặn, người dùng không nhìn thấy cả sự tồn tại của đối tượng đó (khác với RLS chỉ làm rỗng dữ liệu).

Kết hợp nhiều tầng & Sensitivity labels

Bảo mật hiệu quả là nhiều lớp: quyền workspace/app quyết định vào được report → RLS/OLS quyết định thấy dữ liệu gì bên trong. Trên nữa là Sensitivity labels (Microsoft Information Protection): gắn nhãn "Nội bộ / Mật / Tối mật" lên dataset và report. Nhãn này theo dữ liệu cả khi export ra Excel/PDF (mã hoá, kiểm soát), giúp tránh rò rỉ khi dữ liệu rời khỏi Service.

4. Kết nối nguồn & refresh

Với model Import, dữ liệu trong Service là bản chụp và cần được làm mới. Với nguồn on-prem, đường về là gateway.

On-premises data gateway: personal vs standard

Microsoft khuyến nghị dùng standard gateway cho production. Personal gateway là single point of failure, không giám sát/quản lý tập trung được. Mỗi người chỉ chạy được một personal gateway.

Scheduled refresh & giới hạn

Cấu hình scheduled refresh để dataset tự làm mới theo lịch. Cần lưu ý các giới hạn theo license: dung lượng Shared/Pro thường giới hạn số lần refresh mỗi ngày; Premium/Fabric capacity cho tần suất cao hơn và refresh dạng API/XMLA. Luôn quản lý credential/secret của nguồn ngay tại gateway/dataset (tránh nhúng mật khẩu trong file), và ưu tiên tài khoản dịch vụ (service principal) thay vì tài khoản cá nhân.

Incremental refresh

Với bảng fact lớn, đừng refresh toàn bộ mỗi lần. Incremental refresh chỉ nạp lại phần dữ liệu mới/thay đổi (ví dụ 7 ngày gần nhất) và giữ nguyên phần cũ — nhanh hơn nhiều, giảm tải nguồn. Chủ đề này nối tiếp bài chế độ lưu trữ & refresh; ở đây chỉ cần nhớ nó là mặc định nên bật cho các bảng giao dịch lớn của ngân hàng.

5. Phân phối — đưa báo cáo tới người dùng

Đừng chia sẻ báo cáo bằng cách thêm hàng trăm người vào workspace (họ sẽ thấy cả bản nháp). Cách chuẩn là Power BI App.

• Power BI App: đóng gói các report/dashboard "chín" từ workspace thành một ứng dụng gọn gàng cho người tiêu dùng. Người dùng chỉ thấy nội dung đã publish, không thấy đồ dở dang.
• App audiences: trong một app, tạo nhiều audience khác nhau — ví dụ "Ban lãnh đạo" thấy trang tổng hợp, "Cán bộ chi nhánh" thấy trang tác nghiệp. Kết hợp với RLS để cùng một app phục vụ nhiều đối tượng an toàn.
• Chia sẻ trực tiếp: dùng cho tình huống ad-hoc, một-vài người; không nên là kênh phân phối chính.
• Embed (nhắc): nhúng report vào ứng dụng nội bộ / portal (embed for your organization hoặc embed for customers) khi cần tích hợp sâu.
• Export: xuất PDF/PowerPoint/Excel — tiện nhưng nhớ rằng Sensitivity label sẽ theo file; hạn chế export dữ liệu nhạy cảm.

6. Giám sát & quản trị tenant

Quản trị không dừng ở lúc publish. Cần nhìn thấy hệ thống đang được dùng ra sao.

• Usage metrics: mỗi report có báo cáo lượt xem, người xem, thiết bị — biết cái nào được dùng, cái nào nên khai tử.
• Audit log / Activity events: nhật ký toàn tenant (ai xem, export, chia sẻ, đổi quyền) — lấy qua Microsoft Purview / admin API, phục vụ compliance và điều tra sự cố; rất quan trọng với ngân hàng.
• Tenant settings: admin bật/tắt tính năng cấp tổ chức — ai được publish app, share ra ngoài, export, dùng service principal... "van tổng" của quản trị.
• Capacity metrics (Fabric/Premium): theo dõi CPU, bộ nhớ, thời gian refresh, throttling qua app "Fabric Capacity Metrics" để phát hiện nghẽn và điều phối tải.

Use case thực tế — Triển khai chuẩn cho phòng dữ liệu ngân hàng

Bối cảnh: Khối Dữ liệu cần cấp báo cáo "Kết quả kinh doanh chi nhánh" cho ~120 chi nhánh. Mỗi giám đốc chi nhánh chỉ được thấy số liệu chi nhánh mình; ban lãnh đạo thấy toàn hàng.

Thiết kế triển khai:

1. Shared dataset + thin report. Một semantic model "KQKD" duy nhất, được Certified, đặt ở workspace shared datasets. Các report chỉ trực quan hoá, kết nối live — mọi measure ("Dư nợ", "Huy động", "NIM") định nghĩa một chỗ (SSoT).

2. Pipeline DEV → TEST → PROD. Ba workspace theo pipeline. Deployment rule tráo nguồn: DEV → sandbox (import 30 ngày), TEST → bản sao DWH cho UAT, PROD → DWH thật (full + incremental refresh). Model & report được đưa vào Git (PBIP/TMDL) để review qua pull request trước khi thăng cấp.

3. Dynamic RLS theo chi nhánh. Bảng ánh xạ DimUserChiNhanh(Email, MãChiNhanh) đồng bộ từ HR/AD. Role duy nhất ChiNhanhTheoNguoiDung với filter [Email] = USERPRINCIPALNAME(). Thêm/bớt cán bộ = cập nhật bảng ánh xạ, không đụng model. Ban lãnh đạo cho vào role "Toàn hàng" (không lọc). OLS ẩn cột lương/chi phí nội bộ với nhóm chi nhánh.

4. Gateway + refresh. Standard gateway dạng cluster (HA) nối DWH on-prem. Scheduled refresh 02:00 hằng ngày bằng service principal; bảng giao dịch bật incremental refresh. Sensitivity label "Mật — Nội bộ" gắn lên dataset.

5. Phân phối qua App với hai audience: "Ban lãnh đạo" và "Chi nhánh". Cùng một app, RLS đảm bảo mỗi người thấy đúng phần của mình.

6. Giám sát: theo dõi usage metrics để biết chi nhánh nào ít dùng; audit log phục vụ compliance; capacity metrics canh thời gian refresh.

Kết quả: một nguồn sự thật, thay đổi có kiểm soát, dữ liệu đúng người, và ban quản trị nhìn được toàn cảnh — thay cho "rừng" file PBIX gửi qua email.

Best practices

• SSoT (Single Source of Truth): một shared dataset Certified cho mỗi miền nghiệp vụ; báo cáo là thin report kết nối vào đó.
• Tránh "report sprawl": định kỳ rà usage metrics, khai tử báo cáo không ai dùng và các bản trùng lặp.
• Đặt tên & chuẩn hoá: quy ước tên workspace/dataset/measure/role nhất quán; gán quyền qua security group, không qua cá nhân.
• Tài liệu measure: mô tả từng measure (ý nghĩa, công thức, nguồn) — trong model và/hoặc kho tri thức nội bộ.
• Review hiệu năng: dùng Performance Analyzer/DAX Studio định kỳ; canh capacity metrics; bật incremental refresh cho bảng lớn.
• Least privilege ở mọi tầng: workspace role tối thiểu + RLS/OLS + sensitivity label + tenant settings chặt.
• Đừng sửa PROD trực tiếp: mọi thay đổi đi qua Git + pipeline.

Ghi nhớ

• Workspace là ranh giới cộng tác; 4 vai trò Admin/Member/Contributor/Viewer — gán tối thiểu, ưu tiên security group.
• Deployment Pipelines chuẩn hoá DEV→TEST→PROD; deployment rules/parameter tráo nguồn theo môi trường; Git integration + PBIP/TMDL cho source control & review.
• Shared dataset + thin report = một nơi định nghĩa measure, phân quyền tập trung.
• RLS lọc dòng (static cố định; dynamic dùng USERPRINCIPALNAME() + bảng ánh xạ — chuẩn cho quy mô lớn); OLS ẩn bảng/cột; phủ thêm sensitivity labels.
• Standard gateway (không phải personal) cho production; scheduled + incremental refresh; dùng service principal, quản lý secret ở gateway.
• Phân phối qua App + audiences, không nhồi người vào workspace.
• Quản trị bằng usage metrics, audit log, tenant settings, capacity metrics — nhìn được thì mới kiểm soát được.

Kết series: một nền tảng BI tốt không phải là báo cáo đẹp nhất, mà là báo cáo đúng người, đúng số, đúng lúc — và kiểm soát được. Đó là điểm giao giữa kỹ thuật và quản trị mà Power BI, khi triển khai bài bản, có thể đáp ứng cho cả một ngân hàng.

Xem lại series: Tổng quan Power BI · Chế độ lưu trữ & refresh · Thiết kế báo cáo

Nguồn tham khảo (Microsoft Learn & cộng đồng): Deployment pipelines (Fabric ALM) · RLS trong Power BI · Fabric Git integration · PBIP projects · Personal gateway · Scheduled refresh