Re: [Bulk] General advice on database/web applications

The solution that I have seen typical is to have both webserver and database
machine behind a firewall both NATed, with only HTTP and HTTPS ports open on
the webserver. SSH is not open, as trusted clients connect via the VPN in
the firewall. The database machine, unlike the webserver, will not have a
static NAT entry, only a private IP address, and will only permit
connections from the webserver via postgres conf.

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(at)mgako(dot)com> 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(dot)ted(dot)byers(at)rogers(dot)com]
> Sent: Monday, March 27, 2006 2:54 PM
> To: Mark Feller; pgsql-general(at)postgresql(dot)org
> 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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>