How to Implement Enterprise-Scale Data Encryption: Lessons from Huolala

Background

With growing importance of data and network security, laws such as the Cybersecurity Law and Personal Information Protection Law require enterprises to encrypt sensitive data. While encryption functions exist in most programming languages, applying encryption at massive scale involves considerations of security, stability, and cost.

Data Research

The first phase involved surveying service languages, storage components, and the distribution of sensitive data to define the encryption scope. Common enterprise languages (Java, PHP, Go, Python) and storage types (structured vs unstructured, persistent vs transient) were identified, and sensitive data assets were cataloged with a focus on personal information.

Solution Selection

Security, architecture, CI, and DBA teams jointly evaluated options, assessing risks from multiple perspectives. Two main approaches were compared:

Application‑layer encryption : unified sensitive‑information service and per‑service encryption, offering flexibility but requiring significant development effort.

Database‑proxy encryption : encrypt/decrypt data via SQL parsing at the database layer, reducing application changes but incurring higher performance overhead under high concurrency.

After weighing pros and cons, the team favored per‑service application‑layer encryption as it posed fewer performance bottlenecks despite higher development cost.

Encryption Transformation

The transformation focused on three areas: key management, encryption algorithms, and encryption techniques.

Key Management

Commercial KMS services using hardware security modules (HSM) were adopted to avoid hard‑coding keys. A dual‑key model (Data Key DK and Key Encryption Key KEK) was employed. The encryption process creates a plaintext DK, encrypts it with KEK to produce a ciphertext DK, uses the plaintext DK to encrypt data, and stores both ciphertext data and ciphertext DK. Decryption reverses these steps.

Encryption Algorithms

Secure algorithms such as national standards, AES, and RSA were selected based on workload characteristics—symmetric algorithms for high‑volume data, asymmetric for small data or signatures.

Encryption Techniques

Implementation options included:

Providing a unified encryption SDK for developers.

Offering an encryption component (e.g., MyBatis interceptor) to automatically encrypt/decrypt SQL parameters and results.

Optimizing the component to modify original SQL, enabling automatic handling of both incremental and legacy data, consistency checks, gray‑scale reads, and bidirectional comparison.

This component‑based approach aims to achieve “no‑code‑change” migration for many services.

Incremental Control

Risk monitoring is divided into three stages:

Pre‑development : security awareness and guidelines in development manuals.

Pre‑release : database audit of CREATE/ALTER statements to detect unencrypted sensitive fields.

Production : periodic asset scans to identify and remediate missed encryptions.

Metrics

Quantitative indicators such as encryption coverage (tables, fields, data volume) are tracked, considering detection accuracy and recall. Additional metrics address empty‑field detection after clearing plaintext data.

Conclusion

Data encryption is a long‑term, cross‑functional effort that requires coordinated planning, robust key management, appropriate algorithm selection, and systematic monitoring to enhance overall security posture.