第 12 章セキュリティー

この章では、Identity Manager セキュリティー機能と、セキュリティー上のリスクを軽減するための手順について詳しく説明します。

以下のトピックで、Identity Manager でのシステムセキュリティーの管理について詳細に説明します。

セキュリティー機能

Identity Manager では、次の機能によってセキュリティー上のリスクを軽減します。

アカウントアクセスの即時無効化－ Identity Manager では、1 回の操作で組織または個々のアクセス権限を無効にすることができます。

ログインセッションの制限－並行して行われるログインセッション数に制限を設定できます。

アクティブリスク分析－ Identity Manager では、非アクティブなアカウントや疑わしいパスワードのアクティビティーなどのセキュリティー上のリスクを絶えずスキャンします。

包括的なパスワード管理－完全で柔軟性に富んだパスワード管理機能によって、完全なアクセス管理が保証されます。

監査およびレポートによるアクセスのアクティビティーの監視－一連のレポートを実行して、アクセスのアクティビティーについての対象を絞った情報を提供します。(レポート機能の詳細については、第 8 章「レポート」を参照。)

管理特権の詳細な制御－ユーザーに、または管理者ロールで定義された一定範囲の管理作業に単一の機能を割り当てることにより、Identity Manager での管理コントロールを付与し管理できます。

サーバーキーの暗号化－ Identity Manager では、「タスク」領域でサーバー暗号化キーを作成および管理できます。

また、システムアーキテクチャーによってセキュリティー上のリスクを可能な限り軽減するようにしています。たとえば、一度ログアウトすると、ブラウザの「戻る」機能を使用しても、以前にアクセスしたページにアクセスすることはできません。

同時ログインセッションの制限

デフォルトでは、Identity Manager ユーザーは同時ログインセッションを行えます。ただし、変更のために System Configuration オブジェクトを開き (こちら)、security.authn.singleLoginSessionPerApp 設定属性の値を編集すれば、並行セッションをログインアプリケーションごとに 1 つに制限できます。この属性は、管理者インタフェース、ユーザーインタフェース、Identity Manager IDE などのそれぞれのログインアプリケーション名に対応した 1 つの属性を含んだオブジェクトです。この属性の値を true に変更すると、強制的に各ユーザーのログインセッションが 1 つに制限されます。

制限された場合、ユーザーは複数のセッションにログインできますが、最後にログインしたセッションだけがアクティブで有効になります。無効なセッションでアクションを実行すると、ユーザーは自動的にセッションから強制的にログオフされ、セッションが終了します。

パスワード管理

Identity Manager は、複数のレベルでパスワード管理を実行します。

変更の管理

ユーザーのパスワードを複数の場所から変更する (「ユーザーの編集」、「ユーザーの検索」、または「パスワードの変更」ページ)

リソースを細分化して選択することにより、ユーザーの任意のリソースでパスワードを変更する

パスワードリセットの管理

ランダムなパスワードを生成する

パスワードをエンドユーザーまたは管理者に表示する

ユーザーによるパスワードの変更

次のサイトで、エンドユーザーは自己管理機能によりパスワードを変更できる

http://localhost:8080/idm/user

オプションとして、エンドユーザーの環境に適するように自己管理ページをカスタマイズする

ユーザーによるデータの更新

エンドユーザーが管理するユーザーのスキーマ属性を設定する

ユーザーによるアクセスの復旧

秘密の質問を使用して、自分のパスワードを変更するアクセス権をユーザーに与える

パススルー認証を使用して、いくつかのパスワードのうちの 1 つを使ってアクセス権をユーザーに与える

パスワードポリシー

パスワードパラメータを定義する規則を使用する

パススルー認証

パススルー認証を使用して、1 つ以上の異なるパスワードによるアクセス権をユーザーと管理者に与えます。Identity Manager は、次のものを実装することによって認証を管理します。

ログインアプリケーション (ログインモジュールグループの集まり)

ログインモジュールグループ (順序づけされた一連のログインモジュール)

ログインモジュール (割り当てられたリソースごとに認証を設定し、認証の成功条件を複数ある中から 1 つ指定する)

ログインアプリケーションについて

ログインアプリケーションはログインモジュールグループの集まりを定義し、さらにログインモジュールグループはユーザーが Identity Manager にログインするときに使用する一連のログインモジュールと順序を定義します。各ログインアプリケーションは 1 つ以上のログインモジュールグループで構成されます。

ログインアプリケーションは、ログイン時に一連のログインモジュールグループをチェックします。設定されているログインモジュールグループが 1 つだけの場合は、そのログインモジュールグループが使用され、それに含まれるログインモジュールがグループ内で定義された順序で処理されます。ログインアプリケーションに複数のログインモジュールグループが定義されている場合には、Identity Manager が各ログインモジュールに適用されるログイン制約規則をチェックして、処理するグループを決定します。

ログイン制約規則

ログイン制約規則は、ログインモジュールグループに適用されます。ログインアプリケーションのログインモジュールグループの各セットの中で、1 つのログインモジュールグループだけは適用されるログイン制約を持つことができません。

セットの中のどのログインモジュールグループを処理するかを決めるにあたって、Identity Manager は最初のログインモジュールグループの制約規則を評価します。評価が成功した場合は、そのログインモジュールグループが処理されます。評価に失敗すると、制約規則が成功するかまたは制約規則を持たないログインモジュールグループが評価された後に使用されるまで、各ログインモジュールグループが次々に評価されます。

