Oracle Secure Enterprise Searchを使用したセキュアな検索

(1)

Oracle Secure Enterprise Search を使用し

たセキュアな検索

オラクル・ホワイト・ペーパー

(2)

Oracle Secure Enterprise Search を

使用したセキュアな検索

概要 ... 3

はじめに ... 3

保護されたソース... 3

セキュアなクロール、セキュアな検索結果... 4

プラグイン・アーキテクチャ... 4

クローラ・プラグイン... 4

識別プラグイン... 4

認可プラグイン... 5

ディレクトリにおけるセキュリティの実現 ... 5

SESに対するセキュア・モードの選択 ... 6

OIDおよびシングルサインオンの使用... 6

複合ディレクトリの使用... 7

セキュアな検索結果の実現... 7

オプション 1 − チェックなし... 8

オプション 2 − Query Time Authorization... 8

オプション 3 − ACLチェック... 9

オプション 4 − ACLのチェックとQuery Time Authorizationの組合せ .. 10

セキュアなクロール・オプション... 10

Service-to-Service認証 ... 13

Self Service認証 ... 13

カスタム・クローラ・プラグインAPI... 14

フェデレート検索... 15

セキュアな検索索引の実現... 15

検索可能なソース ... 16

結論 ... 17

(3)

Oracle Secure Enterprise Search を

使用したセキュアな検索

概要

企業の検索エンジンは、様々なソースの文書を処理できて初めて、便利になります。これらの文書やソースの多くは保護されており、認可されたユーザーのみが利用できます。ここでは、このような保護されたソースを Oracle Secure Enterprise Search がどのように処理するのかを説明します。

はじめに

Oracle Secure Enterprise Search（SES）は、キーワードまたはコンテキストによって企業のイントラネット内の情報を検索できる製品です。検索するためには、最初に様々なソースからコンテンツを収集してテキスト索引を作成する必要があります。この情報の収集プロセスは、クロールと呼ばれ、クローラによって実行されます。クロールされた情報は索引付けされ、ユーザーはクエリー・アプリケーションを介してその索引にアクセスします。

保護されたソース

組織の中には、パブリックにアクセスできる情報があります。その情報はすべての人が参照できるため、クロールして情報を検出し索引付けすることは比較的簡単です。一方、保護されたソースも多数あります。その場合、データまたはデータの一部にアクセスできるのは、特定のユーザーまたはユーザー・グループ（金融部門など）のみです。わかりやすい例としては電子メール・システムがあります。ほとんどの組織では、ユーザーの電子メールは、その個人にとってプライベートなものと考えます。すべてのユーザーは自身の電子メールを検索したいと考えますが、誰もが（他人のものも含めて）全員の電子メールにアクセスし検索したいとは考えていません。

(4)

セキュアなクロール、セキュアな検索結果

ここに 2 つの課題があります。最初の課題は、クローラ自身が保護されたソースにアクセスできるようにすることです。このためには、クローラ自身を何らかの方法で認可し、ソースに対するアクセス権を得る必要があります。具体的には、ソース自身によって信頼してもらうか、またはソースに対する何らかの資格証明によって自身が正規のユーザーであることを証明します。これらのオプションについては、後で詳しく説明します。 2 つ目は、検索結果を許可された人だけが表示できるよう制限することです。そのためには複数の方法がありますが、それぞれ利点と欠点があります。

プラグイン・アーキテクチャ

プライベートな情報のセキュアなクロールおよびアクセスを実装するために、 Oracle Secure Enterprise Search バージョン 10.1.8 では、包括的なプラグイン・アーキテクチャを導入しました。これにより開発者は、アクセス機能を開発するデータストアの特性に合わせて、重要なセキュリティ・コンポーネントを作成することができます。製品のプレインストール・パーツとして多くのプラグインがあります。サードパーティによって記述されているものもあります。顧客の中には、特定のデータストアに対して自身のプラグインを開発したいと考える人もいます。

次に、Oracle Secure Enterprise Search で使用するプラグインのタイプを概説します。

クローラ・プラグイン

これは、標準のデータ・ソースでサポートされていないタイプのデータ・ソースから文書を取得するために設計されたクローラです。このクローラは、文書とともに、アクセス・コントロール（AC）情報（基本的には、各文書に対するアクセス権を持ったユーザーまたはグループのリスト）をフェッチします。AC 情報が提供されていない場合、ヒットリストが作成されたときにアクセス情報をチェックする Query Time Authorization を使用しない限り、データは、すべての文書に適用されるソースレベルの ACL により保護されるか、またはパブリックになります。

