Docs Menu
Docs Home
/
MongoDBマニュアル
/
セキュリティ
/
クライアントサイドのフィールド レベル暗号化

マスターキーとデータ暗号化キー管理

項目一覧

  • サポートされているキー管理サービス
  • 暗号化キーヴォールト

バージョン 4.2の新機能

サポートされているキー管理サービス

クライアント側のフィールド レベル暗号化では、 CMK（Customer Master Key）にアクセスするためにKMS （ KMS ）が必要です。 MongoDB は、 データ暗号化キーの作成中に、指定された CMK を使用してデータ暗号化キーを自動的に暗号化します。

CMK を削除すると、その CMK で暗号化されたすべてのデータ暗号化キーが永続的に読み取りできなくなります。そのため、それらのデータ暗号化キーで暗号化されたすべての値が永続的に読み取りできなくなります。

クライアント側のフィールドレベル暗号化は、次の KMS プロバイダーをサポートしています。

  • Amazon Web Services KMS

  • Azure Key Vault

  • Google Cloud Platform KMS

  • ローカルで管理されるキー

Amazon Web Services KMS

重要: Amazon Web ServicesKMSmongoshMongoDB4.2.2Amazon Web Servicesmongoshell KMS をサポートするには、 {4 またはMongoDB 以降のレガシー シェル を使用します。の 4 。 2 。 0と 4 。 2 。 1レガシー シェルは、 mongoshellAmazon Web ServicesKMSKMS 応答オブジェクトの予期しない変更により、 Amazon Web Services KMS サービスをサポートしていません。KMS詳細については、 SERVER-44721 を参照してください。

MongoDBクライアント側暗号化は、 を使用することをサポートしますAmazon Web ServicesKMS データ暗号化キーを暗号化および復号化するため。具体的には、 MongoDBは、指定された CMK（Customer Master Key）を使用して暗号化または復号化するために、データ暗号化キーをAmazon Web Services KMSに安全に送信します。 CMK はAmazon Web Services KMSを離れることはありません。

mongosh は、 Amazon Web Services KMSへのアクセスを構成する方法の 2 つをサポートしています。

Amazon Web Services KMSへのアクセスを設定するには、少なくともAmazon Web Servicesアクセス キーとそれに対応する秘密キーが必要です。 アクセス キーに関連付けられた IAM ユーザーは、次のアクションを持つ少なくとも 1 つのポリシーを持っている必要があります。

注意

KMS アクセスの最小特権の原則を実装

MongoDB が機能するために必要なアクションとリソースのみにアクセスできるように IAM ユーザー ロール を設定することを検討してください。

たとえば、次のポリシー JSON は、必要なアクションを単一の CMK にスコープ設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:Encrypt"
            ],
            "Resource": "arn:aws:kms:region:account:key/12a345b6-cd7e-8f9g-0h1i-jk23l45mn6o7"
        }
    ]
}

Amazon Web Services KMSを使用したデータ暗号化キーの管理に関する詳細なドキュメントについては、「データ暗号化キーの管理 」を参照し、[ Amazon Web Services KMS ] タブを選択します。

Azure Key Vault

MongoDBAzure Key VaultKMSは、 を使用したクライアント側の暗号化をサポートしています。 データ暗号化キーを暗号化および復号化するため。具体的には、MongoDB は、指定された CMK（Customer Master Key）を使用して暗号化または復号化するために、データ暗号化キーを Azure Key Vault に安全に送信します。 CMK は Azure Key Vault から離れることはありません。

mongoshは、 KMS 構成オプション を使用する コンストラクターを使用して Azure Key Vault を KMS として指定することをサポートしています。Mongo()

Azure Key Vault へのアクセスを構成するには、少なくとも Azure テナント ID、クライアント ID、クライアント シークレットが必要です。 テナント ID には、次のアクションを実行する機能が必要です。

注意

MongoDB は Azure のクライアント証明書認証（TLS 相互認証とも呼ばれます）をサポートしていません。

Azure Key Vault を使用したデータ暗号化のキー管理に関する詳細なドキュメントについては、「データ暗号化キーの管理 」を参照し、[ Azure Key Vault ] タブを選択します。

Google Cloud Platform KMS

