Skip to main content

Advanced Encryption Patterns

The earlier patterns illustrate field selection. These advanced sketches add key-version and transformation metadata; they still require an external key system, access model, and execution tests.

For a more detailed guide on these topics, please see the Advanced Encryption Patterns in the Encrypting Data tutorial.

Pattern 1: Multi-Key Strategy​

Using a single encryption key for all data is risky. A better pattern is to use separate keys for different data types based on their risk level. This is known as risk-based encryption.

  • CARD_ENCRYPTION_KEY: For PCI-DSS data. Highest security, most frequent rotation.
  • PII_ENCRYPTION_KEY: For GDPR/CCPA/HIPAA data (SSN, email). High security.
  • ADDRESS_ENCRYPTION_KEY: For location data.
  • TEMPORAL_ENCRYPTION_KEY: For sensitive dates.

This strategy limits the "blast radius" if a single key is ever compromised. You implement this by simply calling the encrypt_aes function with the appropriate key environment variable for each field, as demonstrated in the previous steps.

Pattern 2: Transformation audit metadata​

The following processor emits authored metadata about which transformation ran and why. A real audit design needs an independently protected destination, access rules, retention, and tested failure handling.

Partial snippet
Add an Audit Log Processor
- mapping: |
    root = this

    # Create an audit log entry
    let audit_log = {
      "event_id": uuid_v4(),
      "action": "ENCRYPT_PII",
      "timestamp": now(),
      "fields_encrypted": [
        "payment.card_number", "customer.ssn", "customer.email"
      ],
      "compliance_standards": ["PCI-DSS", "GDPR", "HIPAA"],
      "pipeline_id": "encrypt-production-v3"
    }

    root.transformation_audit = $audit_log

Pattern 3: Key Versioning & Decryption​

To handle key rotation, the version of the key used for encryption should be stored alongside the encrypted data.

See the complete configuration for the maintained encryption mapping and its ciphertext fields.

A corresponding decryption service would parse the version and retrieve the referenced key. Historical decryption still depends on retained keys, authorization, metadata integrity, and tested recovery procedures.