Grok解析规则若未同步配置敏感字段过滤，会导致身份证号、手机号等明文泄露，违反《个人信息保护法》第40条；须在grok{}后用mutate→gsub对phone、id_card等字段就地脱敏，并验证匹配与未匹配场景。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在日志系统或API网关中接入Grok解析规则时，若未同步配置敏感字段过滤，身份证号、手机号等原始信息会直接写入日志或透传至下游服务，触发《个人信息保护法》第40条合规风险——这类泄露往往发生在调试阶段被忽略，上线后才被审计发现。
确认Grok解析字段是否暴露原始敏感值
打开你的SLS或Logstash配置文件，定位到使用grok{}插件的filter段，检查pattern中是否包含%{NUMBER:phone}、%{NOTSPACE:id_card}这类未脱敏的捕获组。如果存在，说明Grok已提取出明文手机号或身份证号，但尚未做任何掩码处理。
这一步必须做，否则后续所有脱敏动作都无效——Grok提取后的字段会进入pipeline下游，哪怕你后面加了regex_replace，也只作用于新生成的字段，原字段仍以明文形式存在于event中。
用regex_replace对Grok提取字段做就地脱敏
方法一：针对已提取的手机号字段（如phone）
在grok{}之后添加mutate{}块，使用gsub对phone字段执行正则替换：gsub => ["phone", "^(\d{3})\d{4}(\d{4})$", "$1****$2"]。注意必须用^和$锚定整字段，否则可能只替换中间一段数字。
方法二：针对身份证字段（如id_card）
身份证脱敏需保留前6位+后4位，不能简单星号替换。使用：gsub => ["id_card", "^(\d{6})\d{8}(\d{4})$", "********"]。【前6后4是金融行业强制要求，硬编码不可省略】
方法三：批量处理多个字段
若同时有phone、id_card、email三个字段需脱敏，可合并为一个mutate→gsub，避免重复调用插件开销：
gsub => [ "phone", "^(\d{3})\d{4}(\d{4})$", "$1****$2", "id_card", "^(\d{6})\d{8}(\d{4})$", "$1********$2", "email", "^([^@]+)@(.+)$", "$1***@$2" ]
验证脱敏效果并阻断未匹配字段
第一步：向测试端点发送含敏感信息的原始日志，例如{"msg":"用户张三，身份证110101199003072315，电话13812345678"}。
第二步：在Kibana或SLS控制台搜索该日志，确认phone字段显示为138****5678、id_card字段为110101********2315、email字段为a***@b.com格式。
第三步：手动构造一条不匹配任何grok pattern的日志（如纯文本无结构），观察其是否被漏放——若未匹配grok，则不会进入后续mutate流程，原始敏感信息将直通。此时必须在input层加一层filter，用if判断[message]是否含数字串，再触发通用脱敏逻辑。
第四步：启用Grok的named_captures_only选项，防止未命名捕获组（如%{NUMBER}）意外提取并暴露敏感数字序列。
