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
(Leonardo F <m_lists@yahoo.it>)
|
| 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: