Cassandra TDE
KMIP 経由で DuoKey がキーを供給する、クラスター全体の SSTable とコミットログの暗号化 — レプリケーションされたピアツーピアクラスター向けに設計されたローテーションを備えます。
概要
Apache Cassandra は、プラグイン可能なキープロバイダーの拡張ポイント（DataStax Enterprise の Transparent Data Encryption やサードパーティの KMIP キープロバイダー jar が使用するものと同じもの）を通じて、SSTable とコミットログのセグメントを暗号化できます。このアプリは、そのキープロバイダーが KMIP 経由で DuoKey Cockpit からキーを取得するように設定し、キースペースを暗号化下に置くために必要な cassandra.yaml と CQL を生成します。
すべてのノードが同じ KMIP サーバーから同じ key_alias をロードするため、ストリーミングされたデータとコミットログのリプレイがクラスター全体で復号可能な状態に保たれます。
| プロパティ | 値 |
|---|---|
| 暗号化モデル | エンジンネイティブな TDE（SSTable + コミットログ、ノードごと） |
| キーの転送 | KMIP に支えられたキープロバイダー（プロバイダーは固定 — 常に DuoKey KMIP） |
| オンボーディング | アプリ詳細ページ — ウィザードのエントリなし |
| 実証ステータス | 生成される成果物（設定、CQL、ローテーションランブック）は実物で、そのまま利用可能。ライブのクラスタードライバーセッションはまだありません — 下記参照 |
Cassandra が他の TDE エンジンと異なる理由
このカタログの他のすべての TDE エンジンは、実質的に単一の論理インスタンスとやり取りします。リードレプリカを持つ Percona PostgreSQL でさえ、すべてのレプリカが同じ KMIP プリンシパルキーを同時に取得します。そこでのキーローテーションとは、新しいキーを作成し、エンジンをそれに向けるだけで完了します。
Apache Cassandra はピアツーピアでレプリケーションされたクラスターです。レプリケーションファクターが N の場合、すべての行は N 個のノードに存在し、ノード同士は絶えず生データを交換します。ブートストラップ/デコミッション/リペア時のストリーミング、ヒンテッドハンドオフ、そして再起動時に各ノードが自身のコミットログをリプレイする処理などです。SSTable とコミットログの暗号化は、そのノード自身の cassandra.yaml が現在指しているキーを使って、ノードごとにローカルで行われます。これは KEK でラップされたノードごとのキーではなく同一の共通鍵方式のキーであるため、ストリーミングされたデータとコミットログのリプレイが機能するには、クラスター全体で設定されるキーがバイト単位で同一でなければなりません。
新しいキーを作成して古いキーを直ちに無効化し、その後ノードを 1 台ずつローリングすると、まだ新しい設定を取り込んでいないすべてのノードが取り残されます。そのノードは自身のコミットログも、古いキーのままのノードからストリーミングされたデータも復号できなくなります。ノード A が新しいキーを持ち、ノード B が持たない期間は必ず存在します。そしてリペア、ストリーミング、ヒンテッドハンドオフは、その期間を通じて機能し続けなければなりません。
設定
| フィールド | 目的 | |
|---|---|---|
contact_points | native_port | クラスターへの到達に使用するシードノードとネイティブプロトコルのポート（デフォルトは 9042）。 |
cluster_name | `cassandra.yaml` の `cluster_name` と一致している必要があります。 | |
keyspace | このエンドポイントが暗号化を管理する対象のキースペース。 | |
replication_strategy | `SimpleStrategy`（単一データセンター）または `NetworkTopologyStrategy`（マルチデータセンター）。 | |
replication_factor | `SimpleStrategy` のレプリケーションファクター。 | |
datacenter_replication | `NetworkTopologyStrategy` 用の、データセンターごとのレプリケーションファクター（dc_name:rf） — 列挙されたすべてのデータセンターのすべてのノードが同じプリンシパルキーを適用する必要があります。 | |
sstable_encryption | commitlog_encryption | SSTable レベルとコミットログセグメントの暗号化を、それぞれ独立して切り替えます。 |
linked_key_id | クラスター全体のプリンシパルキーを支える DuoKey vault のキー。 |
デプロイ成果物
# every node in the cluster MUST use the SAME key_alias so
# streamed/replicated data stays decryptable cluster-wide.
transparent_data_encryption_options:
enabled: true
cipher: AES/CBC/PKCS5Padding
key_alias: <app-name>
key_provider:
- class_name: org.apache.cassandra.security.KmipKeyProviderFactory
parameters:
- kmip_host: <dke-cockpit-kmip-host>
kmip_port: 5696
key_label: <app-name>CREATE KEYSPACE IF NOT EXISTS "<keyspace>"
WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3, 'dc2': 2};
-- or, for SimpleStrategy:
-- WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};ALTER TABLE <keyspace>.<table> WITH compression = {
'sstable_compression': 'EncryptingLZ4Compressor',
'cipher_algorithm': 'AES/CBC/PKCS5Padding',
'secret_key_strength': 128,
'key_provider': 'KmipKeyProviderFactory'
};commitlog_compression:
- class_name: EncryptingLZ4Compressor
parameters:
cipher_algorithm: AES/CBC/PKCS5Padding
secret_key_strength: 128レプリケーションを考慮したキーローテーション
クラスター全体のキーはローリング展開中もバイト単位で同一である必要があるため、ローテーションは即時の切り替えではなく5 フェーズのランブックになります。これを成り立たせている不変条件は、新しいキーの作成の副作用として古いキーが破棄されることは決してないという点です。古いキーは active のまま残り、その後 deactivated（復号専用）へ移行し、保持期間の経過後に別途明示的に承認されたオペレーター操作によってのみ destroyed になります。
古いキーが破棄されるのはフェーズ 5 のみです — 保持期間の経過後に行われる、明示的で手動かつ監査された操作です。
新しいキーを作成する — デュアルアクティブのウィンドウが開く
新しいプリンシパルキーが KMIP サーバー上で作成され、有効化されます。古いキーはアクティブなままです。両方のキーが同時に提供可能なため、あるノードがどちらのキーを設定していても、処理中の復号要求が失敗することはありません。
ノードごとのローリング展開
1 台のノードの cassandra.yaml で key_alias を更新し、再起動し、クラスターへの再参加（nodetool status で UN）を待ち、ヘルスチェックのエンドポイントで確認してから、次のノードへ進みます。ラック/データセンターあたり同時に 1 台を超えないようにします。これは他の Cassandra のローリング再起動と同じ、クォーラムを維持するためのルールです。
クラスター全体での確認
すべてのコンタクトポイントが新しい key_alias を報告するまで、ヘルスチェック/セルフテストをポーリングします。肯定的なヘルスシグナルがないノードを移行済みとみなすことはありません。
古いキーを無効化する
すべてのノードが確認されたら、古いキーは deactivated（復号専用であり、破棄はされません）へ移行します。この時点以降、新しい書き込みは常に新しいキーのみを使用します。古いキーで暗号化されたままの既存の SSTable とコミットログのセグメントは、コンパクションによって新しいキーで書き換えられるまで復号可能なままです。
保持期間の経過後に破棄する
min_old_key_retention_days（デフォルトは 90 — 一般的な gc_grace_seconds やメジャーコンパクションのサイクルを十分に上回るように選ばれています）が経過し、かつオペレーターが nodetool/sstablemetadata によって、古い key_alias を参照する SSTable が残っていないことを手動で検証した後にのみ、古いキーが破棄されます。このステップは意図的に手動かつ監査対象であり、自動化されることはありません。
ディスク上のいずれかの SSTable がまだ参照しているキーを破棄すると、恒久的で復旧不能なデータ損失が発生します。フェーズ 5 は、将来フェーズ 2〜3 が自動化されたとしても、意図的に自動化されることはありません。
現時点で実物なもの、ランブックであるもの
| 機能 | ステータス |
|---|---|
| cassandra.yaml のキープロバイダースニペット、CQL のキースペース/テーブル文、ローテーション計画 | 実際に生成されます — オペレーターはこれらを直接使って作業できます |
| ノードごとの展開（フェーズ 2〜3）: 設定の配布、再起動、nodetool status のポーリング | まだ自動化されていません — 現時点ではオペレーター向けのランブックであり、駆動される状態機械ではありません。ローテーション計画は、ノードごとの確認ステータスをでっち上げるのではなく、確認なしとして報告します |
| キーの破棄（フェーズ 5） | 設計上、決して自動化されません — 成熟度のギャップではなく安全性の特性です |
Cassandra TDE の現在の忠実度は、MySQL TDE、MongoDB CSFLE、SQL Always Encrypted と同じ水準です。すなわち、生成されるセットアップ手順と、ライブのデータベースセッションではなくシミュレーションされたヘルス/セルフテストです。ローリング展開をエンドツーエンドで自動化することは自然な次のステップであり、オンホストのエージェントか、クラスター管理者の資格情報を持つネイティブプロトコルのドライバーのいずれかが必要になります。