ログイン制約規則の例

次に示す場所に基づいたログイン制約規則の例では、規則が HTTP ヘッダーからリクエスト側の IP アドレスを取得し、そのアドレスが 192.168 ネットワーク上にあるかどうかをチェックします。IP アドレスに 192.168. が検出されると、規則は true の値を返し、そのログインモジュールグループが選択されます。


注	ログインアプリケーションに複数のログインモジュールグループが含まれる場合には、ログイン制約規則を持たないログインモジュールグループをセットの最後の位置に置くようにしてください。

コード例 12-1 場所に基づいたログイン制約規則


<Rule authType='LoginConstraintRule' name='Sample On Local Network'>
<match>
<ref>remoteAddr</ref>
<s>192.168.</s>
</match>
<MemberObjectGroups>
<ObjectRef type='ObjectGroup' name='All'/>
</MemberObjectGroups>
</Rule>

ログインアプリケーションの編集

メニューバーで、「セキュリティー」を選択してから「ログイン」を選択して、「ログイン」ページにアクセスします。

ログインアプリケーションリストには次の内容が表示されます。

定義済みの各 Identity Manager ログインアプリケーション (インタフェース)

ログインアプリケーションを構成するログインモジュールグループ

各ログインアプリケーションに設定された Identity Manager セッションのタイムアウト制限

カスタムログインアプリケーションの作成

カスタムログインアプリケーションの削除

ログインモジュールグループの管理

ログインアプリケーションを編集するには、リストからログインアプリケーションを選択します。

Identity Manager セッション制限の設定

「ログインアプリケーションの修正」ページから、Identity Manager ログインセッションごとのタイムアウト値 (制限) を設定できます。時間、分、および秒を選択して、「保存」をクリックします。設定した制限が、ログインアプリケーションリストに表示されます。

各 Identity Manager ログインアプリケーションにセッションタイムアウトを設定できます。ユーザーが Identity Manager アプリケーションにログインすると、現在のタイムアウト設定値を使用し、ユーザーセッションが未使用時にタイムアウトされる将来の日時が計算されます。こうして計算された日付はユーザーの Identity Manager セッションとともに格納されるため、リクエストが実行されるたびにチェックできます。

ログイン管理者がログインアプリケーションのセッションタイムアウト値を変更した場合、その値は将来のすべてのログインに影響します。既存のセッションは、ユーザーがログインしたときに適用されていた値に基づいてタイムアウトします。

HTTP タイムアウトの設定値はすべての Identity Manager アプリケーションに影響し、ログインアプリケーションのセッションタイムアウト値よりも優先されます。

アプリケーションへのアクセスの無効化

「ログインアプリケーションの作成」ページと「ログインアプリケーションの修正」ページで、「無効化」オプションを選択してログインアプリケーションを無効化し、ユーザーがログインできないようにすることができます。ユーザーが無効化されたアプリケーションにログインしようとすると、ユーザーはアプリケーションが現在無効にされていることを伝える代替ページにリダイレクトされます。カスタムカタログを編集することで、このページに表示されるメッセージを編集することができます。

このオプションの選択を解除するまで、ログインアプリケーションは無効にされたままになります。安全措置として、管理者ログインは無効化できません。

ログインモジュールグループの編集

ログインモジュールグループリストには次の内容が表示されます。

各ログインモジュールグループ

ログインモジュールグループを構成する個々のログインモジュール

ログインモジュールグループに制約規則が含まれるかどうか

「ログインモジュールグループ」ページから、ログインモジュールグループを作成、編集、削除できます。リストからログインモジュールグループを選択して編集します。

ログインモジュールの編集

詳細を入力するか、ログインモジュールに関して次のように選択します。(すべてのオプションがどのログインモジュールにも選択できるとは限りません。)

「ログイン成功条件」 －このモジュールに適用する条件を選択します。次の中から選択できます。

「必須」 －成功するにはそのログインモジュールが必要です。成功か失敗かに関係なく、認証はリスト内の次のログインモジュールに進みます。ログインモジュールが 1 つしかない場合、管理者は正常にログインします。

「必要条件」 －成功するにはそのログインモジュールが必要です。成功すると、認証はリスト内の次のログインモジュールに進みます。失敗した場合、認証は続行しません。

「十分条件」 －成功するためにそのログインモジュールが必要ではありません。成功すると、認証は次のログインモジュールに進まず、管理者は正常にログインします。失敗した場合、認証はリスト内の次のログインモジュールに進みます。

「オプション」 －成功するためにそのログインモジュールが必要ではありません。成功か失敗かに関係なく、認証はリスト内の次のログインモジュールに進みます。

「ログイン検索属性」 － (LDAP のみ) 関連する LDAP サーバーへのバインド (ログイン) 試行時に使用する、LDAP ユーザー属性名の順序付けられたリストを指定します。指定したユーザーのログイン名とともに、指定された LDAP ユーザー属性を使用して、一致する LDAP ユーザーを順番に検索します。これによりユーザーは、LDAP の cn 属性または電子メールアドレス属性を使用して Identity Manager にログインできます (Identity Manager で LDAP へのパススルーが設定されている場合)。

たとえば、次のように指定するとします。

cn
mail

