Re: PosgreSQL Security Architecture

Thanks for the reply Laurenz. Of course the first thing that I thought of
to prevent man-in-the-middle was SSL. However, I also like to try to
address the issue in a way that seems to get at what they are intending. It
seemed to me that they wanted to do some configuration within the database
related to session IDs.

Regarding what is meant by "security configuration", I couldn't say for
sure. These guides are very much open to interpretation. In any case your
answers are helpful. Thanks again!

On Fri, Feb 12, 2016 at 3:02 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
wrote:

> Lesley Kimmel wrote:
> > I'm working to secure a PosgreSQL database according to a DoD security
> guide. It has many very generic
> > requirements that get more toward the internal architecture of the
> system that wouldn't be apparent to
> > the average admin. I was hoping someone might have some insight to the
> following requirements:
> >
> >
> > a) The DBMS must maintain the authenticity of communications sessions by
> guarding against man-in-the-
> > middle attacks that guess at Session ID values.
>
> You can have that if you use SSL encryption which is available in
> PostgreSQL:
> http://www.postgresql.org/docs/current/static/ssl-tcp.html
>
> It uses that widely-used OpenSSL software, so an encrypted database
> connection
> is as safe from man-in-the-middle attacks as OpenSSL is.
>
> > b) Check DBMS settings and vendor documentation to verify the DBMS
> properly handles transactions in
> > the event of a system failure. The consistent state must include a
> security configuration that is at
> > least as restrictive as before the system failure. This must be
> guaranteed.
>
> I don't understand what is meant by "security configuration" here.
> Is that defined somewhere?
>
> PostgreSQL handles system failures well, it uses a "Write Ahead Log" (WAL)
> to record
> transactions as they get committed. In the case of a system failure, the
> recovery process starts at the latest checkpoint (known consistent state)
> before the
> failure and exactly replays all WAL logged committed transactions up to
> the point of
> the crash:
> http://www.postgresql.org/docs/current/static/wal-intro.html
>
> After crash recovery, the database is in the same state as it was after
> the last
> successful transaction.
> The (unrecovered) database files of a crashed database are no less secure
> than
> any file system backup is.
>
> Yours,
> Laurenz Albe
>