| Oracle® Fusion Middleware Oracle WebCenter Contentの管理 12c (12.2.1.1) E77332-02 |
|
 前へ |
 次へ |
この章の構成は、次のとおりです。
プロキシ接続、またはコンテンツ・サーバー・インスタンス間の接続を使用すると、次の機能により、コンテンツ・サーバーのセキュリティ・レベルが向上します。
あるコンテンツ・サーバー・インスタンスから別のコンテンツ・サーバー・インスタンスへのセキュリティ資格証明マッピング
コンテンツ・サーバー・インスタンスへのセキュアな名前付きパスワード接続(パスワードで保護されたプロバイダ接続)
コンテンツ・サーバー・インスタンス間のHTTPプロトコルによる通信
名前付きパスワード接続とHTTPベースのコンテンツ・サーバー接続の両方が使用できますが、多くの場合、どちらかのタイプの接続を使用する方が便利です。どちらのタイプの接続でも、資格証明マッピングによりセキュリティが向上します。
注意:
1つのサイトに複数のContent Serverインスタンスが存在できますが、各Content Serverインスタンスはその固有のOracle WebLogic Serverドメインにインストールされる必要があります。
コンテンツ・サーバーでは、ProxyConnectionsコンポーネントはデフォルトでインストールされ、有効化されています。典型的なプロキシ接続の使用例には、次のものがあります。
HTTPまたはHTTPSを介してコンテンツ・アイテムのアーカイブ・レプリケーションの実行を可能にするため。たとえば、ある企業が別の企業買収したが、情報を共有するための共通のインフラストラクチャがないとします。どちらの企業もSecure Sockets Layer (SSL)接続を使用してインターネットに接続しています。この企業で、2つのサイト間のコンテンツを共有するとします。プロキシ接続を使用してこの企業のサーバー間にセキュアなインターネット接続を設定できるため、コンテンツには一方のサイトから安全にアクセスでき、もう一方のサイトでレプリケートおよびアーカイブできます。
ターゲット・プロキシ接続に対して名前付きパスワードを使用することにより、コンテンツ・サーバー・インスタンスへのアクセス制限を向上させるため。たとえば、ある企業が、1つのコンテンツ・サーバー・インスタンスから別のコンテンツ・サーバー・インスタンスへの接続に追加のセキュリティを適用するとします。名前付きパスワードを使用すると、受信接続によるアクセスを、管理者はプロキシ接続および名前付きパスワードが事前に設定されている接続に制限できます。
資格証明マップは、コンテンツ・サーバー・インスタンスにより使用される資格証明の、リモート・システムで使用される資格証明へのマッピングであり、これにより、そのシステムでの指定されたリソースへの接続方法がコンテンツ・サーバー・インスタンスに通知されます。管理者はユーザー、ロールおよびアカウントに複数の資格証明マップを作成できます。資格証明マッピングは、プロキシのシナリオで有用な場合があります。たとえば、あるコンテンツ・サーバー・インスタンスで作成されたユーザー、ロールまたはアカウントの資格証明を、別のコンテンツ・サーバー・インスタンスのユーザー、ロールまたはアカウントにマップできるため、ユーザーは、検索などのタスクのために1つまたは複数のコンテンツ・サーバー・インスタンスに関する情報に対して制御されたアクセスが可能になります。
この項の内容は次のとおりです。
資格証明マップを作成する際には、マップの一意識別子、およびユーザー、ロールやアカウントの固有の資格証明値を入力します。プロキシ接続では、ユーザー資格証明が入力値に一致すると、出力値で指定した資格証明がユーザーに付与されます。ユーザー資格証明は次の順序で評価されます。
すべてのロール。
すべてのアカウント。
ユーザー名。
変換の実行後、ユーザーは入力値から正常にマップされた属性値のみを持ちます。
資格証明マップを作成したら、送信プロバイダの構成時に、名前付きパスワード接続とともに資格証明マップを指定できます。ユーザー・プロバイダ(LDAPなど)の構成時にも資格証明マップを指定できます。
LDAPプロバイダのデフォルトの動作では、guestロールは自動的にユーザーに割り当てられません。
資格証明マッピングの実装は、Oracle WebCenter ContentのWebサーバー・プラグインで複製されます。最適なパフォーマンスを実現するために設計および実装されているため、マッピングでの変更はすぐに適用されます(変更内容はキャッシュされ、最大で2、3分間はコンテンツ・サーバー・インスタンスに反映されない、NTやNT管理者インタフェースを使用するADSIユーザー記憶域のパフォーマンスと比較できます)。
注意:
コンテンツ・サーバー・インスタンス以外の資格証明マッピングの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の資格証明マッピング・プロバイダに関する項を参照してください。
ロールまたはユーザー名の場合、資格証明の入力値は、完全一致である場合に一致します。入力アカウント値は、フィルタの場合を除き、いずれかのユーザー・アカウントに接頭辞がある場合に一致します(「アカウントおよびロールの一致」を参照してください)。たとえば、次の資格証明値により、adminロールを持つすべてのユーザーがguestロールを持つユーザーに変更されます。
admin, guest
次の表に、資格証明値の基本的な構文を示します。
| 値 | 接頭辞または順序 | 例 |
|---|---|---|
ユーザー名 |
& |
&name |
ロール |
admin |
|
アカウント |
@ |
@marketing |
空のアカウント |
@#none |
@#none |
すべてのアカウント |
@#all |
@#all |
値を無視または値をコメントアウト |
# |
#comment |
資格証明マップが割り当てられていない場合は、どの資格証明がデフォルトで適用されているかを表示できます。変更せずにすべてをマップする次のマッピングを使用します。このマッピングでは、まずすべてのロールがフィルタされ、次にすべてのアカウントがフィルタされます。
|#all|,%% @|#all|,@%%
マッピングの構文の詳細は、「アカウントおよびロールの一致」を参照してください。
注意:
資格証明マップに、匿名ユーザーがコンテンツ・サーバーWebサイトに接続する際に付与される最小限の権限も割り当てられていない場合、ログイン済のユーザーが異常な動作を体験する可能性があります。たとえば、ACCESS DENIEDというレスポンスを受信するブラウザでは、一般的に匿名ユーザーに戻ります。特に、ドキュメントにアクセスできる場合やできない場合に、予期しない動きが発生する可能性があります(その場合に、ブラウザがユーザーの認証資格証明を送信するかしないかによって異なります)。NTLM認証は定期的に更新する必要があるため、これは特にNTLM認証に当てはまります。
アカウントおよびロールの一致には特別なフィルタを使用できます。たとえば、アカウント・フィルタの構文は、アカウント値を接頭辞@|で開始し、|で終了することで指定されます(たとえば@|accountname|)。パイプ(|)はフィルタを介して値を処理するコマンド・リダイレクト演算子を表します。プロキシ接続の場合は、空白で区切られたアカウントのリストが指定されます。アカウントをダッシュ(-)で開始して、負の値を指定することもできます。ダッシュで開始されていない指定した任意のアカウント文字列がユーザー・アカウントの接頭辞である場合や、ダッシュで開始されているすべてのアカウント文字列がそのユーザー・アカウントの接頭辞ではない場合に、フィルタが一致します。
注意:
フィルタでは、アカウント@#allはマップされません。@#all, @#allマッピングを使用して、アカウント値all accountsを明示的にマップする必要があります。
ロールは、フィルタの先頭から@記号を削除することで、同じルールを使用して、マップできます。たとえば、次の入力値では、接頭辞visitorで開始されるロールを除くすべてのロールが取得されます。#allという式では、すべてのロールが一致することに注意してください。
|#all -visitor|, %%
出力値の特別な配列%%を使用して、入力値を参照できます。たとえば、次のマッピングでは、接頭辞financialで開始されないすべてのアカウントは同じアカウントにマップされますが、先頭に接頭辞employee/が追加されます。
@|#all -financial|, @employee/%%
ユーザーのアカウントがmarketingの場合、マッピング後、ユーザーのアカウントはemployee/marketingになります。
カッコで囲まれた文字"R"、"W"、"D"、"A"を使用したアカウント指定に準拠することで、出力値のアカウントに特定の権限レベル(読取り、書込み、削除、すべて)を付与できます。たとえば、次の構文で、すべてのアカウントのすべての権限レベルを読取り権限に変更できます。
@|#all -financial|, @employee/%%(R)
置換%%を適用する前に、接頭辞を削除すると便利な場合があります。構文%%[n]を使用して、置換のオフセットを指定できます。ここで、nは、%%式に入力値をマップする前に使用する開始のオフセットです。オフセットはゼロベースであるため、%%[1]では入力値の先頭の文字が削除されます。たとえば、すべてのロールから接頭辞DOMAIN1\を削除するには、次の式を使用します。
|domain1\|, %%[8]
この機能を使用して、接頭辞marketing/で開始されるすべてのアカウントを、接頭辞org1/mktで置換することもできます。この場合の式は次のようになります。
@|marketing/|, @org1/mkt/%%[10]
プロキシ資格証明マップは、最初の資格証明がユーザーに割り当てられた後に適用されます。このマッピング例では、(LDAPグループではなく)ユーザーに割り当てられたアカウント値が使用され、同じアカウント値が付与されています。
@|Public|, @Public
(R)などの接尾辞を適用しない場合、マッピング前にアカウントが付与されていた権限はすべて、マッピング後も保持されます。LDAPマップによって割り当てられるデフォルトの権限から権限を降格する場合は、次の構成を試します。
@|Public|, @%%(R)
%%は、接頭辞Publicと一致した入力アカウント値を表します。たとえば、ユーザーのアカウントがPublic/mysuffixであり、|Public|接頭辞フィルタによって取得される場合、%%の値はPublic/mysuffixになります。
コンテンツ・サーバー・インスタンスへのセキュアな接続は、着信リクエストにパスワードの保護を作成することでサポートできます。パスワードを保護すると、コンテンツ・サーバー・インスタンスは別のコンテンツ・サーバー・インスタンスと通信できます。
この項の内容は次のとおりです。
「プロキシ接続の認証/認可情報」画面を使用して、名前付きパスワードを作成できます。これは特定の接続に名前で割り当てるパスワードです。各名前付きパスワードを関連付けられるのは、コンテンツ・サーバー・インスタンスへのダイレクト・ソケット通信と、コンテンツ・サーバー・インスタンスのWebサーバー(HTTPフィルタ)を制御することで実行される任意の通信の両方に対するホストおよびIPアドレス・フィルタです。外部エージェント(別のコンテンツ・サーバー・インスタンスのWebサーバーなど)でコンテンツ・サーバー・インスタンスと通信する必要がある場合、名前付きパスワード接続を使用できます。名前付きパスワード接続は、資格証明マップにも関連付けられるため、コンテンツ・サーバー・インスタンスにアクセスするユーザーの権限を引き下げることや変更することができます。
プロキシ接続のエントリ・フィールドは、送信ソケット・プロバイダおよび送信HTTPプロバイダを構成するためのフォームに提供されており、名前付きパスワード接続を指定できます(インスタンスに選択されているプロバイダを表示するには、「管理」、「プロバイダ」の順に選択します)。
パスワードは、クライアント側の許可されているホストおよびIPアドレス・ワイルドカード・フィルタを使用してハッシュされます(SHA1メッセージ・ダイジェストを使用)。これは、格納されているパスワードのコピーが露呈した場合、ホストおよびIPアドレス・フィルタの両方を満たすクライアントからのアクセスのみが許可されることを意味します。
パスワードに有効期限を実装する場合は、関連する様々なサーバーの時計がかなり正確(最低数分以内)に同期している必要があります。
注意:
すべてのパスワードは、サーバーに送信される前にタイムアウト値でハッシュされます。これは、サーバーへの通信中にパスワード値が露呈した場合、有効期限(リクエストが発行された後の約15分)までの間のみパスワードが使用できることを意味します。また、前述した同じソース・ホストおよびIPアドレスからの再生攻撃でのみ、パスワードは使用できます。ファイアウォールで保護された内部ホストおよびIPアドレスが使用されていない場合は、その実行した攻撃者が主要なDNSサーバーのいずれかをハイジャックすることで、ホストおよびIPアドレスが偽装される可能性があります(少なくとも数件発生しています)。
「プロキシ接続の認証/認可情報」ページに入力するデータにより、外部エージェントがコンテンツ・サーバー・インスタンスに接続する際に使用可能な異なるパスワードを定義できます。様々な理由 (メッセージ・ダイジェスト・アルゴリズムはクリア・テキスト・パスワードが使用されていないなど)で クライアントに対して利用できない可能性があるため、 外部エージェントに各ユーザーのパスワードの入力を要求するのではなく、プロキシ接続を使用します。これにより、ユーザーは単一の名前付き接続パスワードを使用して認証できます。各名前付きパスワード接続をルールにリンクし、コンテンツ・サーバー・インスタンスに接続できるホストを制限したり、ユーザーに付与される権限を制御できます。各名前付きパスワード接続は一意に識別されますが、呼出し側のエージェントはパスワードとともに識別子を指定する必要があります。
ホスト名およびIPアドレス・フィルタは、コンテンツ・サーバー・インスタンスへのダイレクト・ソケット接続を実行する際に、どのホスト名またはIPアドレスで名前付きパスワード接続の使用が許可されているかの判断に使用されます。フィルタの定義ルールは、システム・プロパティ・エディタに定義されているルールと同様です( 0または複数の一致を表す*およびいずれかの一致を表す| のワイルドカード記号を使用して、柔軟なルールを作成できます)。エントリが空の場合には、ターゲット属性の制限はありません (次の2つのフィールドのどちらが関連するかによって、クライアントのホスト名またはIPアドレスのいずれかになります)。
「プロバイダ」ページを介して、次の2つのオプションが実装されます。
送信プロバイダを追加する場合には、名前付きパスワード接続の使用、および(Webアクセスとセキュリティがリモート・サーバーを介して制御されるように)プロバイダを接続サーバーにするかどうかの選択のオプションがあります。
ユーザー・プロバイダ(LDAPなど)を追加した場合は、使用可能な資格証明マップの使用を選択できます。
資格照明マップは、「プロキシ接続の認証/認可情報」画面には定義されていません。資格証明マップの作成の詳細は、「資格証明マッピング」を参照してください。
管理者はHTTPプロトコルを使用してコンテンツ・サーバー・インスタンス間のプロキシ接続を作成できます。たとえば、どちらもそれぞれの機能にアクセスするためのWebサーバーを持つ、2つのコンテンツ・サーバー・インスタンスを作成できます。多数のユーザーがコンテンツ・サーバー・インスタンスのいずれかにある情報へのアクセスにWebブラウザを使用する必要があるが、すべてのユーザーがそのサーバーに直接アクセスできるわけではない場合に、この機能は便利です。
コンテンツ・サーバー・アーカイブの転送には、HTTPプロトコルも便利です。HTTPプロバイダは、Secure Sockets Layer (SSL)を使用したHTTPSプロトコルと連携し、2つのコンテンツ・サーバー・インスタンス間のセキュアな通信を可能にします。
この項の内容は次のとおりです。
管理者は、「プロバイダ」ページで構成可能なhttp送信プロバイダを実装でき、このプロバイダにより、コンテンツ・サーバー・インスタンス間の通信が可能になります。
http送信プロバイダの追加を選択した場合、次の追加のオプションがあります。
CGI URLの指定
名前付きパスワード接続およびクライアントIPフィルタの指定
http送信HTTPプロバイダの選択を表示するには、コンテンツ・サーバー・ポータルから「管理」、「プロバイダ」の順に選択します。
コンテンツ・サーバー・インスタンス間にプロキシ接続を作成するには、いくつかの準備が必要です。コンテンツ・サーバー・インスタンスで、Webレイアウト・ディレクトリに、同じ相対Webルートを使用することはできません。サーバー間の追加のナビゲーション・リンクを提供するには、コンポーネント・アーキテクチャを一部変更する必要があります。
WebサーバーでSSLが使用され、その他のサーバーのフロント・エンドでHTTPが使用されている状態で、コンテンツ・サーバー・インスタンスを設定した場合、ユーザーがWebブラウザでその他のサーバーのURLを変更して、最初のサーバーへのアクセスを試行すると、HTTPS(資格証明が必要)とHTTP間の差異が原因で、エラーが発生する可能性があります。この問題を解決するには、コンテンツ・サーバーとともに入手可能なBrowserUrlPathコンポーネントを使用してください。詳細は、「ブラウザURLのカスタマイズ」を参照してください。
HTTPプロバイダを構成する手順は、次のとおりです。
最初のコンテンツ・サーバー・インスタンスにhttp送信プロバイダを追加します。
ブラウザで「管理」ページに移動し、「プロバイダ」をクリックします。
htt送信プロバイダ・タイプの横の「追加」をクリックします。
http送信プロバイダの必要な情報を入力します。詳細は、送信Httpプロバイダ・ページの表を参照してください。
前の手順で指定した名前付きパスワード接続および接続パスワードを使用する2番目のコンテンツ・サーバー・インスタンスにプロキシ接続を作成します。
このサーバーで、「管理」、「接続パスワード」の順に選択します。
接続に関する情報を入力します。IPアドレス・フィルタ・エントリには最初のサーバーのIPアドレスが含まれている必要があります。
