Oracle® Fusion Middleware

Enterprise Single Sign-On Suiteセキュア・デプロイメント・ガイド

11gリリース2 (11.1.2.2)

E53271-01(原本部品番号:E37694-01)

2013年12月

Oracle Fusion Middleware Enterprise Single Sign-On Suiteセキュア・デプロイメント・ガイド, 11g リリース2 (11.1.2.2)

E53271-01

Copyright © 1998, 2013 Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Logon Managerの保護

- 1.1 ディレクトリ環境でのLogon Managerのデプロイ

- 1.1.1 Logon ManagerによるActive Directoryスキーマの拡張方法

- 1.1.2 Logon ManagerとActive Directoryの同期方法

- 1.1.3 Logon Managerによるアプリケーション資格証明の処理と格納の方法

- 1.1.4 参考文献

- 1.2 Logon Managerディレクトリのサブツリーの設計

- 1.2.1 サブツリーの構築に関するガイドライン

- 1.3 Logon Managerのセキュアな構成の実現

- 1.3.1 推奨されるグローバル・エージェント設定

- 1.3.1.1 SSLのサポート

- 1.3.1.2 構成オブジェクトの使用(Active Directoryのみ)

- 1.3.1.3 ディレクトリに対する認証時に使用する資格認証の選択

- 1.3.1.4 それぞれのユーザー・オブジェクトへのユーザー資格証明の格納(Active Directoryのみ)

- 1.3.2 推奨される管理オーバーライド

- 1.3.2.1 ユーザー設定をセキュアな場所に保存する(Active Directoryのみ)

- 1.3.2.2 エンド・ユーザーのプライマリ・オーセンティケータの選択

- 1.3.2.3 デフォルトの暗号化アルゴリズムの使用

- 1.3.2.4 会社のパスワード変更ポリシーの作成および設定

- 1.3.2.5 マスクされたフィールドの表示時の強制再認証

- 1.4 Logon Manager用のセカンダリ認証の構成

- 1.4.1 対話型のパスフレーズ・プロンプトによるセカンダリ認証

- 1.4.2 その他の方法によるセカンダリ認証

- 1.4.3 GINAおよびNetwork Providerコンポーネントの理解

- 1.5 アプリケーションに対するセキュアなレスポンスの確保

- 1.5.1 コントロールID

- 1.5.2 SendKeys

- 1.5.3 コントロールIDとSendKeys

- 1.5.4 使用する方法

- 1.5.5 テンプレート・レベルでのユーザー・アクセスの構成

2 Password Resetの保護

- 2.1 クライアント側のPassword Resetの保護

- 2.2 サーバー側のPassword Resetの保護

3 Kiosk Managerの保護

4 Provisioning Gatewayの保護

- 4.1 クライアント側のProvisioning Gatewayの保護

- 4.2 サーバー側のProvisioning Gatewayの保護

5 Universal Authentication Managerの保護

- 5.1 リポジトリ接続

- 5.2 サービス・アカウント(エンタープライズ・モードのみ)

- 5.3 ユーザー・ポリシー(エンタープライズ・モードのみ)

- 5.4 Password Resetとの同期

6 Reporting Serviceの保護

7 Anywhereの保護

はじめに

『Oracle Enterprise Single Sign-On Suiteセキュア・デプロイメント・ガイド』では、Oracle Enterprise Single Sign-On Suiteの各コンポーネントをセキュアにデプロイする方法を説明しています。また、使用するOracleソフトウェアのデプロイメントのセキュリティに悪影響を及ぼす可能性があるデプロイメント・シナリオの発生に対する注意も記載しています。

対象読者

このガイドは、アプリケーションの計画、実装およびデプロイメントを担当する熟練した管理者を対象としています。管理者は、ディレクトリ環境、権限構造、ドメイン管理およびデータベースに関する正確な知識を持っている必要があります。

警告:

Oracleと他のアプリケーションのセキュリティを最大化するため、エンタープライズにおけるOracle、Microsoft、およびその他のネットワーク・セキュリティのベスト・プラクティスに従うことをお薦めします。

これには、機密情報への不正アクセスの可能性を減少させるため、Oracle ESSO Suiteアプリケーションの認証に使用するパスワードなどに、ネットワーク全体で強力なパスワードを使用し、厳格なポリシーを適用することが含まれます。

明示的にローカル管理者アクセス権を必要とするユーザー以外にはアクセス権を認めないなど、ユーザーおよびアプリケーションの両方に対し、ドメイン・アカウントに与える権限を最小限にすることを強くお薦めします。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、Oracle Enterprise Single Sign-On Suiteリリース11.1.2.2ドキュメント・セットの次のドキュメントを参照してください。

- Oracle Enterprise Single Sign-On Suiteリリース・ノート

- Oracle Enterprise Single Sign-On Suiteインストレーション・ガイド

- Oracle Enterprise Single Sign-On Suite管理者ガイド

- Oracle Enterprise Single Sign-On Suiteユーザーズ・ガイド

- ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ

- Logon Managerのアプリケーション・テンプレートの構成と診断

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Logon Managerの保護

この章では、Logon Managerをセキュアにデプロイする方法を説明します。

1.1 ディレクトリ環境でのLogon Managerのデプロイ

Active Directory、AD LDS (ADAM)、Oracle Internet Directory、様々なサード・パーティLDAP準拠ディレクトリなどのディレクトリ環境にLogon Managerをデプロイする選択肢もあり、これにより、ネットワーク上の任意のマシンに対して、アプリケーション資格証明、テンプレートおよびポリシーの一括格納によるシングル・サインオン機能を実装できます。ユーザーは、このディレクトリを同期して、これらの項目をダウンロードし、新規作成または変更されたユーザー名やパスワードで資格証明ストアを更新します。

既存のディレクトリ環境にLogon Managerを追加すると、次のような利点があります。

- Logon Managerでは既存のユーザー・アカウント、グループおよびネイティブのディレクトリ権限(ACL)を使用できるため、これらの項目を個別に管理したり、他のディレクトリまたはデータベースと同期する必要がありません。

