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