制定数据加密指南

加密员工记录指南（数据治理）

1. 目的与范围

• 目标：将员工记录在全生命周期内以可验证的方式加密，降低未授权访问与数据泄露风险，满足法律与合规要求。
• 范围：人力资源系统、薪酬与福利平台、绩效与培训系统、文件存储与协作工具、备份与日志、传输与接口、移动与终端设备。

2. 数据定义与分类

• 员工记录通常包含个人身份信息（PII）与敏感个人信息（SPI），需至少归类为“机密”或“受限”级别。
• 强制字段级加密（或代币化）的典型数据：
  • 身份与证件号、国民身份证/社保号、护照号
  • 银行账号、工资、税务信息
  • 联系方式（电话、邮箱、住址）
  • 医疗与残疾相关信息、紧急联系人
  • 背调结果、绩效评价、纪律记录
• 元数据与索引中不得明文包含敏感字段的可还原值（例如不在日志/索引中写入明文证件号）。

3. 角色与职责

• 数据所有者（HR负责人）：定义加密适用范围、审批解密使用场景与例外。
• 数据管理员/数据管家（HR数据管理）：维护数据字典与加密清单，协调数据质量与掩码策略。
• 信息安全与加密服务团队：制定加密标准、管理密钥与KMS/HSM、监控与审计。
• 应用与数据库团队：实施字段/表/磁盘加密、接口加密、性能与可用性保障。
• 法务与合规：对齐 GDPR/PIPL 等法规要求与合同条款。

4. 加密策略总则

• 默认加密：所有受限/机密级员工数据在存储与传输中均需加密（“加密优先”）。
• 最小权限与分层解密：仅在业务必要时解密；优先采用字段级或记录级精细解密，避免系统范围内长时间明文。
• 与数据最小化协同：仅收集、处理所需字段；减少加密/解密面。
• 不在客户端或日志持久化明文敏感数据；采用掩码显示（如仅显示证件号后4位）。

5. 数据生命周期控制

• 采集：在客户端到后端采用强 TLS；在后端入库前进行字段级加密或代币化。
• 存储：数据库、对象存储、文件系统使用加密；备份与快照同等加密。
• 使用：按需解密，记录理由与审批；输出报表采用掩码或代币。
• 共享：对外接口以传输层加密＋载荷签名/加密；跨境传输需法务审批与保障措施。
• 归档与销毁：归档数据保持加密；销毁通过密钥撤销（加密报废/crypto-shredding）与物理删除双重控制。

6. 技术标准（算法与协议）

• 存储加密（推荐）
  • 对称：AES-256-GCM 或 ChaCha20-Poly1305（带认证保证）。
  • 数据库透明加密（TDE）：AES-256；但对高敏字段应加字段级加密以减少广泛解密风险。
  • 文件/对象：采用AEAD模式；避免ECB与过时算法（DES、RC4、MD5、SHA-1）。
• 传输加密
  • TLS 1.3（优先）或 TLS 1.2（仅强制 ECDHE + AES-GCM/ChaCha20-Poly1305；禁用TLS 1.0/1.1与弱套件）。
  • API 载荷可选额外签名（Ed25519）与应用层加密（JWE）。
• 密钥与公钥标准
  • 非对称：RSA ≥2048（优先 3072）或椭圆曲线 P-256/X25519；签名可用 Ed25519。
  • 哈希：SHA-256/384；密码存储使用 KDF（Argon2id 优先；备选 bcrypt/scrypt）。
    • Argon2id示例参数：内存 64–256MB，迭代 2–4，并行度 1–4（结合风险与硬件评估）。

7. 密钥管理（KMS/HSM）

• 集中式KMS或HSM管理密钥；支持密钥分级：主密钥（KEK）与数据密钥（DEK）采用信封加密。
• 密钥生命周期：生成（高熵、硬件来源）、分发（安全通道）、使用（最小暴露）、轮换（至少年度或事件驱动）、撤销与销毁（可验证）。
• 访问控制：密钥使用需基于服务身份与RBAC/ABAC；禁止将密钥与密文共存同一不受控位置（如同一备份包）。
• 审计：所有密钥操作与解密事件可追踪、不可抵赖；异常告警与阈值控制。

8. 访问控制与解密授权

• 解密仅在特定业务流程中进行，采用细粒度授权与临时访问令牌；支持“按字段、按记录、按时段”的访问限制。
• 双人审批或强制理由登记用于高敏字段（例如医疗、财务账号）。
• 前端显示采用动态掩码；导出文件默认加密并设置到期与访问口令的分发机制。

9. 应用与数据库实现模式

