重要

古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。TiDBデータベースの最新の安定バージョンを使用することをお勧めします。

重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

保存時の暗号化

ノート：
クラスタがAWSにデプロイされ、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。 AWSドキュメント-EBS暗号化を参照してください。ローカルNVMeストレージなどのAWSで非EBSストレージを使用している場合は、このドキュメントで紹介されている保存時に暗号化を使用することをお勧めします。

保存時の暗号化とは、データが保存されるときに暗号化されることを意味します。データベースの場合、この機能はTDE（透過データ暗号化）とも呼ばれます。これは、飛行中の暗号化（TLS）または使用中の暗号化（めったに使用されない）とは対照的です。保管時に暗号化を行うことはさまざまですが（SSDドライブ、ファイルシステム、クラウドベンダーなど）、ストレージの前にTiKVに暗号化を行わせることで、攻撃者がデータにアクセスするためにデータベースで認証する必要があります。たとえば、攻撃者が物理マシンにアクセスした場合、ディスク上のファイルをコピーしてデータにアクセスすることはできません。

さまざまなTiDBコンポーネントでの暗号化のサポート

TiDBクラスタでは、コンポーネントごとに異なる暗号化方式が使用されます。このセクションでは、TiKV、TiFlash、PD、バックアップと復元（BR）などのさまざまなTiDBコンポーネントでの暗号化サポートを紹介します。

TiDBクラスタが展開されると、ユーザーデータの大部分はTiKVノードとTiFlashノードに保存されます。一部のメタデータはPDノードに保存されます（たとえば、TiKV領域の境界として使用されるセカンダリインデックスキー）。保管時に暗号化のメリットを最大限に活用するには、すべてのコンポーネントで暗号化を有効にする必要があります。暗号化を実装するときは、バックアップ、ログファイル、およびネットワークを介して送信されるデータも考慮する必要があります。

TiKV

TiKVは、保存時の暗号化をサポートしています。この機能により、 AESはクリック率モードを使用してデータファイルを透過的に暗号化できます。保管時に暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があり、このキーはマスターキーと呼ばれます。 TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーを手動で回転させることもできます。保存データの暗号化は保存データ（つまり、ディスク上）でのみ暗号化され、データがネットワーク経由で転送されている間は暗号化されないことに注意してください。残りの暗号化と一緒にTLSを使用することをお勧めします。

オプションで、クラウドとオンプレミスの両方のデプロイにAWSKMSを使用できます。プレーンテキストのマスターキーをファイルで指定することもできます。

TiKVは現在、コアダンプから暗号化キーとユーザーデータを除外していません。保管時に暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。

TiKVは、ファイルの絶対パスを使用して暗号化されたデータファイルを追跡します。その結果、 raftstore.raftdb-pathノードの暗号化がオンになったら、ユーザーはstorage.data-dirなどのデータファイルraftdb.wal-dirの構成を変更しないでrocksdb.wal-dir 。

TiFlash

TiFlashは、保存時の暗号化をサポートしています。データキーはTiFlashによって生成されます。 TiFlash（TiFlashプロキシを含む）に書き込まれるすべてのファイル（データファイル、スキーマファイル、および一時ファイルを含む）は、現在のデータキーを使用して暗号化されます。暗号化アルゴリズム、TiFlashでサポートされている暗号化構成（ tiflash-learner.tomlファイル内）、および監視メトリックの意味は、TiKVのものと一致しています。

Grafanaを使用してTiFlashをデプロイした場合は、 TiFlash-Proxy-Details- > Encryptionパネルを確認できます。

PD

PDの保存時の暗号化は実験的機能であり、TiKVと同じ方法で構成されます。

BRによるバックアップ

BRは、データをS3にバックアップするときに、S3サーバー側暗号化（SSE）をサポートします。お客様が所有するAWSKMSキーは、S3サーバー側の暗号化と一緒に使用することもできます。詳細については、 BRS3サーバー側の暗号化を参照してください。

ロギング

TiKV、TiDB、およびPD情報ログには、デバッグ目的のユーザーデータが含まれる場合があります。情報ログとその中のこのデータは暗号化されていません。ログ編集を有効にすることをお勧めします。

安静時のTiKV暗号化

概要

TiKVは現在、CTRモードでAES128、AES192、またはAES256を使用したデータの暗号化をサポートしています。 TiKVはエンベロープ暗号化を使用します。その結果、暗号化が有効になっている場合、TiKVでは2種類のキーが使用されます。

マスターキー。マスターキーはユーザーによって提供され、TiKVが生成するデータキーを暗号化するために使用されます。マスターキーの管理はTiKVの外部にあります。
データキー。データキーはTiKVによって生成され、データの暗号化に実際に使用されるキーです。

同じマスターキーをTiKVの複数のインスタンスで共有できます。本番環境でマスターキーを提供するための推奨される方法は、AWSKMSを使用することです。 AWS KMSを使用してカスタマーマスターキー（CMK）を作成し、CMKキーIDを設定ファイルのTiKVに提供します。 TiKVプロセスは、実行中にKMS CMKにアクセスする必要があります。これは、 IAMの役割を使用して実行できます。 TiKVがKMSCMKにアクセスできない場合、起動または再起動に失敗します。 KMSおよびわたしの使用法については、AWSのドキュメントを参照してください。

