Docs Menu
Docs Home
/ /

外部標準とのコンプライアンスのための機能

次の Atlas 機能を使用して、コンプライアンス要件に対処します。

セキュリティ、コンプライアンス、プライバシーの要件に対応するため、MongoDB Atlas は、最高水準の基準適合性と規制上のコンプライアンスを提供することを目指しています。

Atlas データプラットフォームは、セキュリティ、プライバシー、組織的統制を検証するために、独立した第三者機関による厳格な監査を受けています。これらの監査は、規制の厳しい業界特有の要件も含め、プラットフォームがコンプライアンスや規制要件を満たしていることを確認するのに役立ちます。

Atlas は、ISO/IEC 27001、SOC2 Type II、PCI DSS などのコンプライアンス フレームワークを遵守しており、その他についてはAtlas 信頼センターに記載されています。Customer Trust Portalで、証明書、コンプライアンス レポート、その他のコンプライアンス関連ドキュメントを閲覧およびダウンロードできます。

MongoDB 政府向け Atlas は、FedRAMP® Moderate 認定を受けた初のフルマネージド型マルチクラウド開発者向けデータ プラットフォームです。

  • FedRAMP® 認定を受けた、安全で完全管理された専用環境を利用できます。

  • 米国政府の独自の要件と任務をサポートします。

  • レガシー アプリケーションを最新化するために必要な機能セットとスケーラビリティを提供します。

コンプライアンス要件に対応するため、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 KMSAKVGCPを使用して、ストレージエンジンとクラウドプロバイダーのバックアップを暗号化するのをサポートしています。詳しくは、キー管理を使用した保管時の暗号化 を参照してください。

  • Queryable Encryption を使用して、MongoDB に保存されたドキュメント内の特定の機密性の高いフィールドの暗号化されたデータに対するクエリを保護できます。Queryable Encryption を使用することで、ユーザーがデータに対してクエリを実行しても、機密情報は保護されたままになります。

    よく検索された非決定的な暗号化スキームを使用して、セキュリティと機能のバランスを維持します。

    Queryable Encryptionを使用すると、次のタスクを実行できます。

    • クライアント側からの機密データフィールドの暗号化。

    • Atlas で実行されるデータベースクラスター側に、機密データフィールドを完全にランダム化され暗号化されたデータとして保存します。

    • 暗号化されたデータに対する表現クエリの実行。

    MongoDB は、処理しているデータをサーバーに知られることなく、これらのタスクを完了します。

    Queryable Encryptionを使用すると、機密データは、転送中、保存中、使用中、ログ、バックアップなどのライフサイクル全体にわたって暗号化されます。暗号化のキーにアクセスできるのはユーザーだけであるため、データはクライアント側でのみ復号化されます。

    次のメカニズムを使用して、Queryable Encryption を設定できます。

    • 自動暗号化を使用すると、フィールドを暗号化および復号化するための明示的な呼び出しを追加することなく、暗号化された読み取りおよび書込み操作を実行できます。クライアントアプリケーションの作成プロセスが効率化されるため、ほとんどの状況において自動暗号化を推奨します。自動暗号化を使用すると、 MongoDB は読み取りおよび書込み (write) 操作においてフィールドを自動的に暗号化および復号化します。

    • 明示的な暗号化を使用すると、 MongoDBドライバーの暗号化ライブラリを使用して暗号化された読み取りおよび書込み操作を実行できます。アプリケーション全体でこのライブラリを使用して暗号化のロジックを指定する必要があります。明示的な暗号化により、セキュリティをきめ細やかに制御できますが、コレクションの構成やMongoDBドライバー のコード記述の複雑さは増しコスト。明示的な暗号化では、データベースで実行する各操作に対してドキュメント内のフィールドを暗号化する方法を指定し、このロジックをアプリケーション全体に含めます。

      詳細については、「明示的な暗号化の使用」を参照してください。

Atlas は Amazon Web ServicesAzureGCP に対して 110 以上のリージョンでサポートしています。サポートしているロケーションがグローバルに分散されていることにより、データ主権およびコンプライアンス要件に準拠してクラスターをプロビジョニングし、データを保存することができます。Atlas でビルドされるアプリケーションのデータ主権の要件を理解することは、適切なガバナンスに準拠し続けるために必要です。

Atlas クラスターを複数のリージョンに配置することで、データ主権コンプライアンスを簡素化できます。マルチリージョン配置パラダイムを採用すると、データを異なる地理的リージョンに分割して配置できます。例えば、ヨーロッパの顧客データはヨーロッパに、米国の顧客データは米国に保存できます。これにより、データ主権規制に準拠できるほか、ユーザーが各自のリージョンからデータにアクセスする際のレイテンシを低減できます。

バックアップ スナップショットと oplog データを複数のリージョンに分散できます。例えば、コンプライアンス要件を満たし、地理的に異なるロケーションにバックアップを保存することで、地域的な停止時でも確実に障害復旧することができます。詳細については、「スナップショットの分散」を参照してください。

Atlas のバックアップ コンプライアンス ポリシーを使用して、ビジネス重要なデータを保護できます。Atlas に保存されているすべてのバックアップスナップショットとoplogデータが、Atlas ロールに関係なく、ユーザーによる事前定義された保持期間中に変更または削除されるのを防ぐことができます。

これにより、バックアップが完全に WORM(Write Once Read Many)に準拠していることが保証されます。MongoDB サポートおよび法務部門による検証プロセスを完了した後、指定された承認済みユーザーのみがこの保護を解除できます。これにより、攻撃者がバックアップポリシーを変更してデータをエクスポートできないように、手動による遅延とクールダウン期間が必須となります。詳細については、「バックアップ コンプライアンス ポリシーの構成」を参照してください。

戻る

データの暗号化

項目一覧