Add encryption section to documentation.
Christopher Browne
This commit is contained in:
Bruce Momjian
parent
545828a754
commit
99354440b5
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.315 2005/04/23 03:27:40 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.316 2005/05/08 03:29:06 momjian Exp $
|
||||
-->
|
||||
|
||||
<chapter Id="runtime">
|
||||
|
|
@ -5109,6 +5109,132 @@ psql -h localhost -p 3333 template1
|
|||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="encryption-approaches">
|
||||
<title>Use of Encryption in <productname>PostgreSQL</productname></title>
|
||||
<indexterm zone="encryption-approaches">
|
||||
<primary>encryption</primary>
|
||||
</indexterm>
|
||||
|
||||
<para> There is increasing interest in having verifiable mechanisms
|
||||
to maintain the privacy of data in databases. In the United
|
||||
States, legislation called <acronym>HIPAA</acronym> (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.</para>
|
||||
|
||||
<para> Questions frequently come up as to what functionality
|
||||
<productname>PostgreSQL</productname> 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.</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para> Passwords stored in MD5 form </para>
|
||||
|
||||
<para> Passwords are normally not stored in
|
||||
<quote>plaintext</quote> form in the database; they are hashed
|
||||
using the built-in MD5 function, and <emphasis>that</emphasis> is
|
||||
what is stored in the database. </para>
|
||||
|
||||
<programlisting>
|
||||
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)
|
||||
</programlisting>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem><para> Connections protected using SSL</para>
|
||||
|
||||
<para> There are various options to control how mandatory it is
|
||||
to use SSL to protect data connections. At the most
|
||||
<quote>paranoid</quote> end of the spectrum, you can configure
|
||||
<filename>pg_hba.conf</filename> to have the database reject
|
||||
connections that do <emphasis>not</emphasis> come in via
|
||||
SSL.</para>
|
||||
|
||||
<para> 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.</para></listitem>
|
||||
|
||||
<listitem><para> Connections authenticated using SSL</para>
|
||||
|
||||
<para> 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. </para></listitem>
|
||||
|
||||
<listitem><para> Using OS level encryption for entire database
|
||||
partitions</para>
|
||||
|
||||
<para> On Linux, encryption can be layered on top of a filesystem
|
||||
mount using what is called a <quote>loopback device;</quote> 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
|
||||
<acronym>gbde</acronym>.</para>
|
||||
|
||||
<para> 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.
|
||||
</para>
|
||||
|
||||
<para> In contrast, this mechanism does nothing to protect
|
||||
against attacks when the filesystem is mounted, because when
|
||||
mounted, the OS provides a <quote>view</quote> 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.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> Using the contrib function library
|
||||
<function>pgcrypto</function> so the database engine manages
|
||||
encryption of certain fields.</para>
|
||||
|
||||
<para>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 <quote>unencrypted</quote> form while it is being
|
||||
communicated between client and server, and the use of an SSL
|
||||
layer of <quote>superencryption</quote> alleviates that
|
||||
problem.</para>
|
||||
|
||||
<para> 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. </para></listitem>
|
||||
|
||||
<listitem><para> Using cryptographic tools on the client </para>
|
||||
|
||||
<para> 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 <quote>paranoia</quote> 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.</para>
|
||||
|
||||
<para> Peter Wayner's book, <citation>Translucent
|
||||
Databases</citation>, discusses how to do this in considerable
|
||||
detail.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
|
|
|
|||
Loading…
Reference in New Issue