AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

Azure Key Vault でカスタマーキーを管理する

注意

この機能は、次の配置では使用できません。

  • 無料クラスター

  • Flex クラスター

詳しくは、「 制限 」を参照してください。

AKV（Azure Key Vault）のカスタマー マネージド キー（CMK）を使用して、Atlas で保管中のデータをさらに暗号化できます。 Azure Private Link を使用して、 AKVへのすべてのトラフィックを構成することもできます。

注意

MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。

Atlas は Azure Key Vault CMKを使用して MongoDB マスターキーを暗号化および復号化します。 これらの MongoDB マスターキーは、クラスターのデータベースファイルとクラウドプロバイダーのスナップショットを暗号化するために使用されます。 Atlas で暗号化にCMKを使用する方法の詳細については、「 Azure Key Vault を使用したカスタマー マネージド キーについて 」を参照してください。

独自のクラウドプロバイダー KMS を使用する場合、Atlas は MongoDB マスター キーを少なくとも 90 日ごとに自動的にローテーションします。設定されている場合は、キーのローテーションはメンテナンスウィンドウ中に開始されます。メンテナンスを延期すること (手動または自動で) により、キーが 90日を過ぎてローテートされる原因となる可能性があります。キーは順次ローテーションされるため、プロセスでデータを書き換える必要はありません。

重要

Azure は CMK 向けのクライアント シークレットの有効期間を 2 年に制限します。Atlas は、クライアント シークレットの有効期限が切れると、CMK にアクセスできません。したがって、クライアント シークレットの有効期限が切れる前にローテートして、クラスターの可用性が失われるのを防ぎます。シークレッスオプションについて学ぶには、Azure Key Vault でのカスタマーキー管理 (シークレッス) を参照してください。

このページでは、Atlas プロジェクトでAKVを使用してカスタマー キー管理を設定する方法について説明します。 また、Atlas Administration API を使用して、 AKVで Azure Private Link を自動的に設定し、Atlas とAKV間のすべてのトラフィックがAzureのプライベート ネットワーク インターフェイスを介して行われるようにすることもできます。

注意

Atlas Infinite

パブリックプレビュー期間中、Atlas Infinite では Azure Key Vault を利用できません。Atlas Infinite は、パブリックプレビュー期間中、Amazon Web Services KMS を介したカスタマーマネージドキーのみをサポートします。Atlas Infinite の保管時の暗号化の仕組みについては、「Atlas Infinite 暗号化」を参照してください。

Atlas プロジェクトのカスタマー キー マネジメントを構成してから、そのプロジェクトのクラスターで有効にします。

Azure Key Vault を使用したカスタマー マネージド キーについて

Atlas では、エンベロープ暗号化というプロセスに沿ってカスタマー キーを管理します。このプロセスでは、あるキーを別のキーで暗号化することによって複数の暗号化レイヤーが作成されます。カスタマー キー管理を有効にするために、MongoDB Atlas では以下の暗号化キーが使用されます。

Customer-Managed Key (CMK)

Customer-managed keys are encryption keys that you create, own, and manage in Azure Key Vault. You create the CMK in Azure Key Vault and connect it to Atlas at the Project level. To learn more about the CMKs used in Azure Key Vault, see Azure Documentation.

Atlas はこのキーを MongoDB マスター キーの暗号化にのみ使用します。

MongoDB Master Key

Atlasマスター キーを作成しMongoDB 。 MongoDB マスターキーは、MongoDB Server がデータベースごとに暗号化されたキーを暗号化するために使用する暗号化キーです。 Atlas は、キーの暗号化されたコピーをローカルに保存します。

このキーは CMK で暗号化され、データベースごとに暗号化されたキーを暗号化します。

Per-Database Encryption Key

MongoDB Atlas の各ノードは、クラスター内のデータベースごとに暗号化のキーも作成します。Atlas はこれらのキーを使用して、WiredTiger を介してデータの読み取りと書き込みを行い、WiredTiger はこれらのキーを暗号化して保存します。

このキーは、MongoDB マスターキーで暗号化されます。

例

ノードが 3 つのレプリカ セットの次の暗号化階層を検討してみましょう。 Atlas は、Azure Key Vault のCMKを使用して、クラスター内の各ノードで一意の MongoDB マスター キーを暗号化します。 また、各ノードには 3 つのデータベースが含まれており、それぞれがデータベースごとに固有の暗号化キーで暗号化されています。 クラスターが起動すると、Atlas は Azure Key Vault のCMKを使用して MongoDB マスター キーを復号化し、これを MongoDB Server に提供します。

注意

Atlas の CMK へのアクセスを取り消すと、Atlas はクラスター内のノードをシャットダウンし、 CMK へのアクセスを復元するまでデータにアクセスできなくなります。

AKV と Atlas による CMK ワークフローの図

知っている必要があること

AKV CMK を使用するように Atlas を構成した後、 「 Azure Key 識別子のローテーション 」と「 停止時のAzure Key Vault フェイルオーバーの詳細 」を参照してください。

Azure キー識別子のローテーションについて

注意

この機能は、次の配置では使用できません。

  • 無料クラスター

  • Flex クラスター

詳しくは、「 制限 」を参照してください。

MongoDB マスターキー - MongoDB の責任

独自のクラウドプロバイダー KMS を使用する場合、Atlas は MongoDB マスター キーを少なくとも 90 日ごとに自動的にローテーションします。設定されている場合は、キーのローテーションはメンテナンスウィンドウ中に開始されます。メンテナンスを延期すること (手動または自動で) により、キーが 90日を過ぎてローテートされる原因となる可能性があります。キーは順次ローテーションされるため、プロセスでデータを書き換える必要はありません。

