数据分类方案设计

以下方案面向以客户为数据主体的组织，提供一套可操作的数据分类与管控框架，用于统一识别、标记、保护与治理客户数据，满足安全与合规要求并支撑业务使用。

一、目标与范围
- 目标：以风险为导向，区分客户数据敏感性与重要性，明确相应的安全与合规管控，支撑最小必要使用、可审计、可追溯与合规处置。
- 范围：覆盖结构化与非结构化数据（数据库、数据仓库、日志、文件、邮件、音视频、图像/OCR、消息与文档协作系统）、生产与非生产环境、内部与外部共享、跨境流转与备份。

二、分类层级与定义（安全敏感性主维度）
- L0 公共（Public）：对外公开且无识别风险的数据。示例：已发布的官网内容、公开的产品说明。
- L1 内部（Internal）：仅限内部使用、不可对外公开，但不包含个人信息或敏感要素。示例：非客户级汇总指标、内部运营报表（不可识别个人）。
- L2 受限-个人信息（PI）：可直接或间接识别自然人的信息，未达敏感级。示例：姓名、手机号、邮箱、客户ID、设备ID、Cookie、地址（非精准定位）、行为事件与偏好标签（可链接个人）。
- L3 严格-敏感个人信息（SPI）：一旦泄露或非法使用，易导致人格尊严受侵害或人身财产安全受损的信息。示例：身份证/护照/社保号、银行卡号/PAN与CVV、账户认证凭证（密码/私钥/OTP种子）、精准定位（如经纬度与出行轨迹）、生物识别（人脸/指纹/声纹）、医疗健康、未成年人（14岁以下）信息、金融交易详情、宗教/种族等特别类别数据。

补充原则：
- 可逆匿名/假名化数据仍按源级分类（PI/SPI）；仅在经验证不可逆匿名化且重识别风险可接受时可降级为L1。
- 不确定时从严分类（上收一档）。

三、数据类型与示例映射（选摘）
- 身份标识：姓名、证件号（L3）、客户号（L2）
- 联系方式：手机号、邮箱、住址（L2）
- 账户与支付：银行卡号/PAN、账户号、支付令牌（L3）；交易摘要（视粒度 L2/L3）
- 行为与偏好：浏览/点击/APP事件、渠道偏好、营销触达记录（L2）；精准定位（L3）
- 认证与安全：密码/哈希、密保、会话令牌、设备指纹（L3）
- 影像与音频：工单录音、身份证影像、人脸图像（L3）；普通客服聊天记录（含PI时 L2）
- 特殊类：健康、未成年人、宗教/种族（L3）
- 衍生/模型特征：可关联到个人的打分/画像/风险分（L2/若涉及敏感维度则L3）

四、分级管控要求（按最高级别执行）
- 访问控制
  - L0：可公开；无登录要求。
  - L1：企业账号访问；RBAC；按岗位最小授权。
  - L2：审批制访问（数据Owner审批）；RBAC+ABAC（基于用途/项目/地域）；定期（季度）复核；导出需审计。
  - L3：双人审批/临时授权；零信任与强认证（MFA）；按字段/行级细粒度控制；严禁批量外发。
- 环境隔离与脱敏
  - L2：非生产环境强制脱敏/假名化；仅限最小子集。
  - L3：禁止在非生产环境使用真实数据；必要时使用不可逆合成数据或双向不可逆脱敏/代币化。
- 加密与密钥
  - L1-L3：传输TLS 1.2+；静态加密AES-256。L3使用HSM或KMS分级密钥，密钥轮换≤12月。
- 日志与审计
  - L2：访问/导出/共享全量审计，保存≥1年。
  - L3：保存≥3年；异常访问实时告警；高风险操作需事后复核。
- 数据丢失防护（DLP）
  - L2：邮件/网关/端点规则检测PI，敏感字段遮盖。
  - L3：阻断高风险外发通道；仅白名单共享；水印与可追溯标记。
