If your webserver is compromised, it's only a matter of time before they get to through to your DB, so going through the hassle of replication is not worth it IMHO as they can still compromise the DB on the front and cause havoc.
I would suggest that if you want another layer, put a reverse proxy for the clients to get webpages from, then put your webserver behind that. That way no client has direct access to your webserver.
You can put business objects on your database server as someone suggested, but typicaly most people want all their RAM available for the database, and don't really want memory hungry objects cluttering up memory, which they inevitably do. This is also an increase in complexity, and will increase development time significantly if you have to access all data through remote object calls instead of simple SQL. Typicaly this is not regarded as a big enough improvement in security to warrant the extra development hassle (at least not to people who want their websites yestarday, which I have found is virtualy everyone).
Alex.
On 3/27/06, Mark Feller <mfeller@xxxxxxxxx> wrote:
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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
