明文不扩散，日志仍可用：阿里云可观测敏感数据保护方案

作者孙玉梅AI Agent 让日志中的敏感数据更多、更复杂。除手机号、IP、API Key 等传统字段外AI Coding Agent、RAG 应用和运维 Agent 还会读取代码、配置、环境变量与数据库连接串并将工具调用、终端输出和模型回复写入审计日志敏感信息因此更容易进入日志链路。这些数据又不能简单丢弃因为它们是排障、审计和治理的重要依据。为兼顾安全与可用性阿里云可观测提供贯穿采集、写入和加工环节的保护方案数据入库前可脱敏或加密入库后也可进一步加工形成适合长期留存和共享分析的安全数据集。下面先看整体方案再展开不同方式的落地场景。少暴露、不减值保护敏感数据贯穿全链路SLS 的敏感数据保护方案可以拆成两个简单问题敏感内容用什么方式保护保护动作放在数据链路的哪一站执行。前一个问题对应脱敏、对称加密和信封加密后一个问题对应端上处理、写入处理器和数据加工。两类选择可以灵活组合同一种保护方式既可以放在采集侧也可以放在写入前或入库后同一个处理位置也可以根据数据风险选择脱敏或加密。客户可以按数据来源、合规要求和后续分析方式选择组合要求明文不出主机时优先端上处理多来源直写时使用写入处理器集中治理需要长期共享或存量治理时再通过数据加工生成受保护 Logstore。按使用需求选择不同类型的敏感数据不需要用同一种方式处理。SLS 在数据处理中提供脱敏、对称加密和信封加密三类SPL 函数分别对应“保留可读性”“授权可还原”和“职责分离”的安全诉求。脱敏保留可读性降低隐私风险mask适合处理散落在文本中的 PII 或凭证类字段。它支持两类匹配方式buildin内置手机号、邮箱、身份证、银行卡、IP、固话、AccessKey、车牌、IMSI、VIN 等规则keyword按字段名或键名匹配如password、token、authorization、api_key。打码方式可以是占位符也可以保留前后缀。例如手机号保留前三后四既保护隐私也便于排障时与业务侧做模糊核对。脱敏后的日志仍可读、可查、可聚合适合作为大多数日志场景的首选具体使用方式参考帮助文档 。典型场景包括AI 网关 prompt 中散落手机号、邮箱、身份证应用访问日志中的客户端 IP、鉴权 tokenLLM 应用日志中的银行卡号、地址、用户标识。对称加密密文落库授权还原aes_encrypt适合“后续需要还原但密钥归属清晰”的场景。例如内部 RAG 问答、模型请求、客户方案等内容落库时可以是密文授权审计时再由持有 Key IV 的团队还原。如果采集、分析和审计都在同一团队内Key IV 可以统一管理对称加密是简单且高性能的选择。它的边界也很清楚密钥一旦共享出去所有持有者都具备解密能力因此适合同组织、同安全域内部使用不适合跨团队广泛分发。信封加密公私钥分离适合高敏协作envelope_encrypt适合采集方和解密方分离的场景。它采用信封加密机制随机生成 DEK 加密业务数据再用非对称公钥加密 DEK。采集侧只配置公钥私钥由安全或审计团队单独保管。这类模式适合高敏字段例如AI Coding 工具读取文件后的完整返回命令执行输出含密钥、连接串、配置文件的整段日志。信封加密的另一个优势是性能可控。DEK 在 pipeline 级别生成非对称加密只作用于 DEK业务数据仍由 AES 处理避免对采集吞吐造成过大影响。保护方式和处理位置不是固定绑定的。下文按数据流依次展开三个位置每个位置只挑一个代表性方式举例并不代表该位置只支持这一种。端上保护让明文不出采集侧在更严格的合规场景里敏感数据保护需要下沉到采集侧日志刚被采集就已经完成处理明文不出主机、不出容器也不进入后续传输链路。端上保护可以分成两类一类是 LoongCollector 面向主机/容器日志的采集时处理另一类是 LoongSuite Pilot 面向 AI Coding Agent 的端侧隐私控制。二者解决的问题不同但目标一致在数据离开采集侧之前先控制明文扩散。LoongCollector采集即处理业务无需改造备注本文涉及所有姓名、手机号、邮箱、公钥、私钥等敏感数据皆为虚构生成数据对于部署在 ECS、ACK、IDC 主机或容器中的应用LoongCollector 不只是采集器也可以在采集时执行 SPL。AI 网关、百炼应用、RAG 服务、模型代理层等组件通常会输出大量访问日志和交互日志其中既有结构化字段也有用户输入的自然语言内容。把处理放在采集侧可以显著降低明文扩散面。以 AI 网关访问日志为例一条原始日志可能包含调用方 IP、API Key 和用户 promptmodelqwen-max client_ip203.0.113.55 prompt我是张某手机号138xxxxxxxx邮箱zhangweixxxx.com帮我查最近订单 tokens128在 LoongCollector 采集配置中可以用mask同时处理内置 PII 和关键字字段写入 SLS 后日志仍然能用于模型调用量、Token 用量、网关访问趋势分析但敏感值已经被替换这类方案适合业务应用日志、网关日志、模型代理日志等主机/容器侧数据。它的优势是无需修改业务代码采集配置里完成处理日志写入 SLS 时已经是脱敏后的安全形态。LoongSuite PilotAI Coding 数据先脱敏再分发端上方案的另一个典型场景是 AI Coding 审计。开发者本机运行的 Coding Agent 经常会接触项目源码、配置文件和本地环境变量。开发者在提问时粘贴一段配置或者 Agent 读取.env文件后把内容写入工具调用参数都可能让 API Key、云厂商 AK/SK、私钥等数据进入采集链路。LoongSuite Pilot面向这类端侧 AI Coding 场景负责发现并采集 Claude Code、Cursor、Codex、Qoder 等工具的活动数据归一化为会话、工具调用、模型调用、Token 用量等审计事件。同时Pilot 内置基于规则的自动脱敏引擎在数据分发给任何输出通道之前统一扫描并替换敏感内容。开启后无论数据输出到 SLS、JSONL、HTTP 还是 OTLP脱敏规则都会统一生效。Pilot 的自动脱敏覆盖以下常见凭据类型脱敏类型覆盖范围替换标记云 AccessKey阿里云 LTAI、AWS AKIA/ASIA、腾讯云 AKID[ACCESSKEY_MASKED]API KeyOpenAI 兼容sk-、GitHub PATghp_/gho_/ghs_[APIKEY_MASKED]数据库连接串MySQL/PostgreSQL/MongoDB/Redis URI、带密码的 JDBC[DATABASEURL_MASKED]私钥PEM / OpenSSH 私钥块[PRIVATEKEY_MASKED]例如一次 AI Coding 会话中Agent 读取本地.env文件后产生如下工具返回DB_URLmysql://root:Abc2025!10.0.0.12:3306/prod ALIYUN_AKLTAI5tFakeExampleKey0001 -----BEGIN RSA PRIVATE KEY----- MIIEvQIBADANBgkqh... -----END RSA PRIVATE KEY-----Pilot 在输出前完成自动脱敏后写入 SLS 的内容会变成脱敏通过mask.mode配置开关控制支持none、all、custom三种模式默认关闭。开启后敏感凭据不会原样进入后续输出通道而session_id、tool_name、Token 用量、执行耗时等审计元数据仍然保留研发管理和安全团队可以继续分析 AI Coding 的使用情况、工具调用风险和成本分布。综上端上保护适合三类客户诉求明文不能离开业务主机或开发者本机采集链路跨网络、跨团队明文传输风险不可接受希望在不修改业务代码的情况下把敏感数据保护前置到日志产生的第一站。写入前保护直写数据入库前统一治理并不是所有数据都会经过 LoongCollector。很多系统通过 SDK、WebTracking、OpenAPI 或第三方采集链路直接写入 SLS。对于这类数据写入处理器提供了服务端统一治理能力数据到达 SLS 后、写入 Logstore 前先执行 SPL 完成脱敏或加密。写入处理器的优势在于集中配置。规则放在 SLS 侧客户端不需要逐一升级当处理策略变化时只需要调整处理器配置就能覆盖所有直写数据。对于多业务线、多语言 SDK 或第三方系统上报的场景这种方式更容易落地。以 AI 网关的访问日志为例网关把每次模型调用拼成一行、用##分隔后直接写入 SLS。其中request字段是完整的模型请求体可能夹带用户 prompt、身份证号等任意敏感内容其余字段则是结构化的调用元数据2026-06-25 11:17:25.471##c9d7ab4c-b312-9d08-9243-c7f7475905be##5000000276111136##API_KEY##qwen-max##text-generation##{input:{prompt:我的身份证号是53010219200508011x帮我查询保单状态}}##chat-app##3de69809a9d0fd22773f33c77dab12a8这里的request是整段、非结构化的请求体。这个示例选择对request做对称加密重点展示写入处理器如何在入库前统一处理直写数据先按分隔符拆出字段再单独对高敏正文执行aes_encrypt。在写入处理器中加密高敏请求体写入处理器 SPL 配置* | extend temp split(content, ##) | extend time temp[1], request_id temp[2], caller_uid temp[3], source temp[4], model temp[5], api_type temp[6], request temp[7], service_name temp[8], trace_id temp[9] | extend request to_base64(aes_encrypt( cast(request as binary), cast(aZ4kP9mX2qL7nR1t as binary), cast(Gh8dW3sB6vN0cT5e as binary))) | project-away content, temp入库后request变成 Base64 密文而request_id、region、model、service_name、trace_id等调用元数据仍是明文运维可以靠request_id、trace_id排查链路运营可以按model、service_name统计调用量而真正的请求正文已经是密文。授权场景下按需还原需要还原时由持有 Key IV 的团队成员在查询时解密数据加工面向共享分析生成安全数据集端上处理和写入处理器解决的是“入库前保护”。数据加工解决的是另一个问题已经进入 Logstore 的数据如何重新组织成更安全、更适合长期分析的数据集。在实际项目中很多团队会保留两个 Logstore原始 Logstore保留时间短访问权限严格仅用于紧急排障或安全调查受保护 Logstore由数据加工任务生成敏感字段已脱敏或加密保留时间更长面向更大范围的分析和审计。这种模式特别适合 AI 观测数据。以 LoongSuite Pilot 采集的 AI Coding如 Qoder活动日志为例每条llm.response事件都带着一批结构化元数据会话 ID、模型、用户 ID 等以及一个gen_ai.output.messages字段——它是模型本轮回复的完整正文可能夹带内部系统名、主机信息、配置或密钥等任意敏感内容{ event.name: llm.response, gen_ai.session.id: 58bf461a-285f-468e-963c-00cd1706a9d9, gen_ai.provider.name: qwen, gen_ai.response.model: auto, user.id: 1, gen_ai.output.messages: [{role:assistant,parts:[{type:text,content:已整理候选人薪资表张某手机号138xxxxxxxx...}],finish_reason:end_turn}], trace_id: a58ed78ac2573159b4fa8b38ab4c2697, __time__: 1782367255 }gen_ai.output.messages是整段、结构不固定的模型回复逐字段脱敏难以覆盖全部风险真正排查问题时又可能需要还原原文。这个示例选择信封加密重点展示数据加工如何先派生分析字段这里取回复长度msg_len再对高敏正文加密后写入受保护 Logstore* | extend msg_len length(gen_ai.output.messages) | extend result envelope_encrypt( cast(gen_ai.output.messages as binary), -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Vh1QIpNurP0bB9uHRK3 ZL29SjY74OtYa5nmf9xUMKAuLrio5BN6LRZyG680uCkCThCMOK/T9ka5ZYtEIu8b U7acNR1dL3LWsbZG3ScbqyISJ3pEBli2rCgOqBQK3EE6HGavh6wo8FAhkSBiryU eVKxSJSnC928RvlBWtyfdubVYQHPONhx0TbCj38Njjfi8kbKGgE92q9gTlLspge qvgDec9GV2VzxhLoTgxd6jdHYyfFzuQucb0hZtmWqus4E4MTnAXnUJOGizmI02AP 5d49P44kZXElBPRw4A0WISKBmwOzYCZqPSEWyHnj/qIaXAbz90B8TCUiPZlNouCG TwIDAQAB -----END PUBLIC KEY-----, {mode:RSA}, {mode:CTR}) | extend encrypted_dek result[encrypted_dek], enc_output_messages result[encrypted_data] | project-away gen_ai.output.messages加工后写入受保护 Logstore 的记录里gen_ai.output.messages已被移除取而代之的是密文enc_output_messages和被公钥加密的encrypted_dek其余元数据保持明文这样做后受保护 Logstore 中保留了事件类型、会话 ID、模型、用户 ID、回复长度等分析字段仍然可以做告警、趋势统计和风险排查真正的模型回复正文则变成密文。需要深度调查时由持有私钥的安全人员解密指定记录。这也是加密与可分析性之间的平衡点不要把所有字段一股脑加密而是在加密前抽取必要的分析元数据只对高敏正文加密。日常分析依赖元数据敏感原文通过授权解密受控访问。如何选择看明文边界、分析诉求和解密权限落地时可以按三个问题做选择。第一明文能不能离开采集侧如果不能优先把处理放到端上。第二日志是否还需要日常阅读和分析如果需要优先保留可读性只有当内容整体高敏、无法可靠局部处理时才考虑加密。第三谁有权解密同团队、同安全域内可以统一管理密钥跨团队或职责分离场景应让解密权限由安全或审计团队独立掌握。可以把策略总结为一张表场景推荐位置推荐方式主机/容器中的 AI 网关日志要求明文不出主机LoongCollector 端上mask脱敏必要字段加密SDK 或第三方系统直接写入 SLS写入处理器写入前mask或加密已有历史日志需要治理数据加工消费源库后脱敏/加密写新库内部 RAG 问答内容需可控还原端上或写入处理器aes_encrypt对称加密工具返回、配置文件等整段高敏内容端上或数据加工envelope_encrypt信封加密安全与可用可以同时兼顾日志的价值在于可观测、可分析、可追溯敏感数据保护的目标不是让日志失去价值而是让日志在安全边界内继续发挥价值。SLS 把脱敏和加密能力前置到采集、写入和加工链路中帮助企业在控制明文扩散面的同时保留必要的分析能力。最终企业可以按数据类型选择脱敏或加密按数据链路选择端上、写入前或加工后处理按密钥归属选择对称或信封在“数据可用”和“数据安全”之间建立清晰、可执行的边界。