- 共享与第三方
  - L2：签署数据处理协议（DPA），最小字段出数，接口限速/脱敏。
  - L3：开展隐私影响评估（PIA）与安全评估；采用代币化或安全多方方案；严格审计与回收。
- 备份与恢复
  - L2/L3：备份同等加密；跨域/跨境恢复需重新评估。
- 处置
  - L1-L3：到期自动删除或不可逆匿名化；介质销毁可审计留痕。L3需双人复核处置记录。

五、合规模型对齐（非穷尽）
- 中国《个人信息保护法》（PIPL）：区分个人信息与敏感个人信息；最小必要、明确目的、同意/合同等合法性基础；未成年人（<14）需监护人同意；跨境传输需安全评估/标准合同/认证等。
- GDPR：PI与特殊类别（健康、种族、宗教、基因、生物特征等）；数据主体权利；数据保护影响评估（DPIA）；数据最小化与保存期限限制。
- PCI DSS：涉及PAN/CVV等归L3，需加密、截断展示、密钥分离与严格访问控制。

六、元数据与标签体系（在数据目录/资产中统一登记）
为每个数据资产/字段维护至少以下元数据：
- classification_level: L0/L1/L2/L3
- pii_category: none/PI/SPI
- data_domain: 客户/交易/营销/客服/风险等
- subject_category: 客户/潜客/未成年人/员工/第三方
- residency_region: CN/EU/US/...（用于数据在境内存储要求）
- cross_border_restriction: yes/no/条件
- lawful_basis: 同意/合同/法定/合法利益（依据地区法域）
- consent_flag与consent_id: 是/否及证据指针
- retention_class与retention_period: 策略ID与期限
- data_owner与data_steward: 责任人
- system_of_record与lineage: 源系统与血缘
- quality_criticality: 高/中/低（关键数据要素标识）
- masking_policy与dlp_policy: 脱敏与DLP策略引用

七、分类判定规则（决策逻辑）
- 若包含SPI示例（证件号、银行卡号、凭证、精准定位、生物识别、健康、未成年人、宗教/种族等）→ L3。
- 否则，如可直接/间接识别个人（姓名+联系方式、设备ID、可链接事件数据等）→ L2。
- 经验证的不可逆匿名化且重识别风险可接受的汇总/统计 → L1。
- 对外已公开并不含PI/SPI → L0。
- 默认从严：不确定或混合场景取最高级别；派生数据沿用源数据最高级别。

八、保留与生命周期（示例，需法务确认后固化为企业保留表）
- 一般客户主数据（L2）：业务关系终止后保留5年或依据监管更短/更长者优先。
- 交易与对账（可能L3）：满足财税/反洗钱要求，通常7-10年（依司法辖区）。
- 同意与授权记录：处理存续期+3年。
- 客服录音/文本（L2/L3）：12-24个月（如无争议保留需求）。
- 未成年人数据（L3）：最短必要，目的达成即删除。
- 触发器：超期自动清理；法律保全（Legal Hold）优先于删除；归档经去标识与访问限缩。

九、角色与职责
- 数据Owner（业务域负责人）：资产定级、授权审批、共享决策、保留策略。
- 数据Steward（数据管理员）：元数据维护、质量规则、日常审计与整改跟踪。
- 隐私官/法务：合法性基础审查、PIA/DPIA、跨境与合同条款。
- 安全与平台团队（Custodian）：加密、访问控制、日志与DLP技术实施。
- 审计与合规：定期评估与取证。

十、例外与复核
- 例外管理：需Owner+隐私官审批，明确范围、期限与补偿性控制，登记与审计。
- 周期复核：至少每年一次或系统重大变更后进行再定级；抽样核查标签准确率≥95%。

十一、实施路线（建议）
- 阶段一：资产盘点与基线定级（目录建立、关键系统优先：CRM、支付、客服、数据湖）。
- 阶段二：策略落地（RBAC/ABAC、字段级脱敏、非生产合成数据、加密与密钥治理）。
- 阶段三：自动化识别与检测（基于规则/模型的PI/SPI扫描、DLP、数据血缘与影响分析）。
- 阶段四：闭环治理（质量规则、违规告警处置SLA、权限周期复核、共享审批工作流）。
- 工具建议：数据目录/治理平台（如企业数据目录）、数据发现与分类扫描、密钥管理KMS/HSM、细粒度访问控制（列/行级）、DLP、权限审计与日志分析。

