制定数据加密指导原则

企业数据平台与密钥管理系统（KMS）数据加密指导原则

1. 目标与适用范围
- 目标：确保企业数据在传输、存储与使用阶段的机密性、完整性与可用性，降低密钥泄露与误用风险，满足合规要求。
- 适用范围：数据湖/仓库、对象存储、数据库、消息与流处理、备份归档、日志体系，以及中心化或云原生KMS与HSM集群。

2. 总体原则
- 默认加密：所有敏感数据在静态与传输时默认加密，禁止明文落地。
- 最小权限：密钥与解密能力采用最小授权、短时凭证和按需访问。
- 分层防护：结合网络隔离、身份鉴别、审计与数据治理，构成纵深防御。
- 加密敏捷：设计中抽象算法与密钥接口，支持后续算法与参数平滑迁移。
- 可验证性：加密、密钥操作与访问事件须可审计、可追溯、可告警。

3. 算法与参数基线
- 对称加密（首选）：AES-256-GCM（AEAD）；对移动/无硬件加速场景可用ChaCha20-Poly1305。
- 非对称加密：RSA-3072或以上；或椭圆曲线P-256/Curve25519用于密钥协商与签名。
- 哈希与MAC：SHA-256/384；完整性与认证使用 HMAC-SHA-256。
- 密钥派生：HKDF（基于SHA-256），绑定上下文信息（AAD）。
- TLS：TLS 1.3，禁用过时套件（RC4、3DES、SHA-1、RSA-1024/2048长期场景谨慎，优先ECDHE）。
- GCM注意事项：保证96位随机且唯一的Nonce；认证标签长度推荐128位。
- 磁盘级加密：块设备使用AES-XTS；对象/文件级使用AEAD（AES-GCM）。
- 避免：自研算法、DES/3DES、RC4、MD5、SHA-1、无认证的流/分组模式。

4. 数据分类与策略映射
- 依据数据敏感度（公开/内部/机密/高度机密）定义加密强度、密钥隔离级别与访问流程。
- 高度机密数据：字段级加密或令牌化、专用CMK、mTLS与强审计、解密仅在受控计算域内。

5. 传输中加密
- 客户端到服务端、服务到服务均使用TLS 1.3，优先mTLS以实现双向鉴别。
- 内部服务身份采用短期证书（SPIFFE/SPIRE或等效工作负载身份），自动轮换。
- 消息与流平台（如Kafka）启用TLS；如需端到端机密性，采用记录级加密（Envelope Encryption）。

6. 静态数据加密
- 存储层：对象存储、数据湖、备份与快照启用服务端加密（SSE）并使用客户管理密钥（CMK）。
- 数据库：TDE作为基线；对敏感字段使用列/字段级AEAD或令牌化（PCI场景可采用FPE FF1/FF3-1经严格评估）。
- 日志与遥测：禁记载明文敏感信息；必须加密存储并进行敏感字段掩码。
- 去重/压缩：先压缩后加密；避免“可逆去重”导致明文信息泄漏。

7. 使用中加密与受控计算
- 优先在受控执行环境中解密（隔离容器、专用安全域、最小可见性）。
- 需要跨表关联的确定性加密仅限严格评审的特定字段，并控制明文/密文可区分性风险。
- 保密计算（TEE/SGX/SEV等）可用于高敏场景；需评估侧信道与可操作性。
- 脱敏与伪匿名：用不可逆散列+盐或HMAC实现稳定ID；不要用可逆加密替代匿名化。

8. KMS架构与运行原则
8.1 架构与信任边界
- 使用中心化KMS，根密钥由HSM保护（FIPS 140-2/3 验证模块）。
- 区分环境与租户的密钥域，避免跨域共享CMK。
- 对外暴露仅限标准接口（如KMIP、PKCS#11或云KMS API）。

8.2 密钥层级与封装
- 采用密钥分层：Root Key/HSM保护的KEK → CMK（密钥加密密钥）→ DEK（数据加密密钥）。
- Envelope Encryption：DEK用于数据对象加密；DEK以CMK包封并随对象元数据存储。
- 每对象/每文件独立DEK；高吞吐场景可使用会话级DEK缓存并设置短TTL。

