4

Scenario: We have our dedicated servers hosted with a hosting provider. They are running web apps, console apps along with the database which is Sql Server Express edition.

The applications encrypt/decrypt the data to/from the DB. We also store the keys in their server. So theoretically, the hosting provider can access our keys and decrypt our data.

Question: How we can prevent the hosting providers to access our data?

  1. We don't want hosting provider's users to just log into Sql Server and see the data.

  2. We don't want an un-encrypted copy of database files in the box.

To mitigate no. 1: Encrypting app.configs to not store plain text DB username and password.

To mitigate no. 2: Turn on EFS on Sql Server data folder. We could use TDE but the Sql Server is Web Edition version and the hosting company is going to charge us a fortune to use Enterprise Edition.

I'd really appreciate if you guys have any suggestions about above.

casperOne
  • 73,706
  • 19
  • 184
  • 253
user1520015
  • 73
  • 4

4 Answers4

1

You can help mitigate it, but prevention is probably impossible.

It's generally considered that if an attacker has physical access to the machine, they own everything on it.

If this is a concern, you should consider purchasing a server, a virtual server, or using a colocation center and providing your own machine or hosting it yourself entirely.

When you purchase a server, virtual server, or colocate your own hardware, the service provider doesn't have an account on your OS. If you use an encrypted file system, and only access your box via SSH (SSL/TLS), then they will not be able to easily access any data on your computer that isn't being sent out to the network.

The only fool proof way is to have your own hardware in your own secure location and bring the network to your box.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • As we encrypt the data, even if they get access to the hardware it'll be difficult (not completely impossible though) for them to decrypt it without the keys. So we need to find a way to use our keys so we don't have to store them in their disk. – user1520015 Jul 24 '12 at 18:02
  • 1
    @user1520015: At the end of the day, physical access means they can intercept the keys at whichever stage you send them to the server (or, indeed, replace the box with virtual hardware without you noticing), and keys are easy enough to read out of RAM ("cold boot" attacks are not difficult). – tc. Jul 24 '12 at 18:37
  • @tc, agreed. This is only mitigation. I changed "not able" to "not easily able". – Marcus Adams Jul 24 '12 at 18:50
  • @user1520015, you can store the key in memory only, which you enter at bootup. – Marcus Adams Jul 24 '12 at 18:52
  • @MarcusAdams: If you use an encrypted FS, you still need to enter the keys somehow during boot in a way that the attacker cannot intercept. I don't see how to do that short of tamperproof hardware and very good defenses against DPA/etc. – tc. Jul 24 '12 at 18:54
  • @tc, you don't think SSH is a secure way to enter your key? – Marcus Adams Jul 24 '12 at 18:55
  • I do understand that we cannot secure it completely. We don't consider our hosting provider as a threat anyway. However, we want to take some reasonable measure to secure the system. – user1520015 Jul 24 '12 at 21:26
0

It's possible to do database encryption such that the client does the decryption (though if your indexes are sorted, the server obviously needs to be able to figure out relative order of things in the index). I can't think of a link off the top of my head. However, if the client is the web app, there's not much you can do.

There are also various types of homomorphic encryption, but I'm not sure there's anything that scales polynomially. In any case, the overheads are huge.

tc.
  • 33,468
  • 5
  • 78
  • 96
0

I can suggest following, but it's still possible to break, but hard to perform.

First of all, you would need collocation, so you bring your own hardware. Best is to go to such extreme measures not for all your hosts, but only for critical one.

  1. Bring your own server tack to colocation
  2. Have chassis intrusion sensor configured, and better slap additional sensors all around the case.
  3. Have secure boot enabled
  4. Let bootloader extract protection keys from TPM after it checked status of chasis intrusion sensor.

Also verify that no new PCIe devices was installed. Or that IOMMU is configured to block devices from access to RAM, etc.

As an alternative, you could replace step 4 with downloading encryption keys from some external host, during boot, providing that host with cryptographic signature generated by TPM. In this case you would be able to revoke server access to keys remotely.

Crucial parts are secure boot and intrusion sensor. Most likely attacker would try opening your box using normal means, which would trigger sensor. Just make sure that sensor doesn't reset it's state when case is closed back.

But that won't help if attacker would slice case open in places not covered by sensor.

Then sophisticated attacker could attach wires to RAM lines or PCI lanes, and observe state of RAM.

This would give good enough security. But still breakable in theory. In practice should be quite secure.

Implementing such schema would be quite expensive in terms of engineer-hours. And can be quite brittle, system updates can break it. And you need to have way to unbrick system, if that was you who opened the case.

Bogdan Mart
  • 460
  • 8
  • 19
-1

I'm curious if there's a reason why you don't trust your hosting provider - or is this just a scenario?

If this is something you have to worry about, sounds like you should be looking at other providers. Protecting yourself from your hosting partner seems counterproductive, IMO.

Fan Zhu
  • 44
  • 2
  • 1
    We trust our hosting providers. This scenario is raised to us by our client (who are one of the largest banking groups in Europe). – user1520015 Jul 26 '12 at 10:23
  • Hosting provider is organisation that consists of individual humans. Even if organisation as a whole (it's CEO) is not intending to steal your data, that don't mean that it's employees won't get compromised/corrupt. For example they want quick buck for stealing your data. – Bogdan Mart May 21 '23 at 13:16