- Logon Managerのデータは、既存のバックアップ、フェイルオーバーおよび障害時リカバリ計画によって自動的に保護されます。

- 専用サーバーやサーバー側のプロセスは不要で、Logon Managerのスケーラビリティとパフォーマンスは、既存のディレクトリ・インフラストラクチャの容量と堅牢性のみに依存します。

- 管理者のタスクが増えることはなく、また新しいツールや概念について学習する必要もありません。Logon Managerの委任管理は、ディレクトリのネイティブ機能によって行われます。

また、ディレクトリの使用によって、Logon Managerのテンプレートとポリシーの編成を見やすい階層構造で表示することもできます。現行の環境で必要な場合はフラット・モデルを使用できますが、階層を適切に設定すれば、より効率的なアクセス制御によって、トップ・ディレクトリ、エージェント、およびネットワークのパフォーマンスの安定化を図り、Logon Managerの管理を簡略化し、データ・セキュリティを向上できます。

1.1.1 Logon ManagerによるActive Directoryスキーマの拡張方法

Logon ManagerでActive Directoryにデータを格納するためには、Logon ManagerにActive Directoryスキーマの拡張を指示する必要があります。スキーマの拡張は、4つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。Logon Managerでアプリケーション資格証明をユーザー・オブジェクトに格納する場合(推奨されるベスト・プラクティス)は、この機能に必要な権限もLogon Managerによって適用されます。

1.1.2 Logon ManagerとActive Directoryの同期方法

Logon Managerエージェントは、Active Directoryシンクロナイザのプラグインを使用してActive Directoryと通信します。適切に設定されている場合は、次のいずれかのイベントが発生すると同期が実行されます。

- Logon Managerエージェントが起動された。

- アプリケーション資格証明がエンド・ユーザーによって、追加、変更または削除された。

- エージェントを実行しているマシンがIPアドレスを取得した、または既存のIPアドレスが変更された。(Logon Managerがこれらのイベントに応答するように設定されている場合)。

- 自動同期の間隔が経過した(設定されている場合)。

- ユーザーがLogon Managerのリフレッシュ機能を使用して同期を開始した。

- スクリプトがコマンド行パラメータを使用して同期を開始した。

同期を実行している間、Logon Managerエージェントは、Logon Managerツリーを移動して、現在のユーザーにアクセス権が付与されているサブコンテナのコンテンツをロードし、前回の同期後に追加、変更または削除された資格証明を同期します。

1.1.3 Logon Managerによるアプリケーション資格証明の処理と格納の方法

Logon Managerは、ユーザーが「First-Time Use (FTU)」ウィザードを完了したときに生成される一意キーを使用してアプリケーション資格証明を暗号化します。資格証明は、エージェントのローカル・キャッシュ内、ディレクトリ内およびネットワークを移動しているときも常に暗号化された状態を維持します。Logon Managerは、設定されたアプリケーションがログオンをリクエストしたときにのみ資格証明を(ディスクではなくメモリーに対して)復号化し、ログオン・リクエストの完了後すぐにターゲット・メモリーの場所を消去します。ユーザーおよび有効なアプリケーションごとにLogon Managerが格納するデータ量はわずかです(数バイトか数キロバイト)。

1.1.4 参考文献

Logon Managerソフトウェアのアーキテクチャについては、このガイドでは詳しく取り扱いません。詳細な説明が記載されたOracleのホワイト・ペーパーをお求めの場合は、オラクル社の担当者に問い合せてください。

1.2 Logon Managerディレクトリのサブツリーの設計

Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。

- ユーザーの数

- Logon Managerでサポートするアプリケーションの数

- 既存のインフラストラクチャの堅牢性

- 組織の構造

Active Directoryの設計および実装については、Microsoftの次の記事で説明されているベスト・プラクティスに必ず従ってください。

http://technet.microsoft.com/en-us/library/bb727085.aspx

1.2.1 サブツリーの構築に関するガイドライン

次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。

- OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレートおよびポリシーをグループ化します。

- OUレベルでアクセスを制御します。

- 現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのサブツリーのルートでユーザー権限を付与しないようにします。

このように階層を設定すると、次の利点があります。

- 見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。

- 不要な権限の継承なし。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。

- ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。

- 管理タスクの分散。テンプレートを制御しやすいセットに整理し、アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。

- 低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。

サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様であるため、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブOUにアクセスできないようにしています。つまり、具体的な実装方法は使用する環境によって決まります。

図1-1は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。

図1-1 Logon Managerサブツリーの推奨設計

注意:

テンプレートおよびポリシーは、個々のOUに格納することをお薦めします。これを行うには、「構成オブジェクトの使用(Active Directoryのみ)」の説明に従って、構成オブジェクトの使用を有効にする必要があります。

フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスをモニターしてください(後で確認するよりも手間を省くことができます)。

1.3 Logon Managerのセキュアな構成の実現

Logon Managerエージェントの動作(ディレクトリとの相互作用も含む)は構成済の設定によって管理し、エンドユーザーのマシンへのデプロイは管理コンソールを使用してLogon Manager管理者が行います。設定は、次のいずれかのカテゴリに該当します。

- グローバル・エージェント設定は、エージェントのローカル・ポリシーであり、エンド・ユーザー・マシンのWindowsレジストリに格納され、Logon Manager MSIパッケージに含まれて、エージェントにデプロイメント時の初期構成を提供します。グローバル・エージェント設定は、HKEY_LOCAL_MACHINE\Software\Passlogix (32ビット・システム)またはHKEY_LOCAL_MACHINE\Wow6432Node\Software\Passlogix (64ビット・システム)に格納されます。

- 管理オーバーライドはWindowsレジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期化の際にエージェントによって中央リポジトリからダウンロードされ、改ざん防止機能が付いた、エージェントの暗号化済ローカル・キャッシュに格納されるため、これによって、エンド・ユーザーによる変更ができないようになります。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。

注意:

管理オーバーライドを計画する際は、慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。

管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドは、Logon Managerのセキュアなデプロイメントを実現するためにOracleが推奨する構成について説明し、Logon Managerに関する他の文書の情報を補足するものです。

警告:

ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。
入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、管理コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。

1.3.1 推奨されるグローバル・エージェント設定

この項では、セキュアなLogon Manager構築を実現するためにOracleに必須の、グローバル・エージェント設定について記載します。

1.3.1.1 SSLのサポート

Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。

注意: Logon Managerをデプロイする前に、SSLを使用するようにドメイン・コントローラを構成してください。手順は次のMSDNの記事を参照してください。

http://msdn.microsoft.com/en-us/library/aa364671(VS.85).aspx

場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > [シンクロナイザ名]

有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。

1.3.1.2 構成オブジェクトの使用(Active Directoryのみ)

Active Directoryのデプロイメントでは、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「サブツリーの構築に関するガイドライン」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。(この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをツリーのルートの下に単一のフラット・ファイルとして格納します。)

場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」

有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。

1.3.1.3 ディレクトリに対する認証時に使用する資格認証の選択

「Credentials to use」オプションを使用して、ディレクトリに対する認証を行う場合に、Logon Managerで使用する資格証明を選択します。Logon Managerがディレクトリに対して認証できない場合に、ユーザーに再認証のためのプロンプトが表示されないように、これを「Use local computer credentials only」に設定することをお薦めします。

注意: これをデフォルトの設定「Try local computer credentials; if it fails, use directory server account」のままにしないでください。デフォルト設定のままにすると、ディレクトリとエンド・ユーザー・マシンが同じドメイン上にない場合に、認証が失敗します(無効に設定していないかぎり、再認証のプロンプトが表示されます)。

場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > [シンクロナイザ名]

設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。

1.3.1.4 それぞれのユーザー・オブジェクトへのユーザー資格証明の格納(Active Directoryのみ)

Logon ManagerをActive Directoryで使用する主な利点は、それぞれのユーザー・オブジェクトの下にユーザー資格証明を格納できることです。こうすることで、次のような管理の簡略化が図れます。

- 個別のユーザーの資格証明を検索したり表示する操作がすばやく直感的になります。

- ディレクトリからユーザーを削除すると、ユーザーのアプリケーション資格証明のキャッシュがそれぞれのユーザー・オブジェクトから自動的に削除されます。

注意:

このオプションは、必要なスキーマの変更と権限の割当てを行わないかぎり機能しません。手順については、使用しているリポジトリのLogon Managerデプロイメント・ガイドを参照してください。

ユーザー資格証明がそれぞれのユーザー・オブジェクトの下に格納され、資格証明オブジェクトの使用が有効になっている場合、Locatorオブジェクトを使用する必要がありません。Locatorは、フラットなディレクトリ・モデルを使用する場合、ディレクトリ内のテンプレート、証明書、およびその他のオブジェクトを探す場所をLogon Manager示すポインタ・オブジェクトです。詳細は、使用しているリポジトリのLogon Managerデプロイメント・ガイドを参照してください。

場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > 「ADEXT」

有効にするには: チェック・ボックスを選択して、ドロップダウン・リストから「Under respective directory user objects」を選択します。

1.3.2 推奨される管理オーバーライド

この項では、Logon Managerのセキュアな構成を実現するためにOracleに必須の、管理オーバーライドについて記載します。

1.3.2.1 ユーザー設定をセキュアな場所に保存する(Active Directoryのみ)

バージョン11.1.2.0.0以上では、Microsoft Active Directoryにデプロイした場合、Logon Managerの構成ポリシーが、リポジトリのセキュアかつ暗号化された場所に保存されます。「Use secure location for storing user settings」オプションを有効にすることにより、この新しい設定のストレージ・スキーマに移行することを強くお薦めします。

警告:

以前のバージョンのLogon Managerからアップグレードする場合は、Logon Managerのすべてのインスタンスをリリース11.1.2.0.0以上にアップグレードした場合にのみ、このオーバーライドをデプロイする必要があり、そうしない場合、Logon Manager 11.1.2.0.0以上が一度リポジトリと同期すると、以前のすべてのバージョンはそのユーザーのリポジトリと同期できなくなります。

場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > 「ADEXT」

設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。

1.3.2.2 エンド・ユーザーのプライマリ・オーセンティケータの選択

次の場合に、プライマリ・オーセンティケータを選択して構成することをお薦めします。

- 選択したプライマリ・オーセンティケータを介してのみユーザーを認証する場合。

- 次項の説明に従って、FTUウィザードを無効にする場合。

特定のオーセンティケータの構成については、Administrative Consoleのヘルプを参照してください。

注意:

この設定が空白のままで、FTUウィザードが無効な場合、最初にインストールされたログオン方法(アルファベットの降順)がデフォルトで自動的に選択されます。インストールされているオーセンティケータのリストを表示するには、設定を一時的に有効にして、そのドロップダウン・リストを確認します。

場所: 「Global Agent Settings」 > 「Live」 > 「User Experience」 > 「Setup Wizard」

設定するには: チェック・ボックスを選択し、ドロップダウン・リストから希望のログオン方法を選択します。

注意:

元のWinAuth (WinAuth v1とも呼ばれる)オーセンティケータは非推奨となっており、以前のバージョンからのアップグレードを可能にするためにのみ製品内に残されています。Oracleサポートが明示的に指示した場合を除き、ここでは選択しないでください。

1.3.2.3 デフォルトの暗号化アルゴリズムの使用

Logon Managerが、サポートされているすべてのオペレーティング・システムとの互換性を維持するためにアプリケーションの資格証明の暗号化に使用するデフォルトの暗号化アルゴリズム(AES (MS CAPI))は変更しないでください。Logon Managerによってサポートされているすべてのアルゴリズムが、すべてのオペレーティング・システムで機能するわけではありません。

警告:

AES (MS CAPI)を除くすべての暗号化アルゴリズムは非推奨になっており、以前のバージョンからのアップグレードを可能にするためにのみ製品内に残されています。Oracleサポートが明示的に指示した場合を除いて、暗号化アルゴリズムを変更しないでください。

場所: 「Global Agent Settings」 > 「Live」 > 「Security」

デフォルトにリセットするには(変更されている場合): チェックボックスのチェックを外します。