8.3 密钥生命周期
- 生成：在HSM内或经FIPS级随机数源产生；禁止导出根密钥。
- 分发与存储：仅分发包封的DEK；明文DEK仅在受控内存中短暂存在。
- 使用：在KMS或安全执行环境中完成解包与加解密操作，避免长驻内存。
- 轮换：CMK建议每12个月或人员变更/事件后立即轮换；DEK按对象粒度天然轮换，或数据重写时更换。
- 归档与销毁：过期CMK进入冻结期，仅用于解密；符合策略后在HSM内销毁并形成证据。支持“加密删除”（销毁DEK实现快速不可逆删除）。

8.4 访问控制与审批
- 职责分离：KMS管理员、密钥托管人、安全审计与数据所有者相互独立。
- 访问策略：基于属性与身份（ABAC/OPA），细粒度到操作级别（加密/解密/导出）。
- 特殊操作（解密大量历史数据、导出密钥材料）需多方审批与限时授权（M-of-N/双人控制）。

8.5 异常、撤销与妥协处置
- 可疑使用告警：异常解密频率、跨区域访问、非预期服务调用即时告警。
- 密钥妥协：立即禁用版本、切换新CMK、强制数据重加密，评估受影响范围与时间窗口。
- 应急解密“Break-glass”：最小化范围、短时有效、全量审计、事后复盘。

8.6 可用性与性能
- 多活高可用：KMS与HSM集群跨可用区部署，满足RPO/RTO。
- 降低耦合：通过Envelope方案将KMS调用收敛至DEK解封；对热点业务使用本地DEK缓存与重试策略。
- 限流与退让：KMS接口设置TPS阈值与优雅降级，避免放大故障。

8.7 审计与监控
- 全量记录生成、启用、禁用、轮换、解封、访问失败等事件；日志加密且防篡改（哈希链/时间戳）。
- 与SIEM集成，建立基线与行为分析模型，联动SOAR自动化响应。

8.8 灾备与业务连续性
- 密钥材料多站点冗余；根密钥仅在HSM内分裂或封装备份（可采用M-of-N或门限方案）。
- 定期演练KMS失效、密钥恢复与数据重加密流程。

8.9 合规模块与外部集成
- HSM与KMS满足FIPS 140-2/3；外联采用经认证接口。
- 支持客户自带密钥（BYOK）与外部托管（EKM/HYOK），明确密钥主权与审计边界。

9. 应用与数据平台集成指引
- SDK与库：使用经过审计的加密库，统一密钥调用接口，禁止在应用内硬编码密钥或IV。
- 上下文绑定：AEAD的AAD包含数据分类、对象ID、版本、租户ID等，以防跨上下文滥用。
- 大对象分片：分块独立随机Nonce或每块衍生子密钥，避免Nonce重用。
- 字段级方案：身份证件号、卡号采用令牌化或FPE；强一致性查询使用确定性加密需限用并加噪处理。
- 凭据与密码：用户密码存储使用Argon2id或PBKDF2-HMAC-SHA-256（高迭代），每条唯一盐；应用密钥与API令牌统一在Secrets Manager管理并定期轮换。

10. 多云与跨区域
- 采用抽象的KMS适配层，支持主流云KMS与本地HSM，统一策略与审计。
- 跨区域密钥主权：敏感区域使用本地CMK与就地加密；跨境数据传输遵循数据出境合规审批与强加密。
- 密钥与数据同域：尽量保证加密与解密在同一司法与地理域内完成。

11. 合规与标准对齐
- NIST SP 800-57（密钥管理）、SP 800-38D（GCM）、SP 800-175B（加密使用指南）。
- ISO/IEC 27001/27018、PCI DSS Req. 3、GDPR Art. 32、HIPAA 164.312(a)(2)(iv)等要求映射至加密与密钥控制。
- FIPS 140-2/3 模块验证用于HSM与加密模块合规背书。

12. 事件响应
- 预定义剧本：密钥滥用、KMS不可用、算法漏洞披露三类场景的隔离、切换、重加密、合规通报步骤。
- 取证与保全：保留相关加密与访问日志、KMS审计轨迹与时间戳证据。
- 复盘改进：更新访问策略、轮换周期、监控阈值与供应链依赖。

