Docs Menu

Queryable Encryption の制限

Consider these limitations and restrictions before enabling Queryable Encryption. Some operations are unsupported, and others behave differently.

For compatibility limitations, please read 互換性.

警告

Queryable Encryptionは、環境への永続的なアクセスを持つユーザー、またはデータベーススナップショットとそれに付随するクエリ トランザクション/ログの両方を取得できるユーザーではなく、データの流出を防ぎます。

Queryable Encryptionを使用する場合、等価クエリと範囲クエリはデータベーススナップショットを持つ攻撃者に対して同様のセキュリティを提供します。 ただし、データベーススナップショットとクエリ情報の両方にアクセスする攻撃者は、Queryable Encryption のセキュリティ保証の範囲を超えています。 これは、検索されるクエリ トランザクションまたはログの数が少ない場合でも、範囲クエリに特に当てはまります。詳細については、概要ホワイトペーパーの6.1 : 永続モデルの範囲クエリ を参照してください。

コレクションで Queryable Encryption を有効にすると、一部の診断コマンドのフィールドが編集され、クエリ ログから一部の操作が省略されます。これにより、特にクエリのパフォーマンスを分析する際、MongoDBサポートエンジニアが利用できるデータが制限されます。暗号化されたコレクションに対する操作の影響を測定するには、サードパーティのアプリケーションパフォーマンス監視ツールを使用してメトリクスを収集します。

For details, see the 編集 section of this page.

Queryable Encryption supports a subset of commands, query operators, update operators, aggregation stages, and aggregation expressions. For the list of supported operations, see Queryable Encryption がサポートする操作.

Manually run metadata collection compaction when your metadata collections exceed 1 GB. Compaction decreases the size of the metadata collections associated with encrypted fields, and improves performance.

Do not modify the encryptedFieldsMap passed to your MongoClient. Doing so can result in unexpected and incorrect behavior when querying.

Queryable Encryption encrypts the set of fields in the encryptedFieldsMap configuration that you pass to your MongoClient constructor. If you specify a formerly plaintext field in your encryptedFieldsMap configuration that exists in the collection documents, you can only query on that field for documents inserted after you updated your encryptedFieldsMap configuration.

For example, consider a database in which you have inserted documents with a plaintext streetAddress field. Adding this field to encryptedFieldsMap and performing subsequent inserts will insert the encrypted value of streetAddress into the database. The driver will send future queries for a specific streetAddress as BinData. As a result, the plaintext values in the original documents will never match future queries.

You cannot configure Queryable Encryption to encrypt the _id field because it relies on the value auto-generated by MongoDB.

You can't rename an encrypted field. For example, if you specify ssn as a field to encrypt, you can't $rename the field name to taxPayerID.

The query type you specify for a field when creating the collection in encryptedFieldsMap is immutable. You cannot enable new query types to an existing field, and you cannot change the existing query type.

To improve security, Queryable Encryption redacts fields from some diagnostic commands on encrypted collections, and omits certain operations from the query log. An encrypted collection is any collection with the encryptedFields option.

The CRUD operations below are omitted from the slow operations query log and the Database Profiler system.profile collection when you run them on an encrypted collection.

The collStats command and $collStats aggregation stage:

  • Omit "queryExecStats"

  • Omit "latencyStats"

  • Redact "WiredTiger", if present, to include only the url field.

The currentOp command and $currentOp aggregation stage:

  • Omit all fields after "command".

  • Redact "command" to include only the first element, $comment, and $db.

The top command only returns the collection name of encrypted collections.

The $planCacheStats aggregation stage omits operations against encrypted collections, even though the operations are cached as normal.

  • Replica sets and sharded clusters are supported

  • Standalone deployments are not supported

  • Secondary reads are not supported

  • Metadata collections must not be sharded

  • Shard keys must not be encrypted fields

  • You cannot use Client-Side Field Level Encryption with Queryable Encryption on the same collection.

    • Queryable Encryption does not support migration from collections encrypted with Client-Side Field Level Encryption. You must decrypt your documents and insert them one-by-one.

    • Queryable Encryption does not support automatic migration from an unencrypted collection. You must insert the documents one-by-one.

  • Queryable Encryption supports new collections only. You cannot add or remove Queryable Encryption to existing collections.

  • You cannot rename a collection with encrypted fields.

  • You cannot specify jsonSchema to db.createCollection() when creating a Queryable Encryption collection if the jsonSchema contains the encrypt keyword.

  • Queryable Encryption does not support ビュー, 時系列コレクション, or 上限付きコレクション.

  • Queryable Encryption does not support TTL Indexes or Unique Indexes.

  • You cannot disable jsonSchema validation.

  • When a collection uses the encryptedFields option:

    • You cannot set validationLevel to none.

    • You cannot set validationAction to warn.

  • Dropping collections from a MongoClient that is not configured for Queryable Encryption doesn't drop the associated metadata collections. mongod logs a warning if you drop a collection with encrypted fields before dropping the metadata collections.

Tip

When dropping a collection with a MongoClient configured for Queryable Encryption, compatible drivers drop the associated metadata collections as well.

Always explicitly create any collections that use Queryable Encryption. Implicit collection creation doesn't create the necessary indexes and metadata collections, resulting in poor query performance.

Queryable Encryption does not support automatic encryption on fields within an array of documents.

Applications cannot rely on the automatic encryption validation to prevent unsupported queries against views on collections with encrypted fields.

Queries against views on collections containing values encrypted with Queryable Encryption may return unexpected or incorrect results if either the underlying view aggregation pipeline or the query references encrypted fields. If creating a view on a collection containing values encrypted with Queryable Encryption, avoid operating on encrypted fields to mitigate the risk of unexpected or incorrect results.

For more information on views, see ビュー.

Queryable Encryption ignores user-specified collations or collection default collations. Encryption obscures the field value and prevents normal collation behavior. Collation-sensitive queries against encrypted fields may return unexpected or incorrect results.

For more information on collations, see 照合ドキュメント.

Queryable Encryption-compatible drivers have a list of supported operations for automatic encryption. For unsupported read and write operations, the underlying support library cannot introspect the collection catalog to identify the default collation. Applications therefore cannot rely on the Queryable Encryption validation to prevent querying on encrypted fields with collation defaults.

Unique indexes can't guarantee uniqueness if the index key specifies any encrypted fields.

Queryable Encryption always outputs a different encrypted value, even for the same input. The server considers each encrypted value unique, even though the decrypted value may not be. This means that even if a collection uses an index-enforced unique constraint on fields, the collection can still contain multiple documents with duplicate plaintext values for that field.

Queryable Encryption compatible drivers configured for automatic encryption support some operations for automatic encryption. For unsupported read and write operations, the underlying library can't introspect the index catalog to identify a given field as unique. Applications can't rely on automatic encryption validation to prevent unique constraint violations on randomly-encrypted fields.