1.3.2.4 会社のパスワード変更ポリシーの作成および設定

デフォルトでのLogon Managerは、組織のセキュリティ要件を満たす新しいポリシーと置き換える必要のある、不十分なパスワード変更ポリシーが付属しています。組込みポリシーでないことを示すために、ポリシー名には組織の名前を含めます。このポリシーは、このオプションを設定する前に作成する必要があります(パスワード変更ポリシーの作成手順については、コンソール・ヘルプを参照してください)。

場所: 「Global Agent Settings」 > 「Live」 > 「User Experience」 > 「Password Change」

設定するには: チェック・ボックスを選択し、ドロップダウン・リストから希望のポリシーを選択します。

注意:

デフォルトのパスワード変更ポリシーとして設定されたポリシーは、エンタープライズ全体で有効です。

1.3.2.5 マスクされたフィールドの表示時の強制再認証

格納済のアプリケーション・パスワードへの不正アクセスを防止するには、エージェント内でマスクされたフィールドの表示機能が呼び出されたときに認証を行うことをユーザーに求めるようにLogon Managerを構成します。このポリシーを管理オーバーライドとして構成することで、不正な管理者がローカル・マシンのレジストリに手動で設定を追加したり、初期デプロイメント時に設定が未構成のままになっている場合にローカル・ユーザーのパスワードに不正アクセスすることも防止できます。

場所: 「Global Agent Settings」 > 「Security」

設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。

1.4 Logon Manager用のセカンダリ認証の構成

ユーザーを認証し、格納された資格証明に対するアクセス権を付与するため、Logon Managerには、オーセンティケータ・プラグインとして実装された複数の認証方式が用意されています(最も一般的な方式は、ユーザー名とパスワードです)。Active Directory環境では、Logon Managerはこの認証方法をWindows Authenticator v2 (WinAuth v2)プラグインによってサポートします。

ユーザーがLogon Managerに初めて登録する際、Logon Managerはそのユーザーの一意の認証要素を使用して資格証明ストアへのアクセスを保護します。WinAuth v2でのデプロイにおいては、デフォルトでは(明示的に異なる構成がなされていない場合)、Logon Managerはユーザーにパスフレーズを求めます。このパスフレーズは、プライマリ認証が失敗した場合、Logon Managerへのセカンダリ認証の手段を提供します。

1.4.1 対話型のパスフレーズ・プロンプトによるセカンダリ認証

対話型パスフレーズ・メカニズムは、Logon Managerへの初期登録時にユーザーに質問に対する回答の提示を要求するもので、デフォルトの推奨されるセキュアなセカンダリ認証方式です。(質問は管理者が定義します。)ユーザーは、オーセンティケータ・キーの暗号化に使用した要素が変更されるたびに、パスフレーズに回答してLogon Managerを認証する必要があります。この方法の主な利点は次のとおりです。

- 資格証明ストアに対する「第2パスワード」の役割を果たします。パスフレーズは、ユーザーのWindowsパスワードが機能しなくなった、またはパスワードにアクセスできなくなった場合に、資格証明ストアに対するアクセスを回復するために使用できます。

- 不正な管理者からの攻撃を防止します。不正な管理者がユーザーのパスワードを変更し、そのユーザーとしてログオンし、ユーザーの資格証明ストアにアクセスする可能性があります。しかし、パスフレーズが機能している場合、不正な管理者はパスフレーズに回答しないかぎり、ユーザーの資格証明ストアにアクセスできません。

組織において、パスワードと同様の暗号化強度ポリシーをパスフレーズ回答に対して適用することを強くお薦めします。

1.4.2 その他の方法によるセカンダリ認証

また、WinAuth v2は、使用している環境に応じてパスフレーズ方式のかわりに選択して使用できる、次のようなセカンダリ認証方式を提供します。

- カスタム・セカンダリ認証ライブラリ - WinAuth v2セカンダリ認証APIは、ユーザー操作の必要がない、外部セカンダリ認証ライブラリによってプログラム的にパスフレーズ応答を提供できる、セカンダリ認証APIを提供します。このAPIにより、リカバリ中にLogon Managerに2次キーを送る経路を完全に制御できますが、リカバリ・プロセスのいかなる時点においても、資格証明ストアキーのセキュリティを十分に確保する必要があります。

注意:

APIの詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。

- ユーザーのActive Directory SID - 現在ログオン中のユーザーのActive Directory SIDをWinAuth v2に対するパスフレーズ回答として警告なしに提供します。暗号化されたSIDは、エージェントのローカル・キャッシュに格納されます。このセカンダリ認証方法は、ネットワーク上でユーザーを「追跡」(同行)します。

- セキュア・ランダム・キー - ランダムに生成したキーを、WinAuth v2に対するパスフレーズ回答として警告なしに提供します。このランダム・キーは、暗号化形式でActive DirectoryのユーザーのLogon Manager資格証明ストアに保存されます。キーに対する不正アクセスは、ユーザーの資格証明ストア・コンテナに対して有効な、Active Directory ACLにより自動的に制限されます。

- Windows Data Protection - Windows Data Protection API (DPAPI)を使用して、セカンダリ認証をWindows Data Protectionサービスに委任します。ユーザーの資格証明ストアへのセカンダリ・アクセスは、DPAPIが(ユーザーのワークステーションのローカルで)セキュアに処理するため、もう1つの「サイレントな」セカンダリ認証方法として使用できます。ただし、DPAPIの機能はユーザーのワークステーションに限定されているため、このセカンダリ認証方法は移植性がなく、ネットワーク上のユーザーに「同行」しません。そのため、ユーザーが別のワークステーションにログオンした場合、この方法を使用できなくなります。

注意:

Logon ManagerをWinAuth v2でデプロイする場合の詳しい要件および手順は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。

1.4.3 GINAおよびNetwork Providerコンポーネントの理解

