@@ -30,11 +30,84 @@ to encrypt data before transporting it over the network. Sensitive data is
3030transparently encrypted and decrypted by the client and only
3131communicated to and from the server in encrypted form.
3232
33- For more information , see :ref:`{+qe+} Features <qe-features>` and
33+ To compare features in detail , see :ref:`{+qe+} Features <qe-features>` and
3434:ref:`{+csfle-abbrev+} Features <csfle-features>`.
3535
36+ Considerations
37+ --------------
38+
39+ When implementing and application that uses {+qe+} or {+csfle-abbrev+}, review
40+ the security considerations in this section.
41+
42+ For the limitations of each approach, see :ref:`{+qe+} limitations
43+ <qe-reference-encryption-limits>` or :ref:`{+csfle-abbrev+} limitations
44+ <csfle-reference-encryption-limits>`.
45+
46+ For MongoDB server and driver version compatibility, see :ref:`Compatibility
47+ <qe-csfle-compatibility>`.
48+
49+ .. _qe-csfle-security-considerations:
50+
51+ Security Considerations
52+ ~~~~~~~~~~~~~~~~~~~~~~~
53+
54+ * {+csfle-abbrev+} and {+qe+} do not provide any cryptographic integrity
55+ guarantees against adversaries with access to your {+cmk-long+},
56+ {+dek-long+}s.
57+
58+ * {+csfle-abbrev+} and {+qe+} do not provide any cryptographic integrity
59+ guarantees against adversaries with arbitrary write access to collections
60+ containing encrypted data.
61+
62+ * MongoDB uses :ref:`schema validation <schema-validation-overview>` to enforce
63+ encryption of specific fields in a collection. Without a client-side schema,
64+ the client downloads the server-side schema for the collection to determine
65+ which fields to encrypt. To avoid this issue, use client-side schema validation.
66+
67+ Because {+csfle-abbrev+} and {+qe+} do not provide a mechanism to verify
68+ the integrity of a schema, relying on a server-side schema means
69+ trusting that the server's schema has not been tampered with. If an adversary
70+ compromises the server, they can modify the schema so that a previously
71+ encrypted field is no longer labeled for encryption. This causes the client
72+ to send plaintext values for that field.
73+
74+ For an example of {+csfle-abbrev+} configuration for client and server-side
75+ schemas, see :ref:`CSFLE Server-Side Field Level Encryption Enforcement <field-level-encryption-automatic-remote-schema>`.
76+
77+
78+ Using {+qe+} and {+csfle-abbrev+}
79+ ------------------------------------------------------------------------
80+
81+ You can use {+qe+}, {+csfle+}, or both in your application. However,
82+ you can't use both approaches in the same collection.
83+
84+ Consider using {+qe+} in the following scenarios:
85+
86+ - You are developing a new application and want to use the latest
87+ cryptographic advancements from MongoDB.
88+ - You expect users to run ranged, prefix, suffix, or substring queries
89+ against encrypted data.
90+ - Your application can use a single key for a given field, rather than
91+ requiring separate keys on a per-user or per-tenant basis.
92+ - You value read performance over storage requirements. {+qe+} generates
93+ internal :ref:`metadata collections <qe-metadata-collections>` and
94+ indexes to improve query performance. As a result, a collection
95+ encrypted with {+qe+} uses 2-4 times the storage space that it would
96+ if it were plaintext or encrypted with {+csfle-abbrev+}.
97+
98+ There are situations where {+csfle-abbrev+} may be a preferable solution:
99+
100+ - Your application already uses {+csfle-abbrev+}.
101+ - You need to use different keys for the same field. This is commonly
102+ encountered when separating tenants or using user-specific keys.
103+ - You need to be flexible with your data schema and potentially add more
104+ encrypted fields. Adding encrypted fields for {+qe+}
105+ requires rebuilding metadata collections and indexes.
106+ - The increased storage requirements of {+qe+} are a concern.
107+
36108Querying Encrypted Fields
37109~~~~~~~~~~~~~~~~~~~~~~~~~
110+
38111{+qe+} supports equality queries on encrypted fields.
39112Support for ranged queries is upcoming, and support for prefix, suffix,
40113and substring queries with {+qe+} is under development.
@@ -76,44 +149,6 @@ field has very few values, like sex, then attackers can reasonably guess
76149them and use that information to help to decipher the cryptographic
77150algorithm.
78151
79- Using {+qe+} and {+csfle-abbrev+}
80- ------------------------------------------------------------------------
81- You can use {+qe+}, {+csfle+}, or both in your application. However,
82- you can't use both approaches in the same collection.
83-
84- Consider using {+qe+} in the following scenarios:
85-
86- - You are developing a new application and want to use the latest
87- cryptographic advancements from MongoDB.
88- - You expect users to run ranged, prefix, suffix, or substring queries
89- against encrypted data.
90- - Your application can use a single key for a given field, rather than
91- requiring separate keys on a per-user or per-tenant basis.
92- - You value read performance over storage requirements. {+qe+} generates
93- internal :ref:`metadata collections <qe-metadata-collections>` and
94- indexes to improve query performance. As a result, a collection
95- encrypted with {+qe+} uses 2-4 times the storage space that it would
96- if it were plaintext or encrypted with {+csfle-abbrev+}.
97-
98- There are situations where {+csfle-abbrev+} may be a preferable solution:
99-
100- - Your application already uses {+csfle-abbrev+}.
101- - You need to use different keys for the same field. This is commonly
102- encountered when separating tenants or using user-specific keys.
103- - You need to be flexible with your data schema and potentially add more
104- encrypted fields. Adding encrypted fields for {+qe+}
105- requires rebuilding metadata collections and indexes.
106- - The increased storage requirements of {+qe+} are a concern.
107- - Your company or industry prefers mature products over emerging
108- technologies.
109-
110- Compatibility
111- ~~~~~~~~~~~~~
112- {+qe+} and {+csfle+} are compatible with different MongoDB server and
113- driver versions. Both {+qe+} and {+csfle-abbrev+} are supported for the
114- foreseeable future. For details, see :ref:`Compatibility
115- <qe-csfle-compatibility>`.
116-
117152Private Querying
118153~~~~~~~~~~~~~~~~
119154
@@ -123,18 +158,12 @@ With {+qe+}, private querying goes a step further and redacts logs and
123158metadata to scrub information around the query's existence. This ensures
124159stronger privacy and confidentiality.
125160
126- Limitations
127- ~~~~~~~~~~~
128-
129- For the limitations of each approach, see :ref:`{+qe+} limitations
130- <qe-reference-encryption-limits>` or :ref:`{+csfle-abbrev+} limitations
131- <csfle-reference-encryption-limits>`.
132-
133161Choosing Between Automatic and {+manual-enc-title+}
134162---------------------------------------------------------
135163
136164Using Automatic Encryption
137165~~~~~~~~~~~~~~~~~~~~~~~~~~
166+
138167We recommend automatic encryption in most situations, as it streamlines
139168the process of writing your client application. With automatic
140169encryption, MongoDB automatically encrypts and decrypts fields in read
@@ -146,4 +175,11 @@ Using {+manual-enc-title+}
146175.. include:: /includes/queryable-encryption/qe-csfle-manual-enc-overview.rst
147176
148177For details, see :ref:`{+manual-enc-title+} with {+qe+}
149- <qe-fundamentals-manual-encryption>` or :ref:`{+manual-enc-title+} with {+csfle-abbrev+} <csfle-fundamentals-manual-encryption>`.
178+ <qe-fundamentals-manual-encryption>` or :ref:`{+manual-enc-title+} with
179+ {+csfle-abbrev+} <csfle-fundamentals-manual-encryption>`.
180+
181+ .. toctree::
182+ :titlesonly:
183+
184+ /core/queryable-encryption/reference/limitations
185+ /core/csfle/reference/limitations
0 commit comments