PostgreSQL數據庫透明數據加密概述

• 2019 年 10 月 11 日
• 筆記

最近一段時間，一直在和PostgreSQL社區合作開發TDE（Transparent data encryption，透明數據加密）。研究了一些密碼學相關的知識，並利用這些知識和數據庫相結合。本文將會以數據庫內核開發角度，從以下3個維度和大家講述TDE。

1. 數據庫當前面臨的威脅模型
2. 加密策略描述，當前PostgreSQL社區目前的設計狀態以及其他數據庫TDE方案對比
3. 未來的數據安全暢想

那什麼是透明數據加密？

透明數據加密，從字面上來說，可以分為三部分，數據，加密，透明。 數據，這裡不用過多解釋，用戶需要保護的明文數據。 加密，相信大家也清楚，信息安全一直伴隨着世界的發展，加密是信息安全的一種重要手段，常用加密方法目前可以分為流密碼加密、分組加密以及公鑰加密3種。 透明，指的是用戶無感知，這是對加密行為的描述。

透明加密技術是近年來針對企業文件保密需求應運而生的一種文件加密技術。是指對使用者來說是無感知的。當使用者在打開或編輯指定文件時，系統將自動對未加密的文件進行加密，對已加密的文件自動解密。文件在硬盤上是密文，在內存中是明文。一旦離開使用環境，由於應用程序無法得到自動解密的服務而無法打開，從而起來保護文件內容的效果。 –摘自《百度百科》

一般涉及到加密碼學相關話題時，我們首先要清楚面對的安全威脅是什麼？

當前數據庫數據面臨的威脅模型

1. 不恰當的權限 很多應用或者軟件在使用過程中，往往因為使用的便利，將不必要的權限賦予用戶；其次，未及時清理無效的用戶（比如，離職員工），同樣會造成信息的泄露。 大多數應用軟件不會對於DBA和開發人員進行過多的限制，這同樣有數據丟失的風險。 權限賦予策略、三權分立或者數據庫審計都是有效防範此類威脅的重要手段。
2. SQL注入攻擊 SQL注入攻擊一直是數據庫面臨的重大風險之一。隨着B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由於程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據。 合理的軟件架構設計以及合法的SQL審計，是防範此類威脅的有效方法。
3. 惡意攻擊 攻擊者可以通過網絡竊聽、木馬攻擊等方式影響數據庫，造成數據丟失風險。很多廠商往往會因為性能或者資源等原因，沒有開啟網絡傳輸加密，從而造成數據竊聽風險。 其次，惡意攻擊者可以通過木馬病毒等措施，感染合法用戶設備，從而竊取數據，造成數據丟失。 提高安全措施，比如開啟防火牆，開啟網絡傳輸加密等，其次加強數據庫審計可以方法此類威脅。
4. 弱審計跟蹤 由於資源的消耗、性能的下降，很多廠商關閉或者開啟較少功能的審計跟蹤，這會導致惡意的管理員對於數據的非法侵入。 其次，由於審計之後的限制操作比較難以實現，比如對於DBA和非法侵入就難以區分，從而導致審計之後的操作難以防禦攻擊。 網絡設備審計是目前最有效的審計方案。
5. 不安全的存儲介質 存儲介質存儲竊取的風險，其次備份存儲存儲安全設置較低的因素，這都會造成數據丟失。 提高物理介質的保護，加密用戶數據，加強所有數據存儲的安全設置能夠防範此類威脅。
6. 不安全的第三方 隨着雲時代以及5G的到來，更多的廠商將數據存儲到雲端。這其實存在第三方信任問題。如果第三方存在惡意管理員，非法竊取或讀取敏感數據；或者提供存在安全隱患的服務器，這都會造成數據丟失。 選擇可信任的第三方，加密用戶數據，可以避免不安全的第三方威脅。
7. 數據庫漏洞或者錯誤的配置 隨着現代數據庫軟件的功能增多，複雜的程序很可能會存在安全漏洞，而且很多廠商為了保證系統的穩定性不願意進行版本升級，同樣數據面臨很大的泄露風險。 其次，安全設置不足也存在很高的風險。這裡的安全配置不僅僅指的是數據庫層面，操作系統層面也需要加強安全配置。 定期修複數據庫漏洞，加強安全配置。
8. 有限的安全專業知識和教育 據統計，大約有30%的數據泄露事件是由人為疏漏造成的，所以安全教育同樣需要加強。 定期進行安全專業知識講座，提高安全防範意識。