WinAuth v2のGINA (Graphical Identification aNd Authentication)ライブラリおよびNetwork Providerサービス・コンポーネントは、Windowsオペレーティング・システムにおけるユーザー認証メカニズムとの統合を提供します。GINAコンポーネントはWindows XPシステムのGINAチェーンに接続し、Network Providerサービスによって、GINAライブラリを使用しないWindows 7およびWindows Server 2008/2008 R2との統合が可能になります。また、Network Providerサービスによって、GINAライブラリへの変更が許可されておらず、不可能なWindows XPシステムにおける統合が可能になります。この統合には次のような利点があります。

- 二重認証が不要になります。統合を行わない場合、ユーザーはWindows資格証明を2回提供する必要があります - 1回はオペレーティング・システムに対し、ログオンして、デスクトップのロックを解除するかセキュアなスクリーン・セーバーを終了するため、もう1回はLogon Managerに対し、保存された資格証明にアクセスするためです。

- 資格証明ストアの解除をユーザーに意識させません。Logon Managerはログオン時に自動的にユーザーの資格証明に割り込み、資格証明のロックを解除するため、Logon Managerに別の設定が行われていないかぎり、ユーザーは自動シングル・サインオンを使用するためにLogon Managerを認証する必要はありません。

注意:

Windows XPが動作するクライアント・マシンでのPassword Reset環境において、Logon ManagerをWinAuth v2でデプロイする場合、Network Providerをインストールしないでください。Password Resetとは互換性がないためです。GINAライブラリのみをインストールしてください。

1.5 アプリケーションに対するセキュアなレスポンスの確保

Logon Managerがアプリケーションのログオンまたはパスワード変更フォームを正常に検出すると、資格証明をアプリケーションに注入し、送信することによって応答します。ターゲット・アプリケーションの設計に応じて、Logon Managerは次のいずれの方式を使用して、ターゲット・フォームのフィールドおよびコントロールと対話することができます。

1.5.1 コントロールID

これは、ほとんどのアプリケーションでデフォルトかつ推奨されるフォームの対話方式です。この方式では、Windows API (Windowsアプリケーション)、適切なブラウザ・ヘルパー・オブジェクト(Webアプリケーション)、またはHLLAPI(メインフレーム・アプリケーション)を使用して、フォーム内のフィールドおよびコントロールを識別し、対話します。Windows API準拠のアプリケーションでは、各フィールドとコントロールの一意のコントロールIDがオペレーティング・システムに対して公開されます。エージェントはこれらのコントロールIDを検出し、コントロールIDが示すオブジェクト(パスワード・フィールド、送信ボタンなど)の用途を意味する特定のサインオン機能にバインドします。

注意:

アプリケーションで公開されるコントロールIDのいくつか、またはそのすべてが、一意ではないか動的である場合、これらをエージェントで序数(ウィンドウ内の各項目に上から下へ、左から右に割り当てられる連続したID番号)に置き換えて、検出されたフィールドとコントロールを一意に識別することができます。

フィールドまたはコントロールのコントロールIDが公開されていない場合、またはサインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。

1.5.2 SendKeys

この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・アプリケーションと対話することができます。この方法は、エージェントがターゲット・フィールドおよびコントロールをプログラムで検出できないか、または対話できない場合に使用します。たとえば、アプリケーションがフィールドおよびコントロールのいずれのコントロールIDも公開しない場合は、フィールドに移入する個々のキーストローク、フィールドを切り替えるマウス・クリックまたは[Tab]キーストローク、ログオン・ボタンを動作させる最後のマウス・クリックを送信する必要があります。

注意:

コントロールIDによる方法を使用するようにフォーム定義を構成した場合、アプリケーションの非互換性によってLogon Managerが資格証明をプログラム的に注入することに失敗すると、Logon Managerはデフォルトで自動的にSendKeysによる方法にフォール・バックして注入を再試行します。「Logon Managerアプリケーション・テンプレートの構成と診断」の説明に従って、このフォールバック挙動を無効にできます。

1.5.3 コントロールIDとSendKeys

これは、前述の2つの方式を組み合せて両方の長所を活かすもので、プログラムでは実行できないアクションを必要とするサインオン・シナリオの解決方法として望ましい方式です。可能な場合は常にコントロールIDを使用してフォームと対話する一方で、キーストロークおよびマウス・クリックを送信して、フィールドのフォーカス設定、チェック・ボックスの選択、エージェントがターゲット・アプリケーション内ではプログラムで実行できないその他のアクションなどのタスクを実行します。

注意:

この混合モードを実装するには、最初にSendKeysレスポンス方式を使用するようにフォームを構成し、目的のSendKeysアクションを構成し、そのアクションの構成中に、プログラム的なコントロールIDレスポンス方式を保持するアクションに対して「Inject directly into control」オプションを有効にします。

たとえば、カスケード検証のために特定の順序でフィールドに移入する必要がある場合(つまり、ユーザー名フィールドに移入されたときにかぎりパスワード・フィールドがアクティブになる場合)、コントロールIDを使用して資格証明をフィールドに注入しますが、各フィールドの注入の合間にSendKeysで[Tab]キーストロークを送信してフィールドのフォーカスを移動することになります。

1.5.4 使用する方法

SendKeysによる方法はキーストロークをエミュレートするため、Logon Managerが資格証明を注入している間、ユーザーが適切なタイミングでフォーカスを他のアプリケーションに切り替え、プレーン・テキストに取り込むことも理論的には可能です。このため、可能な場合はコントロールIDを使用し、プログラム的な注入が不可能な場合にのみ　SendKeysを使用した方式に戻すことをお薦めします。

1.5.5 テンプレート・レベルでのユーザー・アクセスの構成

アプリケーション・テンプレートを構成する際、Securityタブを使用して、ターゲット・アプリケーション用のシングル・サインオン機能にアクセスできるユーザーおよびグループを制限できます。使用している環境においてユーザーごとに詳細なアクセス・コントロールを行う必要がない場合、管理モデルをより堅牢にするためには、個々のユーザーに対してアプリケーションへのアクセスを制限するのではなく、特定のユーザーをグループに割り振り、ユーザーグループに対してアクセスを制限することをお薦めします。

2 Password Resetの保護