そして、ユーザーは gwilson としてログインしようとするとします。このとき LDAP リソースはまず cn=gwilson という条件で LDAP ユーザーの検索を試行します。これに成功すると、そのユーザーによって指定されたパスワードでバインドを試みます。成功しない場合、LDAP リソースは mail=gwilson という条件で LDAP ユーザーを検索します。これにも失敗すると、ログインが失敗します。

値を指定しない場合のデフォルト LDAP 検索属性は次のとおりです。

uid
cn

「ログイン相関規則」 －ユーザーが提供したログイン情報と Identity Manager ユーザーのマッピングに使用されるログイン相関規則を選択します。この規則では、規則で指定されたロジックを使用して Identity Manager ユーザーが検索されます。この規則は 1 つ以上の AttributeConditions を含むリストを返します。このリストは、一致する Identity Manager ユーザーを検索するために使用されます。選択する規則は、LoginCorrelationRule authType を持つ必要があります。認証されたユーザー ID を Identity Manager ユーザーにマッピングするために Identity Manager が実行する手順の説明については、「ログインモジュールの処理ロジック」を参照してください。

「新規ユーザー命名規則」 －ログインの一環として新規 Identity Manager ユーザーを自動的に作成する場合に使用される、新規ユーザー命名規則を選択します。

「保存」をクリックして、ログインモジュールを保存します。一度保存すると、このモジュールをログインモジュールグループ内のほかのすべてのモジュールと関連づけて配置できます。



警告	Identity Manager ログインが複数のシステムから認証を受けるよう設定する場合は、Identity Manager の認証のターゲットとなるすべてのシステムで、アカウントのユーザー ID とパスワードを同じにします。ユーザー ID とパスワードの組み合わせが異なる場合、ユーザー ID およびパスワードが「Identity Manager ユーザーログイン」フォームに入力されたユーザー ID およびパスワードと一致しないシステムで、ログインが失敗します。これらのシステムの中には、ログイン試行回数が一定数を超えるとアカウントを強制的にロックするロックアウトポリシーを持つものもあります。このようなシステムでは、Identity Manager によるユーザーのログインが成功し続けた場合でも、ユーザーアカウントは最終的にロックされます。

ログインモジュールの処理ロジック

コード例 12-2 には、認証されたユーザー ID を Identity Manager ユーザーにマッピングするために Identity Manager が実行する手順を説明する擬似コードが含まれています。

コード例 12-2 ログインモジュールの処理ロジックを説明する擬似コード


if 既存の IDM ユーザーの ID が指定したユーザー ID と同じ
ifその IDM ユーザーにリンクされたリソースがあり、そのリソースのリソース名と認証されたリソースが一致しており、リソースの accountId が、成功した認証 (dn など) によって返されたリソース accountId と一致している場合は、正しい IDM ユーザーを見つけたことになる
otherwise 設定されたログインモジュールと関連付けられた LoginCorrelationRule がある場合
evaluate ログインクレデンシャルを単一の IDM ユーザーにマッピングしているかどうか LoginCorrelationRule を評価する
otherwise ログインが失敗する
otherwise ログインが失敗する
if 指定したユーザー ID が既存の IDM ユーザーの ID に一致しない場合
try リンクされたリソースがあり、そのリソースのリソース名が、成功した認証によって返されたリソースの accountID と一致する IDM ユーザーの検索を試みる
if 見つかった場合は正しい IDM ユーザーを見つけたことになる
otherwise 設定されたログインモジュールと関連付けられた LoginCorrelationRule がある場合
evaluate ログインクレデンシャルを単一の IDM ユーザーにマッピングしているかどうか LoginCorrelationRule を評価する
otherwise ログインが失敗する
otherwise ログインが失敗する

コード例 12-2 では、システムはユーザーのリンクされたリソース (リソース情報) を使用して、一致する Identity Manager ユーザーを見つけようとします。ただし、リソース情報による方法が失敗し、loginCorrelationRule が設定されている場合、システムは loginCorrelationRule を使用して、一致するユーザーを見つけようとします。

共通リソースの認証の設定

論理的に同一のリソースが複数ある (たとえば、信頼関係を共有する Active Directory ドメインサーバーが複数ある) 場合や、複数のリソースがすべて同一物理ホスト上に置かれている場合、これらのリソースは「共通リソース」であることを指定できます。

リソースのグループを一度だけ試行して認証すればよいことが Identity Manager に認識されるように、共通リソースを宣言してください。そのようにしないと、ユーザーが誤ったパスワードを入力した場合、Identity Manager は同じパスワードを各リソースに対して試行します。これにより、ユーザーが誤ったパスワードを 1 回入力しただけでも、ログインが複数回失敗するためにユーザーのアカウントがロックされることになる場合があります。

共通リソースを使用すると、ユーザーは 1 つの共通リソースに対して認証を行うことができ、Identity Manager は自動的に、共通リソースグループ内の残りのリソースに対して、ユーザーの試行とマッピングを行います。たとえば、ある Identity Manager ユーザーアカウントが、リソース AD-1 のリソースアカウントにリンクされているとします。しかし、ログインモジュールグループでは、ユーザーがリソース AD-2 に対して認証を行う必要があると定義されています。

