Docs Menu
Docs Home
/
MongoDB Atlas
/

カスタマー キー管理を使用した保管時の暗号化

項目一覧

  • 必要なアクセス権
  • カスタマー キー管理による Atlas の構成
  • Atlas クラスターのカスタマー キー管理の有効化
  • 暗号化された Atlas クラスターへのノードの追加
  • KMS 構成の検証
  • 削除されたキーの復元
  • 暗号化されたバックアップ

重要

サーバーレスインスタンスで使用できない機能

サーバーレスインスタンスは現時点ではこの機能をサポートしていません。詳細については、 サーバーレスインスタンスの制限を参照してください。

Atlas は、デフォルトで保管中のすべてのクラスター ストレージとスナップショット ボリュームを暗号化します。クラウドプロバイダーの KMSと MongoDB 暗号化ストレージ エンジンを併用することで、セキュリティをさらに強化できます。

キー管理機能を使用して保管時の暗号化を構成すると、Atlas プロジェクトに追加料金が発生します。詳細については、「高度なセキュリティ」を参照してください。

Atlas プロジェクト向けに保管時の暗号化を構成する際、次のカスタマー キー管理プロバイダーの 1 つ以上を使用できます。

Atlasプロジェクトにキー管理プロバイダーを 1 つ構成したら、暗号化が必要な Atlas クラスターごとにカスタマー キー管理を有効にできます。キー管理プロバイダーは、クラスター クラウド サービス プロバイダーと同じである必要はありません。

注意

カスタマー キー管理を有効または無効にすると、Atlas は最初の同期を実行してクラスター データを再び暗号化します。

あるいは、M10 Azure リージョンのみに配置された 以上の Atlas クラスターを持つプロジェクトの場合、Atlas Administration API を使用して AKV に Azure Private Link を自動的に作成し、Atlas が Azure 経由で AKV と安全に通信できるようにします。取得します。詳しくは、「 Azure Key Vault を使用してカスタマー キーを管理する 」を参照してください。

Atlas はカスタマーが管理する暗号化キーをローテーションできません。キーのローテーションに関するガイダンスについては、キー管理プロバイダーのドキュメントを参照してください。プロジェクトでカスタマー キー管理を設定すると、MongoDB Atlas は 90 日間のキーローテーションアラートを作成します。

KMS プロバイダーが利用できなくなっても、実行中のクラスターは無効になりません。クラスターを再起動する場合、KMS プロバイダーを利用できないとクラスターが無効になります。

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

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

キー管理を使用して保管時の暗号化を行うには、有効なキー管理プロバイダーの認証情報と暗号化キーが必要です。これらの詳細を提供し、カスタマー キー管理を有効にするには、以下の手順に従います。

1
  1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

  3. サイドバーで、 Security見出しの下のAdvancedをクリックします。

    詳細ページが表示されます。

2
3
4
5

重要

現在のところ、インバウンド Atlas コントロール プレーン IP アドレスはまだ利用できません。API レスポンスのインバウンド IP アドレスリストは空になっています。インバウンド Atlas コントロール プレーン IP アドレスのリストを手動で取得するには、「必要なインバウンド アクセス」を参照してください。

KMS の構成によっては、プロジェクトで保管時の暗号化を有効にするために Atlas コントロール プレーンの IP アドレスを追加して、Atlasが KMS と通信できるようにする必要があります。Atlas と KMS 間の通信を有効にするには、次の操作を実行します。

  1. returnAllControlPlaneIPAddresses エンドポイントに GET リクエストを送信します。この API エンドポイントは、次のようにクラウドプロバイダーとリージョン別に分類されたインバウンドとアウトバウンド Atlas コントロール プレーン IP アドレスのリストを CIDR 形式で返します。

    {
    "controlPlane": {
    "inbound": {
    "aws": { // cloud provider
    "us-east-1": [ // region
    "3.92.113.229/32",
    "3.208.110.31/32",
    "107.22.44.69/32"
    ...,
    ],
    ...
    }
    },
    "outbound": {
    "aws": { // cloud provider
    "us-east-1": [ // region
    "3.92.113.229/32",
    "3.208.110.31/32",
    "107.22.44.69/32"
    ...,
    ],
    ...
    }
    }
    },
    "data_federation": {
    "inbound": {},
    "outbound" {}
    },
    "app_services": {
    "inbound": {},
    "outbound" {}
    },
    ...
    }
  2. 返された IP アドレスをクラウドプロバイダーの IP アクセス リストに追加します。詳細については、AWSAzureGCP でカスタマー キーを管理するための前提条件を参照してください。