13. 加密敏捷与后量子准备
- 资产清单：维护全域加密算法、密钥长度、协议版本的系统清单。
- 接口抽象：避免将具体算法写死在业务代码；通过策略下发选择套件。
- 迁移路线：关注后量子标准进展，评估混合密钥协商（PQC+ECDHE）与TLS支持，先从低风险链路试点。

14. 例外管理
- 任何偏离本原则的实现须进行风险评估、获得安全批准、限定期限并制定补救计划；同时启用额外监控与补偿控制。

通过以上原则，企业可在数据平台与KMS间建立明确的加密与密钥治理框架，实现强安全、可运维、可审计且具备面向未来的加密能力。

Encryption Guidelines for HR and Customer Service Data Processing Systems

1. Purpose and Scope
- Apply these guidelines to all HR and customer-service data processing components, including applications, databases, data lakes, message queues, logs, backups, analytics stores, call recordings, chat transcripts, and file attachments.
- Objectives: protect personal data from unauthorized access; reduce breach impact; meet regulatory and contractual obligations; enable controlled, auditable decryption on a least-privilege basis.

2. Data Classification and Protection Objectives
- Classify data before processing:
  - Highly sensitive: government IDs, SSNs, payroll data, medical or benefits information, authentication secrets, payment tokens, full call recordings and transcripts, biometrics.
  - Sensitive: names, contact details, employee records, customer account metadata, HR notes, case histories.
  - Internal: operational metadata without personal identifiers.
- Protection goals:
  - Confidentiality: enforce encryption at rest and in transit; use application-level field encryption for highly sensitive data.
  - Integrity: use authenticated encryption (AEAD) to detect tampering.
  - Availability: design key management for resilience without weakening controls.

3. Approved Cryptographic Standards
- Use only well-vetted, modern, and platform-supported algorithms:
  - Symmetric encryption: AES-256-GCM preferred; ChaCha20-Poly1305 acceptable where AES acceleration is unavailable (e.g., some mobile contexts).
  - Disk/block storage: XTS-AES-256 for full-disk or volume encryption.
  - Hashing: SHA-256/384 for integrity; do not use MD5 or SHA-1.
  - Password hashing: Argon2id (recommended) with memory ≥64 MB, iterations ≥3, parallelism ≥1; alternatively scrypt (N≥2^15, r=8, p=1) or PBKDF2-HMAC-SHA256 with high iteration counts per current OWASP guidance.
  - Public-key: X25519/Ed25519 or NIST P-256 (secp256r1) for key exchange/signatures; RSA 3072-bit minimum if RSA is required.
- Randomness: use OS-provided CSPRNGs; never roll your own.
- Use FIPS 140-2/140-3 validated cryptographic modules when required by policy or regulation.

4. Encryption In Transit
- External and internal services:
  - Require TLS 1.3; allow TLS 1.2 only with strong AEAD suites and ECDHE for perfect forward secrecy. Disable TLS 1.0/1.1 and weak ciphers.
  - Enable HSTS on public endpoints; use OCSP stapling; enforce certificate validation and hostname verification.
  - Use mutual TLS (mTLS) for service-to-service traffic within the data plane.
  - Rotate public TLS certificates within their validity (≤398 days for publicly trusted) and monitor expiration.
- Client applications and endpoints:
  - Use certificate pinning where feasible for mobile apps accessing sensitive APIs.
  - Disable TLS compression and renegotiation; prevent protocol/cipher downgrade.

5. Encryption At Rest
- Apply encryption to all storage layers:
  - Databases: enable Transparent Data Encryption (TDE); additionally encrypt sensitive columns at the application layer (see section 6).
  - Files and object storage: encrypt using server-side encryption with customer-managed keys; verify coverage for attachments, images, audio, and transcripts.
  - Logs, analytics, search indices, caches, and message queues: enforce encryption at rest; do not store plaintext PII in unauthenticated caches.
  - Backups and snapshots: encrypt with keys separate from production keys; verify restorations maintain encryption.
  - Endpoints: enforce full-disk encryption on staff laptops and support desktops; use hardware-backed key protection (e.g., Secure Enclave, TPM).
- Verify encryption for temporary storage (tmp directories, swap, container layers) and exported reports.

