Re: Authentication method for web app - Mailing list pgsql-general

From Scott Mead
Subject Re: Authentication method for web app
Date
Msg-id AANLkTikvwHja2KIb5QUh6-G3TsmSBsOaZqmQx6vmtArH@mail.gmail.com
Whole thread Raw
In response to Re: Authentication method for web app  (Ivan Voras <ivoras@freebsd.org>)
Responses Re: Authentication method for web app
List pgsql-general


On Fri, May 14, 2010 at 4:43 AM, Ivan Voras <ivoras@freebsd.org> wrote:
On 14 May 2010 09:08, Leonardo F <m_lists@yahoo.it> wrote:
>> Personally I would lean toward making
>> the bulk of security within the
>> application so to simplify everything - the
>> database would do what it
>> does best - store and manipulate data - and the
>> application would be the
>> single point of entry. Protect the servers - keep
>> the applications (like
>> ssh, php, apache, your application) updated and make
>> sure you have good
>> and frequent backups.
>
>
>
> Thank you for your reply.
>
> Anyone else? How do you "secure" your db used by
> webapps?

 I would avoid using a 1-to-1 for web users having access to the db.  Keep your database server secure, and keep your connection info inside the app.  Look at it this way:
 
   If you properly secure the system, the chances of a malicious user getting access to the DB are pretty slim, if you do the '1-to-1' that you're talking about, you've effectively given the keys to your database to everyone who can get an account.
 

Basically what I've said:

1) find all points of entry to the db (i.e. the application), secure them

 
2) keep the server itself secure (applications patched, firewall
enabled with custom rules to protect the db if necessary, only trusted
local users etc.) If the app and the db are on different servers,
consider a direct (patch cable) link between them or if the structure
is more complex a switch, remove them from Internet, possibly make a
DMZ, etc.

I think this point number 2 is pretty important. If at all possible, keep the webapp separate from the database, and keep the database server on a fairly restrictive firewall.  This means that someone has got to get in to the webapp, then hop to the database server, it just adds another layer of mis-direction for any would-be evil doers.


 Make sure to have a well thought-out pg_hba.conf, many people overlook this step in favor of a less-headachy 

  host    all   all 0.0.0.0/0 md5

  Line.  The above says "Let everyone connect to everything from everywhere with a password".  Even if your database is behind a firewall, Be Explicit with your access controls:

host    webuser      prodDb     192.168.30.12/32    md5
host    devuser      prodDb      10.1.1.5/32            md5

  etc....

  Don't give it all away.

At the same time, restrict the number of users in your organization that have ssh access to the machine.  My experience (even with developers) is that given the chance, they will create a password that = their username, or something even dumber, and the box WILL get hijacked.   Keep remote console access isolated to a few people that understand the stakes.

Good luck

--Scott


 
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: Catalin BOIE
Date:
Subject: Re: PANIC: corrupted item pointer: 32766
Next
From: Scott Mead
Date:
Subject: Re: pg_dumpall for Postgres Database Daily Backup