SDX — Quản trị dùng chung của Cloudera: RBAC, Masking, Kiểm toán

Một nền tảng dữ liệu luôn có nhiều lối vào cùng một bảng: người phân tích chạy SQL trong kho dữ liệu, kỹ sư chạy Spark, luồng streaming ghi vào liên tục, mô hình AI đọc để huấn luyện. Câu hỏi khó vì thế không phải “có bảo mật được không”, mà là “bảo mật có giống hệt nhau ở mọi lối vào không”.

SDX (Shared Data Experience) là câu trả lời của Cloudera: một lớp bảo mật, phân quyền và quản trị dùng chung nằm bên dưới mọi dịch vụ. Bạn đặt chính sách một lần — và chính sách đó áp dụng ở mọi nơi: kho dữ liệu, Spark, streaming, AI, tại chỗ hay trên đám mây. Đây là điểm khác biệt lớn nhất của Cloudera: quản trị không phải thứ gắn thêm cho từng công cụ, mà là nền móng của cả nền tảng.

Một bộ luật chung — phân quyền theo vai trò RBAC (Role-Based Access Control), kiểm soát tới hàng và cột, che dữ liệu, nhật ký truy cập phục vụ kiểm toán — viết một lần rồi áp cho tất cả. Bài này đi qua từng phần đó.

flowchart TD
  POL["Chính sách đặt MỘT LẦN<br/>RBAC · hàng · cột · masking · nhãn"]
  POL --> SDX["SDX − lớp quản trị dùng chung<br/>Apache Ranger · Apache Atlas"]
  SDX --> DW["Data Warehouse<br/>SQL"]
  SDX --> DE["Data Engineering<br/>Spark"]
  SDX --> STR["Streaming<br/>Kafka · Flink"]
  SDX --> ODB["Operational Database"]
  SDX --> AI["Cloudera AI"]
  DW --> AUD["Nhật ký truy cập → hồ sơ kiểm toán"]
  DE --> AUD
  STR --> AUD
  ODB --> AUD
  AI --> AUD
  SDX -.-> HYB["Chính sách đi theo dữ liệu<br/>tại chỗ ⇒ đám mây ⇒ biên"]

Đặt một lần, áp mọi nơi

Khi mỗi dịch vụ tự giữ một bộ quyền riêng, chính sách trôi dạt theo thời gian: cùng một cột số căn cước, đường SQL thì che, đường Spark thì không. Không ai cố ý — nó chỉ đơn giản là hệ quả của việc cấu hình ở bốn nơi khác nhau, bởi bốn đội khác nhau, vào bốn thời điểm khác nhau.

SDX gỡ đúng chỗ đó: chính sách nằm một nơi duy nhất, dịch vụ nào cũng phải hỏi qua nó trước khi trả dữ liệu.

Lối vào dữ liệu	Khi mỗi dịch vụ tự quản quyền	Với SDX
SQL trong kho dữ liệu	Một bộ cấu hình riêng	Kế thừa cùng một chính sách
Spark · Data Engineering	Một bộ cấu hình riêng	Kế thừa cùng một chính sách
Streaming · Kafka · Flink	Một bộ cấu hình riêng	Kế thừa cùng một chính sách
Notebook · mô hình AI	Một bộ cấu hình riêng	Kế thừa cùng một chính sách
Kiểm toán	Ghép nhật ký từ nhiều nguồn	Một dòng thời gian thống nhất

Bên dưới SDX là hai dự án mã nguồn mở quen thuộc: Apache Ranger lo phân quyền và nhật ký truy cập, Apache Atlas lo metadata, phân loại và nguồn gốc dữ liệu. Đây là điểm đáng lưu ý với các tổ chức có yêu cầu chủ quyền dữ liệu — lớp quản trị không phải hộp đen độc quyền.

RBAC — phân quyền theo vai trò

RBAC là nguyên tắc nền: bạn không cấp quyền cho từng người, mà cấp quyền cho vai trò, rồi gán vai trò cho người. Nhân sự đổi vị trí thì đổi vai trò — không phải dò lại từng bảng, từng cột.

Lợi ích thực tế lớn nhất không nằm ở lúc cấp quyền, mà ở lúc rà soát: câu hỏi “ai đang có quyền đọc dữ liệu khách hàng” trả lời được trong vài phút, vì nó là câu hỏi về vai trò chứ không phải về hàng trăm cá nhân.

Chính sách theo nhãn

Ngoài phân quyền theo tên bảng/cột, SDX cho phép viết chính sách theo nhãn phân loại. Ví dụ: gắn nhãn PII — Personally Identifiable Information, dữ liệu định danh cá nhân — lên các cột nhạy cảm, rồi viết một chính sách duy nhất: “vai trò Marketing không đọc cột mang nhãn PII”.

Chính sách đó tự động áp cho mọi cột được gắn nhãn, kể cả các bảng tạo ra sau này. Đây là cách duy nhất để quản trị theo kịp tốc độ sinh bảng mới — và là lý do Data Catalog gắn chặt với SDX.

Kiểm soát tới hàng và cột

Phân quyền ở mức bảng chỉ có hai lựa chọn: mở hết hoặc khóa hết. Thực tế nghiệp vụ nằm ở giữa.