Password Resetは、SSLで暗号化されたHTTP経由で互いに通信し、SSLで暗号化されたチャネルを使用してデータ・リポジトリにアクセスするクライアント側およびサーバー側コンポーネントで構成されます。

2.1 クライアント側のPassword Resetの保護

クライアント側では、Password ResetはGINAライブラリ・スタブ(Windows XP)または資格証明プロバイダ、およびLocalSystemアカウント下で実行されているシステム・サービスを使用してWindowsログオン・メカニズムに接続します。いずれのメカニズムにおいても、Password Resetは、次に示すサーバー側Password Reset Webアプリケーションに接続(SSL付きHTTP)する、ロックダウンされたInternet Explorerウィンドウを起動するバナーまたはハイパーリンクを追加することにより、通常のWindowsログオン・ダイアログにパスワード・リセット機能を追加できます。サーバー側コンポーネントがSSL接続用に構成されている場合、デフォルトでクライアント側の構成はセキュアであり、それ以上強化する必要はありません。

注意:

SSL使用のためにサーバー側コンポーネントを構成した後、エンド・ユーザー・マシンのWebアプリケーションのURLが、HTTPSプロトコルを使用するよう更新されていることを確認します。

2.2 サーバー側のPassword Resetの保護

サーバー側では、Password Resetはパスワード・リセット、チャレンジ質問、管理機能、およびそれぞれに対するユーザー・インタフェースを一括して提供するWindowsシステム・サービスに加えて、IISがホストするWebアプリケーションを動作させます。また、Universal Authentication Managerにチャレンジ質問機能を提供します。

Webアプリケーションは、EnrollmentClient、ResetClient、ManagementClientおよびWebServicesです。ResetClientおよびWebServices Webアプリケーションでは、権限が制限されたドメイン・ユーザー・アカウント(SSPRWeb)を作成し、そのアカウントをアプリケーション内のページにアクセスしてリポジトリ内のデータを変更できる、唯一のアカウントに指定する必要があります。

WebServicesアプリケーションのAdministration.aspxページに加え、EnrollmentClientおよびManagementClientアプリケーションは、Password Resetが有効なエンド・ユーザー・ワークステーションにログオン中のドメイン・ユーザー・アカウントがアクセスできるよう構成されています。　構成手順は『Enterprise Single Sign-On Suiteインストレーション・ガイド』に記載されています。

SSLを使用するために、IIS内でPassword Reset Webアプリケーションを構成することを強くお薦めします。Password Reset用のSSLサポートを有効にするには、Password Reset Webアプリケーションが使用しているIIS Webサイト用のX.509 SSL証明書を作成し、インストールする必要があります。(証明書は、商業団体またはローカル・ターゲット・マシン上のソフトウェアである認証局(CA)が発行します。)次に、使用しているエンド・ユーザー・ワークステーションとPassword Reset Webアプリケーションへのセキュアな(HTTPS) URLを更新する必要があります。手順は『Enterprise Single Sign-On Suite管理者ガイド』に記載されています。

注意:

最大のセキュリティを維持するため、SSL機能を無効にしないことを強くお薦めします。

また、Password ResetはWindowsシステム・サービスであるSSPRChangePasswordSvc.exeを利用します。このサービスはバックグラウンドで動作し、各ユーザーがPassword Resetのチャレンジ質問を通過した後、ユーザーのパスワードの変更を実際に担当します。このサービスには、ユーザー・アカウントのパスワードを変更し、Active DirectoryのlockoutTimeおよびpwdLastSetの値を書き込むために必要な権限を持つ、権限を制限されたドメイン・アカウント(SSPRReset)が必要です。構成手順、およびこのアカウントに割り当てる必要がある適切な権限は、『Enterprise Single Sign-On Suiteインストレーション・ガイド』に記載されています。

Password Resetは、ユーザー・データをサポートされているリポジトリに保存します。サポートされているリポジトリは、Active Directory、AD LDS (ADAM)、Oracle Internet Directory、Oracle Virtual DirectoryなどのLDAPディレクトリ、およびOracleおよびMicrosoft SQLデータベースです。インストール中、インストーラは組織単位(ディレクトリ・ベースのリポジトリ)またはデータベースと表(データベース・ベースのリポジトリ)を作成し、新規に作成されたコンテナまたはデータベース、およびそのすべてのコンテンツに対して、SSPRWebドメイン・アカウントのフル・アクセスを許可します。その他のアカウントは、管理者が自身の選択により明示的にアクセスを認めた場合を除いて、Password Resetコンテナまたはデータベースへのいかなるアクセス権も与えられません。

3 Kiosk Managerの保護

Kiosk Managerでは、単一のWindowsアカウント・セッションのコンテキスト内において1つまたは複数の「サブセッション」を可能にすることにより、診療所または病院などのKiosk環境において、複数のユーザーが単一のワークステーションを使用できます。

1つまたは複数のKiosk Managerのセッション・セキュリティ機能を使用することをお薦めします。

- ユーザーがCtrl-Alt-Delを押したときにセッションをロックする。

- スクリーン・セーバーの起動時にセッションをロックする。

- セッションがロックされた場合、マウスおよびWindowsホットキーを使用して、タスク・マネージャ、Run命令、およびスタート・メニューとWindowsタスクバーへのアクセスを無効にし、ユーザーがアプリケーションを起動、切り替え、終了できないようにします。

- 他のすべてのウィンドウを確認し、他のアプリケーションにフォーカスが移らないようにします。

Logon Managerが説明に従ってセキュアにデプロイされ、構成されている場合、それ以外にKiosk Managerを保護する作業は必要ありません。Logon Manager内のKiosk ManagerプラグインがLogon Managerの同期メカニズムを使用してリポジトリと対話し、専用の接続を必要としないためです。リポジトリ接続がSSLを使用している場合、Logon Managerに組み込まれた暗号化メカニズムが接続セキュリティおよびデータ・セキュリティを確保します。

ユーザーが、他のKiosk Managerセッション内の他のユーザーのアプリケーションにアクセスするのを防ぐため、エンド・ユーザー・ワークステーション保護のための業界標準のベスト・プラクティスに従ってください。特に、ユーザーがKiosk Managerまたは他のユーザーのアプリケーションを終了できないよう、Kiosk Managerの動作に使用するWindowsアカウントから、必要なターゲット・アプリケーションの起動および使用を可能にする権限を除く、すべての権限を取り除いてください。

