Tuy nhiên, vì dữ liệu giả lập không mô phỏng hết được các trạng thái thực tế (người tạo ra chúng không lường hết các tình huống) nên các nhóm kiểm thử trong quá trình triển khai ứng dụng CNTT vẫn đôi khi phải dùng đến dữ liệu thực. Bên cạnh đó, các nhóm phân tích thị trường, hỗ trợ khách hàng thường xuyên phải truy cập dữ liệu thực và có thể tiếp cận tới những thông tin mà họ không nên biết. Số chứng minh, số tài khoản, số thẻ tín dụng của khách hàng có thể bị những nhân viên hỗ trợ khách hàng ghi nhớ và lạm dụng - đặc biệt là nếu doanh nghiệp thuê dịch vụ call center bên ngoài....
Những nguyên nhân đó đã dẫn đến sự ra đời của các sản phẩm che giấu dữ liệu - những sản phẩm sử dụng dữ liệu gốc làm mô hình để tạo ra dữ liệu sửa đổi (masked data) có những đặc tính khiến người dùng nghĩ đó là dữ liệu thật. Bằng cách sửa đổi để che giấu những phần người dùng cuối không cần biết trong dữ liệu, chúng ta có thể hạn chế được khả năng làm lộ thông tin, đồng thời vẫn tạo điều kiện để người dùng thực hiện công việc.

Bảng 1: Thông tin thực về khách hàng

Tuỳ theo ngữ cảnh sử dụng và nhà cung cấp giải pháp, che giấu dữ liệu có thể được gọi bằng những thuật ngữ khác nhau: data masking, data obfuscation, data scrubbing, data de-identification, anonymization. Chúng đều nhằm một mục đích thay đổi dữ liệu thực để người dùng cuối chỉ biết được những thông tin đủ dùng cho công việc cụ thể. Che giấu dữ liệu không thay thế cho các công nghệ bảo mật dữ liệu như mã hoá, xác thực, phân quyền,…  Khi dữ liệu mã hoá được giải mã, người dùng sẽ có dữ liệu rõ (dữ liệu gốc). Trong khi đó, công nghệ che giấu dữ liệu tốt đảm bảo rằng một phần của dữ liệu gốc không bao giờ bị lộ cho người dùng - họ chỉ thấy những dữ liệu “như thật” (chẳng hạn như tên của những chủ tài khoản có số dư lớn và số dư thực của họ). Phương pháp thay thế giúp che giấu thông tin khách hàng được thể hiện trong Bảng 1 và Bảng 2.

Bảng 2: Thông tin khách hàng đã dùng kỹ thuật che giấu

Kỹ thuật che giấu dữ liệu khá phức tạp nên rất khó để lựa chọn giải pháp thích hợp nếu không có cách tiếp cận đúng đắn. Từ các vấn đề thực tế khi triển khai kỹ thuật này trong lĩnh vực tin học ngân hàng, có thể liệt kê một số tiêu chí để lựa chọn giải pháp che giấu dữ liệu cho doanh nghiệp:
Chuyên nghiệp
Giải pháp archive hay lấy mẫu dữ liệu có thể được tùy biến, mở rộng để phục vụ nhu cầu che giấu dữ liệu nhưng chúng thường chậm hơn nhiều so với các giải pháp che giấu dữ liệu chuyên dụng. Thời gian xử lý để có được dữ liệu là một yếu tố quan trọng cần được lưu tâm, nhất là với các công việc hạn chế về thời gian.
Tạo dữ liệu giả hợp lệ
Không nên áp dụng các kỹ thuật che giấu dữ liệu khác nhau cho từng lần thực hiện. Giải pháp che giấu dữ liệu tốt cần có khả năng sinh giá trị ngẫu nhiên thay thế, xáo trộn dữ liệu,… cũng như tạo dữ liệu giả “như thật” cho các trường hợp đặc biệt như số điện thoại, mã bưu chính, địa chỉ thư điện tử, số thẻ tín dụng (với đủ các yếu tố như mã BIN, số kiểm tra)....
Hỗ trợ nhiều nền tảng và cơ sở dữ liệu
Sẽ không tốt nếu bạn cần sử dụng nhiều sản phẩm khác nhau để che giấu dữ liệu trên các hệ quản trị cơ sở dữ liệu (CSDL) khác nhau. Ngoài khả năng làm việc với nhiều loại hệ quản trị CSDL, một giải pháp che giấu dữ liệu tốt cần cung cấp đầy đủ tính năng có thể trên tất cả các hệ quản trị CSDL đó (thay vì chỉ cung cấp đầy đủ tính năng trên hệ thống hỗ trợ chính và chỉ đưa ra một tập các tính năng hạn chế trên các hệ thống khác).

