test

Sun Identity Manager 8.1 ビジネス管理者ガイド

第 12 章 セキュリティー

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

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

セキュリティー機能

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

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

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

デフォルトでは、Identity Manager ユーザーは複数の同時ログインセッションを持つことができます。ただし、システム設定オブジェクトを開き (「Identity Manager 設定オブジェクトの編集」)、security.authn.singleLoginSessionPerApp 設定属性の値を編集して変更すれば、同時セッションをログインアプリケーションごとに 1 つに制限できます。この属性は、ログインアプリケーション名ごとに 1 つの属性を含むオブジェクトです (管理者インタフェース、ユーザーインタフェース、Identity Manager IDE など)。この属性の値を true に変更すると、ユーザーごとに 1 つのログインセッションに制限されます。

制限された場合でも、ユーザーは 2 つ以上のセッションにログインできます。 ただし、アクティブで有効な状態なのは最後にログインしたセッションのみです。ユーザーが無効なセッションでアクションを実行すると、そのユーザーは自動的にセッションからログオフされ、セッションが終了します。

パスワードの管理

Identity Manager では、複数のレベルでのパスワード管理が可能です。

パススルー認証

パススルー認証を使用して、ユーザーと管理者に 1 つまたは複数の異なるパスワードによるアクセス権を付与します。

Identity Manager は、次の実装によって認証を管理します。

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

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

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

ログイン制約規則

ログイン制約規則は、ログインモジュールグループに適用されます。ログインアプリケーションのログインモジュールグループの各セットについて、ログイン制約規則を適用できないログインモジュールグループが 1 つだけ存在します。

セットのどのログインモジュールグループを処理するかを決定する際、Identity Manager は最初のログインモジュールグループの制約規則を評価します。評価が成功した場合、Identity Manager はそのログインモジュールグループを処理します。評価が失敗した場合、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 セッションとともに格納されるため、リクエストが実行されるたびにチェックできます。

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

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

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

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

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

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

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

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

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

詳細を入力するか、ログインモジュールに関して次のように選択します。ただし、各ログインモジュールですべてのオプションが使用可能なわけではありません。

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

注意 – 注意 –

Identity Manager ログインが複数のシステムで認証されるように設定する場合は、Identity Manager の認証のターゲットとなるすべてのシステムで、アカウントのユーザー ID とパスワードを同じにします。

ユーザー ID とパスワードの組み合わせが異なる場合、ユーザー ID とパスワードが「Identity Manager ユーザーログインフォーム」に入力されたユーザー ID およびパスワードと一致しないシステムで、ログインが失敗します。

これらのシステムの中には、ログイン試行回数が一定数を超えるとアカウントを強制的にロックするロックアウトポリシーを持つものもあります。これらのシステムでは、ユーザーアカウントが最終的にロックされ、ユーザーが Identity Manager を通してログインした場合でも、引き続き成功します。

例 12–2 には、認証されたユーザー ID を Identity Manager ユーザーにマップするために Identity Manager が従う手順について説明する擬似コードが含まれています。

例 12–2 ログインモジュールの処理ロジック


if an existing IDM user’s ID is the same as the specified user ID 

   if that IDM user has a linked resource whose resource name matches the 
   resource that was authenticated and whose accountId matches the resource 
   accountId returned by successful authentication (e.g. dn), then we have 
   found the right IDM user 

   otherwise if there is a LoginCorrelationRule associated with the 
   configured login module 

      evaluate it to see if it maps the login credentials to a single IDM 
      user 

      otherwise login fails 

   otherwise login fails 

if the specified userID does not match an existing IDM user’s ID 

   try to find an IDM user that has a linked resource whose resource 
   name matches the resource accountID returned by successful authentication 

     if found, then we have found the right IDM user 

     otherwise if there is a LoginCorrelationRule associated with the 
     configured login module 

         evaluate it to see if it maps the login credentials to a single 
         IDM user 

         otherwise login fails 

     otherwise login fails

