Re: Securing Postgres - Mailing list pgsql-general

From L van der Walt
Subject Re: Securing Postgres
Date
Msg-id 4343E7C1.3060003@lani.co.za
Whole thread Raw
In response to Re: Securing Postgres  (Richard Huxton <dev@archonet.com>)
Responses Re: Securing Postgres
Re: Securing Postgres
Re: Securing Postgres
Re: Securing Postgres
Re: Securing Postgres
List pgsql-general
The big problem is that the administrators works for the client and not
for me.  I don't want the client to reverse engineer my database.

There might be other applications on the server so the administrators do
require root access.

About the raw database files,  I can use encryption to protect the data.


Richard Huxton wrote:

>
> Don't forget to CC: the list!
>
> L van der Walt wrote:
>
>> Example:  On a MS Windows Server with MS SQL Server.  The
>> administrator with the administrator username and password can not
>> access the SQL server data.  He also needs the SA username and
>> password for the SQL server to do so.  He can stop and start the
>> server and so on but not access the data.
>
>
> He might not be able to directly access the DB, but he can certainly
> gain access to the raw data files/backups/passwords and gain access
> that way.
>
>> How do I secure a system in the same way with Linux and PostgreSQL.
>
>
> Unix security is a big topic, but basically if someone has root
> access, then they can gain access to anything on that machine.
>
> However, you can make it harder by requiring passwords for PG and not
> storing them on the machine (other than in their hashed form within
> the database). Of course that means you'll need to supply a password
> for any automatic tasks (e.g. autovacuum etc) which I don't see as
> being easy if you don't store them on the same machine.
>
> But basically, you need to be able to trust the person with the root
> login - it is more powerful than a standard MS-Windows administrator
> account. Do your administrators need root access?
> --
>   Richard Huxton
>   Archonet Ltd
>
>



pgsql-general by date:

Previous
From: L van der Walt
Date:
Subject: Re: Securing Postgres
Next
From: Tom Lane
Date:
Subject: Re: Cast to integer