Data at Rest Encryption (DARE): Why It Matters in Fintech and How MySQL Handles It

Handling sensitive financial data? PLECCO helps fintech and operationally complex teams ship secure, compliant systems without the overhead of building an internal team. Schedule a call →

If your platform stores anything sensitive—payment details, bank account numbers, personal identifiers, transaction histories—then sooner or later someone will ask a deceptively simple question: “Is our data encrypted?”

The honest answer for most teams is “partly.” They have HTTPS, so data is encrypted while it travels between the browser and the server. But the data sitting in the database—on disk, in backups, on the snapshot that got copied to a laptop three months ago—is often stored in plain text. That gap is exactly what Data at Rest Encryption (DARE) closes.

Encryption in transit vs. encryption at rest

It helps to separate the two states your data lives in:

Data in transit — moving across a network. Protected by TLS/HTTPS. This is what the padlock in your browser means.
Data at rest — sitting on a disk, in a database file, in a backup, or on a storage snapshot. Protected by Data at Rest Encryption.

You need both. Securing data in transit but leaving it readable at rest is like using an armored truck to deliver cash… to a vault you leave unlocked. DARE makes sure that if the physical media is ever stolen, copied, decommissioned improperly, or accessed without authorization, what the attacker gets is unreadable ciphertext—not your customers’ account numbers.

Why this matters in fintech (and other regulated industries)

For fintech, rental, healthcare, and other operationally sensitive businesses, DARE is rarely optional. It shows up in three places at once:

1. Regulation and compliance

PCI DSS (Requirement 3) requires that stored cardholder data be rendered unreadable—encryption at rest is the standard way to satisfy it.
SOC 2 audits expect encryption of data at rest as a baseline security control.
GLBA, GDPR, and state breach-notification laws treat encrypted data differently from plaintext. In many breach scenarios, properly encrypted data can reduce or even eliminate mandatory breach-disclosure obligations—because the exposed data is unusable.

2. Real-world breach exposure

Most breaches don’t look like a Hollywood hacker typing furiously. They look like a misconfigured backup bucket, a stolen laptop, a decommissioned drive that wasn’t wiped, or a database snapshot shared with a vendor. In every one of those cases, encryption at rest is the control that turns “catastrophic breach” into “non-event.”

3. Customer and partner trust

Enterprise customers, banking partners, and payment processors increasingly send security questionnaires before they’ll do business. “Is data encrypted at rest?” is on every one of them. A clear “yes, with AES-256” shortens sales cycles and unblocks partnerships.

How Data at Rest Encryption actually works

At its core, DARE uses symmetric encryption—typically AES-256—where the same key encrypts and decrypts the data. The hard part isn’t the encryption math; it’s key management. If the key sits next to the encrypted data, you’ve locked the door and taped the key to it.

Mature systems use a two-tier key hierarchy:

Data Encryption Keys (DEKs) encrypt the actual data.
A Master Key (or Key Encryption Key) encrypts the DEKs and is stored separately—in a dedicated key manager such as a KMS (Key Management Service) or a hardware security module (HSM).

This separation is what makes the model strong: to rotate keys you only re-encrypt the small DEKs, not your entire dataset; and the master key never lives on the same disk as the data it protects. Good key management also means rotation (changing keys on a schedule), access control (only specific services can request decryption), and auditing (every key use is logged).

Where your database fits in—and how MySQL handles it

Your database is usually the single largest concentration of sensitive data you own, so it’s the most important place to get DARE right. Since our project runs on MySQL, here’s specifically how it works there.

MySQL (5.7+ and 8.0+) supports Transparent Data Encryption (TDE). “Transparent” means the application doesn’t change at all—your queries, ORM, and code stay exactly the same. MySQL encrypts data as it’s written to disk and decrypts it as it’s read into memory, automatically.

What MySQL can encrypt at rest

InnoDB tablespaces — file-per-table and general tablespaces (your actual table data and indexes)
Redo logs and undo logs (MySQL 8.0+)
Binary logs (replication logs, MySQL 8.0.14+)
The doublewrite buffer and temporary tablespaces (MySQL 8.0+)

The MySQL key architecture

MySQL uses the same two-tier model described above:

Each encrypted tablespace has its own tablespace key (a DEK).
A master encryption key encrypts those tablespace keys and is stored outside the database, in a keyring.

The keyring is the critical production decision. MySQL offers several keyring plugins/components:

keyring_file / component_keyring_file — stores the master key in a local file. Fine for development; not recommended for production because the key lives on the same host.
Production-grade keyrings — keyring_aws (AWS KMS), component_keyring_hashicorp (HashiCorp Vault), or Oracle Key Vault. These keep the master key in a dedicated, audited key manager—the right pattern for fintech.

What turning it on looks like

Once the keyring is configured, encrypting a table is straightforward:

-- Encrypt a single table
ALTER TABLE payments ENCRYPTION='Y';

-- Make encryption the default for all new tables (MySQL 8.0)
SET GLOBAL default_table_encryption = ON;

-- Rotate the master key (re-encrypts tablespace keys, not the data)
ALTER INSTANCE ROTATE INNODB MASTER KEY;

If you’re on a managed database like Amazon RDS for MySQL or Aurora, encryption at rest is even simpler: you enable it at instance creation, AWS KMS manages the keys, and it covers the underlying storage, automated backups, snapshots, and read replicas. The trade-off is that it must be enabled when the instance is created—you can’t toggle it on an existing unencrypted instance without a snapshot-and-restore migration.

Defense in depth: DARE is one layer, not the whole strategy

It’s important to be clear about what DARE does not protect against. Because TDE decrypts data transparently for any authorized connection, it does not stop:

SQL injection or a compromised application that has valid database credentials
An attacker who has stolen your application’s database password
Over-privileged internal users querying data they shouldn’t

DARE specifically defends the storage layer: stolen disks, leaked backups, mishandled snapshots, improperly decommissioned hardware. A complete posture layers it with:

Encryption in transit (TLS on every connection, including app-to-database)
Full-disk encryption at the OS/volume level (LUKS/dm-crypt, encrypted EBS volumes) as a second layer
Application-level encryption for the most sensitive fields, so even a valid DB connection can’t read them in the clear
Strong access controls, least-privilege credentials, and audit logging

The bottom line

For any business handling financial or personal data, encryption at rest is no longer a “nice to have”—it’s the difference between a lost laptop being an inconvenience and being a reportable breach. The good news is that with modern MySQL and managed databases, it’s well-supported, transparent to your application, and achievable without re-architecting your platform. The work is in doing it correctly: proper key management, the right keyring for production, key rotation, and layering it with the rest of your security controls.

Not sure where your data stands? We help fintech and operationally complex teams assess and close security gaps like this—encryption at rest, key management, and compliance readiness—without slowing down your roadmap. Talk to PLECCO →