Khả năng làm việc với các khái niệm về CSDL
Yêu cầu không thể bỏ qua với các giải pháp che giấu dữ liệu là có thể quản lý tốt các khái niệm như lọc (chỉ lấy các số thẻ Mastercard), nhóm (các loại thẻ), tính toàn vẹn quan hệ và tất nhiên cần có khả năng che giấu các trường khóa chính.
Cấu hình, các kịch bản chạy lô và triển khai có thể tái sử dụng
Giải pháp che giấu dữ liệu tốt cần có khả năng vận hành ổn định, không đòi hỏi chỉnh sửa cấu hình khi bạn thay đổi schema hay thậm chí là cơ sở dữ liệu. Hơn thế nữa, quá trình chuyển hóa dữ liệu phải có thể chạy theo lô, theo lịch trình định trước trên các máy chủ không có giao diện đồ họa.
Tạo dữ liệu đầu ra nhất quán
Dữ liệu đầu ra phải nhất quán (có giá trị như nhau) với mọi hệ thống/cơ sở dữ liệu. Nếu Nguyễn Văn A trong hồ sơ nhân sự của bạn được chuyển thành Lê Văn B nhưng cũng con người ấy trong CIF lại được hệ thống che giấu dữ liệu đổi thành Trần Văn C thì cần phải xem lại.
Trên đây, chúng ta đã xem xét các tiêu chí lựa chọn những giải pháp che giấu dữ liệu “cổ điển”. Có rất nhiều công ty cung cấp giải pháp che giấu dữ liệu kiểu này như Camouflage Software, DataGuise, Oracle, ... Tuy nhiên, một số ý kiến lại cho rằng cách tiếp cận của các giải pháp đó có nhược điểm là vừa chậm, vừa tạo thêm kho dữ liệu mới – buộc các doanh nghiệp phải thêm chi phí bảo vệ. Liệu có cách che giấu dữ liệu nào khác đơn giản và hiệu quả hơn không? Tính năng Virtual Private Database của Oracle 10g cũng có thể giúp chuyển những cột dữ liệu quan trọng thành khi xử lý các câu truy vấn của người dùng. Theo cách tiếp cận tương tự như vậy, khoảng đầu năm nay, IBM đã công bố giải pháp MAGEN (Masking Gateway for Enterprises) cho phép biến đổi, che giấu dữ liệu trước khi chúng xuất hiện trên màn hình của người dùng cuối. Dù rất hứa hẹn nhưng giải pháp này mới chỉ ở giai đoạn đầu và có thể chưa đạt được đủ các yêu cầu cần thiết, nhất là với những hệ thống phức tạp, yêu cầu sử dụng dữ liệu đa dạng. Trong lúc việc xác định cách tiếp cận nào có ưu thế hơn về mặt lý luận cũng như thực tiễn sử dụng chưa ngã ngũ, chúng ta cần thử nghiệm và đánh giá cẩn thận dựa trên nhu cầu và tình hình thực tế của doanh nghiệp trước khi đưa ra quyết định.
Dù chọn được giải pháp tốt đến mấy, chúng ta cũng không thể thành công nếu không hiểu rõ về dữ liệu của mình. Những vấn đề thường gặp nhất đối với dữ liệu trên mọi hệ thống là:
Tài liệu đặc tả thường được lưu dưới các dạng khác nhau ít được cập nhật, nhất là với một số trường hợp đặc biệt.
Các trường dữ liệu thường được dùng cho nhiều mục đích khác nhau và có thể tạo ra những quan hệ phi chuẩn. Khi yêu cầu nghiệp vụ phát sinh, người ta thường khắc phục bằng cách thay đổi cách sử dụng các trường phụ cho mục đích mới, chẳng hạn ghi chú có thể lưu các dữ liệu có cấu trúc như số điện thoại, số tài khoản, số tham chiếu. Quan hệ phi chuẩn giữa các trường dữ liệu có thể thấy trong các trường hợp: tên đầy đủ của khách hàng và tên rút gọn dập trên thẻ tín dụng có liên hệ với nhau nhưng không có quy tắc cụ thể, một cột lưu ngày sinh trong khi cột khác (có thể ở cùng bảng hoặc khác bảng) lại lưu tuổi.
Dữ liệu sai: khi các hệ thống khác nhau được hợp lại có thể xuất hiện nhiều dữ liệu không hợp lệ, người dùng có thể bỏ qua nếu điều đó không ảnh hưởng nhiều đến hệ thống.