Atlas は、デフォルトで保管中のすべてのクラスター ストレージとスナップショット ボリュームを暗号化します。クラウドプロバイダーの KMS と MongoDB 暗号化されたストレージ エンジンを併用することで、セキュリティをさらに強化できます。
キー管理機能を使用して保管時の暗号化を構成すると、Atlas プロジェクトに追加料金が発生します。詳細については、「高度なセキュリティ」を参照してください。
注意
MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。
プロジェクト内のすべてのクラスターと専用検索配置で保管時の暗号化用のカスタマー マネージド キーが有効になっているようにするには、Atlas リソース ポリシーを使用します。クラスターや検索配置を作成または変更する前に、リソースポリシーを使用して CMK を要求できます。
Atlas プロジェクト向けに保管時の暗号化を構成する際、次のカスタマー キー管理プロバイダーの 1 つ以上を使用できます。
Atlasプロジェクトにキー管理プロバイダーを 1 つ構成したら、暗号化が必要な Atlas クラスターごとにカスタマー キー管理を有効にできます。キー管理プロバイダーは、クラスター クラウド サービス プロバイダーと同じである必要はありません。
注意
カスタマーキー管理を有効または無効にすると、Atlas は最初の同期を実行してクラスター データを再び暗号化します。クラスター上のMongoDB Search およびMongoDB ベクトル検索インデックスも再構築されます。
あるいは、M10 Azure リージョンのみに配置された 以上の Atlas クラスターを持つプロジェクトの場合、Atlas Administration API を使用して AKV に Azure Private Link を自動的に作成し、Atlas が Azure のプライベート ネットワーク インターフェースを介して AKV と安全に通信できるようにします。 。詳しくは、「 Azure Key Vault を使用してカスタマー キーを管理する 」を参照してください。
Atlas はカスタマーが管理する暗号化キーをローテーションできません。キーのローテーションに関するガイダンスについては、キー管理プロバイダーのドキュメントを参照してください。プロジェクトでカスタマー キー管理を設定すると、MongoDB Atlas は 90 日間のキーローテーションアラートを作成します。
KMS プロバイダーが利用できなくなっても、実行中のクラスターは無効になりません。クラスターを再起動する場合には、KMS プロバイダーを利用できないとクラスターが無効になります。
データ分類レベルや使用する暗号化のタイプなど、暗号化の推奨事項 の詳細については、Atlas アーキテクチャ センターの「Atlas データ暗号化の推奨事項」を参照してください。
注意
カスタマーマネージド キーを使用した保管時の暗号化を行っているクラスターの場合、Atlas データ検証には、データを複号化するために、KMS への追加アクセスが必要です。「データ検証 KMS の使用」を学ぶには、こちらを参照してください。
必要なアクセス権
カスタマー キー マネジメントを構成するには、プロジェクトに対して Project Owner のアクセス権が必要です。
Organization Owner アクセス権を持つユーザーは、自分自身を Project Owner としてプロジェクトに追加する必要があります。
カスタマー キー管理による Atlas の構成
キー管理を使用して保管時の暗号化を行うには、有効なキー管理プロバイダーの認証情報と暗号化キーが必要です。これらの詳細を提供し、カスタマー キー管理を有効にするには、以下の手順に従います。
Atlas で、プロジェクトの [Advanced] ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
（任意）Search Node Data Encryption の横にあるボタンを On に切り替えます。
オプションで、検索ノード上のすべてのデータの暗号化を有効にすることができます。この機能は後で有効にすることもできます。
詳細については、「検索ノードのカスタマーキー管理を有効にする」を参照してください。
（オプション）Atlas コントロール プレーンをアクセス先またはアクセス元として許可します。
詳細については、「Atlas Control Plane からのアクセス許可」を参照してください。
Atlas Control Plane からのアクセス許可
KMS の構成によっては、プロジェクトで保管時の暗号化を有効にするために Atlas コントロール プレーンの IP アドレスを追加して、Atlas が KMS と通信できるようにする必要がある場合があります。
Atlas と KMS 間の通信を有効にするには、次の操作を実行します。
エンドポイントに GET returnAllControlPlaneIpAddresses リクエストを送信します。
この API エンドポイントは、クラウドプロバイダーとリージョン別に分類されたインバウンドとアウトバウンド Atlas コントロール プレーン IP アドレスのリストを CIDR 形式で返します。詳細については、AWS、Azure 、GCP でカスタマー キーを管理するための前提条件を参照してください。
Atlas クラスターのカスタマー キー管理の有効化
カスタマー キー管理で Atlas を構成したら、暗号化するデータを含む Atlas クラスターごとにカスタマー キー管理を有効にする必要があります。
注意
該当プロジェクト内のクラスターのカスタマー キー管理を有効にするには、Project Owner ロールが必要です。
新しいクラスターの場合:
任意: 新しいクラスター ノードの IP アドレスを追加します。
キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。
ipAddressesエンドポイントに GET リクエストを送信します。returnAllIpAddresses 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 アクセス リストを変更します。
既存クラスターの場合:
Atlas で、プロジェクトの [Clusters] ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、 Database見出しの下のClustersをクリックします。
[ Clusters （クラスター） ] ページが表示されます。
検索ノードのカスタマー キー管理の有効化
プロジェクトのカスタマー キー マネジメントを構成する場合、検索ノードのカスタマー キー マネジメントを使用して暗号化を有効にすることもできます。これにより、インデックスを含むMongoDB SearchとMongoDB ベクトル検索のワークロードは、カスタマーマネージド キーで暗号化された状態になります。
この機能は、KMS プロバイダー全体で利用できます。
カスタマー マネージド キーを使用して検索ノードデータの暗号化を有効にする方法は以下のとおりです。
Atlas で、プロジェクトの [Advanced] ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
カスタマー キー管理を使用するか、構成を編集して保管時の暗号化を有効にします。
カスタマー キー管理をまだ構成していない場合は、「カスタマー キー管理で Atlas を構成」の手順に従います。
それ以外の場合は、Encryption at Rest using your Key Management の横にある Edit ボタンをクリックします。
Save[ をクリックします。
プロジェクトレベルで検索ノードのデータ暗号化を有効にすると、Atlas は検索ノードを持つ新規または既存のクラスターに対して、クラスター暗号化 1 または 2 を設定することで、クラスターレベルでも暗号化を有効にします。Atlas はカスタマーマネージドキーを使用して検索ノードを暗号化し、検索インデックスを再構築します。このプロセスにかかる時間は、インデックスのサイズと数によって異なります。
注意
プロジェクトレベルでカスタマーキーマネジメントを無効にするか、カスタマー管理キーが無効になると、Atlas はクラスターを一時停止し、Search ノードを削除するため、データベース クエリが利用できなくなります。
カスタマー キー マネジメントを再度有効にするか、キー構成を修正すると、Atlas はクラスターの一時停止を解除し、新しい検索ノードをプロビジョニングして、最初の同期を実行します。最初の同期が完了すると、検索機能が再開されます。
暗号化された Atlas クラスターへのノードの追加
レプリカセット クラスターまたはシャーディングされたクラスターにノードまたはシャードを追加する。
M10 以降のクラスターに選出可能なノードを追加するか、シャーディングされたクラスター内のシャードの数を増やすことができます。
任意: 新しいクラスター ノードまたはシャードから IP アドレスを追加する。
キー管理構成によっては、Atlas クラスター ノードの IP アドレスをクラウドプロバイダーの KMS アクセス リストに追加して、クラスターが KMS と通信できるようにする必要があります。クラスターと KMS 間の通信を有効にするには、次の操作を実行します。
ipAddressesエンドポイントに GET リクエストを送信します。この returnAllIpAddresses 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" ] } ] } }
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 を構成してから認証情報が変更された場合は、認証情報を更新します。
キーが無効化または削除されている場合は、キーを復元します。
![[再試行] ボタンは、Atlas Advanced Security 設定の [CMK ID] フィールドの右側にあります](/ja-jp/docs/platform/api/images/atlas/images/encryptionatrest-try-again.png)
構成を更新してから、[Try Again] をクリックして有効にします。再試行しない場合、Atlas は予定される次回のチェックで検証します。Atlas で構成の有効性が確認されると、すべての mongod と mongos プロセスが再開します。
警告
キーが削除された場合、クラスターへのアクセスを回復するにはキーの復元が必要です。有効なキーがないと、カスタマー キー管理を使用して、キーを変更したり保管時の暗号化機能を無効にしたりできません。
削除されたキーの復元
削除されたキーを復元するには、キー管理プロバイダーのドキュメントを参照してください。
AWS KMS: CMK の削除
Azure Key Vault: 削除されたキーの復元
GCP KMS: キーのバージョンの破棄と復元
データ検証 KMS 使用状況
カスタマーマネージド キーを使用した保管時の暗号化を行っているクラスターの場合、Atlas のデータ検証には、検証チェック中にデータを複号化するための追加の KMS アクセスが必要です。
データ検証は、すべてのプロジェクトでデフォルトで有効になっています。追加の KMS コスト、リクエスト、またはセキュリティの検討事項が要件と一致しない場合は、オプトアウトできます。
KMS の使用
データ検証が有効になっている場合、検証インスタンスは、暗号化されたクラスターからデータを複号化するために、KMS に追加のリクエストを行います。
リクエストボリューム:
Atlas は検証中に、1 時間あたりレプリカセット ノードごとに約 1 件の復号リクエストを行います。7 日間の検証ウィンドウを持つ標準的な 3 ノードのレプリカセットは、約 500 件の追加の KMS リクエストを生成します。
見積もりコスト:
ほとんどのクラスターでは、検証に関連する KMS コストは最小限です。現在の価格については、お使いのクラウドプロバイダーのドキュメントを参照してください。
セキュリティに関する考慮事項:
検証インスタンスは、KMS 監査ログに追加のプリンシパルとして表示されます。
KMS に IP 許可リストを使用する場合は、検証インスタンスの IP 範囲を許可リストに追加する必要がある場合があります。
検証インスタンスは、クラスター ノードと同じカスタマー マネージド キーを使用します。
検証インスタンス IP 範囲の現在のリストについては、MongoDB サポートにお問い合わせください。
暗号化されたクラスターの IP アローリスト構成
ほとんどの KMS 構成では、データ検証のために追加の IP アローリストの変更は必要ありません。ただし、KMS で IP アクセス制御を使用している場合 (例: ファイアウォール制限ありの Azure Key Vault)は、検証インスタンスの IP 範囲をアローリストに追加する必要があります。そうでない場合、検証は失敗します。
KMS の IP 許可リストを構成するには、次の手順に従ってください。
Amazon Web Services KMS は通常、IAM ロールによるアクセスを許可します。IAM ポリシーで Atlas ロールが許可されている場合、検証インスタンスに追加の IP アローリスト構成は必要ありません。
Azure Key Vaultは通常、厳密なIP許可リストを使用します。KMSアクセスエラーで検証が失敗した場合は、Atlas検証IP範囲をAzure Key Vaultネットワークルールに追加します。
Azure ポータルで、Key Vault に移動します。
左側メニューからNetworkingを選択します。
Firewalls and virtual networksで、Atlas 検証 IP 範囲を追加します。
[Save] をクリックします。
Google Cloud Platform の KMS は通常、サービス アカウントによるアクセスを許可します。IAM ポリシーで Atlas サービス アカウントが許可されている場合、検証インスタンスには追加の IP 許可リスト構成は必要ありません。
データ検証の詳細については、「クラスター整合性のデータ検証」を参照してください。
暗号化されたバックアップ
Atlas はすべてのスナップショット ボリュームを暗号化します。これにより、ディスク上のクラスター データが保護されます。クラウドプロバイダーの KMS を使用すると、次のことが可能になります。
バックアップを保存するスナップショット ストレージ ボリュームを暗号化する。
スナップショット内のデータファイルを暗号化する。
暗号化されたスナップショットへのアクセス。詳細については、「暗号化されたスナップショットへのアクセス」を参照してください。
スナップショットの撮影時にアクティブだったキーでスナップショットを復元する。
PIT 復元 oplog データを暗号化します。
無効になったキーで暗号化されたスナップショットを復元することはできません。
基本スナップショット スケジュール を指定して、6 時間ごとにバックアップすることは 可能です 。
注意
暗号化されたスナップショットは、暗号化されていないスナップショットと同じ方法でダウンロードできます。 セキュリティのベストプラクティスとして、プロジェクトの暗号化のキーへのロールベースのアクセスを使用することを推奨します。
スナップショットをダウンロードする方法については、「ローカルにダウンロードしたスナップショットから復元する」を参照してください。
カスタマー キー管理とクラウドバックアップの詳細については、以下を参照してください。