|
| 1 | +<!-- doc/src/sgml/database-encryption.sgml --> |
| 2 | + |
| 3 | +<chapter id="database-file-encryption"> |
| 4 | + <title>Cluster File Encryption</title> |
| 5 | + |
| 6 | + <indexterm zone="database-file-encryption"> |
| 7 | + <primary>Cluster File Encryption</primary> |
| 8 | + </indexterm> |
| 9 | + |
| 10 | + <para> |
| 11 | + The purpose of cluster file encryption is to prevent users with read |
| 12 | + access to the directories used to store database files and write-ahead |
| 13 | + log from being able to access the data stored in those files. |
| 14 | + For example, when using cluster file encryption, users who have read |
| 15 | + access to the cluster directories for backup purposes will not be able |
| 16 | + to decrypt the data stored in the these files. |
| 17 | + </para> |
| 18 | + |
| 19 | + <para> |
| 20 | + Cluster file encryption uses two levels of encryption. The first level |
| 21 | + is data encryption keys, specifically keys zero and one. Key zero is |
| 22 | + the key used to encrypt database heap and index files which are stored in |
| 23 | + the file system, plus temporary files created during database operation. |
| 24 | + Key one is used to encrypt write-ahead log (WAL) files. Two different |
| 25 | + keys are used so that primary and standby servers can use different zero |
| 26 | + (heap/index/temp) keys, but the same one (WAL) key, so that these keys |
| 27 | + can eventually be rotated by switching the primary to the standby as |
| 28 | + and then changing the WAL key. |
| 29 | + </para> |
| 30 | + |
| 31 | + <para> |
| 32 | + The second level of encryption is a key used to encrypt first-level |
| 33 | + keys. This type of key is often referred to as a Key Encryption Key |
| 34 | + (<acronym>KEK</acronym>). This key is <emphasis>not</emphasis> stored |
| 35 | + in the file system, but provided at <command>initdb</command> time and |
| 36 | + each time the server is started. This key prevents anyone with access |
| 37 | + to the database directories from decrypting the data because they do |
| 38 | + not know the second-level key which encrypted the first-level keys |
| 39 | + which encrypted the database cluster files. |
| 40 | + </para> |
| 41 | + |
| 42 | + <sect1 id="encryption-file-encryption"> |
| 43 | + <title>Initialization</title> |
| 44 | + |
| 45 | + <para> |
| 46 | + Cluster file encryption is enabled when |
| 47 | + <productname>PostgreSQL</productname> is built |
| 48 | + with <literal>--with-openssl</literal> and <xref |
| 49 | + linkend="app-initdb-cluster-key-command"/> is specified |
| 50 | + during <command>initdb</command>. The cluster key |
| 51 | + provided by the <option>--cluster-key-command</option> |
| 52 | + option during <command>initdb</command> and the one generated |
| 53 | + by <xref linkend="guc-cluster-key-command"/> in the |
| 54 | + <filename>postgresql.conf</filename> must match for the database |
| 55 | + cluster to start. Note that the cluster key command |
| 56 | + passed to <command>initdb</command> must return a key of |
| 57 | + 64 hexadecimal characters. For example. |
| 58 | +<programlisting> |
| 59 | +initdb -D dbname --cluster-key-command='ckey_passphrase.sh' |
| 60 | +</programlisting> |
| 61 | + </para> |
| 62 | + </sect1> |
| 63 | + |
| 64 | + <sect1 id="key-encryption-key"> |
| 65 | + <title>Internals</title> |
| 66 | + |
| 67 | + <para> |
| 68 | + During the <command>initdb</command> process, if |
| 69 | + <option>--cluster-key-command</option> is specified, two data-level |
| 70 | + encryption keys are created. These two keys are then encrypted with |
| 71 | + the key enryption key (KEK) supplied by the cluster key command before |
| 72 | + being stored in the database directory. The key or passphrase that |
| 73 | + derives the key must be supplied from the terminal or stored in a |
| 74 | + trusted key store, such as key vault software, hardware security module. |
| 75 | + </para> |
| 76 | + |
| 77 | + <para> |
| 78 | + If the <productname>PostgreSQL</productname> server has |
| 79 | + been initialized to require a cluster key, each time the |
| 80 | + server starts the <filename>postgresql.conf</filename> |
| 81 | + <varname>cluster_key_command</varname> command will be executed |
| 82 | + and the cluster key retrieved. The data encryption keys in the |
| 83 | + <filename>pg_cryptokeys</filename> directory will then be decrypted |
| 84 | + using the supplied key and integrity-checked to ensure it |
| 85 | + matches the initdb-supplied key. If this check fails, the |
| 86 | + server will refuse to start. |
| 87 | + </para> |
| 88 | + |
| 89 | + <para> |
| 90 | + The data encryption keys are randomly generated and are of 128, 192, |
| 91 | + or 256-bits in length. They are encrypted by the key encryption key |
| 92 | + (KEK) using Advanced Encryption Standard (<acronym>AES256</acronym>) |
| 93 | + encryption in Galois/Counter Mode (<acronym>GCM</acronym>), which also |
| 94 | + provides KEK authentication. |
| 95 | + </para> |
| 96 | + </sect1> |
| 97 | +</chapter> |