Skip to content
Muhammet Şafak
tr
Asked by: Çağrı Answered:

Why is keeping the key in .env risky when encrypting sensitive financial data — what do KMS/Vault give you?


Question

We have to keep users' national ID numbers or credit card tokens in the DB encrypted for KVKK/GDPR; an attacker who breaches the DB must not be able to read this data. When using symmetric encryption (AES-256) at the application layer, what are the risks of keeping the encryption key in a `.env` file on the app server? How does integrating AWS KMS or HashiCorp Vault make the architecture secure?

Answer

Short answer: encrypting the field with AES-256 is right, but if the key sits in the .env next to the app, an attacker who reaches the server gets both the data and the key — the encryption buys you almost nothing. The whole point of KMS/Vault is to separate the key from the data.

The core of the problem: if the encrypted data and the key that opens it sit in the same place, the two are effectively one secret. Security comes from physically/permission-wise decoupling the key from the data.

  1. The key in .env is risk concentrated in one spot. An attacker who takes the server (or causes a backup/.env leak) gets the encrypted DB and the key at the same time. The key also sits in plaintext in the file, it’s hard to rotate, and there’s no trace of who decrypted what and when.
  2. KMS/Vault never hand the raw key to the app. The app calls KMS to encrypt/decrypt, or uses envelope encryption: the master key stays in KMS and encrypts a separate data key per record. So compromising the DB — or even the app server — doesn’t hand over plaintext, because the master key was never there.
  3. You gain central rotation, audit, and IAM-scoped access. KMS/Vault rotate the key centrally, write every decrypt to an audit log, and scope access via IAM/policy. “Which service decrypted which data, and when?” becomes answerable — critical under a compliance (KVKK/GDPR) audit.
  4. Prefer tokenization for national IDs/card data. Where possible, don’t hold the sensitive value at all: keep the real value in a vault/provider and pass only a token around the system. Then the vast majority of the system never sees the sensitive data — even if it leaks, what’s taken is a meaningless token.

Bottom line: envelope encryption via KMS or Vault; the key never in .env, but somewhere that’s rotated + audited. Tokenize wherever you can. One more note: full-disk encryption or pgcrypto alone isn’t enough — a live DB connection still reads plaintext. The real protection comes from separating the key from the data and never giving the app the raw key.

Tags: #data#security#infrastructure
Share:

Comments

Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.

More Questions

All questions
Bora

Canary or Blue-Green deployment for a fintech API?

Make Canary your default for routine releases (smallest blast radius), and keep Blue-Green for big cutovers where you want an instant flip/rollback. The real pivot is the database: both demand backward-compatible (expand/contract) schema changes.

#ci-cd#deploy#resilience

Search the site

Start typing to search posts, projects and pages.

Esc to close Powered by Pagefind