6. Application-Level and Field-Level Encryption
- Encrypt highly sensitive fields before persisting:
  - Government ID numbers, SSNs, national insurance numbers.
  - Payroll/bank details, benefits/medical data.
  - Authentication secrets, security answers.
  - Call recording audio segments and transcript payloads if they include sensitive content.
- Use AEAD (AES-GCM or ChaCha20-Poly1305) with unique nonces; never reuse nonces under the same key.
- Manage per-tenant or per-record data keys via envelope encryption:
  - Generate a unique data encryption key (DEK) per record or logical group.
  - Wrap DEKs with a key encryption key (KEK) in a KMS/HSM.
  - Store only wrapped DEKs with the data; never store plaintext keys alongside ciphertext.
- For searchable fields, prefer cryptographic tokenization or deterministic encryption with strict scoping; evaluate leakage risks before use.
- Format-preserving encryption should be used only when strictly necessary and implemented via vetted, standards-compliant libraries; document the risk trade-offs.

7. Tokenization and Hashing
- Payment data: do not store PANs; use PCI-compliant tokenization. If necessary, store only truncated PAN and token; encrypt all related reference data.
- Identifiers frequently used for lookup (e.g., SSN): prefer irreversible tokenization or salted hashing; if deterministic mapping is required, use a keyed cryptographic transform and restrict access tightly.
- Passwords: store using Argon2id (preferred) with unique 16-byte salts and an application-level pepper held in an HSM/KMS; never encrypt passwords.

8. Key Management
- Centralize in a KMS or HSM with strong access controls and audit logging:
  - Separate roles: key administrators, security operations, application owners.
  - Enforce m-of-n approval for key creation, rotation, and deletion.
  - Deny direct key export except under tightly controlled, approved workflows.
- Key lifecycle:
  - Use envelope encryption with hierarchical key separation (root -> KEK -> DEK).
  - Rotate KEKs at least annually and upon suspected compromise; rotate DEKs more frequently (e.g., 90–180 days) or per data group, balancing re-encryption cost and risk.
  - Support cryptographic agility: document algorithms, key sizes, and migration plans for deprecation events.
- Crypto-shredding:
  - Design data structures so destroying KEKs renders associated data irrecoverable where retention and legal holds allow.
- Storage and handling:
  - Never hardcode keys or store them in source control or configuration files.
  - Use short-lived, scoped access tokens to request decryption from KMS; log all decrypt operations.

9. Decryption Controls and Access Governance
- Enforce least privilege:
  - Gate decryption through service-layer authorization aligned to data classification and purpose limitation.
  - Require just-in-time access for support workflows; time-bound, audited, and approved.
- Minimize plaintext exposure:
  - Decrypt only in memory; avoid writing plaintext to disk or logs.
  - Redact sensitive fields by default in UI and exports; require elevated approval for full views.
- Monitor and alert on anomalous decryption patterns (volume, frequency, off-hours access, unusual principals).

10. Data Lifecycle, Environments, and Transfers
- Ingestion: encrypt data at the earliest possible point; validate encryption before persistence.
- Processing: where plaintext is required, confine it to isolated services and memory; prefer streaming APIs to minimize materialization.
- Backups/archives: enforce encryption and access separation; verify restores; apply retention consistent with legal and business requirements.
- Non-production: use synthetic or de-identified data; if production data is necessary, retain encryption and restrict keys to test environments with strict controls.
- Third parties and vendors:
  - Use mTLS and HTTPS for transfers; prefer secure managed file transfer with server-side and client-side encryption.
  - Require contractual controls for encryption, key management, and breach notification.
  - Support BYOK/HYOK where mandated; conduct key custody reviews.

11. Logging, Telemetry, and Support Artifacts
- Sanitize PII before logging; if sensitive data must be logged for troubleshooting, encrypt log fields and restrict access.
- Encrypt call recordings, chat transcripts, screenshots, and file attachments; store encryption metadata alongside assets and enforce controlled playback/decryption.
- Enable tamper-evident logging for key usage and decryption events; retain logs per compliance obligations.

