主な機能
項目一覧
Overview
このページでは、Queryable Encryption のセキュリティ上の利点、その仕組み、および MongoDB がサポートする他のセキュリティ メカニズムとの比較について学習できます。 また、データの保護における Queryable Encryption の値を示す架空のシナリオを表示することもできます。
Queryable Encryption
Queryable Encryption を使用すると、クライアントアプリケーションはクエリ可能性を維持しつつ、完全にランダム化された暗号化を使用してネットワーク経由でデータを転送する前にデータを暗号化できます。 機密データはクライアントによって透過的に暗号化および復号化され、暗号化された形式でのみサーバーとの間で通信されます。
決定的 な暗号化 を使用できる クライアント側フィールドレベル暗号化 とは異なり、Queryable Encryption は構造化暗号化に基づく高速で検索可能な暗号化スキームを使用します。これらのスキームでは、同じクリアテキスト入力を指定しても、異なる暗号化出力値が生成されます。
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の両方を使用できません。
重要
これは一般的な比較を目的とした高レベルのサマリーです。 詳しくは、「 Queryable Encryptionの概要 」 参照してください。 および ステートレス ドキュメント データベース暗号化スキームの設計と分析 ホワイトペーパー。
スレッド | TLS/SSL トランスポートの暗号化 | 保管時の暗号化（EaR） | Queryable Encryption (Equality) + TLS/SSL + EaR | CSFLE + TLS/SSL + EaR |
|---|---|---|---|---|
ネットワーク スループット（攻撃者はネットワーク トラフィックにアクセスできる） | 操作メタデータを識別します | 操作メタデータを識別します | 操作メタデータを識別します | 操作メタデータを識別します |
ディスクからのデータベース回復（攻撃者は物理ディスクにアクセスできる） | データベースを説明します | データベースと操作メタデータのサイズを表示 | データベースと操作メタデータのサイズを表示 | データベースと操作メタデータのサイズを表示 |
データベースを説明します | データベースを説明します | データベースと操作メタデータのサイズを表示 | 値と操作メタデータの頻度を報告 | |
高度な永続しきい値（攻撃者はネットワーク、ディスク、メモリに長期間にわたって継続的にアクセスし、検出されないまま） | データベースを説明します | データベースを説明します | Queryable Encryptionは ATP を保護するように設計されていません。 詳細については、 ホワイトペーパー を参照してください。 | CSFLE は ATP から保護するように設計されていません。 詳細については、 ホワイトペーパー を参照してください。 |
| [1] | これでは、完了した操作の間に抽出が発生することを前提としています。 ホワイトペーパー を参照 詳細については、「 」を参照してください。 |
警告
Queryable Encryptionは、環境への永続的なアクセスを持つユーザー、またはデータベーススナップショットとそれに付随するクエリ トランザクション/ログの両方を取得できるユーザーではなく、データの流出を防ぎます。
Queryable Encryptionを使用する場合、等価クエリと範囲クエリはデータベーススナップショットを持つ攻撃者に対して同様のセキュリティを提供します。 ただし、データベーススナップショットとクエリ情報の両方にアクセスする攻撃者は、Queryable Encryption のセキュリティ保証の範囲を超えています。 これは、検索されるクエリ トランザクションまたはログの数が少ない場合でも、範囲クエリに特に当てはまります。詳細については、概要ホワイトペーパーの6.1 : 永続モデルの範囲クエリ を参照してください。
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 の使用を開始するには、「クイック スタート」を参照してください。