Re: Authentication method for web app

From: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: Leonardo F <m_lists(at)yahoo(dot)it>, pgsql-general(at)postgresql(dot)org
Subject: Re: Authentication method for web app
Date: 2010-05-14 10:23:06
Message-ID: AANLkTikvwHja2KIb5QUh6-G3TsmSBsOaZqmQx6vmtArH@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 14, 2010 at 4:43 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:

> On 14 May 2010 09:08, Leonardo F <m_lists(at)yahoo(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Mead 2010-05-14 10:40:34 Re: pg_dumpall for Postgres Database Daily Backup
Previous Message Catalin BOIE 2010-05-14 09:43:02 Re: PANIC: corrupted item pointer: 32766