例 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 にもマップすることができます。

注意 – 注意 –

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

共通リソースは、システム設定オブジェクト (「Identity Manager 設定オブジェクトの編集」) で以下の形式で定義できます。

例 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 アプリケーションサーバーの信頼できる証明書のキーストアにインポートされている必要があることを意味します。

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

Procedureクライアント証明書の「クライアント証明書」オプションが選択されていることを確認する

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

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

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

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

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

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

ProcedureX509 証明書認証を設定する

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

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

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

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

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

  6. ログインの成功条件を設定します。

    次の値が有効です。

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

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

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

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

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

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

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

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

    注 –

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

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

Identity Manager の X509 証明書ログインモジュールは、ログイン相関規則を使用して証明書データを該当する Identity Manager ユーザーにマップする方法を決定します。Identity Manager には、Correlate via X509 Certificate subjectDN という名前の組み込み型の相関規則が含まれます。

独自の相関規則を追加することもできます。例として、idm/sample/rules ディレクトリにある LoginCorrelationRules.xml を参照してください。

各相関規則は、次のガイドラインに従っている必要があります。

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

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

cert.field name.subfield name

次の例のような引数名を規則で使用できます。

ログイン相関規則は、渡された引数を使用して、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 サーバーで次のクラスとレベルのトレースを有効にします。

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

ProcedureHTTP リクエスト内のクライアント証明書の属性名を修正する

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

  2. Identity Manager のデバッグ機能 (「Identity Manager デバッグページ」) を使用して、LoginConfig オブジェクトを編集します。

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

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

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

暗号化の使用と管理

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

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

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

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

表 12–1 暗号化によって保護されるデータの種類

データ型  

RSAMD5 

NIST トリプル DES 168 ビットキー (DESede/ECB/NoPadding) 

PKCS#5 パスワードベースの Crypto56 ビットキー (PBEwithMD5andDES) 

サーバー暗号化キー 

 

Default 

設定オプション 

ゲートウェイ暗号化キー 

 

Default 

設定オプション1 

ポリシー辞書単語 

はい 

   

ユーザーパスワード 

 

はい 

 

ユーザーパスワード履歴 

 

はい 

 

ユーザーの回答 

 

はい 

 

リソースパスワード 

 

はい 

 

リソースパスワード履歴 

はい 

   

サーバーゲートウェイ間のすべてのペイロード 

 

はい 

 

サーバー暗号化キーについてのよくある質問

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

質問:

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

回答:

サーバー暗号化キーはトリプル DES 168 ビットの対称キーです。

サーバーでサポートされるキーには 2 つのタイプがあります。

質問:

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

回答:

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

質問:

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

回答:

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

質問:

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

回答:

Identity Manager には「サーバー暗号化の管理」というタスクが用意されています。

このタスクを使用することにより、承認されたセキュリティー管理者は次のようなキー管理タスクを実行することができます。

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

質問:

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

回答:

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

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

質問:

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

回答:

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

質問:

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

回答:

サーバーがパスワードベースの暗号化 (PBE) - PKCS#5 暗号化を使用するよう pbeEncrypt 属性または「サーバー暗号化の管理」タスクを使用してシステム設定オブジェクトで設定されていない場合には、デフォルトキーを使用してサーバーキーが暗号化されます。デフォルトキーはすべての 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 つのモードで作動します。

質問:

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

回答:

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

質問:

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

回答:

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

質問:

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

回答:

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

質問:

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

回答:

ゲートウェイキーは、サーバーキーの場合と同じく、「サーバー暗号化の管理」タスクを使用してエクスポートできます。詳細は、「サーバー暗号化キーについてのよくある質問」を参照してください。

質問:

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

回答:

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

サーバー暗号化の管理

