ASA CX および Cisco Prime Security Manager 9.0 ユーザ ガイド
SSL/TLS トラフィック フローの管理
SSL/TLS トラフィック フローの管理
発行日;2013/04/11   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

SSL/TLS トラフィック フローの管理

HTTPS など一部のプロトコルは、Secure Sockets Layer(SSL)またはその後継バージョンである Transport Layer Security(TLS)を使用して、セキュアな転送のためにトラフィックを暗号化します。 暗号化されたトラフィックは検査できないため、アクセス判断のために上位層のトラフィック特性を考慮したアクセス ルールを適用する場合は、トラフィックを復号化する必要があります。

ここでは、SSL/TLS トラフィック フロー管理と復号化についてさらに詳しく説明します。

SSL/TLS トラフィック管理の概要

SSL/TLS プロトコルは、トラフィックを暗号化して保護するために広く使用されています。 トラフィックは暗号化されるため、トラフィック インスペクタはトラフィックのコンテンツを判別できません。 ASA CX では、復号化ポリシーを使用してトラフィック フローを復号化するかどうかが決定されます。

SSL/TLS 暗号化トラフィックの処理方法には、次のオプションがあります。
  • [Decrypt the traffic, inspect it, then re-encrypt it]:トラフィックの復号化を選択した場合、ASA CX は中間者のように動作します。
    • 着信トラフィックが復号化されます。
    • トラフィックが HTTPS である場合、そのトラフィックは検査されます(HTTPS トラフィックのみが検査されます。他のトラフィック タイプは検査されません)。 アクセス ルールが適用されます。
    • トラフィックが許可されると、そのフローのアクセス ポリシーに定義されているすべてのアクション プロファイルが適用され、フローが再暗号化されて、宛先に送信されます。
    • 復路のトラフィックも復号化され、検査された後、再暗号化されてクライアントに送信されます。
    トラフィック フローを復号化することにした場合、ユーザは ASA CX 証明書を信頼できるルート認証局として受け入れる必要があります。 詳細については、SSL/​TLS 証明書のダウンロードとインストールを参照してください。

    (注)  


    トラフィック フローの復号化を選択した場合でも、復号化は単に検査を行えるようにするため実行されるに過ぎません。 ASA CX はフローを再暗号化してから宛先に送信するため、エンドツーエンドのトラフィック フローは暗号化されます。 復号化されたコンテンツが別のホストに送信されることはなく、デバイスの外部に出ることがありません。


  • [Conditionally decrypt potentially malicious traffic]:宛先に割り当てられた Web レピュテーションに基づいて、トラフィックを条件付きで復号化できます。 ある Web レピュテーションが、定義されている低レピュテーション ゾーンに該当する場合、トラフィックは復号化され、他の復号化されたフローと同様に処理されます。 その Web レピュテーションが、高レピュテーション ゾーンに該当する場合、トラフィックは復号化されず、他の復号化されないフローと同様に処理されます。
  • [Do not decrypt the traffic]:トラフィックを復号化しなかった場合、ASA CX はトラフィックを検査しません。 ネットワーク グループ、サービス グループ、またはユーザ ID に基づくアクセス ルールがすでに適用されているため、暗号化されたトラフィック フローは復号化ポリシーによって評価される前に、すでに拒否されている可能性があります。 復号化されない暗号化トラフィックの場合、アクセス ルールが適用され、許可またはドロップの決定は、ネットワーク(IP アドレス)、サービス(ポート、TCP/UDP)、およびユーザ アイデンティティ ポリシー オブジェクトなど、公開されているトラフィック フローの特性に基づいて行われます。 URL オブジェクトの場合はドメイン名のみが照合され、その結果 Web カテゴリ照合が行われる場合もありますが、同じ Web サーバまたはドメインで異なるリソースに対して、別個の振る舞いを指定することはできません。 暗号化されたトラフィック フローは、アプリケーションまたはユーザ エージェントのポリシー オブジェクトが含まれた仕様と照合されることはありません。 また、許可されたトラフィック フローに適用するすべてのアクション プロファイルは、暗号化されたトラフィックに対して無視されます。 たとえば、特定のタイプのアップロードまたはダウンロードを回避するファイル フィルタリング プロフィルや、低レピュテーションの Web サイトからのトラフィックをドロップする Web レピュテーション アクション プロファイルを適用することはできません。 暗号化されたフローのコンテンツは不明であるため、暗号化されたフロー全体が許可されます。

復号化のヒントと制限

