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

From: "Jonel Rienton" <jonel(at)rientongroup(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Mark Feller" <mfeller(at)mgako(dot)com>, "Ted Byers" <r(dot)ted(dot)byers(at)rogers(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: [Bulk] General advice on database/web applications
Date: 2006-03-27 21:45:34
Message-ID: 7ef91acf0603271345t7a765065p7fd4b46454e3b603@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/27/06, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> > 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
>
> this is natural. One solution is to put 2nd nic on the web server
> (carefully firewalled) for connections to the database. Theres lots
> of solutions to the problem.

a second nic would only introduce more headaches don't you think?
it's like opening another can of woop a$$ that'll eventually bite you
later.

>
> > 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
>
> I personally don't think this is a very good solution. You are
> complicating your architecture where database user accounts are much
> more natural and appropriate. create a web user and explicitly grant
> permisions to that user. This gives you the flexibility to do real
> stuff when you want to via functions...pg functions can operate under
> a elevated security when you want them to (check out create
> function...invoker/definer)
>
> > 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?
>
> again, I don't like this. you have to maintain the syncing proces and
> you are introducing timing issues, as well as greatly complicating
> constring checking. Factor in the complexity and the load. I would
> suggest doing this only as a last resort. If you must do this, I
> would suggest using the slony replicator.
>
> > 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?
>
> My suggestion would be to familiarize yourself with database security.
> If using postgres, this means reading over the administration
> chapters very carefully, as well as grant/revoke usage, etc.
>
> Merlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Jonel Rienton
mailto:jonel(at)rientongroup(dot)com
powered by: google

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Stark 2006-03-27 22:01:49 Re: [GENERAL] PANIC: heap_update_redo: no block
Previous Message Jonel Rienton 2006-03-27 21:43:32 Re: [Bulk] General advice on database/web applications