Identity Manager のサーバー暗号化機能を使用すると、新しい 3DES サーバー暗号化キーを作成し、これらのキーを 3DES、PKCS#5、または AES (Advanced Encryption Standard) 暗号化を使用して暗号化できます。サーバー暗号化の管理タスクは、Security Administrator 機能を持つユーザーだけが実行でき、「サーバー暗号化の管理」ページから設定します。

Procedure「サーバー暗号化の管理」ページにアクセスする

「サーバー暗号化の管理」ページを開くには、次の手順に従います。

  1. メニューバーから「サーバータスク」>「タスクの実行」を選択します。

  2. 「利用可能なタスク」ページが表示されたら、「サーバー暗号化の管理」をクリックして「サーバー暗号化の管理」ページを開きます。

    図 12–1 「サーバー暗号化の管理」ページ

    「サーバー暗号化の管理」ページを示す図

Procedureサーバー暗号化を設定する

このページを使用してサーバーとオブジェクトの暗号化、ゲートウェイキー、バックアップオプション、および実行モードを設定します。

  1. 「タスク名」を入力します。

    このフィールドのデフォルトは、「サーバー暗号化の管理」です。デフォルト設定を使用しない場合は、別のタスク名を入力できます。

  2. 次のオプションの 1 つ以上を選択します。

    選択に応じて、以下の処理を行うことができます。

    • サーバー暗号化の管理. サーバー暗号化を設定するには、このオプションを選択します。

      さらに次のオプションが表示されます。

      • 「サーバー暗号化キーの暗号化」。サーバー暗号化キーの暗号化方法を指定する必要があります。暗号化タイプには、トリプル DES、PKCS#5 (DES)、PKCS#5 (AES) が含まれます。

        注 –

        • このページには、システム上でインスタンス化が可能な暗号化タイプのみが表示されます。たとえば、PKCS#5 (AES) がサポートされない場合は、トリプル DES と PKCS#5 (DES) のみが表示されます。

        • PKCS#5 (AES) では、Identity Manager を実行する JVM の「Unlimited Strength Jurisdiction Policy Files」をダウンロードして設定する必要があります。詳細は、Java ベンダーのマニュアルを参照してください。

          また、PKCS#5 (AES) では、Identity Manager を実行する JVM の JCE プロバイダとして、Bouncy Castle JCE provider jar ファイルをインストールして設定する必要があります。この jar ファイルは、Identity Manager のインストールイメージにパッケージ化され、wshome/WEB-INF/lib ディレクトリに配置されます。対応する Java のバージョンで使用するために、2 つの jar ファイル、bcprov-jdk15-137.jar と bcprov-jdk16-137.jar が提供されます。詳細は、Java ベンダーのマニュアルや Bouncy Castle のマニュアルを参照してください。

      • 「新しいサーバー暗号化キーを生成し、現在のサーバー暗号化キーとして設定する」。新しいサーバー暗号化キーの生成を選択します。このオプションを選択した後に暗号化されるデータは、この鍵を使用して暗号化されます。新しいサーバー暗号化鍵を生成しても、すでに暗号化されているデータに適用された鍵には影響しません。

      • 「セキュリティー保護された新規ランダム PBE パスワードの生成」。サーバーが起動するたびにサーバー固有の秘密キーに基づいて新しいパスワードを生成するには、このオプションを選択します。このオプションを選択しなかった場合や、サーバーがパスワードベースの暗号化を使用するように設定されていない場合、Identity Manager はデフォルトキーを使用してサーバーキーを暗号化します。

    • 「オブジェクト暗号化の管理」。再暗号化すべきオブジェクトタイプや使用する暗号化方法を指定するには、このオプションを選択します。

      • 「オブジェクトタイプの暗号化」。表示されている暗号化タイプのいずれかを選択します。暗号化タイプには、トリプル DES (デフォルト)、AES 256 ビットキー、AES、192 ビットキー、AES 128 ビットキーが含まれます。

        注 –

        192 ビットキーまたは 256 ビットキーを使用する AES では、Identity Manager を実行する JVM の「Unlimited Strength Jurisdiction Policy Files」をダウンロードして設定する必要があります。詳細は、Java ベンダーのマニュアルを参照してください。

        このページには、システム上でインスタンス化が可能な暗号化タイプのみが表示されます。たとえば、「Unlimited Strength Jurisdiction Policy Files」を使用する AES 192 ビットキーまたは 256 ビットキーがサポートされない場合は、トリプル DES および AES 128 ビットキーオプションのみが表示されます。

      • 「現在のサーバー暗号化キーを使用して再暗号化するオブジェクトタイプを選択」。表に一覧表示される 1 つ以上の Identity Manager オブジェクトタイプを選択します。

    • 「ゲートウェイ鍵の管理」。ゲートウェイ暗号化を指定するには、このオプションを選択します。

      次のオプションが表示されます。

      • 「ゲートウェイ鍵オプションの選択」。次のオプションのいずれかを選択します。

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

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

      • 「ゲートウェイ鍵のタイプ」。表示されているキータイプのいずれかを選択します。キータイプには、トリプル DES、AES 256 ビットキー、AES、192 ビットキー、AES 128 ビットキーが含まれます。

        注 –

        192 ビットキーまたは 256 ビットキーを使用する AES では、Identity Manager を実行する JVM の「Unlimited Strength Jurisdiction Policy Files」をダウンロードして設定する必要があります。詳細は、Java ベンダーのマニュアルを参照してください。

        このページには、システム上でインスタンス化が可能な暗号化タイプのみが表示されます。たとえば、「Unlimited Strength Jurisdiction Policy Files」を使用する AES 192 ビットキーまたは 256 ビットキーがサポートされない場合は、トリプル DES および AES 128 ビットキーオプションのみが表示されます。

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

      注 –

      PKCS#5 暗号化を使用していて、新しいサーバー暗号化キーを生成および設定するように選択した場合は、このオプションを選択します。さらに、エクスポートした鍵を取り外し可能な媒体に保存し、ネットワーク上ではない安全な場所に保管してください。

  3. 「実行モード」を選択します。

    このタスクは、フォアグラウンドまたはバックグラウンド (デフォルト設定) で実行できます。

    注 –

    新しく生成したキーを使用して 1 つ以上のオブジェクトタイプを再暗号化する場合には、時間がかかることがあるため、バックグラウンドで実行することをお勧めします。

  4. このページでオプションの設定が終了したら、「起動」をクリックします。

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

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

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

