CSA: セキュリティ、パスワード、LDAP、SSL、SSO、XSS、および FIPS (オンプレミスのみ)

ccppmop157
CA PPM システム管理(CSA)を使用して、セキュリティの管理、データベース サーバ パスワードの設定、SSL の有効化、LDAP サーバとの統合、SSO の設定、FIPS の有効化、および外部 URL の管理を行います。
 
2
データベース サーバ パスワードの管理
サーバ パスワードを使用して、各サーバのセキュリティを確保します。 サーバがクラスタ内にある場合は、そのサーバのパスワードによってクラスタ内の他のサーバにアクセスすることはできません。
不正アクセスのリスクを最小限に抑えるには、各サーバのパスワードを定期的に変更します。
  1. データベース サーバのパスワードを変更します。 詳細については、サードパーティ データベースのドキュメントを参照してください。
  2. CSA のパスワードを変更します。
  3. データベース サーバ パスワードを変更した後にサービスを再起動します。
サーバ パスワードの暗号化
サーバのパスワード ファイルを保護するために、パスワード ファイルを暗号化できます。
properties.xml
ファイルを通じてサーバ パスワードの AES 暗号化を有効にできます。 この暗号化方式では、
properties.xml
内のパスワードを暗号化するときに、別個のパスワード(キー)を使用する必要があります。 この暗号化されていないキーは安全に保管してください。
サーバ側での暗号化の利点は、1 つのキーをセキュリティで保護するだけでよいことです。このキーはサーバからアクセス可能なファイル内に格納されます。 キーはサーバの起動時にのみ必要です。
Clarity PPM
を実行すると、暗号化の別のレイヤでキー ファイルをさらに保護することができます。 ファイルがリムーバブル ストレージに格納されている場合は、そのファイルを金庫に隔離してロックすることができます。
サーバ パスワードの暗号化を有効にすると、次回
Clarity PPM
がファイルにアクセスするときに、
properties.xml
内のすべてのクリア テキスト パスワードが暗号化されます。 暗号化を有効にして、
properties.xml
を直接編集する場合は、パスワードをクリア テキストで入力できます。 次回そのファイルがアクセスされるとき、たとえば、サービスがデプロイあるいは開始されるときなどに、クリア テキスト パスワードが暗号化されます。
サーバ パスワードを暗号化するには、有効なキー ファイルを作成します。有効なキー ファイルとは、サーバにアクセス可能で、プロパティ ファイルを含んでいるファイルです。 各サーバには、キー ファイル(ネットワーク上)またはそのコピー(サーバのローカル ディスク上)に対するアクセス権が必要です。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. [ホーム]
    -
    [サーバ]
    をクリックします。
  3. サーバの名前をクリックします。
  4. [セキュリティ]
    タブをクリックします。
  5. オプションを 1 つ選択し、
    [保存]
    をクリックします。
    • システム キーを使用して暗号化を有効にするには、
      [暗号化パスワード]
      フィールドで
      [システム キーを使用する]
      オプションを選択します。 このオプションは、製品に標準装備のハードコード キーを使用します。 これは 2 つのオプションのうち、より安全性の低いオプションです。 1 つの CA PPM インストールのキーが知られることにより、すべてのインストールのキーが判明してしまいます。 このオプションは、偶然の目撃に対処するためのものです。 従業員が悪意なくシステム キーを見た場合、その従業員はパスワードに気づくことはありません。 しかし、侵入者がシステムへのアクセスを試行しており、すでにサーバ上のファイルにアクセスしている場合、パスワードを復号化できる可能性があります。
    • カスタム キー ファイルを使用して暗号化を有効にするには、
      [カスタム キー ファイルを使用する]
      オプションを選択します。
      [キー ファイル]
      フィールドに、カスタム キー ファイルのフル パスとファイル名を入力します。 このオプションでは、キー ファイルを作成し、そのキー ファイルによって、
      Clarity PPM
      を実行しているすべてのサーバにアクセスできるようにする必要があります。 キー ファイルは適切にセキュリティ保護されるため、侵入者は、キーなしでパスワードを復号化するという、事実上不可能な作業に直面することになります。
      カスタム キー ファイルでパスワードを暗号化する場合は、カスタム キー ファイルを変更してください。 これを行わないと、パスワードが失われます(復号化できなくなります)。 この場合、パスワードを再入力する必要があります。
データベース サーバ パスワードの変更
 
以下の手順に従います。
 
  1. データベース上のデータベース サーバ パスワードを変更します。
    詳細については、サードパーティ データベースのドキュメントを参照してください。
  2. CSA 内のデータベース サーバ パスワードを、入力した新しいパスワードに変更します。 CSA にログインします。
  3. 以下の手順に従って、CA PPM アプリケーション(app)サービスと CA PPM バックグラウンド(bg)サービスを停止します。
    1. [ホーム]-[すべてのサービス]をクリックします。
    2. [CA PPM アプリケーション]および[CA PPM バックグラウンド]の隣のチェック ボックスをオンにして、[停止]をクリックします。
      サービスが停止します。
  4. [ホーム]-[サーバ]をクリックします。
  5. [プロパティ]をクリックし、次に[データベース]タブをクリックします。
  6. [内部接続: Niku]セクションで、以下のフィールドに入力します。
    •  
      パスワード
      新しいパスワードを入力します。
    •  
      パスワードの確認
      再度パスワードを入力します。
  7. [保存]をクリックします。
  8. CA PPM バックグラウンド(bg)サービスと CA PPM アプリケーション(app)サービスを再起動します。
    1. [ホーム]-[すべてのサービス]をクリックします。
    2. [CA PPM バックグラウンド](bg)および[CA PPM アプリケーション](app)の隣のチェック ボックスをオンにし、[開始]をクリックします。
Apache Tomcat での SSL (Secure Sockets Layer)の設定
SSL は、ノード間でデータを転送するためのプロトコルです。 このプロトコルでは、暗号化メソッドを使用して不正なアクセスからデータを保護します。暗号化メソッドは、2 つのキー(周知のパブリック キー、およびメッセージの受信者のみが知っているプライベート(秘密)キー)に基づいています。  
  • このセクションの手順では、サードパーティ製のコンポーネントを参照するため、サポートは制限されます。
  • SSL をインストールする場所を決定します。 たとえば、パフォーマンスを向上させるため、アプリケーション サーバではない別のサーバを使用します。
  • Java
    keytool
    コマンドは、SSL 証明書を作成および管理するための一般的な方法です。 その他のツールとコマンドを利用できます。
  • 記載された手順は、多くの環境に適用されますが、全ての環境に適用されるわけではありません。 さらに、一部の環境においては手順が間違っている可能性があります。 具体的には、自己署名証明書(Verisign や Thawte などの認定されたベンダーから購入したものではないもの)を使用する場合があります。 これらの証明書は、本物の証明書をインストールする前に、複数のインストールを必要とする可能性があります。 これらの証明書の名前は異なります。
  • このページ上の手順のみを見るのではなく、SSL 証明書のベンダからの手順に従ってください。 ベンダの指示で、特定の手順またはコマンドを変更しなければいけない可能性があります。
  • テスト目的の場合は、
    Clarity PPM
    に含まれているプライベート キーを使用します。
 HTTP が SSL と共に使用される場合は、HTTPS と呼ばれます。
アプリケーション サービスで SSL を有効にすると、クライアント アプリケーション(Web ブラウザや Open Workbench など)間を移動するデータはすべて暗号化されます。 データは送信前に暗号化され、受信前に復号化されます。 SSL 暗号化を使用しない場合は、未認可のエンティティによってデータが読み取られ、機密情報(ユーザ名やパスワードなど)が盗まれる可能性があります。
 
以下の手順に従います。
 
このページ上の手順は、最初に
Clarity PPM
をインストールする場合にのみ適用されます。 古い証明書の有効期限が切れた場合は、更新された証明書をインストールすることもできます。
4
4
パブリック キーとプライベート キーのペアの生成
Java
keytool
コマンドを使用して、パブリック キーとプライベート キーのペアを生成し、証明書署名要求(CSR)を作成します。
このページの手順では、必要な Java パラメータのみを指定します。 Java コマンドのすべてのパラメータの詳細については、Oracle のドキュメント Web サイトを参照してください。
システムを実稼働させる前に、プライベート キー用のキーストア ファイルを作成し、そのファイルをすべてのアプリケーション サーバに配布します。 すでに別のキーストア ファイルがある場合は、そのファイルを
Clarity PPM
で使用することもできます。
 
以下の手順に従います。
 
  1. Clarity PPM
    アプリケーション サーバを開いて、コマンド プロンプトを開き、以下のコマンドを発行して、パブリック キーとプライベート キーのペアを生成します。
    keytool -genkey -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -storepass keystore
  2. 以下の値を定義します。
    •  
      -genkey
      キーストアが存在していない場合は、このオプションによって生成されます。 キーストアにはパブリック キーとダミーのパブリック キーが含まれます。
    •  
      keystore
      キーストア ファイルのパスとファイル名を指定します。 既定では、キーストアは
      .keystore
      と命名され、
      /<Clarity Home Directory>/config/
      ディレクトリに配置されます。
    •  
      keyalg
      キー ペアの生成に使用するアルゴリズムを指定します(この例では RSA)。
    •  
      storepass
      キーストアの保護に使用されるパスワード(6 文字以上)。 このパスワードは、キーストアにアクセスするすべてのコマンドに提供されます。
  3. 入力を求められたら、組織に関する適切な情報を入力します。
  4. キー パスワードの入力を求められたら、
    Enter
    キーを押します。 キー パスワードとキーストア パスワードは同じにする必要があります。
 自己署名証明書については、生成したプライベート キーから .cer ファイルをエクスポートし、次の手順をスキップしてください。 証明書署名要求(CSR)を生成しないでください。 CSR はこの場合は必要ありません。 ファイルをエクスポートするには、以下のコマンドを使用します。
 
keytool –export -file <file_name.cer> -keystore <ClarityHome/config/.keystore> -storepass keystore
証明書署名要求(CSR)の作成
実稼働システムの場合は、テスト証明書を本物の認定証明書と置き換えます。 認定証明書を取得するには、証明書署名要求(CSR)を作成し、それを証明機関に送付します。 証明機関は、ユーザのパブリック キーを認証する本物の証明書を生成します。 CSR はご使用のシステム情報に基づく本物の SSL 証明書の要求です。 CSR をインストールしないでください。 CSR に対して SSL プロバイダによって提供される本物の証明書をインストールします。 常に SSL プロバイダからの指示に従ってください。 ルートまたは中間の証明書をインストールするとき、特定のコマンドがよく必要となります。 ベンダの指示で、他の証明書をインストールしなければいけない可能性があります。
 
