runtime.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

  <title>Encryption Options</title>

  <indexterm zone="encryption-options">
   <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 to secure
   sensitive data such as 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 cannot 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.
    </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 file system mount
     using a <quote>loopback device</quote>. This allows an entire
     file system 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 unencrypted data from being read from the
     drives if the drives or the entire computer is stolen. This does
     not protect against attacks while the file system is mounted,
     because when mounted, the operating system provides an unencrypted
     view of the data. However, to mount the file system, 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 using the same encrypted password to
      connect to the database server at a later time.
     </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 prevents 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 cannot 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.
    </para>
   </listitem>
  </varlistentry>

  </variablelist>

 </sect1>

 <sect1 id="ssl-tcp">
  <title>Secure TCP/IP Connections with SSL</title>

  <indexterm zone="ssl-tcp">
   <primary>SSL</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</> has native support for using
   <acronym>SSL</> connections to encrypt client/server communications
   for increased security. This requires that
   <productname>OpenSSL</productname> is installed on both client and
   server systems and that support in <productname>PostgreSQL</> is
   enabled at build time (see <xref linkend="installation">).
  </para>

  <para>
   With <acronym>SSL</> support compiled in, the
   <productname>PostgreSQL</> server can be started with
   <acronym>SSL</> enabled by setting the parameter
   <xref linkend="guc-ssl"> to <literal>on</> in
   <filename>postgresql.conf</>. When
   starting in <acronym>SSL</> mode, the server will look for the
   files <filename>server.key</> and <filename>server.crt</> in the
   data directory, which must contain the server private key
   and certificate, respectively. These files must be set up correctly
   before an <acronym>SSL</>-enabled server can start. If the private key is
   protected with a passphrase, the server will prompt for the
   passphrase and will not start until it has been entered.
  </para>

  <para>
   The server will listen for both standard and <acronym>SSL</>
   connections on the same TCP port, and will negotiate with any
   connecting client on whether to use <acronym>SSL</>.  By default,
   this is at the client's option; see <xref
   linkend="auth-pg-hba-conf"> about how to set up the server to
   require use of <acronym>SSL</> for some or all connections.
  </para>

  <para>
   For details on how to create your server private key and certificate,
   refer to the <productname>OpenSSL</> documentation. A
   self-signed certificate can be used for testing, but a
   certificate signed by a certificate authority (<acronym>CA</>)
   (either one of the global
   <acronym>CAs</> or a local one) should be used in production so the
   client can verify the server's identity. To create a quick
   self-signed certificate, use the following
   <productname>OpenSSL</productname> command:
<programlisting>
openssl req -new -text -out server.req
</programlisting>
   Fill out the information that <command>openssl</> asks for. Make sure
   that you enter the local host name as <quote>Common Name</>; the challenge
   password can be left blank. The program will generate a key that is
   passphrase protected; it will not accept a passphrase that is less
   than four characters long. To remove the passphrase (as you must if
   you want automatic start-up of the server), run the commands
<programlisting>
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
</programlisting>
   Enter the old passphrase to unlock the existing key. Now do
<programlisting>
openssl req -x509 -in server.req -text -key server.key -out server.crt
chmod og-rwx server.key
</programlisting>
   to turn the certificate into a self-signed certificate and to copy the
   key and certificate to where the server will look for them.
  </para>

  <para>
   If verification of client certificates is required, place the
   certificates of the <acronym>CA</acronym>(s) you wish to check for in
   the file <filename>root.crt</filename> in the data directory.  When
   present, a client certificate will be requested from the client
   during SSL connection startup, and it must have been signed by one of the
   certificates present in <filename>root.crt</filename>.
  </para>

  <para>
   When the <filename>root.crt</filename> file is not present, client
   certificates will not be requested or checked.  In this mode, SSL
   provides communication security but not authentication.
  </para>

  <para>
   The files <filename>server.key</>, <filename>server.crt</>,
   and <filename>root.crt</filename> are only examined during server
   start; so you must restart the server to make changes in them take
   effect.
  </para>
 </sect1>

 <sect1 id="ssh-tunnels">
  <title>Secure TCP/IP Connections with <application>SSH</application> Tunnels</title>

  <indexterm zone="ssh-tunnels">
   <primary>ssh</primary>
  </indexterm>

  <para>
   One can use <application>SSH</application> to encrypt the network
   connection between clients and a
   <productname>PostgreSQL</productname> server. Done properly, this
   provides an adequately secure network connection, even for non-SSL-capable
   clients.
  </para>

  <para>
   First make sure that an <application>SSH</application> server is
   running properly on the same machine as the
   <productname>PostgreSQL</productname> server and that you can log in using
   <command>ssh</command> as some user. Then you can establish a secure
   tunnel with a command like this from the client machine:
<programlisting>
ssh -L 3333:foo.com:5432 [e-mail]
</programlisting>
   The first number in the <option>-L</option> argument, 3333, is the
   port number of your end of the tunnel; it can be chosen freely. The
   second number, 5432, is the remote end of the tunnel: the port
   number your server is using. The name or IP address between
   the port numbers is the host with the database server you are going
   to connect to. In order to connect to the database server using
   this tunnel, you connect to port 3333 on the local machine:
<programlisting>
psql -h localhost -p 3333 postgres
</programlisting>
   To the database server it will then look as though you are really
   user <literal>[e-mail]</literal> and it will use whatever
   authentication procedure was configured for connections from this
   user and host.  Note that the server will not think the connection is
   SSL-encrypted, since in fact it is not encrypted between the
   <application>SSH</application> server and the
   <productname>PostgreSQL</productname> server.  This should not pose any
   extra security risk as long as they are on the same machine.
  </para>
  <para>
   In order for the
   tunnel setup to succeed you must be allowed to connect via
   <command>ssh</command> as <literal>[e-mail]</literal>, just
   as if you had attempted to use <command>ssh</command> to set up a
   terminal session.
  </para>

  <tip>
   <para>
    Several other applications exist that can provide secure tunnels using
    a procedure similar in concept to the one just described.
   </para>
  </tip>

 </sect1>

</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->