十二、度量指标（KPI）
- 覆盖率：已定级资产/字段占比（目标≥95%）。
- 准确率：抽样复核一致率（目标≥95%）。
- 违规事件：DLP阻断/告警趋势、未授权访问次数。
- 权限健康：过期/闲置高敏权限清理率，权限复核完成率。
- 时效性：数据主体请求（访问/更正/删除）平均处理时长与合规达标率。
- 生命周期：到期数据自动处置达成率。

本方案可作为企业级数据分类政策与标准的基础。建议结合组织所处行业与法域，由法务与隐私团队校准敏感类别清单与保留期限，并在关键系统内以技术控制与流程控制双重落地。

Objective
Design a clear, enforceable classification scheme for personal sensitive data to support consistent handling, compliance, and risk mitigation across the data lifecycle (collection, storage, use, sharing, retention, and disposal).

Scope and Definitions
- Personal Data: Any information relating to an identified or identifiable natural person (directly or indirectly).
- Sensitive Personal Data: Personal data that poses elevated risk to individuals if misused or disclosed, or is specifically protected by law or industry frameworks.
- Pseudonymized Data: Personal data processed such that it can no longer be attributed to a specific person without additional information; remains personal data.
- Anonymized Data: Data irreversibly de-identified; not personal data if anonymization is robust and irreversible.

Classification Levels
Use three levels for personal data with criteria, examples, and handling requirements:

Level PD-1 — Personal (Basic)
- Criteria: Identifiers and attributes with lower risk if disclosed; not specifically protected as “sensitive” by law.
- Examples: Name, work title, employer, general contact details (work email, phone), general demographic attributes (age range), device identifiers when not linked to precise location or sensitive context, cookie IDs, user IDs.
- Key handling requirements:
  - Access: Role-based access control (RBAC); need-to-know.
  - Encryption: In transit mandatory; at rest recommended.
  - Masking: Required in non-production environments when feasible.
  - Retention: Minimize and document; delete when business purpose ends.
  - Sharing: Contracts with processors; data protection addendum.

Level PD-2 — Personal (Sensitive)
- Criteria: Elevated risk of harm, fraud, identity theft, or discrimination; often explicitly defined as sensitive by regulations or industry standards.
- Examples:
  - Government IDs (passport, national ID, SSN, driver’s license).
  - Financial data (bank account numbers, payment card data subject to PCI DSS).
  - Authentication data (passwords, MFA secrets, private keys).
  - Precise geolocation (e.g., within ~185 meters).
  - Children’s personal data (age thresholds vary by jurisdiction; e.g., under 13 in the US COPPA; under GDPR, member states set 13–16).
  - Contact details when combined with identity verification data.
- Key handling requirements:
  - Access: Strict RBAC; least privilege; periodic access recertification.
  - Encryption: Mandatory at rest and in transit; hardware-backed or FIPS-validated where applicable.
  - Masking: Mandatory in non-production; dynamic masking in production for non-administrative users.
  - Logging: Full access logging; tamper-evident logs; anomaly monitoring.
  - Transfer: Cross-border transfer controls; assess lawful basis and transfer mechanisms (e.g., SCCs under GDPR).
  - DPIA: Required where processing is likely high risk (e.g., large-scale tracking, profiling).
  - Breach response: Notify per applicable law (e.g., GDPR supervisory authority notification within 72 hours if risk exists; data subject notification when high risk).
  - Retention: Strict minimization; time-bound with documented deletion controls.
  - Vendor management: Due diligence and security assessments; contractual controls.

