Thanks for the discussion guys, I need to explain some more: my customer data on my server is name, email, address, order amount, products bought, etc. What I don't want is anyone other than myself access to this data, I am mainly concerned with financial data (the total sales history of my products) the issue I have is customers can request their registration code or change their email in my system, so I can't remove the data that is old, or encrypt it because it will need to be encrypted/decrypted with each database query wouldn't it, if that is even possible? Even so the encryption keys would need to be on the server, and if they have access to the server they have access to the keys.

One idea I had is to simply remove all of the dates and price information from my database on the server, and keep a database with the dates locally, then do a sync every month or so removing the older dates on the server. This wouldn't remove all of my historical sales data but would remove two important factors, timing and pricing.

I'm not really _that_ worried about it, but would like to protect it is possible.

If you want to control the access of data to just yourself then what braindigitalis propsed would work well for just restricting access to the data. I wonder why you think you can't encrypt the data. Just because the email address field changes it's value doesn't necessarily mean the encryption keys change. So, is this server a repository or something that customers access by placing an order on your system?

If you don't trust the admins don't use their services. There is no technological way to protect your database from the root user.

If you don't trust the admins don't use their services. There is no technological way to protect your database from the root user.

Seconded!

I think you are worrying too much. Bare in mind that most hosting companies will have hundreds, if not thousands of servers, with multiple clients on each one. I'm sure the admins have better things to do than look through everyones database looking at their financial details.

You may as well keep all cash you receive under your mattress to stop the bankers looking through your accounts and seeing how much you make...

[quote name='krez' timestamp='1307371420' post='4820092']
If you don't trust the admins don't use their services. There is no technological way to protect your database from the root user.

Seconded!

I think you are worrying too much. Bare in mind that most hosting companies will have hundreds, if not thousands of servers, with multiple clients on each one. I'm sure the admins have better things to do than look through everyones database looking at their financial details.

You may as well keep all cash you receive under your mattress to stop the bankers looking through your accounts and seeing how much you make...
[/quote]
That's a fairly naive outlook, honestly. Why do they care? There are several reasons why they might mettle in his data. They could sell it to his competitors, hold it hostage, use it against him in a competing business of their own, etc. Corporate espionage is a serious matter. The recent RSA hacks give a clear indication what lengths people will go to in order to get access to data including hacking military systems. What makes his company special? None of us know but it shouldn't just be discounted. I'm just putting this out there as a general warning to not take it lightly. Data security is one of my personal soapboxes because I have the belief that if a company asks for and stores certain data they should be accountable to take reasonable measures to protect that data and if they don't have the means to protect said data then they should ask for it or store it in any form. I was the principal developer for a company's e-commerce platforms and management liked to generally play fast and loose with data security and it was my job to make sure proper protections were in place. As far as I know we were never hacked in over a decade and their sites did millions per year in transactions and there were attempts so it's not like hacking groups didn't notice us. Fact is when it comes to financial data doing everything short of locking the data in a vault then encasing that vault in concrete followed by placing that in a bomb-proof steel enclosure is a "reasonable" measure.

Over half of the data breaches in the past few years have involved insiders (sometimes in collaboration with outside hackers and other criminals).

But security is a trade-off. The cost of better security (in money and work / time) gives diminishing returns, and at some point it isn't worth it anymore. So don't leave everything out in the open, but you have to figure out how much time and money is reasonable to protect your data sufficiently. You will never be 100% secure, but hopefully you can do a good enough job that nobody finds it worth the time and money to beat you. So don't store unencrypted credit card info or SSNs, and don't taunt Anonymous

Perhaps you should inquire about the security protections in place at whatever hosts you are considering, and bring up your concerns with them.

Being a web developer (hi) when ever we do anything that requires customer data we do the following.


1. Have a static server that is meant just for that data. You can use a VPS, a Dedi or a shared really it does not matter.
2. Have a seperate server that connects to that data only. The best way is VPS to VPS or dedi to VPS, etc. If you are working with a shared information server you run the risk of not being able to connect to it.

We usually work with people using WIndows so its easy to setup that without being logged into that server you cannot connect to the other server. If that didn't make sense, then imagine a remote SQL server where the only host that can connect to it is the host you define. We do it this way so that you have to know what your doing with our products on one server to get to the other server, as well as if someone injects inside or xss the main host it won't pull up the information since the validation won't be there from the main server.

-Mayple