以下の手順に従います。
 
  1. Clarity PPM
    アプリケーション サーバでコマンド プロンプトを開き、以下のコマンドを発行します。
    keytool -certreq -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file ca_ppm.csr
  2. パスワードの入力を求められたら、デフォルトのパスワード(
    keystore
    )を入力します。
  3. 以下の値を定義します。
    •  
      -certreq
      証明書署名要求(CSR)を生成します。
    •  
      keystore
      キーストア ファイルのパスとファイル名を指定します。 既定では、キーストアは
      .keystore
      という名前で、<Clarity Home Directory>/config/ ディレクトリに配置されます。
    •  
      keyalg
      鍵ペアを生成するときに使用するアルゴリズム(RSA)を指定します。
    •  
      file
      生成された証明書要求ファイルの名前(ca_ppm.csr)を指定します。
  4. Web ブラウザを使用して証明機関の Web サイトを開き、生成した CSR ファイルの内容を提示します。
    証明機関を指定するプロセスを使用します。 証明機関から CSR が提供されます。
  5. SSL プロバイダによって提供される新しい証明書(たとえば、ca_ppm.cer)を
    Clarity PPM
    アプリケーション サーバ上にコピーします。
    プライベート キーは影響を受けません。
  6. 別のボリュームにコピーすることで、キーストア ファイルをバックアップします。 本物の証明書を待っている間は、キーストア ファイルを変更しないでください。 変更を加えると、本物の証明書をインポートするとき、問題が発生する可能性があります。 本物の証明書をインポートできない、または誰かがファイルを変更した場合は、やり直すことができます。 新規 CSR の生成をしたり、本物の証明書の新しいコピーを待ったりしないでください。 キーストア ファイルをバックアップ コピーすることにより、時間を節約できます。
証明書のインストール
SSL ベンダから証明書を受け取ったら、証明機関からの返答をインポートし、自己署名証明書を一連の証明書と置き換えます。 その一連の証明書の最後に、パブリック キーを認証する証明機関によって発行された証明書があります。 一連の証明書内の次の証明書は、証明機関のパブリック キーを認証するものです。
一連の証明書を作成するため、証明書をインポートします。 自己署名証明書または自分の証明書サーバ上で作成された証明書の場合は、作成者が証明書を提供します。 作成者は、信頼チェーンを設定し、SSL がベンダから購入した証明書のようにシームレスに動作するようにします。 ルート、中間、その他の証明書、および CSR に対して SSL プロバイダによって提供される本物の証明書をインポートします。
これらの手順に従って、証明機関から発行された署名証明書とペアになるプライベート キーが含まれるキーストア ファイルを作成します。
 
以下の手順に従います。
 
  1. Clarity PPM
    アプリケーション サーバを開いて、コマンド プロンプトを開き、以下のコマンドを発行します。
    keytool -import -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file CA PPM - Source.cer -trustcacerts
    証明書をインポートする前に、証明機関のルート中間証明書をキーストア ファイルにインポートすることが必要な場合があります。 詳細については、サードパーティの証明機関のドキュメントを参照してください。
  2. キーストア パスワードを入力し、Enter キーを押します。
  3. yes
    」と入力します。
アプリケーション サーバへのキーストア ファイルの配布
複数のサーバでアプリケーション サービスが実行されている場合は、すべてのサーバにキーストアを配布します。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. 以下の手順に従って、すべてのサービスを停止します。
    1. [ホーム]-[すべてのサービス]をクリックします。
    2. すべてのサービスを選択し、[停止]をクリックします。
  3. [配布]-[すべて配布]をクリックします。
  4. 各サーバの隣にあるチェック ボックスをすべてオンにして、[配布]をクリックします。
  5. 以下の手順に従って、すべてのサービスを再起動します。
    1. [ホーム]-[すべてのサービス]をクリックします。
    2. すべてのサービスを選択し、[開始]をクリックします。
      アプリケーション サービスを搭載しているサーバにキーストア ファイルが配布されます。
キーストア ファイルの場所とパスワードの設定
クラスタ内の各サーバに対して以下の手順を繰り返してください。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. サーバを変更するには、[プロパティ]アイコンをクリックします。
  3. [セキュリティ]タブをクリックします。
  4. 以下のフィールドに入力し、保存します。
    •  
      SSL キーストア
      キーストア ファイルの場所を入力します。 このフィールドが空欄の場合は、既定値
      <Clarity Home Directory>/config/.keystore
      が使用されます。
    •  
      SSL パスワード
      キーストア パスワードを入力します(既定値は
      keystore
      です)。
    •  
      パスワードの確認
      再度キーストア パスワードを入力します。
  5. 以下の手順に従って、すべてのサービスを停止し、再起動します。
    1. [ホーム]を開き、[すべてのサービス]をクリックします。
    2. [すべて選択]アイコンをクリックしてすべてのサービスを選択し、[停止]をクリックします。
    3. [すべて選択]アイコンをクリックしてすべてのサービスを選択し、[開始]をクリックします。
各サーバ上での SSL の有効化
[SSL 処理]設定では、SSL に関するアプリケーションの動作を決定します。 この設定には、以下のオプションが含まれています。
  •  
    ポート設定から取得(暗黙)
    Web サーバ ポートが有効または無効になっているかどうかに由来します。 この設定は、以前のリリース(バージョン 13.0 より前)からの SSL の動作をエミュレートします。
  •  
    SSL が使用されましたが、外部で処理されました(外部)
    ロード バランサまたはその他の以前のエンドポイントが、アプリケーション サーバの外部で SSL を終了することを指定します。
  •  
    機密情報を含むページのみ HTTPS に切り替え(ハイブリッド)
    Clarity PPM
    が、セキュアおよびセキュアでないページに対して HTTP および HTTPS を自発的に切り替えることを指定します。
  •  
    切り替えなしで HTTP と HTTPS をサポート(両方)
    HTTP および HTTPS の両方が有効になっていることを指定します。 これら 2 つの間を切り替えないでください。
  •  
    HTTPS のみサポート(完全)
    すべての SSL を指定します。 すべての情報は暗号化されます。 必要な場合は、SSL に切り替えます。
  •  
    HTTP のみサポート(なし)
    SSL を指定しません。 すべての情報は暗号化されません。
これらの手順では、[HTTPS のみサポート]オプションで SSL 処理を設定する方法について説明します。 [SSL 処理]オプションで[ポート設定から取得]を選択した場合、各アプリケーション インスタンスに対して以下の追加フィールドの設定が必要です。
  •  
    HTTP 有効
    チェック ボックスをオフにします。
  •  
    HTTPS 有効
    チェック ボックスをオンにします。
SSL を有効にするには、各サーバでこれらの手順を完了させます。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. [ホーム]-[サーバ]をクリックします。
  3. 設定するサーバの名前をクリックします。
  4. [プロパティ]タブをクリックします。
  5. [アプリケーション]タブをクリックします。
  6. [アプリケーション サーバ]セクションで、以下のフィールドに入力します。
    •  
      SSL 処理
      [HTTPS のみサポート]
      オプションを選択します。
  7. サーバに関連付けられている各[アプリケーション インスタンス]
    セクションで、以下のフィールドに入力します。
    •  
      HTTPS ポート
      HTTPS トラフィックに使用するポートを入力します。
    •  
      HTTPS エントリ URL
      (ポートを含めて)HTTPS URL を入力します。
      例:
       
      https://ca_ppm.mycompany.com:8443
  8. 変更を保存します。
  9. 以下の手順に従って、アプリケーション サービスを停止し、再起動します。
    1. [ホーム]
      -
      [すべてのサービス]
      をクリックします。
    2. 停止する各サービスを選択し、
      [停止]
      をクリックします。
    3. 再起動する各サービスを選択し、
      [開始]
      をクリックします。
パスワード保護ページに対する SSL の有効化
ユーザ パスワードを含んでいるページに対してのみ SSL を有効にできます。 この設定により、ユーザは、アプリケーション内のセキュリティ保護されたページと保護されていないページ間で自動的にリダイレクトされます。 リダイレクトは、HTTP および HTTPS を同時に有効にすることで可能になります。 
この設定では、UNIX オペレーティング システム上の両方のポートを 1024 より大きい番号にする必要があります。 ルートのような権限を持つサービスを起動するため SUDO コマンドを使用する場合、例外として、通常のポート番号を使用できます。負荷分散または代理インストールの場合は、この例外は適用されません。 その場合、カスタム ポート範囲を使用します。 非実稼働環境では、ロード バランサ(SSL オフロード オプション)を使用しないことを選択できます。 1024 より小さい従来のポートを使用することも
できます
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. [ホーム]
    -
    [サーバ]
    をクリックします。
  3. 設定するサーバの
    [プロパティ]
    アイコンをクリックします。
  4. [アプリケーション]
    タブをクリックします。
  5. [アプリケーション サーバ]
    セクションで、以下のフィールドに入力します。
    •  
      SSL 処理
      [機密情報を含むページのみ HTTPS に切り替え]
      オプションを選択します。
  6. サーバに関連付けられている各[アプリケーション インスタンス]
    セクションで、以下のフィールドに入力します。
    •  
      HTTP 有効
      チェック ボックスをオンにします。
    •  
      HTTPS 有効
      チェック ボックスをオンにします。
    •  
      HTTPS ポート
      HTTPS トラフィックに必要なポートを入力します。
      UNIX の場合、SUDO コマンドを使用しない限り、HTTP と HTTPS のポート番号を 1024 より大きい値にする必要があります。
    •  
      HTTP エントリ URL
      (ポートを含めて)HTTP URL を入力します。
      例:
       
      http://ca_ppm.mycompany.com:8080
    •  
      HTTPS エントリ URL
      (ポートを含めて)HTTPS URL を入力します。
      例:
       
      https://ca_ppm.mycompany.com:8443
  7. その他のサーバを設定します。
  8. 各アプリケーション サービスを停止し、再起動します。
    1. [サービス]
      タブをクリックします。
    2. 停止する各サービスを選択し、
      [停止]
      をクリックします。
    3. 再起動する各サービスを選択し、
      [開始]
      をクリックします。
