次の Atlas 機能を使用して、コンプライアンス要件に対処します。
認証と規制へのコンプライアンス
MongoDB Atlas は、セキュリティ、コンプライアンス、プライバシーの要件に対処するためのさまざまな機能と構成を提供しています。
MongoDB Atlasデータプラットフォームは、そのセキュリティ、プライバシー、および組織制御を検証するために、厳格な独立した第三者による監査を受けます。Atlas は、ISO/ IEC 27001、SOC2 Type II、PCI DSS などのコンプライアンスフレームワークに準拠し、Atlas 信頼センター に記載されています。認証、コンプライアンスレポート、およびその他のコンプライアンスドキュメントは、カスタマー トラスト ポータルで表示およびダウンロードができます。
MongoDB Atlas for Government
MongoDB Atlas for Government は、FedRAMP: モードで認可されたマルチクラウド開発者向けデータプラットフォームであり、
FedRAMP® 認定を受けた、安全で完全管理された専用環境を利用できます。
米国政府の独自の要件と任務をサポートします。
レガシー アプリケーションを最新化するために必要な機能セットとスケーラビリティを提供します。
Atlas リソース ポリシー
コンプライアンス要件に対応するため、Atlas リソース ポリシーは組織全体の統制を提供し、セキュリティ、コンプライアンス、運用におけるベストプラクティスに沿ったリソースの構成および管理を可能にします。組織のオーナーは、クラスター、ネットワーク構成、プロジェクト設定といったリソースを作成・変更する際のユーザー アクションを管理するルールを定義できます。組織作成時には、自社の基準に基づいてリソース ポリシーを設定することを推奨します。
Atlas リソース ポリシーは、次のようにしてコンプライアンス上の目標達成をサポートします。
最小 TLS バージョンの強制: 最新の TLS プロトコルをすべての Atlas 配置に適用し、古くて安全性の低いバージョンに伴うリスクを軽減しながらセキュリティを強化します。これにより、すべての転送中データに対して最新の暗号化標準の遵守が保証されます。
デフォルトの TLS 暗号をカスタマイズ: 許可された TLS 暗号の特定のセットを選択して、レガシー暗号化メソッドに関連する脆弱性を回避しながら、運用ニーズに基づいてセキュリティを最適化します。これにより、特定のコンプライアンス要件を満たすために暗号化プロトコルを微調整できます。
VPC ピアリングの変更の制限: 既存の VPC ピアリング接続を利用して、安全なクロスネットワーク通信を可能にしつつ、構成変更を防止します。現在のプロジェクト レベルのピアリングは、既存のルーティング テーブルとセキュリティ プロトコルで有効なまま維持され、顧客は VPC関係およびそれに関連するネットワーク制御メカニズムを参照することはできますが、変更することはできません。
プライベートエンドポイントの変更を制限: 既存のプライベート エンドポイント構成を読み取り専用で維持することで、安全なサービス接続を確保します。プロジェクトレベルの接続は、現在のプライベート IP アドレッシング方式の下で機能し続けます。顧客は VPC 内の専用サービス接続ポイントを参照できますが、変更することはできません。
IP アクセス リストの制御: IP アクセス リストへの不正変更を防止し、データベースへのコンシステントで制御されたネットワーク アクセスをサポートします。これにより、慎重に定義されたネットワーク境界が維持され、誤った構成変更から保護されることで、データベースのセキュリティが強化されます。
クラスター階層の制限を設定: 最大および最小のクラスター サイズ制限を設定することで、配置のガードレールを定義し、開発者がリソースをプロビジョニングする際に遵守すべき基準を定めます。この境界設定アプローチにより、チームは組織承認済みのパラメーター内で適切に分離された環境を配置でき、インフラストラクチャの利用を最適化しつつ、すべてのプロジェクト ワークロードにわたって一貫したリソース割り当てポリシーを強制できます。
メンテナンスウィンドウ要件の設定: すべてのプロジェクトに対してメンテナンスウィンドウを要求することで、プラットフォームの安定性を強化します。このガバナンス制御により、組織は予測可能な更新期間(特定の期間を指定せずに)を設定し、運用ニーズに応じてコンシステントなシステムメンテナンスをサポートできます。
クラウドプロバイダーとリージョンを設定する:クラウドプロバイダーを設定し、クラスターを複数のリージョンとプロバイダーに分散して、データレジデンシー要件を満たし、高可用性を確保します。
ワイルドカードIPアドレスの使用をブロックする: IP アクセス リストまたはファイアウォールルールにワイルドカードIPアドレスを含めずに、明示的に許可されたIPアドレスのみにクラスターへのアクセスを制限します。ワイルドカードIPアドレスは 0.0.0.0/0 で、あらゆる場所からのアクセスを許可します。
詳細については、「Atlas リソース ポリシー」を参照してください。
以下のリソース ポリシー例では、AWS 上にクラスターを作成できるようにします。
{ "name": "Only Allow Clusters on AWS", "policies": [ { "body": "forbid ( principal, action == cloud::Action::\"cluster.createEdit\", resource) unless { context.cluster.cloudProviders == [cloud::cloudProvider::\"aws\"] };" } ] }
次の例では、Terraform リソース ポリシー ファイルを作成し、アプリケーション内でリソース ポリシーを適用するために使用できます。このファイルは、次のポリシーを強制します。
クラスターの変更を特定のクラウドプロバイダーのみに制限します。
ワイルドカード IP アドレスからのクラスターへのアクセスを禁止する。
クラスターの最小および最大サイズを指定する。
プライベート エンドポイントの変更を防止する。
resource "mongodbatlas_resource_policy" "restrict_cloud_provider" { org_id = var.org_id name = "restrict-cloud-provider" policies = [ { body = <<EOF forbid ( principal, action == ResourcePolicy::Action::"cluster.modify", resource ) unless { context.cluster.cloudProviders == [ResourcePolicy::CloudProvider::"<cloud provider name>"] }; EOF }, ] } resource "mongodbatlas_resource_policy" "forbid_project_access_anywhere" { org_id = var.org_id name = "forbid-project-access-anywhere" policies = [ { body = <<EOF forbid ( principal, action == ResourcePolicy::Action::"project.ipAccessList.modify", resource ) when {context.project.ipAccessList.contains(ip("0.0.0.0/0"))}; EOF }, ] } resource "mongodbatlas_resource_policy" "restrict_cluster_size: { org_id = var.org_id name = "restrict-cluster-size" policies = [ { // restrict cluster size to a minimum of M30 and a maximum of M60 body = <<EOF forbid ( principal, action == ResourcePolicy::Action::"cluster.modify", resource ) when { (context.cluster has minGeneralClassInstanceSizeValue && context.cluster.minGeneralClassInstanceSizeValue < 30) || (context.cluster has maxGeneralClassInstanceSizeValue && context.cluster.maxGeneralClassInstanceSize > 60) }; EOF }, ] } resource "mongodbatlas_resource_policy" "prevent-modifications-private-endpoints" { org_id = var.org_id name = "prevent-modifications-private-endpoints" policies = [ { body = <<EOF forbid ( principal, action == ResourcePolicy::Action::"privateEndpoint.modify", resource ) when {context.project.privateEndpoints == [ \"aws:<VPC_ENDPOINT_ID>", \"azure:<PRIVATE_ENDPOINT_RESOURCE_ID>:<PRIVATE_ENDPOINT_IP_ADDRESS>", \"gcp:<GCP_PROJECT_ID>:<VPC_NAME>" ]}; EOF }, ] }
暗号化
暗号化を実装することで、データ処理のすべての段階にわたってデータのセキュリティを強化できます。暗号化は、業界セキュリティ標準へのコンプライアンスを確保するための最も一般的な要件の 1 つであり、Atlas は要件を満たすための堅牢な暗号化オプションのセットを提供します。
デフォルトで、Atlas は転送中データを暗号化する。Atlas では、データベースへの接続を暗号化するために TLS/SSL が必要です。
デフォルトでは、Atlas はクラウドプロバイダーのディスク暗号化を使用して保管中のすべてのデータを暗号化します。Atlasクラウドバックアップを使用する場合、Atlas は AES-256 暗号化を使用して、Atlas クラスター内の S バケットに保存されているすべてのデータを暗号化します。3さらに、Atlas は、Amazon Web Services KMS、AKV、GCPを使用して、ストレージエンジンとクラウドプロバイダーのバックアップを暗号化するのをサポートしています。詳しくは、キー管理を使用した保管時の暗号化 を参照してください。
Queryable Encryption を使用して、 MongoDBに保存されているドキュメント内の機密フィールドの選択されたセットに対する暗号化されたデータに対するクエリを保護できます。Queryable Encryptionを使用すると、ユーザーがデータに対してクエリを実行しても、機密情報は保護されたままになります。
よく検索された非決定的な暗号化スキームを使用して、セキュリティと機能のバランスを維持します。
Queryable Encryptionを使用すると、次のタスクを実行できます。
クライアント側からの機密データフィールドの暗号化。
Atlas で実行されるデータベースクラスター側に、機密データフィールドを完全にランダム化され暗号化されたデータとして保存します。
暗号化されたデータに対する表現クエリの実行。
MongoDB は、処理しているデータをサーバーに知られることなく、これらのタスクを完了します。
Queryable Encryptionを使用すると、機密データは、転送中、保存中、使用中、ログ、バックアップなどのライフサイクル全体にわたって暗号化されます。暗号化のキーにアクセスできるのはユーザーだけであるため、データはクライアント側でのみ復号化されます。
次のメカニズムを使用して、Queryable Encryption を設定できます。
自動暗号化を使用すると、フィールドを暗号化および復号化するための明示的な呼び出しを追加することなく、暗号化された読み取りおよび書込み操作を実行できます。クライアントアプリケーションの作成プロセスが効率化されるため、ほとんどの状況において自動暗号化を推奨します。自動暗号化を使用すると、 MongoDB は読み取りおよび書込み (write) 操作においてフィールドを自動的に暗号化および復号化します。
明示的な暗号化を使用すると、 MongoDBドライバーの暗号化ライブラリを使用して暗号化された読み取りおよび書込み操作を実行できます。アプリケーション全体でこのライブラリを使用して暗号化のロジックを指定する必要があります。明示的な暗号化により、セキュリティをきめ細やかに制御できますが、コレクションの構成やMongoDBドライバー のコード記述の複雑さは増しコスト。明示的な暗号化では、データベースで実行する各操作に対してドキュメント内のフィールドを暗号化する方法を指定し、このロジックをアプリケーション全体に含めます。
詳細については、「明示的な暗号化の使用」を参照してください。
データのリージョン化
Atlas はAWS、 Azure、 GCPなどの 110 以上のリージョンをサポートしています。このサポートされているロケーションのグローバルな分散により、データローカライズ要件に準拠したクラスターをプロビジョニングし、データを保存できます。また、Atlas クラスターを複数のリージョンに配置することもできます。マルチリージョン配置パラダイムを配置すると、データを分割して異なるリージョンに存在できます。各リージョンは異なる地理的リージョンにあります。例、ヨーロッパではヨーロッパのカスタマーデータを保存し、米国では米国のカスタマーデータを保存できます。これにより、データ ローカライズの選択が柔軟になり、それぞれのリージョンからデータにアクセスするユーザーのレイテンシが軽減されます。
バックアップ スナップショットの分散
バックアップスナップショットとoplogデータを複数のリージョンに分散できます。例、では、リージョン停止時が発生した場合に障害復旧を有効にしたり、データローカライズの選択と一貫してバックアップを維持したりするために、異なる地理的ロケーションにある保存のバックアップを満たすことができます。詳細については、「スナップショット分散」を参照してください。
バックアップ コンプライアンス ポリシー
Atlas のバックアップ コンプライアンス ポリシーを使用して、ビジネス重要なデータを保護できます。この機能により、Atlas ロールに関係なく、ユーザーによる事前定義された保持期間中に、Atlas に保存されているすべてのバックアップ スナップショットとoplogデータが変更または削除されるのを防止します。
これにより、バックアップが完全に WORM(WriteMany)に完全に準拠していることを保証することができます。MongoDBサポートによる検証プロセスが完了した後に、この保護をオフにすることができます。これにより、必須の手動遅延とクールダウン期間が追加されるため、攻撃者はバックアップポリシーを簡単に変更してデータをエクスポートできません。詳細については、バックアップ コンプライアンス ポリシーの構成を参照してください。