The SOC 2 Blueprint: Beyond RBAC with AppLevel Infrastructure Isolation & Key Sharding. Part #2

#symfony #security #php #architecture

In Part 1, we implemented Application-Level Envelope Encryption. Our documents are now protected by per-record AES keys, wrapped in user-specific RSA envelopes. But a secure application is more than just secure data — it must have a secure infrastructure.

Under SOC 2, two critical principles often challenge developers:

Log Integrity (Audit Trail): You must prove that security logs are immutable and cannot be tampered with, even if the primary database is compromised.
Key Lifecycle Management: You must prove that your encryption keys are rotated and that the compromise of a single key does not result in the compromise of the entire system.

In this deep dive, we will implement Audit Trail Isolation using the Outbox Pattern and a Distributed Key Management Service (KMS) with Master Key Sharding.

Physical Isolation - The Three-Database Architecture

To fulfill SOC 2 requirements, we move away from a monolithic data store. We will configure three physically and logically separate SQLite databases:

Primary DB (data.db): Stores users, encrypted documents and envelopes.
Audit DB (audit.db): Stores immutable log entries. It should ideally be on a separate mount point with “Append-Only” permissions in production.
Keys DB (keys.db): Stores the encrypted pool of Master Keys.

Configuring Multiple Entity Managers

In Symfony’s doctrine.yaml, we define three connections and three entity managers. This allows us to inject a specific manager (e.g., @doctrine.orm.audit_entity_manager) into our services, ensuring they can only “see” their designated database.

# config/packages/doctrine.yaml
doctrine:
    dbal:
        connections:
            default:
                url: '%env(resolve:DATABASE_URL)%'
            audit:
                url: '%env(resolve:AUDIT_DATABASE_URL)%'
            keys:
                url: '%env(resolve:KEYS_DATABASE_URL)%'

    orm:
        entity_managers:
            default:
                connection: default
                mappings:
                    App: { type: attribute, dir: '%kernel.project_dir%/src/Entity', prefix: 'App\Entity' }
            audit:
                connection: audit
                mappings:
                    gedmo_loggable: { type: attribute, dir: '%kernel.project_dir%/vendor/gedmo/doctrine-extensions/src/Loggable/Entity', prefix: 'Gedmo\Loggable\Entity' }
            keys:
                connection: keys
                mappings:
                    KeyStore: { type: attribute, dir: '%kernel.project_dir%/src/Entity/KeyStore', prefix: 'App\Entity\KeyStore' }

The Immutable Audit Trail - Outbox Pattern

A common mistake is to write logs to a separate database synchronously. This creates two problems:

Performance: Every document save now waits for two database writes.
Atomicity: If the primary DB saves but the Audit DB fails, you have an unlogged action — a major SOC 2 violation.

Symfony Messenger + Outbox Pattern

The Outbox Pattern ensures that business data and the intent to log are saved in the same atomic SQL transaction.

Capture: During the primary Entity Manager’s onFlush event, we identify new LogEntry entities.
Queue: We dispatch an AuditLogMessage to the Symfony Messenger bus.
Outbox: We use the doctrine://default transport (or any other). This saves the message into a messenger_messages table in the Primary DB.
Process: A background worker consumes the message and uses the Audit Entity Manager to move the data to audit.db.

This architecture provides Asynchronous Persistence with Synchronous Reliability.

// src/EventListener/AuditLogMoverListener.php
public function onFlush(OnFlushEventArgs $args): void
{
    $uow = $args->getObjectManager()->getUnitOfWork();

    foreach ($uow->getScheduledEntityInsertions() as $entity) {
        if ($entity instanceof LogEntry) {
            // Track logs to be moved to the audit database
            $this->logsToMove->attach($entity);
        }
    }
}

public function postFlush(PostFlushEventArgs $args): void
{
    foreach ($this->logsToMove as $log) {
        // Dispatch to Messenger for asynchronous processing
        $this->messageBus->dispatch(new AuditLogMessage(...$log->getData()));

        // Remove from primary DB to keep it clean
        $args->getObjectManager()->remove($log);
    }
    $args->getObjectManager()->flush();
}