Level PD-3 — Personal (Special Category/Restricted)
- Criteria: Highest risk; special categories under GDPR Article 9, criminal offense data (Article 10), or other highly sensitive contexts; significant potential for discrimination or serious harm.
- Examples:
  - Special categories: racial or ethnic origin; political opinions; religious or philosophical beliefs; trade union membership; genetic data; biometric data used for unique identification; health data; sex life or sexual orientation.
  - Criminal convictions and offenses (treated as restricted even though not part of Article 9).
  - Highly sensitive medical records (e.g., diagnostic results, mental health notes).
  - Biometric templates used for authentication (face/iris/voice/fingerprint).
- Key handling requirements:
  - Access: Explicit data owner approval; segregated environments; break-glass access for emergencies with post-incident review.
  - Encryption: Mandatory at rest and in transit; strong key management; separate key domains.
  - Isolation: Logical or physical segregation; dedicated datasets; minimize copies.
  - Masking/Redaction: Default masked views; disclose fields only when strictly necessary.
  - DPIA: Mandatory before new processing; consult privacy/legal.
  - Consent/Lawful Basis: Explicit consent or other legally valid basis; document purpose limitation.
  - Transfer: Additional safeguards; conduct Transfer Impact Assessments for cross-border flows.
  - Audit: Quarterly audits; continuous monitoring; data lineage and traceability.
  - Retention: Shortest feasible; strict deletion; prove erasure.
  - Incident response: Escalated severity; regulatory and data subject notification per law.

Special Handling Flags (metadata augmentations)
Apply flags to refine controls within PD-2 and PD-3. These do not replace the level; they enhance it.
- ChildrenFlag: Indicates data about minors; enforce age-specific requirements and parental consent where applicable.
- HealthFlag: Indicates regulated health data; align with HIPAA/health laws where relevant.
- PaymentCardFlag: Indicates PCI DSS scope; enforce network segmentation and PCI controls.
- BiometricFlag: Indicates biometric templates or data used for unique identification.
- GeoPreciseFlag: Indicates precise location data.
- CredentialsFlag: Indicates authentication secrets or cryptographic keys.
- CriminalFlag: Indicates criminal convictions/offenses data.

Metadata and Labeling Requirements
- Mandatory fields for each dataset/element:
  - DataClass: PD-1, PD-2, or PD-3
  - SensitivityFlags: zero or more flags from the list above
  - LawfulBasis: consent, contract, legal obligation, legitimate interests, vital interests, public task (as applicable)
  - Purpose: specific, documented use case(s)
  - DataOwner and DataSteward: accountable roles
  - RetentionPeriod and DisposalMethod: defined and approved
  - ProcessingLocation(s): regions, hosting environments
  - CrossBorder: yes/no and mechanism (e.g., SCCs)
  - SourceSystem and Lineage: upstream/downstream systems
  - AccessModel: RBAC profiles and approval workflow

Assignment Criteria and Decision Rules
- If any field matches PD-3 characteristics, classify the entire dataset PD-3 unless securely segregated at field level with consistent enforcement.
- If dataset contains PD-2 attributes (e.g., IDs, financial accounts, credentials), classify PD-2 unless PD-3 criteria apply.
- Pseudonymized data inherits the highest sensitivity level of its source attributes.
- Aggregated data remains personal if re-identification risk is reasonable; treat as personal until a formal anonymization assessment confirms PD-0 (non-personal).
- Mixed datasets should use field-level tags plus a dataset-level classification equal to the highest field-level sensitivity present.

Controls Matrix Summary
- PD-1: RBAC, transport encryption, basic masking, documented retention, standard vendor contracts.
- PD-2: Strong encryption at rest and in transit, strict RBAC with recertification, mandatory masking in non-prod, logging and monitoring, DPIA when high risk, stricter retention, vendor due diligence, cross-border safeguards.
- PD-3: Segregation, strong encryption and key management, explicit approvals, default masking/redaction, DPIA mandatory, explicit consent or equivalent lawful basis, enhanced audit, shortest retention, escalated incident response.

