+
+
Use of Encryption in <productname>PostgreSQL</productname>
+
+
+
+
There is increasing interest in having verifiable mechanisms+ to maintain the privacy of data in databases. In the United
+ States, legislation called
HIPAA (Health
+ Insurance Portability and Accountability Act) requires that
+ personal health information is handled securely. The European
+ Union has similarly been developing directives as to how personal
+ data is to be managed there.
+
+
Questions frequently come up as to what functionality+
PostgreSQL offers with regard to
+ supporting the use of data encryption. It uses and provides use of
+ encryption tools in several ways that may be useful to provide
+ protection against certain classes of attacks.
+
+
+
+
Passwords stored in MD5 form +
+
Passwords are normally not stored in+ plaintext
form in the database; they are hashed
+ using the built-in MD5 function, and that is
+ what is stored in the database.
+
+sample=# alter user foo password 'some dumb value';
+ALTER USER
+sample=# select usename, passwd from pg_shadow where usename = 'foo';
+ usename | passwd
+---------+-------------------------------------
+ foo | md5740daa4aaa084d85eb97648084a43bbb
+(1 row)
+
+
+
+
+
Connections protected using SSL+
+
There are various options to control how mandatory it is+ to use SSL to protect data connections. At the most
+ paranoid
end of the spectrum, you can configure
+ pg_hba.conf to have the database reject
+ connections that do not come in via
+ SSL.
+
+
The use of SSL, alone, is useful for protecting+ communications against interception. It may not be necessary
+ for connections that take place across a carefully controlled
+ network; if connections are coming in from less controlled
+ sources, its use is highly recommended.
+
+
Connections authenticated using SSL+
+
It is possible for both the client and server to provide+ to one another SSL keys or certificates. It takes some extra
+ configuration on each side where these are used, but this likely
+ provides stronger verification of identity than the mere use of a
+ text password.
+
+
Using OS level encryption for entire database+ partitions
+
+
On Linux, encryption can be layered on top of a filesystem+ mount using what is called a loopback device;
this
+ permits having a whole filesystem partition be encrypted on disk,
+ decrypted by the operating system. On FreeBSD, the equivalent
+ facility is called GEOM Based Disk Encryption, or
+
+
This mechanism may be expected to be useful for protecting+ against the threat that someone might pull disk drives out and
+ try to install them somewhere else to draw data off of them.
+
+
+
In contrast, this mechanism does nothing to protect+ against attacks when the filesystem is mounted, because when
+ mounted, the OS provides a view
of the filesystem
+ accessible in plain text form. Furthermore, you need some way
+ for the encryption key to be passed to the operating system in
+ order to mount the filesystems, which encourages having the key
+ accessible somewhere on the host that mounts the disk.
+
+
+
Using the contrib function library+ pgcrypto so the database engine manages
+ encryption of certain fields.
+
+
If much of the data can be in plain text form, and only a+ subset is particularly sensitive, this mechanism supports
+ treating them differently. The encrypted data is only ever
+ presented in unencrypted
form while it is being
+ communicated between client and server, and the use of an SSL
+ layer of superencryption
alleviates that
+ problem.
+
+
Unfortunately, in this approach, the encryption keys need+ to be present on the server, even if only for a moment, which
+ presents the possibility of them being intercepted by someone
+ with access to the database server. As a result, this mechanism
+ is not suitable for storage of data that is too sensitive for
+ system administrators to have access to it.
+
+
Using cryptographic tools on the client +
+
If it is not safe to trust the system administrators at+ least somewhat, you may find it necessary to encrypt data at the
+ client level such that unencrypted data never appears on the
+ database server. This sort of paranoia
is quite
+ appropriate for applications where it would be damaging for data
+ to be seen by inappropriate readers that might generally be
+ considered trustworthy, as can be the case with
+ medical and legal records.
+
+
Peter Wayner's book, Translucent+ Databases, discusses how to do this in considerable
+ detail.
+
+
+
+
+
projects / postgresql.git / commitdiff