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
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 |