Encrypting Amazon RDS Resources | Hacker News Reader

Encrypting Amazon RDS Resources

docs.aws.amazon.com

80 pointsmakmanalp29 comments

This is encrypting the disk that the RDS instance is using to store the data right? And amazon are holding the decryption key.

What exactly is this protecting against? (Genuine question not rhetoric).

Without encryption, I guess someone with physical access to an Amazon data center could pull a drive somewhere and grab the data.

With encryption, that same person would also have to get hold of the key as well, but nothing seems to be said about the key storage being in some separate super secure location, so could that same malicious employee with physical access not also go on a key hunt and end up getting access anyway? So it's just another "layer" of protection not totally impossible.

.... or am I missing something crazy obvious where an unencrypted RDS disk is accessible by some other means? Maybe via to nature of disks being reused without proper cleaning or similar?

Keys are stored within AWS Key Management Service, which relies on Hardware Security Appliances (a dedicated tamper-proof hardware appliance just for storing secrets). For EBS, encryption works like this (I imagine RDS will work similarly):

  The basic steps to encrypt data being written to an EBS volume are:

  1. Amazon EBS obtains an encrypted volume key under a customer master key through AWS KMS, and stores the encrypted key with the volume metadata.

  2. When the EBS volume is mounted, the encrypted volume key is retrieved.

  3. A call to AWS KMS over SSL is made to decrypt the encrypted volume key. AWS KMS will identify the CMK and make an internal request to an HSA in the fleet to decrypt the volume key, and will return the volume key back to the customer over the SSL session.

  4. The volume key is stored in memory and used to encrypt and decrypt all data going to and from the attached EBS volume. Amazon EBS retains the encrypted volume key for later use in case the volume key in memory is no longer available.

More info: https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Detai...

I see, thanks.

So there _is_ extra¹ care taken over the protection of the keys vs the protection of disks to significantly raise the barrier.

¹not saying that they just leave their data centers open to the public, but you know what I mean :)

I went to an Encryption and Key Management in AWS presentation at the pop-up loft in San Francisco, and they explained how their KMS system is built on shared Hardware Security Modules (HSMs) that are tamper evident and have hardcoded logging. So any decryption event is logged and you'd have to physically break into the HSMs to prevent a log entry (and thus have to replace lots of equipment).

This basically meant that it would cost millions of dollars to secretly decrypt something where the user wouldn't be able to see a log of it. It's basically a "porcupine defense" where governments won't bother asking for secret decryption since it would cost so much money. They specifically designed the infrastructure to be extremely expensive to hide any log altering. It also means that governments will more likely try compromising the targets system first, rather than send a secret decryption order to Amazon.

EDIT: Additionally, since the HSMs are shared, any physical tampering would require them to notify and migrate all the other users on that HSM that are under regulations (HIPAA, PCI DSS, etc.). AWS would charge a lot of money for this sort of migration.

It's to comply with IT policies that require data to be encrypted on disk. Now, businesses that wouldn't use RDS before can now tick that last box off on the IT security audit.

It is a requirement for HIPPA compliance.

Basically, it's protecting you against a screw-up in Amazon procedures where somebody physically gets the disk media that your data is stored on. It may also protect you against a compromise affecting the hosts that your VMs or storage are running on.

Is it useful? If it prevents you having to do a breach disclosure, absolutely yes.

The keys used by KMS are stored in an AWS-managed hardware security module (HSM) on-site and never go outside that data center. This means that even if the person had physical access to the data center, they should not be able to extract the decryption keys because HSMs are specifically designed to prevent that. If it was an Amazon employee that had super-user privileges over that HSM for management purposes...who knows.

Stealing physical hard drives is really the only thing being protected against here, as far as I can tell. It seems that any instance in your account can access any encrypted volume in your account - there's no access control. I imagine Amazon is working on that, but right now if someone were to e.g. get permission to spin up an instance with stolen API keys, then they'd have access to all your encrypted volumes. Someone correct me if I'm wrong.

I've actually rolled my own device encryption in the OS layer using LUKS and puppet. The puppet master is heavily locked down, and holds the decryption keys, which are only available to the correct client and then only ever stored in memory. So this provides somewhat more defense in depth than the AWS native solution.

I wonder if it has anything to do with the fact that the CIA is now an Amazon customer. Hopefully they don't also become Amazon's employees.

The NSA almost certainly has staff posing as Amazon Web Services employees. They would be negligent not to have infiltrated the company.

Your comment implies that the American surveillance apparatus hasn't already infiltrated Amazon... but do you really think that is possible?

One idea is to audit the use of the encryption key.

I'm curious how one could implement dual control of keys on Amazon, or if auditing would have ot be a compensating control for it.

Calls made to KMS are logged in CloudTrail where they can be used for auditing.

I'm assuming CloudTrail logs can be sent to another AWS account with no delete access from the sending account?

Great news, I might finally be able to use RDS now. I'm always impressed that the AWS team seem to be on the ball with improvements - whenever I think "I could really do with X feature", they come out with it a few months later.

Having said that, the limitations at the bottom are a little arduous if you're already on RDS. Can't encrypt an existing unencrypted database. So you'd think to take a backup and restore to a new encrypted DB, but you can't do that either. Nor can you stream from an unencrypted master to an encrypted replica, freeze and swap over. Bit of a pain there!

It looks great but it appears the smallest encrypted RDS is medium. I would love to see it for the micro or small instances (my level :-) ).

Encrypting backups makes a lot of sense. Is encrypting an active db a requirement in some enterprise environments?

HIPAA requires encryption-at-rest of any personally identifiable information.

PCI compliance requires that, IIRC.

This new feature encrypts the entire database. PCI compliance requires only to encrypt the account number, i.e. the credit card number.

Been a while since I've had to deal with PCI, but I don't think encryption is required.

It is now. From https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...

PCI Requirement 3.4:

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

- One-way hashes based on strong cryptography, (hash must be of the entire PAN)

- Truncation (hashing cannot be used to replace the truncated segment of PAN)

- Index tokens and pads (pads must be securely stored)

- Strong cryptography with associated key-management processes and procedures.

PCI Requirement 3.5

Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

Perhaps this is new in v3 since I was working under v2 at the time. It certainly makes sense that the card number must be stored encrypted.

http://www.csoonline.com/article/2124346/compliance/end-to-e...

> Section 3 provides the high-level details around encryption. At a minimum, PCI requires the PAN (primary account number) to be rendered unreadable anywhere it is stored, including portable digital media, backup media and logs.

It is if you store credit card numbers.

Yes, it's 2014 and credit card numbers should not be stored and tokenization is the standard.

Somebody's got to store the number eventually.

Actually, not really.

Reply on news.ycombinator.com