復号化を設定するときは、次の点に注意してください。
  • どのタイプの暗号化トラフィックも復号化できますが、復号化の後に検査されるプロトコルは HTTPS のみです。
  • 復号化ポリシーは、フローが SSL/TLS ハンドシェイクで開始している場合のみ、トラフィック フローに適用されます。 SMTP over TLS などの暗号化をネゴシエーションするトラフィック フローが復号化されることはありません。 暗号化をネゴシエーションするトラフィック フローは、暗号化されていないトラフィック フローのように処理されます。
  • 復号化を有効にしたが、復号化ポリシーは作成しない場合、トラフィックは復号化されず、暗号化されたトラフィック フローは設定したアクセス ポリシーに基づいて許可または拒否されます。 [Decrypt Everything] または [Decrypt Potentially Malicious Traffic] アクションが適用される復号化ポリシーを作成して、すべてのフローを復号化する必要があります。
  • 復号化ポリシーで使用する URL オブジェクトを設定する際には、パス情報を含めないでください。 トラフィックが URL オブジェクトと一致するかどうか評価する際に、復号化ポリシーではパス情報を含んだすべての URL を完全に無視します。 オブジェクトに、ドメイン名だけの URL と、パスが含まれる URL が混在している場合、復号化ポリシーはそのオブジェクトを、ドメイン名だけを指定した URL のみが含まれるものとして扱います。
  • 復号化を有効にすると、システムのスループットが下がり、SSL/TLS 暗号化プロトコルを使用するアプリケーションのパフォーマンスに影響が及ぶ可能性があります。
  • 一部のアプリケーションは、クライアントとサーバ間のトラフィックの復号化をサポートしていません。 その理由としては、そのようなアプリケーションで信頼できる証明書ストアに証明書を追加できないか、そのアプリケーションが信頼する証明書のハードコードされたリストが使用されていることなどがあります。 たとえば、インターネット メッセージング用アプリケーション、Dropbox、および多くの銀行サイトなどです。 これらのアプリケーションについては、サポートされないアプリケーションの復号化のバイパスに記載されているように、復号化をバイパスする必要があります。

トラフィックを復号化する理由


ヒント


ASA CX のアクセス ポリシーの目的は、ネットワークでのユーザの行動を検出、モニタリング、測定、および制御することです。 SSL/TLS セッション内部に隠されたプロトコルに対しては、トラフィック フローの復号化も行わない限り、これらをうまく行うことはできません。


暗号化されたトラフィックを復号化するかどうかを選択できます。また、一部のトラフィック フローは復号化して、他は復号化しないように決定することもできます。 トラフィックを復号化するかどうかを検討する際に、暗号化トラフィックのタイプとして最も注目されるのは HTTPS です。

HTTPS は、HTTP の保護された形式として機能する Web プロトコルです。 HTTPS は HTTP 要求と応答を暗号化してから、ネットワーク経由で送信されます。 一般的に、HTTPS を使用しているサイトへの接続は「安全」であると考えられています。HTTPS 接続は保護されていますが、安全というわけではなく、悪意のあるサーバや信頼できないサーバは識別されません。

HTTPS トラフィックを復号化すると、以下を行うことができます。
  • ネットワーク トラフィックを詳しく調べる:使用されているアプリケーションなど、ネットワーク トラフィックをより詳細に調べることができます。 トラフィックを復号化することで、HTTPS を使用してアクセスされた Web サイトについての詳しい情報をレポートに含めることができます。
  • 低レピュテーションの送信元をブロックする:Web レピュテーション プロファイルを使用して、低レピュテーションの送信元でホストされたコンテンツを選択的にブロックすることで、ユーザは保護されると同時に、許可された Web サイトにアクセスできます。
  • 好ましくないファイル交換をブロックする:ファイルのアップロードとダウンロードを選択的にブロックすることで、セキュリティ ポリシーを実装できます。
  • 調査対象の特性に基づいてアクセスを制御する:アプリケーション、タイプ、および振る舞いなど、一部のトラフィック特性は調査でしか把握できないため、トラフィックを最初に復号化する場合にのみ、これらの特性を使用するアクセス ポリシーを適用できます。

SSL/TLS 復号化の設定

次の手順では、SSL/TLS トラフィック フローの復号化を設定するプロセスの概要を示します。 この手順を使用して、一般的な設定プロセスを理解し、参照トピックで詳細な手順を確認してください。