しばらくの間操作を行わなかった場合にユーザーのセッションをロックする、非アクティブ・タイマーを必ずセットしてください。たとえば、ユーザーが患者の世話をするため、キオスクから離れる場合などです。

4 Provisioning Gatewayの保護

Provisioning Gatewayを使用すると、管理者は、組み込まれたProvisioning Gateway Webコンソールを使用するか、またはOracleおよびサード・パーティのアイデンティティ管理ソリューションと連携して、Logon Managerのユーザーに対するアプリケーションの資格証明のリモート・プロビジョニングを行うことができます。

サーバー側において、Provisioning Gatewayは、Microsoft IISがホストする2つのWebアプリケーションとして動作します。

- Provisioning Gateway Webサービス - Web Consoleサービスまたは外部アイデンティティ管理ソリューションからの(適切なコネクタ・プラグインを使用して)プロビジョニング命令の受信、Logon Managerリポジトリへの書込みなどのリモート・プロビジョニング機能を有効にします。

- Provisioning Gateway Webコンソール - Provisioning Gateway Webサービスに対する管理フロントエンドを提供し、Provisioning Gatewayおよび資格証明プロビジョニングが構成できるようにします。

エンド・ユーザー側では、個々の同期イベントにおいて、Logon ManagerのプラグインがLogon Managerリポジトリに格納されたプロビジョニング命令を読み出し、ユーザーの資格証明ストアからアプリケーションの資格証明を追加、変更、削除することにより命令を実行します。

4.1 クライアント側のProvisioning Gatewayの保護

Logon ManagerがSecuring Logon Managerに従ってセキュアにデプロイされ、構成されている場合、それ以外にクライアント側のProvisioning Gatewayを保護する作業は必要ありません。Logon Manager内のProvisioning GatewayプラグインがLogon Managerの同期メカニズムを使用してリポジトリと対話し、専用の接続を必要としないためです。リポジトリ接続がSSLを使用している場合、Logon Managerに組み込まれた暗号化メカニズムが接続セキュリティおよびデータ・セキュリティを確保します。

4.2 サーバー側のProvisioning Gatewayの保護

サーバー側のProvisioning Gatewayを保護するには、次の手順を実行します。

- 使用しているLogon Managerのリポジトリは、必ず「Logon Managerの保護」に記載されたセキュアな方法で構築、構成してください。

- 前項で説明したProvisioning Gateway Webサービスを、SSL接続のみを許可するように構成します。手順は『Oracle ESSO Suite Plusインストレーション・ガイド』に記載されています。

- Provisioning Gateway Webサービスへの接続に"https"で始まるURLを使用するよう、Provisioning Gateway Web Consoleサービスを構成します。手順は『Oracle ESSO Suite Plusインストレーション・ガイド』に記載されています。

- アカウントのデフォルト名はPMSERVICEです。ただし、使用している環境に応じてアカウント名をつけ、Provisioning Gatewayを構成してカスタマイズされた名前を使用するようにすることができます。

- Oracle Privileged Account Managerと統合する場合、必要なSSL証明書を、Provisioning Gateway ServerマシンのTrusted Root Certificate Authorityに、コンピューター・アカウント・レベルでインストールする必要があります。詳細は『Enterprise Single Sign-On Suiteインストレーション・ガイド』に記載されています。Oracle Privileged Account Managerは、暗号化されていない(非SSL)接続を許可しません。

- 以前のリリースのProvisioning Gatewayからアップグレードする場合、Provisioning Gatewayのイベント・ログ・データの保存にOracle Databaseを使用しているのであれば、アップグレード作業をすべて完了した後で、Provisioning Gateway Consoleにログオンする必要があります。これは、Windowsレジストリに保存された(データベース・ログオン資格証明が含まれる可能性がある)データベース接続文字列を暗号化します。

- Provisioning Gateway Server Webアプリケーションが使用するweb.configファイルのappSettingsセクションは、常に暗号化されている必要があります。手順は『Enterprise Single Sign-On Suiteインストレーション・ガイド』に記載されています。

- Provisioning Gateway Web サービスがリポジトリへの接続に使用するLogon Managerリポジトリをホストしているドメインに、専用のアカウントを作成し、アカウントのアクセス権限をProvisioning Gatewayが適切に機能するために必要な最低限にまで制限してください。次のようなアカウントを作成します。

- サービス・アカウントは、Provisioning Gatewayサービスが属すドメイン内の、Domain Usersグループのメンバーである必要があります。

- サービス・アカウントは、各Provisioning Gatewayサーバー・マシンのローカル管理者グループのメンバーである必要があります。

- アカウントのデフォルト名はPMSERVICEです。ただし、使用している環境に応じてアカウント名をつけ、Provisioning Gatewayを構成してカスタマイズされた名前を使用するようにすることができます。

構成手順は『Enterprise Single Sign-On Suiteインストレーション・ガイド』、『Enterprise Single Sign-On Suite管理者ガイド』、および個々のProvisioning Gatewayに関する文書に記載されており、すべてOracleサポート・ウェブサイトで閲覧できます。

5 Universal Authentication Managerの保護

Universal Authentication Managerは、指紋、近接型/スマート・カード、チャレンジ質問、およびWindowsパスワードをログオン方法としてサポートしています。

注意:

Universal Authentication Managerは、エンタープライズ・モード(中央管理型、リポジトリ・ベース)およびローカル・モード(スタンドアロン)のいずれにおいてもデプロイできます。この項における推奨事項は、管理者が構成したポリシーによりエンタープライズ全体で実施するためのもので、主にUniversal Authentication Managerのエンタープライズ・モードにのみ適用されます。詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。

それぞれの方法の使用にあたっては、次のガイドラインに従い、セキュリティを最大化してください。

- 強度の高いPINを使用します(指紋、近接型/スマート・カードのみ)。

