mirror of
https://github.com/postgres/postgres.git
synced 2025-09-02 04:21:28 +03:00
Backpatch encryption doc section to 8.0.X.
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.301.4.4 2005/03/24 04:36:55 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.301.4.5 2005/05/09 17:14:47 momjian Exp $
|
||||
-->
|
||||
|
||||
<chapter id="runtime">
|
||||
@@ -4827,6 +4827,161 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
</important>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="encryption-approaches">
|
||||
<title>Use of Encryption in <productname>PostgreSQL</productname></title>
|
||||
|
||||
<indexterm zone="encryption-approaches">
|
||||
<primary>encryption</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> offers encryption at several
|
||||
levels, and provides flexibility in protecting data from disclosure
|
||||
due to database server theft, unscrupulous administrators, and
|
||||
insecure networks. Encryption might also be required by government
|
||||
regulation, for example, for medical records or financial
|
||||
transactions.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry>
|
||||
<term>Password Storage Encryption</term>
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
By default, database user passwords are stored as MD5 hashes, so
|
||||
the administrator can not determine the actual password assigned
|
||||
to the user. If MD5 encryption is used for client authentication,
|
||||
the unencrypted password is never even temporarily present on the
|
||||
server because the client MD5 encrypts it before being sent across
|
||||
the network. MD5 is a one-way encryption --- there is no
|
||||
decryption algorithm.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Encryption For Specific Columns</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The <filename>/contrib</> function library
|
||||
<function>pgcrypto</function> allows certain fields to be stored
|
||||
encrypted. This is useful if only some of the data is sensitive.
|
||||
The client supplies the decryption key and the data is decrypted
|
||||
on the server and then sent to the client.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The decrypted data and the decryption key are present on the
|
||||
server for a brief time while it is being decrypted and
|
||||
communicated between the client and server. This presents a brief
|
||||
moment where the data and keys can be intercepted by someone with
|
||||
complete access to the database server, such as the system
|
||||
administrator.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Data Partition Encryption</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
On Linux, encryption can be layered on top of a filesystem mount
|
||||
using a <quote>loopback device</quote>. This allows an entire
|
||||
filesystem partition be encrypted on disk, and decrypted by the
|
||||
operating system. On FreeBSD, the equivalent facility is called
|
||||
GEOM Based Disk Encryption, or <acronym>gbde</acronym>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This mechanism prevents unecrypted data from being read from the
|
||||
drives if the drives or the entire computer is stolen. This
|
||||
mechanism does nothing to protect against attacks while the
|
||||
filesystem is mounted, because when mounted, the operating system
|
||||
provides a unencrypted view of the data. However, to mount the
|
||||
filesystem, you need some way for the encryption key to be passed
|
||||
to the operating system, and sometimes the key is stored somewhere
|
||||
on the host that mounts the disk.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Encrypting Passwords Across A Network</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>MD5</> authentication method double-encrypts the
|
||||
password on the client before sending it to the server. It first
|
||||
MD5 encrypts it based on the user name, and then encrypts it
|
||||
based on a random salt sent by the server when the database
|
||||
connection was made. It is this double-encrypted value that is
|
||||
sent over the network to the server. Double-encryption not only
|
||||
prevents the password from being discovered, it also prevents
|
||||
another connection from replaying the same double-encryption
|
||||
value in a later connection.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Encrypting Data Across A Network</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
SSL connections encrypt all data sent across the network: the
|
||||
password, the queries, and the data returned. The
|
||||
<filename>pg_hba.conf</> file allows administrators to specify
|
||||
which hosts can use non-encrypted connections (<literal>host</>)
|
||||
and which require SSL-encrypted connections
|
||||
(<literal>hostssl</>). Also, clients can specify that they
|
||||
connect to servers only via SSL. <application>Stunnel</> or
|
||||
<application>SSH</> can also be used to encrypt transmissions.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>SSL Host Authentication</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
It is possible for both the client and server to provide SSL keys
|
||||
or certificates to each other. It takes some extra configuration
|
||||
on each side, but this provides stronger verification of identity
|
||||
than the mere use of passwords. It prevent a computer from
|
||||
pretending to be the server just long enough to read the password
|
||||
send by the client. It also helps prevent 'man in the middle"
|
||||
attacks where a computer between the client and server pretends to
|
||||
be the server and reads and passes all data between the client and
|
||||
server.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Client-Side Encryption</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
If the system administrator can not be trusted, it is necessary
|
||||
for the client to encrypt the data; this way, unencrypted data
|
||||
never appears on the database server. Data is encrypted on the
|
||||
client before being sent to the server, and database results have
|
||||
to be decrypted on the client before being used. Peter Wayner's
|
||||
book, <citation>Translucent Databases</citation>, discusses how to
|
||||
do this in considerable detail.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ssl-tcp">
|
||||
<title>Secure TCP/IP Connections with SSL</title>
|
||||
|
||||
|
Reference in New Issue
Block a user