Coming to PostgreSQL: On-disk database encryption

Transparent Data Encryption (TDE) is a popular approach to encrypting data at the storage layer, beefing up database security. While PostgreSQL has steadily climbed in popularity – especially among professional developers – it has so far lacked this enterprise feature, at least in open source. So claims Percona, an open source …

[elsergiovolador]

And then just patch me till I can get my...

Another week, another compliance-driven patch to a system not built for the modern surveillance-and-regulation nightmare we now call IT.

GDPR says "encrypt it." Security says "air gap it." Finance says "cloud it." Legal says "access it." And Postgres is just trying not to segfault.

[Charlie Clark]

Re: And then just patch me till I can get my...

If you don't understand something then it's best to say nothing instead of talking out of your arse. This kind of encryption, "at rest", significantly reduces the risk of data being stolen simply because access has been gained to the file system. You'd expect this as standard for anything dealing with sensitive personal information such as financial or medical data.

[David Newall]

why?

HDD & SDD already encrypt. Linux already has encrypted filesystems. How does this improve anything?

[kynetic29]

Re: why?

I'm way out of my area here but it seems like an appropriate step to me when considering the cloud environment. Since these systems are accessed online, there's no such thing as an HDD or SDD in the physical sense. If I get access to your server, I'm seeing every file there, regardless of whatever encryption you've added to it. This seems like it may help in those scenarios. If I access your server online, I still can't do anything with the files because they're separately encrypted from the storage medium. At least that's what this sounds like to me. Does the Linux encryption support this kind of scenario already as well? Or am I misunderstanding things?

[Anonymous Coward]

Re: why?

Every cloud thing is encrypted out of an abundance of fear. Considering AWS, where most of my experience is, you have the option of either using the default account key or your own per-instance KMS key for disk (ref: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html). The caveat here is that if someone gets access to your whole account, through IAM credential compromise or IAM permission stupidity, then they can access your data - just like if they root your box through SQL injection.

EC2 instances, in particular, are virtual machines. You can format virtual disks as you would any disk, use any filesystem (ext4, btrfs, zfs) that you like, and enable any (additional) encryption that you would like. RDS (managed database without a virtual machine) instances have a separate encryption flag to use your own key for at-rest encryption - but as always with anything aws, your data is never clear-text on disk.

All of this "extra" encryption is just multi-layer encryption - physical disk, logical disk, filesystem, now application layer - where no single layer of modern encryption has been compromised. Permissions, maybe - but it's usually the application layer that is compromised by external bugs, which fells all higher layers all at once. (Application layer and probably filesystem-layer encryption might save you if you set your permissions badly, where probably virtual-layer encryption will not.) All of the additional layers of encryption is yet-more compute overhead for data use -- power, latency, compute. (FWIW, modern encryption processing gets to - I read recently - 0.16 cycles per byte, with AVX-512 parallelization of PCLMUL(??) instructions.)

[Catch-the-Pigeon]

Re: why?

one advantage of this might be if you don't want to encrypt EBS volumes and use the native db encryption instead, this means the machine and disk are easier to image and copy to other regions or attaching the volume to another instance for recoverability is easier ? but in general most would enable the default settings of encrypting EBS volumes or equivalent in Azure. Has the disadvantage though it would offload encryption to the instance CPU's rather than let if offload ot dedicated hardware.

[Doctor Syntax]

Re: why?

Two alternative answers.

1. Without seeing the exact details I suspect this encryption includes everything between the client and the storage medium. If that's the case it provided protection over and above what the network may already provide (on-prem that might well be nothing) so that it can't be observed by an eavesdropper or queried by anyone without an encryption key.

2. The cynical answer: it ticks another box on the ISO9000 inspired checklist.

[HereIAmJH]

Re: why?

If I get access to your server, I'm seeing every file there,

Secure database systems are what I do, and it is this exactly. I have worked on systems where PCI DSS is the minimum requirements, and data is generally much more sensitive that that.

Encrypted mounts only protect you until it is mounted. Then, anyone with access to login can take your data. TDE, while not the ultimate in DB encryption, means they have to get access to your database system as well to get unencrypted data. Most TDE integrations also encrypt your backup files.

If your data is worth keeping, you should be using TDE.

My first thought on seeing this article is; finally.

[Anonymous Coward]

Re: why?

What are the odds that they can get access into your system without access into the applications running on the system?

[HereIAmJH]

Re: why?

My system administrators never had access to my app or it's data. They had the proper security clearances to manage the OS, but not to see the data. So they could delete my databases, uninstall my apps, shut the whole thing down. And be unemployed within the hour when system monitors started screaming at a level to alert upper management. But they could not see the data or even connect to the database. I suppose they could install wireshark and capture encrypted packets, but that would trigger a different system monitor.

It's all about layers of security.

[alain williams]

Re: why?

HDD & SDD already encrypt. Linux already has encrypted filesystems. How does this improve anything?

An encrypted file system helps if someone steals the disks it does not help if the operating system is compromised - ie someone breaks in - to a process running under the operating system the file systems will be seen unencrypted.

[Charlie Clark]

Re: why?

Also, there may be users with legitimate access to the disk but who should have no access to the data, or even the underlying files of the database system.

[DrXym]

Re: why?

A database will read & write a lot more than most applications so I suppose there is potential that built-in encryption yields better performance than what you get from an encrypted volume. Or perhaps people only want a particular table, or field encrypted instead of absolutely everything.

But then again maybe not. If the entire DB is encrypted then I don't think it would benefit performance to have postgres do the encryption. I think if individual tables / fields were encrypted then it might but there would are all kinds of weird corner cases to think about, like full text search, GIN indexing and other weirdness.

[HereIAmJH]

Re: why?

It's not storage encryption vs TDE, at least for performance reasons. They are different levels of security. I have worked for large corporations that were not comfortable with disk encryption, worrying that they might not be able to rebuild systems after a disaster. That is probably old thinking, but it still exists with corporate decision makers.

I remember when we first got the requirement to deploy TDE on SQL Server. There was a lot of concern over performance, so we did extensive testing. We were surprised that server load was negligible during the initial encryption and not measurable during day-to-day operations on a high volume transactional database.

I think if individual tables / fields were encrypted then it might but there would are all kinds of weird corner cases to think about, like full text search, GIN indexing and other weirdness.

Column level encryption only gets implemented on new systems or during a serious upgrade because it requires the application to be redesigned to encrypt/decrypt. Along with a full system outage while the app is upgraded at the same time the database is converted. And it's not just full text searches, it's all searches and indexes become difficult to impossible to implement. As far as table encryption, I haven't seen a use case where encrypting a whole table provides any benefit over TDE. Encryption is usually driven by specific column values, like SSN or cardholder data.

[TMr]

Re: why?

Read the article next time: centralized key management that's aligned with industry best practices.

The article literally says the GDPR now requires more than drive encryption.

How'd you get past the title to leave a comment?

[Anonymous Coward]

Marketing?

> where storage encryption alone is no longer sufficient to protect personal data at rest.

From what marketing department did this drivel originate?

[b0llchit]

Re: Marketing?

From what marketing department did this drivel originate?

Politicians.

[HereIAmJH]

Re: Marketing?

Real world experience, file system encryption is not sufficient. Not on the server, not on the SAN. There is too much phishing and privilege escalation. Too much crappy software used by businesses and mediocre staff. Would you leave your doors unlocked because you have security cameras? No reason to lock the server room, they have to get into the building fiirst...

[Anonymous Coward]

Re: Marketing?

> Would you leave your doors unlocked because you have security cameras?

Apples and oranges. Do you chain your TV to your wall, lock your kitchen drawers and cabinets, and your dresser, even while having locks on your doors?

No. That's absurd.

If someone is phished, if there is a logic error in the application, then the attacker has access -- it doesn't matter how many times things are encrypted. How often is it that an attacker exploits an OS-level vulnerability and gets shell access, without the ability to read API keys, without the ability to read application memory, and clearly that is not root and thus without the ability to read data straight off the disks - but still can read all data everywhere? The question makes you go - what?

The premise is absurd.