Azure キー ID のローテーション - お客様の責任

Atlas は、Azure Key Vault に使用されるキー識別子を自動的にローテーションしません。

Atlasencryption key rotation alert 90プロジェクトで保管時の 暗号化を有効 にする場合、Atlas はデフォルトで 日ごとに Azure キー識別子のローテーションを促すため、 を自動的に作成します。

You can rotate CMK stored in Azure Key Vault yourself or configure your Azure Key Vault to automatically rotate your keys. If you configure automatic rotation in Azure Key Vault, the default time period for rotation is approximately 365 days.

Azure Key Vault で自動ローテーションをすでに設定していて、90 日ごとに Azure キー識別子をローテーションするための Atlas アラートを受信したくない場合は、デフォルトのアラート期間を 365 日より長く変更できます。

停止時の Azure Key Vault フェイルオーバーについて

リージョン停止時中は、AKV リージョンが利用できなくなる可能性があります。このような場合、Azure は受信した Key Vault リクエストを事前に割り当てられたセカンダリ リージョンに自動的にルーティングします。詳しくは、Azure Key Vault フェイルオーバーとリージョンのペアを参照してください。

両方のリージョンがダウンした場合は、リージョン ペア外のリージョンにキーを手動で移行できます。詳しくは、「キーヴォールトをリージョン間で移動する」を参照してください。

注意

カスタマー キー マネジメントを使用した保管時の暗号化 を有効にした場合、停止中も少なくとも 1 つのノードが使用可能な状態であれば暗号化および復号化操作を実行できます。 Atlas はクラスターをシャットダウンしません。

特定のリージョンでは、Azure は自動フェイルオーバーをサポートしていません。詳しくは、Azure のドキュメント を参照してください。

必要なアクセス権

カスタマー キー マネジメントを構成するには、プロジェクトに対して Project Owner のアクセス権が必要です。

Organization Owner アクセス権を持つユーザーは、自分自身を Project Owner としてプロジェクトに追加する必要があります。

Permission Model を利用して、Atlas にお使いの AKV へのアクセスを付与する必要があります。Key Vault アクセス ポリシーまたは Azure RBAC を使用することで、アクセス権限を付与できます。

データプレーンの許可を付与する前に、まずサービスプリンシパルに読取者ロールを割り当てる必要があります。これは両方の許可モデル（RBAC とアクセス ポリシー）に必要です。

PowerShell

New-AzRoleAssignment `  -ObjectId "<SERVICE_PRINCIPAL_ID>" `  -RoleDefinitionName "Reader" `  -Scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.KeyVault/vaults/<KEY_VAULT_NAME>"

読み取りロールを割り当てた後、次のいずれかの権限モデルを使用してデータプレーンの権限を付与します。

アクセスを使用する場合は、 AzureポリシーUIで次の操作を実行して、Atlas に AKV へのアクセスを許可します。

  1. Follow the Azure documentation to grant the Microsoft.KeyVault/vaults/read permission to your application in the Access Control (IAM) settings:

    • ロールの割り当てを追加する場合は、Key Vault Reader ロールを選択します。

    • ノードを選択する際は、アプリケーションを選択します。

  2. Access Policies ページで、次の Key Permissions を使用してアクセス ポリシーを作成します。

    この権限を付与...
    宛先...

    得る

    AKV に保存されているキーに関するメタデータを読み取ります。

    暗号化

    AKV 内のキーを使用してデータを暗号化します。

    解読

    AKV 内のキーを使用して、以前にそれらのキーで暗号化されたデータを復号化します。

  3. プリンシパルと同じアプリを追加し、アクセス ポリシーを構成します。

  4. Azure ドキュメントに従って新しい RSA キーを作成します。キーバージョンの詳細を開き、次の手順で Atlas を構成するのに必要な Key Identifier URI をコピーします。

次のステップ

パブリック ネットワークまたはAzureプライベート エンドポイント経由で AKV（Azure Key Vault）からのカスタマー マネージド キー（CMK）を使用できます。 詳しくは、以下を参照してください。

Azure プライベートエンドポイントを使用する場合、Azure リソース ロックがプライベートエンドポイントの作成と削除をどのように阻止できるかを学ぶには、「Azure リソース ロック」を参照してください。

注意

カスタマー キー マネジメントを使用した保管時の暗号化 を有効にした場合、停止中も少なくとも 1 つのノードが使用可能な状態であれば暗号化および復号化操作を実行できます。

検索ノードでのカスタマー マネージド キーの有効化

デフォルトでは、MongoDBと検索プロセスは同じノードで実行されます。このアーキテクチャでは、カスタマー マネージドの暗号化はデータベースデータに適用されますが、検索インデックスには適用されません。

専用の検索ノードを有効にすると、検索プロセスは別々のノードで実行されます。これにより、検索ノード データの暗号化が有効になり、データベースデータと検索インデックスの両方を同じカスタマー マネージド キーで暗号化して、包括的な暗号化をカバーすることができます。

パブリックプレビュー期間中、Atlas Infiniteクラスタークラスターでは専用検索ノードはサポートされていません。

注意

データベース ノードと検索ノードは、同じカスタマー マネージド キーを使用して異なる暗号化方法を使用します。データベース ノードはWiredTiger暗号化ストレージ エンジンを使用し、検索ノードはディスク レベルの暗号化を使用します。

重要

この機能は KMS プロバイダー全体で利用できます。

戻る
プライベートエンドポイント経由のアクセスの設定
次へ
パブリック ネットワーク経由のアクセスの設定
このページを評価

項目一覧