12. Validation, Monitoring, and Testing
- Maintain an encryption coverage inventory mapping all data stores and flows to encryption controls.
- Automate configuration checks:
  - Verify TLS versions, cipher suites, certificate expirations.
  - Detect unencrypted stores, volumes, buckets, indices, and queues.
  - Scan code and CI/CD artifacts for hardcoded secrets.
- Run periodic cryptographic health checks and penetration tests; include nonce reuse tests and AEAD misuse detection.
- Monitor KMS/HSM for key usage anomalies, failed decrypts, and policy violations; integrate with SIEM.

13. Incident Response for Cryptographic Events
- Key compromise procedures:
  - Immediately disable affected keys; rotate KEKs and re-encrypt impacted DEKs.
  - Assess blast radius via KMS audit logs; prioritize re-encryption for highly sensitive data.
  - Notify stakeholders and regulators as required (e.g., GDPR Articles 33–34); document whether effective encryption mitigated risk.
- Data exposure involving plaintext:
  - Identify encryption gaps; remediate controls; conduct root-cause analysis; update coverage inventory and guardrails.
- Preserve forensics: ensure logs are immutable and time-synchronized.

14. Compliance Alignment
- GDPR: implement encryption and pseudonymization per Article 32; maintain records of processing and DPIAs for high-risk processing; consider Article 34 breach notification exemptions where encryption renders data unreadable.
- HIPAA (if applicable): encrypt ePHI at rest and in transit; document key management and access controls; apply the Security Rule safeguards.
- PCI DSS (if payment data is handled): use tokenization; encrypt PAN when present; segregate cryptographic keys; enforce strict access controls.
- ISO/IEC 27001/27002 and NIST SP 800-53: align controls with SC-12/SC-13; document cryptographic architecture and operations.

15. Minimum Configuration Baselines
- Transport:
  - TLS 1.3 preferred; TLS 1.2 with ECDHE and AEAD only.
  - Approved cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256; for TLS 1.2, ECDHE-ECDSA/RSA with AES-GCM.
- Symmetric keys: AES-256 for data; unique 96-bit nonces for GCM; enforce nonce uniqueness per key.
- RSA: 3072-bit minimum; ECC: P-256 or X25519/Ed25519.
- Password hashing: Argon2id with parameters tuned to current hardware; review annually.
- Rotation: KEK annually or on compromise; DEK 90–180 days or event-driven; TLS certificates before expiry; immediate rotation on personnel changes affecting key custody.

16. Governance and Documentation
- Maintain up-to-date cryptographic architecture diagrams, key inventories, rotation schedules, and exception registers.
- Require security review and approval for any use of non-standard cryptography (e.g., deterministic or format-preserving encryption).
- Train HR and support staff on handling encrypted artifacts, access requests, and the implications of decryption approvals.

These guidelines establish a consistent, defensible encryption posture for HR and customer-service systems. Implement them via policy, automated controls, and continuous monitoring to minimize plaintext exposure, reduce breach impact, and meet regulatory obligations.

Principes directeurs de chiffrement des données pour microservices cloud natifs et clusters de bases de données

1) Objectifs et portée
- Garantir la confidentialité, l’intégrité et la résilience des données en transit et au repos dans des architectures microservices et des clusters de bases de données (SQL et NoSQL), sur Kubernetes et services managés cloud.
- Réduire le rayon d’impact par la segmentation des clés, la rotation systématique et une gestion centralisée des secrets.
- Assurer la conformité aux exigences réglementaires (RGPD/Article 32, ISO 27001/27002, ISO 27018, PCI DSS si applicable).

2) Normes cryptographiques et principes
- Utiliser exclusivement des bibliothèques et modules cryptographiques validés (FIPS 140-2/140-3 ou équivalent).
- Algorithmes recommandés:
  - Chiffrement symétrique: AES-256-GCM pour données applicatives; AES-XTS (256) pour chiffrement de volumes/disques.
  - Chiffrement en transit: TLS 1.3 (ou 1.2 avec ciphers AEAD), suites TLS: AES-GCM ou ChaCha20-Poly1305, PFS via ECDHE.
  - Signatures/certificats: ECDSA P-256/P-384 ou RSA ≥ 2048 (3072 recommandé).
- Privilégier l’«envelope encryption»: clés de données (DEK) chiffrées par des clés maîtres (KEK) dans un KMS/HSM.
- Chiffrement avant persistance; compression avant chiffrement si nécessaire.