識別プラグイン

識別プラグインは、ユーザーとグループに関係します。このプラグインは主に次のタスクを実行します。 • ユーザーとパスワードをペアで承認することによって、ログイン時にユーザーを認証する。 • 指定されたユーザーについてグループ（またはロール）のリストを提供する。 • 指定されたユーザーが存在するかどうかを示す。

(5)

認可プラグイン

認可プラグインには、次の 2 つのコンポーネントのいずれか、または両方を含めることができます。クエリー・フィルタ・プラグインクエリー・フィルタ・プラグインは、現在ログインしているユーザーに関するセキュリティ属性のリストを取得します。つまり、通常、そのユーザーがメンバーとして含まれているグループ（またはセキュリティ・ロール）のリストが返されます。結果フィルタ・プラグイン

結果フィルタ・プラグインは、Query Time Authorization（QTA）を実装しています。このフィルタは、ヒットリストの生成中に文書ごとにコールされ、そのユーザーがこの文書を表示する権限を持っているかどうかをクエリー・エンジンに通知します。Oracle Secure Enterprise Search 10.1.8 では、QTA の実装に適した方法として、QueryTimeFilter の代わりに ResultFilter を使用しています。

ディレクトリにおけるセキュリティの実現

Oracle Secure Enterprise Search をセキュア・モードで使用する前に、識別プラグインに接続する必要があります。

Oracle Secure Enterprise Search には、多数の標準のディレクトリ・タイプ（および特定のアプリケーションのための特別な識別プラグイン）が付随しています。 Admin 画面の中には、次のディレクトリに対するプラグインがあり、あらかじめ登録されています。

• Oracle Internet Directory（OID） • Microsoft Active Directory（AD）

また、次のディレクトリに対するコネクタもありますが、登録はされていません。 • iPlanet • OpenLDAP • 標準の LDAP 登録されていないコネクタは、対象となる使用可能なディレクトリのすべてのバージョンに対してテストされず、そのままの状態で提供されます。また、次のアプリケーション特有のプラグインが付随しており、登録されています。 • Documentum

• FileNet Image Services • Livelink Content Services • Oracle E-Business Suite 11i • Siebel 8

(6)

SES に対するセキュア・モードの選択

識別プラグインに SES を接続すると、セキュアな検索に対するモードを選択できます。Admin 画面で、「Search」→「Query Configuration」→「Secure Search Configuration」と選択します。「Require login for secure content only」を選択して、ログインせずにパブリックな情報を検索すること、または「Require login for public and secure content」を選択して、ログインしなければパブリックな検索実行ができないようにすることができます。この構成は、以前のバージョンでは、SQL*Plus ツールを使用していました。

OID およびシングルサインオンの使用

OID 識別プラグインを使用すると、ユーザーはフォームベースのログインを通じてログインすること、また OID と連携して Oracle Application Server（AS）で提供されるシングルサインオン（SSO）の機能でログインすることもできます。SSO を使用するには、追加の構成手順が必要です。これについては、『Oracle Secure Enterprise Search管理者ガイド』の「セキュア検索の有効化」で説明しています。 SSO を使用できるように SES を構成すると、一度のログインだけでシームレスに検索を実行して、その結果が含まれているリポジトリにジャンプすることができます。 SSO モードでは、検索アプリケーションに対するすべてのコールは AS を介して渡されます。AS は、次にクライアントの SSO 認証をチェックします。ユーザーが SSO にすでにログインしている場合、AS は、セキュアな HTTP 接続を介して SES に接続し、クライアントに対する通信を再ルートします。ユーザーがログイ

(7)

ンしておらず、かつ認証が必須の場合、AS はクライアントを SSO ログイン・ページへ渡します。クライアントが認証されると、SES に対して前述の場合と同様に通信が再ルートされます。このモードでは、SES は AS と通信するだけであり、クライアントは SSO ログインをバイパスして検索に直接アクセスできません。認証されていない検索が許可された場合、ユーザーはログインを選択するまで検索アプリケーションに直接ルートされます。

注意: Oracle Internet Directory および Single Sign-On は Oracle Application Server のコ

ンポーネントです。Oracle Application Server は、SES とは別にライセンスを取得してインストールする必要があります。

