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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