Lifecycle Governance
- Collection: Minimize; capture only necessary fields aligned to documented purpose and lawful basis.
- Storage: Segregate by classification; apply encryption and access controls per level.
- Use: Enforce purpose limitation; restrict analytics on PD-3 unless approved by data owner and privacy/legal.
- Sharing: Use data sharing agreements; apply data processing addenda and transfer assessments.
- Retention/Deletion: Enforce time-bound retention; automate deletion; verify and log erasure events.
- Quality: Validate identifiers (format, checksum), deduplicate, maintain accuracy especially for PD-2/PD-3 to reduce harm risk.
- Monitoring: Continuous control testing; periodic audits; track data lineage and access patterns.

Roles and Responsibilities
- Data Owner: Approves classification, access, use cases, retention; accountable for compliance.
- Data Steward: Maintains metadata, data quality, and control adherence.
- Data Custodian: Implements technical controls (encryption, masking, logging).
- Privacy/Legal: Reviews lawful basis, DPIA, cross-border transfers, and consent mechanisms.
- Security: Designs and operates controls; incident response.
- Compliance: Audits adherence; manages findings and remediation.

Implementation Steps
- Discover: Use data scanning and pattern recognition to identify personal and sensitive fields.
- Label: Apply DataClass and SensitivityFlags at field and dataset levels in the catalog.
- Enforce: Bind classification to access policies, encryption, masking, and retention controls.
- Review: Quarterly recertification of PD-2/PD-3 access; annual DPIA refresh for high-risk processing.
- Train: Provide role-based training for handling PD-2 and PD-3.
- Measure: Track incidents, access violations, and retention compliance; report to governance board.

This scheme provides a practical, regulation-aware structure for classifying and governing personal sensitive data, ensuring consistent controls and decision-making across the organization.

日志数据分类方案（面向数据治理）

1. 目标与范围
- 目标：为组织内各类日志（应用、系统、网络、安全、审计等）建立统一的分类标准，指导采集、存储、访问、保留、脱敏与共享，满足安全与合规要求，提升数据质量与可用性。
- 适用范围：所有环境（生产、测试、开发、SaaS/云服务、终端设备）产生的日志与其衍生数据（聚合、指标、追踪、告警、报表、导出）。

2. 分类模型与标签体系
采用“主等级 + 合规标签 + 辅助属性”的组合式模型，以适配不同监管与业务场景。

2.1 主机密等级（Confidentiality Level）
- L0（公开/可公开）：已严格脱敏/汇总，不含敏感内容，可对外公开或用于公开状态页。日志场景较少。
- L1（内部—一般）：仅含运行状态与技术事件信息，不含个人数据、商业秘密、凭据、交易内容等敏感信息。
- L2（内部—敏感）：可能包含有限个人数据或可与个人关联的信息（如IP、用户标识、邮箱哈希）、认证事件、业务操作轨迹等，需强化访问控制与脱敏。
- L3（受限—高度敏感/机密）：可能包含凭据/令牌、密钥材料、详尽请求/响应载荷中的个人敏感数据、财务/医疗等受监管数据、数据库审计内容、取证日志等，需最严格保护与最小化。

2.2 合规标签（Regulatory Tags，复选）
按内容与适用地域/业务标注，驱动差异化控制与保留。
- GDPR-个人数据：任何可识别个人的信息（直接或间接），需数据最小化、目的限制、合法基础、跨境限制。
- PCI-持卡人数据：支付卡相关数据（包括PAN等），需强制脱敏/屏蔽、访问最小化、严格审计。
- HIPAA-PHI（如适用）：受保护健康信息，需严格隔离、审计与最小化。
- SOX/财务控制（如适用）：与财务报告控制相关的审计/系统访问日志，需不可变与可追溯。
- 其他本地法规标签（如国家/行业数据出境、网安法类要求）。

2.3 辅助治理属性
在元数据中统一维护以下属性，支持策略引擎自动执行：
- data_owner（数据责任人/系统所有者）
- purpose（处理目的，如安全监控、审计、运营分析）
- lawful_basis（合法基础，如合法利益、合同履行）
- region（数据驻留/管辖地域）
- retention_schedule_id（保留计划标识，指向组织保留台账）
- quality_tier（数据质量等级，Q1/Q2/Q3）
- lineage_id（数据血缘）
- schema_version（日志模式版本）
- regulated_tags（合规标签列表，如["GDPR","PCI"]）
- classification_level（L0/L1/L2/L3）

