DOD PKI 情報

このセクションでは、Reflection をインストール、構成、使用して DOD (Department of Defense) 環境またはその他の PKI (Public Key Infrastructure) 環境内で操作する方法について解説します。PKI 構成は、Secure Shell 接続および SSL/TLS 接続の両方に影響します。

DOD PKI モードでの Reflection の実行

既定では、Reflection アプリケーションにより DOD PKI 要件を満たさない構成が一部許可されます。管理者は、Reflection グループポリシを使用して DOD PKI 要件を満たすようにすべての Reflection セッションを構成できます。

DOD PKI モードの構成には、以下の影響があります。

• CRL を確認したり、OCSP レスポンダを使用するように Reflection を構成する必要があります。DOD PKI モードでは、いずれの確認形式も使用しないオプションは無効です(SSH 接続の場合、[Reflection Secure Shell の設定] ダイアログボックスの [PKI] タブを使用して、証明書の取り消しを構成します。SSL/TLS 接続の場合、[PKI の構成] ダイアログボックスを使用して構成します)。

  認証局によって失効された、電子署名された証明書の一覧。CRL で識別された証明書はすでに有効ではありません。

• Reflection では、FIPS 承認の暗号化アルゴリズムを実行します。SSH 接続の場合、[Reflection Secure Shell の設定] ダイアログボックスの [暗号化] タブでは FIPS 承認オプションのみ使用できます。SSL/TLS 接続の場合、[暗号化レベル] を 40 ビットまたは 56 ビットに設定できません。
• 接続を確立するためには、証明書のホスト名が Reflection 接続に指定したホスト名と完全に一致している必要があります。つまり、[証明書のホスト名と対象ホスト名が一致するかどうかを確認する] が自動的にオンになり、変更することはできません(SSH 接続の場合、[Reflection Secure Shell の設定] ダイアログボックスの [PKI] タブを使用して、この設定を構成します。SSL/TLS 接続の場合、[PKI の構成] ダイアログボックスを使用して構成します)。
• MD2 または MD5 ハッシュを使用して署名された中間 CA 証明書は、証明書検査に対応していません。

トラストポイントのインストールおよび削除

トラストポイントは、信頼チェーン内の任意の CA 証明書です。

注意

• 中間 CA トラストポイントは、LDAP サーバまたは HTTP サーバから取得できます。このサーバは、証明書の AIA (Authority Information Access) 拡張に定義されている明示的な URI、または [Reflection 証明書マネージャ] の [LDAP] タブに構成されている LDAP サーバ情報を使用して特定できます。これらの証明書は、<マイドキュメント>¥Attachmate¥Reflection¥.pki または ¥All users¥Application data¥Attachmate¥Reflection にある cert_cache ファイルに保存されます。

  情報の中央位置への保存およびユーザへの情報の配布に使用できる標準的なプロトコル。

• Reflection が DOD PKI モードで実行中の場合、[Reflection 証明書マネージャ] に追加したルート証明書のみが使用されます。Windows の証明書格納場所に存在する可能性がある DOD PKI 以外の証明書を削除する必要はありません。

証明書取り消しの確認の構成

Reflection では、証明書取り消しの確認の既定値は現在のシステム設定に基づいて決まります。システムが CRL の確認を行うように構成されている場合は、既定で Reflection セッションにおいて CRL を使用して証明書取り消しが確認されます。OCSP レスポンダを使用するように Reflection を構成することもできます。

Reflection では、CRL 確認を無効にする設定にも対応しています。この設定をテストに使用できますが、Reflection が DOD PKI モードで実行中の場合にはこのオプションを使用できません。

警告:CRL 確認を無効にすると、セキュリティ上のリスクが高まります。このオプションはテストにのみ使用します。

中間証明書または CRL を取得する 1 台または複数の LDAP サーバを定義できます。

DOD PKI サービスの URI の使用

Reflection では、CRL の自動更新および取得に URI を使用できます。RFC3280 のセクション 4.2.1.14 に定義されています。

CRL 確認が有効の場合、Reflection では以下のように証明書の取り消しを確認します。

