Application-Level Envelope Encryption for SOC 2 Compliance

Achieving SOC 2 compliance in modern SaaS applications necessitates going beyond traditional Role-Based Access Control (RBAC) and basic encryption-at-rest. While standard database encryption protects against physical theft, it offers no defense if an attacker compromises the running application or database credentials. This article proposes an application-level encryption architecture to ensure data is cryptographically isolated at the record level, proving that only authorized users access specific data and protecting it even if the perimeter fails.

Architectural Strategy: Hybrid Cryptography with Envelope Encryption

The core of this advanced security model is a hybrid cryptographic strategy known as Envelope Encryption, which combines the strengths of symmetric (AES) and asymmetric (RSA) encryption. This pattern addresses the dilemma of using fast symmetric encryption for large data while securely distributing keys.

1. Generate a Data Encryption Key (DEK): A unique, random, one-time-use DEK is generated for each document. AES-256-GCM is used to encrypt the document content with this DEK.
2. Wrap the DEK: The small DEK is then encrypted (wrapped) using the recipient's RSA Public Key (acting as the Key Encrypting Key - KEK).
3. Store Encrypted Data: Both the encrypted content and the "wrapped" DEK (the Envelope) are stored in the database.

For decryption, the user's RSA Private Key unwraps the DEK, which then decrypts the document. This ensures the document content is never encrypted with a shared, static password, enhancing security significantly. The use of AES-256-GCM provides integrity and authenticity, crucial for SOC 2, by generating an Authentication Tag to prevent 'Bit-Flipping' attacks.

Data Modeling for Cryptographic Isolation

The database schema is designed to support this hybrid model, ensuring cryptographic isolation. Key entities include:

• User Entity: Stores the user's RSA Public Key (KEK Public Component). The Private Key is managed by a secure session vault or HSM.
• Document Entity: Stores the AES-256-GCM encrypted content and a server-side envelope (DEK encrypted with a Master Key) for recovery and audit purposes.
• DocumentShare Entity: A many-to-many relationship table that stores the DEK wrapped specifically for each user it's shared with.

interface EnvelopeCryptoServiceInterface {
    public function generateDek(): string;
    public function encryptContent(string $plainText, string $dek): string;
    public function decryptContent(string $payload, string $dek): ?string;
    public function encryptDekForUser(string $dek, string $publicKey): string;
    public function decryptDekWithUserKey(string $wrappedDek, string $privateKey): string;
}