使用中の暗号化アプローチの選択
項目一覧
MongoDBは、 使用中の暗号化に対して、 Queryable Encryptionとクライアント側フィールド レベルの暗号化（CSFLE） という 2 つのアプローチを提供します。 どちらのアプローチを使用する場合は、自動暗号化と明示的な暗号化のどちらかを選択することもできます。
Queryable Encryption と CSFLE について
Queryable Encryption と クライアント側フィールド レベル暗号化（CSFLE） の両方により、クライアント アプリケーションはネットワーク経由でデータを転送する前にデータを暗号化できます。 機密データはクライアントによって透過的に暗号化および復号化され、暗号化された形式でのみサーバーとの間で通信されます。
機能を詳しく比較するには、「 Queryable Encryption の機能 」と「 CSFLE の機能 」を参照してください。
Considerations
Queryable Encryption または CSFLE を使用する および アプリケーションを実装する場合は、このセクションのセキュリティに関する考慮事項を確認してください。
各アプローチの制限については、「 Queryable Encryption の制限」または「 CSFLE の制限 」を参照してください。
MongoDB サーバーとドライバーのバージョンの互換性については、「互換性 」を参照してください。
セキュリティに関する考慮事項
CSFLE および Queryable Encryption は、カスタマー マスター キー、データ暗号化キーにアクセスするノードに対して、暗号化の整合性を保証しません。
CSFLE および Queryable Encryption では、暗号化されたデータを含むコレクションへの任意の書込み (write) アクセス権を持つノードに対して、暗号化の整合性を保証するものはありません。
MongoDB はスキーマ検証を使用して、コレクション内の特定のフィールドの暗号化を強制します。 クライアント側のスキーマがない場合、クライアントはコレクションのサーバー側スキーマをダウンロードして、暗号化するフィールドを決定します。 この問題を回避するには、 クライアント側のスキーマ検証 を使用します。
CSFLE および Queryable Encryption ではスキーマの整合性を検証するメカニズムが提供されていないため、サーバー側のスキーマに依存するということは、サーバーのスキーマが操作されていないことを信頼することを意味します。 攻撃者がサーバーを侵害した場合、スキーマを変更して、以前に暗号化されたフィールドに暗号化のラベルが付けられなくなるのです。 これにより、クライアントはそのフィールドのプレーンテキスト値を送信します。
クライアントとサーバー側スキーマの CSFLE 構成の例については、「 CSFLE サーバー側フィールド レベル暗号化強制 」を参照してください。
Queryable Encryption と CSFLE の使用
アプリケーションでは、Queryable Encryption、クライアント側のフィールドレベル暗号化、またはその両方を使用できます。 ただし、同じコレクションで両方のアプローチを使用することはできません。
次のシナリオでは、Queryable Encryption の使用を検討してください。
新しいアプリケーションを開発していて、MongoDB の最新の暗号化の機能を使用したいと考えています。
暗号化されたデータに対して、範囲指定されたプレフィックス、サフィックス、またはサブストリングのクエリを実行することがユーザーを想定しています。
アプリケーションでは、ユーザーごとまたはテナントごとに個別のキーが必要になるのではなく、特定のフィールドに単一のキーを使用できます。
ストレージ要件よりも読み取りパフォーマンスを重視する場合。 Queryable Encryption は、クエリのパフォーマンスを向上させるために、内部メタデータ コレクションとインデックスを生成します。 その結果、Queryable Encryption で暗号化されたコレクションは、プレーンテキストまたは CSFLE で暗号化された場合に比べて、 2 - 4のストレージ領域を使用します。
CSFLE が推奨されるソリューションがあります。
アプリケーションはすでに CSFLE を使用している。
同じフィールドには異なるキーを使用する必要があります。 これは通常、テナントを分離したり、ユーザー固有のキーを使用したりするときに発生します。
データスキーマを柔軟に対応する必要があり、暗号化フィールドを追加できる可能性があります。 Queryable Encryption に暗号化されたフィールドを追加するには、メタデータコレクションとインデックスを再構築する必要があります。
Queryable Encryption のストレージ要件の増加が懸念されます。
暗号化されたフィールドのクエリ
Queryable Encryption は、暗号化されたフィールドに対する等価クエリをサポートします。 範囲指定されたクエリのサポートは予定されており、Queryable Encryption を使用したプレフィックス、サフィックス、サブストリング クエリのサポートは開発中です。
クライアント側のフィールドレベル暗号化は、確定的に暗号化されたフィールドに対する等価クエリをサポートします。
サポートされているクエリ演算子の詳細については、「 Queryable Encryptionでサポートされているクエリ演算子 」および「 CSFLE 用にサポートされているクエリ演算子 」を参照してください。 MongoDB クエリ演算子の完全なリストについては、「 クエリ演算子とプロジェクション 演算子 」を参照してください。
暗号化アルゴリズム
Queryable Encryption の新しい暗号化アルゴリズムは、構造化暗号化に基づくランダム化された暗号化を使用し、同じ入力から異なる暗号化された出力値を生成します。 これにより、攻撃者が暗号化を逆方向に実行するのを防ぎます。
MongoDB の Queryable Encryption へのアプローチの詳細については、 Queryable Encryption の概要 を参照してください。 および ステートレス ドキュメント データベース暗号化スキームの設計と分析 ホワイトペーパー。
CSFLE 暗号化アルゴリズムは、ランダム化された暗号化と決定的な暗号化 の両方をサポートしています。 ただし、サポートするのは確実に暗号化されたフィールドのクエリのみです。
決定的な暗号化では、特定の入力値は常に同じ出力値に暗号化されます。 決定的な暗号化は、濃度の高いデータに適しています。 住所などのフィールドに多数の潜在的な一意の値がある場合、潜在的な攻撃者が暗号化された値をプレーンテキストに元に戻すのは困難です。 逆に、性のようにフィールドの値が非常に少ない場合、攻撃者は無難にそれらを推測し、その情報を使用して暗号化アルゴリズムを解読するのに役立ちます。
プライベートクエリ
MongoDB は、Queryable Encryption とクライアント側フィールドレベル暗号化の両方でクエリを暗号化するため、サーバーはクリアテキストドキュメントまたはクエリ値に関する情報を持たなくなります。 Queryable Encryption では、プライベートクエリがさらにステップダウンし、ログとメタデータが編集され、クエリの存在に関する情報がスクレイピングされます。 これにより、プライバシーと機密性が強化されます。
自動暗号化と明示的暗号化のどちらかを選択する
自動暗号化の使用
クライアント アプリケーションの作成プロセスが効率化されるため、ほとんどの場合、自動暗号化を推奨します。 自動暗号化を使用すると、MongoDB は読み取りおよび書込み操作においてフィールドを自動的に暗号化および復号化します。
明示的な暗号化の使用
明示的な暗号化により、セキュリティをきめ細やかに制御できますが、コレクションの構成や MongoDB ドライバー のコード記述の複雑さは増します。 明示的な暗号化では、データベースで実行する各操作に対してドキュメント内のフィールドを暗号化する方法を指定し、このロジックをアプリケーション全体に含めます。
詳細については、「 Queryable Encryption による明示的な暗号化 」または「 CSFLE による明示的な暗号化 」を参照してください。