または、カスタムキーを使用する必要がある場合は、ファイルを介したマスターキーの提供もサポートされています。ファイルには、16進文字列としてエンコードされた256ビット（または32バイト）のキーが含まれ、改行（つまり、 \n ）で終わり、他には何も含まれていない必要があります。ただし、キーをディスクに保持するとキーがリークするため、キーファイルはRAMのtempfsに保存する場合にのみ適しています。

データキーは、基盤となるストレージエンジン（つまり、RocksDB）に渡されます。 SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーによって暗号化されます。ユーザーデータを含む可能性のあるTiKVによって使用される他の一時ファイルも、同じデータキーを使用して暗号化されます。データキーは、デフォルトで毎週TiKVによって自動的にローテーションされますが、期間は構成可能です。キーローテーションでは、TiKVは既存のすべてのファイルをリライトしてキーを置き換えるわけではありませんが、クラスタが一定の書き込みワークロードを取得する場合、RocksDBコンパクションは古いデータを最新のデータキーで新しいデータファイルにリライトすることが期待されます。 TiKVは、各ファイルの暗号化に使用されるキーと暗号化方法を追跡し、その情報を使用して読み取り時にコンテンツを復号化します。

データの暗号化方法に関係なく、データキーは追加の認証のためにGCMモードのAES256を使用して暗号化されます。これには、KMSの代わりにファイルから渡す場合、マスターキーが256ビット（32バイト）である必要がありました。

キーの作成

AWSでキーを作成するには、次の手順に従います。

AWSコンソールのAWS KMSに移動します。
コンソールの右上隅で正しい領域を選択していることを確認してください。
[キーの作成]をクリックし、キータイプとして[対称]を選択します。
キーのエイリアスを設定します。

AWSCLIを使用して操作を実行することもできます。

aws --region us-west-2 kms create-key
aws --region us-west-2 kms create-alias --alias-name "alias/tidb-tde" --target-key-id 0987dcba-09fe-87dc-65ba-ab0987654321

2番目のコマンドに入力する--target-key-idは、最初のコマンドの出力にあります。

暗号化を構成する

暗号化を有効にするには、TiKVおよびPDの構成ファイルに暗号化セクションを追加します。

[security.encryption]
data-encryption-method = "aes128-ctr"
data-key-rotation-period = "168h" # 7 days

data-encryption-methodに指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、および「plaintext」です。デフォルト値は「plaintext」です。これは、暗号化がオンになっていないことを意味します。 data-key-rotation-periodは、TiKVがデータキーをローテーションする頻度を定義します。新しいTiKVクラスタまたは既存のTiKVクラスタに対して暗号化をオンにすることができますが、暗号化を有効にした後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルのdata-encryption-methodを削除するか、「plaintext」にリセットして、TiKVを再起動します。暗号化方式を変更するには、構成ファイルのdata-encryption-methodを更新し、TiKVを再起動します。

暗号化が有効になっている場合（つまり、 data-encryption-methodは「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。 AWS KMS CMKをマスターキーとして指定するには、 encryptionセクションの後にencryption.master-keyセクションを追加します。

[security.encryption.master-key]
type = "kms"
key-id = "0987dcba-09fe-87dc-65ba-ab0987654321"
region = "us-west-2"
endpoint = "https://kms.us-west-2.amazonaws.com"

key-idは、KMSCMKのキーIDを指定します。 regionは、KMSCMKのAWSリージョン名です。 endpointはオプションであり、AWS以外のベンダーのAWS KMS互換サービスを使用しているか、 KMSのVPCエンドポイントを使用する必要がない限り、通常は指定する必要はありません。

AWSでもマルチリージョンキーを使用できます。このためには、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。

ファイルに保存されるマスターキーを指定するには、マスターキーの構成は次のようになります。

[security.encryption.master-key]
type = "file"
path = "/path/to/key/file"

ここで、 pathはキーファイルへのパスです。ファイルには、16進文字列としてエンコードされた256ビット（または16バイト）のキーが含まれ、改行（ \n ）で終わり、他には何も含まれていない必要があります。ファイルの内容の例：

3b5896b5be691006e0f71c3040a29495ddcad20b14aff61806940ebd780d3c62

マスターキーを回転させます

マスターキーをローテーションするには、構成で新しいマスターキーと古いマスターキーの両方を指定し、TiKVを再起動する必要があります。 security.encryption.master-keyを使用して新しいマスターキーを指定し、 security.encryption.previous-master-keyを使用して古いマスターキーを指定します。 security.encryption.previous-master-keyの構成フォーマットはencryption.master-keyと同じです。再起動時に、TiKVは古いマスターキーと新しいマスターキーの両方にアクセスする必要がありますが、TiKVが起動して実行されると、TiKVは新しいキーにのみアクセスする必要があります。それ以降、構成ファイルにencryption.previous-master-keyの構成を残しておいてもかまいません。再起動しても、TiKVは、新しいマスターキーを使用して既存のデータを復号化できない場合にのみ、古いキーを使用しようとします。