カスタマー キー管理で Atlas を構成したら、暗号化するデータを含む Atlas クラスターごとにカスタマー キー管理を有効にする必要があります。

注意

該当プロジェクト内のクラスターのカスタマー キー管理を有効にするには、Project Owner ロールが必要です。

新しいクラスターの場合:

1

クラスター構成フォームで Manage your own encryption keys 設定を Yes に切り替えます。

2
  1. [Review Changes] をクリックします。

  2. 変更内容を確認し、[Apply Changes] をクリックしてクラスターを配置します。

3

キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。

  1. ipAddresses エンドポイントに GET リクエストを送信します。API エンドポイントは、次のような新しいクラスター ノードの IP アドレス リストを返します。

    {
    "groupId": "xxx", // ObjectId
    "services": {
    "clusters": [
    {
    "clusterName": "Cluster0",
    "inbound": [
    "3.92.113.229",
    "3.208.110.31",
    "107.22.44.69"
    ],
    "outbound": [
    "3.92.113.229",
    "3.208.110.31",
    "107.22.44.69"
    ]
    }
    ]
    }
    }
  2. 返された IP アドレスをクラウドプロバイダーの IP アクセス リストに追加します。IP アクセス リストは、プロビジョニング プランのロールバック前に、変更する必要があります。クラスターは、プロビジョニング プランが IP アクセス制限からロールバックする前に、最大 3 日間プロビジョニングを試みます。

    詳細については、AWSAzureGCP でカスタマー キーを管理するための前提条件を参照してください。

    注意

    IP アクセス リストの更新にさらに時間が必要な場合は、次の解決策があります。

    • 保管時の暗号化機能を使用せずにクラスターをプロビジョニングし、IP アクセス リストをアップデートしてから有効にします。

    • クラウドプロバイダーの KMS でより包括的な IP アクセス リストを構成し、保管時の暗号化を使用してクラスターを起動してから、IP アクセス リストを変更します。

既存クラスターの場合:

1
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Clusters ページがまだ表示されていない場合は、サイドバーの Database をクリックします。

    [ Clusters (クラスター) ] ページが表示されます。

2

暗号化するデータを含むクラスターで、クリックします、次にEdit Configurationを選択します。

3
  1. [Additional Settings] パネルを展開します。

  2. Manage your own encryption keys 設定を Yes に切り替えます。

  3. クラスターのRequire Private Networking設定のステータスを確認します。

    プロジェクト レベルで Atlas のCMKを使用した保管時の暗号化(オーバープライベート ネットワーク)を構成した場合、ステータスはActiveです。 プロジェクトにプライベートエンドポイント接続を構成していない場合、ステータスはInactiveです。

4
  1. [Review Changes] をクリックします。

  2. 変更内容を確認し、[Apply Changes] をクリックしてクラスターをアップデートします。

1

M10 以降のクラスターに選出可能なノードを追加するか、シャーディングされたクラスター内のシャードの数を増やすことができます。

2

キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。

  1. ipAddresses エンドポイントに GET リクエストを送信します。API エンドポイントは、次のような新しいクラスター ノードまたはシャードの IP アドレス リストを返します。

    {
    "groupId": "xxx", // ObjectId
    "services": {
    "clusters": [
    {
    "clusterName": "Cluster0",
    "inbound": [
    "3.92.113.229",
    "3.208.110.31",
    "107.22.44.69"
    ], // List<String>
    "outbound": [
    "3.92.113.229",
    "3.208.110.31",
    "107.22.44.69"
    ]
    }
    ]
    }
    }
  2. 返された IP アドレスをクラウドプロバイダーの IP アクセス リストに追加します。IP アクセス リストは、プロビジョニング プランのロールバック前に、変更する必要があります。クラスターは、プロビジョニング プランが IP アクセス制限からロールバックする前に、最大 3 日間プロビジョニングを試みます。

    詳細については、AWSAzureGCP でカスタマー キーを管理するための前提条件を参照してください。

Atlas は次のタイミングで KMS 構成を検証します。

次のいずれかの条件に一致する場合、Atlas は予定されている次回検証チェックで、すべての mongodmongos プロセスをシャットダウンします。

  • キー管理プロバイダーの認証情報が無効になった

  • 暗号化のキーを誰かが削除または無効にした

Atlasはキー管理プロバイダーに接続できない場合でも、プロセスをシャットダウンしません。すべての新しいプロジェクトで KMS ネットワークへのアクセス失敗が伝達されるように、Encryption at Rest KMS network access denied アラートはデフォルトで有効になっています。アラート設定を構成できます。

Atlas がクラスターをシャットダウンすると、次のイベントが発生します。

  • Atlas は、影響を受けるすべてのクラスターのリストを作成して、Project Owner に送信します。

  • Clusters ページには、保管時の暗号化設定が無効なため、Atlas がクラスターを無効にした状態が反映されています。

無効にされたクラスターではデータの読み取りも書き込みもできません。ディスクやインスタンス サイズの変更などの更新は、無効にされたクラスターに送信できます。Atlas はユーザーが暗号化キーを復元すると、こうした変更を処理します。また、メンテナンスとセキュリティ パッチの適用は継続します。無効にされたクラスターではすべてのデータが保持されるため、課金は継続されます。

注意

仮想マシンの電源

Atlas は、クラスターが無効になっている間も、クラスターが実行中の仮想マシン(VM)を停止しません。Atlas がサーバーを再起動するパッチを実行する場合がありますが、VM の電源はオフとオンに切り替わりません。

データへのアクセス権を復活するには、次のアクションを実行します。

[再試行] ボタンは、Atlas Advanced Security 設定の [CMK ID] フィールドの右側にあります
クリックして拡大します

構成を更新してから、[Try Again] をクリックして有効にします。再試行しない場合、Atlas は予定される次回のチェックで検証します。Atlas で構成の有効性が確認されると、すべての mongodmongos プロセスが再開します。

警告

キーが削除された場合、クラスターへのアクセスを回復するにはキーの復元が必要です。有効なキーがないと、カスタマー キー管理を使用して、キーを変更したり保管時の暗号化機能を無効にしたりできません。

削除されたキーを復元するには、キー管理プロバイダーのドキュメントを参照してください。

Atlas はすべてのスナップショット ボリュームを暗号化します。これにより、ディスク上のクラスター データが保護されます。クラウドプロバイダーの KMS を使用すると、次のことが可能になります。

  • バックアップを保存するスナップショット ストレージ ボリュームを暗号化する。

  • スナップショット内のデータファイルを暗号化する。

  • 暗号化されたスナップショットへのアクセス。詳細については、「暗号化されたスナップショットへのアクセス」を参照してください。

  • スナップショットの撮影時にアクティブだったキーでスナップショットを復元する。

  • PIT 復元 oplog データを暗号化する。

無効になったキーで暗号化されたスナップショットを復元することはできません。

ユーザーが管理しているキーで暗号化されたクラスターでは、レガシーバックアップ(非推奨)は有効にできません。基本スナップショット スケジュールを指定して、6 時間ごとにバックアップすることは可能です

カスタマー キー管理とクラウドバックアップの詳細については、以下を参照してください。

戻る

x.509