Securing Automotive Logs: Data Masking with Alibaba Cloud SLS Mask Function

Regulatory Background

China's Automobile Data Security Management Regulations (Trial) Article 6 advocates desensitization, anonymization, and de-identification. For services targeting EU users, GDPR principles of data minimization and privacy by design/default also apply.

Alibaba Cloud SLS Mask Function Overview

The SLS mask function replaces matched sensitive values during log collection or ingestion while retaining business status and trace context. It works with access control and retention policies to reduce exposure. The function can be applied at the collector side (LoongCollector, SDK, OpenAPI) using buildin or keyword rules, or at the server-side write processor after logs arrive but before they are stored in the Logstore. Enterprises can choose the location based on ingestion method and processing requirements, and can combine both.

Choosing Masking Location and Identification Mode

After deciding the processing location, the identification mode is selected based on content type:

buildin – built-in rules for VIN, phone numbers, IMSI, ID cards, license plates, emails, credit cards, IP addresses, AccessKeys, API keys, etc. Supports regional variants for PHONE, IDCARD, IMSI.

keyword – matches fixed field keys (e.g., owner_name, user_id, token).

semantic – uses a model to recognize Chinese names and addresses in natural language; only available on the server side.

Multiple rules can be combined in a single mask call. The scope is determined by ingestion configuration, business conditions, and specified fields. Processed logs remain usable for query, alerting, and analysis.

Case 1: Vehicle Event Processing Log

Vehicle signals flow through a message queue to rule evaluation and cloud diagnostics. Event logs contain VIN, software version, signal values, and rule results. The same VIN may appear in both the event header and nested payload; masking must cover every occurrence.

Original Log

{
  "time": "2026-10-13T09:18:42.036+08:00",
  "level": "INFO",
  "service": "vehicle-event-processor",
  "trace_id": "demo-event-a201",
  "event": "vehicle_signal_evaluated",
  "vin": "LZZAB12C7T1006842",
  "plate_no": "粤B24680",
  "payload": {
    "vin": "LZZAB12C7T1006842",
    "signal": "coolant_temperature",
    "value": 94,
    "rule_id": "coolant_temp_guard",
    "rule_version": "r12",
    "decision": "NORMAL"
  },
  "software_version": "5.4.0",
  "mq": {
    "topic": "vehicle.signal.events",
    "partition": 3,
    "offset": 873204
  },
  "latency_ms": 21,
  "token": "demo_vehicle_token_82"
}

SPL Configuration

* | extend content = mask(content, '[
  {"mode":"buildin","types":["VIN"],"maskType":"placeholder"},
  {"mode":"buildin","types":["LICENSE_PLATE"],"keepPrefix":2},
  {"mode":"keyword","keys":["token"],"maskType":"placeholder"}
]')

Masked Result

Both the top-level vin and payload.vin become [VIN_MASKED]. The license plate becomes 粤B***** (first two characters retained). Signal value 94, decision NORMAL, rule version r12, software version 5.4.0 remain unchanged. mq.offset retains the consumption offset; latency_ms retains processing latency.

Built-in VIN recognition includes format and checksum validation. Non-standard vehicle identifiers can be handled via keyword rules. For cross-log event tracing, use evaluated event IDs or Trace IDs; placeholders and partially masked identifiers cannot serve as unique correlation keys.

Case 2: Owner Identity Verification and Vehicle Binding

User-center logs record real-name authentication and vehicle binding requests. Personal data may appear in request parameters; user identifiers may appear in both request and database query contexts. The goal is to hide personal information while preserving verification results and binding status.

Original Log

2026-10-13 09:24:16.218 INFO [owner-identity-service] trace_id=demo-owner-b018 uri=/api/owners/bind method=POST cost_ms=38 status=200
{
  "request": {
    "owner_name": "陈宁",
    "phone": "13900004567",
    "id_card": "320104199408190028",
    "user_id": "owner-demo-018"
  },
  "response": {
    "verification": "PASS",
    "binding_status": "SUCCESS",
    "code": "OK"
  },
  "query": {
    "mapper": "OwnerBindingRepository.findByUser",
    "user_id": "owner-demo-018"
  }
}

SPL Configuration

