主な機能
項目一覧
Overview
このページでは、Queryable Encryption のセキュリティ上の利点、その仕組み、および MongoDB がサポートする他のセキュリティ メカニズムとの比較について学習できます。 また、データの保護における Queryable Encryption の値を示す架空のシナリオを表示することもできます。
Queryable Encryption
Queryable Encryption を使用すると、クライアントアプリケーションはクエリ可能性を維持しつつ、完全にランダム化された暗号化を使用してネットワーク経由でデータを転送する前にデータを暗号化できます。 機密データはクライアントによって透過的に暗号化および復号化され、暗号化された形式でのみサーバーとの間で通信されます。
決定的 な暗号化 を使用できる クライアント側のフィールドレベル暗号化 とは異なり、Queryable Encryption は構造化暗号化に基づく高速で検索可能な暗号化スキームを使用します。これらのスキームでは、同じクリアテキスト入力を指定しても、異なる暗号化出力値が生成されます。
セキュリティに関する考慮事項
Queryable Encryption では、カスタマー マスター キーまたはデータ暗号化キーにアクセスする所有者に対して、暗号化の整合性を保証しません。
Queryable Encryption では、暗号化されたデータを含むコレクションへの任意の書込み (write) アクセス権を持つノードに対して、暗号化の整合性を保証するものはありません。
MongoDB はスキーマ検証を使用して、コレクション内の特定のフィールドの暗号化を強制します。 クライアント側のスキーマがない場合、クライアントはコレクションのサーバー側スキーマをダウンロードして、暗号化するフィールドを決定します。 この問題を回避するには、 クライアント側のスキーマ検証 を使用します。
Queryable Encryption ではスキーマの整合性を検証するメカニズムが提供されていないため、サーバー側のスキーマに依存するということは、サーバーのスキーマが変更されていないことを信頼することを意味します。 攻撃者がサーバーを侵害した場合、スキーマを変更して、以前に暗号化されたフィールドに暗号化のラベルが付けられなくなるのです。 これにより、クライアントはそのフィールドのプレーンテキスト値を送信します。
クライアントとサーバー側スキーマの構成の例については、「 CSFLE サーバー側フィールド レベル暗号化強制 」の CSFLE の例を参照してください。
Queryable Encryptionの仕組み
以下の図は、カスタマー環境で Queryable Encryption がどのように使用されるかについてのプロセスとアーキテクチャを示しています。
この図では、ユーザーは SSN 番号などの完全にランダムに暗号化されたデータをクエリできます。
Queryable Encryption 内でこれを可能にするプロセスとメカニズムは次のとおりです。
アプリケーションがクエリを送信すると、MongoDB ドライバーはまずクエリを分析します。
ドライバーは、クエリが暗号化されたフィールドに対するものであることを認識し、次のようなカスタマーがプロビジョニングされたキープロバイダーに暗号化のキーをリクエストします。
Amazon Web Services KMS （ Amazon Web Services KMS ）
Google Cloud KMS
Azure Key Vault
任意の KMIP準拠のキー プロバイダー
ドライバーは、暗号化されたフィールドを 暗号テキストとしてレンダリングしたクエリを MongoDB サーバーに送信します。
Queryable Encryption は、高速で検索可能なスキームを実装し、サーバーが完全に暗号化されたデータに対するクエリを処理できるようにします。 データとクエリ自体は、サーバー上で常に暗号化されたままです。
MongoDB サーバーは、ドライバーへのクエリの暗号化された結果を返します。
クエリ結果はドライバーによって保持され、クライアントに返され、プレーンテキストとして表示されます。
次のデータ構造の支援を持つ Queryable Encryption 関数。 これらが変更または削除されないことが重要です。クエリ結果は不正確になるためです。
Queryable Encryption は、Queryable Encryption の暗号化フィールドがあるコレクション内のドキュメントに
__safeContent__フィールドを追加します。Queryable Encryption は、Queryable Encryption の暗号化フィールドがあるコレクションと同じデータベースに 2 つの内部メタデータコレクションを作成します。 これらの名前は次のようになります。
enxcol_.<collectionName>.escenxcol_.<collectionName>.ecoc
警告
これらのデータ構造を変更しないでください。クエリ結果が不正確になり、セキュリティに影響が出る可能性があります。
Queryable Encryption は、次のシナリオで暗号化されたフィールドを安全に維持します。
データベース スーパーユーザーによる暗号化されたフィールドへの直接アクセス
サーバーのメモリを読み取ることで暗号化されたフィールドにアクセスする
安全でないネットワーク経由で暗号化されたフィールドのキャプチャ
データベースまたはバックアップ ファイルの読み取りを使用して、ディスク上の暗号化されたフィールドにアクセスする
暗号化されたフィールドを持つドキュメントのパターンを識別することによる頻度分析攻撃
すべてのクライアントが機密性のないデータ フィールドにアクセスできますが、暗号化されたデータ フィールドを使用して読み取りおよび書込みクエリを実行できるのは、適切に構成された Queryable Encryption クライアントのみです。
重要
リモート キー管理システム
本番環境で Queryable Encryption を使用する場合は、暗号化のキーを保存するためにリモート KMS（Key Management System）を使用する必要があります。
リモート KMS を Queryable Encryption と併用する方法について、段階的なガイドを表示するには、「チュートリアル 」を参照してください。
サポートされているすべての KMS プロバイダーのリストを表示するには、「 KMS プロバイダー 」を参照してください。
リモート KMS を使用する必要がある理由の詳細については、「リモート キー管理システムを使用する理由 」を参照してください。
その他のセキュリティ メカニズム
このセクションでは、MongoDB でサポートされている次のセキュリティ メカニズムについて説明し、そのユースケースと制限について説明します。
ロールベースのアクセス制御
ロールベースのアクセス制御は、管理者がユーザーに対するコレクション レベルの権限を付与および制限できるセキュリティ メカニズムです。 適切なロールの定義と割り当てにより、このソリューションは誤ってデータを公開し、アクセスを防止します。
ロールベースのアクセス制御では、次のシナリオを保護できません。
安全でないネットワーク経由でのデータのキャプチャ
データベースまたはバックアップ ファイルの読み取りによるディスク上のデータへのアクセス
サーバーのメモリを読み取ることでデータにアクセスする
データベース スーパーユーザーによるデータへの直接アクセス
詳細については、「ロールベースのアクセス制御 」を参照してください。
保管時の暗号化
保管時の暗号化は、ディスク上のデータベースファイルを暗号化するメカニズムです。 このメカニズムにより、データベース認証情報を持たないが、データベースをホストしているコンピューターにアクセスできるユーザーは、データを表示できなくなります。
このメカニズムでは、次のシナリオからデータを保護しません。
安全でないネットワーク経由でのデータのキャプチャ
サーバーのメモリを読み取ることでデータにアクセスする
データベース スーパーユーザーによるデータへの直接アクセス
詳細については、「保存時の暗号化 」を参照してください。
トランスポート暗号化 (TLS/SSL)
TLS/SSL を使用したトランスポート暗号化により、ネットワーク経由でデータが暗号化されます。 TLS/SSL は、安全でないネットワークを移動する際にデータを保護しますが、特権ユーザーからのデータやディスク上にあるデータを保護することはできません。
詳しくは、「 TLS/SSL を使用したトランスポート暗号化」を参照してください。
機能の比較
次の図では、MongoDB がサポートするセキュリティ機能と、それが対処する潜在的なセキュリティ脆弱性について説明しています。
重要
メカニズムを併用する
本番環境の配置を保護するには、ロールベースのアクセス制御、保管時の暗号化、トランスポート暗号化、オプションで 使用中の暗号化 のセキュリティ メカニズムを併用します。 クライアント側フィールドレベル暗号化と Queryable Encryption の両方を使用して、同じコレクション内の異なるフィールドを暗号化することはできません。
クライアント側のフィールドレベル暗号化の詳細については、「クライアント側のフィールドレベル暗号化機能 」を参照してください。
Scenario
次の架空のシナリオは、アプリケーションのデータを保護する際の Queryable Encryption の値と、Queryable Encryption がこのガイドで説明されている他のセキュリティ メカニズムとどのように相互作用するのかを示しています。
このシナリオでは、架空の会社MedcoMDの従業員の個人情報、請求情報、医療レコードを保存する医療マネジメント システムで機密データを保護します。 医療データはいずれも公開されておらず、ソーシャル セキュリティ 番号（SSN、米国政府が発行する ID 番号）、受信者 ID 番号、請求情報、医療情報などの特定のデータは特に機密性が高く、プライバシー コンプライアンスが対象となります。 データが機密かつ安全に保たれることは、会社と従業員にとって重要です。
MedcoMD では、次のユースケースを満たすためにこのシステムが必要です。
」
システムを使用して、連絡先情報を使用してユーザーの身元を確認します。
レシーバーは、クライアントの請求情報を表示できますが、クライアントの ID 番号は表示できません。
レプリケーション担当者は、従業員の医療レコードにアクセスできません。
MedcoMDは、次のいずれかの方法で機密データを公開することにも懸念されています。
受信者の一般表示画面でのデータの誤った公開。
データベース管理者などのスーパーユーザーによるデータベースへの直接アクセス。
安全でないネットワーク経由でのデータのキャプチャ。
データベース サーバーのメモリを読み取ることでデータにアクセスします。
データベースまたはバックアップ ファイルを読み取ることでデータにアクセスします。
MedcoMD は、メトリクス マネジメント システムの機能とアクセス制限のバランスを取るためにできることは何ですか。
解決法
MedcoMD は、ユースケースを満たし、機密性の高い医療データの公開を防ぐために、次のセキュリティ メカニズムを使用しています。
ネットワーク上を移動する際にデータを保護するためのトランスポート暗号化（TLS/SSL） 。
データベースまたはバックアップ ファイルの読み取りによるデータの公開を防ぐための保管時の暗号化。
ロールベースのアクセス制御は、データベースユーザーがタスクを実行するために必要なコレクションへのアクセスを制限します。
Queryable Encryption を使用して機密フィールドを暗号化すると、次のユースケースと制約を満たすことができます。
Queryable Encryption で暗号化されたデータは、暗号化されていない形式でデータベース サーバーに存在しないため、サーバー メモリからのデータの読み取りは防止します。
Queryable Encryption が有効になっていないクライアントを提供することで、受信者の ID を確認し、受信者の一般表示画面に機密データが誤って表示されるのを防ぎます。
Queryable Encryption が有効なクライアントを提供することで、従業員がオフィス内で機密データをプライベートで表示できるようにします。
詳細
MongoDB デプロイを保護するために実装する必要があるセキュリティ対策のリストを表示するには、セキュリティ チェックリスト を参照してください。
Queryable Encryption の使用を開始するには、「クイック スタート」を参照してください。