The webserver runs linux and I also have iptables on that server filtering out all but HTTP and SSH traffic. I have not yet implemented the database, and I am VERY reluctant to put the full db outside our "main" firewall because of the need to protect sensitive info. So my question, is how do the applications on the webserver interface with the database? My one thought for a solution is to have a more limited database hosted on the same machine as the webserver that would have customer account number, price lists, and product lists--enough for an order to be taken. Credit info, etc. is stored someplace more secure. After an order is taken, the webserver/database/something then forwards an "order placed" type of message to the main database. Maybe a synch is done between webserver database and main database every five minutes, where the main database pulls any new orders, and pushes any updated part lists, pricing etc. to the webserver db? My question, is would such a scheme be practical, or is there a "best practices" type of approach that I should consider instead, such as the suggestion in your next-to-last paragraph? Thanks. --Mark -----Original Message----- From: Ted Byers [mailto:r.ted.byers@xxxxxxxxxx] Sent: Monday, March 27, 2006 2:54 PM To: Mark Feller; pgsql-general@xxxxxxxxxxxxxx Subject: Re: [Bulk] [GENERAL] General advice on database/web applications > > I am developing a small web application. Currently, our web server is > sitting outside our firewall (running its own firewall), and the > application > being developed would let users do things like place orders. > > My question is...what and where is the database for this? > What do you mean when you say your web server is running its own firewall? I could well be wrong, but I am not aware of a web server that can run a firewall; web servers and firewalls are, as I understand them, quite different kinds of software, though I am aware of some hardware that have built in firewalls. Your question, though, doesn't make sense. If, as you say explicitly in your first sentence, that you're developing a small web application, then either you don't have a database and need to create it, or you have already created your database and know both where and what it is. If you haven't created it already, then you can create it and you have absolute control over where to put it and what RDBMS to use. The only circumstance in which I could imagine you having a database back end for your application but not knowing about it is if you bought hosting services from a company that provides such services. But if that's the case, then you ought to be asking that company about it. But if that's the case, they probably already have a ready made virtual store application for you to use, which makes developing your own unnecessary unless you're planning to do your own hosting, and that takes us back to you having complete control over what you use and where you put it. If I were to create such a web application as you describe, I'd create a database using PostgreSQL or something similar and have it live inside the firewall, configured to respond only to applications running behind the firewall. Under no circumstances would I want it to accept connections across the firewall. Similarly, I'd have my application server and my httpd server behind the firewall and configured to accept connections across the firewall but only from proxy servers set up in a DMZ. Since you are dealing with sensitive information such as financial data, you are going to have to design security into your application from start to finish, and then harden your entire network inside and out, including especially your firewall and each machine individually. You have some legal responsibilities to protect your clients' data. I'm told, by folk who ought to know, that you could face major problems if you fail to exercise due diligence in protecting your clients' data. Cheers, Ted