Mức cột — ẩn hoặc chặn từng cột nhạy cảm, giữ nguyên phần còn lại của bảng. Đội phân tích vẫn dùng được bảng giao dịch mà không thấy số tài khoản.
Mức hàng — lọc dòng theo chính người đang hỏi. Giám đốc chi nhánh Đà Nẵng chỉ thấy khách hàng chi nhánh mình; hội sở thấy toàn bộ. Cùng một bảng, cùng một dashboard, cùng một câu truy vấn.

Điểm quan trọng: không cần tạo bảng riêng cho từng chi nhánh, từng phòng ban. Một bảng, nhiều góc nhìn — dữ liệu không bị nhân bản, nên cũng không có chuyện bản sao lệch số.

Che dữ liệu — masking

Che dữ liệu diễn ra lúc truy vấn, theo vai trò của người hỏi. Không có bảng “bản đã che” song song để phải đồng bộ.

Vai trò	Cột `so_the` trả về
`VAN_HANH_THE`	`9704 1234 5678 9010` — giá trị thật
`PHAN_TICH`	`** ** 9010` — giữ 4 số cuối
`MARKETING`	`NULL` — che hoàn toàn

Các kiểu che thường dùng: che toàn bộ, giữ vài ký tự cuối, băm giá trị (hash) để vẫn nối bảng được mà không lộ gốc, trả về rỗng, hoặc rút ngày sinh về chỉ còn năm.

Nhật ký truy cập — chứng cứ, không phải lời hứa

Mỗi lần một dịch vụ hỏi dữ liệu, SDX ghi lại: ai hỏi, lúc nào, hỏi tài nguyên nào, qua dịch vụ nào, chính sách nào quyết định, và kết quả là cho phép hay từ chối.

Chi tiết dễ bị bỏ qua nhưng có giá trị cao nhất: các lần bị từ chối cũng được ghi. Một tài khoản liên tục chạm vào bảng ngoài phạm vi công việc là tín hiệu sớm, thấy được trước khi thành sự cố.

Chính sách đi theo dữ liệu xuyên hybrid

Dữ liệu hiếm khi đứng yên một chỗ. Khi khối lượng xử lý tràn từ trung tâm dữ liệu riêng sang đám mây lúc cao điểm, hoặc khi cùng một tập dữ liệu được đọc ở cả hai môi trường, chính sách và metadata đi cùng dữ liệu thay vì phải dựng lại từ đầu ở mỗi nơi.

Với các tổ chức Việt Nam vận hành song song trung tâm dữ liệu tại chỗ và đám mây, đây là khác biệt giữa một mô hình quản trị và hai mô hình phải liên tục đối chiếu. Xem thêm Triển khai hybrid & Cloud Bursting.

Đóng khung Việt Nam: trả lời được câu hỏi của kiểm toán

Ngân hàng, viễn thông và khu vực công đều gặp cùng một nhóm câu hỏi — từ kiểm toán nội bộ, kiểm toán độc lập, hay đoàn thanh tra chuyên ngành:

Câu hỏi được hỏi	SDX trả lời bằng gì
Ai đã xem dữ liệu khách hàng trong quý vừa rồi?	Nhật ký truy cập, lọc theo tài nguyên và mốc thời gian
Người đó có quyền không, quyền đến từ đâu?	Vai trò đang gán + chính sách đã áp
Dữ liệu cá nhân có được che ngoài phạm vi nghiệp vụ?	Chính sách masking theo nhãn, áp cho mọi dịch vụ
Có ai bị từ chối truy cập bất thường không?	Bản ghi từ chối trong nhật ký
Quyền đã thay đổi thế nào từ lần kiểm tra trước?	Lịch sử thay đổi chính sách

Điểm mấu chốt: các câu hỏi này được trả lời bằng bản ghi của hệ thống, không phải bằng cam kết miệng hay một file Excel tổng hợp thủ công. Và vì Cloudera chạy được ngay trong trung tâm dữ liệu của bạn, cả dữ liệu lẫn nhật ký chứng minh đều không rời khỏi vành đai — điều kiện gần như bắt buộc với dữ liệu thuộc diện nhạy cảm tại Việt Nam.

Các sai lầm dễ mắc phải

Gán quyền thẳng cho từng người. Chạy tốt trong ba tháng đầu, và trở thành mê cung ở tháng thứ mười hai. Vai trò trước, người sau.
Tạo bảng “bản đã che” riêng. Có vẻ nhanh, nhưng sinh ra hai nguồn số liệu và một việc đồng bộ vĩnh viễn. Che lúc truy vấn giải quyết gọn hơn.
Chỉ phân quyền tới mức bảng. Kết cục là hoặc mở quá tay, hoặc khóa đến mức đội phân tích tự đi xin file — dữ liệu rời khỏi vùng kiểm soát bằng đúng con đường mà chính sách định chặn.
Bật nhật ký nhưng không định trước thời gian lưu. Kiểm toán hỏi về quý trước, nhật ký chỉ còn hai tuần.
Quản trị bằng nhãn nhưng không ai gắn nhãn. Chính sách theo nhãn chỉ mạnh khi việc phân loại chạy đều — đó là phần việc của Data Catalog.

Đọc tiếp

Data Catalog & Lineage Phân loại, nhận diện dữ liệu nhạy cảm và truy vết nguồn gốc — nguyên liệu cho chính sách theo nhãn.

Triển khai hybrid & Cloud Bursting Vì sao chính sách đi theo dữ liệu lại quan trọng khi chạy cả tại chỗ lẫn đám mây.