先週、MongoDB Queryable Encryption におけるプレフィックス、サフィックス、およびサブストリングのクエリサポートの一般提供開始をアナウンスしました。これらの機能は、Queryable Encryption の対象を等価クエリやレンジクエリ以外にも拡大するものであり、本番ワークロードでも完全にサポートされるようになりました。
MongoDB Queryable Encryptionは、MongoDB Cryptography Research Groupが開発した画期的な業界初の使用中の暗号化テクノロジーです。これは、お客様が機密性の高いアプリケーションデータを暗号化し、MongoDBに暗号化された形式で保存し、復号することなくその暗号化されたデータに対して表現豊かなクエリを実行できるように有効にするものです。データベースは、プレーンテキストのデータを見ることはありません。
組織は、本番環境で暗号化されたデータに対して柔軟なテキスト検索（部分的な名前、単語、識別子の一致など）を実行できるようになり、明確に定義されたセキュリティ保証の下で、基礎の情報を設計により保護できるようになりました。つまり、より強力なデータ保護とよりシンプルなコンプライアンスが実現し、外部の検索インデックスのような回避策が不要になるのです。すべては最小限のコード変更と新しいインフラなしで実現されます。
Queryable Encryption でプレフィックス、サフィックス、サブストリングのクエリが一般提供されるようになったことで、MongoDB は、保存時、転送時、使用時といったデータライフサイクル全体を通じて、組織が機密データを保護できるようにします。その結果、チームは機能を損なうことなく、セキュリティを確保しプライバシーに配慮したアプリケーションをビルドできます。Queryable Encryptionは、MongoDB Atlas、MongoDB Enterprise Advanced、および MongoDB Community Edition で追加コストなしで利用できます。
挑戦：データを使用するまでしか保護されない
ほとんどの組織では、氏名や社会保障番号のような個人識別情報（PII）や、医療レコードのような保護対象保健情報（PHI）など、機密データを保存しています。そのデータをストレージへの保存中やネットワーク経由での移動中に安全に保つことは、広く認識されています。保管時の暗号化と転送中の暗号化は、今日では標準的な手法となっています。
しかし、そのデータのクエリは別の話です。従来の暗号化はデータを読み取り不能にするため、データベースは最初に復号化しない限り検索できません。"edema"（浮腫）という単語を含む診断を受けたすべての患者を特定する必要がある医療プロバイダを例に挙げてみましょう。レコードを復号化しないと、データベースはその用語を検索できません。
これを回避するために、多くの組織では、機密フィールドを暗号化しないままにするか、アプリケーションに必要なクエリを有効にするために外部検索インデックスをビルドしています。どちらのアプローチも、運用上のオーバーヘッドが増大します。どちらも、機密データが最も露出する瞬間に、不正なアクセス権のリスクを高めます。
規制当局からの圧力がある場合、これはさらに困難になります。医療保険の相互運用性と責任に関する法律（HIPAA）、Payment Card Industry Data セキュリティ Standard（PCI-DSS）、一般データ保護規則（GDPR）などの基準では、機密データを単に保存中や転送中に保護するだけでなく、あらゆる段階で保護されていることを実証するよう組織に求めています。データがアクティブに使用されている間の保護は、ほとんどの暗号化手法では対処できない課題です。
機密データを完全に保護し、コンプライアンス要件を満たすために、組織は、復号化を行うことなく、またパフォーマンスを犠牲にしたり新しいインフラを追加したりすることなく、暗号化されたデータを検索する方法を必要としています。
Zero-exposure data protection
MongoDB Queryable Encryptionは、このギャップを埋めるためにビルドされています。機密データをアクティブに検索している最中も、つまり他の暗号化手法では到達できないステージでも、データを暗号化されたまま維持します。
Queryable Encryptionを使用すると、機密フィールドは、データベース・サーバー自体でもプレーンテキストで保存する、送信、処理、返信されることはありません。クエリは、暗号化されたデータに対して実行されます。復号化はなく、データが露出するウィンドウもありません。
これは、Queryable Encryptionが、サーバーでのクエリ処理中に常にデータを暗号化された状態にしておく構造化暗号化スキーム上にビルドされているために可能です。このスキームは完全にオープンソースであり、ベンダーの主張を鵜呑みにするのではなく、個別に検証できます。これは業界初の取り組みです。現在、これほど高度な使用中の暗号化を提供するデータベース技術は他にありません。また、セキュアエンクレーブのような特殊なハードウェアにも依存していません。
組織はすでに、最も機密性の高いデータの一部を保護するためにQueryable Encryptionを採用しています。フランスの内部セキュリティ部隊（ANFSI）は、政府レベルのセキュリティレビューに支えられて、機密レコードを保護するために同製品を採用しています。
PII（個人を特定できる情報）、PHI（保護されるべき医療情報）、またはその他の規制対象データを扱うチームにとって、これは機密情報が露出する可能性のある場所を減らすことを意味します。直接データベースにアクセス権を持つ内部関係者からの露出を防ぐことも可能です。
より表現力豊かな検索、組み込み
これまでQueryable Encryptionでは、一般提供で等価クエリとレンジクエリがサポートされていました。これは完全一致と有界数値参照を対象としていますが、アプリケーションでは、部分名参照、オートコンプリート、部分単語フィルターなど、より柔軟なものが必要になることがよくあります。プレフィックス、サフィックス、サブストリングの各クエリが一般提供されるようになったことで、そのギャップが埋まりました。
暗号化されたフィールドで直接実行できるようになったことは次の通りです。
プレフィックスクエリは、フィールド値が特定の文字シーケンスで始まるドキュメントを返します。例として、姓が"Mac"で始まるすべてのカスタマーを検索することがあります。
サフィックスクエリは、フィールドの値が特定のシーケンスで終わるドキュメントを返します。例として、暗号化された社会保障番号の下4桁の一致を挙げます。
Substringクエリは、フィールド内のどこかに特定のシーケンスが表示されるドキュメントを返します。Substring検索は、最大50文字の短い構造化フィールドをカバーし、2〜6文字の期間を検索します。例えば、暗号化されたジョブタイトルフィールド内で「eng」を検索し、「Engineer」と「エンジニアリング マネージャー」の両方に一致させます。
レンジクエリ（既存）は、暗号化された給与レンジのように、フィールド値が指定された下限と上限の範囲内に収まるドキュメントを返します。
等価クエリ (既存) は、特定の暗号化されたメールアドレスのように、フィールド値が完全に一致するドキュメントを返します。
これらのクエリタイプは、MongoDBのネイティブクエリエンジンとドライバーを介して実行されます。これは、他のすべてのクエリタイプに使用されるものと同じです。立ち上げる外部検索インデックス、保守するミドルウェアは不要で、アプリケーションコードの変更も最小限で済みます。チームは、既に実行しているのと同じアーキテクチャを使用して、暗号化されたデータの表現力豊かな部分一致検索を取得します。
主張するだけでなく、証明できるコンプライアンス
HIPAA、PCI-DSS、GDPRなどの要件を満たすとは、単に主張するだけでなく、機密データが保護されていることを実証することを意味します。暗号化の主張を独立して検証できない場合、それは困難であり、さらにその主張がアクティブに使用中のデータをカバーしていない場合はさらに困難になります。
Queryable Encryptionは、コンプライアンスチームとリスクチームに説得力のある答えるを提供します。その構造化暗号化スキームは完全にオープンソースであるため、その基盤となる暗号技術は、信頼のみに依存するのではなく、独立してレビューできます。さらに、保存時や転送時だけでなく、クエリの処理全体を通じてデータを保護できるため、ほとんどのコンプライアンスプログラムでは対応できないステージに対処できます。
プレフィックス、サフィックス、サブストリングのクエリが一般提供されるようになったことで、名前やメールアドレスの部分検索、自由記述フィールドでの部分的な単語のフィルター、部分的なID一致など、多くのユースケースで同じ証拠を得られるようになりました。その結果、ワークロードがオンプレミス、ハイブリッド環境、複数のクラウドのいずれで実行されている場合でも、監査する際のギャップや調整が必要な断片化されたツールが減少します。
チームがビルドできること
Queryable Encryptionで接頭辞、接尾辞、部分文字列クエリが一般的に利用可能になったことで、組織が達成できることの例をいくつか紹介します。
コンプライアンスとユーザビリティのためのPII検索：GDPRやHIPAAなどの規制では、個人情報の厳格なプライバシーが義務付けられています。接頭辞クエリを使用すると、チームは基礎のデータを暗号化したまま、名字やメールの接頭辞でユーザーを抽出できます。これにより、検索機能を損なうことなく、コンプライアンスが容易になります。
構造化フィールドの部分単語フィルター：診断などの構造化フィールドでは、部分一致がしばしば必要になります。サブストリングクエリのサポートにより、チームは暗号化された健康状態フィールドで"diabet"のような期間を検索でき、"diabetes"と"diabetic"の両方に一致します。”
安全なID検証：IDワークフローは、社会保障番号、全国保険番号、Aadhaar番号の下4桁など、部分的な識別子に依存することがよくあります。サフィックスクエリを使用すると、完全な値を明らかにすることなく、暗号化されたフィールドでこれらの参照を有効にできるため、規制された環境でのデータ漏洩のリスクが軽減されます。
公共機関のケースマネージメント：公共部門のアプリケーションにおけるケース番号と参照IDは、多くの場合、構造化された形式に従います。接頭辞クエリを使用すると、機関は機密性の高いケースのメタデータを公開することなく、「NYC-」や「EUR-」などの地域またはオフィスベースの接頭辞を使用してレコードを抽出できます。
Queryable Encryptionを開始する
プレフィックス、サフィックス、およびサブストリングクエリにより、チームはセキュリティと機能性の間で妥協する必要なく、機密データを柔軟に検索できます。コンプライアンス要件への対応、インフラストラクチャの複雑さの軽減、より優れたアプリケーションの構築など、どのような目的であっても、これらの機能は現在、本番環境ですぐに使用できます。
プレフィックス、サフィックス、サブストリングクエリにより、チームは機密データを検索する柔軟性が新しいレベルに引き上げられます。これらの新しいクエリタイプは、不正なアクセス権から機密データを保護し、コンプライアンス要件を満たしながら、インフラストラクチャと運用の複雑さを軽減します。
次のステップ
Queryable Encryption とその仕組みの詳細については、「Queryable Encryption の機能」ページを参照してください。まずは、「クイック スタート ガイド」を参照してください。