綜上所述，目前數據加密能夠應對的威脅有有不安全的存儲介質，不安全的第三方。 而我們知道數據庫不僅需要安全因素的考量，同時需要兼顧性能、穩定、易用的因素。那麼如何設計數據加密？

加密等級

首先我們回顧一下PostgreSQL整體架構：

通過整體架構來看，我們可以將加密分為6個等級。 從上圖可以看到，客戶端和服務端進行交互，用戶數據自客戶端起，由服務端接收，並寫入到服務端緩存中，再刷入到磁盤內。 而PostgreSQL存儲物理結構為：集群–>表空間–>數據庫–>關係對象。 由此我們可以將數據庫分為6個層級進行加密，分別是，客戶端加密，服務端加密，集簇級加密，表空間級加密，數據庫級加密以及表級或對象級加密。 下面對這6個層級進行分別闡述：

1. 客戶端加密，由用戶生成密鑰，對字段進行加密；
   1. 優點：在某種程度上能夠防範DBA以及開發人員；加密粒度小，加密數據量可控。現有的加密插件pgcrypto可以客戶端的數據加密功能。
   2. 缺點：使用成本較高，需要調整現有應用系統，對數據插入語句進行修改；其次由於從數據生成開始加密，等於是緩存級加密，性能較差，索引無法使用。
2. 服務端加密，建立加密類型，對字段進行加密；
   1. 優點：使用成本相對於客戶端加密較低，僅需要對數據庫進行調整，無需修改應用程序，加密粒度小，加密數據量可控。
   2. 缺點，同樣是緩存級加密，性能較差，索引無法使用。
3. 集簇級加密，對整個集簇進行加密，初始化時確定集簇是否加密；
   1. 優點：架構簡單，使用成本低，操作系統緩存級加密（數據緩存刷入、讀取磁盤時加解密），性能相對較好；
   2. 缺點，加密細粒度大，所有集簇內對象都會加密，會造成性能下降。
4. 表空間級加密，對某一個表空間設置加密屬性，所有在加密表空間內都默認加密；
   1. 優點：架構簡單，使用成本低，操作系統緩存級加密，性能相對較好，加密細粒度降低，能夠更好的控制加密數據量，有利於數據加密效率；
   2. 缺點：表空間在PostgreSQL的概念不夠明確，用戶容易誤解，其次在備份管理等方面使用成本較高。
5. 數據庫級加密，指定某個庫為加密庫，所有在加密庫中的對象默認加密；
   1. 優點：架構簡單，使用成本低，操作系統緩存級加密，加密細粒度降低，數據加密效率高；
   2. 缺點：加密細粒度相對較大。
6. 表級加密或者文件級加密，指定某個對象加密；
   1. 優點：架構簡單，使用成本低，操作系統緩存級加密，加密細粒度進一步降低，數據加密效率高；
   2. 缺點：密鑰管理成本較大，開發複雜度較高。其次當需要加密的對象較多時，使用成本較高。

*這裡解釋以下為什麼緩存級加密無法建立索引的原因： 建立索引的目的是提高數據建索效率，而加密的原因是保護敏感數據。

• 那麼如果我們在緩存級加密，如果建立索引，這裡也需要分為兩種情況，基於明文建索引或基於密文建索引。
  • 基於明文建索引則需要對明文進行解密，建立索引，後對索引加密，但這樣加解密次數過多，會引起性能下降，其次索引本身的順序也會造成一定的信息泄漏。
  • 基於密文建索引則索引無法有效對數據排序，也就難以起到快速減速的能力。
• 那如果不對索引加密，則會對數據安全產生影響。

當然如果加密後不使用索引則不會有任何影響。*

上面提到了緩存級和文件系統級加密接下來從存儲架構上來看：

由上圖可知，我們可以分為三個等級，數據庫緩存級，操作系統緩存級以及文件系統級：

數據庫緩存級加密：上述的等級1、2都是數據寫入緩存時已經加密，緩存級加密，數據檢索時解密，性能最差； 操作系統緩存級：等級3、4、5、6都是在PostgreSQL數據刷寫磁盤是加密，數據加載時解密，性能相對較好； 文件系統級：數據庫自身無法實現，需要使用文件系統加密，數據庫不可控。

那對於數據庫來說應該如何選擇？ 雖然加密是一種很好的數據安全保護手段，但是如何加入到數據庫中還需要進行整體性考慮。 在對數據庫進行加強時，我們需要考慮

• 開發成本；
• 安全性；
• 性能；
• 易用性。

社區經過多次討論，目前由於設計難易度以及開發成本的角度，選擇了集簇級加密作為TDE的第一個方案。

我們都知道，常用加密目前主要有流式加密、分組加密、公鑰加密三種。 在使用加密算法的時候，應注意：

• 加密方法由兩部分構成，密鑰以及加密算法。通常我們建議使用國際公開、認證的加密算法。
• 密鑰的保護等同於明文的保護。

所以如何進行加密我們將會分為兩部分講述：加密算法的選擇以及密鑰的管理。

加密算法選擇

首先分析一下三種加密方式：

1. 流式加密的特性是，密鑰長度與明文數據長度一致，而這在數據庫中是難以實現的，所以在這不考慮。
2. 公鑰加密是最大的優勢在於分為公私密鑰，公鑰是可以公開的，這就降低了密鑰管理的問題，但是其加密性能太差，分組加密算法是公鑰加密的幾百倍，所以在此也不進行考慮。
3. 分組加密是目前主流的加密算法，性能最優，應用最廣。

而當前國際公認的分組加密算法是AES。 下面我們簡單介紹一下AES。 分組加密算法，首先需要分組，AES的加密長度為128bits，也就是說16 bytes。 擁有3種密鑰長度，128，192以及256。 AES擁有5種加密模式：

ECB mode: Electronic Code Book mode，電子密碼本模式 CBC mode: Cipher Block Chaining mode，密碼分組鏈表模式 CFB mode: Cipher FeedBack mode，密文反饋模式 OFB mode: Output FeedBack mode，輸出反饋模式 CTR mode: Counter mode，計數器模式

5種模式的加密流程

ECB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 使用相同的密鑰進行加密明文； iii. 得到密文； iv. 逆向則解密。

CBC mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV（Initialization Vector，向量）； iii. 使用IV和明文進行異或； iv. 使用相同的密鑰加密步驟iii的結果； v. 得到密文； vi. 使用密文作為一下次加密時與明文進行異或的數據； vii. 逆向則解密。

CFB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV； iii. 使用相同的密鑰進行加密IV； iv. 使用加密後的IV和明文進行異或； v. 得到密文； vi. 使用密鑰加密密文，與一下次的明文進行異或，重複iv，v，vi； vii. 逆向則解密。

OFB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV； iii. 使用密鑰加密IV； iv. 使用加密後的IV對明文異或； v. 在此使用密鑰加密步驟iii結果，重複步驟iv和v，直至完成整個明文加密； vi. 逆向則解密。

CTR mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化計數器，要求所有計數為唯一值； iii. 使用密鑰加密計數； iv. 使用加密後的計數和明文異或； v. 得到密文； vi. 重複步驟iii，iv，v； vii. 逆向則解密。

5種模式的異同

上述闡述了，5種mode的加密過程，由此不同的加密過程，則產生異同點：

5種模式的加解密效率

加密：

解密：

註：以上數據僅是單進程下的對比。

數據庫中如何選擇加密模式

開發成本：使用openssl自帶的加密算法，加密算法開發成本低；其中除ECB外都需要額外的使用向量或計數器，開發成本相當；由於CBC和ECB需要進行填充數據，考慮到WAL流複製過程，不推薦使用。最優選擇為CFB，OFB和CTR。 安全性：ECB不予考慮，其他皆可。 性能：由於是在刷寫磁盤時進行加解密，那麼考慮到讀取和寫入的並行要求，以及加密算法的性能，CTR mode是最優選擇。 易用性：在此不需要考慮。

以上，從各個層面來說，CTR都是最優的加密mode，社區同樣選擇了CTR mode作為加密模式。

數據庫中如何使用CTR mode

要添加CTR mode到數據庫，需要了解CTR的加密過程。 從上面的加解密流程可以知道，CTR加解密時需要4部分共同協作，明/密文，算法，計數器，密鑰。

• 算法本身是調用openssl的CTR mode，所以這裡無需開發，只需要熟讀openssl的文檔即可。
• 明/密文，根據加密等級的介紹，數據庫是將緩存刷入磁盤時進行加密的，也就是說將會對page進行加解密，其大小為8192 bytes，正好是加密塊的整數倍；其次在考慮流複製的特殊性，我們也會對recode進行加解密。
• 計數器，根據NIST的加密算法說明，我們可以知道，這裡的計數器不要求強隨機，只要是保證不重複即可。其次，計數同樣需要保存在數據庫中。因此考慮使用page頁上的LSN來作為計數器的一部分，（這裡要說明的是，LSN是存在重複的可能性。社區目前有人提供一個新的補丁來防止LSN重複的可能），其次使用文件名以及也的順序作為其中的一部分。以此來保證其唯一性。
• 密鑰，密鑰的保護等於密文的保護。所以密鑰如何生成、管理是非常重要的。將由下面這個章節進行說明。

密鑰管理

密鑰管理由四部分構成：密鑰生成、密鑰交換、密鑰保存以及密鑰輪轉。

密鑰生成

上面的章節介紹了我們將會選擇對稱分組加密方法進行加解密，那麼我們的密鑰即是對稱密鑰。而對稱密碼生成方法有：

• 隨機數作為密鑰
• 基於口令的密鑰生成
• HKDF（HMAC-based Extrac-and-Expand Key Derivation Function）

1. 隨機數作為密鑰：這很用以理解，使用強隨機數生成器，生成密鑰。
2. 基於口令的密鑰生成：根據用戶口令生成密鑰並使用它進行加解密的方法。具體方法如下：

1. 用戶輸入口令；
2. 系統生成隨機數，與用戶口令進行hash計算，得到密鑰加密密鑰；
3. 存儲密鑰加密密鑰至安全處；
4. 系統生成隨機數作為數據加密密鑰；
5. 密鑰加密密鑰對數據密鑰進行加密，同樣也存儲到安全處；
6. 使用數據加密密鑰對數據加解密。

1. HKDF：密鑰派生函數(KDF)是密碼系統的基本組成部分。它的目標是獲取一些初始的密鑰材料，並從中派生出一個或多個安全強度很大的密鑰。
2. 提取，使用強隨機數和輸入的信息使用hmac方法進行hash運算；
3. 擴展，通過多次hash計算，對上面結果進行擴展，擴展到我們需要的長度。

密鑰保存

密鑰的生成無論是隨機數的還是基於口令的，都有一部分是目前難以記憶的，所以這就需要存儲密鑰了（也可能是salt）。 密鑰不能與數據存儲在同一位置，否則等於是鑰匙掛在門上，沒有任何意義。 我們一般需要將密鑰存儲在文件內，放到保險柜等安全的存儲位置或者安全的密鑰分配中心。 當時當密鑰數量達到一定數量時，我們就需要另一種密鑰，KEK（Key encryption key，密鑰加密密鑰）。 這是由於密鑰如果不進行加密，竊取後，盜取者很容易使用密鑰對數據解密了。同樣，管理多個密鑰難度遠遠大於單個密鑰。 所以可以考慮使用KEK來保存密鑰的一種方式，當然KEK也需要存儲在安全的位置。

密鑰交換

密鑰交換目前有4種：事先共享密鑰，使用密鑰分配中心，使用公鑰密碼以及Diffie-Hellman密鑰交換方法。

下面簡單描述一下4種方法： 事先共享密碼： 雙方加密前通過安全途徑交換密鑰，但是在數據庫中，雙方為服務端和磁盤，即密鑰和磁盤在同一區域，不安全，所以數據庫不會考慮這種方式。

使用公鑰密碼： 由於我們這裡使用對稱加密體系，所以不考慮公鑰。但是這可以作為密鑰交換的一部分使用。

使用密鑰分配中心： 將密鑰存儲到可信任的第三方，使用時通過第三方獲取密鑰。在需要使用密鑰時，向第三方通訊，生成會話密鑰，使用會話密鑰加密密鑰進行發送密鑰。 這裡的會發密鑰可以使用公鑰加密體系。

DIffie-Hellman密鑰交換： DIffie-Hellman是1976年由Whitfield Diffie和Martin Hellman共同發明的一種算法。該算法可以通過交換可以公開的信息就能夠生成共享的秘密數字，從而達到共享密鑰的目的，其過程如下圖所示：

1. DB server向Key server（以下簡稱D和K）發送兩個質數P，G；  2. D生成一個隨機數A；  3. K生成一個隨機數B；  4. D將GA mod P 發送給K；  5. K將GB mod P 發送給D；  6. D使用K發過來的數B', 計算B』mod P，這就是數據加密密鑰；  7. K使用D發過來的數A'，計算A' mod P，這個和D計算得到的加密密鑰是相等的；

當然再加入數據庫時，同樣需要使用安全第三方作為信息交換，但這減少了密鑰被竊聽的可能性。

密鑰輪轉

密鑰輪轉，分為密鑰更新和作廢兩部分。 密鑰更新，更新可以提高密鑰暴力破解的難度，其次即便是過去的密鑰被破解也無法獲取當前的數據。 密鑰作廢，在更新後要及時對密鑰進行作廢，這裡的作廢不僅僅指的是刪除，而是要達到無法還原密鑰的目的。

TDE的密鑰管理方法

以上密鑰管理方法沒有明確不推薦的情況下，都是可以使用的。 筆者再和社區溝通的過程中推薦的是，基於口令的密鑰生成，使用KEK存儲密鑰，DIffie-Hellman密鑰交換的方案。

當前社區經過多輪討論後，目前由兩種方案2層密鑰管理以及3層密鑰管理：. 相面對其進行介紹：

2層密鑰管理：

2層密鑰管理使用的是，基於口令的密鑰生成，使用KEK存儲密鑰以及使用密鑰分配中心3者的結合，架構體系如下圖：

這和之前講到的基於口令的密碼很相似，不過數據加密密鑰將會存儲到數據庫服務器，這有別於基於口令的密碼存儲到外部服務器。

3層密鑰管理：

這裡使用的是，基於口令的密鑰生成，HKDF，使用KEK存儲密鑰以及使用密鑰分配中心4者的結合，架構體系如下圖：

1. 用戶輸入口令；  2. 系統生成隨機數，與用戶口令進行hash計算，得到密鑰加密密鑰；  3. 隨機數存儲至安全處；  4. 系統生成隨機數作為MDEK（master data encryption key），存儲至安全處；  5. 使用MDEK和加密文件信息得到數據加密密鑰；  6. 使用數據加密密鑰對數據進行加解密。

目前密鑰管理還有一定爭議，我個人比較贊同第二種方式，為後期更小加密細粒度做準備。

其他數據庫TDE方案對比

做任何事情都不是閉門造車，現階段，很多數據庫已經支持了TDE，我們對此進行對比，以此來確定最優的方案：

1. Oracle
   • 加密等級：Tablespace-level，Column-level
   • 加密算法：AES，3DES
   • 密鑰管理：主密鑰和數據加密密鑰
2. SQL Servel
   • 加密等級：Database-level
   • 加密算法：AES，3DES
   • 密鑰管理：系統密鑰，主密鑰，系統證書，數據加密密鑰
3. DB2
   • 加密等級：Database-level
   • 加密算法：AES，3DES
   • 密鑰管理：主密鑰和數據加密密鑰
4. MySQL
   • 加密等級：Tablespace-level，Column-level
   • 加密算法：AES，3DES
   • 密鑰管理：OASIS Key Management Interoperability Protocol (KMIP) TC

未來的數據安全暢想

現在5G的來臨，雲時代的來臨，我想未來的IT架構，更多的都是基於雲的設計。更多的數據存儲在雲上，那麼雲廠商如果對用戶數據竊取、分析，那都會嚴重侵犯我們的隱私。 之前在威脅模型中也說到的惡意DBA和開發人員，他們往往具有較高的數據庫權限，哪怕沒有權限，他們如果有讀取緩存的方法，那麼數據同樣會泄露。 那麼如何保護我們的數據呢？

同態加密

同態加密是基於數學難題的計算複雜性理論的密碼學技術。對經過同態加密的數據進行處理得到一個輸出，將這一輸出進行解密，其結果與用同一方法處理未加密的原始數據得到的輸出結果是一樣的。 –摘自《百度百科》