* | extend content = mask(content, '[
  {"mode":"buildin","types":["PHONE"],"keepPrefix":3,"keepSuffix":4},
  {"mode":"buildin","types":["IDCARD"],"maskType":"placeholder"},
  {"mode":"keyword","keys":["owner_name","user_id"],"maskType":"placeholder"}
]')

Masked Result

Both occurrences of user_id (in request and query) are replaced. Owner name and full ID card number no longer appear. verification=PASS, binding_status=SUCCESS, and code=OK are retained, confirming the request passed verification and completed binding. The log header's API path, Trace ID, and 38 ms latency remain intact for request tracing.

Keyword configuration must include actual key names (e.g., owner_name, userName). Retaining partial phone digits is a business choice; if manual verification is not needed, a placeholder can be used instead. The masking scope should also cover duplicate information across request, response, and query contexts.

Case 3: Overseas Subscription Status Query (Germany, UK)

For international connected-car services, logs must retain subscription status and plan details while masking phone numbers and communication subscription identifiers (IMSI) according to their actual region. Using only domestic rules may miss overseas data.

Original Log

2026-10-13 09:41:22.075 INFO [connectivity-subscription-service] trace_id=demo-connect-d005 uri=/api/subscriptions/status method=GET cost_ms=34 status=200
{
  "code": "OK",
  "subscriptions": [
    {
      "market": "DE",
      "phone": "+4915700002468",
      "imsi": "262010000345678",
      "email": "[email protected]",
      "sim_status": "ACTIVE",
      "connection_status": "CONNECTED",
      "quota_mb": 4096
    },
    {
      "market": "GB",
      "phone": "+447700900123",
      "imsi": "234100000456789",
      "email": "[email protected]",
      "sim_status": "ACTIVE",
      "connection_status": "CONNECTED",
      "quota_mb": 2048
    }
  ],
  "token": "demo_subscription_token_05"
}

SPL Configuration

* | extend content = mask(content, '[
  {"mode":"buildin","types":["PHONE","IMSI"],"regions":["DE","GB"],"maskType":"placeholder"},
  {"mode":"buildin","types":["EMAIL"],"maskType":"anchor","maskBeforeChar":"@"},
  {"mode":"keyword","keys":["token"],"maskType":"placeholder"}
]')

Masked Result

Phone numbers become [PHONE_MASKED]; IMSIs become [IMSI_MASKED]. Email addresses are masked before the @ character, preserving the domain. The token becomes a keyword placeholder. Market, connection status, and quota (4096 MB and 2048 MB) remain unchanged.

Current built-in support covers Germany (DE) and UK (GB) for phone and IMSI. The regions parameter selects recognition rules; the vehicle's sales region does not necessarily match the phone/IMSI home network, especially in cross-border roaming scenarios. Support for DE/GB does not imply coverage for all European countries, document types, or license plate formats.

Case 4: Cockpit Voice Interaction with LLM

Cockpit voice transcripts are sent to intent recognition or an LLM, which then calls tools like contacts lookup and navigation. The same name and destination may appear in the ASR text, tool results, and model response. Log masking must cover all these locations.

Original Log

{
  "time": "2026-10-13T09:48:30.906+08:00",
  "service": "cockpit-assistant-gateway",
  "session_id": "session-demo-047",
  "trace_id": "demo-cockpit-e047",
  "model": "cockpit-text-model",
  "intent": "NAVIGATE_AND_CALL",
  "asr_text": "请给林晨打电话，号码是13600007890，然后导航到杭州市西湖区示例路28号。",
  "tool_calls": [
    {
      "name": "contacts.lookup",
      "result_text": "联系人林晨，联系电话13600007890。",
      "status": "SUCCESS"
    },
    {
      "name": "navigation.search",
      "result_text": "目的地为杭州市西湖区示例路28号。",
      "status": "SUCCESS"
    }
  ],
  "assistant_text": "已找到林晨，将导航至杭州市西湖区示例路28号。",
  "llm_api_key": "sk-DemoCockpitKeyAbcdef0123456789",
  "input_tokens": 96,
  "output_tokens": 27,
  "cost_ms": 463
}

SPL Configuration

* | extend content = mask(content, '[
  {"mode":"semantic","types":["NAME","ADDRESS"],"maskType":"placeholder"},
  {"mode":"buildin","types":["PHONE","API_KEY"],"maskType":"placeholder"},
  {"mode":"keyword","keys":["token","api_key"],"maskType":"placeholder"}
]')