• 字段级加密：应用层在写入前加密高敏字段；避免数据库层广泛解密。可选确定性加密以支持等值查询，但须评估泄露风险并仅用于低风险字段。
• 代币化/映射表：将高敏值替换为不可逆代币；必要时以受控服务检索原值。
• 索引与搜索：对敏感字段不建立基于明文的索引。等值查询可用哈希索引（带盐，避免可逆推断）。
• 会话与缓存：禁止在中间缓存中存储明文；使用内存加密与最短TTL。

10. 接口与集成

• 第三方对接：合同与DPA需明确加密要求、密钥责任与审计权；使用互信TLS证书管理与双向TLS。
• 批量文件交换：采用加密容器（如 age/PGP）或 S/MIME；通道与载荷双重加密优先。

11. 终端与移动

• 终端全盘加密（Windows BitLocker、macOS FileVault、移动设备原生加密）；MDM强制策略与远程擦除。
• 禁止在未经授权的终端存储员工数据明文；U盘与可移动介质须强制加密或禁用。

12. 备份与灾难恢复

• 备份与快照必须加密，且密钥独立管理；定期演练解密恢复流程。
• 异地与冷备：遵循同等加密与密钥隔离；确保恢复链路的TLS安全。

13. 监控、审计与度量

• 日志：记录解密调用、数据访问主体、用途、时段、结果；保护日志不可被篡改。
• 度量：加密覆盖率、密钥轮换达标率、异常解密告警率、备份恢复成功率。
• 定期评估：加密方案渗透测试与密码合规评审，更新弱算法清单。

14. 例外管理与事件响应

• 例外须由数据所有者与安全团队联合审批，明确补偿控制与到期时间。
• 密钥泄露或嫌疑：立即轮换与撤销、影响评估、通知流程与取证；必要时执行加密报废策略。

15. 培训与文件化

• 面向HR与IT的加密与数据最小化培训；开发团队掌握安全编程与密钥使用模式。
• 文档：维护加密字段清单、算法与参数标准、密钥RACI、操作流程与应急预案。

16. 合规参考（指导性）

• GDPR 第32条（处理安全）、数据保护原则（最小化、完整性与保密性）。
• 中国个人信息保护法（PIPL）：采取加密等安全措施，严格访问控制与审计。
• ISO/IEC 27001/27002、NIST SP 800-57（密钥管理）、NIST SP 800-52（TLS 配置）等实践框架。

17. 实施检查清单（摘要）

• 明确数据分类与加密清单；确定字段级与存储级加密范围。
• 选定算法与协议（AES-256-GCM/TLS 1.3 等），建立KMS/HSM与信封加密。
• 配置RBAC/ABAC与审批流程；前端掩码与导出加密。
• 备份加密与密钥隔离；日志与审计报表上线。
• 定期轮换密钥与渗透测试；例外与事件响应机制就绪。
• 与第三方/云供应商签署加密与审计条款，验证实施。

本指南旨在在治理层面规定“加什么、谁批、如何管、如何审”，在技术层面规定“用什么算法与工具、如何实施与运维”。实施前应结合组织风险评估、系统架构与法律要求进行细化与验证。

Guidelines for Encrypted Database Backups

1. Purpose and scope

• Ensure backups of databases are encrypted end to end (in transit and at rest) to protect confidentiality and integrity, meet regulatory obligations, and support recoverability.
• Apply to full, differential/incremental, and log/WAL backups; include backup catalogs, configuration exports, and snapshots.

2. Policy requirements

• All database backups must be encrypted using approved algorithms and keys managed in a controlled key management system.
• Encryption must be enabled by default and enforced by technical controls (policy-as-code where possible).
• Backups must be transmitted over encrypted channels.
• Access to backup data and keys must follow least privilege, separation of duties, and dual control for key escrow/recovery.
• Implement immutability/WORM for critical backups and maintain at least one offline/air-gapped copy.
• Verify backup integrity and restoration regularly; treat successful test restores as a control objective.
• Retention, location, and deletion must comply with data classification, legal hold, and data residency requirements.

3. Roles and responsibilities

• Data Owner: Defines classification, retention, and location constraints.
• DBA: Implements backup encryption at the database/tool level; executes restores; validates integrity.
• Backup Administrator: Manages backup infrastructure, repositories, immutability, and monitoring.
• Key Management Owner (KMS/HSM): Manages keys, rotation, access, escrow, and auditing.
• Security/GRC: Defines cryptographic standards; verifies compliance; oversees risk exceptions.
• Internal Audit: Tests controls (encryption, access, restores, logging).

4. Approved cryptography

