On 3/27/06, Merlin Moncure <mmoncure@gmail.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@rientongroup.com
powered by: google