Distributed Key Management (KMS)

The “Server Master Key” used in Part 1 is a liability. If it’s stored in a .env file and that file is leaked, your entire backup recovery system is compromised.

The “Dual Lock” Root Key Strategy
We store our Master Keys in the keys.db. However, we never store them in plain text. Every Master Key is encrypted using a ROOT_KEY stored in the server’s environment.

To access a document’s DEK, you need the Keys DB AND the Environment ROOT_KEY.
This fulfills the SOC 2 requirement for “Separation of Duties” and “Layered Defense”.

Master Key Sharding - Reducing the Blast Radius

If you have 1,000,000 documents encrypted with one Master Key, the value of that key to an attacker is immense. Master Key Sharding distributes this risk.

We maintain a pool of 10 active Master Keys. When creating a document, we pick one deterministically:

// src/Security/MasterKeyStore.php
public function getActiveKeyData(): array
{
    $activeKeys = $this->getActiveKeyEntities();

    // Selection Algorithm: Pick one deterministically based on current millisecond
    $index = (int) (microtime(true) * 1000) % count($activeKeys);
    $selectedKey = $activeKeys[$index];

    return [
        'id' => $selectedKey->getId(),
        'key' => $this->decryptWithRootKey($selectedKey->getEncryptedKey())
    ];
}

By using millisecond-precision timestamps, we ensure a near-perfect distribution.

The Blast Radius Math

In a standard system, a compromised Master Key = 100% data loss.
In our sharded system, a compromised Master Key = ~10% data loss.
This 90% reduction in risk is exactly what SOC 2 auditors look for in high-maturity organizations.

Key Lifecycle & Rotation

Master Keys are not eternal. They have a lifecycle defined by activatedAt and deactivatedAt timestamps.

Automatic Selection for Encryption

When encryptDekForServer is called, the MasterKeyStore always provides a key from the currently active pool.

Versioned Decryption

Every encrypted payload in our system is prefixed with its Key ID: keyId:initializationVector:authenticationTag:cipherText

When an administrator or a backup process needs to decrypt a document from three years ago, the system sees Key ID: 14. It fetches Key #14 from the historical archive in keys.db, unwraps it with the ROOT_KEY and restores the document. This makes rotation completely transparent to the application logic.

// src/Security/EnvelopeCryptoService.php
public function decryptDekFromServer(string $serverEncryptedDek): ?string
{
    [$keyId, $encryptedPayload] = explode(':', $serverEncryptedDek, 2);

    // Fetch the specific key used for THIS record
    $masterKey = $this->masterKeyStore->getKeyById((int) $keyId);

    return $this->decryptContent($encryptedPayload, $masterKey);
}

Security Performance -The Stateful Listener

Moving logs and managing sharded keys can be computationally expensive. In our AuditLogMoverListener, we use an optimized Stateful Tracking pattern:

We use SplObjectStorage to track entities within a single request.
We only process the exact logs created in that request.
We avoid findAll() or heavy database scans, ensuring our security layer adds only negligible millisecond overhead to the user experience.

Final Architecture Summary

We have built a “Fortress” application:

Record-Level Privacy: Every document has a unique AES-256 key.
Zero Trust Logs: Audit trails are physically isolated and moved asynchronously via the Outbox pattern.
Sharded Authority: Master Keys are pooled and distributed, reducing the impact of any single failure.
Dual-Lock Protection: The KMS database is itself encrypted by an environment-level Root Key.

Closing Thoughts

SOC 2 compliance is often viewed as a “check-the-box” exercise in documentation. But we have the power to make it a technical reality. By using the patterns described in these two articles — Envelope Encryption, Outbox Isolation and Key Sharding — you aren’t just passing an audit. You are building a system that is fundamentally resilient to the most common failure modes in modern software.

Source Code: You can find the full implementation and follow the project’s progress on GitHub: [https://github.com/mattleads/SOC2Database]

Let’s Connect!

If you found this helpful or have questions about the implementation, I’d love to hear from you. Let’s stay in touch and keep the conversation going across these platforms: