為何需要多層次加密？
資料庫檔案在作業系統層面以檔案形式管理，駭客可繞過 DBMS 直接竊取、偽造、竄改檔案。傳統 B2 級安全要求堵塞 OS 漏洞，但現實難以全面覆蓋。因此必須在資料庫管理系統內部建立「最後一道防線」：即使檔案外洩，內容仍為密文，無法被破譯。
三大加密層次架構比較
1. OS 層加密
- 原理：檔案系統或磁碟層面透明加密（如 BitLocker、EFS、SAN 加密）。
- 缺點：無法識別資料庫邏輯結構（表、欄、列），難以產生合理金鑰粒度；金鑰管理與存取控制脫離 DBMS 安全模型；大型資料庫效能損耗大、備份/還原複雜。
- 結論：適合整庫離靜態保護，不適合細粒度業務級加密。
2. DBMS 核心層加密
- 原理：在資料寫入磁碟前、讀取後於 DBMS 內核完成加解密，與儲存引擎無縫整合。
- 優點：加密功能最強、透明度最高、不影響 SQL 功能、支援欄位/儲存格級粒度。
- 缺點：加解密運算在伺服器端，增加 CPU 負載；需 DBMS 廠商提供介面（如 SQL Server TDE、Always Encrypted），遷移性差。
- 關鍵組件：加密需求定義工具、DBMS、應用系統、加密器（軟/硬體）。
3. DBMS 外層工具加密
- 架構：獨立中介層位於應用與 DBMS 之間，攔截 SQL 指令，依加密字典改寫語句再轉發。
- 核心模組：
- 加密字典管理程式：定義哪些表/欄使用何種演算法、金鑰、模式。
- 加解密引擎：三大子模組——資料庫介面（接收請求、轉發結果）、加解密處理（語法分析、語義改寫、演算法執行、緩衝管理）、使用者介面（與管理工具通訊）。
- 處理流程：
- SQL 語法分析 → 非標準語法直接透傳。
- 內部控制指令識別 → 直接處理。
- 引擎關閉或僅編譯模式 → 透傳。
- 檢索加密字典 → 語義分析判斷需加密欄位。
- SQL 改寫（常數替換為密文、WHERE 條件轉換）。
- 轉發給 DBMS 執行。
- 結果集解密 → 回傳應用端。
- 優點：對應用透明、不修改既有程式；加解密在客戶端分散運算、不佔用 DB 伺服器資源；支援網路傳輸加密。
- 缺點：功能受限（如無法支援加密欄位的索引範圍查詢、JOIN、排序）；與 DBMS 耦合度較低，維護複雜度高。
加密字典驅動的透明加密機制
管理員透過圖形介面定義「表.欄 = 演算法 + 金鑰 + 模式」，引擎啟動時載入字典至記憶體。運行期攔截 SQL，針對 INSERT/UPDATE 將明文常數替換為加密值，SELECT 的 WHERE 條件同步轉換，結果集再解密。整過程對 DBA、開發者、終端用戶完全透明。
選型建議
| 場景 | 推薦層次 | 理由 |
|---|
| 合規要求全庫靜態加密、不改應用 | OS 層 / TDE | 部署最快、效能影響最小 |
| 核心欄位（信用卡、身分證）需細粒度、高強度加密 | DBMS 核心層 | 原生索引、查詢優化完整保留 |
| 異構資料庫、舊版不支援 TDE、需跨平台統一策略 | 外層工具 | 單一管理介面、支援多種 DBMS |
| 極高效能、海量交易、加密運算不可佔用 DB CPU | 外層工具（客戶端加解密） | 運算下推至應用伺服器叢集 |
總結
沒有銀彈，只有分層纖深防禦。建議採用「OS 層全盤加密 + DBMS 核心層敏感欄位加密 + 外層工具跨庫統一管理」三位一體策略，並在金鑰管理、存取審計、災難恢復演練上持續投資。
