Oracle Secure Enterprise Search 10g を
使用したセキュアな検索
オラクル・ホワイト・ペーパー
Oracle Secure Enterprise Search 10g を
使用したセキュアな検索
概要 ... 3
はじめに ... 3
保護されたソース... 3
セキュアなクローリング、セキュアな検索結果... 4
Oracle Internet Directoryを使用してセキュリティを有効化... 4
Microsoft Active Directoryとの同期... 5
検索結果の保証... 5
オプション 1 − チェックなし ... 5
オプション 2 − 問合せ時間の認可 ... 6
オプション 3 − ACLチェック ... 6
オプション 4 − ACLチェックと問合せ時間の認可の組合せ... 7
セキュアなクロール・オプション ... 7
Adminベースの認証 ... 8
基本認証 ... 8
Formベース認証 ... 8
Single Sign On認証... 9
ユーザー名およびパスワードの格納 ... 9
サービス間認証 ... 10
セルフサービス認証 ... 10
カスタム・クローラ・プラグインAPI ... 11
連携検索 ... 11
検索索引の保証 ... 12
検索可能なソース ... 12
結論 ... 14
Oracle Secure Enterprise Search 10g を
使用したセキュアな検索
概要
企業情報検索エンジンが便利なツールであるためには、多様なソースのドキュメ ントを処理できる必要があります。これらのドキュメントとソースの多くは保護 され、権限が付与されたユーザーのみ使用が許可されます。このような保護され たソースを Oracle Secure Enterprise Search がどのように処理するか説明します。はじめに
Oracle Secure Enterprise Search（SES）は、キーワード検索またはコンテキスト検索 によって企業イントラネット内の情報を検出できます。 そのためには、まず多様なソースからコンテンツを回収しテキスト索引を行いま す。 この情報回収プロセスはクローリングとして知られ、クローラによって実行され ます。 このドキュメントでは、クローラがネットワーク上のコンテンツにセキュアにア クセスする様々な方法と、そのコンテンツに無許可のユーザーがアクセスするの を Oracle SES がどのように防止するかを紹介します。
保護されたソース
企業内の一部の情報は、公にアクセス可能です。誰でも表示できるため、クロー ラは非常に簡単にこれらの情報を検出し索引付けします。 しかし、セキュリティで保護されたソースも多数あります。あるユーザーまたは ユーザー・グループ（財務部門など）のみが、データまたはその一部にアクセス できる場合などです。 明快な例としては、電子メール・システムがあります。多くの企業では、ユーザー の電子メールは各人のプライベートなものと考えられています。どのユーザーも 自身が所有する電子メールを検索できることが必要ですが、誰もがすべてのユー ザーの電子メールまたは他人の電子メールに入り込んで検索できることを望んで いません。セキュアなクローリング、セキュアな検索結果
課題が 2 つあります。まず、クローラが、保護されたソースにアクセス可能であ る必要があります。通常のユーザーのように、ソース自体によって信頼されるか ソースに対して一種の資格証明を提示するなど、ソースのアクセス権を取得する なんらかの方法でクローラに権限を付与する必要があります。これらのオプショ ンについては、後で詳細に説明します。 次に、権限を持つ者のみが、検索結果を表示できるように制限する必要がありま す。そのための方法はいくつかありますが、それぞれメリットとデメリットがあ ります。Oracle Internet Directory を使用してセキュリティを有効化
Oracle Secure Enterprise Search をセキュア・モードで使用するまでは、Oracle Internet Directory（OID）のインスタンスにリンクする必要があります。
まず、OID にリンク後、セキュアでないモードで検索するか、Oracle SES のフォー ムベースのログイン画面からログインするかを選択します。
フォームベースのログインではなく、OID と連動して Oracle Application Server （AS）から提供される Single Sign-On（SSO）機能を選択します。この選択では、 『Oracle Secure Enterprise Search管理者ガイド』の「セキュア検索の有効化」の項
にある追加の構成手順を実行する必要があります。
Oracle SES で SSO を使用する構成の場合、一度のログインだけで検索をシームレ スに実行して、検索結果を含むリポジトリにジャンプできます。
SSO は、検索の実行前にユーザー認証が必要となる構成、または認証されていな いユーザーは公開ソースを検索できるがログインした場合のみプライベート・ ソースを使用できる構成ができます。 SSO モードでは、検索アプリケーションに対するすべてのコールは、Oracle AS を 介して渡されます。AS は、クライアントの SSO 認証をチェックします。ユーザー がすでに SSO にログインしている場合、AS はセキュアな HTTP 接続を介して Oracle SES に接続し、通信をそのクライアントに再ルートします。ログインせず に認証が必要な場合は、クライアントを SSO ログイン・ページに渡し、認証後、 前述のように通信を Oracle SES に再ルートします。このモードでは、SES は AS のみで通信するため、クライアントは SSO ログインをバイパスして、直接検索に アクセスすることはできません。認可されていない検索が許可されている場合は、 ログインを選択するまで検索アプリケーション・ナビゲータに直接ルートされま す。
注意: Oracle Internet Directory と Single Sign-On は、Oracle Application Server のコン ポーネントです。Oracle Application Server にはライセンスが必要で、Oracle SES とは別にインストールする必要があります。
Microsoft Active Directory との同期
オラクル社の Directory Integration and Provisioning プラットフォームを使用するこ とにより、Microsoft 社の Active Directory など、他の LDAP ディレクトリを OID と同期させることができます。したがって、企業ディレクトリ標準が Microsoft Active Directory でも、SES の Single Sign-On 機能を活用できます。
検索結果の保証
次に、ドキュメントの表示権限を持つユーザーを特定する、3 つの検索メカニズ ムを説明します。オプション 1 − チェックなし
この最もシンプルな方法は、ドキュメントが公開されているなどセキュアでない 場合に適用でき、問合せ時のチェックについて難しいことは一切ありません。結 果のリストは、オリジナルのドキュメントのポインタ（通常は URL）のリストと ともに表示されます。このアプローチでは、ドキュメントがそのドキュメントを 提供するアプリケーションによって保護されている場合、ヒットリストに表示さ れます。しかし、リンクをクリックした場合は、接続が失敗するか、またはその ドキュメントを表示する権限が付与されていないというメッセージが表示されま す。 このアプローチには、次のようなメリットがあります。第一は、簡単なことです。 Oracle SES はセキュリティ・チェックがまったく必要なく、検索の実行前にログ イン・ユーザーの検索も必要ありません。 第二は、認可されていない結果を表示するために検索する場合でも、実質的には 許可されることです。例として、いくつかのサブスクライバ・コンテンツを持つ ニュース・ソースを考えてみます。これらのドキュメントをヒットリストに表示 してドキュメントを表示する場合、ユーザーに対しサブスクライブの指示を要求します。あるいは、コンテンツの表示には場合により許可が必要であることを知 らせる警告を表示します。 しかし、このアプローチは、高度な安全対策が施された状況では許可されません。 ドキュメントに特定の検索語が存在することを知っているだけで、機密保護モデ ルに違反する恐れがあります。また、慎重に検索を絞り込むことにより、問題の ドキュメントの詳細を見つけることができる可能性があります。 このモデルでは、ドキュメントのキャッシングを無効化することが重要になりま す。無効化しない場合は、ドキュメントのキャッシュ・バージョンの表示のみを 行って、セキュリティを回避できます。これを実行するには、管理ツールから、 「グローバル設定 / クローラ構成」に進み「索引付け後にキャッシュを消去」で 「はい」を設定します（注意: この設定は、グローバル設定としてすべてのソース に適用されます）。
オプション 2 − 問合せ時の認可
このモデルでは、問合せにセキュリティ制限を適用しませんが、ヒットリストを 作成してユーザーに表示する前にカスタム Java クラスをコールして、ユーザーに 各ドキュメントへのアクセス権があるかをチェックします。Java クラスは一般に、 オリジナルのアプリケーションで機能をコールして、アクセス権の有無をチェッ クします。アクセス権のチェックが成功した場合、そのドキュメントをヒットリ ストに入れ、失敗した場合は入れません。 この最後の瞬間にチェックを行うメリットは、認可されていないドキュメントを まったく表示せずに最新のセキュリティ情報を確実に維持できることです。 デメリットは速度の低下です。特に、ユーザーがすべてのドキュメントの小型の サブセットのみ表示を許可されている場合には、ほとんどのヒットをヒットリス トから取り除く必要があるため、遅くなる可能性があります。10 項目のヒットリ ストを満たすドキュメントを検出するためには、何千ものドキュメントをチェッ クする必要があります。 ユーザーは、常に、このモデルの OID を介したログインが要求されます。これは、 検索アプリケーションには、検索を実行しているユーザーを知る方法がないから です。オプション 3 − ACL チェック
このモデルでは、索引付けする各ドキュメントとともにアクセス情報を格納しま す。これは通常、ドキュメントごとに Access Control List（ACL）を格納して実行 されます。ACL（エイシーエルまたはアックルなどと発音します）は、そのドキュ メントにアクセスするユーザーまたはユーザー・グループを記述する XML のフラグメントです。アクセスの目的は読取りのみであるにもかかわらず、アクセス にはドキュメントの読取り、書込みまたは削除の権限が含まれています。 通常、ACL はデータソース全体に適用されます。つまり、特定データソースのす べてのドキュメントが同じ ACL（または ACL セット）を持ちます。しかし、ユー ザー定義のデータソースの場合、データソースはドキュメントレベルの ACL を提 供でき、各ドキュメントは固有の ACL を持ちます。 ACL チェックは一般に高速です。問合せの一部に含めることができるため、ドキュ メントごとのチェックに比べはるかに効果的です。しかし、このチェックには、 クロール時のみに格納されるというデメリットがあるため、ドキュメントのアク セス権が最後のクロールの実行後に変更されても、その変更は反映されず、どの ように変更されたかによって false ヒットとなるか、またはそのドキュメントが見 つかりません。false ヒットの場合、通常、現在のアクセス制御がドキュメント・ ソースによって実行されるため、オリジナルのドキュメントにアクセスできませ ん。ドキュメントのキャッシュ・バージョンが使用できる場合は、そのドキュメ ントを表示できます。
オプション 4 − ACL チェックと問合せ時間の認可の組合せ
オプション 2 と 3 を組み合せることで、ACL を使用してフィルタを事前に適用し てヒットリストを管理可能なサイズに縮小したり、各ヒットをオリジナル・ソー スと照合してそのユーザーがこれらのドキュメントにアクセス可能かを確認した りすることもできます。この組合せは、オプション 2 の場合よりパフォーマンス が向上し、ACL の制限が厳しい場合は false ヒットを防止します。ただし ACL の 制限が厳しくない場合、依然としてヒットは見つからない可能性があります。一 般に、false の拒絶はセキュリティ・リスクではないため、このオプションは最も 安全です。 ドキュメント管理システムは何千ものユーザーを持ち、各ユーザーに表示可能な 小型のドキュメント・セットがあります。これらのドキュメントすべてを問合せ 時間の認可で実行するには負荷がかかります。通常、検索結果のドキュメントの およそ 99.9%を除去する必要があります。そのため、ACL をソースから適用する ことにより、確実に検索ユーザーが表示できる小型のドキュメント・セットをター ゲットとして検索できます。その後、QTA を 2 次フィルタとして使用できます。 この場合、クロールが実行されたため（おそらく、見落としたことでいくつかの ドキュメントが公開されてしまい、後で制限されたため）、すべてのドキュメン トが表示できなくなります。 注意: ユーザーに追加ドキュメントへのアクセス権が付与されている場合、これ らのドキュメントは、次のクロール実行まで検索できません。セキュアなクロール・オプション
前述のように検索結果の表示前に、検索エンジンでは、検索を要する様々なソー スをクロールして索引を構築する必要がありました。SES には、クロールを安全 に実行する多数の方法が用意されています。Oracle Secure Enterprise Search Crawler では、適切なデータソースへアクセスするために認証が必要です。データソース がクローラなどの外部エージェントを拒否する場合、このデータソースは検索で きません。データソースがすべての外部エージェントにコンテンツへのアクセス を認める場合、データソースはセキュアではありません。そのため、クローラの認証によって、セキュリティを犠牲にせずにコンテンツを検索する方法を実現す ることが重要です。 ここで、いくつかの認証方法を検討します。 1. Admin ベースの認証 2. サービス間認証 3. セルフサービス認証 4. カスタム・クローラ 5. 連携検索 6. 情報公開 オプション 5 では、検索およびセキュリティのすべての面に対する責任はデータ ソース・アプリケーションに渡されるため、クローラは必要ありません。
Admin ベースの認証
これは、最もシンプルなクローラ認証です。このシナリオで、Oracle SES 管理者 は、データソースの定義とデータソースでの認可に使用するログイン資格証明を 指定します。 認証に使用する実際の方法は、データソース型によって決まります。たとえば、 電子メールのデータソースを定義する場合、ユーザー名とパスワードは、索引付 けが必要な電子メールの IMAP ユーザーのユーザー名とパスワードになります （一般に、電子メールではセルフサービス認証の選択をお薦めします。これについ ては後述します）。 Web データソースに対する認証では、Admin ベースの認証を提供する 3 つの方法 があります。 • HTTP 基本認証 • Form ベース認証• Oracle Single Sign On 認証
基本認証
HTTP 基本認証は、HTTP プロトコルに内蔵された標準の認証方法です。資格証明 のプロンプトは、通常、ユーザー・ブラウザ（通常、ユーザー名/パスワード・ボッ クスをポップアップさせて表示します）で実行されます。資格証明は、パラメー タとしてサーバーに、次に各 HTTP コールに渡されます。Form ベース認証
Form ベース認証は、Web デザイナがログイン経験をカスタマイズできる範囲が大 きく、HTTP 基本認証の無味乾燥なログイン・プロンプトより親しみやすいため、 商用 Web サイトでは一般的に使用されています。しかし、ログイン・フォームの 種類やレイアウトが多様化すると、SES クローラがログインの実行方法を指定す るタスクが複雑になります。シンプルな HTTP フォームの場合、Oracle SES はウィ ザードを提供して、ログイン時に問題の Web ページを監視し、クロール時にログ インに必要な情報を回収します。複雑な（または Javascript ベース）フォームの場 合、管理者ユーザーは必要な情報を手動で入力する必要があります。Single Sign On 認証
アプリケーションが Oracle Single Sign-On で保護されている場合、管理者ユーザー には、シンプルなログインとパスワードの入力のみ必要です。
1 つのデータソースは複数の保護された領域を含み、各領域でログイン詳細情報 を使用します。基本認証の場合、資格証明セットにドメインとレルムを指定でき ます。複数のフォームを定義することもできます。クローラは、指定のフォーム を検出した場合、提供されたログイン詳細情報を使用します。Oracle Single Sign-On の性質上、資格証明セットが 1 つだけ提供され、発見された SSO 保護のサイトす べてにそのセットが適用されます。あるサイトに異なる SSO 資格証明の提供が必 要な場合、そのサイトを別のデータソースから索引付けする必要があります。 Admin ベースの認証ではほとんどの場合、管理者は、異なるユーザーまたはユー ザー・グループ、あるいはその両方に複数のデータソースを設定する必要があり ます。したがって、管理者は、セキュリティ・ポリシーの実施だけでなく定義の 責任も負います。これらの複数のデータソースは、必要に応じて、すべてのデー タソースが一緒にクロールされるよう Oracle SES 内のスケジューリング・メカニ ズムを介して結合できます。
ユーザー名およびパスワードの格納
通常、管理者インタフェースから提供されたユーザー名とパスワードは、デジタ ル・ウォレットによりセキュアに暗号化されたフォーマットで、Oracle SES エン ジン内に内蔵された屈強な Oracle データベースに格納されます。一旦格納される と、これらの資格証明は、スケジュールに沿ってデータソースのクロールに何度 も使用されます。ログイン資格証明の長期保存は、ローカル・セキュリティ・ポリシーで認められ ないことがあります。その場合、オプションを使用してクロール後にパスワード を削除することができます。この場合、データソースの自動定期スケジューリン グは無効になります。スケジュールは管理者インタフェースから手動で起動し、 パスワードは起動時に手動で入力する必要があります。パスワードは、クロール 中のみ、一時的に Oracle Secure Enteprise Search に保存されます。
サービス間認証
サービス間（S2S）認証の場合、データソースは、SES クローラを信頼されたアプ
リケーションとして処理します。つまり、Oracle SES が ACL を実行し、許可され
ていないユーザーによる情報へのアクセスを防止することを条件として、アプリ ケーションにより要求されるすべての情報が ACL とともにクローラに提供され ます。
S2S クローラを実行するため、データ・プロバイダは、Access Manager Authentication Web Service（Sun Microsystems 社が定義、所有するプロトコルで、多様なプラッ トフォームで使用可能）をサポートする必要があります。
頭字語で実行するには、Simple Authentication and Security Layer（SASL）を使用し て、認証サポートを Simple Object Application Protocol（SOAP）トランスポート層 に追加します。詳細は次の Web サイトを参照してください。 http://docs.sun.com/source/817-7648/authn_web.html
セルフサービス認証
前述した Admin ベースの認証において、管理者ユーザーはすべてのアクセス資格 証明を知りこれを提供する必要があります。しかし、これは適切でないと判断さ れることがよくあります。セルフサービス認証の場合、この詳細な情報を知って おく必要があるのは、データ所有者のみです。 セルフサービス認証は、次の手順で行います。 1. 管理者ユーザーは、テンプレート・データソース（情報の型、その情報 の場所など）の定義を作成します。 2. 通常のユーザーは、Oracle SES 問合せアプリケーションにログインし、セ ルフサービス・オプションを選択します。使用可能なテンプレート・デー タソースのリストが表示されます。ソースまたはクロールが必要なソー スを選択し、ログイン資格証明を入力フォームに入力します。これらの 資格証明は、セキュアなウォレットによって、Oracle SES に組み込まれた データベースに格納され暗号化されます。 3. スケジュールはこのユーザーのクロール用に作成されますが、まだ起動 されません。スケジュールがすぐに起動された場合、多くのユーザーが ピーク時に索引付けソースを起動する可能性があります。一方、管理者 には新しく作成されたスケジュールを適切な時間に起動する責任があり ます。セルフサービス認証は、Admin ベースの認証またはサービス間認証を提供しない データソースの場合も便利です。IMAP サーバーや外部 Web サイトの場合がこれ に該当します。
カスタム・クローラ・プラグイン API
カスタム・クローラは、Java で書き込むことができ、Oracle SES が提供する標準 クローラのいずれの型でもクロールできないリソースへアクセスを提供します。 カスタム・クローラ・プラグインは、ドキュメントを索引付けエンジンに戻しま す。各ドキュメントに ACL を付随させ、その特定のドキュメントにアクセス可能 なユーザーを制限することができます。また、ACL はデータソース全体の管理者 画面からも設定できます。 必要に応じて認証資格証明をパラメータからプラグインに提供し、管理者画面か ら渡すことができます。プラグインでは、これらの資格証明を使用してセキュア なソースへアクセスします。 セキュアなクローラ・プラグインの例は標準装備で、search/sample/agent/db ディレ クトリに配置されています。これは柔軟性のあるデータベース・クローラです。 ACL をデータベースの列からフェッチできるため、表に保存されたデータの行レ ベルの検索セキュリティを提供できる可能性があります。
連携検索
Oracle SES は、連携検索モデルもサポートします。すなわち、一部またはすべて の検索が外部エンティティによって実行されます。そのエンティティは、別の SES インスタンスの場合もあれば、まったく別のアプリケーションの場合もあります。 セキュアな検索の点からは、別のアプリケーションが最も重要です。たとえば、 電子メール・システム（Oracle Collaboration Suite（OCS）Email）にはテキスト索 引が含まれています。この場合、Oracle SES で電子メール・データをクロールす るのではなく、OCS により検索を実行するよう決定できます。つまり、ユーザー が問合せを入力する場合、それをローカルに実行するのではなく OCS に渡して実 行し、結果を回収します。その結果は、他のデータソースの結果とマージされ、 同時に検索が行われて通常の SES ヒットリストとして表示されます。連携検索には複数のメリットがあります。 1. クロールを必要とせず、Oracle SES システムのリソースとスペースを解放 します。 2. 対象となるシステムの検索特性によって、検索には、最近の新規ドキュ メントと変更ドキュメントが反映される可能性が高くなります。通常の SES 検索では、常に最新のクロールに更新されるのに対して、他のシス テムにはリアルタイムの索引更新機能があります。 3. Wallet でユーザー資格証明をローカル保存する必要がありません。セキュ リティは、対象のアプリケーションによって処理され、ログイン・ユー ザーが表示できるヒットを戻すだけです。 これに対して、SES には、ネットワーク・トラフィックが増加するためにパフォー マンスが低下するというデメリットがあります。また、対象マシンの検索パフォー マンスが低下する可能性もあります。
検索索引の保証
検索索引にはセキュアなソースのコンテンツや ACL 情報が含まれているため、 ソースはよりセキュアで強固である必要があります。Oracle SES では、危険にさ らされる可能性があるディスク上のファイルではなく、SES に組み込まれた特別 強固なデータベースに検索索引を格納します。このデータベースは外部からアク セスできません。 このように Oracle データベースを使用することで、膨大な開発作業から次のよう な Oracle SES のメリットが得られます。 • アンブレーカブル − Oracle SES は、他のベンダーより高いレベルのセ キュリティを認定されたアンブレーカブルな Oracle 10g プラットフォー ムに構築されます。 • 完全グローバル化 − Unicode および他のすべてのデータベース・キャラク タ・セットと、100 以上の言語のドキュメントをサポートしています。 • 複数のプラットフォームで使用可能 − 当初の Windows と Linux に加え、 Unix 実装にも対応しています。 • スケーラビリティとパフォーマンスの向上 − Oracle Text エンジンに基づ き構築され、実際の顧客の実装における多数のテラバイトの情報処理で 実証済です。検索可能なソース
Oracle SES は、すべてのソースを安全に検索できます。次のリポジトリが検索で きます。 • Web サーバーが提供する HTML ページ • データベース表 − Oracle データベースおよび ODBC 標準に対応するすべ てのデータベースを検索します。データベース表は、Oracle SES 固有の データベース・インスタンスに存在するか、またはネットワークを介してアクセスされるリモート・データベースの一部です。フル・テキスト 列とフィールド・テキスト列両方をクロールします。 • ファイル − ローカル・ファイルまたはリモート・ファイルも、file://プロ トコルにより検索できます。 • 電子メール − 電子メールおよびメーリング・リストは、IMAP プロトコ ルを介してクロールできます。
• Oracle Application Server 10g Portal リポジトリ − プライベートならびに 公開されたポータルページ、フォルダ、サブフォルダ、テキスト項目な どを含みます。 • Google 企業向けデスクトップなどのデスクトップ検索エンジンと統合さ れたデスクトップ・コンテンツ。デスクトップ検索エンジンは、ローカ ルにダウンロードされた電子メール、ローカル・ストレージ上のファイ ル、表示済みの Web ページなどを検索するようにオプションで構成でき ます。
• 他のソース − Secure Crawler Plug-in SDK により、他のリポジトリへアク セスするようにクローラをカスタマイズできます。
認可（検索セキュリティ）および認証（クローラ・ログイン）機能の型すべてが、 すべてのソース型に適切というわけではありません。たとえば、フォーム・ログ インは Web ソースにのみ適用可能で、各ドキュメントの ACL（ソース ACL）は、 実際にアクセス権を各ドキュメントに添付するソースによってのみ提供されます。
結論
保護されたソースの索引付けができず、ソースの検索結果を安全に戻せない検索 エンジンは、企業情報検索エンジンとは呼べません。Oracle Secure Enterprise Search は、様々なアプリケーションとセキュリティ要件に適した様々な手法を提供しま す。
Oracle Secure Enterprise Search 10g を使用したセキュアな検索 2006 年 3 月
著者: Roger Ford
寄稿者: Sandeepan Banerjee, 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 はオラクル社の登録商標です。 このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。 その他のすべての製品名およびサービス名は、各社の商標です。
Copyright © 2006 Oracle Corporation 無断転載を禁ず。