• Symmetric encryption: AES-256 with AEAD (GCM or CCM) preferred; alternatives: AES-256-CBC plus HMAC-SHA-256/512 if AEAD unavailable.
• Key wrapping: AES-KW (RFC 3394) or AES-GCM; if public key, use RSA-OAEP (≥3072-bit) or ECIES with P-256/P-384.
• Hashing: SHA-256/512; avoid MD5 and SHA-1.
• TLS: v1.2+ (prefer 1.3) with modern cipher suites.
• Use FIPS 140-3 validated crypto modules where required.

5. Key management (NIST SP 800-57 aligned)

• Use centralized KMS/HSM for root and data-encryption keys (DEKs). Prefer customer-managed keys (CMKs).
• Generate keys with KMS/HSM; never hardcode in scripts or store in source control.
• Separate key roles: DBAs and backup admins cannot access key material; key custodians manage keys.
• Rotation: Rotate KEKs annually or on material change; re-wrap DEKs; plan re-encryption of long-lived backups on schedule or upon compromise.
• Escrow and recovery: Define dual-control procedures; consider Shamir Secret Sharing for master key escrow.
• Backup keys securely and test key recovery; loss of keys renders backups unrecoverable.
• Access controls: Enforce least privilege with per-environment key policies; log key usage with key ID, principal, and purpose.
• Crypto-shredding: Define process to destroy keys for data subject deletion or end-of-life, subject to legal holds.

6. Architecture patterns

• Application/database-native encryption of backup artifacts is preferred over storage-only encryption.
• Storage-level encryption (e.g., encrypted disks/buckets) is additive, not a substitute for backup-file encryption.
• For dedup/compression, perform these operations before encryption within the backup application to maintain efficiency.

7. End-to-end workflow

• Data classification and scope: Include only necessary datasets. Exclude test data or anonymize where appropriate.
• Backup creation:
  • Use native DB features or enterprise backup tools that support AEAD and KMS integration.
  • Compress, then encrypt, then write to repository.
  • Embed or store separately a cryptographic signature/HMAC for integrity.
• Transport:
  • Use mTLS or SSH (SFTP) for agent-to-repository traffic; pin server certs where feasible.
• Storage:
  • Store encrypted backups on immutable/WORM-capable repositories; replicate to secondary region/account/tenant.
• Catalogs/metadata:
  • Encrypt the backup catalog, manifests, and any stored credentials; protect with separate keys and access controls.
• Verification:
  • Automatically verify backup integrity (checksums, HMAC, or AEAD tag) post-write and on a scheduled basis.
• Restore testing:
  • Perform periodic test restores to a sterile environment using production keys; validate data and logs/WAL replay.

8. Immutability and ransomware resilience

• Enable WORM/immutability:
  • Object storage: S3 Object Lock (Compliance/Governance), Azure Immutable Blob, GCP Bucket Lock.
  • Backup appliances: Retention lock features.
  • Tape: LTO WORM for offline copies.
• Maintain an offline/air-gapped copy for critical systems.
• Require MFA delete or governance-mode protections for retention settings.
• Scan backups for malware pre- and post-restore; do not rely solely on scanning encrypted data.

9. Access control and logging

• RBAC with least privilege for backup operations; separate roles for backup admin, DBA, and key custodian.
• PAM for privileged sessions; just-in-time elevation where possible.
• Break-glass process with dual approval and time-bound access; log all actions.
• Comprehensive audit logs: who/what/when/where for backup creation, key usage, restore attempts, deletions, and retention changes; forward to SIEM with alerts on anomalies.

10. Retention, residency, and legal holds

• Define retention by data classification and regulation (e.g., 30–90 days operational, 1–7 years regulatory, longer for specific rules).
• Apply legal holds in the backup system; blocks deletion and rotation.
• Enforce data residency: Ensure backup data and keys remain in approved regions; encryption does not waive residency constraints.
• Document cross-border transfers and apply SCCs or equivalent where required.

11. Integrity and authenticity

• Use AEAD (GCM) to provide confidentiality and integrity; additionally sign archives or manifests (Ed25519/ECDSA) where tools support it.
• Maintain and verify cryptographic checksums (SHA-256/512) for each backup segment; store separately from data.
• Validate integrity at backup time and before every restore.

12. Performance considerations

• Use hardware acceleration (AES-NI, ARMv8 Cryptography Extensions).
• Compress before encrypt; deduplicate before encrypt where supported by the backup tool.
• Avoid convergent encryption due to privacy and collision risks.
• Tune concurrency and I/O to offset encryption overhead; size CPU accordingly on agents and repositories.

13. Cloud provider specifics

• AWS:
  • RDS/Aurora: Enable encryption at instance/cluster creation; automated backups and snapshots inherit KMS CMK. To encrypt an unencrypted snapshot, copy with encryption and a CMK. Use AWS Backup with CMK and Vault Lock for immutability.
  • EC2 self-managed DBs: Use agent-based encryption with KMS; store backups in S3 with SSE-KMS and Object Lock.