手順
    ステップ 1   復号化設定の指定の説明に従って、復号化を有効にして、使用する CA 証明書を選択します。

    復号化をイネーブルにする必要があります。 イネーブルにしなかった場合、トラフィック フローは復号化されず、復号化ポリシーは使用されません。

    ユーザからのトラフィック フローの復号化には、CA 証明書が使用されます。 目的の宛先からの証明書を使用してトラフィック フローを再暗号化した後、それを宛先に送信します。

    ステップ 2   復号化ポリシーの設定の説明に従って、復号化ポリシーを設定します。

    復号化ポリシーによって、さまざまなトラフィック フローをどのように処理するかが定義されます。 それらを復号化して調査し、Web レピュテーションに基づいてそれらを条件付きで復号化するか、単に復号化しないことを選択できます。 デフォルトではトラフィックは復号化されないため、何らかのタイプの復号化を実装するポリシーを作成して、すべてのトラフィック フローを復号化する必要があります。

    ステップ 3   サポートされないアプリケーションの復号化のバイパスの説明に従って、信頼されているサイト、および復号化をサポートしていないサイトの復号化はバイパスします。

    安全と思われるフローの不要な復号化プロセスを防止するため、金融など、よく知られている URL カテゴリへのトラフィックは復号化しないようにすることを検討してください。 また、ネットワーク上で使用されているアプリケーションの中で、インスタント メッセージ アプリケーションのように、クライアントとサーバの間でトラフィックが復号化されると機能しなくなるアプリケーションは復号化しないでください。

    ステップ 4   信頼できるルート CA 証明書として復号化で使用される CA 証明書を認識するように、クライアント アプリケーションを設定します。

    ユーザは、TLS/SSL を使用するアプリケーションで、信頼できるルート認証局として定義された暗号化プロセスで使用される、CA 証明書を持っている必要があります。 SSL/​TLS 証明書のダウンロードとインストールの説明に従って、CA 証明書をダウンロードし、ユーザが使用できるようにブラウザにインストールします。 ソフトウェア管理メソッドを使用して、ブラウザに証明書を事前インストールすることで、ユーザの操作を回避できます。 一部のブラウザ以外のアプリケーションでは、証明書を追加できない場合があります。この場合、それらのアプリケーション用に復号化のバイパスが必要になることがあります。

    ステップ 5   Event Viewer を使用して、復号化イベントを表示および分析します。

    [Events] > [Events] を選択してイベント ビューアを開きます。


    復号化設定の指定

    ASA CX に復号化ポリシーを実装するには、それらをイネーブルにし、ASA CX が管理対象の復号化されたトラフィック フローに使用する認証局(CA)の証明書を特定する必要があります。

    この CA 証明書は、クライアント アプリケーションがアクセスするサイトごとに、一時的な代替証明書を発行するために使用されます。 一時証明書は、クライアントと ASA CX の間の保護された(SSL または TLS)セッションで、実サーバの証明書の代わりに使用されます。 一方、実サーバの証明書は、ASA CX とサーバの間の保護されたセッションで使用されます。 この手法によって、ASA CX は両側からデバイスに着信するコンテンツを復号化し、再暗号化してから、リレーすることができます。

    手順
      ステップ 1   [Device] > [Decryption] を選択します。
      ステップ 2   TLS/SSL 復号化をイネーブルにし、ポリシーを復号化するには、[Enable Decryption Policies: On] を選択します。

      復号化ポリシーをイネーブルにすると、追加設定が表示され、復号化されたフローの管理に使用する CA 証明書を選択できます。

      ステップ 3   使用する [Certificate Initialization Method] を [Generate] または [Import] のいずれかから選択し、フィールドに入力します。

      復号化をすでにイネーブルにしている場合は、現在設定されている証明書に関する要約情報が、[Certificate Initialization Method] フィールドではなく、ページに表示されます。 証明書の [Export] または [Replace] のリンクがあります。

      [Replace] をクリックすると、[Certificate Initialization Method] フィールドが表示され、証明書の置き換え方法を選択できます。

      証明書の設定の詳細については、復号化証明書の設定を参照してください。

      ヒント   

      [Export] をクリックして、ブラウザにアップロードできるファイルで証明書をエクスポートできます。これにより、ユーザは復号化トラフィック フローの中での要求に従って、証明書を保存する必要がなくなります。

      ステップ 4   [Save] をクリックして変更を保存します。

      次の作業

      復号化をイネーブルにすると、復号化ポリシーを設定できるようになります。

      復号化証明書の設定

      ASA CX は、クライアントが最初に接続要求を送信した TLS サーバを模倣します。 要求先サーバのように振舞うクライアントとの間に保護された接続を構築するには、アプリケーションがそのクライアントに、アプライアンスで設定された認証局で署名済みのサーバ証明書を送信する必要があります。

      復号化ポリシーを設定するときは、アプライアンスがそのサーバ証明書への署名に使用する CA 証明書を設定する必要があります。 この CA 証明書は、宛先サーバから提示される証明書の代わりになる、新しい一時的な証明書の発行に使用されます。

      次の証明書初期化方法を使用して、証明書情報を入力できます。
      • [Generate]:いくつかの基本構成情報を入力して、システムに新しい認証局(CA)証明書を自動的に生成させることができます。 この証明書は、自己署名のルート CA 証明書になります。 中間 CA を発行するために使用できる独自の認証局が組織にない場合、および外部 CA から証明書を購入しない場合は、証明書を生成できます。
      • [Import]:システムの外部で作成された CA 証明書と、それと一致する秘密キー ファイルをインポート(アップロード)できます。 ネットワーク上のクライアントが、証明書または証明書を発行した CA を信頼するよう設定済みの場合、証明書とキー ファイルをアップロードできます。 認証局によって署名されたルート証明書または中間証明書のいずれかをアップロードできます。 ASA CX がサーバ証明書を模倣すると、アップロードされた証明書とともに模倣された証明書がクライアント アプリケーションに送信されます。 このように、クライアント アプリケーションが信頼する認証局によって中間証明書が署名される限り、アプリケーションは模倣されたサーバ証明書も信頼します。 組織が独自の認証局を使用する場合、中間証明書をアップロードすることもできますが、セキュリティ上の理由から、ルート証明書は ASA CX にアップロードしないでください。 CA から新しい証明書を要求する場合、それ自体が認証局となる証明書を要求するようにしてください。 つまり、追加の「子」証明書を発行できる証明書が必要です。 アップロードする証明書とキー ファイルは PEM 形式にする必要があります。 DER 形式はサポートされていません。 DER 形式の証明書またはキーを PEM 形式に変換する方法の詳細については、証明書およびキー形式の変換を参照してください。

        (注)  


        アップロードする証明書は、Mozilla Firefox ブラウザを使用して機能するための、基本制約拡張が行われている必要があります。 この制約により、Firefox は証明書を信頼された CA として認識できるようになります。 一般的に、証明書には基本制約拡張が含まれている必要があり、証明書は CA 証明書となっている必要があります。


      生成またはアップロードする証明書は、クライアント アプリケーション(通常はブラウザ)から認識される必要があります。認識されない場合、信頼されていない証明書に関する警告がユーザに表示されることがあります。 また、SSL/​TLS 証明書のダウンロードとインストール で説明されているように、証明書を認識するようにユーザのアプリケーションを設定する必要もあります。

      次に、復号化ポリシーに必要な証明書を生成またはアップロードする手順を説明します。

      手順
        ステップ 1   [Device] > [Decryption] を選択します。

        [Enable Decryption Policies: On] が選択されていることを確認します。

        ステップ 2   次のいずれかを実行します。
        • [Certificate Initialization Method: Generate] を選択して、新しい証明書を作成します。
        • [Certificate Initialization Method: Import] を選択して、すでに存在する証明書と秘密キー ファイルをアップロードします。
        • 設定済みの復号化証明書がすでにあり、それを置き換える場合は、[Current Certificate Information: Replace] をクリックした後、いずれかの初期化方法を選択します。
        ステップ 3   [Generate] を選択した場合、次の情報を入力します。
        • [Common Name]:(CN)。証明書に含める共通名。 これは、デバイスの名前、Web サイト、または他の文字列にすることができます。
        • [Organization]:(O)。証明書に含める組織または会社の名前。
        • [Organizational Unit]:(OU)。証明書に含める組織単位の名前(部門名など)。
        • [Country]:(C)。証明書に含める 2 文字の ISO 3166 国番号。 たとえば、米国の国番号は US です。
        • [Months to Expiration]:証明書の月単位の有効期間。 デフォルトは 12 ヵ月間です。
        • [Set Basic Constraints Extension to Critical: On/Off]:基本制約拡張をクリティカルに設定するかどうか。 基本制約拡張は、証明書が CA 証明書であり、他の証明書の署名にもそれを使用できることを示すものです。 この拡張をクリティカルとして設定すると、この拡張は証明書の意味に対して非常に重要であり、クライアント アプリケーションはこの拡張が意味することを理解していない場合、証明書を受け入れるべきではないということを示します。 大部分の TLS クライアントは、この拡張を認識します。 ただし、[Off] を選択して、拡張が意味することを理解しないクライアント アプリケーションに対処することができます。

        これらの証明書フィールドに含めた情報は、エンド ユーザが Web ブラウザで証明書の詳細を調べると、エンド ユーザに表示されます。 [Common Name and Organization] フィールドを使用して、エンド ユーザに証明書の所有権に関する情報をわかりやすく示します。

        ステップ 4   [Import] を選択した場合、次の情報を入力します。
        • [Certificate]:[Browse] をクリックし、使用する CA 証明書ファイルを選択して、それをデバイスにアップロードします。
        • [Key]:[Browse] をクリックし、使用する秘密キー ファイルを選択して、それをデバイスにアップロードします。
        • [Private Key Phrase]:パス フレーズで保護されている場合は、秘密キー ファイルのパス フレーズを入力します。
        ステップ 5   [Save] をクリックします。

        証明書が生成またはインポートされます。 証明書の概要がページに表示されます。 [Export] をクリックすると、証明書をエクスポートできます。


        証明書およびキー形式の変換

        アップロードするルート証明書と秘密キー ファイルは PEM 形式にする必要があります。 DER 形式はサポートされていません。 ただし、DER 形式の証明書とキーを PEM 形式に変換してから、アップロードすることはできます。 たとえば、OpenSSL を使用して形式を変換できます。

        次の OpenSSL コマンドを使用して、DER 形式の証明書ファイルを PEM 形式の証明書ファイルに変換します。

        openssl x509 -inform DER -in cert_in_DER -outform PEM -out out_file_name
        

        また、同様の OpenSSL コマンドを実行して、DER 形式のキー ファイルを PEM 形式に変換することもできます。

        RSA キーの場合は、次のコマンドを使用します。

        openssl rsa -inform DER -in key_in_DER -outform PEM -out out_file_name
        

        DSA キーの場合は、次のコマンドを使用します。

        openssl dsa -inform DER -in key_in_DER -outform PEM -out out_file_name
        

        OpenSSL の使用の詳細については、OpenSSL のマニュアルを参照するか、http://openssl.org にアクセスしてください。

        SSL/TLS 証明書のダウンロードとインストール

        トラフィックを暗号化する場合、ユーザは TLS/SSL を使用するアプリケーションで、信頼できるルート認証局として定義された暗号化プロセスで使用される、ASA CX CA 証明書を持っている必要があります。 通常、証明書を生成した場合や、証明書をインポートした場合であっても、これらのアプリケーションで証明書がすでに信頼されているものとして定義されることはありません。 大部分の Web ブラウザはデフォルトで、ユーザが HTTPS 要求を送信すると、Web サイトのセキュリティ証明書に問題があることを知らせる警告メッセージがクライアント アプリケーションから表示されます。 通常、このエラー メッセージでは、Web サイトのセキュリティ証明書が信頼された認証局から発行されたものではないこと、または Web サイトが不明な認証局で証明されたものであることが示されますが、警告によって処理中に中間者攻撃の可能性があることが示唆される場合もあります。 クライアント アプリケーションによっては、この警告メッセージがユーザに示されず、ユーザは承認されない証明書を受け入れることができません。

        以下のいくつかの方法で、ユーザに必要な証明書を提供できます。
        • ユーザにルート証明書を受け入れるよう知らせる:組織内のユーザに会社の新しいポリシーの内容を伝え、信頼された送信元として組織によって提供されるルート証明書を受け入れるように伝えることができます。 ユーザは証明書を受け入れ、信頼されたルート認証局のストレージ エリアにそれを保存して、次にサイトにアクセスしたときにプロンプトが再度表示されないようにする必要があります。

          (注)  


          ユーザは、代替証明書を作成した CA 証明書を受け入れて、信頼する必要があります。 そうではなく、単に代替サーバ証明書を信頼した場合は、異なる HTTPS サイトを訪問するたびに、警告が表示される状況が続きます。


        • ルート証明書をクライアント マシンに追加する:信頼できるルート認証局として、ネットワーク上のすべてのクライアント マシンにルート証明書を追加できます。 そうすれば、クライアント アプリケーションは自動的にルート証明書を持つトランザクションを受け入れるようになります。 アプリケーションが使用しているルート証明書を配布したことを確認するには、[Device] > [Decryption] ページからルート証明書をダウンロードします。 [Export] リンクをクリックして、ファイルを保存します。 証明書を電子メールで送信するか、共有サイトに置くことで、ユーザが証明書を入手できるようにします。または、会社のワークステーション イメージに証明書を組み込み、アプリケーションの更新機能を使用して、ユーザに証明書を自動的に配布することもできます。

        ヒント


        クライアント マシンで証明書エラーが発生する可能性を下げるには、証明書をエクスポートしてクライアント アプリケーションに追加するまで、証明書に変更を加えないでください。


        次に、CA 証明書をダウンロードして、ブラウザにインストールする方法を説明します。

        手順
          ステップ 1   必要に応じて、ASA CX から証明書をダウンロードします。
          1. [Device] > [Decryption] を選択します。
          2. [Current Certificate Information] という見出しの横にある [Export] リンクをクリックします。

            ブラウザの設定によっては、ファイルを開くか、保存するかの問い合わせが表示されます。 都合のよい場所に保存します。

          ステップ 2   クライアント システムの Web ブラウザにある信頼されたルート認証局のストレージ エリアに証明書をインストールするか、クライアント自体が証明書をインストールできるようにします。

          手順は、ブラウザのタイプによって異なります。また、ブラウザのバージョンによって異なる場合もあります。 たとえば、Firefox 11 での手順は以下のとおりです。

          1. Firefox で、[Tools] > [Options] を選択します。
          2. [Advanced] を選択してから [Encryption] タブを選択します。
          3. [View Certificates] をクリックして、証明書マネージャを開きます。
          4. [Authorities] タブを選択します。
          5. [Import] をクリックし、ダウンロード ファイル(ca.crt.pem)を選択してダウンロードし、[OK] をクリックします。

            [Downloading Certificate] ダイアログ ボックスが開きます。

          6. [Trust this CA to identify web sites] を選択し、[OK] をクリックします。

            [Authorities] タブの [Certificate Names] のリストに、その CA 名が表示されます。 これで、すべての証明書ダイアログ ボックスを閉じて、ブラウザ ウィンドウに戻ることができます。


          補足的な信頼できる証明書の管理

          ASA CX が TLS サーバの接続要求を受け取ると、サーバ証明書を署名したルート認証局によって検証された宛先サーバの信頼性を検証します。 ASA CX で、サーバ証明書に署名したルート証明書が認識されない場合、そのサーバ証明書は信頼されません。 これは、ASA CX に付属する信頼できる認証局のセットにリストされていない認証局を、TLS サーバが使用している場合に発生します。 組織が内部認証局を使用して、内部ネットワーク上のサーバの証明書に署名する場合に発生する可能性があります。

          ASA CX が、認識されないルート認証局を使用するサーバへのアクセスをブロックしないようにするには、組織が信頼するアプライアンス ルート証明書をアップロードします。 たとえば、ネットワーク上のサーバによって使用されているルート証明書をアップロードできます。 これらの補足的な証明書は、組み込まれた信頼できる証明書と組み合わせて使用されます。

          複数の証明書ファイルをアップロードできます。また、アップロードする各ファイルには複数の証明書を格納することができます。 ルート CA 証明書、中間 CA 証明書、または個々のサーバ証明書でもアップロードできます。 ただし、アップロードする各証明書は PEM 形式にする必要があります。


          (注)  


          システムには、有名な信頼できる CA 証明書の組み込みリストが含まれています。 これらの証明書は、[Device] > [Certificates] ページには表示されません。


          手順
            ステップ 1   [Device] > [Certificates] を選択します。

            証明書リストにはインポートしたすべての証明書が表示され、証明書に定義されている場合は、共通名、組織、組織単位、およびそれぞれの国なども表示されます。

            (注)     

            証明書が不要になった場合、証明書リストで対象の証明書にマウスを合わせ、[Delete Certificate] をクリックします。

            ステップ 2   [I Want To] > [Add Certificate] を選択します。
            ステップ 3   [Browse] をクリックし、証明書ファイルを選択します。
            ステップ 4   [Save] をクリックします。

            その証明書がルート証明書のリストに追加されます。


            復号化ポリシーの設定

            コンテキスト対応復号化ポリシーを ASA CX で使用して、SSL/TLS 暗号化トラフィック フローの処理方法を判別します。 HTTPS トラフィック フローの復号化により、検査されたトラフィック フローの内容、たとえば、アプリケーション、URL カテゴリ、Web レピュテーションなどに基づいてアクセス ポリシーを適用することが可能になります。


            ヒント


            デフォルトでは、暗号化されたトラフィックは復号化されません。 このため、[Decrypt Everything] または [Decrypt Potentially Malicious Traffic] アクションが適用されるポリシーを作成することに焦点を当てます。 [Do Not Decrypt] を使用しているポリシーは、一定のレベルの復号化が適用されるポリシーと別の方法で照合するトラフィックのサブセットを指定している場合にのみ必要です。


            手順
              ステップ 1   [Policies] > [Policies] を選択します。

              ポリシーはポリシー セットに編成され、各ポリシー セットは、ポリシーが別個の順序付きリストになっています。 ポリシー セットに関連したコマンドを参照するには、そのポリシー セットの名前にマウスを置きます。 個々のポリシーに関連したコマンドを参照するには、そのポリシーの名前にマウスを置きます。 これで目的のコマンドを選択できます。

              既存のポリシーについて処理する必要がある場合、フィルタ コントロールを使用すると、変更するポリシーを簡単に見つけることができます。

              ステップ 2   次のいずれかを実行します。
              • リストの最上部に新規ポリシーを作成するには、復号化ポリシー セットの上にマウスを置き、[Add New Policy] をクリックします。
              • 新規ポリシーをリスト中に挿入するには、目的の位置の直下の複合化ポリシーの上にマウスを置き、[Add Above] をクリックします。
              • 既存のポリシーを編集するには、複合化ポリシー名の上にマウスを置き、[Edit Policy] をクリックします。
              • 類似した既存のポリシーを基に新規ポリシーを作成するには、複合化ポリシー名の上にマウスを置き、[Duplicate Policy] をクリックします。

              復号化ポリシーのプロパティとともに、フォームが開きます。 これらのプロパティの詳細については、復号化ポリシーのプロパティを参照してください。

              ステップ 3   [Source]、[Destination]、および [Service] フィールドを使用して、トラフィックの一致基準を定義します。

              基準に基づいてポリシーを制限しない場合は、フィールドをブランクのままにします。 非常に複雑な送信元または宛先基準を作成する必要がある場合は、送信元および宛先グループ ポリシー オブジェクトを使用します。 これらのオブジェクトを使用して、複雑な組み合わせの他のオブジェクトでトラフィック フローを正確に定義できます。 各フィールドについての詳細情報の関連トピックを参照してください。

              ステップ 4   一致するトラフィックに適用するアクションを定義します。
              • [Decrypt Everything]:一致するトラフィックを復号化し、追加のアクセス コントロール ポリシーに従うようにするには、[Decrypt Everything] を選択します。 このオプションは、セキュリティと脅威の特性が不明なトラフィック クラスに使用するのが最も適しています。
              • [Decrypt Potentially Malicious Traffic]:Web レピュテーションに基づいて条件付きでトラフィックを複合化するときに、[Decrypt Potentially Malicious Traffic] を選択します。 低レピュテーション ゾーンに該当する、一致するトラフィックは復号化されますが、高レピュテーション トラフィックは復号化されません。 このオプションを選択する場合は、[Web Reputation Action Profile] フィールドに低レピュテーション ゾーンを定義する Web レピュテーション プロファイル オブジェクトも選択する必要があります。
              • [Do Not Decrypt]:よく知られた銀行または他の金融機関など、受け入れ可能なことが明らかなトラフィックについては、[Do Not Decrypt] を選択して、トラフィックが自由に渡され、トラフィックの復号化に処理パワーが使用されないようにすることができます。
              ステップ 5   [Save Policy] をクリックして変更を保存します。
              ステップ 6   ポリシー セット内の優先順位に収まるように、必要に応じて [Policies] ページでポリシーを移動します。

              ポリシー セット内のポリシーは、最初に一致したものから順に適用されるため、限定的なトラフィック一致基準を持つポリシーは、同じトラフィックに適用され、汎用的な基準を持つポリシーよりも上に置く必要があります。

              ポリシーをドラッグ アンド ドロップしたり、ポリシーにマウスを移動すると表示される [Move Up]、[Move Down] 各リンクを使用することができます。


              復号化ポリシーのプロパティ

              コンテキスト対応復号化ポリシーを ASA CX で使用して、SSL/TLS 暗号化トラフィック フローの処理方法を判別します。 HTTPS トラフィック フローの復号化により、検査されたトラフィック フローの内容、たとえば、アプリケーション、URL カテゴリ、Web レピュテーションなどに基づいてアクセス ポリシーを適用することが可能になります。

              復号化ポリシーには、次のプロパティがあります。

              Policy Name

              ポリシーの名前。 この名前は、このポリシーと一致するトラフィックによって生成された復号化イベントの [Event Viewer] に表示されます。したがって、イベント データの分析に役立つ名前を選択してください。

              Enable Policy:On/Off

              ポリシーがイネーブルかどうかを示します。 ポリシーをオフにすると、ポリシーを削除せずに一時的にディセーブルにできます。 ディセーブルに設定されたポリシーはトラフィックに適用されません。

              Traffic Matching Criteria

              ポリシーが適用されるトラフィックを特定するトラフィックの一致基準。 ポリシーと一致するためには、フローは指定したすべてのプロパティと一致する必要があります。つまり、プロパティの間には AND 関係があります。 条件に基づいてポリシーを制限しない場合は、デフォルトの [Any] を選択します。 考えられるすべてのトラフィック フローを照合するには、すべてのフィールドをデフォルトの [Any] のままにします。

              以下のすべての基準が使用されて、ポリシーが適用されるトラフィックが判別されます。
              • [Source]:ネットワーク グループ(IP アドレス)、ID(ユーザまたはユーザ グループ名)、または Secure Mobility(リモート アクセス VPN クライアントのタイプ)の各タイプのポリシー オブジェクトのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。
              • [Destination]:URL(URL または Web カテゴリ)、または宛先オブジェクト グループ(ポリシーでは直接定義できない複雑な AND/OR 関係のネットワーク グループまたは URL オブジェクトの集合体)の各タイプのポリシー オブジェクトのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、宛先条件を満たしていると見なされます。 URL フィルタリング機能を無効にするか、有効な Web Security Essentials ライセンスを持っていない場合、このフィールドや宛先オブジェクト グループで URL オブジェクトを使用することはできません。

                ヒント


                復号化ポリシーで使用する URL オブジェクトを設定する際には、パス情報を含めないでください。 トラフィックが URL オブジェクトと一致するかどうか評価する際に、復号化ポリシーではパス情報を含んだすべての URL を完全に無視します。 オブジェクトに、ドメイン名だけの URL と、パスが含まれる URL が混在している場合、復号化ポリシーはそのオブジェクトを、ドメイン名だけを指定した URL のみが含まれるものとして扱います。


              • [Service]:プロトコルとポートの組み合わせを定義するサービス グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、サービス条件を満たしていると見なされます。

              (注)  


              マルチ デバイス モード)。PRSMマルチ デバイス モード で使用する際には、送信元基準または宛先基準には、ASA で定義されているネットワーク オブジェクトまたはグループを使用し、サービス基準には、ASA サービス オブジェクトを使用することもできます。 ネットワーク グループ オブジェクトには 2 つのタイプがあります。1 つは ASA と ASA CX の両方で使用できます。もう 1 つは ASA CX でのみ使用でき、特に ASA CX ネットワーク グループと呼ばれます。


              項目の追加、編集、削除方法などの項目の選択方法、選択リストのフィルタリング方法、オブジェクトの作成または編集方法、オブジェクト内容の表示方法については、項目の選択を参照してください。

              Action
              [Action] セクションによって、一致するトラフィック フローが復号化されるかどうかが決定します。 次のオプションがあります。
              • [Decrypt Everything]:トラフィックを復号化して、HTTPS トラフィックを検査します。 アクセス ポリシーによってトラフィック フローが許可された場合、フローは再暗号化され、宛先に送信されます。

                (注)  


                たとえば、デバイスがリモート サーバの証明書を信頼できないなどが原因で、リモート サーバへの保護されたセッションを構築できない場合は、トラフィック フローが拒否されることがあります。 また、サーバによって強力な暗号化が要求される場合、ASA CX の K9 ライセンスを持っている必要があります。これがない場合、フローは拒否されます。


              • [Decrypt Potentially Malicious Traffic]:Web レピュテーションに基づいて、条件付きでトラフィックを復号化します。 低レピュテーション ゾーンに該当する、一致するトラフィックは復号化されますが、高レピュテーション トラフィックは復号化されません。 このオプションを選択する場合は、[Web Reputation Action Profile] フィールドに低レピュテーション ゾーンを定義する Web レピュテーション プロファイル オブジェクトも選択する必要があります。 低レピュテーションの Web サイトへのトラフィックを拒否するには、アクセス ポリシーと同じ Web レピュテーション プロフィルを使用する必要があります。

                (注)  


                [Create New Profile] をクリックして、新規プロフィル オブジェクトを作成できます。 プロファイルの作成、編集、および表示プロセスは、上記で述べたように、これらのアクションを他のポリシー オブジェクトで行う場合と同じです。


              • [Do Not Decrypt]:(デフォルト)。トラフィックを復号化しません。 このトラフィック フローは検査されません。 ただし、十分な情報が HTTP ヘッダーと宛先サーバ証明書から収集され、宛先基準に沿って URL オブジェクトの照合を行えます。 URL の照合は、宛先のドメイン名に基づきます。これは、URL カテゴリと照合することもできます。

                (注)  


                どの宛先ポリシーとも一致しない暗号化されたフローのデフォルト アクションは、[Do Not Decrypt] です。


              Tags

              この項目の識別に役立つ語とフレーズ。 たとえば、同じタグを複数の項目に割り当てると、検索での表示が容易になります。 タグでは、ユーザが選択した使用例、目的、またはその他の特性を識別できます。 これらのタグは、ユーザの目的にのみ対応しています。システムやポリシーの機能には影響しません。 複数のタグを入力(または選択)できます。

              Ticket ID

              ご使用のサポート システム(Remedy など)からのケース ID またはチケット ID。 ネットワーク サポート ケースに関連する変更を行う場合、トラッキング用にここにチケット ID を入力できます。 新しい ID を入力するか、保留中の変更に使用されている既存の ID から選択することができます。必要なだけの ID を指定します。 (すでにコミットされている変更で使用した ID は、このリストに表示されません)

              ナビゲーション パス
              • 復号化ポリシーを作成するには、[Policies] > [Policies] を選択してから、復号化ポリシー セットの名前の上にマウスを置いて、[Add New Policy] をクリックします。
              • 復号化ポリシーを編集するには、[Policies] > [Policies] を選択してから、ポリシーの上にマウスを置いて、[Edit Policy] をクリックします。

              サポートされないアプリケーションの復号化のバイパス

              Dropbox や、AOL Instant Messenger(AIM)などの大部分のインスタント メッセージ アプリケーションは、信頼できるルート証明書ストアに証明書を追加できません。 これらのアプリケーションでは、復号化に使用されている証明書が、あらかじめ信頼されたものになっている必要があります。 ASA CX によって、信頼されていない証明書を使用してトラフィックが復号化されると、これらのアプリケーションは機能しません。 復号化設定で適切な証明書をアップロードしなかった、またはアップロードできなかった場合は、復号化ポリシーによってトラフィックを識別する必要があります。また、これらのアプリケーションを許可する場合は、[Do Not Decrypt] アクションを適用します。

              ASA CX のようなプロキシ サーバによって HTTPS サーバへのトラフィックが復号化されると、一部の HTTPS サーバは期待どおりに機能しなくなります。 たとえば、セキュリティの高い銀行のサイトなど、一部の Web サイトとそれらに関連する Web アプリケーションおよびアプレットは、オペレーティング システムの証明書ストアを使用するのではなく、信頼できる証明書のハードコードされたリストを維持します。

              アプリケーションが ASA CX の復号化をサポートできない現象として、以下を考えます。
              • Event Viewer で、「不明な CA」または「不適切な証明書」アラートが [Decryption Error Details] 列に含まれ、証明書に指定されている認証局が不明であるか、それに関して他の容認できない問題があることを示している TLS の完了イベントを探します。 これは、自己署名証明書を生成した場合に発生する可能性の高いエラーです。
              • AIM の場合、ユーザはログインできません。 他のアプリケーションでも同様の問題が生じることがあります。
              • Dropbox の場合、ユーザに「Unable to make a secure connection」というメッセージが表示される可能性があります。 他のアプリケーションでも同様の問題が生じることがあります。
              これらのアプリケーションで使用されているサーバへのトラフィックに対する復号化をバイパスし、すべてのユーザがこれらのタイプのサイトに確実にアクセスできるようにできます。 復号化をバイパスするには、次の手順に従います。
              1. トラフィックの宛先を識別するオブジェクトを作成します。 HTTPS の場合は URL オブジェクトを使用できます。その他のタイプの TLS トラフィックでは、ネットワーク オブジェクトを使用します。
              2. 宛先としてオブジェクトを使用する復号化ポリシーを作成し、[Do Not Decrypt] アクションを適用します。 同じトラフィックに復号化処理を適用するどのポリシーよりも、ポリシー セット内でそのポリシーが上にあることを確認します。

              次に、AIM の復号化をバイパスする方法の例を示します。

              手順
                ステップ 1   [Policies] > [Policies] を選択します。
                ステップ 2   復号化ポリシーのセットの上にマウスを置き、[Add New Policy] をクリックします。
                ステップ 3   ポリシーの名前(Bypass AIM など)を入力します。
                ステップ 4   [Destination] フィールドの下にある [Create New Object] リンクをクリックして、以下を行います。
                1. オブジェクト名(AIM など)を入力します。
                2. オブジェクト タイプとして [URL Object] を選択します。
                3. [Include] リストで [Instant Messaging] URL カテゴリを選択するか、オプションで、[URL] フィールドに次の項目を入力します。
                  • aimpro.premiumservices.aol.com
                  • bos.oscar.aol.com
                  • kdc.uas.aol.com
                  • buddyart-d03c-sr1.blue.aol.com
                  • 205.188.8.207
                  • 205.188.248.133
                  • 205.188.13.36
                  • 64.12.29.131
                  ヒント   

                  両方を行うと、オブジェクトがカテゴリとサーバ リストを指定するようになります。 サーバをリストする場合、AIM で使用されるサーバの実際のリストは時間の経過に伴って変わる可能性があるため、リストの調整が必要になる可能性があることに注意してください。

                4. [Save Object] をクリックします。

                  オブジェクトが作成され、[Destination] フィールドに追加されます。

                ステップ 5   [Action] フィールドで [Do Not Decrypt] を選択します。
                ステップ 6   [Save Policy] をクリックします。