Masked Result

Names and addresses in asr_text, both result_text fields, and assistant_text are replaced by entity position. Phone numbers and API keys are hidden. Model name, intent NAVIGATE_AND_CALL, both tool SUCCESS statuses, input/output token counts, and total latency (463 ms) are preserved. Developers can verify intent and tool results and measure overall response time; per-stage timing requires dedicated timing fields.

Using Type Labels and Mask Preview for Privacy and Debugging

In natural language and mixed-text logs, masked output may still need to distinguish between phone numbers, credentials, etc., while retaining enough context for troubleshooting. The prependPlaceholder:true parameter adds a type tag outside the masked portion, typically outputting [TYPE_MASKED]{preview} to aid query and audit.

Example based on Case 4: names and addresses continue to use full placeholders; phone numbers and API keys retain first three and last four digits with type tags. Configuration:

* | extend content = mask(content, '[
  {"mode":"semantic","types":["NAME","ADDRESS"],"maskType":"placeholder"},
  {"mode":"buildin","types":["PHONE","API_KEY"],"keepPrefix":3,"keepSuffix":4,"prependPlaceholder":true},
  {"mode":"keyword","keys":["token","api_key"],"keepPrefix":3,"keepSuffix":4,"prependPlaceholder":true}
]')

Result: [PHONE_MASKED]{136****7890} indicates a masked phone number; the retained prefix/suffix helps verify the called party. Combined with trace_id, the call chain, tool statuses, and latencies can be inspected. The number of retained digits should be chosen based on debugging needs. The same parameter works for names/addresses: e.g., keepPrefix:1 with prependPlaceholder:true yields [NAME_MASKED]{林*}.

Mask Function Parameters Reference

The function signature is mask(field, params) where field is the string field to process and params is a JSON array string of rule objects. Key parameters:

Parameter          Purpose
mode               Required. "buildin" for built-in recognition, "keyword" for key-name matching, "semantic" for Chinese name/address (region-limited).
types / keys       "buildin" and "semantic" use "types" (e.g., VIN, PHONE, NAME, ADDRESS); "keyword" uses "keys" for business field names.
regions            Selects regional rules for PHONE, IDCARD, IMSI. Defaults to "CN". See regional support matrix below.
maskChar           Replacement character for default character masking and anchor masking. Default "*".
keepPrefix / keepSuffix  Number of prefix/suffix characters to keep in default character masking. Default 0.
maskType           Omitted → character masking; "placeholder" → replace with placeholder; "anchor" → mask up to a specified character.
maskBeforeChar     Used with "anchor". In Case 4 set to "@" to mask email local part, keep @ and domain.
prependPlaceholder Optional boolean, default false. When true, adds type label outside masked result (e.g., [PHONE_MASKED]{136****7890}).

Built-in Types and Regional Support

Only PHONE, IDCARD, and IMSI support regional switching; other types use fixed rules. The following matrix shows current support ("—" means no built-in rule yet).

Region Code | Country/Region | PHONE | IDCARD | IMSI
CN          | China Mainland | Yes   | Yes    | Yes
HK          | Hong Kong      | Yes   | Yes    | Yes
DE          | Germany        | Yes   | —      | Yes
GB          | United Kingdom | Yes   | —      | Yes
AE          | UAE            | Yes   | —      | Yes
SA          | Saudi Arabia   | Yes   | —      | Yes
SG          | Singapore      | Yes   | —      | Yes
KZ          | Kazakhstan     | Yes   | Yes    | —
UZ          | Uzbekistan     | Yes   | Yes    | —
RU          | Russia         | Yes   | —      | —

Other built-in types (VIN, LICENSE_PLATE, LANDLINE_PHONE, EMAIL, CREDIT_CARD, IP_ADDRESS, ACCESSKEY, API_KEY) do not use regional selection.

References

[1] https://www.cac.gov.cn/2021-08/20/c_1631049984897667.htm - Automobile Data Security Management Regulations Article 6

[2] https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en - GDPR Principles

[3] https://developer.aliyun.com/article/1748652 - Plaintext Not Spread, Logs Still Usable: Alibaba Cloud Observability Sensitive Data Protection Solution