AD-1 と AD-2 が、共通リソースとして定義されている場合 (この場合、同じ信頼できるドメイン内にある)、ユーザーが AD-2 に対して正常に認証されると、Identity Manager はリソース AD-1 で同じユーザーの accountId を持つユーザーを見つけることによって、そのユーザーを AD-1 にマップすることができます。


注	共通リソースグループ内にリストされるすべてのリソースは、ログインモジュールの定義にも含まれている必要があります。共通リソースの完全なリストがログインモジュールの定義にも記載されていない場合、共通リソース機能は正しく動作しません。

共通リソースは、次の形式を使用して System Configuration オブジェクト (こちら) で定義できます。

コード例 12-3 共通リソースの認証の設定


<Attribute name='common resources'>
<Attribute name='Common Resource Group Name'>
<List>
<String>Common Resource Name</String>
<String>Common Resource Name</String>
</List
</Attribute>
</Attribute>

X509 証明書認証の設定

次の情報と手順を使用して、Identity Manager の X509 証明書認証を設定します。

前提条件

Identity Manager で X509 証明書ベースの認証をサポートするには、クライアントとサーバーの 2 方向の SSL 認証が正しく設定されているかを確認します。クライアントの観点では、これは、X509 準拠のユーザー証明書がブラウザにインポートされ (またはスマートカードリーダーで利用可能で)、ユーザー証明書に署名するために使用された信頼できる証明書が、Web アプリケーションサーバーの信頼できる証明書のキーストアにインポートされている必要があることを意味します。

さらに、使用したクライアント証明書がクライアント認証のために選択されている必要があります。

クライアント証明書のクライアント認証オプションが選択されていることを確認するには、次の手順に従います。

Internet Explorer を使用して、「ツール」を選択し、「インターネットオプション」を選択します。

「コンテンツ」タブを選択します。

「証明書」領域で、「証明書」をクリックします。

クライアント証明書を選択し、「詳細」をクリックします。

「証明書の目的」領域で、「クライアント認証」オプションが選択されていることを確認します。

Identity Manager での X509 証明書認証の設定

X509 証明書の認証について Identity Manager を設定するには、次の手順に従います。

管理者インタフェースに Configurator (または同等の権限を持つユーザー) としてログインします。

「設定」を選択し、「ログイン」を選択して、「ログイン」ページを表示します。

「ログインモジュールグループの管理」をクリックし、「ログインモジュールグループ」ページを表示します。

リストからログインモジュールグループを選択します。

「ログインモジュールの割り当て」リストから「Identity Manager X509 証明書ログインモジュール」を選択します。「ログインモジュールグループの修正」ページが表示されます。

ログインの成功条件を設定します。使用可能な値は次のとおりです。

ログイン相関規則を選択します。組み込み規則またはカスタム相関規則を選択できます。(カスタム相関規則の作成については、次の節を参照してください。)

「保存」をクリックして、「ログインモジュールグループの修正」ページに戻ります。

オプションの作業として、ログインモジュールの順序を変更し (複数のログインモジュールがログインモジュールグループに割り当てられている場合)、「保存」をクリックします。

ログインモジュールグループがログインアプリケーションに割り当てられていない場合はここで割り当てます。「ログインモジュールグループ」ページで、「ログインアプリケーションに戻る」をクリックし、ログインアプリケーションを選択します。ログインモジュールグループをログインアプリケーションに割り当てたら、「保存」をクリックします。



注	waveset.properties ファイルで allowLoginWithNoPreexistingUser オプションの値が true に設定されている場合、「Identity Manager X509 証明書ログインモジュール」を設定するときに、新規ユーザー命名規則を選択するようにリクエストされます。この規則は、関連付けられたログイン相関規則によってユーザーが検出されないときに作成される新しいユーザーの命名方法を決定するために使用されます。新規ユーザー命名規則では、ログイン相関規則と同じ入力引数を使用できます。この規則は、1 つの文字列を返し、これが新しい Identity Manager ユーザーアカウントを作成するためのユーザー名として使用されます。サンプルの新規ユーザー命名規則が、NewUserNameRules.xml という名前で idm/sample/rules にあります。

ログイン相関規則の作成とインポート

ログイン相関規則は、Identity Manager X509 証明書ログインモジュールによって、証明書データを適切な Identity Manager ユーザーにマップする方法を決定するために使用されます。Identity Manager には、「X509 証明書 subjectDN を使用した相関」という名前の組み込み相関規則が 1 つ用意されています。

独自の相関規則を追加することもできます。例として、idm/sample/rules ディレクトリにある LoginCorrelationRules.xml を参照してください。各相関規則は、次のガイドラインに従っている必要があります。

authType 属性は LoginCorrelationRule に設定する必要があります。

相関規則は、関連付けられた Identity Manager ユーザーを検出するためにログインモジュールが使用する AttributeConditions のリストのインスタンスを返す必要があります。たとえば、ログイン相関規則は、関連付けられた Identity Manager ユーザーを電子メールアドレスによって検索する AttributeCondition を返す場合があります。

標準の X509 証明書フィールド (subjectDN、issuerDN、有効な日付など)

重要な拡張プロパティーと重要ではない拡張プロパティー

次の証明書引数の命名規則がログイン相関規則に渡されます。

cert.subjectDN

cert.issuerDN

cert.notValidAfter

cert.notValidBefore

cert.serialNumber

