Apache ShardingSphere Data Masking: Architecture, Scenarios, and Implementation Details

Abstract Security control is a crucial part of governance, and data masking falls under this category. For internet companies and traditional industries, data security is a highly sensitive topic. Data masking transforms sensitive information according to masking rules to protect privacy.

Background In real business scenarios, development teams often need to implement and maintain their own encryption systems to meet security department requirements. When masking requirements change, these systems face reconstruction risks. Moreover, existing services need a transparent, low‑risk way to apply masking without altering business logic or SQL.

Apache ShardingSphere offers a complete, secure, transparent, and low‑cost data masking solution that addresses these pain points.

ShardingSphere Overview Apache ShardingSphere is an open‑source distributed database middleware ecosystem consisting of Sharding‑JDBC, Sharding‑Proxy, and the planned Sharding‑Sidecar. It provides standardized data sharding, distributed transactions, and governance, suitable for Java homogenous, heterogeneous languages, containers, and cloud‑native environments.

The data masking module is a sub‑function of ShardingSphere’s distributed governance. It parses user SQL, rewrites it according to masking configurations, encrypts the original data, and stores both plaintext (optional) and ciphertext in the underlying database. During queries, it decrypts ciphertext and returns the original data, making the masking process automatic and transparent.

Requirement Scenarios There are two typical scenarios: (1) New services where sensitive fields (e.g., bank account, phone number) must be encrypted before storage; (2) Existing services that stored plaintext and now need masking without changing SQL or business logic. The latter involves handling historical data, masking new data transparently, and safely migrating between plaintext and ciphertext.

Architecture Encrypt‑JDBC is deployed together with business code. Business applications interact with the database through Encrypt‑JDBC, which implements all JDBC interfaces, requiring no code changes. Users only need to provide masking rules.

Encrypt‑JDBC intercepts SQL, parses it, identifies fields that need masking based on the provided rules, applies the configured encryptor, and forwards the transformed SQL to the underlying database. It stores ciphertext and optionally plaintext, and decrypts ciphertext on read.

Masking Rules Masking configuration consists of four parts: data source configuration, encryptor configuration (e.g., AES, MD5), table masking configuration (cipherColumn, plainColumn, logicColumn), and query property configuration (whether to return plaintext or decrypted ciphertext).

Masking Process Example: a table t_user has pwd_plain (plaintext) and pwd_cipher (ciphertext) columns, with logicColumn set to pwd. Users write INSERT INTO t_user SET pwd = '123'. ShardingSphere maps the logical column to the appropriate physical columns, encrypts the value, and stores it accordingly. During queries, it decrypts the ciphertext and returns the original value.

Conclusion Apache ShardingSphere offers full‑stack data masking solutions for both new and legacy services, enabling seamless, transparent, and secure migration of sensitive data without modifying business code. The next article will detail the complete solution.