How 58 Daojia Secures Data in the DT Era: Threats, Practices, and Lessons

Security Landscape in the Data‑Technology (DT) Era

Data has become the core asset for enterprises, driving cross‑industry services such as sensor‑enabled shared bicycles and on‑demand logistics. The rapid expansion of data volumes has led to frequent data‑leak incidents; 2018 statistics show monthly breaches across multiple sectors. At the same time, national and international data‑security regulations have tightened, making data protection a mandatory compliance requirement.

Enterprise Data‑Security Threats

Research by the Polomon Institute (2018) identified internal threats as the largest source of data‑security incidents. For a platform that connects service providers (e.g., housekeepers, babysitters) with families, the following threat vectors are critical:

Malicious intrusion from external attackers.

Privileged IT accounts (DBA, BI, operations) with broad data access.

Business staff who handle large volumes of plaintext data.

Partners who receive plaintext data based on granted permissions.

Data‑Security Architecture Implemented at 58 Daojia

Security was built on a solid foundation (network segmentation, host hardening, least‑privilege networking) before adding data‑centric controls.

Five‑step data‑centric framework

Data discovery : Automated scanning of databases, object stores, and file systems to locate repositories that contain sensitive information.

Data classification : Automatic tagging of discovered assets (e.g., PII, financial, credential) using pattern‑matching rules and statistical models.

Access control : Integration of HR, SSO, permission‑management, and business systems. Role‑based access is assigned at onboarding and revoked at off‑boarding.

Monitoring & auditing : Collection of logs from bastion hosts, MySQL binlog, Gltlab, Nginx‑Lua, SSO, AMS, VPN, and web‑behavior sources. Sensitive‑operation events are filtered, correlated, and fed into a SOC for real‑time alerting and automated response.

Incident response : Detected violations trigger immediate action (e.g., firewall block, session termination) and generate forensic traces for post‑mortem analysis.

Automation replaced manual discovery; a custom data‑discovery tool continuously updates asset inventory and applies sensitivity labels. Identity federation across HR, SSO, and permission platforms ensures that role changes propagate instantly.

The monitoring platform detects activities such as unauthorized data reads, abnormal logins, or policy violations and can automatically invoke firewall rules or other defensive measures.

Technical components

Log aggregation from bastion, binlog, Gltlab, Nginx‑Lua, SSO, AMS, VPN, and web‑behavior sources.

Rule engine built on Elasticsearch; alerting implemented with ElastAlert (open‑source) for log‑based detection.

Security Operations Center (SOC) receives enriched alerts and orchestrates response actions.

Production database credentials are protected by network‑zone isolation, a unified deployment platform, and a key‑center service that substitutes passwords with short‑lived keys, enforcing whitelist‑only connections.

Key Operational Lessons

Service‑oriented supervision : Security teams should act as trusted service providers, building collaborative relationships with business units.

Cross‑department coordination : Early planning and clear communication are essential for projects that require support from operations, data engineering, or compliance.

Fundamentals first : Robust basic security (network, host, identity) must precede advanced data‑security initiatives.

Governance + technology : Technical controls need accompanying policies, procedures, and clear accountability.

Fit‑for‑purpose solutions : Simple statistical rules can replace heavyweight AI models when data volume is limited.

Implementation Details Highlighted in Q&A

Alert rule creation : Collect public breach cases, internal audit findings, and business scenarios; draft rules covering data‑exfiltration, privilege escalation, and abnormal access patterns. Start with low thresholds and refine based on historical data.

Log‑based alerting : Use Elasticsearch as the log store and ElastAlert for rule definition. Example rule (in elastalert.yaml) filters for “SELECT * FROM *” queries originating from non‑privileged IP ranges and triggers a Slack notification.

type: frequency
name: suspicious_sql_query
index: logs-*
num_events: 5
timeframe:
  minutes: 10
filter:
- query:
    query_string:
      query: "SELECT * FROM" AND NOT "admin_ip"
alert:
- slack
slack:
  slack_webhook_url: "https://hooks.slack.com/services/..."

Measuring security ROI : Quantify prevented incidents (e.g., number of unauthorized reads blocked), estimate potential loss avoidance, and compare against cost of tools and personnel.

Data‑masking strategy : Classify fields as fully masked, partially masked, or reversible encryption. Apply dynamic masking at the application layer for real‑time queries and static masking for data extracts.

Protecting production DB credentials : Enforce strict network zones, require deployment through a centralized platform, and replace passwords with short‑lived keys managed by a key‑center service. Connections are whitelisted, preventing developers from direct access.

Additional safeguards : Watermarking of exported screenshots, rate‑limiting of sensitive‑field queries, and continuous audit of permission changes.