ログイン相関規則は、渡された引数を使用して、1 つ以上の AttributeConditions のリストを返します。Identity Manager X509 証明書ログインモジュールは、これらを使用して関連付けられた Identity Manager ユーザーを検出します。

サンプルのログイン相関規則が、LoginCorrelationRules.xml という名前で、idm/sample/rules にあります。

カスタム相関規則を作成したら、その規則を Identity Manager にインポートする必要があります。管理者インタフェースで、「設定」を選択し、「交換ファイルのインポート」を選択して、ファイルインポート機能を使用します。

SSL 接続のテスト

SSL 接続をテストするには、SSL を介して、設定済みのアプリケーションインタフェースの URL (例: https//idm007:7002/idm/user/login.jsp) にアクセスします。セキュアなサイトに入ったことを知らせるメッセージが表示され、Web サーバーに送信する個人用証明書を指定するようにリクエストされます。

問題の診断

X509 証明書を使用した認証に関する問題は、ログインフォーム上でエラーメッセージとして報告されます。詳しい診断情報を得るには、Identity Manager サーバーで次のクラスとレベルのトレースを有効にします。

com.waveset.session.SessionFactory 1

com.waveset.security.authn.WSX509CertLoginModule 1

com.waveset.security.authn.LoginModule 1

HTTP リクエスト内のクライアント証明書の属性が javaxservlet.request.X509Certificate 以外である場合、この属性が HTTP リクエスト内に見つからないことを知らせるメッセージが表示されます。

SessionFactory のトレースを有効にして、HTTP 属性の完全なリストを表示し、X509Certificate の名前を特定します。

Identity Manager デバッグ機能 (こちら) を使用して、LoginConfig オブジェクトを編集します。

Identity Manager X509 証明書ログインモジュールの <LoginConfigEntry> 内の <AuthnProperty> の名前を正しい名前に変更します。

保存して、もう一度試します。

さらに、Identity Manager X509 証明書ログインモジュールをログインアプリケーションから削除して、もう一度追加することが必要な場合があります。

暗号化の使用と管理

暗号化は、メモリーおよびリポジトリ内のサーバーデータだけでなく、サーバーとゲートウェイの間で送信されるすべてのデータの機密性と完全性を保証するために使用されます。

続く節では、Identity Manager サーバーとゲートウェイで暗号化が使用および管理される方法を詳しく説明し、サーバーとゲートウェイの暗号化キーに関する質問を検討します。

暗号化によって保護されるデータ

次の表は、Identity Manager 製品で暗号化によって保護されるデータの種類と、各データの種類を保護するために使用される暗号を示したものです。

表 12-1 暗号化によって保護されるデータの種類
データの種類	RSA MD5	NIST トリプル DES 168 ビットキー (DESede/ECB/NoPadding)	PKCS#5 パスワードベースの暗号化 56 ビットキー (PBEwithMD5andDES)
サーバー暗号化キー		デフォルト	設定オプション1
ゲートウェイ暗号化キー		デフォルト	設定オプション1
ポリシー辞書単語	はい
ユーザーパスワード		はい
ユーザーパスワード履歴		はい
ユーザーの回答		はい
リソースパスワード		はい
リソースパスワード履歴	はい
サーバーゲートウェイ間のすべてのペイロード		はい

1pbeEncrypt 属性または「サーバー暗号化の管理」タスクにより System Configuration オブジェクト (こちら) 経由で設定します。

サーバー暗号化キーに関する質問と答え

続く節では、サーバー暗号化キーのソース、場所、保守、使用についてよく尋ねられる質問に答えていますのでご覧ください。

サーバー暗号化キーとは何ですか ?

サーバー暗号化キーはトリプル DES 168 ビットの対称キーです。サーバーでサポートされるキーには 2 つのタイプがあります。

デフォルトキー －このキーはコンパイル時にサーバーコードに組み込まれます。

ランダムに生成されるキー －このキーは、サーバーの最初の起動時、または現在のキーのセキュリティーに不安がある場合にいつでも生成することができます。

サーバー暗号化キーはどこで維持管理されますか ?

サーバー暗号化キーはリポジトリで維持管理されるオブジェクトです。どのリポジトリにも多数のデータ暗号化キーがある可能性があります。

暗号化されたデータの復号化や再暗号化にどのキーを使用するかを、サーバーはどのようにして認識するのですか ?

リポジトリに格納された各暗号化データの先頭には、そのデータを暗号化する際に使用したサーバー暗号化キーの ID が付加されます。暗号化データを含むオブジェクトがメモリーに読み込まれると、Identity Manager はその暗号化データの ID プレフィックスに関連づけられたサーバー暗号化キーを使用して復号化し、データが変更されている場合には同じキーで再暗号化します。

サーバー暗号化キーはどのようにして更新しますか ?

Identity Manager には「サーバー暗号化の管理」というタスクが用意されています。このタスクを使用することにより、承認されたセキュリティー管理者は次のようなキー管理タスクを実行することができます。

新しい現在のサーバーキーの生成

現在のサーバーキーを使用して暗号化したデータを含む既存オブジェクトに対する、タイプ別の再暗号化

このタスクの使用法の詳細については、この章の「サーバー暗号化の管理」を参照してください。

現在のサーバーキーが変更された場合、既存の暗号化データはどうなりますか ?

何も問題はありません。既存の暗号化データは、引き続き、暗号化データの ID プレフィックスで参照されているキーを使用して復号化や再暗号化されます。新しいサーバー暗号化キーが生成され、そのキーが現在のキーに設定された場合、新たに暗号化されるデータには新しいサーバーキーが使用されます。

複数のキーがあることによる問題を回避するため、またデータの完全性のレベルを高い状態に保つために、「サーバー暗号化の管理」タスクを使用して、現在のサーバー暗号化キーで既存の暗号化データをすべて再暗号化してください。

暗号化キーを使用できない暗号化データをインポートした場合、どのようなことが起こりますか ?

暗号化データを含むオブジェクトをインポートする際、読み込み先となるリポジトリにないキーでデータが暗号化されている場合、データはインポートされますが、復号化されません。

サーバーキーはどのように保護されますか ?

サーバーがパスワードベースの暗号化 (PBE) - PKCS#5 暗号化を使用するよう pbeEncrypt 属性または「サーバー暗号化の管理」タスクによって System Configuration オブジェクトで設定されていない場合には、デフォルトキーを使用してサーバーキーが暗号化されます。デフォルトキーはすべての Identity Manager インストールで同じです。

サーバーが PBE 暗号化を使用するよう設定されている場合は、サーバーを起動するたびに PBE キーが生成されます。PBE キーは、サーバー固有の秘密キーから生成されるパスワードを PBEwithMD5andDES 暗号に渡すことによって生成されます。PBE キーはメモリー内にのみ保持され、それが持続させられることは決してありません。また、共通リポジトリを共有するすべてのサーバーの PBE キーは同じです。

サーバーキーの PBE 暗号化を有効化するには、暗号 PBEwithMD5andDES が使用できなければなりません。この暗号は Identity Manager にはデフォルトでパッケージされていませんが、Sun や IBM が提供する実装をはじめ、多くの JCE プロバイダ実装で使用可能な PKCS#5 標準です。

サーバーキーを安全な外部記憶装置にエクスポートしてもよいですか ?

はい。サーバーキーが PBE 暗号化されている場合、エクスポートの前に、サーバーキーは復号化されてデフォルトキーで再暗号化されます。これにより、それ以後ローカルサーバー PBE キーに依存することなく、同じサーバーまたは別のサーバーにサーバーキーをインポートできるようになります。サーバーキーがデフォルトキーで暗号化されている場合は、エクスポート前の事前処理は行われません。

サーバーキーをサーバーにインポートするときには、サーバーが PBE キー用に設定されていればキーが復号化され、次いで、そのサーバーが PBE キー暗号化用に設定されていればローカルサーバーの PBE キーで再暗号化されます。

どのデータがサーバーとゲートウェイの間で暗号化されますか ?

サーバーとゲートウェイの間で送信されるすべてのデータ (ペイロード) が、ランダムに生成されたサーバーゲートウェイセッション対称 168 ビットキーを使用してトリプル DES で暗号化されます。

ゲートウェイキーに関する質問と答え

続く節では、ゲートウェイのソース、記憶装置、配布、保護についてよく尋ねられる質問に答えていますのでご覧ください。

データの暗号化または復号化に使用するゲートウェイキーとは何ですか ?

Identity Manager サーバーがゲートウェイに接続するたびに、初期ハンドシェークによって新規のランダム 168 ビットのトリプル DES セッションキーが生成されます。それ以降サーバーとゲートウェイの間で送信されるすべてのデータは、このキーを使用して暗号化または復号化されます。サーバー/ゲートウェイのペアごとに一意のセッションキーが生成されます。

ゲートウェイキーはどのようにしてゲートウェイに配布されますか ?

セッションキーはサーバーによってランダムに生成された後、初期サーバーゲートウェイ間ハンドシェークの一環として共有秘密マスターキーによって暗号化されることにより、サーバーとゲートウェイの間でセキュアに交換されます。

初期ハンドシェーク時に、サーバーはゲートウェイに問い合わせて、ゲートウェイがサポートするモードを判別します。ゲートウェイは次の 2 つのモードで作動します。

「デフォルト」モード －サーバーゲートウェイ間の初期プロトコルハンドシェークは、コンパイル時にサーバーコードに組み込まれている、デフォルトの 168 ビットトリプル DES キーで暗号化されます。

「セキュア」モード －共有リポジトリを使用する、ランダムな 168 ビットキーであるトリプル DES ゲートウェイキーが生成され、初期ハンドシェークプロトコルの一環としてサーバーからゲートウェイに送信されます。このゲートウェイキーは他の暗号化キーと同様にサーバーリポジトリに格納され、ゲートウェイによりゲートウェイ自身のローカルレジストリにも格納されます。

セキュアモードでかつサーバーがゲートウェイに接続している場合、サーバーはテストデータをゲートウェイキーで暗号化してゲートウェイに送信します。ゲートウェイはテストデータの復号化を試み、テストデータにゲートウェイ固有のデータを追加してから、元のデータと追加したデータの両方を再暗号化してサーバーに送り返します。サーバーがテストデータとゲートウェイ固有のデータを正常に復号化できた場合、サーバーはサーバーゲートウェイ間用に一意のセッションキーを生成し、それをゲートウェイキーで暗号化してゲ―トウェイに送信します。ゲートウェイはセッションキーを受け取ると、すぐに復号化し、サーバーゲートウェイ間のセッションが持続する間そのキーを保持して使用します。サーバーがテストデータとゲートウェイ固有のデータを正常に復号化できない場合、サーバーはデフォルトキーを使用してゲートウェイキーを暗号化し、ゲートウェイに送信します。ゲートウェイはコンパイル時に組み込まれたデフォルトキーを使用してゲートウェイキーを復号化し、そのゲートウェイキーをレジストリに格納します。その後、サーバーはそのゲートウェイキーを使ってサーバーゲートウェイ間で一意のセッションキーを暗号化し、セッションキーをゲートウェイに送信して、サーバーゲートウェイ間のセッションが持続する間そのセッションキーを使用します。

それ以後、ゲートウェイは自身のゲートウェイキーでセッションキーを暗号化したサーバーからのリクエストのみを受け入れます。ゲートウェイは、起動時にキーのレジストリをチェックします。キーのレジストリがあれば、そのキーを使用します。ない場合は、デフォルトキーを使用します。いったんゲートウェイがレジストリにキーを設定してしまうと、デフォルトキーを使用してセッションを確立することはできなくなります。それにより、だれかが不正なサーバーを設定してゲートウェイに接続することを防げます。

サーバーゲートウェイ間ペイロードの暗号化や復号化に使用するゲートウェイキーを更新できますか ?

Identity Manager には「サーバー暗号化の管理」というタスクが用意されており、承認されたセキュリティー管理者はいろいろなキー管理タスクを実行することができます。そのタスクには、新しい現在のゲートウェイキーの生成や生成された現在のゲートウェイキーによるすべてのゲートウェイの更新などが含まれます。このキーはサーバーゲートウェイ間で送信されるすべてのペイロードを保護する、セッション単位のキーを暗号化するために使用されます。新たに生成されるゲートウェイキーは、システム設定 (こちら) の pbeEncrypt 属性の値に基づいて、デフォルトキーまたは PBE キーで暗号化されます。

ゲートウェイキーはサーバー上とゲートウェイ上のどこに格納されますか ?

サーバー上では、ゲートウェイキーはサーバーキーとまったく同じようにリポジトリに格納されます。ゲートウェイ上では、ローカルレジストリキー内に格納されます。

ゲートウェイキーはどのように保護されますか ?

ゲートウェイキーはサーバーキーの場合と同じように保護されます。サーバーが PBE 暗号化を使用するように設定されている場合、ゲートウェイキーは PBE が生成するキーで暗号化されます。このオプションが false に設定されている場合には、ゲートウェイキーはデフォルトキーで暗号化されます。詳細については、前述の「サーバーキーはどのように保護されますか ?」の節を参照してください。

ゲートウェイキーを安全な外部記憶装置にエクスポートしてもよいですか ?

サーバーキーやゲートウェイキーはどのようにして破棄されますか ?

サーバーキーとゲートウェイキーは、サーバーリポジトリからそれらを削除することによって破棄されます。あるキーを使用して暗号化されたサーバーデータがある間や、そのキーに依存するゲートウェイがある間は、そのキーを削除しないように注意してください。「サーバー暗号化の管理」タスクを使用して、現在のサーバーキーですべてのサーバーデータを再暗号化し、現在のゲートウェイキーをすべてのゲートウェイで同期することによって、古いキーを削除する前に、確実にどの古いキーも使用されていない状態になるようにしてください。

サーバー暗号化の管理

次の図に示すように、Identity Manager のサーバー暗号化機能を使用して、新しい 3DES サーバー暗号化キーを作成してから、3DES または PKCS#5 暗号化を使ってこれらのキーを暗号化できます。サーバー暗号化の管理タスクは、Security Administrator 機能を持つユーザーだけが実行でき、「サーバータスク」タブからアクセスします。

「タスクの実行」を選択し、リストから「サーバー暗号化の管理」を選択して、タスクに関する次の情報を設定します。

「サーバー暗号化キーの暗号化の更新」 －サーバー暗号化キーの暗号化を、デフォルトの 3DES 方式または PKCS#5 方式のどちらを使用して行うかを選択します。このオプションを選択すると、2 つの暗号化方式 (「デフォルト」と「PKCS#5」) が表示されるので、どちらかを選択します。

「新しいサーバー暗号化キーを生成し、現在のサーバー暗号化キーとして設定する」 －新しいサーバー暗号化キーを生成する場合に選択します。このオプションを選択した場合は、それ以降に生成される暗号化データでは、このキーが使用されます。新しいサーバー暗号化キーを生成しても、既存の暗号化データに適用されているキーはそのまま使用できます。

「現在のサーバー暗号化キーを使用して再暗号化するオブジェクトタイプを選択」 － 1 つ以上の Identity Manager オブジェクトタイプ (リソースやユーザーなど) を選択し、現在の暗号化キーを使用して再度暗号化します。

「ゲートウェイ鍵の管理」 －選択すると、ページに次のゲートウェイキーオプションが表示されます。

「新しい鍵を生成し、すべてのゲートウェイを同期させる」
最初からセキュリティー保護されたゲートウェイ環境を有効にする場合は、このオプションを選択します。このオプションは、新しいゲートウェイキーを生成し、それをすべてのゲートウェイに送信します。

「現在のゲートウェイ鍵を使用して、すべてのゲートウェイを同期させる」
新しいゲートウェイ、または新しいゲートウェイキーが送信されていないゲートウェイを同期させる場合に選択します。すべてのゲートウェイが現在のゲートウェイキーを使用して同期されている状況で 1 つのゲートウェイが停止した場合、または新規ゲートウェイにキーを更新させる場合は、このオプションを選択します。

「バックアップ用にサーバー暗号化キーをエクスポート」 －既存のサーバー暗号化キーを XML 形式のファイルにエクスポートする場合に選択します。このオプションを選択すると、追加フィールドが表示され、キーをエクスポートするためのパスおよびファイル名を指定できます。



注	PKCS#5 暗号化を使用しているときに、新しいサーバー暗号化キーを生成および設定することを選択した場合には、このオプションも選択する必要があります。さらに、エクスポートしたキーは、リムーバブルメディアに保存した上で、ネットワークに接続されていない安全な場所に保管する必要があります。

「実行モード」 －このタスクをバックグラウンド (デフォルトオプション) またはフォアグラウンドのどちらで実行するかを選択します。新しく生成したキーを使用して 1 つ以上のオブジェクトタイプを再暗号化する場合には、時間がかかることがあるため、バックグラウンドで実行することをお勧めします。

認可タイプを使用したオブジェクトのセキュリティー保護

通常は AdminGroup 機能で指定した権限を使用して、設定、規則、TaskDefinition などの Identity Manager objectType に対するアクセス権を付与します。ただし、1 つ以上の管理する組織内にある Identity Manager objectType のすべてのオブジェクトに対してアクセス権を付与するのは範囲が広すぎます。

認可タイプ (AuthType) を使用すると、特定の Identity Manager objectType に関して、オブジェクトのサブセットに対するアクセスの範囲を指定したり、制限したりすることができます。たとえば、ユーザーフォームでの選択元になる規則を作成している場合、ユーザーの管理範囲内にあるすべての規則に対しては、ユーザーにアクセスを付与したくない場合があります。

新しい認可タイプを定義するには、Identity Manager リポジトリで AuthorizationTypes 設定オブジェクトを編集し、新しい <AuthType> 要素を追加します。この要素には次の 2 つのプロパティーが必要です。

新しい認可タイプの名前

新しい要素で拡張または範囲の指定を行う、既存の認可タイプまたは objectType

たとえば、Rule を拡張する Marketing Rule という名前の新しい Rule 認可タイプを追加する場合は、次のように定義します。

次に、使用するために認可タイプを有効にするには、その認可タイプを 2 つの場所で参照する必要があります。

新しい認可タイプに対する権限を 1 つ以上与えるカスタム AdminGroup 機能の内部

このタイプであるべきオブジェクトの内部

最初の例は、Marketing Rule に対するアクセス権を与える AdminGroup 機能の定義を示しています。

次の例は、Rule または Marketing Rule に対するアクセス権を付与されているため、ユーザーがオブジェクトにアクセスできるようになる Rule 定義を示しています。


注	親の認可タイプに対して、または認可タイプによって拡張された静的タイプに対してアクセス権を付与されたすべてのユーザーは、子であるすべての認可タイプに対して同じ権限を持つことになります。このため、前の例を使用すると、Rule に対する権限を付与されたユーザーはすべて、Marketing Rule に対しても同じ権限を持つことになります。ただしその逆は成り立ちません。

セキュリティーの実装

Identity Manager 管理者は、設定時とそれ以降に以下の推奨事項に従うことで、保護されたアカウントおよびデータに対するセキュリティー上のリスクをさらに軽減できます。

設定時

HTTPS を使用するセキュアな Web サーバーを通じて Identity Manager にアクセスする。

デフォルトの Identity Manager 管理者アカウント (Administrator と Configurator) 用のパスワードをリセットする。これらのアカウントのセキュリティーをさらに向上させるには、アカウント名を変更します。

Configurator のアカウントへのアクセス権を制限する。

管理者の機能セットをその職務権限に必要な操作のみに制限し、組織階層を設定して管理者の機能を制限する。

Identity Manager インデックスリポジトリのデフォルトパスワードを変更する。

Identity Manager アプリケーションでのアクティビティーの追跡の監査をオンにする。

Identity Manager ディレクトリのファイルに対する権限を編集する。

承認またはほかのチェックポイントを挿入してワークフローをカスタマイズする。

復旧手順を作成して、緊急の際に Identity Manager 環境を復旧する方法を記述しておく。

実行時

デフォルトの Identity Manager 管理者アカウント (Administrator と Configurator) 用のパスワードを定期的に変更する。

システムをあまり使用していないときには Identity Manager からログアウトする。

Identity Manager セッションのデフォルトのタイムアウト期間を設定する、あるいは既存の設定値を知っておく。セッションタイムアウト値は各ログインアプリケーションに別々に設定できるため、異なる可能性があります。

アプリケーションサーバーが Servlet 2.2 準拠の場合、Identity Manager のインストールプロセスでは、HTTP セッションのタイムアウトをデフォルトの 30 分に設定します。この値はプロパティーを編集して変更できますが、セキュリティーを向上させるため、この値を低く設定する必要があります。30 分を超える値を設定しないでください。

セッションのタイムアウト値を変更するには、次の手順に従います。

前へ目次索引次へ
Sun™ Identity Manager 8.0 管理ガイド