On 3/27/06, Merlin Moncure <mmoncure@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx powered by: google