MongoDBクライアント側の暗号化は を使用したものをサポートしていますGCPKMS データ暗号化キーを暗号化および復号化するため。具体的には、 MongoDBは、指定された CMK（Customer Master Key）を使用して暗号化または復号化するために、データ暗号化キーをGCP KMSに安全に送信します。 CMK はGoogle Cloud Platform KMSを離れることはありません。

KMSは、 構成オプションMongo() を使用するmongosh コンストラクターを使用してGoogle Cloud PlatformKMS として として指定することをサポートしています。KMS

Google Cloud Platform KMSへのアクセスを設定するには、少なくともGoogle Cloud Platform Email と関連付けられた秘密キーが必要です。 Google Cloud Platformメール アカウントには、指定された秘密キーに対する次の IAM 権限が必要です。

  • cloudkms.cryptoKeyVersions.useToEncrypt

  • cloudkms.cryptoKeyVersions.useToDecrypt

これらの IAM 権限は、特定のGoogle Cloud Platform 事前定義されたロール に含まれています または は、Google Cloud Platform カスタムロールに含めることができます。

Google Cloud Platform KMSを使用したデータ暗号化キーの管理に関する詳細なドキュメントについては、「データ暗号化キーの管理 」を参照し、[ Google Cloud Platform KMS ] タブを選択してください。

ローカルで管理されるキー

mongoshでは、 Mongo()コンストラクターを使用してローカルで管理されるキーを KMS として指定することがサポートされています。 ローカルキーは、96 バイトの長さのstringである必要があります。

ローカルで管理されているキーを使用したデータ暗号化のキー管理に関する詳細なドキュメントについては、「データ暗号化キーの管理 」を参照し、[] タブを選択してください。

暗号化キーヴォールト

キーヴォールトは、クライアント側のフィールドレベル暗号化で使用するデータ暗号化キーを保存するコレクションです。 データ暗号化キーは、サポートされているKMS（Key Management System）を通じて管理される CMK（Customer Master Key）を使用して暗号化されます。

mongosh データ暗号化キー管理のヘルパー メソッドを提供します。

ユースケース
ヘルパー メソッド
データ暗号化キーの取得
データ暗号化キーの作成または変更
データ暗号化キーの削除

KeyVault.deleteKey()

重要

データ暗号化キーを削除すると、そのデータ暗号化キーを使用して暗号化されたすべてのフィールドが永続的に読み取りできなくなります。

キーヴォールト コレクションへのreadアクセスを持つアプリケーションは、コレクションをクエリすることでデータ暗号化キーを検索できます。 ただし、データ暗号化キーの暗号化に使用される CMK にアクセスできるアプリケーションのみが、そのキーを暗号化または復号化に使用できます。

デフォルトでは、MongoDB は接続されたクラスターにキーヴォールトコレクションを保存します。 MongoDB では、キーヴォールトとしてリモートクラスターを指定することもできます。 クライアント側のフィールドレベルの暗号化操作を実行するには、アプリケーションはリモート キーヴォールトクラスターと接続クラスターの両方にアクセスする必要があります。

データ暗号化キーの構造は次のとおりです。

{
  "_id" : UUID("<string>"),
  "keyMaterial" : BinData(0,"<encrypted binary data string>"),
      "creationDate" : ISODate("2019-08-20T15:45:02.575Z"),
      "updateDate" : ISODate("2019-08-20T15:45:02.575Z"),
      "status" : <int>,
      "version" : NumberLong(0),
      "masterKey" : {
        "provider" : "<string>",
        "key" : "<string>",
        "region" : "<string>",
        "endpoint" : "<string>"
      },
      "keyAltNames" : [
    "<string>"
  ]
}

クライアント側のフィールドレベルの暗号化は、 keyAltNames値の一意性に依存します。 mongosh KeyVault.createKey()メソッドは、 keyAltNamesに一意のインデックスが存在しない場合はそれを作成します。 アプリケーションは、キーヴォールト コレクションに対してlistIndexesコマンドを使用して、一意なインデックスが存在するかどうかを確認できます。 一意のインデックスが存在しない場合、アプリケーションはデータ暗号化キー管理を実行する前に一意のインデックスを作成する必要があります。

データ暗号化キーの管理に関する詳細なドキュメントについては、「 データ暗号化キーの管理 」を参照してください。

戻る

明示的（手動）クライアント側フィールドレベル暗号化

次へ

データ暗号化キーの管理