3) Chiffrement des communications (en transit)
- Service à service (intra-maillage):
  - mTLS obligatoire entre microservices; identité de service forte (SPIFFE/SPIRE ou équivalent).
  - Rotation automatique des certificats et courts TTL (jours).
  - Interdire TLS 1.0/1.1 et ciphers non AEAD; activer PFS.
- Frontière externe (ingress/API gateway):
  - TLS 1.3, certificats gérés et renouvelés automatiquement, contrôle des suites.
  - Validation stricte des certificats, OCSP stapling si supporté.
- Messageries/streaming:
  - Kafka/RabbitMQ/NATS: TLS client-broker et broker-broker; authentification mutuelle; durées de vie de certificats courtes.
- Connexions bases de données:
  - TLS obligatoire client-serveur; authentification par certificat pour administrateurs/automates sensibles.
  - Chiffrement des canaux internes (réplication, gossip, cluster coordination).

4) Chiffrement des données au repos
- Couches de stockage:
  - Volumes et disques: chiffrement de volumes (LUKS/OS ou cloud provider), AES-XTS; activé par défaut pour toutes charges étatfull.
  - Objets (S3/GCS/Azure Blob): SSE-KMS ou équivalent; journaliser l’usage des clés (audit KMS).
- Microservices:
  - Chiffrement applicatif pour champs sensibles (PII, secrets métier) via AES-256-GCM avec envelope encryption; limiter les données en clair en mémoire.
  - Tokenisation/pseudonymisation pour minimiser exposition; chiffrement déterministe uniquement si nécessaire pour jointures, après évaluation du risque de corrélation.
- Bases de données:
  - RDBMS:
    - TDE si disponible (Oracle, SQL Server, MySQL InnoDB, MariaDB). Pour PostgreSQL communautaire, utiliser chiffrement de stockage (volume/disk) et TLS; pour services managés (RDS/Aurora/Cloud SQL), activer le chiffrement au repos via KMS.
    - Chiffrement des journaux (redo/undo/WAL) et backups si supporté; sinon garantir chiffrement du volume et du canal de sauvegarde.
    - Chiffrement au niveau colonne (ex. pgcrypto) pour données hautement sensibles; documenter les impacts sur index et recherches.
  - NoSQL:
    - MongoDB: chiffrement au repos (Enterprise), TLS client et inter-nœud; Client-Side Field Level Encryption si besoin de confidentialité bout-en-bout.
    - Cassandra: chiffrer tables/commitlogs, TLS client et intra-cluster.
    - Redis/Elasticsearch/OpenSearch: TLS, chiffrement de disque/volume; pour Elasticsearch/OpenSearch, activer node-to-node TLS.
- Snapshots et images:
  - Chiffrer toutes les sauvegardes/snapshots; utiliser des clés distinctes des clés de production; imposer la rétention et la protection contre la suppression (WORM si applicable).

5) Gestion des clés et des secrets
- KMS/HSM central:
  - Hiérarchie de clés: root/master (KEK) protégées par HSM/KMS; DEK par ressource/tenant/domaine de données.
  - Rotation:
    - Certificats: ≤ 90 jours.
    - KEK: annuelle ou selon risque/compliance; DEK: rotation régulière (ex. trimestrielle) ou à l’événement (compromission).
  - Segmentation:
    - Clés par environnement (prod/stage/dev), par tenant et par service; séparation des droits (key admins vs data owners).
  - Contrôles d’accès:
    - IAM avec moindre privilège; approbations multi-personnes pour suppression/export des clés; journaux d’audit immuables.
- Secrets management:
  - Utiliser un gestionnaire de secrets (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).
  - Éviter l’injection via variables d’environnement pour données sensibles persistantes; préférer volumes projetés/sidecars avec rotation.
  - Intégration CI/CD: chiffrer les manifests (SOPS/Sealed Secrets); empêcher la fuite de secrets dans les logs et images.

6) Spécificités Kubernetes et maillage
- Kubernetes:
  - Chiffrement au repos d’etcd via KMS provider; interdire le stockage de secrets en clair (base64).
  - RBAC strict, admission controllers pour valider politique TLS et usage de secrets.
  - CSI/KMS pour volumes; imposer StorageClasses chiffrés.
- Service mesh (Istio/Linkerd/Kuma):
  - mTLS global par défaut, exceptions documentées et approuvées.
  - Politique de chiffrement/ciphers uniforme; surveillance des identités SPIFFE; rotation continue des certificats sidecar.

7) Clusters de bases de données: exigences détaillées
- Transport:
  - TLS obligatoire pour réplication, backups, outils d’administration; authentification mutuelle pour inter-nœuds.
- Au repos:
  - Activer TDE quand disponible; sinon chiffrement de volumes et des répertoires de données/journaux.
- Backups:
  - Chiffrement côté client ou server-side KMS; vérifier la chaîne de chiffrement jusqu’au stockage objet; clés séparées des clés de production.
- Index et recherche:
  - Évaluer les impacts du chiffrement sur indexation et tri; pour exigences de recherche, étudier schémas de tokenisation ou services de recherche isolés avec contrôles stricts.
- Multi-tenant:
  - Isolation des schémas/déploiements et clés par tenant; tests de fuite inter-tenant.

8) Journaux, traces et données dérivées
- Interdire les données sensibles en clair dans logs/traces/metrics; appliquer masquage ou tokenisation.
- Chiffrement des archives de logs; rétention conforme; accès contrôlé et audité.
- DLP et egress controls pour prévenir exfiltration de données en clair.

9) Surveillance, détection et réponse à incident
- Superviser:
  - Événements KMS (usage, erreurs, tentatives d’accès), anomalies TLS (échecs, downgrade), certificats proches de l’expiration.
  - Intégrer au SIEM; corrélation avec identités de service.
- Tests:
  - Scans de configuration (ciphers, versions TLS), tests de pénétration focalisés sur canaux et stockage, revue de code pour crypto correcte.
- Playbooks:
  - Compromission de clé: révocation/rotation immédiate (certificats et DEK), re-chiffrement progressif des données, validation d’intégrité, communication contrôlée.
  - Procédures «break-glass» limitées, tracées et approuvées, avec expiration automatique.

10) Conformité et gouvernance
- RGPD:
  - Chiffrement et pseudonymisation comme mesures de sécurité (Art. 32); minimisation des données; contrôle d’accès; journalisation.
  - Localisation/résidence des clés et des données; évaluation d’impact (DPIA) pour traitements sensibles.
- Standards:
  - Politiques cryptographiques documentées (algorithmes, tailles de clés, durées de vie).
  - Preuves d’usage de modules validés (FIPS) si requis réglementairement.
- Audits:
  - Revue périodique des politiques, rotations, accès KMS, conformité des environnements.

11) Performance et résilience
- Activer l’accélération matérielle (AES-NI) sur nœuds; mesurer l’impact du chiffrement (latence mTLS, TDE).
- Éviter le double chiffrement inutile; documenter les couches de chiffrement et leur rôle.
- Procédures de re-chiffrement en ligne avec throttling; tests de restauration de backups chiffrés.

12) Critères de mise en œuvre et responsabilités
- Responsabilité centralisée de la politique crypto (Security/Platform), exécution déléguée aux équipes applicatives et DBA avec contrôles d’accès.
- Définir des SLO/SLA de sécurité (taux de connexions mTLS, couverture de chiffrement, délais de rotation).
- Documenter et valider toute exception par un processus de risque formel et une date d’expiration.

Contrôles minimaux obligatoires (baseline)
- TLS 1.3 pour toutes communications externes et internes; mTLS via service mesh.
- Chiffrement au repos activé pour tous volumes, bases et objets; backups chiffrés.
- KMS central avec rotation et journaux d’audit; clés segmentées par environnement/tenant/service.
- Kubernetes: chiffrement d’etcd via KMS, RBAC strict, secrets gérés via Vault/Cloud Secret Manager.
- Surveillance des événements crypto (KMS/TLS) et playbooks de réponse testés.

Ces lignes directrices doivent être intégrées dans des «guardrails» automatisés (policies d’admission, tests CI, scanners de configuration) afin d’assurer une application systématique et mesurable du chiffrement dans l’ensemble du paysage cloud natif et des clusters de bases de données.