複合ディレクトリの使用

データの一部が OID で保護され、別の部分が Microsoft Active Directory(AD)で保護されている場合は、どうすればよいのでしょうか。SES で指定できるのは、1 つの識別プラグインのみです。この場合、次の 2 つの方法が考えられます。 1. SES のフェデレーション機能を使用して、SES を 2 つ（またはそれ以上）インストールし、それぞれを特定の識別プラグインに割り当てます。 2. ディレクトリとして OID を選択し、OID と他のすべてのディレクトリを確実に同期化します。OID と他のディレクトリとの同期化については、このホワイト・ペーパーでは対象外です。詳細は OID のドキュメントを参照してください。AD に接続する場合、AD のユーザー名が OID のユーザー名と同じならプロセスは比較的簡単です。

これらのソリューションのいずれかを機能させるために、各識別システムの属性に対して共通した値があります。たとえば、OID および AD を使用している場合、 AD の BUSINESS_EMAIL と同じ情報を OID の GLOBAL_UID に定義する必要がありますが、値が一致していれば、属性名は同じある必要はありません。これらの値は、属性間でマッピングが指定されていればユーザーを識別できるため、両方のディレクトリで使用するログイン属性である必要はありません。フェデレーションを使用している場合、ユーザーは最初に 1 つの SES インスタンスに対して認証され、この認証が他の SES インスタンスおよび他の識別プラグインに対しても有効であると仮定されます。フェデレーションはセキュアであるうえ、両方の SES インスタンスに対して admin 権限を持ったユーザーのみが設定できるため、このプロセスはセキュアです。ただし、admin ユーザーは、2 つの識別プラグイン間で権利または権限が変わるセキュアでない接続も作成できるため、この設定には注意が必要です。

セキュアな検索結果の実現

次に、文書の表示が許可されたユーザーを識別する検索のための 3 つのメカニズムを説明します。

(8)

オプション 1 − チェックなし

最も簡単な方法は、文書がパブリックまたはアンセキュアな場合に適用するもので、すべてのクエリーでチェックする必要がないことです。結果の一覧およびオリジナルの文書に対するポインタ（通常は URL）の一覧が表示されます。このアプローチでは、その文書を提供するアプリケーションによって文書が保護されている場合、ユーザーはヒットリストの中で文書を表示することはできますが、リンク上で文書をクリックしてもリンクが失敗するか、またはこの文書の表示は許可されていない、というメッセージが表示されます。このアプローチにはメリットがあります。まず、シンプルです。SES はセキュリティをチェックする必要はなく、検索するユーザーは検索前にログインする必要はありません。 2 つ目のメリットは、場合により検索で認証されていない結果が表示されることです。たとえば、サブスクライバのみを対象としたコンテンツの新しいニュースがあるとします。これらの文書はヒットリストで表示できますが、実際に表示しようとするとプロンプトが表示され、ユーザーはサブスクライブできません。または、対象となるコンテンツに対して警告を表示してから、表示できる権限を適用することもできます。ただし、このアプローチは、高度なセキュリティが設定されている場合には適していません。ある検索語が含まれている文書が存在することを調べるだけで、機密保持のモデルに違反してしまいます。また、ユーザーは、この検索の精度を高めていくと、その文書についてさらに多くのことを発見できます。このモデルでは、文書のキャッシングをローカルに行うことはできません。それ以外、ユーザーは、文書のキャッシュ・バージョンを表示して、セキュリティをバイパスできます。これは、Administration ツールの「Global Settings / Configuration」で「Clear Cache After Indexing」を「Yes」に設定することで実行できます（注意: グ

ローバルな設定であるため、これはすべてのソースに適用されます）。

オプション 2 − Query Time Authorization

Oracle Secure Enterprise Search 10.1.8 における Query time authorization（QTA）は、認可プラグインの一部である結果フィルタ・プラグインで処理されます。このモデルでは、クエリー自身にはセキュリティ制限を一切適用しません。ただし、ヒットリストを作成する際、ユーザーにヒットリストを表示する前に結果フィルタ・プラグインをコールして、対象ユーザーが各文書に対するアクセス権限を持っているかどうかを順次チェックします。Java クラスは通常、オリジナルのアプリケーションでいくつかの関数をコールし、権限をチェックします。権限の

(9)

