Atlas は、転送中、保存中、使用中にデータを保護するためのいくつかの暗号化機能を提供しており、データのライフサイクル全体にわたって保護します。
Atlas のデータ暗号化に関する機能
転送中の暗号化
転送中の暗号化により、クライアントとサーバー間の転送中にデータが保護され、移動中にデータを検査できないようになります。Atlas では、クラスターへのすべてのネットワーク トラフィックは、トランスポート層セキュリティ (TLS) によって保護されています。TLS はデフォルトで有効になっており、無効にすることはできません。ノードとの間で送信されるデータは、TLS を使用して転送中に暗号化され、通信全体で安全な通信が確保されます。
Atlas で使用する TLS バージョンを選択できます。TLS 1.2 と 128 ビットの最小鍵長が推奨されるデフォルト設定です。転送中のすべての暗号化は OpenSSL FIPS オブジェクト モジュールによってサポートされています。
保管時の暗号化
保管時の暗号化は、ディスク上のすべてのデータが暗号化され、許可されたプロセスまたはアプリケーションによって復号化された場合にのみ表示されることを保証します。
Atlas では、カスタマーデータは保存時に AES-256 を使用して自動的に暗号化されます。このプロセスでは、クラウドプロバイダーのディスク暗号化を利用し、プロバイダーが暗号化のキーを管理します。このプロセスを無効にすることはできません。
デフォルトでは、保管時の暗号化はボリュームレベルの暗号化です。
さらに、独自のキー(BYOK)を持ち込むことで、データベースレベルの暗号化を有効にすることができます。これは、AWS KMS、Google Cloud KMS、Azure Key Vault などのキー管理サービス(KMS)を使用して追加するカスタマー管理キー(CMK)です。BYEK 機能はファイルレベルの暗号化を提供し、エンタープライズ TDE 要件を満たしている TDE(Transparent Data Encryption)と同等であり、カスタマーキー マネジメントを使用した暗号化は、機密性とデータセグメンテーションを追加するためのセキュリティ層を提供します。
詳しくは、「 カスタマー キー マネジメントを使用した保管時の暗号化 」を参照してください。
使用中の暗号化
使用中の暗号化は、データが処理されている間のデータを保護します。MongoDB には、データ保護のニーズを満たすために使用される使用中の暗号化機能が 2 つあります。それは、クライアント側のフィールド レベル暗号化と Queryable Encryption です。
クライアントサイドのフィールド レベル暗号化
クライアント側フィールドレベル暗号化(CSFLE)は、 MongoDBデータベースに保存する前にクライアントアプリケーションが機密データを暗号化できるようにする使用中の暗号化機能です。機密データは透過的に暗号化され、ライフサイクル全体で暗号化され続け、クライアント側でのみ復号化されます。
ドキュメント内の個々のフィールド、ドキュメント内の複数のフィールド、またはドキュメント全体を選択的に暗号化することができます。必要に応じて各フィールドを独自のキーで保護し、MongoDB ドライバーを使用してクライアント上でシームレスに復号化することができます。CSFLE は認証付き CBC モードで AES-256 を使用してデータを暗号化します。
さらに、ランダム化された暗号化を選択することもできます。これはクエリ可能ではありませんが、特定のセキュリティ要件には必要になる場合があります。
次の図は、ユーザー レコードがMongoDBデータベースに保存され、クライアントによってクエリされる CSFLE ワークフローを示しています。ユーザーのソーシャル セキュリティ 番号(SSN)は、データベースに保存される前に暗号化されます。アプリケーションがフィールドに基本的な等価クエリを送信すると、 MongoDBドライバーは キーを使用してクライアント側でクエリを暗号化し、暗号化されたクエリをサーバーに送信します。サーバーは暗号化された結果をクライアントに返します。クライアントは、その結果を復号化してから、読み取り可能なプレーンテキストとして認証されたクライアントに返します。
CSFLE は、すべての主要なクラウドとオンプレミスのキー管理サービスをサポートしています。
Queryable Encryption
Queryable Encryption は、機密データに対してクエリを実行された際に、組織が機密データを保護するのに役立ちます。CSFLE のように、MongoDB データベースに保存する前に、アプリケーションがクライアント側でデータを暗号化できます。また、暗号化された検索アルゴリズムを使用することにより、アプリケーションは暗号化されたデータに対して直接、等価クエリなどの表現力豊かなクエリを実行することができます。Queryable Encryption は、クエリを実行する能力を犠牲にすることなく、機密情報を確実に保護します。Queryable Encryption は常に非決定論的暗号化を使用します。
Queryable Encryptionで使用されるアルゴリズムについて詳しくは、Queryable Encryption のホワイトペーパーを参照してください。
次の図は、ユーザー レコードが MongoDB データベースに保存され、クライアントによってクエリされる Queryable Encryption ワークフローを示しています。ユーザーの生年月日は、データベースに保存される前に暗号化されます。アプリケーションがフィールドに対して表現力豊かな範囲指定クエリを送信すると、MongoDB ドライバーはキーを使用してクエリを暗号化し、暗号トークンを MongoDB サーバーに渡します。サーバーは暗号化された検索アルゴリズムを使用して、実際のデータを知ることなくクエリを処理します。最後に、ドライバーはキーを使用してクエリ結果を復号し、判読できるプレーンテキストとして認証済みのクライアントに返します。
Atlas のデータ暗号化に関する推奨事項
単一リージョンの配置には、データ暗号化に関する特別な考慮事項はありません。" すべての配置パラダイムの推奨事項 " については、次のセクションを参照してください。
マルチリージョンおよびマルチクラウド配置では、独自のカスタマーマネージドキー(BYOK)を使用することで、データベースレベルの暗号化を有効にできます。
一部の KMS プロバイダーはマルチリージョン機能をサポートしています。以下に例を挙げます。
GCP KMS はマルチリージョン配置と自動キーレプリケーションをサポートしています。
Amazon Web Services KMS では、キーを明示的にマルチリージョン設定し、Atlas が配置されているすべてのリージョンに複製する必要があります。 詳細については、 Amazon Web Servicesでのマルチリージョンレプリカキーの作成 を参照してください。
ただし、設定されたKMSエンドポイントに影響を与えるリージョンの停止時が発生した場合、AtlasとKMSプロバイダーの統合は、リージョン間のKMSへの接続またはアクセスメカニズムの自動フェイルオーバーを提供しません。
構成された KMS プロバイダーが利用できなくなった場合、Atlas は KMS 構成の定期的な検証を実行します。KMS プロバイダーの認証情報が無効になったり、暗号化のキーが削除または無効化された場合、Atlas は次回のスケジュールされた検証チェックでmongod
およびmongos
プロセスをシャットダウンし、Atlas UIのステータスを反映してメールで通知いたします。
Atlasはキー管理プロバイダーに接続できない場合でも、プロセスをシャットダウンしません。したがって、地域の問題で KMS へのアクセスが中断された場合、クラスターは手動で再起動するか、検証がより重大な失敗をするまで実行を続ける可能性があります。
このため、KMS がダウンした場合には、構成を変更することができます。マルチリージョン停止時シナリオで暗号化のキーへのアクセスを回復するには、Atlas の設定を手動で変更し、別のアクセス可能な KMS インスタンスまたは設定を点すようにする必要があります。
プライベートエンドポイントを使用して KMS に接続する場合は、Atlas ノードが配置されている各リージョンからプライマリ KMS へのプライベートエンドポイントを確立する必要があります。これは、定期的なチェック中や初期設定、キーのローテーション時に、各ノードがプライマリ KMS に保存されている CMK にアクセスする必要がある際に、設定が有効であることを確認するためです。
要約すると、Atlas と保管時の暗号化のための BYOK プロバイダーの統合は、マルチリージョンフェイルオーバーを自動的にサポートしていないため、構成を手動で変更する必要があります。
すべてのデプロイメントパラダイムに関する推奨事項
次の推奨事項は、すべての 配置パラダイムに適用されます。
カスタマー キー管理による暗号化
プロジェクトレベルでカスタマーキー管理を使用して暗号化を有効にします。この設定を有効にすると、プロジェクト内で作成されたすべてのクラスターに設定が自動的に適用されるため、環境全体で一貫したデータ保護が確保されます。Amazon Web Services KMS、 Google Cloud Platform KMS、 Azure Key Vault などの KMS(KMS)を使用することをお勧めします。
ステージング環境と本番環境 では、クラスターをプロビジョニングするときにカスタマーキー管理で暗号化を有効にすることをお勧めします。これにより、アプリケーション開発チームが後で暗号化を構成できるようにします。
開発環境およびテスト環境 では、コストを節約するためにカスタマーキー管理で暗号化をスキップすることを検討してください。ただし、医療サービスや金融サービスプロバイダーなど、機密データを Atlas に保存する場合は、開発環境やテスト環境でもカスタマーキー管理を使用した暗号化を有効にすることを検討してください。
カスタマー キー管理による暗号化を有効にするには、次の方法を使用します。
新しい Atlas 組織、プロジェクト、クラスターをプロビジョニングする際に、カスタマーキー管理を使用して暗号化を設定する方法については、「オートメーションの例:Atlas 組織、プロジェクト、クラスター」を参照してください。
データ分類
プロビジョニングプロセス中に、データ内の特定のフィールドの機密性を評価し、それらを分類して、どのデータが暗号化れているか、またこれらのグループに適用するグローバル制限を決定することをお勧めします。一般的なガイドラインとして、データ モデリングのベストプラクティスに従うことに加えて、すべての機密フィールドにQueryable Encryptionを適用することをお勧めします。
次のデータ分類レベルを 開始点として検討します。
公開データ : データの不正公開、変更、または破棄が発生した場合に、会社にほとんどのリスクがほとんどまたはまったくないデータ。機密性は問題がありませんが、公開データの不正変更や破棄を防ぐために、認可制御を適用する必要があります。
例: 製品、カタログ、トレーニング情報
プライベート データ: データの不正な開示、改ざん、または破壊が発生した場合、会社にとって中程度のリスクをもたらすデータ。デフォルトでは、明示的に制限データまたは公開データとして分類されていない機関データは、すべてプライベート データとして扱われるべきです。PII など個人データを含むフィールドには、CSFLE または Queryable Encryption を適用します。
例: 顧客情報、契約、製品コスト
制限付きデータ : データの不正公開、変更、または破棄が発生した場合、会社に重大なリスクを与えるデータ。制限されたデータには、すべてのフィールドに CSFLE またはQueryable Encryptionなどの最高レベルのセキュリティ制御を適用し、セキュリティを強化するためにカスタマーキー管理を使用した暗号化を適用します。
例: 収益情報、給与、セキュリティリスク
オートメーションの例: Atlas のデータ暗号化
Tip
すべてのピリオドにわたって推奨事項を強制する Terraform の例については、 Githubの次のいずれかの例を参照してください。
次の例では、オートメーション用の Atlas ツール を使用して、カスタマーキー管理による暗号化を構成します。
カスタマーキー管理で暗号化を設定する前に、組織、プロジェクト、クラスターを作成する必要があります。詳細については、「オートメーションの例: Atlas の組織、プロジェクト、クラスター」を参照してください。
カスタマー キー管理による暗号化の設定
規制の厳しい業界や機密データを保存している場合を除き、開発およびテスト環境では、コストを節約するためにカスタマー鍵管理による暗号化をスキップすることを検討してください。詳細については、「Atlas の組織、プロジェクト、クラスターに関する推奨事項」をご覧ください。
Terraform を使用してカスタマー キー管理による暗号化を有効にするには、次のリソースを作成します。ID と名前を変更して、自分の値を使用します。
Tip
完全な 構成例については、Atlas Terraform プロバイダーの例 を参照してください。
あるいは、構成プロセスを簡素化するために、保管時の暗号化Terraform モジュールを使用することもできます。
resource "mongodbatlas_cloud_provider_access_setup" "setup_only" { project_id = var.atlas_project_id provider_name = "AWS" } resource "mongodbatlas_cloud_provider_access_authorization" "auth_role" { project_id = var.atlas_project_id role_id = mongodbatlas_cloud_provider_access_setup.setup_only.role_id aws { iam_assumed_role_arn = aws_iam_role.test_role.arn } } resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id aws_kms_config { enabled = true customer_master_key_id = aws_kms_key.kms_key.id region = var.atlas_region role_id = mongodbatlas_cloud_provider_access_authorization.auth_role.role_id } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_aws_kms_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.aws_kms_config.valid }
Tip
完全な 構成例については、Atlas Terraform プロバイダーの例 を参照してください。
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id azure_key_vault_config { enabled = true azure_environment = "AZURE" tenant_id = var.azure_tenant_id subscription_id = var.azure_subscription_id client_id = var.azure_client_id secret = var.azure_client_secret resource_group_name = var.azure_resource_group_name key_vault_name = var.azure_key_vault_name key_identifier = var.azure_key_identifier } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_azure_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.azure_key_vault_config.valid }
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id google_cloud_kms_config { enabled = true service_account_key = "{\"type\": \"service_account\",\"project_id\": \"my-project-common-0\",\"private_key_id\": \"e120598ea4f88249469fcdd75a9a785c1bb3\",\"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEuwIBA(truncated)SfecnS0mT94D9\\n-----END PRIVATE KEY-----\\n\",\"client_email\": \"my-email-kms-0@my-project-common-0.iam.gserviceaccount.com\",\"client_id\": \"10180967717292066\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-email-kms-0%40my-project-common-0.iam.gserviceaccount.com\"}" key_version_resource_id = "projects/my-project-common-0/locations/us-east4/keyRings/my-key-ring-0/cryptoKeys/my-key-0/cryptoKeyVersions/1" } }
詳細の構成オプションとこの例に関する情報については、Terraform のドキュメント を参照してください。
ステージング環境と本番環境では、クラスターをプロビジョニングする際に、カスタマー キー管理による暗号化を有効にすることを推奨します。詳細については、「Atlas の組織、プロジェクト、クラスターに関する推奨事項」をご覧ください。
Terraform を使用してカスタマー キー管理による暗号化を有効にするには、次のリソースを作成します。ID と名前を変更して、自分の値を使用します。
Tip
完全な 構成例については、Atlas Terraform プロバイダーの例 を参照してください。
あるいは、構成プロセスを簡素化するために、保管時の暗号化Terraform モジュールを使用することもできます。
resource "mongodbatlas_cloud_provider_access_setup" "setup_only" { project_id = var.atlas_project_id provider_name = "AWS" } resource "mongodbatlas_cloud_provider_access_authorization" "auth_role" { project_id = var.atlas_project_id role_id = mongodbatlas_cloud_provider_access_setup.setup_only.role_id aws { iam_assumed_role_arn = aws_iam_role.test_role.arn } } resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id aws_kms_config { enabled = true customer_master_key_id = aws_kms_key.kms_key.id region = var.atlas_region role_id = mongodbatlas_cloud_provider_access_authorization.auth_role.role_id } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_aws_kms_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.aws_kms_config.valid }
Tip
完全な 構成例については、Atlas Terraform プロバイダーの例 を参照してください。
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id azure_key_vault_config { enabled = true azure_environment = "AZURE" tenant_id = var.azure_tenant_id subscription_id = var.azure_subscription_id client_id = var.azure_client_id secret = var.azure_client_secret resource_group_name = var.azure_resource_group_name key_vault_name = var.azure_key_vault_name key_identifier = var.azure_key_identifier } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_azure_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.azure_key_vault_config.valid }
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id google_cloud_kms_config { enabled = true service_account_key = "{\"type\": \"service_account\",\"project_id\": \"my-project-common-0\",\"private_key_id\": \"e120598ea4f88249469fcdd75a9a785c1bb3\",\"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEuwIBA(truncated)SfecnS0mT94D9\\n-----END PRIVATE KEY-----\\n\",\"client_email\": \"my-email-kms-0@my-project-common-0.iam.gserviceaccount.com\",\"client_id\": \"10180967717292066\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-email-kms-0%40my-project-common-0.iam.gserviceaccount.com\"}" key_version_resource_id = "projects/my-project-common-0/locations/us-east4/keyRings/my-key-ring-0/cryptoKeys/my-key-0/cryptoKeyVersions/1" } }
詳細の構成オプションとこの例に関する情報については、Terraform のドキュメント を参照してください。