Encryption Bundle Laravel Package

Product Decisions This Supports

• Data Security & Compliance: Enables encryption-at-rest for sensitive fields (e.g., PII, financial data, or proprietary content) in Doctrine entities, aligning with GDPR, HIPAA, or SOC2 requirements.
• Build vs. Buy: Avoids reinventing encryption logic for Symfony/Laravel apps, reducing dev time and security risks from custom implementations.
• Multi-Tenant SaaS: Supports organization-level data isolation (e.g., shared cipher keys per tenant) while preventing cross-tenant data leaks via user-specific decryption.
• Roadmap Prioritization: Justifies investment in security infrastructure for projects handling regulated or high-value data (e.g., healthcare, fintech, or enterprise apps).
• Legacy System Modernization: Simplifies retrofitting encryption to existing Doctrine-based applications without major architecture changes.

When to Consider This Package

• Adopt if:

  • Your app stores sensitive data in Doctrine entities and needs encryption-at-rest.
  • You’re using Symfony/Laravel with Doctrine ORM and want a lightweight, Doctrine-integrated solution.
  • Your threat model includes SQL injection, server breaches, or unauthorized data access (e.g., root-level attacks).
  • You require user/organization-specific decryption keys (e.g., shared data within a team but isolated from others).
  • Your team lacks cryptography expertise or time to build a secure custom solution.

• Look elsewhere if:

  • You need client-side encryption (this is server-side only; consider libraries like Tink or Libsodium PHP).
  • Your data is extremely large (e.g., multi-GB files)—this is optimized for entity fields, not file storage (use Vault or AWS KMS instead).
  • You require asymmetric encryption (e.g., for public/private key scenarios; this uses symmetric keys tied to user passwords).
  • Your app uses non-Doctrine databases (e.g., Eloquent-only Laravel apps; consider Laravel Encryption or Iron).
  • You need audit logs or key rotation—this package lacks built-in logging or automated key management.
  • The GPL-2.0 license conflicts with your project’s licensing (e.g., proprietary software).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us securely store sensitive customer data—like passwords, health records, or financial details—directly in our database without exposing it to breaches. Even if our server is compromised, attackers can’t decrypt the data without a user’s credentials. It’s like adding a deadbolt to our database doors, and it integrates seamlessly with our existing Symfony/Laravel setup. The cost? Minimal—just a Composer install and a few lines of code. The upside? Compliance with regulations, reduced risk of data leaks, and peace of mind for our users and stakeholders."

Key Outcomes:

• ✅ Regulatory compliance (GDPR, HIPAA, etc.) with minimal dev effort.
• ✅ Reduced breach impact—encrypted data is useless without user credentials.
• ✅ Scalable security—works for single users or entire organizations sharing data.
• ✅ Future-proof—avoids technical debt from custom encryption solutions.

For Engineering Teams:

*"The Sidus Encryption Bundle gives us a battle-tested way to encrypt Doctrine entity fields using symmetric keys tied to user passwords. Here’s why it’s a no-brainer:

• Zero cryptography headaches: Handles key derivation, storage, and decryption automatically.
• Doctrine-native: Uses custom DBAL types (encrypt_string, encrypt_text) for seamless ORM integration.
• User-level isolation: Each user decrypts only their own data (or shared org data) at login, via session keys.
• Lightweight: No heavy dependencies—just a Symfony bundle with clear usage patterns.

Trade-offs:

• Not for client-side encryption: Keys live in PHP sessions (mitigated by requiring user auth).
• GPL license: Ensure compatibility with your project (may need a commercial alternative if needed).
• No key rotation: Manual process for long-term security (plan for future upgrades).

Proposal:

1. Pilot: Encrypt 1–2 high-risk entity fields (e.g., user.ssn, patient.notes) in a non-production environment.
2. Performance test: Measure overhead on read/write operations (expect <5% latency).
3. Roll out: Phase encryption for all sensitive fields, with docs for devs on usage (e.g., @ORM\Column(type="encrypt_text"))."*

Alternatives Considered:

• Custom solution: Risky (cryptography is hard; reinventing wheels here could introduce vulnerabilities).
• Database-level encryption: Overkill for field-level needs and often vendor-locked (e.g., AWS KMS, Transparent Data Encryption).
• Laravel’s built-in encryption: Limited to strings/arrays, not Doctrine entities.