3

Possible Duplicate:
Securing an E-commerce site

I'm developing an e-commerce site in a LAMP environment. Is it advisable to separate data on to different servers (i.e. to have one server as the web server and another server to house transaction and other customer data)? In other words, from a security perspective is there any reason why I should not house all the data both for the e-commerce webshop and all backend customer and transaction data on a single machine and even in a single database)? [with daily backups of course].

Thanks in advance...

Peter

Community
  • 1
  • 1
    I'm torn on this question - it's a very interesting topic, the full answer will cover a lot of important subjects, but it's a little too broad and maybe even off-topic. To answer it in its current form we'd have to cover PCI compliance, SQL injection and data validation to name but a few - all of which are huge topics in themselves. – Widor Feb 22 '12 at 13:12
  • Already asked here: [link](http://stackoverflow.com/questions/659970/why-is-it-not-advisable-to-have-the-database-and-web-server-on-the-same-machine) [1]: http://stackoverflow.com/questions/659970/why-is-it-not-advisable-to-have-the-database-and-web-server-on-the-same-machine –  Feb 22 '12 at 13:56
  • Unless it really is your only option, please try to avoid processing card data yourself. Use the online solution provided by your merchant bank. Nobody will enjoy the process and continual expense of being validated for PCI compliance every quarter (minimum). If you really to need to handle cards yourself, seriously consider hiring a financial applications/processes expert. There's a lot to get wrong and high penalty to pay, if you do. – Cheekysoft Feb 22 '12 at 14:20

4 Answers4

1

The main reasons are that you want to put as many obstacles in the way of an attacker as possible, and put different security measures in place for your database server than for your web server.

In general, web servers - being exposed to the public internet and all that - are considered fairly vulnerable. Therefore, you want to keep as little sensitive data on those servers as possible. It would be tragic if a vulnerability in your web server configuration allowed access to the raw database files, or the backups etc. This is why most organizations put the web servers in a "DMZ" - a zone which is not fully trusted. The DMZ is often separated from the rest of the infrastructure via separate network segments and a firewall.

You also want to be able to have different security settings for your database server; often, different people should have access, and different apps should be installed. This is easier to achieve with a separate system.

I often explain this decision by reminding people that they don't leave their wallet on display in the car - you lock it away!

Neville Kuyt
  • 111
  • 2
0

The main reasons that sites are spread across > 1 server are load balancing, fail-over and security.

Load balance: If you have 1 customer a day on an internal site then 1 server is probably fine. If you have 10K customers / hour then you'll want to spread out the work.

Fail-over: If you have no reason to care whether your site is always up then 1 server is fine. IE If you can run to the office and turn it back on after the cleaning people unplug it, then no problem. If your business depends on this site being available then you'll want some sort of redundancy w/re DB, power, etc.

Security: putting everything on 1 machine means that if that machine gets compromised then you lose everything. Again, if that's not a big deal then you are fine.

As @widor said, this is a huge subject. My comments will barely scratch the surface.

ethrbunny
  • 101
  • 1
0

Its always best to have all sensitive data on a server that is not accessible externally. A firewall on this server should ensure the specific local IP addresses that can connect.

A good firewall on any external facing servers is also vital. Choose a good hosting company that provides monitored firewalls and you will be fine.

Implement the usual practices of strong passwords that must be changed regularly, and encrypt all information being sent between machines.

0

If your a small ecom provider doing a custom LAMP ECOM build and just getting started would agree with the other comments. You would not want to store any card data at all.

That said PayPal has a good ecom system as an example . I have used this one -https://www.paypal.com/webapps/mpp/merchant. It works well and you do not store any credit card data onsite. It allows you to do your own custom basket and shopping carts and then upon checkout the customer is redirected to paypal web services for credit card clearing.

(There are several others) Make sure on your ecom site- you have a tab about web security and talk how your are PCI compliant by using a service like this.

You will be storing some data in a DB within the LAMP stack. Customer information, Mailing address, Phone numbers. All of that data that is resting in the SQL DB should be encrypted and be behind stand DMZ architecture with hardened servers.

Also - you consider doing a simple web application pen test prior to launching the service.

If your site starts making money - consider spending some money on a continuous scan service like from Mcafee. http://www.sitelock.com/products.php . The pitch you will hear is that with the Mcafee scan service stamp on your site - consumers will feel better about your site security.

SecurityCrunch
  • 116
  • 2