SSL による別のホスト上の CA PPM アプリケーション サーバとデータベース サーバ間の安全な JDBC 接続の有効化
情報セキュリティ ポリシーおよびその他のフレームワークへの準拠のため、AWS、Azure、およびその他のクラウド サービスに移行する CA PPM などのアプリケーションを、アプリケーションおよびデータベース レベルで暗号化する必要がある場合があります。
CA PPM のプロパティ ファイルのデータベース接続文字列で特定のパラメータを定義し、SSL を有効化できます。
  1. 上記の手順を実行し、Oracle または SQL Server に SSL 証明書をインストールします。
  2. CA PPM プロパティ ファイルのデータベース要素に以下の属性を追加します。
    1. useURL="true"
      を追加します。
    2. url
      属性で、以下のように
      encryptionmethod=SSL
      を追加します。
    <database id="Niku" vendor="mssql" serviceName="niku" password="xxxxxx" upgradeStatus="upgradeNotNeeded" schemaName="niku" username="xxxxxxx" host="sqlservere.clarity.com" url="jdbc:clarity:sqlserver://sqlserver.clarity.com:1433;DatabaseName=NNNNN_STAGE;InsensitiveResultSetBufferSize=0;ProgramName=Clarity;encryptionmethod=ssl;" driver="com.ca.clarity.jdbc.sqlserver.SQLServerDriver" instanceName="" serviceId="NNNNN_STAGE" jndiDatabaseId="jdbc/NikuDS" useURL="true"/>
  3. Oracle ネットワーク暗号化もサポートされています。 JDBC URL に以下のパラメータを追加します。
     
    DataIntegrityLevel=required
  4. sqlnet.ora
    ファイルを開き、以下のパラメータ設定が含まれていることを確認します。
     SQLNET.ENCRYPTION_SERVER = required
    SQLNET.CRYPTO_CHECKSUM_SERVER = required
    required
    設定によって暗号化または整合性サービスが有効化され、クライアント側でセキュリティ サービスが有効化されていない場合に接続が拒否されます。 これは、データベース クラウド サービスのデータベース展開のデフォルト設定です。
  5. サービスを再起動します。
 ネットワーク接続が SSL で暗号化されていることを確認するには、wireshark パケット トレースを実行し、接続文字列で定義した SQL Server DB の IP アドレスとポート番号でフィルタリングします。
SSL オフローダと連携するための
Clarity PPM
の設定
SSL アプリケーション サービスでは、クライアント アプリケーション間を移動するデータは送信前に暗号化され、受信前に復号化されます。 SSL パケット暗号化により、アプリケーション サーバのパフォーマンスの低下が引き起こされる場合があります。 SSL を処理するには、アプリケーション サーバではなくロード バランサまたはプロキシ サーバを使用します。
外部 SSL オフローダ(ロード バランサやリバース プロキシなど)を使用している場合は、その SSL オフローダによって
Clarity PPM
の HTTP トラフィックが暗号化されます。 このオフローダは HTTPS を使用してクライアントと通信します。 このセットアップによりパフォーマンスを向上させることができますが、オフローダ デバイスと
Clarity PPM
の両方での設定が必要になります。
使用する SSL オフローダが URL リライト機能を備えており、その機能が有効になっていることを確認してください。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. [ホーム]
    -
    [サーバ]
    をクリックします。
  3. 設定するサーバの
    [プロパティ]
    アイコンをクリックします。
  4. [アプリケーション]
    タブをクリックします。
  5. [アプリケーション サーバ]
    セクションで、以下のフィールドに入力します。
    •  
      SSL 処理
      [SSL が使用されましたが、外部で処理されました]
      オプションを選択します。
  6. Clarity PPM
    アプリケーション サーバ インスタンス以外の各アプリケーション インスタンスに対して、以下の設定を行います。
    •  
      HTTP 有効
      HTTP を使用して通信することを指定します。 チェック ボックスをオンにします。
    •  
      HTTP エントリ URL
      Clarity PPM
      とクライアント間のトラフィックに使用する URL を指定します。 複数サーバ環境でロード バランサがフロントエンドであるのと類似した方法で、SSL オフローダが
      Clarity PPM
      のフロントエンドになります。 SSL オフローダ URL はセキュリティで保護されているため、このフィールドには、以下の形式で HTTPS URL を入力します。
      https://<hostname>:CA Portal
    •  
      HTTPS 有効
      SSL オフローダを使用している場合は、このチェック ボックスは適用されません。 チェック ボックスをオフにします。
  7. 変更を保存します。
HTTPS を使用するように Clarity PPM を設定する
 
以下の手順は、クラスタ化されていない Clarity PPM 環境用のものです。
 この手順では、キーストアおよび証明書要求を生成します。 証明書をインポートしたら、CSA で調整を行います。
 負荷分散アーキテクチャの実装では、アプリケーション サーバではなくロード バランサに証明書をインストールして SSL を有効化します。
[アプリケーション]
タブで、
[SSL 処理]
フィールドの値を[SSL が使用されましたが、外部で処理されました]
に変更します。
 
