Docs Menu
Docs Home
/ /
Atlas Architecture Center
/

Atlas のデータ暗号化に関するガイダンス

項目一覧

  • Atlas のデータ暗号化に関する機能
  • 転送中の暗号化
  • 保管時の暗号化
  • 使用中の暗号化
  • Atlas のデータ暗号化に関する推奨事項
  • カスタマー キー管理による暗号化
  • データ分類
  • オートメーションの例: Atlas のデータ暗号化
  • カスタマー キー管理による暗号化の設定

Atlas は、転送中、保存中、使用中にデータを保護するためのいくつかの暗号化機能を提供しており、データのライフサイクル全体にわたって保護します。

転送中の暗号化により、クライアントとサーバー間の転送中にデータが保護され、移動中にデータを検査できないようになります。Atlas では、クラスターへのすべてのネットワーク トラフィックは、トランスポート層セキュリティ (TLS) によって保護されています。TLS はデフォルトで有効になっており、無効にすることはできません。ノードとの間で送信されるデータは、TLS を使用して転送中に暗号化され、通信全体で安全な通信が確保されます。

Atlas で使用する TLS バージョンを選択できます。TLS 1.2 と 128 ビットの最小鍵長が推奨されるデフォルト設定です。転送中のすべての暗号化は OpenSSL FIPS オブジェクト モジュールによってサポートされています。

クライアントアプリケーションとMongoDB Atlas間で TLS を使用して転送中の暗号化を示す画像。
クリックして拡大します

保管時の暗号化により、ディスク上のすべてのデータが暗号化され、認可されたプロセスまたはアプリケーションによって復号化された場合にのみ表示されます。Atlas では、カスタマーデータは AES-256 を使用して保管時に自動的に暗号化されます。このプロセスでは、クラウドプロバイダーの ディスク暗号化を利用し、プロバイダーが暗号化キーを管理します。このプロセスは無効にできません。

デフォルトでは、保管時の暗号化はボリュームレベルの暗号化です。

さらに、 Amazon Web Services KMS、 Google Cloud Platform KMS、 Azure Key Vault などの KMS(KMS)を使用して、独自のカスタマー マネージド キー(CMK)を起動することで、データベースレベルの暗号化を有効にすることができます。 この機能はファイルレベルの暗号化を提供し、エンタープライズ TDE 要件を満たしている TDE(Transparent Data Encryption)と同等であり、カスタマーキー管理による暗号化により、機密性とデータのセグメンテーションのためのレイヤーがさらに強化されます。

詳しくは、「 カスタマー キー マネジメントを使用した保管時の暗号化 」を参照してください。

カスタマーが管理する追加のキーを使用した保管時の暗号化の画像。
クリックして拡大します

使用中の暗号化は、データが処理されている間のデータを保護します。MongoDB には、データ保護のニーズを満たすために使用される使用中の暗号化機能が 2 つあります。それは、クライアント側のフィールド レベル暗号化と Queryable Encryption です。

クライアント側フィールドレベル暗号化(CSFLE)は、 MongoDBデータベースに保存する前にクライアントアプリケーションが機密データを暗号化できるようにする使用中の暗号化機能です。機密データは透過的に暗号化され、ライフサイクル全体で暗号化され続け、クライアント側でのみ復号化されます。

ドキュメント内の個々のフィールド、ドキュメント内の複数のフィールド、またはドキュメント全体を選択的に暗号化することができます。必要に応じて各フィールドを独自のキーで保護し、MongoDB ドライバーを使用してクライアント上でシームレスに復号化することができます。CSFLE は認証付き CBC モードで AES-256 を使用してデータを暗号化します。

さらに、ランダム化された暗号化を選択することもできます。これはクエリ可能ではありませんが、特定のセキュリティ要件には必要になる場合があります。

次の図は、ユーザー レコードがMongoDBデータベースに保存され、クライアントによってクエリされる CSFLE ワークフローを示しています。ユーザーのソーシャル セキュリティ 番号(SSN)は、データベースに保存される前に暗号化されます。アプリケーションがフィールドに基本的な等価クエリを送信すると、 MongoDBドライバーは キーを使用してクライアント側でクエリを暗号化し、暗号化されたクエリをサーバーに送信します。サーバーは暗号化された結果をクライアントに返します。クライアントは、その結果を復号化してから、読み取り可能なプレーンテキストとして認証されたクライアントに返します。

CSFLE は、すべての主要なクラウドとオンプレミスのキー管理サービスをサポートしています。

クライアントサイドのフィールドレベル暗号化(CSFLE)ワークフローの例を示す画像。
クリックして拡大します

Queryable Encryption は、機密データに対してクエリを実行された際に、組織が機密データを保護するのに役立ちます。CSFLE のように、MongoDB データベースに保存する前に、アプリケーションがクライアント側でデータを暗号化できます。また、暗号化された検索アルゴリズムを使用することにより、アプリケーションは暗号化されたデータに対して直接、等価クエリなどの表現力豊かなクエリを実行することができます。Queryable Encryption は、クエリを実行する能力を犠牲にすることなく、機密情報を確実に保護します。Queryable Encryption は常に非決定論的暗号化を使用します。

Queryable Encryptionで使用されるアルゴリズムについて詳しくは、Queryable Encryption のホワイトペーパーを参照してください。

次の図は、ユーザー レコードが MongoDB データベースに保存され、クライアントによってクエリされる Queryable Encryption ワークフローを示しています。ユーザーの生年月日は、データベースに保存される前に暗号化されます。アプリケーションがフィールドに対して表現力豊かな範囲指定クエリを送信すると、MongoDB ドライバーはキーを使用してクエリを暗号化し、暗号トークンを MongoDB サーバーに渡します。サーバーは暗号化された検索アルゴリズムを使用して、実際のデータを知ることなくクエリを処理します。最後に、ドライバーはキーを使用してクエリ結果を復号し、判読できるプレーンテキストとして認証済みのクライアントに返します。

Queryable Encryption ワークフローの例を示す画像。
クリックして拡大します

クラスターをプロビジョニング際には、次のセキュリティ推奨事項を考慮してください。

プロジェクトレベルでカスタマーキー管理を使用して暗号化を有効にします。この設定を有効にすると、プロジェクト内で作成されたすべてのクラスターに設定が自動的に適用されるため、環境全体で一貫したデータ保護が確保されます。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などの最高レベルのセキュリティ制御を適用し、セキュリティを強化するためにカスタマーキー管理を使用した暗号化を適用します。

    例: 収益情報、給与、セキュリティリスク

Github のすべての柱にわたるステージングおよび本番環境における推奨事項を実行するための Terraform の例を参照してください。

次の例では、オートメーション用の Atlas ツール を使用して、カスタマーキー管理による暗号化を構成します。

カスタマーキー管理で暗号化を設定する前に、組織、プロジェクト、クラスターを作成する必要があります。詳細については、「オートメーションの例: 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
}
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\": \"[email protected]\",\"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 のドキュメント を参照してください。

戻る

認可と認証