セキュリティー

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

セキュリティー機能

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

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

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

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

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

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

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

パスワード管理

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

変更の管理

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

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

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

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

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

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

http://localhost:8080/idm/user で、エンドユーザーは自己管理機能によりパスワードを変更できる

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

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

エンドユーザーが管理するユーザーのスキーマ属性をセットアップする

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

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

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

パススルー認証

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

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

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

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

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

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

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

ログイン制約規則

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

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

ログイン制約規則の例

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

<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 ログインモジュールグループ

各ログインモジュールグループに含まれるログインモジュール

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

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

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

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

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

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

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

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

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

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

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

cn
mail

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

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

uid
cn

「ログイン相関規則」 －ログイン情報と Identity Manager ユーザーのマッピングに使用されるログイン相関規則を選択します。選択する規則は、LoginCorrelationRule authType を持つ必要があります。

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

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

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

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

物理的または論理的に同一の複数のリソースがある場合 (たとえば、同一の物理ホストに対して定義された 2 つのリソース、NT または AD ドメイン環境内の信頼できるドメインを表す複数のリソース)、システム設定オブジェクト内でそれらのリソースのセットを「共通リソース」として指定することができます。

リソースを共通リソースとして設定することで、あるユーザーを共通リソースの 1 つのリソースに対して認証しながら、共通リソースの別のリソースを使用してそのユーザーの関連付けられた Identity Manager ユーザーにマップすることができます。たとえば、あるユーザーのリソース AD-1 に対するリソースアカウントが、自分の Identity Manager ユーザーにリンクされているとします。ログインモジュールグループでは、ユーザーがリソース AD-2 を認証する必要があることが定義されているとします。AD-1 と AD-2 が、共通リソースとして定義されている場合 (この場合、同じ信頼できるドメイン内にある)、ユーザーが AD-2 に対して正常に認証されると、Identity Manager はリソース AD-1 で同じ accountId を持つユーザーを見つけることによって、関連付けられた Identity Manager ユーザーにマップすることができます。

このシステム設定オブジェクトの属性は次の形式で指定します。

<Attribute name=苗ommon resources�gt;
    <Attribute name='Common Resource Group Name�gt;
        <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 証明書認証の設定

Identity Manager で X509 証明書認証を設定するには、次を実行します。

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

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

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

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

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

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

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

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

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

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

waveset.properties

allowLoginWithNoPreexistingUser

NewUserNameRules.xml

idm/sample/rules

ログイン設定規則の作成とインポート

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

独自の相関規則を追加することもできます。各相関規則は、次のガイドラインに従っている必要があります。

authType 属性はLoginCorrelationRule に設定する必要があります (<LoginCorrelationRule> 要素で 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 製品で暗号化によって保護されるデータの種類と、各データの種類を保護するために使用される暗号を示したものです。


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

1pbeEncrypt 属性または「サーバー暗号化の管理」タスクによりシステム設定オブジェクト経由で設定します。

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

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

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

サーバー暗号化キーはトリプル 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 つのモードで作動します。

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー暗号化の管理

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

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

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

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

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

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

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

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

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

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

セキュリティーの実装

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

セットアップ時

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

デフォルトの Identity Manager 管理者アカウント (Administrator と 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 分を超える値を設定しないでください。

セッションのタイムアウト値を変更するには、次を実行します。

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

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

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

前へ目次次へ
Sun Java System Identity Manager 2005Q4M3 管理ガイド