チェックが成功すると、文書がヒットリストに挿入されます。チェックに失敗すると、ヒットリストから除外されます。この最後のチェックによるメリットは、許可されていない文書が表示されないこと、およびセキュリティ情報が必ず最新であることです。一方、デメリットもあります。特にユーザーの表示権限が文書全体の一部に限定されている場合は、処理が遅くなることがあります。これは、大半のヒットはヒットリストから除外され、10 項目のヒットリストをすべて埋めるには、何千もの文書をチェックすることが必要なためです。このモデルでは、検索アプリケーションは検索を行っているユーザーを認識できないため、ユーザーは必ず、識別プラグインを介してログインすることが求められます。 QTA を単独で使用している（つまり ACL のチェックと組み合せて使用していない）場合は、「Hit Count Method」を「Exact count (adjusted for query-time filtering)」に設定することをお薦めします。さもないと、ヒットカウントが多すぎることがあります。

オプション 3 − ACL チェック

このモデルでは、索引付けする各文書とともにアクセス情報を格納します。これは通常、各文書に対して Access Control List（ACL）を格納することによって実現します。ACL（エーシーエルともアクェルとも発音される）は XML のフラグメントで、文書に対してアクセス権限を持ったユーザーまたはユーザー・グループを記述します。アクセスには、文書を読取り、書込み、または削除できる権限が含まれていますが、ここでは読取りアクセスのみを説明します。 ACL はデータ・ソース全体に適用することができます。つまり、特定のデータ・ソース内のすべての文書に同じ ACL を定義することができます。これはソースレベルACL と呼ばれます。また、ソースでクロールするときに、各文書に対して ACL を提供することもできます。これは文書レベルACL と呼ばれます。文書レベ ル ACL は、クローラ・プラグインによって、特定のビルトイン・クローラに対して提供されます。一般的に ACL チェックは高速です。このチェックは、クエリー自身の一部として含めることができるため、文書ごとのチェックに比べはるかに効率的です。ただし、この方法では、クロール時にのみ格納されるというデメリットがあります。最後のクロール以降に文書に対するアクセス権限が変わった場合は変更が反映されず、権限がどのように変わったかによって誤ったヒットが提示されたり、または文書が見つからないことがあります。現行のアクセス制御は文書のソースによって実現されますが、文書のキャッシュ・バージョンが有効な場合、ユーザーはそのキャッシュを表示きるため、誤ったヒットが提示されるとユーザーは通常、元の文書にアクセスできません。 ACL で保護されたソースを使用する場合、クエリー・フィルタ・プラグインを提供する必要があります。このプラグインは、使用中の識別プラグインから使用できない ACL でセキュリティ属性を使用している場合に使用されます。たとえば、ソースでは Oracle Internet Directory を認証ディレクトリとして使用できますが、 OID とはまったく別のグループまたはロールのコンセプトを持つことができます。

(10)

このケースでは、グループが ACL に格納されている場合、SES はクエリー・フィルタ・プラグインをコールして、現在ログインしているユーザーのグループ・リストを取得することが必要です。

オプション 4 − ACL のチェックと Query Time Authorization の組合せ

オプション 2 と 3 は組み合せることができます。つまり、ACL を使用し、ヒットリストを妥当な大きさのサイズにするためにプレフィルタしてから各ヒットを元のソースと比べてチェックし、対象のユーザーがこれらの文書にアクセスできることを確認します。これにより、オプション 2 のパフォーマンスが改善され、ACL の制限が強化された場合には、誤ったヒットが回避されます。ただし、ACL の制限が緩くなると、ヒットした文書が見つからないという状況が発生します。一般的には、偽陰性であることはセキュリティ・リスクではないため、このオプションが最もセキュアです。たとえば、ある文書管理システムで何千人ものユーザーを管理しており、各ユーザーは自身が参照できる少量の文書セットを保持しているとします。Query Time Authorization によってこれらの文書をすべて実行すると、通常、検索の結果として提示された文書の 99.9%を除外する必要があります。ソースから ACL を適用すると、検索ユーザーが表示できる少量の文書セットが、検索の対象として正しく使用されます。QTA をセカンダリ・フィルタとして使用し、クロールの発生以降に制限されている文書（文書が誤まってパブリックになり、後で制限されたもの）がユーザーに表示されないようにします。注意: 追加の文書に対してユーザーがアクセスを許可されていても、次のクロー ルが実行されるまで、これらの文書は検索することはできません。

セキュアなクロール・オプション

