Exercise 3: The Key-Stored-Next-to-the-Data Mistake — Possible Solution
====================================================================

This setup provides little real security benefit because it violates
the one rule this chapter treats as non-negotiable: never store an
encryption key in the same place as the data (or the credentials
protecting that data) it's meant to secure.

Anyone who gains access to that Git repository — through a leaked
credential, an over-permissioned team member, a misconfigured
repository visibility setting, or the repository itself being
compromised — gains BOTH the database connection string (letting them
connect directly, per Chapter 2's threat model) AND the encryption key
needed to decrypt the very column that encryption was supposed to
protect, in the exact same place, in the exact same access event.

This is precisely what this chapter's tip box means by "encryption
without real key management is obfuscation, not security" — the
encrypted column still LOOKS protected (it's genuinely ciphertext in
the database), but anyone capable of reaching the repository has
everything needed to reverse that in one step. The encryption adds an
extra technical step for an attacker to follow, not a genuine
additional barrier, because the key that would make it a real barrier
was never actually kept separate from what it protects.

THE FIX: move the encryption key into a dedicated key management
service (a cloud KMS or HashiCorp Vault, as this chapter names), with
its own access controls entirely independent of whoever can read the
application's Git repository — so that access to the repository alone
is no longer sufficient to decrypt the protected data.