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

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

認証と規制へのコンプライアンス

セキュリティ、コンプライアンス、プライバシーの要件に対処するために、 MongoDB Atlas は最高レベルの標準コンプライアンスと規制コンプライアンスを提供することを目的としています。

Atlas データプラットフォームは、セキュリティ、プライバシー、組織制御を検証するために、厳格な独立したサードパーティ監査を行います。これらの監査は、プラットフォームがコンプライアンスと規制要件（高度に規制されたセカンダリに固有の要件を含む）を満たしていることを確認するのに役立ちます。

Atlas は、ISO/IEC27001 、SOC2 Type II、PCI DSS など、当社の Atlas トラストセンターにリストされているコンプライアンスフレームワークに準拠しています。認証、コンプライアンスレポート、およびその他のコンプライアンスドキュメントは、カスタマートラストポータルで表示およびダウンロードできます。

MongoDB Atlas for Government

MongoDB Atlas for Government は、FedRAMP: モードで認可された最初のフルマネージドマルチクラウド開発者向けデータプラットフォームです。

安全でフルマネージドの専用 FedRAMP() 認可環境を使用します。
米国政府の固有の要件と目的をサポートします。
レガシーアプリケーションの最新化に必要な機能セットとスケーラビリティを提供します。

Atlas リソースポリシー

コンプライアンス要件をサポートするために、 Atlas リソースポリシーは、セキュリティ、コンプライアンス、運用のベストプラクティスに合わせて Atlas リソースの構成と管理を行うための組織全体のコントロールを提供します。組織の所有者は、クラスター、ネットワーク構成、プロジェクト設定などのリソースを作成または変更する際に、ユーザーアクションを制御するルールを定義できます。組織の作成時に、会社の標準に従ってリソースポリシーを設定することをお勧めします。

Atlas リソースポリシーは、次のことを可能にすることでコンプライアンス目的をサポートします。

最小 TLS バージョンを強制する: すべての Atlas 配置で最新の TLS プロトコルの使用を許可することで、セキュリティを強化し、古いバージョンに関連するリスクを軽減します。これにより、転送されるすべてのデータに対して最新の暗号化標準に準拠していることが保証されます。
デフォルトの TLS 暗号をカスタマイズ: 許可された TLS 暗号の特定のセットを選択して、運用ニーズに基づいてセキュリティを最適化すると同時に、レガシー暗号化メソッドに関連する脆弱性を排除します。これにより、特定のコンプライアンス要件を満たすために暗号化プロトコルを微調整できます。
VPCピアリングの変更を制限する: 構成の変更を防ぎ、確立されたVPCピアリング接続を通じて安全なクロスネットワーク通信を有効にします。現在のプロジェクトレベルのピアリングは、既存のルーティングテーブルとセキュリティプロトコルではアクティブのままであるため、カスタマーはこれらの 1 対 1 の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 クラスター内の S3 バケットに保存されているすべてのデータを暗号化します。さらに、Atlas は、 AWS KMS 、 AKV 、 GCPを使用したストレージエンジンの暗号化とクラウドプロバイダーのバックアップをサポートしています。詳しくは、「キー管理を使用した保管時の暗号化」を参照してください。
Queryable Encryption を使用して、MongoDB に保存されたドキュメント内の特定の機密性の高いフィールドの暗号化されたデータに対するクエリを保護できます。Queryable Encryption を使用することで、ユーザーがデータに対してクエリを実行しても、機密情報は保護されたままになります。
よく検索された非決定的な暗号化スキームを使用して、セキュリティと機能のバランスを維持します。
Queryable Encryptionを使用すると、次のタスクを実行できます。
- クライアント側からの機密データフィールドの暗号化。
- Atlas で実行されるデータベースクラスター側に、機密データフィールドを完全にランダム化され暗号化されたデータとして保存します。
- 暗号化されたデータに対する表現クエリの実行。
MongoDB は、処理しているデータをサーバーに知られることなく、これらのタスクを完了します。
Queryable Encryptionを使用すると、機密データは、転送中、保存中、使用中、ログ、バックアップなどのライフサイクル全体にわたって暗号化されます。暗号化のキーにアクセスできるのはユーザーだけであるため、データはクライアント側でのみ復号化されます。
次のメカニズムを使用して、Queryable Encryption を設定できます。
- 自動暗号化を使用すると、フィールドを暗号化および復号化するための明示的な呼び出しを追加することなく、暗号化された読み取りおよび書込み操作を実行できます。クライアントアプリケーションの作成プロセスが効率化されるため、ほとんどの状況において自動暗号化を推奨します。自動暗号化を使用すると、 MongoDB は読み取りおよび書込み (write) 操作においてフィールドを自動的に暗号化および復号化します。
- 明示的な暗号化を使用すると、 MongoDBドライバーの暗号化ライブラリを使用して暗号化された読み取りおよび書込み操作を実行できます。アプリケーション全体でこのライブラリを使用して暗号化のロジックを指定する必要があります。明示的な暗号化により、セキュリティをきめ細やかに制御できますが、コレクションの構成やMongoDBドライバーのコード記述の複雑さは増しコスト。明示的な暗号化では、データベースで実行する各操作に対してドキュメント内のフィールドを暗号化する方法を指定し、このロジックをアプリケーション全体に含めます。
  詳細については、「明示的な暗号化の使用」を参照してください。

Data Sovereignty

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

Atlas クラスターを複数のリージョンに配置することで、データ所有権コンプライアンスを簡素化できます。マルチリージョン配置パラダイムを配置すると、データを分割して異なるリージョンに存在できます。各リージョンは異なる地理的リージョンにあります。例、ヨーロッパのカスタマーデータをヨーロッパに保存し、米国のカスタマーデータを米国に保存できるため、データ所有権規則に準拠し、それぞれのリージョンからデータにアクセスするユーザーのレイテンシを軽減できます。

バックアップスナップショットの分散

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

バックアップコンプライアンスポリシー

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

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

戻る

データの暗号化

監査およびログ記録

認証と規制へのコンプライアンス

MongoDB Atlas for Government

Atlas リソース ポリシー

暗号化

Data Sovereignty

バックアップ スナップショットの分散

バックアップ コンプライアンス ポリシー

Atlas リソースポリシー

バックアップスナップショットの分散

バックアップコンプライアンスポリシー