これまでに説明した検索結果の表示前に、検索エンジンは、検索する様々なソースをクロールして索引を作成する必要があります。クロールをセキュアに実装するには、様々な方法があります。Oracle Secure Enterprise Search Crawler は、適切なデータ・ソースにアクセスできるようにするために認証が必要です。データ・ソースでクローラなどの外部エージェントを拒否する場合、これらを検索できません。データ・ソースで、すべての外部エージェントがコンテンツにアクセスすることが許可されている場合、これらのコンテンツはセキュアではありません。したがって、クローラの認証では、セキュリティに影響を与えずにコンテンツを検索できることが重要です。次に、いくつかの認証方法を説明します。 1. Admin ベースの認証 2. Service-to-Service 認証 3. Self-Service 認証 4. カスタム・クローラ 5. フェデレート検索 6. パブリック情報

(11)

オプション 5 にはクローラが含まれていません。これは、検索に対する責任（したがって、セキュリティの全局面）が、データ・ソース・アプリケーションに渡されるためです。

Admin ベースの認証

これは、最も簡単なクローラ認証です。このシナリオでは、SES の管理者がデータ・ソースを定義し、そのデータ・ソース内で認可に対して使用するログイン資格証明を指定します。実際の認証方法は、データ・ソースのタイプによって異なります。たとえば、電子メールのデータ・ソースを定義した場合、索引付けしたい IMAP ユーザーの電子メールに対して、ユーザー名とパスワードが認証されます（後述しますが、電子メールの場合には通常、Self Service 認証が適しています）。 Web データ・ソースに対する認証を提供する場合、admin ベースの認証を提供するには次の 3 つの方法があります。 • HTTP 基本認証 • Form ベースの認証 • Oracle Single Sign-On 認証 HTTP 基本認証 HTTP 基本認証は、HTTP プロトコルに組み込まれている標準的な認証方法です。資格証明に対するプロンプトは通常、ユーザーのブラウザによって実行され（一般的に、ユーザー名とパスワード・ボックスがポップアップで表示されます）、資格証明は、サーバーを介してパラメータとして各 HTTP コールに渡されます。 Form ベースの認証 Form ベースの認証は、Web デザイナがログイン・エクスペリエンスをカスタマイズできる範囲が広く、HTTP 基本認証の簡素なログイン・プロンプトよりフレンドリーな感じがするため、商業用の Web サイトで広範に使用されています。ただし、ログイン・フォームで提供されるタイプやレイアウトが多様なため、SES クローラによるログイン実行方法の指定が複雑です。簡単な HTTP フォームでは、 SES はウィザードを提供し、これによってログイン時に対象の Web ページを監視し、クロール時にログインで必要な情報を収集します。より複雑な（Javascript ベースの）フォームの場合は、admin ユーザーが必要な情報を手動で提供する必要があります。

(12)

Single Sign-On 認証

アプリケーションが Oracle Single Sign-On によって保護されている場合、admin ユーザーに必要なものは簡単なログインとパスワードだけです。 1 つのデータ・ソースには複数の保護されたエリアが含まれ、各エリアが独自のログイン・ディティールを使用している可能性があります。基本認証の場合、資格証明のセットに対してドメインとレルムを指定することができます。また、複数のフォームを定義することにより、クローラが指定されたフォームを検出したときに、提供されたログイン・ディティールを使用することができます。Oracle Single Sign-On の性質上、1 つの資格証明のみが提供され、この証明が SSO で保護されたすべてのサイトに適用されます。サイトによっては、別の SSO 資格証明が提供される場合、その索引付けを別のデータ・ソースから行う必要があります。通常、admin ベースの認証では、管理者は複数のユーザーやユーザー・グループに対して複数のデータ・ソースを設定する必要があります。そのため、管理者は、責任とはセキュリティ・ポリシーを強制するだけではなく、それを定義することとみなします。これらの複数のデータ・ソースは、必要に応じて、SES のスケジューリング・メカニズムを介して組み合せることができるため、すべて一緒にクロールすることができます。

(13)