• Azure:
  • Azure SQL/MI: TDE on by default; backups are encrypted. For CMK, integrate with Azure Key Vault (TDE with CMK). Use Azure Backup vault with immutability.
  • Self-managed: Encrypt with tool; store in Immutable Blob Storage with CMK.
• GCP:
  • Cloud SQL: CMEK-supported instances encrypt backups with CMEK; ensure key rotation and availability. Use Bucket Lock and CMEK for GCS backups of self-managed DBs.

14. Database/tool-specific notes

• Oracle: Use RMAN backup encryption (AES 128/192/256). Modes: Transparent (TDE wallet), Password, or Dual. Protect wallet with HSM/KMS where possible.
• Microsoft SQL Server: Use native backup encryption (AES-256) with certificates or asymmetric keys in master; protect the certificate private key; back it up securely. TDE does not encrypt unencrypted backups unless backup encryption is also enabled.
• PostgreSQL: pg_dump/pg_basebackup lack built-in encryption; encrypt via:
  • pgBackRest (AES-256, key management, compression, delta).
  • WAL-G or barman with KMS/GPG integration.
  • Pipe through OpenSSL or GPG with AEAD and signed manifests.
• MySQL/MariaDB: MySQL Enterprise Backup and Percona XtraBackup support encryption (AES-256) with keyring plugins (file, HashiCorp Vault, KMS). Ensure redo/binlog and keyring backups are coordinated for recoverability.
• MongoDB: Use backup tooling (Ops Manager/Cloud Manager/Atlas) with backup encryption; for file-level snapshots, ensure filesystem/block-device encryption does not replace backup-file encryption; protect keys in KMIP/KMS.
• Backup catalogs: Many enterprise backup suites (e.g., NetBackup, Commvault, Veeam) support per-tenant keys, immutability, and KMS/HSM integration; enable repository encryption and lock credentials.

15. Testing and drills

• Quarterly restore tests per critical system; include point-in-time recovery.
• Validate decryption using production-like keys and roles.
• Document RTO/RPO attainment; capture lessons learned and adjust runbooks.
• Test key rotation impact and expired/disabled key scenarios.

16. Compliance mapping (examples, verify against your obligations)

• GDPR Art. 32: Encryption appropriate to risk; ensure data subject rights and deletion with crypto-shredding when permissible.
• HIPAA: Encryption is addressable but expected; ensure key management, access logging, and secure disposal.
• PCI DSS v4.0: Strong cryptography for PAN at rest (Req 3); key management (Req 3.5/3.6); logging and monitoring (Req 10); backup media protection.
• SEC/FINRA: WORM retention (SEC 17a-4(f)) for broker-dealers; implement immutable backups and supervision.

17. Metrics and monitoring

• Coverage: Percentage of backup jobs with encryption enabled (target 100%).
• Key usage: Backups tied to CMKs with valid rotation status.
• Immutability: Percentage of backups stored on immutable/WORM media.
• Restore success rate and time; integrity check pass rate.
• Unsuccessful/unauthorized restore attempts and deletions (alerts).
• Age and compliance of keys, certificates, and modules (FIPS status).

18. Implementation checklist

• Define policy: Approved algorithms, KMS, roles, retention, regions.
• Inventory databases and backup flows; classify data and set retention.
• Select tooling that supports AEAD, KMS/HSM, immutability, and verification.
• Implement mTLS between agents and repositories; enforce TLS 1.2+.
• Enable encryption for all backup types (full, differential, log/WAL).
• Integrate with KMS/HSM; define key hierarchy and rotation.
• Configure immutable/WORM storage and offline copies.
• Encrypt backup catalogs and protect credentials/secrets.
• Automate integrity verification and periodic test restores.
• Implement RBAC, dual control for key recovery, and break-glass.
• Centralize logs in SIEM; build alerts and dashboards.
• Document runbooks for backup, restore, key recovery, and incident response.
• Conduct tabletop exercises for key compromise and ransomware scenarios.

19. Common pitfalls to avoid

• Relying solely on disk or bucket encryption without encrypting backup files.
• Losing key material due to inadequate escrow/testing.
• Not encrypting backup catalogs or manifests that may expose sensitive metadata or credentials.
• Skipping integrity verification and restore tests.
• Storing keys and backups in the same administrative domain without separation of duties.
• Compressing after encryption (ineffective) or expecting deduplication to work on encrypted blobs.
• Allowing retention/immutability settings to be reduced without multi-party approval and audit.

These guidelines provide a governance-aligned baseline. Adapt to your regulatory scope, threat model, and technology stack, and codify requirements into build/backup pipelines and configuration policies to ensure continuous compliance.