現在、オンラインマスターキーローテーションはサポートされていないため、TiKVを再起動する必要があります。オンラインクエリを提供する実行中のTiKVクラスタに対してローリングリスタートを実行することをお勧めします。

KMSCMKをローテーションするための設定例を次に示します。

[security.encryption.master-key]
type = "kms"
key-id = "50a0c603-1c6f-11e6-bb9e-3fadde80ce75"
region = "us-west-2"

[security.encryption.previous-master-key]
type = "kms"
key-id = "0987dcba-09fe-87dc-65ba-ab0987654321"
region = "us-west-2"

監視とデバッグ

保管時の暗号化を監視するために、Grafanaを使用してTiKVをデプロイする場合は、 TiKV-詳細ダッシュボードの[暗号化]パネルを確認できます。探すべきいくつかのメトリックがあります：

初期化された暗号化：TiKVの起動中に暗号化が初期化された場合は1、それ以外の場合は0。マスターキーローテーションの場合、暗号化が初期化された後、TiKVは前のマスターキーにアクセスする必要はありません。
暗号化データキー：既存のデータキーの数。データキーのローテーションが発生するたびに、数値は1ずつ増えます。このメトリックを使用して、データキーのローテーションが期待どおりに機能するかどうかを監視します。
暗号化されたファイル：現在存在する暗号化されたデータファイルの数。以前に暗号化されていないクラスタの暗号化をオンにしたときに、この数をデータディレクトリ内の既存のデータファイルと比較して、暗号化されているデータの一部を推定します。
暗号化メタファイルサイズ：暗号化メタデータファイルのサイズ。
読み取り/書き込み暗号化メタ期間：暗号化のためにメタデータを操作するための追加のオーバーヘッド。

デバッグの場合、 tikv-ctlコマンドを使用して、ファイルの暗号化に使用される暗号化方式やデータキーIDなどの暗号化メタデータ、およびデータキーのリストをダンプできます。この操作は機密データを公開する可能性があるため、本番環境での使用はお勧めしません。 TiKVコントロールドキュメントを参照してください。

TiKVバージョン間の互換性

TiKVが暗号化メタデータを管理するときにI/Oとミューテックスの競合によって引き起こされるオーバーヘッドを減らすために、最適化がTiKV v4.0.9に導入され、TiKV構成ファイルでsecurity.encryption.enable-file-dictionary-logによって制御されます。この構成パラメーターは、TiKVv4.0.9以降のバージョンでのみ有効です。

有効になっている場合（デフォルト）、暗号化メタデータのデータ形式はTiKVv4.0.8以前のバージョンでは認識できません。たとえば、暗号化を保存し、デフォルトのenable-file-dictionary-log構成でTiKVv4.0.9以降を使用するとします。クラスタをTiKVv4.0.8以前にダウングレードすると、TiKVの起動に失敗し、情報ログに次のようなエラーが表示されます。

[2020/12/07 07:26:31.106 +08:00] [ERROR] [mod.rs:110] ["encryption: failed to load file dictionary."]
[2020/12/07 07:26:33.598 +08:00] [FATAL] [lib.rs:483] ["called `Result::unwrap()` on an `Err` value: Other(\"[components/encryption/src/encrypted_file/header.rs:18]: unknown version 2\")"]

上記のエラーを回避するには、最初にsecurity.encryption.enable-file-dictionary-logをfalseに設定し、v4.0.9以降でTiKVを開始します。 TiKVが正常に起動すると、暗号化メタデータのデータ形式は、以前のTiKVバージョンで認識できるバージョンにダウングレードされます。この時点で、TiKVクラスタを以前のバージョンにダウングレードできます。

BRS3サーバー側の暗号化

BRを使用してS3にバックアップするときにS3サーバー側の暗号化を有効にするには、 --s3.sseの引数を渡し、値を「aws：kms」に設定します。 S3は、暗号化に独自のKMSキーを使用します。例：

./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms

作成して所有したカスタムAWSKMSCMKを使用するには、さらに--s3.sse-kms-key-idを渡します。この場合、BRプロセスとクラスタのすべてのTiKVノードの両方がKMS CMKにアクセスする必要があり（たとえば、AWS IAM経由）、KMSCMKは以前のS3バケットと同じAWSリージョンにある必要がありますバックアップを保存します。 AWSIAMを介してBRプロセスおよびTiKVノードにKMSCMKへのアクセスを許可することをお勧めします。わたしの使用法については、AWSのドキュメントを参照してください。例えば：

./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.region <region> --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321

バックアップを復元するときは、 --s3.sseと--s3.sse-kms-key-idの両方を使用しないでください。 S3はそれ自体で暗号化設定を把握します。バックアップを復元するクラスタのBRプロセスとTiKVノードも、KMS CMKにアクセスする必要があります。そうしないと、復元が失敗します。例：

./br restore full --pd <pd-address> --storage "s3://<bucket>/<prefix> --s3.region <region>"