Encrypted Fields Bundle Laravel Package

Product Decisions This Supports

• Data Protection by Default: Automatically encrypts sensitive fields (e.g., PII, payment data) in Doctrine entities with minimal developer effort, reducing exposure risks and aligning with GDPR, HIPAA, or PCI-DSS requirements without manual implementation.
• Build vs. Buy Decision: Eliminates the need to build custom encryption logic (e.g., manual AES-GCM implementation) while providing auditability, key rotation, and compliance-ready features out-of-the-box.
• Roadmap Prioritization:
  • Short-Term: Secure high-risk fields (e.g., user credentials, financial data) in existing systems with <1 week of dev time.
  • Mid-Term: Extend to temporary data (e.g., session tokens, audit logs) or third-party integrations (e.g., encrypting data before sending to external APIs).
  • Long-Term: Integrate with automated compliance tools (e.g., Vanta, Drata) to dynamically scan for encrypted fields and generate reports.
• Use Cases:
  • SaaS Platforms: Protect multi-tenant data (e.g., customer portals, healthcare apps) with tenant-isolated encryption keys.
  • Legacy Systems: Retrofit encryption to Doctrine-based legacy apps without full rewrites or downtime.
  • Regulated Industries: Financial services, healthcare, or legal tech where data residency laws (e.g., EU GDPR, CCPA) mandate encryption-at-rest.
  • Internal Tools: Secure admin dashboards or internal databases storing sensitive metadata (e.g., employee records, API keys).

When to Consider This Package

Adopt if:

• Your application uses Doctrine ORM (Symfony or Laravel with Doctrine bridge) and stores sensitive data in database fields (not files or external services).
• You need field-level encryption (not full-database encryption like AWS KMS or TDE) with automatic key management (per-record keys encrypted with a master key).
• Compliance deadlines require encryption-at-rest (e.g., "Encrypt all PII by Q3") and you lack in-house cryptography expertise.
• Your team prefers open-source, MIT-licensed solutions with no vendor lock-in and minimal maintenance overhead.
• You’re using Symfony or can adopt Doctrine in Laravel with reasonable effort (e.g., laravel-doctrine package).

Look elsewhere if:

• You need client-side encryption (e.g., encrypting data before it reaches your API).
• Your data is already encrypted via database-level solutions (e.g., PostgreSQL TDE, AWS KMS, or Transparent Data Encryption).
• You require hardware security modules (HSMs) or FIPS 140-2 compliance (this uses OpenSSL, which may not meet all HSM requirements).
• Your application uses non-Doctrine ORMs (e.g., Eloquent in Laravel without Doctrine) or raw SQL.
• You prioritize serverless encryption (e.g., AWS Lambda + KMS) over application-layer solutions.
• Your team lacks Symfony/Laravel familiarity and cannot dedicate time to Doctrine integration.

How to Pitch It (Stakeholders)

For Executives: *"This package lets us automatically encrypt sensitive customer data—like credit card numbers, health records, or login credentials—without writing custom security code. It’s like adding a compliance shield to specific database fields, which helps us:

• Meet GDPR/HIPAA/PCI-DSS requirements with minimal effort.
• Reduce breach risk by encrypting data at rest (keys are never stored in plaintext).
• Save ~3 months of dev time compared to building encryption from scratch. The trade-off? A small upfront setup (~1 dev day) for long-term security. Competitors without this would struggle to prove data protection in an audit or breach investigation."*

For Engineering: *"This is a Symfony/Laravel bundle that handles AES-256-GCM encryption for Doctrine fields with zero crypto expertise needed. Key benefits:

• Drop-in integration: Just add [EncryptedField] to your entity properties (e.g., #[EncryptedField] private string $ssn;).
• Per-record keys: Each encrypted field gets a unique key, stored encrypted with a master key (you control where it’s stored, e.g., env vars or secrets manager).
• Performance: Encryption happens at the database layer, so no app slowdowns for read-heavy workloads.
• Key rotation: Built-in CLI command to rotate master keys and re-encrypt data (php bin/console gebler:encryption:rotate-key). Downsides:
• Requires OpenSSL (check your server setup).
• Doctrine-only: Not compatible with Eloquent or raw SQL.
• Migration needed: Adds an encryption_key table to your DB. Alternatives: If we can’t use Doctrine, we’d need to build custom encryption or use a Laravel-specific package like spatie/laravel-encryption."*

For Security/Compliance: *"This meets NIST SP 800-175B guidelines for key management (per-record keys encrypted with a master key) and supports data masking for audits. Key advantages:

• No plaintext keys: Master key is stored encrypted (e.g., in .env or a secrets manager), and per-record keys are never exposed.
• Audit trails: The encryption_key table logs all encrypted fields, which can be scanned for compliance (e.g., by Vanta or Drata).
• Key rotation: Supports zero-downtime key changes via CLI (though manual re-encryption is required for large datasets). Risks:
• Master key compromise exposes all per-record keys (mitigate with secrets manager + rotation policies).
• No built-in HSM support (if FIPS 140-2 is required, we’d need to integrate a third-party HSM). Recommendation: Pilot this for high-risk fields (e.g., PII, payment data) and expand based on audit feedback."*

For Product Managers: *"This enables us to ship security features faster without blocking the roadmap. For example:

• Feature: ‘Encrypt customer SSNs by default’ → Implementation: Add [EncryptedField] to the User entity and run a migration. Done.
• Compliance: ‘Prepare for GDPR audit’ → Leverage: Automated encryption + key management reduces manual work by 70%.
• Risk Mitigation: ‘Protect against data leaks’ → Outcome: Even if the database is breached, encrypted fields remain unreadable without the master key. Trade-offs:
• Dev effort: ~1 day to set up vs. ~3 months to build custom encryption.
• Flexibility: If we later need client-side encryption, we’d still need a separate solution. Next steps:

1. Assess: Identify top 3 sensitive fields to encrypt.
2. Pilot: Test with a non-production dataset.
3. Scale: Roll out to high-risk entities (e.g., Payment, MedicalRecord)."*