同態加密（Homomorphic Encryption）是很久以前密碼學界就提出來的一個Open Problem。早在1978年，Ron Rivest, Leonard Adleman, 以及Michael L. Dertouzos就以銀行為應用背景提出了這個概念。

一般的加密方案關注的都是數據存儲安全。即，我要給其他人發個加密的東西，或者要在計算機或者其他服務器上存一個東西，我要對數據進行加密後在發送或者存儲。沒有密鑰的用戶，不可能從加密結果中得到有關原始數據的任何信息。只有擁有密鑰的用戶才能夠正確解密，得到原始的內容。我們注意到，這個過程中用戶是不能對加密結果做任何操作的，只能進行存儲、傳輸。對加密結果做任何操作，都將會導致錯誤的解密，甚至解密失敗。同態加密方案最有趣的地方在於，其關注的是數據處理安全。同態加密提供了一種對加密數據進行處理的功能。也就是說，其他人可以對加密數據進行處理，但是處理過程不會泄露任何原始內容。同時，擁有密鑰的用戶對處理過的數據進行解密後，得到的正好是處理後的結果。

如果不是很理解他的概念，那麼我們可以看下圖：

同態加密你可以想像，DBA和開發人員或者惡意的雲管理員，他們就像是操作工人（攻擊者），必須帶着手套在加鎖的盒子里（加密算法）處理金子，沒有鑰匙（密鑰）打不開，如此，他們是無法竊取金子（數據）的。

那麼未來如何使用同態加密呢？

Alice通過Cloud，以Homomorphic Encryption（以下簡稱HE）處理數據的整個處理過程大致是這樣的： Alice對數據進行加密。並把加密後的數據發送給Cloud； Alice向Cloud提交數據的處理方法，這裡用函數f來表示； Cloud在函數f下對數據進行處理，並且將處理後的結果發送給Alice； Alice對數據進行解密，得到結果。

那麼為什麼現在還沒有大規模應用呢？根據IBM團隊的研究，直到2016年，該技術都還存在性能瓶頸，巨大的性能開銷讓人無奈至極。 同態加密的發明者克雷格•金特里(Craig Gentry)帶領IBM的研究團隊進行了一系列同態加密嘗試。最初的時候，同態加密的數據處理速度比明文操作慢「100萬億倍」，後來在16核服務器上執行，速度就提升了200萬倍，但還是比明文操作慢很多。因此，IBM繼續改進HElib，其發佈在GitHub上的最新版就重新實現了同態線性變換，性能得到極大提升，速度加快了15-75倍。國際密碼學研究協會的一篇論文中，IBM密碼研究團隊的謝•哈勒維(Shai Halevi)和紐約大學庫朗數學研究所教授維克多•舒普（Victor Shoup，同時供職IBM蘇黎世研究實驗室）闡述了速度提升的方法。

所以當前同態加密的性能無法滿足正常需要，如果商用到數據庫層面，我認為還需要密碼學家的進一步研究。請大家期待吧。

寫在最後

以上所有方法都是軟件層面的操作，目前關於數據加密其實湧現了很多硬件解決方案，比如FPGA卡加解密，以提高其性能；還有Intel的基於可信執行環境技術（TEE，Trusted Execution Environment）的可信計算等等。 加密也僅僅是數據庫安全的一小部分，更多的內容需要大家的共同努力，也希望在未來能夠看到更多的人從事到數據庫安全領域當中。

參考文章

1. http://raghavt.blogspot.ca/2011/04/postgresql-90-architecture.html
2. Computer Security — NIST
3. RFC 5869 – HMAC-based Extrac-and-Expand Key Derivation Function.pdf
4. https://www.zhihu.com/question/27645858/answer/37598506
5. https://zhuanlan.zhihu.com/p/82191749
6. https://www.postgresql.org/message-id/flat/CAD21AoAB5%2BF0RAb5gHNV74CXrBYfQrvTPGx86MrEfVM%3Dx4iPbQ%40mail.gmail.com#321a08844300a49c89590cbf12ccb12a
7. https://wiki.postgresql.org/wiki/Transparent_Data_Encryption
8. https://www.slideshare.net/masahikosawada98/transparent-data-encryption-in-postgresql