以下の手順に従います。
  1. CA PPM をホストしているサーバにログインします。
  2. プライベート キーを格納するディレクトリに移動します。 例:
    C:\ppm150101
  3. ここから、ステップ 5 のプロンプトに対する回答を事前に準備します。
  4. コマンド「keytool -genkey -keystore C:\ppm15101\keystore.jks -keyalg RSA -storepass changeit」でキーストアを作成します。
    「Keystore.jks」がキーストアの名前で、パスワードが「changeit」であることに注意してください。 このコマンドを実行するときは、パスワードを強固なものに変更します。
  5. サーバおよび組織の詳細を入力する複数のプロンプトが表示されます。 ステップ 3 で準備した情報を使用します。 認証機関はすべての必要な詳細を提供できます。 すべてのプロンプトに自分で回答できない場合は認証機関にお問い合わせください。
  6. 姓と名
    を求められた場合は、名前に
    http://
    または
    https://
    を使用せずにサーバの完全な名前を入力します。
  7. 証明書要求を生成します。
    keytool -certreq -keystore C:\ppm15101\keystore.jks -keyalg RSA -file myRequest0.cer
  8. サーバ用の証明書を取得するには、このファイルを認証機関に送信します。
  9. キーストアにインポートする前に、これらの証明書の準備ができていることを確認します。
    1. サーバ証明書
    2. 中間証明書
    3. ルート証明書
      (ルートおよび中間証明書については認証機関に確認してください)
  10. ルート証明書をインポートします(キーストア名、パス、証明署名およびパッチ、その他のパラメータを置き換えます)。
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file root.cer -trustcacerts -alias root
  11. 中間証明書をインポートします。
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file intermediate.cer -trustcacerts -alias intermediate
  12. サーバ証明書をインポートします。
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA file server.cer -trustcacerts -alias server
CSA での変更
  1. CSA にログインし、
    [セキュリティ]
    タブをクリックします。
  2. [SSL キーストア]
    フィールドに、キーストアの完全修飾パスを入力します。
  3. [SSL パスワード]
    および
    [パスワードの確認]
    フィールドに入力します。
  4. [アプリケーション]
    タブをクリックします。
  5. [SSL の処理]
    [切り替えなしで HTTP と HTTPS をサポート]
    に変更します。
  6. [アプリケーション インスタンス: アプリ]
    セクションで、
    [HTTPS 有効]
    を選択します。
  7. [HTTPS ポート]を CA PPM アプリケーションに割り当てられた番号に変更します(これは組織によって異なります)。 たとえば、ポート番号は 8043 になります
  8. [HTTPS エントリ URL]を、キーストア生成中に指定した正確なサーバ名に変更します。
  9. アプリケーション サービスを再起動します。
  10. HTTPS を使用して移動することで、HTTPS が動作することを確認します(正しいポート番号と URL を使用してください。 たとえば、URL は「https://servername.organization.com:8043/」となります)。
  11. [SSL 処理]を[HTTPS のみサポート]に変更します。
  12. アプリケーション サービスを再起動します。
誤った方法で証明書をインポートしてしまい、削除したい場合は、「keytool -keystore c:\ppm15101\keystore.jks -alias root -delete」というようなコマンドを使用できます。
キーストアのすべての証明書を一覧表示する非常に便利なコマンドは「keytool -keystore c:\ppm15101\keystore.jks -list" and to turn verbose on, use "keytool -keystore c:\ppm15101\keystore.jks -list -v」です。
最後に、ここに記載されているパスは Windows オペレーティング システムのものです。 アプリケーションがそのオペレーティング システム上でビルドされている場合、Linux のパス指定規則に変更します。 パス以外はすべて同じままです。
Clarity PPM
と LDAP (ライトウェイト ディレクトリ アクセス プロトコル)との統合
すべてのアプリケーションに対するアクセスを許可するために Lightweight Directory Access Protocol (LDAP)インターフェースを使用すると便利な場合があります。 セントラル ディレクトリ サーバによってアクセスを制御することにより、ユーザはすべてのアプリケーションに対して 1 つのユーザ名とパスワードを持つことができます。 以下のオプションをサポートしています。
  • LDAP v2 (シンプル)プロトコルでは、認証(クリア テキストまたは SSL)、バインディング、および検索などを含む、LDAP 機能の小さいサブセットを使用します。
  • ページ結果に対する LDAP v3 コントロール(RFC 2696 の定義に準拠)。
ディレクトリ サーバと
Clarity PPM
の間でユーザを同期するために、ディレクトリ サーバからユーザが一括して取得されます。
Clarity PPM
の LDAP 構成設定で、バッチ サイズを指定します。
セッション ベースのクッキーは、セッション データへのアクセスに使用されるトークンを受け渡します。 トークンはキャッシュ(単一アプリケーション環境の場合)、またはデータベース(クラスタ化環境の場合)に留まります。 ユーザの Web ブラウザは
Clarity PPM
からクッキーを受け入れる必要があります。クッキーはセッション ベースであるため、ディスクに書き込まれません。 ユーザがログアウトすると、クッキーに対応する、データベースとキャッシュ内のセッション情報が削除されます。
Clarity PPM
を LDAP サーバと統合すると、以下のような利点があります。
  • ユーザ名とパスワードの管理の簡略化。 IT は、1 人のユーザに対して 1 つのユーザ名とパスワードのペアを管理するだけで済みます。
  • 認証のサポート。 IT 担当者は、ユーザの認証問題が発生する可能性がある 1 か所をサポートするだけで済みます。
  • 操作性の改善。 ユーザは 1 つのユーザ名とパスワードを記憶するだけで済みます。
  • ユーザ管理の改善。 ユーザ名および電子メール情報を LDAP に格納できます。
  • セキュリティの強化。 1 つのユーザ名とパスワードを使用することにより、複雑なパスワードの使用や、それらの頻繁な変更が容易になります。 記憶するパスワードが 1 つだけなので、ありふれたパスワードを選択する可能性が低くなります。
LDAP - 新規ユーザと変更されたユーザの同期ジョブは、LDAP エントリと同期します。 その後、ジョブが正常に実行された最後の日時と情報を、MN_DIRECTORY_SERVERS データベース テーブルに格納します。 次のバックグラウンド ジョブの実行中に、ジョブによってエントリが同期されます。 ジョブにより、タイム スタンプが CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE プロパティの値より大きい、最近作成または変更されたユーザ エントリのみが同期されます。
  •  
    Clarity PPM
    では、グループ内のユーザ、または CSA で指定した検索で検出されたユーザが、LDAP でアクティブであるか、非アクティブであるかを確認しません。 
    Clarity PPM
    では、ユーザが
    Clarity PPM
    グループに存在しているかどうか、または検索対象の属性が
    Clarity PPM
    に存在しているどうかについてのみ確認します。
  •  
    Clarity PPM
    では、LDAP 内のネスト グループは認識されません。 「
    LDAP - 新規ユーザと変更されたユーザの同期
    」ジョブまたは「
    LDAP - 古いユーザの同期
    」ジョブを実行する前に、CSA の検索で検出可能な PPM グループがユーザと関連付けられていることを確認します。 LDAP 同期ジョブの実行時には、LDAP の
    Clarity PPM
    グループ内のネスト グループのユーザは確認されません。
  • LDAP サーバで非アクティブ化されているユーザは、次回の同期ジョブの実行時に、
    Clarity PPM
    で非アクティブ化されます。 ユーザが LDAP サーバで再アクティブ化された場合、そのユーザは
    Clarity PPM
    で再アクティブ化されません。リソースを再アクティブ化する必要があります。
LDAP を実装する前に、互換性のある LDAP サーバを選択してください。
 
アプリケーション サービスを実行している各サーバで LDAP 認証を行うように
Clarity PPM
をセットアップします。 以下の手順を完了するには、LDAP サーバを設定します。
Clarity PPM
サーバのクラスタがある場合は、クラスタ内の各サーバでこれらの手順を繰り返してください。
 
以下の手順に従います。
 
  1. LDAP ユーザとして
    Clarity PPM
    へのアクセスに使用できるリソースを、テスト ユーザとして作成します。
    このテスト ユーザの
    Clarity PPM
    でのユーザ ID は、Microsoft Active Directory のユーザの LDAP sAMAccountName、またはその他の LDAP 実装の UID と同一である必要があります。
  2. Clarity PPM
    へのアクセスが許可されている LDAP ユーザの定義方法を決定します。
    グループを指定するか、LDAP で属性/値の組み合わせを作成するか、またはその両方を行うことによって、グループ認証を有効にできます。 この設定は、CSA のセキュリティ
    [サーバ: プロパティ]
    ページから定義できます。
  3. LDAP サーバ プロパティを定義します。
  4. 認証する
    Clarity PPM
    をセットアップします。
  5. Clarity PPM
    サービスをすべて停止し、再起動します。
LDAP サーバのプロパティの定義
CSA では、LDAP サーバのプロパティを定義できます。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. セットアップするサーバの
    [プロパティ]
    アイコンをクリックします。
  3. [セキュリティ]
    タブをクリックします。
  4. [LDAP サーバ]
    セクションで、以下のフィールドに入力します。
    •  
      URL:
      LDAP サーバの URL を定義します。 LDAP サーバが SSL 対応の場合は、URL で LDAPS プロトコル(既定の LDAP プロトコルではなく)を使用します。
    •  
      ルート コンテキスト:
      LDAP ネーミング コンテキストを定義します(例: "ou=People, dc=niku, dc=com")。
    •  
      ユーザの検索:
      LDAP サーバにバインドするための適切な認証情報を使用してユーザ名を定義します。
    •  
      パスワード:
      パスワードを定義し、[パスワードの確認]フィールドで確認します。
    •  
      検索フィルタ:
      検索フィルタ文字列を定義します(RFC 2254 の定義に準拠)。
    •  
      日付/時刻形式:
      LDAP サーバで使用される日時の形式を定義します。
    •  
      グループ名:
      グループ認証を有効にします。 グループ名を入力し、[グループ識別子]フィールドでグループ ID を入力します。
    •  
      LDAP 以外のユーザを許可:
      別の認証方式による
      Clarity PPM
      へのアクセスを許可することを指定します。
    •  
      グループ メンバシップの使用
      : 「LDAP - 古いユーザの同期」ジョブのパフォーマンスを改善する必要がある場合に、このチェック ボックスをオンにします(既定ではオフ)。 ジョブでは同期の際にグループ メンバシップが使用され、LDAP 内でのユーザからグループへの逆関係が必要になります。 既定値は
      memberOf
      ですが、次のフィールドで別の値を指定できます。
    •  
      ユーザのグループ識別子
      : 既定の
      memberOf
      属性以外の値を指定する必要がある場合、LDAP でサポートされているグループ識別子をここに入力します。
       
      [グループ メンバシップの使用]
      および
      [ユーザのグループ識別子]
      は 15.5.1.1 パッチで利用可能です。
  5. [保存]
    をクリックします。
  6. 以下の手順に従って、すべての
    Clarity PPM
    サービスを停止し、再起動します。
    1. [ホーム]
      -
      [すべてのサービス]
      をクリックします。
    2. [すべて選択]
      アイコンをクリックし、各サービスの隣のチェック ボックスをオンにして、
      [停止]
      をクリックします。
    3. [すべて選択]
      アイコンをクリックし、各サービスの隣のチェック ボックスをオンにして、
      [開始]
      をクリックします。
  7. [保存]
    をクリックします。
  8. CSA で、
    [アプリケーション]
    タブをクリックします。
  9. [アプリケーション サーバ]
    セクションで、
    [LDAP の使用]
    を選択し、
    [保存]
    をクリックします。
LDAP 同期
以下の LDAP 同期ジョブは、
Clarity PPM
と LDAP を同期するために連携して動作します。
  •  
    LDAP - 新規ユーザと変更されたユーザの同期ジョブ
    このジョブでは、LDAP の
    Clarity PPM
    グループに追加されるユーザを同期することで、LDAP レコードと
    Clarity PPM
    レコードを同期します。 また、このジョブでは、ユーザを
    Clarity PPM
    サーバ上でアクティブにします。 検索フィルタ オプションを使用している場合に、属性を
    Clarity PPM
    で使用される属性に変更すると、そのユーザは
    Clarity PPM
    サーバでアクティブになります。 次回のジョブの実行時にアクティブ化されます。 このジョブはその後、ジョブが正常に実行された最後の日時を CMN_DIRECTORY_SERVERS データベース テーブルに格納します。 ジョブは、最近に作成または変更されたユーザ エントリのみを同期します。 同期するには、タイム スタンプが CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE フィールドの値より大きい必要があります。
  •  
    LDAP - 古いユーザの同期ジョブ
     
このジョブは、LDAP サーバ上の LDAP
Clarity PPM
グループから削除されたユーザ、または、選択された検索属性がレコードに含まれていないユーザを非アクティブ化します。 このジョブは、LDAP の
Clarity PPM
グループ内で見つかったユーザ、または CSA で指定した検索で見つかったユーザが、LDAP でアクティブであるか、非アクティブであるかについて確認しません。 このジョブを使用して
Clarity PPM
のユーザを非アクティブにするには、LDAP の
Clarity PPM
グループからユーザを削除するか、CSA で指定されている検索属性を削除します。 CSA の[LDAP サーバ]および[LDAP 属性マッピング]セクションが適切に設定されている場合、これらの同期ジョブは適切に機能します。
各ジョブのスケジュールを選択する必要があります。
 
ベスト プラクティス:
これらのジョブは夜間に実行します。
データベースをディレクトリ サーバと同期させるには、CMN_DIRECTORY_SERVERS データベース テーブルからすべての行を削除し、再度バックグラウンド ジョブを実行します。 特定のグループに対してジョブを実行し、そのグループのユーザのレコードのみが影響を受けるようにすることもできます。
LDAP - 新規ユーザと変更されたユーザの同期ジョブによる完全同期の強制実行
LDAP - 新規ユーザと変更されたユーザの同期
ジョブの動作を上書きすることが必要な場合があり、完全同期を強制することができます。
 
以下の手順に従います。
 
  1. CMN_DIRECTORY_SERVERS データベース テーブルから行を削除します。
  2. 再度ジョブ(またはスケジュール)を実行します。
LDAP のトラブルシューティング
ここでは、LDAP に関する一般的な問題、およびそれらへの対処方法について説明します。
  • LDAP 認証プロセスをデバッグするには、セキュリティ コンポーネントによってログ記録されたデバッグ メッセージを有効にします。 1 つのバックグラウンド サービスでデバッグ メッセージを有効化し、その他のバックグラウンド サービスをすべて停止します。 バックグラウンド サービスを再起動して変更を有効にし、ログ ファイル(bg-ca.log)を確認します。
  • Clarity PPM
    ログでエラー メッセージを確認すると、LDAP 固有のエラー コードが表示される場合があります。
    LDAP 固有のエラー コードの説明については、サードパーティの LDAP ドキュメントを参照してください。
  • LDAP ユーザ名とパスワードを使用して
    Clarity PPM
    にログインできない場合は、以下の項目を検討してください。
    • Clarity PPM
      でもアクティブなアカウントとして通用する、アクティブな LDAP アカウントを使用していますか。
    • CSA のアプリケーション サーバのプロパティ ページで[LDAP の使用]フィールドをオンにして、LDAP 設定を有効にしましたか。
    • CSA のセキュリティ サーバのプロパティ ページで、[ユーザの検索]フィールドに正しいユーザ ID を入力し、[パスワード]フィールドに正しいパスワードを入力しましたか。
    • 特定のメッセージの詳細については、ログ ファイルを参照してください。
    • LDAP - 古いユーザの同期
      ジョブおよび
      LDAP - 新規ユーザと変更されたユーザの同期
      ジョブの処理時間は、ディレクトリ サービスから
      Clarity PPM
      にロードされるユーザ数に応じて異なります。 特に、数が多い場合は処理時間が長くなることがあります。
LDAP 同期ジョブのトラブルシューティング
LDAP 同期ジョブや認証プロセスが予想どおりに動作しない場合は、以下のいずれかのタスクを実行してください。
  • /niku/Clarity/logs/ldapsync ディレクトリ内の LDAP 同期ログ ファイルを確認します。
  • *users*.xml ファイルを確認します。 このファイルには、LDAP サーバから抽出したユーザ名のリストが含まれています。 このファイルがない場合は、
    Clarity PPM
    と LDAP サーバ間の通信に失敗しています。
  • *sync*.xml ファイルを確認します。 このファイルには、ゲートウェイ ユーザ インポート セッションの結果が含まれています。 このファイルがない場合は、
    Clarity PPM
    とゲートウェイ間の通信に失敗しています。
  • 以下の手順に従って、セキュリティ コンポーネント内のデバッグ メッセージを有効にします。
    1. bg-logger.xml
      を編集し、
      com.niku.security
      カテゴリを追加します。
    2. 優先度を
      debug
      に設定します。
    3. CA PPM バックグラウンド(bg)サービスを再起動して、変更を有効にします。
    4. bg-ca.log ファイルを確認します。
    5. クラスタ内に複数の bg サービスがある場合は、1 つを除きすべてを停止します。 1 つの bg サービスのみを実行することで、デバッグ対象のサーバでジョブが確実に実行されている状態にします。 すべてのサービスでデバッグを個別に有効にすることもできます。
LDAP 同期ログの確認
以下のディレクトリにある LDAP 同期トランザクション ログを確認します。
<Clarity Home Directory>/logs/ldapsync
新規ユーザと変更されたユーザ ジョブに関連するログ ファイルは以下のとおりです。
  • ldapusers_nm_*.xml: ディレクトリ サーバで検出された、
    Clarity PPM
    と同期させるユーザのリスト。
  • ldapsync_nm_*.xml: この同期ジョブに対する成功/エラー/警告メッセージのリスト。
LDAP - 古いユーザの同期
ジョブに関連するログ ファイルは、以下のとおりです。
  • ldapusers_ia_*.xml:
    Clarity PPM
    で非アクティブ化するユーザのリスト。
  • ldapsync_ia_*.xml: この同期ジョブに対する成功/エラー/警告メッセージのリスト。
デバッグ メッセージの有効化
セキュリティ コンポーネントは、デバッグ メッセージをログに記録します。 デバッグ メッセージを有効化しているもの以外の、実装内の CA PPM バックグラウンド(bg)サービスをすべて停止します。 CA PPM バックグラウンド(bg)サービスを再起動して変更を有効にし、ログ ファイル(bg-niku.log)を確認します。
 
以下の手順に従います。
 
  1. CSA にログインします。
  2. [ホーム]-[サーバ]をクリックします。
  3. デバッグ メッセージを有効にするサーバの[ログ]アイコンをクリックします。
  4. [設定の編集]サブタブをクリックします。
  5. [カテゴリ]セクションで、[カテゴリの追加]をクリックします。
  6. 新しい項目に対して以下の値を入力します。
    •  
      名前
      com.niku.security
      と入力します。
    •  
      優先度
      ドロップダウンから[デバッグ]を選択します。
  7. 変更を保存します。
    デバッグ メッセージが有効になります。
LDAP と SSL の設定
LDAP サーバをセキュア ソケット レイヤー(SSL)で実行している場合は、LDAP と SSL を設定する必要があります。
Clarity PPM
管理者は、CA PPM バックグラウンド(bg)サービスを実行しているコンピュータに、LDAP サーバ用の信頼できるセキュリティ証明書をインストールします。 証明書をインストールするには、Java 7 JDK に標準装備されている keytool を使用します。
コマンド プロンプトで以下のコマンドを発行します。
keytool -import -v -trustcacerts -alias <alias> -file <certificate file name> -keystore cacerts
 
例:
 
$cd $JAVA_HOME/jre/lib/security $keytool -import -v -trustcacerts -alias NikuLdapServer -file TrustedRootCert.der -keystore cacerts
クラシック
Clarity PPM
のシングル サインオン(SSO)の設定
シングル サインオン(SSO)は、単一のユーザ名とパスワードを使用して、複数のシステムへのユーザ アクセスを許可する認証プロセスです。 SSO により、サーバは LDAP ディレクトリの情報を使用してユーザの身元を認証すると、ユーザのアクセス権限に応じて、リクエストされた情報へのアクセスを許可します。
SSO をセットアップして、ユーザの認証を行う内部ポータル アプリケーションに
Clarity PPM
を統合することができます。 SSO は、アプリケーション間で切り替えるときに、ユーザ名とパスワードを繰り返し入力する手間を省きます。 ポータル アプリケーションには、その他の内部アプリケーションへのリンク(URL)があります。 ポータル アプリケーションを一度呼び出すと、ユーザは認証ダイアログ ボックスに入力することなく、直接、アプリケーションへと進むことができます。 ポータル アプリケーションに組み込まれている SSO プラグインは、ユーザをポータルにログインさせ、次に、適切なアプリケーションへと進めます。 この方法では、ユーザはページをブックマークできないため、ログインしないとそのページに戻ることができません。
SSO には、以下のような利点があります。
  • ユーザ名/パスワードの管理。 IT は、1 人のユーザに対して 1 つのユーザ名/パスワードを管理するだけで済みます。
  • 認証のサポート。 IT 担当者は、ユーザの認証問題が発生する可能性がある 1 か所をサポートするだけで済みます。
  • 操作性 ユーザは 1 つのユーザ名とパスワードのみを記憶し、1 回ログインするだけで済みます。
  • セキュリティ。 1 つのユーザ名とパスワードを使用することにより、複雑なパスワードの使用や、それらの頻繁な変更が容易になります。 記憶するパスワードが 1 つだけなので、ありふれたパスワードを選択する可能性が低くなります。
ベスト プラクティス
: CA SiteMinder または他の SSO ソフトウェアを使用する場合は、URL 内で山かっこ文字(< と >)の使用を許可するよう設定します。 たとえば、SiteMinder を使用する場合は、CssChecking を無効にします。 そうしないと、 山かっこが含まれている URL を
Clarity PPM
が受け渡すときにエラーが発生します。 山かっこは URL 内に含まれることがあり、<、<=、>、>= など、条件を使用するプロセスによって作成される可能性があります。
 
以下の手順に従います。
 
  1. SSO サーバとプロキシ サーバを設定し、それらが
    Clarity PPM
    を指し示して、有効な
    Clarity PPM
    ユーザ名を含む認証トークンを渡すようにします。
    SSO サーバを設定して、エントリ URL を以下のようにします。
    http://<server>/niku/nu#action:npt.overview
  2. CSA にログインし、[ホーム]-[サーバ]をクリックします。
  3. セットアップするサーバの名前をクリックします。
  4. [アプリケーション]サブタブをクリックします。
  5. LDAP を使用するには、[アプリケーション サーバ]セクションで、[LDAP の使用]チェック ボックスをオンにします。
    LDAP を有効にすると、非ブラウザ クライアントは同じユーザ名とパスワードを使用します。
  6. [アプリケーション インスタンス]セクションで、[シングル サインオンを使用]チェック ボックスをオンにして、[保存]をクリックします。
  7. [セキュリティ]タブをクリックします。
  8. [暗号化]セクションで、以下のフィールドに入力します。
    •  
      SSL キーストア
      キーストア ファイルへのパスを定義します。
      例:
      <pathtokeystore>/server.keystore
    •  
      SSL パスワード
      キーストア パスワードを定義します。 入力したら、[パスワードの確認]フィールドで確認します。
  9. [LDAP サーバ]セクションで、以下のフィールドに入力します。
    •  
      URL
      LDAP サーバの URL を定義します。
    •  
      ルート コンテキスト
      LDAP サーバのネーミング コンテキストを定義します(例: "u=People, dc=niku, dc=com")。
    •  
      ユーザの検索
      LDAP サーバにバインドするための適切な認証情報を使って、ユーザ名を定義します。
    •  
      パスワード
      LDAP サーバのパスワードを定義します。 入力したら、[パスワードの確認]フィールドで再確認します。
    •  
      バッチ サイズ
      同期動作を有効にします。 以下の基準を使用して、バッチ サイズを設定します。
      • 0. 生成されたすべての結果をそのままサーバから受信すること許可します。
      • ゼロ以外の数。 サーバから
        n
        個のメッセージを受信するまでメッセージがブロックされます。 メッセージがさらにキューに追加される間、列挙を続行します。
      • 既定のバッチ サイズは 1 です。 サーバからメッセージを受信し、同期検索処理の検索結果の列挙が 1 になると、メッセージが返されます。
    •  
      検索フィルタ
      検索フィルタ文字列を定義します(RFC 2254 の定義に準拠)。
    •  
      日付/時刻形式
      LDAP サーバで使用される日時の形式を定義します。
    •  
      グループ名
      グループ認証に対して有効にするグループを定義します。
    •  
      グループ識別子
      グループ認証に対して有効になっているグループのグループ ID を指定します。
    •  
      LDAP 以外のユーザを許可
      非 LDAP ユーザが代替の認証方式を使用してアプリケーションにアクセスすることを、許可するかどうかを指定します。
  10. [LDAP 属性マッピング]セクションで、以下のフィールドに入力します。
    ユーザ名
    ユーザ名の属性を指定します。
    名の属性を指定します。
    姓の属性を指定します。
    フル ネーム
    姓の属性を指定します。
    電子メール アドレス
    電子メール アドレスの属性を指定します。
    タイム スタンプの変更
    タイム スタンプの変更の属性を指定します。
  11. [シングル サインオン]セクションで、以下のフィールドに入力します。
    トークン名
    ユーザ セッションを開始するための有効な認証トークンとして
    Clarity PPM
    が受け入れる HTTP クッキーを指定します。
    トークン タイプ
    トークン タイプを指定します。 値は以下のとおりです。
    クッキー。
     
    トークンはクッキー内に含まれます。
    ヘッダ。
     
    トークンはメッセージ ヘッダ内に含まれます。
    パラメータ。
     
    トークンはパラメータで提供されます。
    ログアウト URL
    ユーザがログアウトするときに表示される完全修飾 URL を定義します。
    認証エラー URL
    ユーザを認証できないときに表示される完全修飾 URL を定義します。
  12. 変更を保存します。
  13. アプリケーションを再起動し、アプリケーション管理者として
    Clarity PPM
    にログインします。
    システム設定ページが表示されます。
新ユーザ エクスペリエンスのシングル サインオン(SSO)の設定
新ユーザ エクスペリエンス
の SSO 実装を有効にするには、以下の手順の説明に従って、SSO サーバを設定します。 構成設定についての例は、SiteMinder SSO サーバに適用されます。 ご使用の SSO サーバによって設定が異なる場合があります。
新ユーザ エクスペリエンス
用に SSO サーバを設定する前に、クラシック
Clarity PPM
で SSO が有効であることを確認してください。 詳細については、「クラシック CA PPM のシングル サインオン(SSO)の設定」を参照してください。 クラシック
Clarity PPM
で SSO が設定されていない場合、
新ユーザ エクスペリエンス
で SSO は動作しません。
 
以下の手順に従います。
 
  1. 以下の
    新ユーザ エクスペリエンス
    URL を保護します。
    https://<server:port>/pm*
    https://<server:port>/ppm/rest/*
    SiteMinder の例
    クラシック
    Clarity PPM
    レルムが含まれる既存のドメインで、2 つの新しいレルムを作成します。
     
    REST API を保護するルールが含まれるレルムを作成します
     
    •  
      名前
      : CA PPM REST API ルール
    •  
      説明
      Clarity PPM
      Rest API を保護するルール
    •  
      [属性]
      -
      [リソース]
      : ppm/rest/*
    • [アクション]
      -
      [Web エージェント アクション]
      リスト ボックス: [Get]、[Post]、[Put]、[Delete]、および[Head]を選択 します
     
    新ユーザ エクスペリエンス
    を保護するルールが含まれるレルムを作成します
    •  
      名前
      Clarity PPM
      の新しい UI ルール
    •  
      説明
      新ユーザ エクスペリエンス
      を保護するルール
    •  
      [属性]
      -
      [リソース]
      : pm*
    • [アクション]
      -
      [Web エージェント アクション]
      リスト ボックス: [Get]、[Post]、[Put]、[Delete]、および[Head]を選択 します
      ルールを定義した後は、[ルール]タブに移動し、クラシック
      Clarity PPM
      SSO から既存の
      レスポンス
      を新しい各ルールに追加します。 レスポンスでは、ユーザ名の Cookie の名前と
      Clarity PPM
      SSO で想定される値の形式を定義します。
    image2017-1-27 9:44:40.png
     
  2. Web エージェントの以下のプロパティを設定します。
    1. 既存のログオフ URL リストに、以下の URL を追加します。
      https://<server:port>/ppm/rest/v1/auth/logout
    2. 無視する URL リストに、以下の URL を追加します。
      https://<server:port>//pm/js/core/layout/logout.html
    3. 無視する拡張子のリストに以下のファイル拡張子を追加します。
      • .woff
      • .svg
      • .ttf
      • .eot
    4. 一重引用符(値が存在する場合)を、不正な URL 文字リストから削除します。
    5. 一重引用符(値が存在する場合)を、不正なクエリ文字リストから削除します。
 
SiteMinder の例:
 
以下のエージェント プロパティを変更します。
  •  
    IgnoreExt:
    ファイル拡張子 .woff、.svg、.ttf、および .eot を、無視する拡張子のリストに追加します。
  •  
    IgnoreUrl
    : /pm/js/core/layout/logout.html を無視する URL リストに追加します。
  •  
    LogoffUri:
    /ppm/rest/v1/auth/logout をログオフ URI リストに追加します。
  •  
    BadUrlChars:
    一重引用符の値が存在する場合は削除します。
  •  
    BadQueryChars:
    一重引用符の値が存在する場合は削除します。
LDAP の使用(SSO を使用する場合)
シングル サインオン(SSO)と共に LDAP を使用することができます。
 
ベスト プラクティス:
SSO を使用する際は LDAP が有効である必要はありませんが、以下の理由により、SSO と共に LDAP を使用します。
  • 非ブラウザ クライアントは、SSO から大きな恩恵を受けます。
  • SSO 単独使用の場合は、名前や電子メールなどのユーザ情報を
    Clarity PPM
    で管理する必要があります。 LDAP を使用すると、このデータはディレクトリ サーバで保持されます。
LDAP の使用(SSO を使用しない場合)
LDAP にとって SSO はあまり有用ではありません。
Clarity PPM
にログインするためにユーザ名とパスワードを入力する必要がありますが、それ以外のすべての恩恵が LDAP によってもたらされます。 システム設定は、LDAP 単独の場合は非常に簡単です。 LDAP では、プロキシ サーバや SSO サーバは不要であり、1 つの
Clarity PPM
インスタンスのみが必要です。
XSS (Cross-Site Scripting、クロスサイト スクリプティング)脆弱性に対するオプションの設定
クロスサイト スクリプティング(XSS)攻撃は、有害なスクリプトが埋め込まれない場合は信頼される Web サイトに有害なスクリプトを埋め込みます。 XSS アタッカーは、Web アプリケーションを使用して、通常は、ブラウザ側のスクリプトの形式で、有害なコードをエンド ユーザに送信します。 これらの攻撃は、Web アプリケーションの生成する出力に、Web アプリケーションによる事前の検証や入力データのエンコーディングなしに、ユーザ入力データが含まれる場合に成功します。
エンド ユーザのブラウザでは、スクリプトが有害であるかどうかを判断できません。 有害なスクリプトは信頼されたソースからのものとして現れるため、ブラウザはスクリプトを実行します。 コードは、cookie、セッション トークン、またはその他の秘密情報にアクセスすることができます。
XSS 脆弱性に対応するには、ブラウザに送り返されるユーザ入力がすべて安全であることを確認する必要があります。 ユーザ入力は、出力ページに含まれる前に適切にエスケープされる必要があります。 出力を適切にエンコーディングすれば、ユーザ入力は、ブラウザ内で、常に実行可能なアクティブなコンテンツではなくテキストとして扱われます。
XSS 脆弱性に対する保護手段として、リリース 14.1 および 14.2 以降では、アプリケーションはユーザ入力の検証および制限(エスケープ)を処理します。 既定の制限設定の変更要求または XSS セキュリティの問題についてのその他の支援については、ca.com/support にお問い合わせください。
5
5
XSS: ユーザ入力検証
 
Clarity PPM
では、ブラウザに返されるすべてのユーザ入力が XSS に対して安全であることを検証します。 ユーザ入力は、XSS でよく使用される一連の文字列パターンと比較されます。 ユーザ入力の任意の部分が共通のパターンのいずれかに一致する場合、
Clarity PPM
はユーザ入力内の XSS 文字列を制限(エスケープ)します。
XSS 文字列は、その文字列の前後にエスケープ文字を配置することによって制限されます。 これらの文字はエンド ユーザに表示されます。 エスケープ文字は、ブラウザに対して、ユーザ入力に添付されているスクリプトまたは HTML タグを無視するように指示します。
XSS 検出は既定で有効になっています。 URL 属性およびサイト リンクは、このチェックから除外されます。 これらの設定を変更する方法の詳細については、「XSS ユーザ入力制限の設定」を参照してください。
XSS: ユーザ入力制限
共通の XSS パターンのいずれかを含むユーザ入力は、出力ページに含まれる前にエスケープする必要があります。 この出力エンコーディングにより、ユーザ入力はテキストとして扱われ、実行可能なアクティブ コンテンツとして扱われなくなります。 管理オプションにより、ユーザによる XSS 制限(エスケープ)のオンとオフの切り替えが可能になります。
オプションの設定を変更するには、データベース SQL ステートメントを実行します。
 
以下の手順に従います。
 
  1. CMN_OPTION_VALUES データベース テーブルにアクセスします。
  2. 特定のオプションのテーブル エントリを更新します。 各オプションについては、オプションの説明を参照してください。
  3. キャッシュをクリアします。
XSS: 制限オプション
このオプションは、ユーザ入力に含まれる XSS 文字列が CMN.XSS.PATTERNS オプション内のパターンに一致した場合、その文字列を制限します。 このシステム オプションは、
Clarity PPM
アプリケーション全体に適用されます(URL 属性およびサイト リンクを除く)。 URL 属性とサイト リンクに対する制限は、別のオプションを使用して設定できます。
  •  
    RESTRICT.APP.XSS
    値 = True (制限が有効)、False (制限が無効)
    既定値 = True
HtmlPortlet コンテンツは制限(エスケープ)されません。 HTML ポートレットは、HTML コンテンツ内のすべてのスクリプトを実行します(通常の動作です)。
RESTRICT.APP.XSS オプションを変更するには、以下の SQL ステートメントを使用して CMN_OPTION_VALUESデータベース テーブルを更新します。
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.APP.XSS')
 
セキュリティの注意事項
: この update コマンドを適用すると、JavaScript を使用して HTML ポートレットをコーディングすること、HTML ポートレットがクライアント マシンで JavaScript を実行することを回避できなくなります。 管理者としての関心はサーバにあり、メルトダウンやスペクターから保護することです。 クライアント マシンを十分コントロールできないので、そこで有害である可能性のある Javascript について関心はありません。
攻撃者がさらに深刻な攻撃を開始するには、攻撃対象のプロセッサでコードを実行する必要があります。 最新の web サイトをレンダリングするには、あらゆる web JavaScript エンジンは、ユーザのプロセッサで信頼されていない JavaScript コードの実行を許可する必要があります。 HTML ポートレットの一部である任意の Javascript が、サーバではなくクライアント マシンのブラウザで実行されます。 PPM では、サーバ サイド Javascript は実行されません。
XSS 制限では、クライアントのブラウザに送り返される場合、クライアント マシンに損害を与える可能性のある攻撃 Javascript を含む可能性があるフォームの投稿や URL からパラメータを除外します。 これらの制限は、クライアントへの応答が、クライアントが侵害されないように、実行またはリダイレクトすることを想定してサーバにクライアントから送信されたリクエストを処理する web アプリケーション内のフィルタによって対応します。 ユーザにより Javascript でコーディングされている HTML ポートレットはこれらのフィルタを通過しません。 これは PPM がポートレットを表示するなど、実行するように要求されたアクションに対する応答です。 各応答はフィルタを通過しません。 したがって、HTML ポートレットを Javascript を使用してコーディングするユーザは、自分のクライアント マシンのみで実行される Javascript を利用できます。
XSS: URL 属性値オプション
このオプションは、(Studio で作成した) URL 属性値が CMN.XSS.PATTERNS オプション内のパターンに一致した場合、その値を制限します。
  •  
    RESTRICT.URL.ATTR.XSS
    値 = True (制限が有効)、False (制限が無効)
    既定値 = False
RESTRICT.URL.ATTR.XSS オプションを変更するには、以下の SQL ステートメントを使用して CMN_OPTION_VALUES データベース テーブルを更新します。
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.URL.ATTR.XSS')
XSS: サイト リンク オプション
このオプションは、サイト リンク エントリ値が CMN.XSS.PATTERNS オプション内のパターンに一致した場合、その値を制限します。
  •  
    RESTRICT.SITE.LINKS.XSS
    値 = True (制限が有効)、False (制限が無効)
    既定値 = False
RESTRICT.SITE.LINKS.XSS オプションを変更するには、以下の SQL ステートメントを使用して CMN_OPTION_VALUES データベース テーブルを更新します。
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.SITE.LINKS.XSS')
XSS: 共通 XSS パターン オプション
このオプションは XSS でよく使用される文字列パターンを定義します。 このオプションに値を追加することで、文字列パターンをさらに追加できます。
  •  
    CMN.XSS.PATTERNS
     
    String patterns = </script> <script(.*?)> <script>(.*?)</script> alert(.*?) eval\\((.*?)\\) expression\\((.*?)\\) javascript: onerror(.*?)= onload(.*?)= src[\r\n]*=[\r\n]*\\\"(.*?)\\\" src[\r\n]*=[\r\n]*\\\'(.*?)\\\'
パターンを追加するには、CMN_OPTION_VALUES データベース テーブルにアクセスし、CMN.XSS.PATTERNS オプションに新しいパターンを追加します。
 
例: 新しいパターン「onfocus」を CMN.XSS.PATTERNS オプションに追加します
 
 
Oracle
 
CMN_OPTION_VALUES_INS_SP('CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1);
 
MSSQL
 
EXEC CMN_OPTION_VALUES_INS_SP 'CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1
セキュリティ応答ヘッダ: X-XSS-Protection および X-Content-Type-Options
Web ブラウザには、追加の保護レイヤとして、既定によって 2 つのセキュリティ応答ヘッダがあります。
  •  
    X-XSS-Protection
    X-XSS-Protection
    ヘッダは、XSS フィルタを(無効化されている場合でも)強制的に有効化モードにします。 この応答ヘッダは、Internet Explorer、Chrome、および Safari ブラウザでサポートされており、ブラウザが反映された XSS 攻撃を検出したときにページのロードを停止します。 このヘッダは、安全ではないインライン JavaScript の使用を無効にする強力な CSP (Content-Security-Policy)をアプリケーションが実装している場合、最新のブラウザでは必要ありません。 CA PPM のセキュリティはこの点に関しては強力ですが、この保護は、CSP をまだサポートしていない古い Web ブラウザのユーザに対して提供されています。
  •  
    X-Content-Type-Options
    X-Content-Type-Options
    ヘッダは、Content-Type ヘッダでアドバタイズされた MIME タイプの変更を防ぐためにサーバによって使用されるマーカです。
可能性は低いですが、問題が発生した場合は、以下の SQL コマンドを使用して、ネットワーク応答内の個々のヘッダまたはすべてのヘッダを無効にできます。
  • X-Content-Type-Options: nosniff
    を無効にする方法
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-Content-Type%'
  • X-XSS-Protection: 1; mode=block
    を無効にする方法
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-XSS-Protection%'
  • すべてのヘッダを無効にする方法
    call CMN_OPTION_VALUES_DEL_SP('ENABLED_RESPONSE_HEADERS');
外部 URLs
externalUrl プロパティはオプションのアプリケーション設定で、通知メッセージにおいて外部認証スキーマやフェデレーション認証スキーマをサポートします。 externalUrl が未指定の場合、URL を含んでいる
Clarity PPM
通知メッセージは、標準の entryUrl プロパティを使用します。
標準の entryUrl プロパティは、
Clarity PPM
サーバを直接指し示します。 externalUrl プロパティを指定すると、リクエストは、最初、セッションにログイン認証を与える外部サーバにルーティングされます。 外部サーバは SSO (Single Sign-On、シングル サインオン)を使用して、オリジナルのリクエストを
Clarity PPM
にリダイレクトして戻します。 この方法により、ユーザは
Clarity PPM
に直接ログインする必要がなくなります。 ユーザが通知リンクをクリックすると、外部認証が行われ、リクエストが
Clarity PPM
に転送されます。 ユーザがすでにログインしている場合、リクエストは中断されることなく自動的に転送されます。
外部 URL は標準のエントリ URL を置換しません。その代わりに標準のエントリ URL と共に動作します。 この 2 つの URL は複合 URL を作成します。この URL には外部アドレスと内部アドレスが含まれており、それらは、埋め込み URL を的確に渡すためにエンコードされています。 認証ルートには複数のサーバを含めることができるため、通常、URL には、リクエスト処理後のリダイレクト先を各サーバに伝えるクエリ パラメータが含まれます。
externalUrl プロパティは以下のマクロをサポートしています。
  •  
    ${entryurl} 
    現在の entryUrl 設定プロパティを挿入します。
  •  
    replace(regex,replacement,text)
    「regex」のすべてのインスタンスを「text」の「replacement」に置換します。
  •  
    encode()
    テキストを UTF-8 エンコード テキストに置換します。
マクロは、組み合わせてネストすることができます。
制限する XML 文字(アンパサンドなど)は、同等のエンティティ名(&amp; など)を使用して指定します。 このように指定しないと、すべての
Clarity PPM
サービスを開始できくなる可能性があります。
例: 外部 URL の作成
特定の環境への認証ルートによって externalUrl が決まります。 具体的に示すと、認証ルートには、ルート内の各サーバのアドレス、および各サーバに必要なパラメータが含まれます。 この値を設定する前に、これらの情報を収集してルートを決定してください。
たとえば、以下の環境を想定してください。
  •  
    サーバ 1
    用途
    : 外部認証サーバ
    アドレス
    : http://auth.somecompany.com
    必須パラメータ
    : REDIRECT
    説明
    : (必要に応じてログインを呼び出して)認証し、次に、REDIRECT パラメータで指定されたアドレスにリダイレクトします。
  •  
    サーバ 2
    用途
    : 内部認証サーバ
    アドレス
    : http://sso.mycompany.com
    必須パラメータ
    : TARGET
    説明
    : 内部シングル サインオンを呼び出して、TARGET パラメータで指定されたアドレスにリクエストをルーティングします。
  •  
    サーバ 3
    用途
    Clarity PPM
    アプリケーション サーバ
    アドレス
    : http://ca_ppm.mycompany.com
    必須パラメータ
    : すべての標準の
    Clarity PPM
    パラメータ
    説明
    : entryUrl で指定されたアドレス。
要約すると、リクエストは最初に、http://auth.somecompany.com (外部 ID 管理システム)に送られます。 次に、リクエストは、http://sso.mycompany.com の内部シングル サインオン サーバに送られ、最後に、http://ca_ppm.mycompany.com のサーバに送られます。
 
以下の手順に従います。
 
  1. 最初の立ち寄りポイント(外部認証サーバ)を追加すると、外部 URL の作成が開始されます。
    externalUrl=http://auth.somecompany.com
    このサーバには、処理後のリクエストのルーティング先をサーバに示す、1 つのパラメータ(REDIRECT)が必要です。 この例では、リクエストは内部認証サーバに送られます。
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com
  2. 内部 SSO サーバには、標準の
    Clarity PPM
    エントリ URL を含む、1 つのパラメータ(TARGET)が必要です。 ${entryurl} マクロは、通知の送信時に自動的に展開され、現在の entryUrl 設定を示します。
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com?TARGET=${entryurl}
  3. 外部 URL はほぼ完了しましたが、手順がもう 1 つ残っています。
    サーバ 1 の REDIRECT パラメータに含まれている文字列は、支障なくクエリ文字列に渡すために、UTF-8 でエンコードする必要があります。 エンコード マクロは以下のとおりです。
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=${entryurl})
    サーバ 2 にもエンコードが必要なパラメータがあります。
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=encode(${entryurl}))
    encode() マクロはネストされています。 ネストによって、内部のものが二重にエンコードされます。つまり、UTF-8 でエンコードされるテキストは 2 回エンコードされます。 最初の立ち寄りポイントでは、サーバ 1 によって、REDIRECT パラメータ全体がデコードされてしまいます。しかし、サーバ 2 は UTF-8 エンコードしたパラメータを予想しているため、この二重エンコーディングが必要になります。 最後のパラメータを適切にエンコードするために、エンコード マクロを必要なだけネストできます。
 
リクエストのライフサイクル
 
新しい
Clarity PPM
電子メール通知の生成時、イベントへの適切なクリックスルー URL を生成するために、externalUrl と entryUrl プロパティが使用されます。 標準の URL (externalUrl を使用しない場合)は、以下のようになります。
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
この例で externalUrl を有効にした場合は、以下のようになります。
externalUrl=http://auth.somecompany.com?REDIRECT=http%3A%2F%2Fsso.mycompany.com%3FTARGET%3Dhttp%253A%252F%252Fca_ppm.mycompany.com%252Fniku%252Fnu%2523action%253Atimeadmin.currentTimesheet
前の例は、サーバ 1 を示す URL、サーバ 2 とサーバ 3 のアドレスとプロパティを示す、UTF-8 エンコードされた単一のパラメータ(エントリ URL は 2 回エンコード)から成っています。 ユーザがこの URL をクリックすると、リクエストはサーバ 1 (http://auth.somecompany.com)へ送信されます。 サーバ 1 はパラメータ(REDIRECT= 以降のテキストすべて)を次のようにデコードします。
http://sso.mycompany.com?TARGET=http%3A%2F%2Fca_ppm.mycompany.com%2Fniku%2Fnu%23action%3Atimeadmin.currentTimesheet
サーバ 1 はこの URL を使用して、サーバ 2 にリダイレクトします。 サーバ 1 によってクエリ文字列全体がデコードされていますが、サーバ 2 のパラメータ文字列がエンコードされたままになります。 この例が二重エンコードの効果を示しています。 次に、サーバ 2 が TARGET パラメータをデコードし、以下が生成されます。
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
上記が最終の URL です。 URL はデコードされ、
Clarity PPM
による処理の準備が整っています。 ここまでに、サーバ 1 とサーバ 2 によって認証作業が実行されています。 リクエストが最後に
Clarity PPM
に到着したとき、リクエストには、ユーザを識別するための適切なシングル サインオン認証トークンが含まれています。 通知の作成時に適切な URL を生成することを除き、
Clarity PPM
は認証プロセスに関与しません。
外部 URL のトラブルシューティング
問題がある外部 URL のトラブルシューティングにおいて重要なことは、チェーン内の各サーバに必要な値を理解することです。 これを理解すると、各ポイントで URL とパラメータが適切にエンコードされていることを確認できます。 以下の手順に従って、特定の通知 URL を手動で確認できます。
 
以下の手順に従います。
 
  1. UTF-8 デコード ユーティリティを取得します。 シンプルなユーティリティをダウンロードできます。
  2. 現在の外部 URL 設定を使用して、通知電子メールを生成します。
  3. URL を調べて、URL の先頭部分がサーバ 1 を指していることを確認します。 URL の先頭部分には、最初の疑問符文字までのすべてが含まれます。
  4. 最初の疑問符とその前の文字列をすべて破棄し、サーバ 1 に渡されたパラメータ文字列を残します。
  5. UTF-8 デコード ユーティリティを 1 回使用して、残りの文字列をデコードします。
    デコードされた文字列は、サーバ 1 に渡されたパラメータを示しています。 パラメータが正しいことを確認します。
  6. パラメータ名(この例では REDIRECT)を破棄し、URL の先頭部分がサーバ 2 を指していることを確認します。 もう一度、疑問符までのすべてが、URL の最初の部分に含まれています。
  7. もう一度、疑問符とその前の文字列をすべて破棄し、次に、残りの文字列を 1 回デコードします。
  8. 以下の点を確認します。
    • URL の先頭部分が
      Clarity PPM
      サーバを指している。
    • 残りのクエリ文字列に標準の
      Clarity PPM
      パラメータが含まれている。
    • パラメータがエンコードされていない。
Clarity PPM
はどのようにユーザ セッションを追跡するのですか。
セッション ベースのクッキーは、次の場所に留まるセッション データへのアクセスに使用されるトークンを伝達します。
  • キャッシュ(単一アプリケーション環境の場合)
  • データベース(クラスタ化された環境の場合)
ユーザ環境でこの場所に制約はありますか。
エンド ユーザの Web ブラウザは、
Clarity PPM
アプリケーションからの Cookie を受け入れる必要があります。 クッキーはセッションに基づいているため、ディスクに書き込まれません。
このテクニックによってロード バランサやクラスタは影響を受けますか。
負荷分散およびクラスタ化は、このテクニックによる影響を受けません。 多数の会社が
Clarity PPM
を負荷分散して、クラスタ化しています。
不注意にまたは故意にセッションが乗っ取られる可能性がありますか。
故意にユーザのセッションを盗むには、HTTP トラフィックをスヌーピングして、認証クッキーを含むヘッダを識別する必要があります。 しかし、このトークンは本物のユーザがログインしている間だけ有効です。 ユーザがログアウトすると、
Clarity PPM
で Cookie の値に対応するデータベース/キャッシュ内のセッション情報が削除されます。
どうすればログからセッション ID を除外できますか。
セキュリティ対策として、セッション ID の値がログ ファイルに表示されるのを防ぐために
Clarity PPM
を設定することができます。 これらの値が表示されるのを防ぐには、logger.xml ファイルを編集します。 ログ パターン(%u:%s:%a)をパターン(%U:%a)で置き換えます。
以下の例に、logger.xml ファイル内の両方のログ パターンを使用した結果を示します。
 
例: (%u:%s:%a)
 
このコード行は、logger.xml ファイル内のセッション ID の値の表示パターンを示しています。
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%u:%s:%a) %m\r\n"/>
このパターンでは、セッション ID の値を持つレコードがログ ファイルに作成されます。 以下の app-ca.log のレコードには、セッション ID 値(太字)が示されています。
DEBUG 2014-08-18 19:52:02,949 [http-bio-80-exec-3] odf.view (ca_ppm:admin:
5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0
:npt.overview) Adding view FILTER_VIEW_LOADER::USER:NIKU.ROOT to transient cache
 
例: (%U:%a)
このコード行は、logger.xml ファイルにセッション ID の値が表示されるのを防ぐパターンを示しています。
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%U:%a) %m\r\n"/>
このパターンでは、セッション ID の値を持たないレコードがログ ファイルに作成されます。 以下の例は、セッション ID 値が表示されない app-ca-service.log のレコードを示したものです。
DEBUG 2014-08-18 19:52:02,494 [http-bio-80-exec-3] in.service (admin:npt.overview)
 
Clarity PPM
では、アペンダの logger.xml でレイアウトが NikuLayout に設定されている場合、以下の表の追加のログ パターンをサポートします。
 
パターンのオプション
 
 
目的
 
u
テナント ID を持つユーザ ID をログに作成します。
例: (%u) は出力 (clarity:admin) をログに作成します。
U
ユーザ ID をログに作成します。
例: (%u) はログに出力 (admin) を作成します。
s
セッション ID をログに作成します。
例: (%s) は、ログに出力 (5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0) を作成します。
a
アクション ID をログに作成します。
例: (%a) はログに出力 (npt.overview) を作成します。
log4j バージョン 1.2 でサポートされているパターンの詳細については、https://logging.apache.org でクラス PatternLayout の API ドキュメントを参照してください。
FIPS 140-2 動作モードの有効化
FIPS 140-2 は、機密データの暗号化に関する米国連邦政府の標準規格です。 Apache Tomcat アプリケーション サーバ上で、
Clarity PPM
を FIPS 140-2 準拠モードで動作させることができます。 このサーバ動作モードでは FIPS 140-2 準拠の暗号化モジュールを使用します。 FIPS モードを使用する動作の例には、セキュリティ サーバ プロパティ ページでの定義に従った SSL プロトコルおよびパスワード暗号化が含まれます。
 CA PPM リリース 15.3 以降では、以前のリリースの RSA B-SAFE FIPS プロバイダが、FIPS の新しい Bouncy Castle 暗号パッケージに置き換えられました。
Clarity PPM
を FIPS 140-2 準拠モードで設定するには、以下の動作上の制限事項に従います。
 これらの手順に従わない場合、アプリケーションが起動せず、ログに例外が記録される可能性があります。
 
以下の手順に従います。
 
  1. FIPS を有効化する前に、以下を確認します。
    1. 15.5.1 にアップグレードする場合は、FIPS が有効ではないことを確認します。 まず FIPS を無効化するか、FIPS が必要な場合は、パッチが利用可能になるまでアップグレードを延期します。 リリース 15.5.1 では FIPS がサポートされていません。
    2. ハードウェアがセキュア ランダムをサポートする、またはセキュア ランダム デーモンがインストールされていることを確認します。
  2. HTTPS を使用する場合、SSL キーストアは Bouncy Castle (BC)形式である必要があります。 キーストアを BC 形式で作成します。
    keytool -genkey -keyalg RSA -alias selfsigned -sigalg SHA256withRSA -keystore <path_to_keystore>\mykeystore.jks -keypass <key_password> -storepass <store_password> -validity 365 -keysize 2048 -storetype BCFKS -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath <path_to_fips_provider_jar>\bc-fips.jar
    以下の例は、Java keytool を使用するコマンドを示しています。 openSSL などのさまざまなツールを使用して、キーストアを作成できます。
  3. Sun JKS 形式のキーストア(たとえば、以前のリリースのもの)がすでにある場合は、キーストアを BC 形式に変換できます。
    keytool -importkeystore -srckeystore <path_to_keystore>\mykeystore.jks -srcstoretype JKS -srcstorepass <password> -destkeystore <path_to_keystore>\mykeystore.bcfks -deststoretype BCFKS -deststorepass <password> -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath <path_to_fips_provider_jar>\bc-fips.jar
  4. Clarity PPM
    サーバで使用される JAVA_HOME に移動します。
  5. <install_dir>/lib の
    bc-fips.jar
    ファイルを JAVA_HOME/jre/lib/ext ディレクトリにコピーします。
  6. JAVA_HOME/jre/lib/security で、java.security ファイルを編集します。
    1. リストから、以下の古いプロバイダ エントリを削除します。
      com.sun.net.ssl.internal.ssl.Provider
       
       
       
    2. 以下のプロバイダをリストに追加します。
      security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
      security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS 
    3. 残りのプロバイダ インデックス エントリを再度番号付けします。 以下の例は、更新されたリストを示しています。
      security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS security.provider.3=sun.security.provider.Sun security.provider.4=sun.security.rsa.SunRsaSign security.provider.5=sun.security.ec.SunEC security.provider.6=com.sun.crypto.provider.SunJCE security.provider.7=sun.security.jgss.SunProvider security.provider.8=com.sun.security.sasl.Provider security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.10=sun.security.smartcardio.SunPCSC security.provider.11=sun.security.mscapi.SunMSCAPI
  7. CSA にログインします。
  8. [ホーム]
    メニューで、
    [サーバ]
    をクリックします。
  9. 設定するサーバの名前をクリックします。
  10. [セキュリティ]
    タブをクリックします。
    image2017-6-6 11:59:41.png
  11. [FIPS 140-2 モード]
    チェック ボックスをオンにします。
  12. [暗号化パスワード]
    フィールドで、
    [システム キーを使用する]
    を選択します (
    [カスタム キー ファイルを使用する]
    を選択することもできます)。
  13. 各ユーザの
    Clarity PPM
    ログイン パスワードの長さが 14 文字以上であることを確認してください。 以前の FIPS 対応
    Clarity PPM
    環境からアップグレードする場合、新しいリリースでは、古いパスワードが短すぎる場合にパスワードの変更が強制的に行われます。
  14. [保存]
    をクリックします。
  15. <install_dir>/bin から app サービスと bg サービスを停止、展開、および開始します。 変更を適用するには、3 つの個別のコマンドを 1 つずつ発行します。
    1.  
      service stop app bg
       
    2.  
      service deploy app bg
       
    3.  
      service start app bg
       
 お使いのハードウェアでは
セキュア ランダム
をサポートでき、さまざまな方法で
セキュア ランダム デーモン
をインストールできるので、ここでは詳細な手順は説明しません。 SaaS 環境で FIPS を有効にするために必要な最終手順の 1 つの例を次に示します。
  1. 以下のファイルのバックアップを行います。
    /opt/java/jdk1.8.0_101/jre/lib/security/java.security
  2. 以下の行を変更します。
     
    変更前:
    securerandom.source=file:/dev/random
    変更後:
    securerandom.source=file:/dev/urandom
     
     
     
  3. 以下のコマンドを実行します。
     
      service deploy start beacon nsa app bg
     
15.5.1 で FIPS サポートが提供されない
既知の問題によって、15.5.1 では FIPS を有効化できません。アップグレードする前に設定をリセットして、15.5.1 にアップグレードする前に、以前のリリースで FIPS 140-2 モードを有効化するために行ったすべての設定変更を元に戻します。 15.5.1 へのアップグレードの前に FIPS を無効化しなかった場合、1 つ以上のエラーが発生する可能性があります。
アップグレード後も、システム管理者は通常、新しいキーストアを再生成せず、古いキーストアを引き続き使用します。 理想上は、JDK 11 は下位バージョンの JDK、openjdk、または openssl によって生成された古いキーストアを読み取ることができるはずです。 しかし、以前のリリースで FIPS を有効化して 15.5.1 にアップグレードすると、BCFIP.jar シグネチャの検証が失敗します。 Bouncy Castle (弊社の暗号化プロバイダ)は、JDK 11 で FIPS をサポートしていません。 ログに以下のエラーが表示される場合があります。
 
java.util.jar.JarException: file:/fs0/niku/1551runtime/lib/bc-fips.jar not signed by trusted signer
 
 
回避策
: この問題を回避するには、
java.security
プロパティで BCFIPS をコメント化し、ログ内で上記の FIPS エラーを無視します。
# List of providers in their preferred order: # security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider #security.provider.1=BCFIPS security.provider.2=SunJSSE BCFIPS security.provider.3=SUN security.provider.4=SunRsaSign security.provider.5=SunEC security.provider.6=SunJCE security.provider.7=SunJGSS security.provider.8=SunSASL security.provider.9=XMLDSig security.provider.10=SunPCSC security.provider.11=JdkLDAP security.provider.12=JdkSASL security.provider.13=SunPKCS11
 JRE は JDK 11 に含まれなくなりました。 修正が見つかったら、FIPS プロバイダ jar (bc-fips.jar)を
JAVA_HOME/JRE/lib/ext
ではなく
JAVA_HOME/lib
にコピーする必要が生じる場合があります。古い Java 8 の場所である
JAVA_HOME/JRE/lib/security/java.security
ではなく
JAVA_HOME/conf/security/java.security
のプロパティ ファイル内のセキュリティ プロバイダ リストを修正してください。