3. 分类判定标准（决策准则）
按以下顺序决策，取最高风险原则：
- 是否包含凭据/令牌/密钥材料、完整业务载荷或敏感受监管数据（是 → L3）。
- 是否包含可识别个人数据或与个人可关联的数据（如IP、用户ID、设备ID、电子邮箱、电话号码、位置）（是 → 至少L2，并加“GDPR-个人数据”等标签）。
- 是否涉及支付、医疗、财务控制审计（是 → L2或L3，并加对应合规标签）。
- 是否为严格汇总、不可回溯到个体且已充分脱敏（是 → 可评估为L0）。
- 其余默认归为L1；无法确认时按更高等级处理（安全默认提升）。

4. 各等级处置要求（概要）
L0（公开/可公开）
- 内容要求：仅限汇总/指标，不可回溯到个人或敏感交易。
- 访问控制：可公开或广泛内部可读。
- 存储/传输：标准加密；变更需审批。
- 保留：按业务需要；仍需防止再识别风险。

L1（内部—一般）
- 内容最小化：禁止记录凭据、个人数据、商业秘密。
- 访问控制：内部授权访问，基础RBAC。
- 存储/传输：加密（静态/传输中），常规备份。
- 保留：遵守保留台账；到期删除或归档。
- 质量：Q2及以上，保证时间戳、主机、服务标识等基础字段完备。

L2（内部—敏感）
- 脱敏/伪匿名化：对个人标识、IP、邮件、设备ID等进行哈希/部分屏蔽；默认不保留原值。
- 访问控制：严格RBAC + ABAC（基于监管标签），最小权限，审计访问。
- 存储/传输：加密加强；细粒度密钥管理与访问审计。
- 保留：严格按照保留台账与法规“存储限制”；数据到期自动清除；必要时差分留存（保留事件元数据，删除敏感字段）。
- 质量与不可变性：审计关键字段不可篡改；时间同步；Q2/Q3。

L3（受限—高度敏感/机密）
- 默认禁止：禁止记录凭据明文、完整载荷中敏感字段；如无法避免，必须立即在管道中截断/令牌化。
- 双重控制：隔离存储域，专用密钥域，访问需双人审批或“break-glass”流程；全面审计与告警。
- 不可变/WORM：审计类日志采用不可变存储（写一次、读多次）和完整性校验。
- 保留与处置：严格受保留台账与法律要求约束；到期进行经过审计的删除；保留例外需法务/合规批准。
- 跨境/驻留：按地域标签强制在本地区域存储与处理。
- 质量：Q3（完整性、顺序性、时间同步、模式一致性最高要求）。

5. 示例映射（常见日志类型）
- Web访问日志（已屏蔽URL参数与IP段）：L1；若含IP和用户标识 → L2 + GDPR。
- 认证/授权日志（登录失败、MFA、令牌签发）：L2；若含令牌/会话ID原值 → L3。
- 应用错误/业务请求日志（可能含请求体/标头）：若存在用户输入/业务数据 → 至少L2；含敏感字段原值 → L3。
- 数据库审计日志（SQL、对象访问）：通常L3；加合规标签（如SOX/HIPAA视业务）。
- 网络/防火墙/代理/DNS/NetFlow：含IP与域访问行为 → L2 + GDPR（在部分司法辖区IP视为个人数据）。
- EDR/安全检测日志：至少L2；若含可还原个人或机密内容 → L3。
- 指标/可观测性汇总（聚合度高、不可回溯个体）：可评估为L0或L1。
- 云提供商审计（例如IAM变更、密钥管理审计）：L2或L3（视是否涉及密钥/权限高风险）。