- 選択したログオン方法に関連するPINを要求し、2要素認証を実行します。使用している環境がPINの使用を禁止していないかぎり、PINを構成し、常に要求するようにしてください。

- 最小長を長くする、複数の文字タイプ(大文字、数字、拡張文字)を要求するなど、それぞれのログオン方法のPINポリシーを構成し、PINの複雑度を高めます。

- スマート・カードを使用する場合、スマート・カードの組込みPINを使用するようにUniversal Authentication Managerを構成し、カードに記録されたPINポリシーを再構成して前述のようにPINの複雑性を高めてください。

- スマート・カードを使用する場合、エンタープライズの公開鍵インフラストラクチャ(PKI)を使用するようにカードを構成し、証明書失効プラグインをインストール、構成します。(証明書失効プラグインの詳細は、Oracleサポートにお問合せください。)

- 厳密な認証のみをログオン方法として許可します。WindowsパスワードをUniversal Authentication Managerへのログオン方法として許可しないことにより、総当たり攻撃およびソーシャル・エンジニアリング攻撃の機会を減少させることができます。

- 使用している環境にパスワードが必要な場合、エンタープライズ・ワイドな、複雑性を要求するパスワード・ポリシーを実施します。総当り攻撃の機会を最小限にするため、パスワード・ポリシーは、非常に複雑なパスワードの使用を要求するものである必要があります。

- 一意のチャレンジ質問を実施します。簡単に回答を予測できない、一意のチャレンジ質問を作成、実施してください。

5.1 リポジトリ接続

注意:

Universal Authentication Managerは、エンタープライズ・モード(中央管理型、リポジトリ・ベース)およびローカル・モード(スタンドアロン)のいずれにおいてもデプロイできます。詳細は、Oracle Enterprise Single Sign-On Suite管理者ガイドを参照してください。

Universal Authentication Managerは、ユーザー認証およびポリシー・データを、Active Directoryベースのリポジトリにセキュアに保存します。Universal Authentication Managerとリポジトリ間で保存、転送されるデータは常に暗号化されているため、不正な管理者がリポジトリの内容を直接閲覧しても、データを解読できません。また、セキュリティをさらに強化するために、使用しているリポジトリをSSL接続用に構成することをお薦めします。

5.2 サービス・アカウント(エンタープライズ・モードのみ)

Universal Authentication Managerをエンタープライズ(リポジトリ同期)・モードで動作させる場合、Universal Authentication Managerにリポジトリへの接続および変更を許可するドメイン・アカウントを作成、構成する必要があります。セキュリティを最大化するため、次のことを行う必要があります。

- 『Enterprise Single Sign-On Universal Authentication Manager管理者ガイド』に記載された、最小限の必要な権限割当てなどのリポジトリ構成手順を厳守してください。サービス・アカウントにはいかなる追加権限も付与しないでください。

- Universal Authentication Managerリポジトリ・コンテナを、このサービス・アカウントのみがアクセスでき、その他のユーザーがアクセスできないように構成します。

注意:

また、Universal Authentication Managerを機能させるため、エンド・ユーザー・ワークステーションにおいて、このアカウントにローカルで「サービスとして実行する」権限を与える必要があります。

5.3 ユーザー・ポリシー(エンタープライズ・モードのみ)

Universal Authentication Managerをエンタープライズ・モードでデプロイする場合、構成のデフォルト値に依存するのではなく、各Universal Authentication Managerの設定を明示的に実行するエンタープライズ・ワイドなポリシーを実施し、ユーザーが変更できないようにすることを強くお薦めします。明示的なポリシーが有効である場合、エンド・ユーザーがUniversal Authentication Manager設定を変更することはできません。

5.4 Password Resetとの同期

Universal Authentication Managerをチャレンジ質問ログオン方法でデプロイしていて、Password Resetを使用してチャレンジ質問を一元的に構成し、ユーザーの登録データを保存する場合は、セキュリティを最大化するため、Password ResetのインストールにおいてSSL接続のみを許可するよう設定することをお薦めします。Password Resetとの統合の詳細は、『Oracle Enterprise Single Sign-On Universal Authentication Manager管理者ガイド』を参照してください。

6 Reporting Serviceの保護

Reporting Serviceは各Suiteアプリケーションで発生したイベントを受け取り、Suite管理者が構成したデータベースに格納します。

Reporting Serviceがイベント情報を送受信する通信経路は2つあります。

- SuiteアプリケーションおよびReporting Service - イベント・データは動作中の各Suiteアプリケーションにより、セキュアかつ自動的にReporting Serviceに送られます。サービスにデータを送信する前に、各Suiteアプリケーションはサービスのデジタル署名を検証し、検証に失敗した場合はデータを送信しません。また、アプリケーションからイベント・データを受け取る前にも、サービスはアプリケーションのデジタル署名を検証し、検証が失敗した場合はイベント・データを受け取りません。このため、データ交換が発生した場合、送信を行うアプリケーションとサービス自体の間で双方向の信頼を確立する必要があります。　このため、プログラムによってSuiteアプリケーションまたはReporting Serviceのいずれかに成りすますことは不可能です。

- Reporting Serviceとデータベース - Reporting Serviceは、イベント・データ・リポジトリを保持するデータベースへのセキュアな接続を開くことができます。しかし、セキュアな接続のためにデータベースを構成し、セキュアな接続を可能にする正しい接続文字列をReporting Serviceに提供する必要があります。例:

"Provider=SQLOLEDB;Data Source=myServerName;Initial Catalog=myDatabaseName;Integrated Security=SSPI;Use Encryption for Data=True"

前述の例では、Integrated Security=SSPIおよびUse Encryption for Data=Trueの設定がデータベースへのセキュアな接続を確保します。詳細は、使用しているデータベースシステムのドキュメントを参照してください。レポート作成サービス用のデータベース・インスタンスを構成する手順は、『Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。

7 Anywhereの保護

セキュリティを最大化するため、Anywhereで作成されたカスタム・インストール・パッケージへの署名に使用するSSL証明書を生成することをお薦めします。証明書の作成およびエクスポートの手順については、『Oracle Enterprise Single Sign-On Suite管理者ガイド』を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。