文件首頁
MySQL 8.4 參考手冊
相關文件 下載本手冊
PDF (US Ltr) - 39.9Mb
PDF (A4) - 40.0Mb
Man Pages (TGZ) - 258.5Kb
Man Pages (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 參考手冊  /  InnoDB 儲存引擎  /  InnoDB 靜態資料加密

17.13 InnoDB 靜態資料加密

InnoDB 支援 每個資料表檔案 表空間、一般 表空間、mysql 系統表空間、重做日誌和復原日誌的靜態資料加密。

您可以為綱要和一般表空間設定加密預設值;這允許資料庫管理員控制在這些綱要和表空間中建立的資料表是否加密。

InnoDB 靜態資料加密功能和特性在本節的以下主題中說明。

關於靜態資料加密

InnoDB 使用兩層加密金鑰架構,包含主加密金鑰和表空間金鑰。當表空間被加密時,表空間金鑰會被加密並儲存在表空間標頭中。當應用程式或經過驗證的使用者想要存取加密的表空間資料時,InnoDB 會使用主加密金鑰來解密表空間金鑰。表空間金鑰的解密版本永遠不會變更,但主加密金鑰可以根據需要變更。此動作稱為主金鑰輪換

靜態資料加密功能依賴於金鑰環元件或外掛程式進行主加密金鑰管理。

所有 MySQL 版本都提供 component_keyring_file 元件,該元件將金鑰環資料儲存在伺服器主機的本機檔案中。

MySQL 企業版提供額外的金鑰環元件和外掛程式

  • component_keyring_encrypted_file:將金鑰環資料儲存在伺服器主機本機的加密、受密碼保護的檔案中。

  • keyring_okv:一個 KMIP 1.1 外掛程式,用於與相容 KMIP 的後端金鑰環儲存產品搭配使用。支援的相容 KMIP 產品包括集中式金鑰管理解決方案,例如 Oracle Key Vault、Gemalto KeySecure、Thales Vormetric 金鑰管理伺服器和 Fornetix Key Orchestration。

  • keyring_aws:與 Amazon Web Services 金鑰管理服務 (AWS KMS) 通訊,作為金鑰產生的後端,並使用本機檔案儲存金鑰。

  • keyring_hashicorp:與 HashiCorp Vault 通訊,作為後端儲存。

警告

對於加密金鑰管理,component_keyring_filecomponent_keyring_encrypted_file 元件不旨在作為法規遵循解決方案。PCI、FIPS 和其他安全標準要求使用金鑰管理系統,以在金鑰保險庫或硬體安全模組 (HSM) 中保護、管理和保護加密金鑰。

安全且穩健的加密金鑰管理解決方案對於安全性和符合各種安全標準至關重要。當靜態資料加密功能使用集中式金鑰管理解決方案時,該功能稱為「MySQL Enterprise 透明資料加密 (TDE)」。

靜態資料加密功能支援進階加密標準 (AES) 基於區塊的加密演算法。它使用電子碼本 (ECB) 區塊加密模式進行資料表空間金鑰加密,並使用密碼區塊鏈結 (CBC) 區塊加密模式進行資料加密。

有關靜態資料加密功能的常見問題,請參閱第 A.17 節,「MySQL 8.4 常見問題:InnoDB 靜態資料加密」

加密先決條件

  • 金鑰環元件或外掛程式必須在啟動時安裝和設定。提早載入可確保元件或外掛程式在 InnoDB 儲存引擎初始化之前可用。有關金鑰環安裝和設定說明,請參閱第 8.4.4 節,「MySQL 金鑰環」。這些說明會顯示如何確保所選的元件或外掛程式處於作用中狀態。

    一次只能啟用一個金鑰環元件或外掛程式。不支援啟用多個金鑰環元件或外掛程式,並且結果可能不如預期。

    重要

    一旦在 MySQL 執行個體中建立加密的資料表空間,建立加密資料表空間時載入的金鑰環元件或外掛程式必須在啟動時繼續載入。若未這樣做,將會在啟動伺服器期間以及 InnoDB 復原期間產生錯誤。

  • 在加密生產資料時,請務必採取步驟防止主加密金鑰遺失。如果遺失主加密金鑰,則無法復原儲存在加密資料表空間檔案中的資料。如果您使用 component_keyring_filecomponent_keyring_encrypted_file 元件,請在建立第一個加密資料表空間後、在主金鑰輪替之前以及在主金鑰輪替之後,立即建立金鑰環資料檔案的備份。對於每個元件,其組態檔案會指出資料檔案的位置。如果您使用 keyring_okvkeyring_aws 外掛程式,請確保您已執行必要的設定。如需說明,請參閱第 8.4.4 節,「MySQL 金鑰環」

定義結構描述和一般資料表空間的加密預設值

default_table_encryption 系統變數會定義結構描述和一般資料表空間的預設加密設定。CREATE TABLESPACECREATE SCHEMA 操作會在未明確指定 ENCRYPTION 子句時,套用 default_table_encryption 設定。

ALTER SCHEMAALTER TABLESPACE 操作不會套用 default_table_encryption 設定。必須明確指定 ENCRYPTION 子句,才能變更現有結構描述或一般資料表空間的加密。

可以使用 SET 語法,為個別用戶端連線或全域設定 default_table_encryption 變數。例如,以下陳述式會在全域啟用預設結構描述和資料表空間加密

mysql> SET GLOBAL default_table_encryption=ON;

也可以在建立或變更結構描述時,使用 DEFAULT ENCRYPTION 子句定義結構描述的預設加密設定,如此範例所示

mysql> CREATE SCHEMA test DEFAULT ENCRYPTION = 'Y';

如果在建立結構描述時未指定 DEFAULT ENCRYPTION 子句,則會套用 default_table_encryption 設定。必須指定 DEFAULT ENCRYPTION 子句,才能變更現有結構描述的預設加密設定。否則,結構描述會保留其目前的加密設定。

預設情況下,資料表會繼承其建立所在的結構描述或一般資料表空間的加密設定。例如,在啟用加密的結構描述中建立的資料表預設為加密。此行為可讓 DBA 透過定義和強制執行結構描述和一般資料表空間加密預設值,來控制資料表加密的使用方式。

透過啟用 table_encryption_privilege_check 系統變數來強制執行加密預設值。當啟用 table_encryption_privilege_check 時,當建立或變更結構描述或一般資料表空間時,若其加密設定與 default_table_encryption 設定不同,或者當建立或變更資料表時,若其加密設定與預設結構描述加密不同,則會發生權限檢查。當停用 table_encryption_privilege_check (預設) 時,不會發生權限檢查,並且允許先前提到的操作繼續進行,但會發出警告。

當啟用 table_encryption_privilege_check 時,覆寫預設加密設定需要 TABLE_ENCRYPTION_ADMIN 權限。DBA 可以授予此權限,以讓使用者在建立或變更結構描述或一般資料表空間時,可以偏離 default_table_encryption 設定,或者在建立或變更資料表時,可以偏離預設結構描述加密。此權限不允許偏離在建立或變更資料表時,一般資料表空間的加密設定。資料表必須與其所在的常規資料表空間具有相同的加密設定。

每個資料表檔案的資料表空間加密

每個資料表檔案的資料表空間會繼承資料表建立所在結構描述的預設加密設定,除非在 CREATE TABLE 陳述式中明確指定 ENCRYPTION 子句。

mysql> CREATE TABLE t1 (c1 INT) ENCRYPTION = 'Y';

若要變更現有每個資料表檔案的資料表空間的加密設定,必須指定 ENCRYPTION 子句。

mysql> ALTER TABLE t1 ENCRYPTION = 'Y';

啟用 table_encryption_privilege_check 後,指定 ENCRYPTION 子句且其設定與預設結構描述加密不同,則需要 TABLE_ENCRYPTION_ADMIN 權限。請參閱定義結構描述和一般資料表空間的加密預設值

一般資料表空間加密

除非在 CREATE TABLESPACE 陳述式中明確指定 ENCRYPTION 子句,否則 default_table_encryption 變數會決定新建立的一般資料表空間的加密設定。

mysql> CREATE TABLESPACE `ts1` ADD DATAFILE 'ts1.ibd' ENCRYPTION = 'Y' Engine=InnoDB;

若要變更現有一般資料表空間的加密設定,必須指定 ENCRYPTION 子句。

mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';

如果啟用 table_encryption_privilege_check,指定 ENCRYPTION 子句且其設定與 default_table_encryption 設定不同,則需要 TABLE_ENCRYPTION_ADMIN 權限。請參閱定義結構描述和一般資料表空間的加密預設值

雙寫檔案加密

在 MySQL 8.4 中,InnoDB 會自動加密屬於加密資料表空間的雙寫檔案頁面。不需要採取任何動作。雙寫檔案頁面會使用相關資料表空間的加密金鑰進行加密。寫入資料表空間資料檔案的相同加密頁面也會寫入雙寫檔案。屬於未加密資料表空間的雙寫檔案頁面會保持未加密。

在復原期間,加密的雙寫檔案頁面會解除加密並檢查是否損毀。

mysql 系統資料表空間加密

mysql 系統資料表空間包含 mysql 系統資料庫和 MySQL 資料字典資料表。預設為未加密。若要啟用 mysql 系統資料表空間的加密,請在 ALTER TABLESPACE 陳述式中指定資料表空間名稱和 ENCRYPTION 選項。

mysql> ALTER TABLESPACE mysql ENCRYPTION = 'Y';

若要停用 mysql 系統資料表空間的加密,請使用 ALTER TABLESPACE 陳述式設定 ENCRYPTION = 'N'

mysql> ALTER TABLESPACE mysql ENCRYPTION = 'N';

啟用或停用 mysql 系統資料表空間的加密,需要在執行個體中的所有資料表上具有 CREATE TABLESPACE 權限 (CREATE TABLESPACE on *.*)

重做記錄檔加密

使用 innodb_redo_log_encrypt 組態選項啟用重做記錄檔資料加密。重做記錄檔加密預設為停用。

與資料表空間資料一樣,重做記錄檔資料加密會在將重做記錄檔資料寫入磁碟時發生,而解密會在從磁碟讀取重做記錄檔資料時發生。一旦將重做記錄檔資料讀取到記憶體中,它會處於未加密的形式。重做記錄檔資料會使用資料表空間加密金鑰進行加密和解密。

當啟用 innodb_redo_log_encrypt 時,磁碟上未加密的重做日誌頁面將保持未加密狀態,而新的重做日誌頁面將以加密形式寫入磁碟。同樣地,當停用 innodb_redo_log_encrypt 時,磁碟上已加密的重做日誌頁面將保持加密狀態,而新的重做日誌頁面將以未加密形式寫入磁碟。

重做日誌加密的中繼資料,包括表空間加密金鑰,會儲存在具有最新檢查點 LSN 的重做日誌檔標頭中。如果移除了包含加密中繼資料的重做日誌檔,重做日誌加密將會停用。

一旦啟用重做日誌加密,如果沒有金鑰環組件或外掛程式,或沒有加密金鑰,則無法正常重新啟動,因為 InnoDB 在啟動期間必須能夠掃描重做頁面,如果重做日誌頁面已加密,則無法做到。如果沒有金鑰環組件或外掛程式,或沒有加密金鑰,則只能在不使用重做日誌的情況下強制啟動(SRV_FORCE_NO_LOG_REDO)。請參閱第 17.20.3 節,〈強制 InnoDB 復原〉

還原日誌加密

可以使用 innodb_undo_log_encrypt 組態選項來啟用還原日誌資料加密。還原日誌加密適用於位於還原表空間中的還原日誌。請參閱第 17.6.3.4 節,〈還原表空間〉。預設會停用還原日誌資料加密。

如同表空間資料,還原日誌資料加密發生在將還原日誌資料寫入磁碟時,而解密發生在從磁碟讀取還原日誌資料時。一旦將還原日誌資料讀取到記憶體中,就會以未加密的形式存在。還原日誌資料會使用表空間加密金鑰進行加密和解密。

當啟用 innodb_undo_log_encrypt 時,磁碟上未加密的還原日誌頁面將保持未加密狀態,而新的還原日誌頁面將以加密形式寫入磁碟。同樣地,當停用 innodb_undo_log_encrypt 時,磁碟上已加密的還原日誌頁面將保持加密狀態,而新的還原日誌頁面將以未加密形式寫入磁碟。

還原日誌加密的中繼資料,包括表空間加密金鑰,會儲存在還原日誌檔的標頭中。

注意

當停用還原日誌加密時,伺服器仍會繼續需要用於加密還原日誌資料的金鑰環組件或外掛程式,直到包含已加密還原日誌資料的還原表空間被截斷為止。(只有在截斷還原表空間時,才會從還原表空間中移除加密標頭。)如需截斷還原表空間的資訊,請參閱截斷還原表空間

主金鑰輪換

主加密金鑰應定期輪換,且每當您懷疑金鑰已遭洩漏時都應輪換。

主金鑰輪換是一種不可分割的執行個體層級作業。每次輪換主加密金鑰時,MySQL 執行個體中的所有表空間金鑰都會重新加密,並儲存回各自的表空間標頭中。作為不可分割的作業,一旦啟動輪換作業,就必須成功重新加密所有表空間金鑰。如果主金鑰輪換因伺服器故障而中斷,InnoDB 會在伺服器重新啟動時將作業向前推出。如需更多資訊,請參閱加密和復原

輪換主加密金鑰只會變更主加密金鑰,並重新加密表空間金鑰。它不會解密或重新加密關聯的表空間資料。

輪換主加密金鑰需要 ENCRYPTION_KEY_ADMIN 權限(或已過時的 SUPER 權限)。

若要輪換主加密金鑰,請執行

mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

ALTER INSTANCE ROTATE INNODB MASTER KEY 支援並行 DML。不過,它無法與表空間加密作業同時執行,並且會取得鎖定,以防止並行執行可能發生的衝突。如果 ALTER INSTANCE ROTATE INNODB MASTER KEY 作業正在執行,它必須先完成,才能繼續執行表空間加密作業,反之亦然。

加密和復原

如果在加密作業期間發生伺服器故障,作業會在伺服器重新啟動時向前推出。對於一般表空間,加密作業會從上次處理的頁面在背景執行緒中繼續執行。

如果在主金鑰輪換期間發生伺服器故障,InnoDB 會在伺服器重新啟動時繼續作業。

必須在儲存引擎初始化之前載入金鑰環組件或外掛程式,以便在 InnoDB 初始化和復原活動存取表空間資料之前,可以從表空間標頭擷取解密表空間資料頁面所需的資訊。(請參閱加密先決條件。)

InnoDB 初始化和復原開始時,主金鑰輪換作業會繼續執行。由於伺服器故障,某些表空間金鑰可能已經使用新的主加密金鑰進行加密。InnoDB 會從每個表空間標頭讀取加密資料,如果資料指出表空間金鑰是使用舊的主加密金鑰加密的,InnoDB 會從金鑰環擷取舊金鑰,並使用它來解密表空間金鑰。InnoDB 接著會使用新的主加密金鑰重新加密表空間金鑰,並將重新加密的表空間金鑰儲存回表空間標頭。

匯出已加密的表空間

表空間匯出僅支援每個表格一個檔案的表空間。

匯出已加密的表空間時,InnoDB 會產生一個傳輸金鑰,用於加密表空間金鑰。已加密的表空間金鑰和傳輸金鑰會儲存在 tablespace_name.cfp 檔案中。執行匯入作業時,需要此檔案以及已加密的表空間檔案。在匯入時,InnoDB 會使用傳輸金鑰解密 tablespace_name.cfp 檔案中的表空間金鑰。如需相關資訊,請參閱第 17.6.1.3 節,〈匯入 InnoDB 表格〉

加密和複寫

識別已加密的表空間和結構描述

Information Schema INNODB_TABLESPACES 表格包含一個 ENCRYPTION 資料行,可用於識別已加密的表空間。

mysql> SELECT SPACE, NAME, SPACE_TYPE, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
       WHERE ENCRYPTION='Y'\G
*************************** 1. row ***************************
     SPACE: 4294967294
      NAME: mysql
SPACE_TYPE: General
ENCRYPTION: Y
*************************** 2. row ***************************
     SPACE: 2
      NAME: test/t1
SPACE_TYPE: Single
ENCRYPTION: Y
*************************** 3. row ***************************
     SPACE: 3
      NAME: ts1
SPACE_TYPE: General
ENCRYPTION: Y

當在 CREATE TABLEALTER TABLE 陳述式中指定 ENCRYPTION 選項時,它會記錄在 INFORMATION_SCHEMA.TABLESCREATE_OPTIONS 資料行中。可以查詢此資料行,以識別位於已加密的每個表格一個檔案的表空間中的表格。

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
       WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test         | t1         | ENCRYPTION="Y" |
+--------------+------------+----------------+

查詢 Information Schema INNODB_TABLESPACES 表格,以擷取與特定結構描述和表格相關聯的表空間資訊。

mysql> SELECT SPACE, NAME, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME='test/t1';
+-------+---------+------------+
| SPACE | NAME    | SPACE_TYPE |
+-------+---------+------------+
|     3 | test/t1 | Single     |
+-------+---------+------------+

您可以查詢 Information Schema SCHEMATA 表格,以識別已啟用加密的結構描述。

mysql> SELECT SCHEMA_NAME, DEFAULT_ENCRYPTION FROM INFORMATION_SCHEMA.SCHEMATA
       WHERE DEFAULT_ENCRYPTION='YES';
+-------------+--------------------+
| SCHEMA_NAME | DEFAULT_ENCRYPTION |
+-------------+--------------------+
| test        | YES                |
+-------------+--------------------+

SHOW CREATE SCHEMA 也會顯示 DEFAULT ENCRYPTION 子句。

監控加密進度

您可以使用Performance Schema來監控一般表空間和 mysql 系統表空間加密進度。

stage/innodb/alter tablespace (encryption) 階段事件工具會報告一般表空間加密作業的 WORK_ESTIMATEDWORK_COMPLETED 資訊。

下列範例示範如何啟用 stage/innodb/alter tablespace (encryption) 階段事件工具和相關的取用者表格,以監控一般表空間或 mysql 系統表空間加密進度。如需 Performance Schema 階段事件工具和相關取用者的資訊,請參閱第 29.12.5 節,〈Performance Schema 階段事件表格〉

  1. 啟用 stage/innodb/alter tablespace (encryption) 工具

    mysql> USE performance_schema;
    mysql> UPDATE setup_instruments SET ENABLED = 'YES'
           WHERE NAME LIKE 'stage/innodb/alter tablespace (encryption)';
  2. 啟用階段事件取用者表格,其中包括 events_stages_currentevents_stages_historyevents_stages_history_long

    mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';
  3. 執行表空間加密作業。在此範例中,名為 ts1 的一般表空間會被加密。

    mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';
  4. 透過查詢 Performance Schema events_stages_current 表格,檢查加密作業的進度。WORK_ESTIMATED 報告表空間中的總頁數。WORK_COMPLETED 報告已處理的頁數。

    mysql> SELECT EVENT_NAME, WORK_ESTIMATED, WORK_COMPLETED FROM events_stages_current;
    +--------------------------------------------+----------------+----------------+
    | EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
    +--------------------------------------------+----------------+----------------+
    | stage/innodb/alter tablespace (encryption) |           1056 |           1407 |
    +--------------------------------------------+----------------+----------------+

    如果加密操作已完成,events_stages_current 表格會返回一個空集合。在這種情況下,您可以查看 events_stages_history 表格,以檢視已完成操作的事件資料。例如:

    mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_history;
    +--------------------------------------------+----------------+----------------+
    | EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
    +--------------------------------------------+----------------+----------------+
    | stage/innodb/alter tablespace (encryption) |           1407 |           1407 |
    +--------------------------------------------+----------------+----------------+

加密使用注意事項

  • 當使用 ENCRYPTION 選項來變更現有的每個表格空間檔案時,請妥善規劃。每個表格空間檔案中的表格會使用 COPY 演算法重建。INPLACE 演算法會在變更一般表格空間或 mysql 系統表格空間的 ENCRYPTION 屬性時使用。 INPLACE 演算法允許在一般表格空間中的表格上同時執行 DML。同時執行的 DDL 會被封鎖。

  • 當一般表格空間或 mysql 系統表格空間被加密時,該表格空間中的所有表格都會被加密。同樣地,在加密的表格空間中建立的表格也會被加密。

  • 如果伺服器在正常運作期間退出或停止,建議使用先前設定的相同加密設定重新啟動伺服器。

  • 第一個主加密金鑰會在第一個新的或現有的表格空間被加密時產生。

  • 主金鑰輪換會重新加密表格空間金鑰,但不會變更表格空間金鑰本身。若要變更表格空間金鑰,您必須停用並重新啟用加密。對於每個表格空間檔案,重新加密表格空間是一個 ALGORITHM=COPY 操作,會重建表格。對於一般表格空間和 mysql 系統表格空間,它是一個 ALGORITHM=INPLACE 操作,不需要重建位於表格空間中的表格。

  • 如果使用 COMPRESSIONENCRYPTION 選項建立表格,則會在表格空間資料加密之前執行壓縮。

  • 解除安裝 component_keyring_filecomponent_keyring_encrypted_file 元件並不會移除現有的金鑰環資料檔案。

  • 建議您不要將金鑰環資料檔案放置在與表格空間資料檔案相同的目錄下。

  • 當新增 FULLTEXT 索引時隱含建立的 InnoDB FULLTEXT 索引表格支援加密。如需相關資訊,請參閱 InnoDB 全文索引表格

加密限制

  • 進階加密標準 (AES) 是唯一支援的加密演算法。InnoDB 表格空間加密使用電子密碼本 (ECB) 區塊加密模式進行表格空間金鑰加密,並使用密碼區塊鏈結 (CBC) 區塊加密模式進行資料加密。CBC 區塊加密模式不使用填補。相反地,InnoDB 會確保要加密的文字是區塊大小的倍數。

  • 加密僅支援每個表格空間檔案一般表格空間和 mysql 系統表格空間。其他表格空間類型(包括 InnoDB 系統表格空間)則不支援加密。

  • 您無法將表格從加密的每個表格空間檔案一般表格空間或 mysql 系統表格空間移動或複製到不支援加密的表格空間類型。

  • 您無法將表格從加密的表格空間移動或複製到未加密的表格空間。但是,允許將表格從未加密的表格空間移動到加密的表格空間。例如,您可以將表格從未加密的每個表格空間檔案一般表格空間移動或複製到加密的一般表格空間。

  • 預設情況下,表格空間加密僅適用於表格空間中的資料。重新執行日誌和復原日誌資料可以透過啟用 innodb_redo_log_encryptinnodb_undo_log_encrypt 來加密。請參閱重新執行日誌加密復原日誌加密。如需二進位日誌檔案和中繼日誌檔案加密的資訊,請參閱第 19.3.2 節「加密二進位日誌檔案和中繼日誌檔案」

  • 不允許變更位於或先前位於加密表格空間中的表格的儲存引擎。