ユーザー名とパスワードのストレージ通常、admin インタフェースを介して提供されるユーザー名とパスワードは、SES エンジンに埋め込まれた Oracle データベース内のデジタルな wallet にセキュアな暗号化された形式で格納されます。いったん格納されると、これらの資格証明を何度も使用して、任意のスケジュールでデータ・ソースをクロールすることができます。ログインの資格証明を長期にわたって格納する場合、ローカルなセキュリティ・ポリシーが無効になることがあります。その場合には、「Delete Passwords After Crawl」のオプションを使用できます。このオプションでは、データ・ソースに対する定期的な自動スケジューリングが無効になります。スケジュールは admin インタフェースから手動で開始し、起動時にパスワードを入力する必要があります。パスワードは、クロールの期間、Oracle Secure Enteprise Search に一時的に保存されます。

Service-to-Service 認証

service-to-service（S2S）認証では、データ・ソースは SES クローラを信頼されて いるアプリケーションとして扱います。つまり、SES が ACL を強制的に実行し、認可されていないユーザーが情報にアクセスできないようにするという条件で、クローラに対し必要なすべての情報が ACL とともに提供されます。

S2S クローラを実装するには、データ・プロバイダが Access Manager Authentication Web Service（Sun Microsystems が定義および所有するプロトコルで、様々なプラットフォームで利用できる）をサポートしていることが必須です。

頭字語で実行するためには、Simple Authentication and Security Layer（SASL）を使用して、Simple Object Application Protocol（SOAP）トランスポート・レイヤーに対して認証サポートを追加します。詳細は、次のサイト（英語）を参照してください。 http://docs.sun.com/source/817-7648/authn_web.html

Self Service 認証

前述の Admin ベースの認証では、管理ユーザーは、すべてのアクセス資格証明について認識しこれを提供する必要があります。これは、しばしば現実的ではありません。Self Service 認証では、データの所有者のみがこれらの資格証明を認識することが必要です。 Self Service 認証には、2 つまたは 3 つのステップ・プロセスがあります。 1. admin ユーザーがテンプレートのデータ・ソース（情報のタイプの定義、情報の場所など）を作成します。 2. 一般ユーザーは SES のクエリー・アプリケーションへログインし、 SelfService オプションを選択します。使用できるテンプレート・データ・ソースのリストが表示されます。ソースまたはクロールするソースを選択し、入力フォームで自身のログイン資格証明を入力します。これらの資格証明は、セキュアな wallet 内で SES の埋込みデータベースに暗号化されて格納されます。

(14)

3. このユーザーのクロールに対してスケジュールを作成しますが、まだ開始されません。スケジュールをすぐに開始すると、ピーク時に多数のユーザーがソースの索引付けを開始する、というリスクが発生します。その代わり、管理者は、新しく作成されたスケジュールを適当な時間に開始します。

Self service 認証は、admin ベースの認証または service to service 認証を提供していないデータ・ソースにとっても有用です。これは、IMAP サーバーおよび外部の Web サイトにも関連します。

カスタム・クローラ・プラグイン API

カスタム・クローラを Java で記述して SES で提供する標準のクローラ・タイプでは、クロールされないリソースに対してアクセスすることができます。カスタム・クローラ・プラグインは、索引付けエンジンに対して文書を返します。各文書には、特定の文書にアクセスできるユーザーを特定するための ACL を付加できます。また、admin 画面を介してデータ・ソース全体について ACL を設定することもできます。必要に応じ、admin 画面から渡されたパラメータを介して、認証の資格証明をプラグインに提供することができます。プラグインは、これらの資格証明を使用してセキュアなソースにアクセスします。

セキュアなクローラ・プラグインの例は、Oracle の Secure Enterprise Search の Web サイトで参照できます。これは柔軟なデータベース・クローラで、データベースのカラムから ACL をフェッチできるため、表のデータで行レベルの検索セキュリティを潜在的に提供します。また、セキュアなファイル・クローラの簡単な例を紹介した「Building Custom Crawlers for Oracle Secure Enterprise Search」（英語）も参照してください。

(15)

フェデレート検索