新しい認可タイプを定義するには、Identity Manager リポジトリで AuthorizationTypes 設定オブジェクトを編集し、新しい <AuthType> 要素を追加します。

この要素には次の 2 つのプロパティーが必要です。

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

<AuthType name=’Marketing Rule’ extends=’Rule’/>

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

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

例 12–4 AdminGroup 機能の定義


<AdminGroup name=’Marketing Admin’>
  <Permissions>
    <Permission type=’Marketing Rule’ rights=’View,List,Connect,Disconnect/>
  </Permissions>
  <AdminGroups>
    <ObjectRef type=’AdminGroup’ id=’#ID#Account Administrator’/>
  </AdminGroups>
</AdminGroup>

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

例 12–5 Rule 定義


<Rule name=’Competitive Analysis Info’ authType=’Marketing Rule’>
 ...
</Rule>
注 –

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

セキュリティーのベストプラクティス

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

設定時

設定時のセキュリティーリスクを軽減するには、次の推奨事項に従います。

実行時

実行時のセキュリティーリスクを軽減するには、次の推奨事項に従います。

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

Procedureセッションタイムアウト値を変更する

  1. web.xml file を編集します。このファイルは、アプリケーションサーバーのディレクトリツリーの idm/WEB-INF ディレクトリにあります。

  2. 次の行の数値を変更します。


    <session-config>  <session-timeout>30</session-timeout></session-config>