制定数据加密指导原则

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.