SES は「フェデレート検索」モデルもサポートしています。この検索では、検索の一部またはすべてが外部のエンティティによって実行されます。このエンティティは、もうひとつの SES インスタンスにすること、また完全に別のアプリケーションにすることもできます。セキュアな検索に関しては、別のアプリケーションを使用する方法が最も有効です。たとえば、電子メール・システム（Oracle Collaboration Suite（OCS）Email など）には、独自のテキスト索引を含むことがあります。この場合、SES で電子メールデータをクロールせずに、OCS で検索ができます。クエリーは、ユーザーがローカルに実行するときではなく入力したときに、実行のために OCS に渡されて結果が収集されます。結果は、同時に検索された他のデータ・ソースの結果とマージされ、通常の SES ヒットリストの形式で表示されます。フェデレート検索には次のようなメリットがあります。 1. クロールが不要なため、SES システムにおけるリソースおよびスペースが解放されます。 2. ターゲット・システムの検索特性によって、検索で最新の文書および変更された文書が反映される確率が高くなります。通常の SES では、最後のクロールのときに最新である索引のみを検索しますが、システムによっては、リアルタイムの索引更新機能があります。 3. ユーザーの資格証明は wallet にローカルに格納する必要はありません。セキュリティはターゲット・アプリケーションで処理され、ログイン・ユーザーが表示できるヒットを返します。一方、ネットワーク・トラフィックが増加するためパフォーマンスが低下し、ターゲット・マシンで検索のパフォーマンスが低下する、というデメリットがあります。

セキュアな検索索引の実現

セキュアなソースの ACL 情報が含まれているため、検索の索引は、セキュアなソースよりもセキュアで信頼性が高くなります。SES は、検索の索引をセキュアではないディスク上のファイルではなく、SES に埋め込まれた（特に堅牢な）データベース内に格納します。このデータベースは、外部アクセスで利用できません。この方法で Oracle データベースを利用すると、開発作業の時間面でメリットが得られます。SES には次の特徴があります。 • Unbreakable − SES は、他のベンダーより強力なセキュリティ証明を備えた厳重な Oracle 10g プラットフォーム上に構築されます。 • 完全なグローバル化 − Unicode および他のすべてのデータベース・キャラクタ・セットがサポートされ、文書は 100 ヶ国語以上の言語でサポートされています。

(16)

• 複数のプラットフォームで利用可能 − Windows、Linux をはじめ多数の UNIX プラットフォームで利用できます。 • 優れた拡張性とパフォーマンス − 顧客の実際の実装において、テラバイトの情報処理で定評のある Oracle Text エンジン上に構築されます。

検索可能なソース

SES はすべてのソースをセキュアに検索することができます。検索可能なリポジトリには次があります。 • Web Server で提供される HTML ページ • データベース表 − Oracle データベースの検索。フルテキストのカラムとフィールドのカラムを両方クロールできます。 • ファイル − file://プロトコルによってローカルまたはリモートのファイルを検索できます。 • 電子メール − IMAP プロトコルを介して電子メールおよびメーリング・リストをクロールできます。

• Oracle Application Server 10g Portal リポジトリ − プライベートおよびパブリックな Portal ページ、フォルダ、サブフォルダおよびテキスト・アイテムなど

• ダウンロードした電子メール、ローカル・ストレージ上のファイル、以前に表示した Web ページなどをローカルに検索するためにオプションで構成できる、Google Desktop for Enterprise などのデスクトップ検索エンジンとの統合によるデスクトップ・コンテンツ

• 他のソース − Secure Crawler Plug-in SDK を使用すると、クローラをカスタマイズして他のリポジトリにアクセスできます。

すべてのタイプのソースに対して、すべての認可タイプ（検索のセキュリティ）および認証（クローラ・ログイン）機能が適しているわけではありません。たとえば、Form ログインは Web ソースのみに適している一方、文書ごとの ACL（Source ACL）は、各文書に対して実際にアクセス権を割り当てるため、ソースでのみ提供できます。

(17)

認可認証ソース・タイプソース ACL 提供される AC L QTA Form ログイン SSO S elf S erv ice Sour ce ログイン S ervic e to S ervi ce Web X X X 表 X X ファイル X 電子メール X X X メーリング・リスト X X X Portal X X Oracle Content Database X X Calendar X X NTFS X X Exchange X X Apps X X フェデレート X X X X カスタム X X X X

結論

保護されたソースを索引付けできなければ、エンタープライズな検索エンジンであるとは言えません。Oracle Secure Enterprise Search は、様々なテクニックを提供して、多くのアプリケーションおよびセキュリティ要件に対応します。

(18)

Oracle Secure Enterprise Search を使用したセキュアな検索 2007 年 1 月

著者: Roger Ford

寄稿者: Meeten Bhavsar、Thomas Chang、Muralidhar Krishnaprasad

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com この文書はあくまで参考資料であり、契約または協定には含まれていないことがあります。 Oracle はオラクル社の登録商標です。このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標です。その他のすべての製品名およびサービス名は、各社の商標です。