6. 分类实施流程与职责
- 角色
  - 数据所有者（Data Owner）：负责其系统日志的分类与保留策略对齐。
  - 数据保管人（Data Custodian/平台）：执行技术控制、标签落地、存储与访问策略。
  - 安全与隐私（Security/Privacy）：定义分类标准、检测规则、合规审计。
  - 法务与合规（Legal/Compliance）：维护保留台账与合规映射，审批例外。
- 流程（纳入日志管道）
  1) 采集前设计：定义日志模式，剔除敏感字段，指定分类预期。
  2) 入站检测：PII/秘密扫描、合规识别、规则匹配（如正则识别PAN/邮箱/令牌）。
  3) 自动分类与打标：写入统一元数据字段（classification_level、regulated_tags、purpose等）。
  4) 脱敏/伪匿名化：在入口进行字段级屏蔽/令牌化；保留最小必要信息。
  5) 路由与存储：按等级与标签路由至存储域（受限域/通用域），应用加密与不可变策略。
  6) 访问与审计：RBAC/ABAC策略启用；所有访问有审计轨迹与告警。
  7) 保留与删除：依据retention_schedule_id执行到期处置；记录可证明的删除日志。
  8) 评审与改进：定期（至少年度或重大变更时）审查分类效果与例外。

7. 元数据与技术控制建议
- 标准元数据字段（建议在每条日志或数据集级维护）
  - classification_level, regulated_tags, purpose, lawful_basis, region
  - data_owner, system_id, lineage_id, schema_version
  - retention_schedule_id, quality_tier
- 自动检测与规则库
  - 个人数据：邮箱、电话、IP、cookie、设备ID、用户名等模式。
  - 高敏：令牌（JWT、OAuth）、API密钥、密码、密钥材料、支付卡号（Luhn校验）。
  - 领域特定：医疗标识、财务账户号、政府ID等。
- 加密与密钥管理
  - 分级加密（L2/L3采用独立密钥域与密钥轮换策略）。
  - 访问分离（操作人员与审计人员权限隔离）。
- 存储策略
  - L3采用不可变存储/WORM与完整性签名（如基于哈希链/时间戳服务）。
  - 按region标签进行数据驻留与跨境控制。
- 访问策略
  - L2/L3需强鉴权、多因素；按合规标签限制查询功能（禁止自由文本检索敏感字段）。
- 数据质量管理
  - 质量维度：完整性（字段必填）、一致性（模式与类型）、及时性（时间延迟）、准确性（时间同步、主机ID校验）、可追溯性（链路与血缘）。
  - 质量等级：Q1（分析/趋势用途）、Q2（运营用途）、Q3（审计/取证用途）。
  - 检测与告警：模式漂移与敏感字段泄露告警；时间同步偏差阈值；丢日志率阈值。

8. 保留与合规对齐原则
- 建立统一保留台账（Retention Schedule），按业务目的与法规要求（含地域差异）制定，避免在分类方案中硬编码时长。
- 遵循“数据最小化、目的限定、存储限制”：日志仅保留满足监控、审计、合规所需的最短期限。
- 对受监管标签的日志实施专项流程（如审计可用性、取证保全与受控删除）。
- 处理数据主体权利请求：在不削弱安全审计前提下，优先减少或伪匿名化个人数据，提供可行的定位与处置流程。

9. 例外与变更管理
- 任何降级分类或保留延长需法务/安全审批并记录理由与期限。
- 新增系统或日志模式上线前进行隐私与安全评估（DPIA/安全评审）。
- 定期开展抽样核查与红队测试（验证无敏感字段泄露）。

10. 快速检查清单（用于落地与审计）
- 是否明确每类日志的classification_level与regulated_tags？
- 是否在采集前完成字段级最小化与脱敏设计？
- 是否在管道中启用自动检测与打标，并阻断高敏字段进入非受限域？
- 是否有统一保留台账与到期自动删除机制？
- 是否对L3启用不可变存储与访问双重控制？
- 是否记录并审计所有访问与导出？

该方案可直接用于制定组织级《日志数据分类与处理规范》，并与数据目录、SIEM/日志平台、DLP/秘密扫描、密钥管理系统和保留台账集成，实现策略驱动的自动化治理。