1. crl_cache ファイルで有効な取り消し情報を確認します。見つからない場合は、手順 2 に進みます。
2. 証明書の CDP 拡張で HTTP URI または LDAP URI を確認し、指定した順番 (最初に HTTP、次に LDAP) で問い合わせます。取り消し対象の証明書が見つかった場合は、接続を切断します。証明書が見つからない場合は、手順 3 に進みます。
3. 1 台または複数の LDAP サーバが [Reflection 証明書マネージャ] の [LDAP] タブに指定されている場合、証明書の発行者の拡張子に示されている CA の識別名をまとめて、CRL ファイルに問い合わせます。いずれの CRL にも取り消し対象の証明書が見つからない場合は、次の検証手順に進みます。

期限切れの CRL の更新は自動的に処理されるため、管理者の介入または構成の必要はありません。

OCSP 確認が有効の場合、Reflection ではすべての使用可能な OCSP レスポンダを必ず確認します。これは、証明書が取り消されたことをいずれかのレスポンダが把握している場合に、接続が失敗することを確認するためです。接続を確立するためには、少なくとも 1 つの OCSP レスポンダが使用可能であり、認証ステータスに対して値「good」を返す必要があります。Reflection では、以下のように確認を実行します。

1. 証明書の AIA 拡張で 1 つまたは複数の OCSP レスポンダを確認し、各レスポンダに問い合わせます。いずれかのレスポンダからの証明書のステータスが「revoked」に戻った場合、接続を切断します。
2. [Reflection 証明書マネージャ] の [OCSP] タブを使用して指定した 1 つまたは複数のユーザ構成 OCSP レスポンダを確認し、各レスポンダに問い合わせます。いずれかのレスポンダからの証明書のステータスが「revoked」に戻った場合、接続を切断します。
3. すべてのレスポンダが「unknown」を返した場合、接続を切断します。少なくとも 1 つの OCSP レスポンダから「good」応答が返された場合、次の検証手順に進みます。

URI を使用した中間証明書の取得

RFC3280 のセクション 4.2.2.1 に定義されているように、Reflection では以下のように URI を使用して中間 CA 証明書を取得できます。

1. cert_cache ファイルで必要な中間証明書を確認します。見つからない場合は、手順 2 に進みます。
2. HTTP URI または LDAP URI のいずれかが証明書の AIA (Authority Information Access) 拡張に定義されている場合、中間 CA 証明書の取得にこれらの使用を試行します (最初に HTTP、次に LDAP)。
3. 前の試行に失敗した場合、発行している証明書の件名から識別名をまとめて、CACertificate 属性の内容に定義された LDAP サーバに問い合わせます。

Reflection では証明書のセキュリティポリシ拡張を実施するため、セキュリティポリシ構成は不要です。

証明書と秘密鍵の構成と保護

証明書を使用してクライアント認証を構成するには

1. [Reflection 証明書マネージャ] を開きます。
2. [個人] タブで [インポート] をクリックしてから、証明書 (通常、*.pfx または *.p12) を検索して指定します。この鍵を使用するごとに要求されるパスフレーズを作成する画面が表示されます。システムでこの鍵を保護するのに役立つため、パスフレーズの入力が推奨されます。
3. Secure Shell 接続の場合、[Reflection Secure Shell の設定] ダイアログボックスを開き、[ユーザ鍵] タブをクリックして、現在指定しているホストへのクライアント認証に使用したい証明書を選択します(このステップは、SSL/TLS 接続には必要ありません)。

秘密鍵の保護

クライアントの秘密鍵が盗まれた場合、悪意のあるユーザがそのユーザにアクセス可能な任意のサーバのファイルにアクセスできます。このリスクを最小限にするには、各クライアントユーザがパスフレーズを使用して自分の秘密鍵を必ず保護する必要があります。これによって、パスフレーズを知っている人だけがその鍵で認証できることになります。ユーザは、組織のセキュリティポリシのパスワード仕様に従ってパスフレーズを作成し、保護する必要があります。

鍵が改ざんされた場合の操作

秘密鍵が不正な人物によって利用可能になった場合、または鍵にアクセスする人物の操作を信用しない理由がある場合、秘密鍵が改ざんされたと見なします。

クライアントの鍵が改ざんされた場合、クライアントの証明書を取り消します。