Zilliz Cloudにおける顧客管理の暗号化キー（CMEK）の導入
企業がより多くの AI ワークロードを本番環境へ移行するにつれて、ベクトルデータベースは RAG、セマンティック検索、AI エージェントなどのミッションクリティカルなアプリケーションの背後に配置されることが増えています。これらのワークロードは多くの場合、機密性の高いビジネスコンテキストに依存しているため、セキュリティチームは、データがどのように暗号化されるか、鍵がどのように管理されるか、アクセスをどのように監査または取り消せるかについて、明確な制御を必要としています。
Zilliz Cloud はすでに、AES-256 を使用してデフォルトで保存データを暗号化しています。本日、Zilliz Cloud における Customer-Managed Encryption Keys (CMEK) の一般提供により、お客様による制御をさらに強化する新たなレイヤーを追加します。
CMEK により、お客様は AWS Key Management Service (KMS) で独自の鍵を持ち込み、管理できます。これにより、セキュリティチームおよびコンプライアンスチームは、鍵のライフサイクル管理、アクセスポリシー、監査証跡、取り消し制御を直接所有しながら、Zilliz Cloud をフルマネージドのベクトルデータベースとして引き続き利用できます。
エンタープライズチームが鍵の直接制御を求める理由
デフォルトのプラットフォーム管理型暗号化は、あらゆるマネージドクラウドサービスにとって重要なベースラインです。多くのワークロードでは、お客様に運用上の複雑さを追加することなく、強力な保護を提供します。
しかし、一部のエンタープライズ環境や規制対象環境では、より高いレベルのお客様による制御が求められます。セキュリティチームは、自社のクラウドアカウントで鍵を管理したり、鍵の所有権をデータ処理から分離したり、既存の監査システムで鍵の使用状況を監視したり、サポートチケットを開いたりベンダー側のワークフローに依存したりせずにアクセスを取り消したりする必要がある場合があります。
CMEK は、こうしたチームのために設計されています。Zilliz Cloud のマネージドデータベース体験を維持しながら、お客様のデータを保護するために使用されるルート鍵を直接制御できるようにします。
Zilliz Cloud における CMEK の紹介
Zilliz Cloud はすでに、AES-256 を使用してデフォルトですべての保存データを暗号化しています。厳格なセキュリティ、コンプライアンス、またはデータガバナンス要件を持つ組織向けに、CMEK はお客様による制御を追加するレイヤーを提供します。プラットフォーム管理型の鍵のみに依存するのではなく、自社のクラウドプロバイダーの KMS でルート鍵を管理します。
CMEK により、データを保護するために使用されるルート鍵を制御できます。アーキテクチャは次のとおりです。
お客様は KMS で Customer Master Key (CMK) を生成して保存します。 これは KMS の境界を離れることはありません。Zilliz Cloud がマスター鍵を保有することはなく、必要なときに使用するための一時的かつ範囲限定のアクセスのみが付与されます。
CMK は、データベースごとに一意の中間 Encryption Zone Key (EZK) を暗号化します。Zilliz Cloud がデータを処理する必要がある場合、お客様の KMS に対して EZK の復号をリクエストします。復号された EZK は、必要な期間のみ、メモリ内にのみ存在します。この設計により、セキュリティ境界を弱めることなく、操作ごとの KMS 呼び出しを排除します。
EZK はファイルごとの Data Encryption Keys (DEKs) を暗号化します。これらは実際のベクトルブロック、インデックス、ログを保護します。この 3 階層アーキテクチャにより、影響範囲が制限されます。仮に 1 つの DEK が漏えいしたとしても、被害は 1 つのファイルに封じ込められます。
その結果、すべてのベクトル検索でお客様の KMS を呼び出すことによるミリ秒単位のペナルティなしに、お客様が制御する暗号化を実現します。マスター鍵は信頼のルートであり続ける一方で、Zilliz Cloud は低レイテンシのベクトル検索を継続して提供できます。
暗号化されるもの
Zilliz Cloud の CMEK は、ストレージレイヤーだけでなく、ライフサイクル全体にわたってデータを保護するように設計されています。
- オブジェクトストレージ — S3 内の binlog、インデックスファイル、スナップショット
- ローカル SSD キャッシュ — 低レイテンシ検索のためにコンピュートノードにキャッシュされたデータ
- メッセージキュー — 内部コンポーネント間を移動中の挿入および削除操作
データが長期ストレージで保存されている場合でも、パフォーマンスのためにキャッシュされている場合でも、内部処理パイプラインを流れている場合でも、AES-256 を使用して、お客様の鍵の下で暗号化された状態を維持します。
セキュリティチームが最も重視する 3 つの成果
1. 職務の分離 — 明確かつ監査可能
Zilliz Cloud はお客様のデータを処理し、保存します。お客様はご自身の KMS 内でキーを保持します。これらは、それぞれ異なる役割を持つ別個のエンティティです。お客様のコンプライアンスチームは、監査においてこの境界を明確に定義でき、多くのチームが GDPR、HIPAA、PCI-DSS、SOC 2 などのフレームワークに対応付ける職務分掌およびキー管理の統制をサポートするのに役立ちます。
2. 即時取り消し可能性 — 顧客による直接制御
侵害を検知した場合、ベンダー関係をオフボードする必要がある場合、またはリーガルホールドに対応しなければならない場合、お客様は KMS で CMK を直接無効化できます。その効果は即時です。影響を受ける Zilliz クラスター内のデータは、キーアクセスが復元されるまで、サービスによって読み取られたり処理されたりすることはできません。これはデータを削除または移動するものではなく、ベンダー側のワークフローにも依存しません。
これにより、チームはデータ主権、インシデント対応、ベンダーアクセス管理のための強力な制御ポイントを得られます。
3. 統合監査証跡 — 既存インフラストラクチャ内で
Zilliz Cloud からのすべてのキーアクセスリクエストは AWS CloudTrail に記録されます。セキュリティチームは、別個のベンダー固有ワークフローに依存するのではなく、すでに使用している同じ AWS 監査インフラストラクチャ内で、キーがいつどのようにアクセスされたかを確認できます。お客様の Zilliz 暗号化キーは、他の AWS KMS キーと並んで存在し、同じポリシーによって管理され、同じチームによって監視されます。
CMEK の始め方
私たちは、CMEK の導入を可能な限りスムーズにするよう努めてきました。
- ステップ 1 — IAM ポリシーを生成する。 Zilliz Console で、お客様の AWS アカウントに必要な正確な IAM ポリシースニペットを自動生成します。クラスターに適した principal ID が事前設定されています。手動で JSON を編集する必要はありません。
- ステップ 2 — キーを作成し、アクセスを承認する。 AWS KMS でキーを作成し、ポリシーを適用して、Zilliz に厳密にスコープされた権限（Decrypt と GenerateDataKey のみ）を付与します。必要以上に広範な権限はありません。
- ステップ 3 — クラスターで CMEK を有効化する。 新しい Dedicated クラスターを作成する際に、Key ARN を Zilliz Console に貼り付け、Customer-Managed Key を ON に切り替えます。
セットアップ全体は数日ではなく数分で完了します。キーのローテーションはダウンタイムなしでサポートされています。AWS KMS がローテーションを処理し、Zilliz Cloud は Key ARN にシームレスに追従します。
利用可能性
CMEK は現在、AWS 上の business-critical plan の Dedicated クラスターで利用可能です。開始する前に知っておくべき点がいくつかあります。
- 暗号化キーは project level で管理されます
- プロジェクトごとに最大 20 unique keys（重複キーを追加すると失敗します）
- クラスターが暗号化されると、データベース間でのコレクションの移行はサポートされません
- KMS キーのクラウドプロバイダーとリージョンは、Zilliz Cloud クラスターのものと一致している必要があります
- Milvus v2.5.x を実行している既存クラスターで CMEK を有効にするには、データをバックアップし、Milvus v2.6.x 上の新しいクラスターに復元してください — 既存クラスターをアップグレードしても、以前のデータは遡及的に暗号化されません
- AWS 以外のリージョンについては、利用可能性を相談するために お問い合わせください。
Zilliz Cloud の CMEK またはエンタープライズセキュリティについてご質問がありますか？詳細については、この CMEK ドキュメント をご確認いただくか、 当社のソリューションチーム までお問い合わせください。
読み続けて
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.