Our small comapny wants to launch a paid service, hosted on the outsourced VPS server. The obvious risk is that the machine is physically not in our office and that possibly the database could be accessed by the stuff of the host. Are there any obvious security problems with VPS that I should consider? Second question would be: How to protect DB on the VPS server so I could be sure the host will not read data there? Thank you

  • 1
    well you should think of starting your own datacenter then,if you don't trust anyone :)
    – techno
    Commented May 22, 2014 at 9:22

3 Answers 3


As you have said, any VPS will be accessible by the hosting staff. You should also bear in mind that not all VPS providers will physically host their own servers so there may be a second set of staff who might gain access. This is why it is important to choose a VPS provider you trust and to test out their processes and understand them well.

Of course, your main driver for using a VPS will be cost and the lower the cost the fewer the processes and security certifications they will maintain.

Depending on the type of VPS host, there may be a level of shared resources as well that should be thought about.

In general though, this is rarely a problem unless you are working in a regulated area such as health or finance. In such cases you are unlikely to get away with the use of a VPS and you need to look for alternatives at least for part of your solution. For example, it is typical when taking payments to hand off to a secure payments service for the actual payment (e.g. PayPal or Worldpay).

When using a database with a web front end, you will have to embed the id and password somewhere on the system so a knowledgeable person with access to the hardware will certainly be able to gain access should they wish to.


Here are the elements that we had to take care of when we went down that same road:

The first aspects are the same wether you're dealing with physical hosting or virtual hosting:

  • Remember there is a legal aspect to this: in some cases, there are strict requirements regarding where and by whom your data can be hosted (in our case, we had to keep them on national soil). If you're trying to achieve or maintain some form of standard, you will have to make sure your provider has been audited for it (PCI, ISO 27001, etc...)
  • Work out a detail contract with your hosting provider about what you require him to do, what is the procedure for granting access to a data server, etc.
  • Run your disaster recovery plan by them. Once you're worked it out in theory, TEST IT!

And some element are more specific (although not completely) to virtual hosting:

  • Encrypt internal, server-to-server communication. That is important because you cannot trust the local network to be local any more and since you're sharing the infrastructure, you must be sure that even if your virtual infrastructure
  • For the same reason, use full-disk encryption everywhere you can. Doing so safely and securely in a virtual infrastructure, however, can be challenging so you might have to limit the scope of data-at-rest encryption to your databases (although you'll need to remember that the OS usually contains all data necessary to decrypt the database: it's up to you to find a secure solution for that, including keeping the decryption keys themselves in your own infrastructure).
  • Research and keep up-to-date on the virtual infrastructure used. That is important in order to understand the specific challenge posed by the tools you're going to be using. For instance, a friend of mine had to perform a post-mortem on a hosted VM and he was suprised to find other customer's data on the free sector of the hard drive image. Details on how it got was unclear because no one knew how exactly the solution was designed.
  • Research and vet the security of the management infrastructure used. There is no point in using 2-factor authentication in your app, for instance, if the management interface doesn't implement at least a similar level of security.
  • Have a detailed procedure in place on how a VM should be recycled. Ideally, you want to zero the virtual hard drives (all of them) before releasing them.

It will be extremely difficult: the provider will have physical access to the machine, and you won't. Worse, your system is going to be virtualized by someone other than you, which means that if you're paranoid, you can't even trust your OS.

Even with full disk encryption, you will have a hard time preventing someone from the staff from accessing your data (unless you never decrypt it, which would defeat the point).

So basically, if you don't trust the hosting company's staff, don't bother trying to lock them out. You won't. Choose a different company instead. And if you don't trust anyone with your data, look into in-house hosting.

Apart from that, VPS servers aren't so different from dedicated servers, security-wise. Just make sure to remove the possible pre-configured authorized SSH keys that some hosting companies add to their VM templates for maintenance purposes, and lock the box as you would lock any sensitive Linux machine.

Linode's tutorials are a good place to start if you're unsure what to do.

  • So hardware description would be at least something I could do, right?
    – Thamk
    Commented May 22, 2014 at 7:52
  • I'm sorry, but I'm not sure I understand what you mean by "hardware description"...
    – executifs
    Commented May 22, 2014 at 8:03
  • Omg, I thought hard disk encryprion :)
    – Thamk
    Commented May 22, 2014 at 8:13
  • Sure, it won't hurt, but remember that your disk will need to be unencrypted while your application runs (= likely all the time). Anyone snooping on the server at that moment would be able to access the database.
    – executifs
    Commented May 22, 2014 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .