カスタマー キー管理を使用した保管時の暗号化
項目一覧
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
としてプロジェクトに追加する必要があります。
カスタマー キー管理による Atlas の構成
キー管理を使用して保管時の暗号化を行うには、有効なキー管理プロバイダーの認証情報と暗号化キーが必要です。これらの詳細を提供し、カスタマー キー管理を有効にするには、以下の手順に従います。
Atlas Atlasで、プロジェクトの {0 ページにGoします。GoAdvanced
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のAdvancedをクリックします。
詳細ページが表示されます。
Atlas コントロール プレーンからのアクセスを許可します。
任意。
KMS の構成によっては、プロジェクトで保管時の暗号化を有効にするために Atlas コントロール プレーンの IP アドレスを追加して、Atlasが KMS と通信できるようにする必要があります。
Atlas と KMS 間の通信を有効にするには、次の操作を実行します。
エンドポイントに GETreturnAllControlPlaneIPAddresses
リクエストを送信します。
API エンドポイントは、クラウドプロバイダーとリージョン別に分類されたインバウンドとアウトバウンド Atlas コントロール プレーン IP アドレスのリストを CIDR 形式で返します。詳細については、 GCP 、 Azure 、 AWSでカスタマーキーを管理するための前提条件を参照してください。
Atlas クラスターのカスタマー キー管理の有効化
カスタマー キー管理で Atlas を構成したら、暗号化するデータを含む Atlas クラスターごとにカスタマー キー管理を有効にする必要があります。
注意
該当プロジェクト内のクラスターのカスタマー キー管理を有効にするには、Project Owner
ロールが必要です。
新しいクラスターの場合:
任意: 新しいクラスター ノードの IP アドレスを追加します。
キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。
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" ] } ] } } 返された IP アドレスをクラウドプロバイダーの IP アクセス リストに追加します。IP アクセス リストは、プロビジョニング プランのロールバック前に、変更する必要があります。クラスターは、プロビジョニング プランが IP アクセス制限からロールバックする前に、最大 3 日間プロビジョニングを試みます。
詳細については、AWS、Azure、GCP でカスタマー キーを管理するための前提条件を参照してください。
注意
IP アクセス リストの更新にさらに時間が必要な場合は、次の解決策があります。
保管時の暗号化機能を使用せずにクラスターをプロビジョニングし、IP アクセス リストをアップデートしてから有効にします。
クラウドプロバイダーの KMS でより包括的な IP アクセス リストを構成し、保管時の暗号化を使用してクラスターを起動してから、IP アクセス リストを変更します。
既存クラスターの場合:
AtlasGoClustersAtlas で、プロジェクトの ページにGoします。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
まだ表示されていない場合は、サイドバーの Clusters をクリックしてください。
[ Clusters (クラスター) ] ページが表示されます。
暗号化された Atlas クラスターへのノードの追加
レプリカセット クラスターまたはシャーディングされたクラスターにノードまたはシャードを追加する。
M10 以降のクラスターに選出可能なノードを追加するか、シャーディングされたクラスター内のシャードの数を増やすことができます。
任意: 新しいクラスター ノードまたはシャードから IP アドレスを追加する。
キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。
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" ] } ] } } 返された IP アドレスをクラウドプロバイダーの IP アクセス リストに追加します。IP アクセス リストは、プロビジョニング プランのロールバック前に、変更する必要があります。クラスターは、プロビジョニング プランが IP アクセス制限からロールバックする前に、最大 3 日間プロビジョニングを試みます。
KMS 構成の検証
Atlas は次のタイミングで KMS 構成を検証します。
認証情報を追加または更新するとき。
15 分ごと。
保管時の暗号化 API エンドポイントを使用して、オンデマンドで。
次のいずれかの条件に一致する場合、Atlas は予定されている次回検証チェックで、すべての mongod
と mongos
プロセスをシャットダウンします。
キー管理プロバイダーの認証情報が無効になった
暗号化のキーを誰かが削除または無効にした
Atlasはキー管理プロバイダーに接続できない場合でも、プロセスをシャットダウンしません。すべての新しいプロジェクトで KMS ネットワークへのアクセス失敗が伝達されるように、Encryption at Rest KMS network access denied
アラートはデフォルトで有効になっています。アラート設定を構成できます。
Atlas がクラスターをシャットダウンすると、次のイベントが発生します。
Atlas は、影響を受けるすべてのクラスターのリストを作成して、
Project Owner
に送信します。Clusters ページには、保管時の暗号化設定が無効なため、Atlas がクラスターを無効にした状態が反映されています。
無効にされたクラスターではデータの読み取りも書き込みもできません。ディスクやインスタンス サイズの変更などの更新は、無効にされたクラスターに送信できます。Atlas はユーザーが暗号化キーを復元すると、こうした変更を処理します。また、メンテナンスとセキュリティ パッチの適用は継続します。無効にされたクラスターではすべてのデータが保持されるため、課金は継続されます。
注意
仮想マシンの電源
Atlas は、クラスターが無効になっている間も、クラスターが実行中の仮想マシン(VM)を停止しません。Atlas がサーバーを再起動するパッチを実行する場合がありますが、VM の電源はオフとオンに切り替わりません。
データへのアクセス権を復活するには、次のアクションを実行します。
カスタマー キー管理で Atlas を構成してから認証情報が変更された場合は、認証情報を更新します。
キーが無効化または削除されている場合は、キーを復元します。
構成を更新してから、[Try Again] をクリックして有効にします。再試行しない場合、Atlas は予定される次回のチェックで検証します。Atlas で構成の有効性が確認されると、すべての mongod
と mongos
プロセスが再開します。
警告
キーが削除された場合、クラスターへのアクセスを回復するにはキーの復元が必要です。有効なキーがないと、カスタマー キー管理を使用して、キーを変更したり保管時の暗号化機能を無効にしたりできません。
削除されたキーの復元
削除されたキーを復元するには、キー管理プロバイダーのドキュメントを参照してください。
AWS KMS: CMK の削除
Azure Key Vault: 削除されたキーの復元
GCP KMS: キーのバージョンの破棄と復元
暗号化されたバックアップ
Atlas はすべてのスナップショット ボリュームを暗号化します。これにより、ディスク上のクラスター データが保護されます。クラウドプロバイダーの KMS を使用すると、次のことが可能になります。
バックアップを保存するスナップショット ストレージ ボリュームを暗号化する。
スナップショット内のデータファイルを暗号化する。
暗号化されたスナップショットへのアクセス。詳細については、「暗号化されたスナップショットへのアクセス」を参照してください。
スナップショットの撮影時にアクティブだったキーでスナップショットを復元する。
PIT 復元 oplog データを暗号化する。
無効になったキーで暗号化されたスナップショットを復元することはできません。
ユーザーが管理しているキーで暗号化されたクラスターでは、レガシーバックアップ(非推奨)は有効にできません。基本スナップショット スケジュールを指定して、6 時間ごとにバックアップすることは可能です。
カスタマー キー管理とクラウドバックアップの詳細については、以下を参照してください。