SSL 復号

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

SSL 復号について

通常、接続は、許可されるかブロックされるかを決定するアクセス コントロール ポリシーを経由します。ただし、SSL 復号ポリシーを有効にする場合、暗号化された接続は最初に SSL 復号ポリシー経由で送信され、復号するかブロックする必要があるかが判断されます。ブロックされていない接続は、復号されているかどうかにかかわらず、許可/ブロックの最終的な決定のためアクセス コントロール ポリシーを経由します。


（注）  

アイデンティティ ポリシーでアクティブな認証ルールを実装するためには、SSL 復号ポリシーを有効にする必要があります。SSL 復号を有効にしてアイデンティティ ポリシーを有効にするが、SSL 復号は実装しない場合、デフォルトのアクションに [復号しない（Do Not Decrypt）] を選択し、追加の SSL 復号ルールは作成しないでください。アイデンティティ ポリシーでは、必要なルールを自動的に生成します。

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

なぜ SSL 復号を実装するか

HTTPS 接続などの暗号化されたトラフィックは検査することができません。

銀行や他の金融機関への接続など、多くの接続は合法的に暗号化されます。多くの Web サイトでは、プライバシーや機密性の高いデータを保護するために暗号化を使用します。たとえば、Device Manager への接続は暗号化されます。

ただし、暗号化された接続の中ではユーザが望ましくないトラフィックを隠すこともできます。

SSL 復号を実装することによって、接続を復号して脅威またはその他の望ましくないトラフィックが含まれていないかを確認するために検査し、再度暗号化してから接続の続行を許可することができます。（復号されたトラフィックは、アクセス制御ポリシーを通過し、暗号化された特性ではなく、復号された接続の検査特性に基づいたルールに一致します。）これは、機密情報を保護するために、アクセス制御ポリシーを適用する必要性とユーザの必要性との間でバランスをとります。

ネットワークを利用させたくない種類の暗号化されたトラフィックをブロックする SSL 復号ルールを構成することもできます。

トラフィックの復号とその後の再暗号化は、全体的なシステム パフォーマンスを低下させるデバイスの処理負荷を増加することに注意してください。

暗号化されたトラフィックに適用できるアクション

SSL 復号ルールを設定する場合は、次のトピックで説明しているアクションを適用できます。これらのアクションは、明示的なルールと一致しないすべてのトラフィックに適用されるデフォルトのアクションにも使用できます。


（注）  

SSL 復号ポリシーを経由するすべてのトラフィックは、アクセス コントロール ポリシーを経由する必要があります。SSL 復号ポリシーにドロップするトラフィックを除き、許可またはドロップの最終的な決定はアクセス コントロール ポリシーに委ねられます。

再署名の復号

トラフィックを復号し再署名する場合、システムは中間者として機能します。

たとえば、ユーザがブラウザでhttps://www.cisco.comと入力します。トラフィックが 脅威に対する防御 デバイスに達すると、デバイスはルールで指定された CA 証明書を使用するユーザと交渉し、ユーザと 脅威に対する防御 デバイス間に SSL トンネルを構築します。同時に、デバイスはhttps://www.cisco.comに接続し、サーバと脅威に対する防御 デバイス間にSSLトンネルを作成します。

このため、ユーザには、www.cisco.comからの証明書ではなく、SSL復号ルールで設定されたCA証明書が表示されます。ユーザは、接続を完了するために証明書を信頼する必要があります。脅威に対する防御 デバイスは、ユーザと宛先サーバ間のトラフィックで両方向に復号/再暗号化を実行します。


証明書の再署名を使用して復号化します。


（注）  

クライアントがサーバ証明書の再署名に使用された CA を信頼していない場合、その証明書を信頼できないとユーザに警告されます。これを防止するには、クライアントの信用できる CA ストアに CA 証明書をインポートします。または組織にプライベート PKI がある場合は、組織の全クライアントで自動的に信頼されるルート CA が署名する中間 CA 証明書を発行して、その CA 証明書をデバイスにアップロードすることもできます。

再署名の復号アクションでルールを設定する場合、設定されているルールの条件に加え、参照される内部 CA 証明書の署名アルゴリズムの種類に基づいてルールがトラフィックと一致します。SSL 復号ポリシーに 1 つの再署名証明書を選択できるため、これによって再署名ルールのトラフィック一致を制限することができます。

たとえば、楕円曲線（EC）アルゴリズムで暗号化された発信トラフィックは、再署名証明書が EC ベースの CA 証明書の場合にのみ、再署名の復号ルールと一致します。同様に、RSA アルゴリズムで暗号化されたトラフィックは、グローバル再署名証明書が RSA の場合にのみ、再署名の復号ルールと一致します。EC アルゴリズムで暗号化された発信トラフィックは、設定されたその他すべてのルール条件が一致していても、このルールとは一致しません。

既知キーの復号

宛先サーバを所有している場合、既知のキーで復号を実装できます。この場合、ユーザが https://www.cisco.com への接続を開くと、それが証明書を提示している 脅威に対する防御 デバイスであっても、www.cisco.com の実際の証明書がユーザに表示されます。


既知のキーを使用して復号します。

ドメインおよび証明書の所有者は、所属組織でなければなりません。cisco.com を例として取り上げると、エンドユーザにシスコの証明書が表示されるのは、組織が実際にドメイン cisco.com の所有者であり（つまり、所属企業が Cisco Systems であること）、パブリック CA によって署名された cisco.com 証明書の所有権を持っている場合のみです。復号できるのは、所属組織が所有するサイトの既存のキーを使用する場合のみです。

既知のキーを使用して復号する主な目的は、HTTPS サーバへのトラフィックを復号して、社内サーバを外部の攻撃から保護することです。外部 HTTPS サイトへのクライアント側のトラフィックを検査する場合は、サーバを所有していないので、再署名の復号を使用する必要があります。


（注）  

既知キーの復号を使用するには、サーバの証明書およびキーを内部アイデンティティ証明書としてアップロードし、SSL 復号ポリシー設定で既知のキー証明書の一覧に追加する必要があります。その後は、宛先アドレスとしてサーバのアドレスを使用して既知のキーの復号のルールを作成できます。SSL 復号ポリシーに証明書を追加する方法については、既知のキーと復号の再署名の証明書の設定を参照してください。

復号禁止

特定の種類のトラフィックで復号をバイパスする場合、トラフィックの処理は行われません。暗号化されたトラフィックはアクセス コントロール ポリシーに渡され、一致するアクセス制御ルールに基づいて許可またはドロップされます。

ブロック

単に SSL 復号ルールと一致する暗号化されたトラフィックをブロックすることができます。SSL 復号ポリシーのブロックでは、アクセス コントロール ポリシーに接続が達することを防ぎます。

HTTPS 接続をブロックすると、ユーザにはシステムのデフォルトのブロック応答ページが表示されません。代わりに、ブラウザのセキュアな接続の障害時のデフォルト ページが表示されます。このエラー メッセージは、ポリシーに基づいてサイトがブロックされたことは示しません。代わりに、一般的な暗号化アルゴリズムが存在しないことを示します。このメッセージでは、接続が意図的にブロックされたのかは分かりません。

自動的に生成された SSL 復号ルール

SSL 復号ポリシーを有効にしてもしなくても、システムはアクティブな認証を実装する各アイデンティティ ポリシー ルールに対して再署名の復号ルールを自動的に生成します。これは、HTTPS 接続でアクティブな認証を有効にするために必要です。

SSL 復号ポリシーを有効にすると、アイデンティティ ポリシーのアクティブな認証ルールの見出しの下にこれらのルールが表示されます。これらのルールは、SSL 復号ポリシーの上部にグループ化されます。ルールは読み取り専用です。アイデンティティ ポリシーを変更することによってのみ変更できます。

復号できないトラフィックの処理

接続が復号できなくなる特性は複数あります。接続に次の特性のいずれかがある場合、接続で一致するルールがあっても接続にはデフォルトのアクションが適用されます。（[復号しない（Do Not Decrypt）] ではなく）デフォルト アクションとしてブロックを選択する場合、正当なトラフィックの過剰なドロップなどの問題があることがあります。デフォルトの動作は変更できます（高度なトラフィックおよび復号できないトラフィックの設定の指定を参照）。

  • 圧縮されたセッション：データ圧縮が接続に適用されています。

  • SSLv2 セッション：サポートされている最下位の SSL バージョンは SSLv3 です。

  • 不明な暗号スイート：システムで接続の暗号スイートが認識されません。

  • サポート外の暗号スイート：システムで、検出された暗号スイートに基づく復号がサポートされません。

  • キャッシュされないセッション：SSL セッションにおいてセッションの再利用が可能になっていて、クライアントとサーバがセッション ID でセッションを再確立したときに、システムがそのセッション ID をキャッシュに入れなかったことを意味します。

  • ハンドシェイク エラー：SSL ハンドシェイクのネゴシエーション中にエラーが発生しました。

  • 復号エラー：復号処理中にエラーが発生しました。

  • パッシブ インターフェイス トラフィック：パッシブ インターフェイス（パッシブ セキュリティ ゾーン）のすべてのトラフィックが復号不能です。

SSL 復号のためのライセンス要件

SSL 復号ポリシーを使用するのに特別なライセンスは必要ありません。

ただし、URL カテゴリおよびレピュテーションを一致基準として使用するルールを作成するには、URL ライセンスが必要です。ライセンスの設定については、オプション ライセンスのイネーブル化とディセーブル化を参照してください。

SSL 復号のガイドライン

SSL 復号ポリシー設定してモニタする場合は、次の点に注意してください。

  • SSL 復号ポリシーは、次のようなアクセス制御ルールがトラフィックを信頼またはブロックするように設定されている場合に、それらのルールに一致する接続に関してバイパスされます。

    • セキュリティ ゾーン、ネットワーク、地理位置情報、およびポートだけをトラフィック照合基準として使用する。

    • 検査を必要とする他のルール（アプリケーションまたは URL に基づいて接続を照合するルールなど）に先立つか、侵入またはファイル検査を適用するルールを許可する。

  • URL カテゴリ照合を使用する場合は、サイトのログイン ページがサイト自体とは異なるカテゴリに含まれる場合があることに注意してください。たとえば、Gmail は「Web based email（Web ベース電子メール）」カテゴリに含まれますが、ログイン ページは「Internet Portals（インターネット ポータル）」カテゴリに含まれます。これらのサイトへの接続を復号するには、両方のカテゴリをルールに含める必要があります。

  • 脆弱性データベース（VDB）の更新によってアプリケーションが削除（廃止）される場合は、削除されたアプリケーションを使用するすべての SSL 暗号解読ルールまたはアプリケーションフィルタに変更を加える必要があります。これらのルールを修正するまで、変更は展開できません。さらに、システムソフトウェアの更新は、問題を修正するまでインストールできません。[アプリケーションフィルタ（Application Filters）] オブジェクト ページ、またはルールの [アプリケーション（Application）] タブでは、これらのアプリケーション名の後に「（廃止）（Deprecated）」と表示されます。

  • アクティブ認証ルールを使用している場合は、SSL 復号ポリシーを無効にすることができません。SSL 復号ポリシーを無効にするには、アイデンティティ ポリシーを無効にするか、またはアクティブ認証を使用するアイデンティティ ルールを削除する必要があります。

SSL 復号ポリシーの実装および管理方法

URL フィルタリング、侵入、マルウェア コントロール、および詳細なパケット検査を必要とするその他のサービスを適用できるように、SSL 復号ポリシーを使用して暗号化されたトラフィックをプレーン テキスト トラフィックにできます。ポリシーがトラフィックが許可する場合、そのトラフィックはデバイスから出る前に再暗号化されます。

SSL 復号ポリシーは、暗号化されたトラフィックにのみ適用されます。暗号化されていない接続は SSL 復号ルールに対して評価されません。

他のセキュリティ ポリシーの場合とは異なり、SSL 復号ポリシーは、監視して積極的に保守する必要があります。これは、証明書の期限が切れたり、宛先サーバで変更されたりするためです。さらに、クライアント ソフトウェアの変更により特定の接続を復号する能力が変わる場合もあります。これは、再署名の復号アクションを中間者攻撃と区別できないためです。

次の手順では、SSL 復号ポリシーの実装と保守のエンドツーエンド プロセスを説明します。

手順

ステップ 1

再署名の復号ルールを実装する場合は、必要な内部 CA 証明書を作成します。

内部認証局（CA）証明書を使用する必要があります。次の選択肢があります。ユーザは証明書を信頼する必要があるため、すでに信頼されると設定されているクライアント ブラウザに証明書をアップロードするか、またはアップロードする証明書がブラウザの信頼ストアに追加されるようにします。

ステップ 2

既知キーの復号ルールを実装する場合は、各内部サーバから証明書とキーを収集します。

サーバから証明書とキーを取得する必要があるため、既知キーの復号は自分で制御しているサーバでのみ使用できます。これらの証明書とキーを内部証明書（内部 CA 証明書ではない）としてアップロードします。「内部および内部 CA 証明書のアップロード」を参照してください。

ステップ 3

SSL 復号ポリシーの有効化。

ポリシーを有効にする際に、いくつかの基本的な設定も構成します。

ステップ 4

SSL 復号のデフォルト アクションの設定を確認してください。

不確かな場合は、デフォルト アクションとして [復号しない（Do not decrypt）] を選択します。この場合でも、アクセス制御ポリシーは、デフォルトの SSL 復号ルールに一致するトラフィックを適切な場合はドロップできます。

ステップ 5

SSL 復号ルールの設定を確認してください。

復号するトラフィック、および適用する復号のタイプを識別します。

ステップ 6

既知のキーでの復号を設定する場合は、これらの証明書を含めるように SSL 復号ポリシー設定を編集します。既知のキーと復号の再署名の証明書の設定を参照してください。

ステップ 7

必要に応じて、再署名の復号ルールに使用する CA 証明書をダウンロードして、クライアント ワークステーションのブラウザにアップロードします。

証明書のダウンロードおよびクライアントへの配布については、再署名の復号ルールの CA 証明書のダウンロードを参照してください。

ステップ 8

定期的に、再署名証明書および既知のキーの証明書を更新します。

  • 再署名証明書：期限切れになる前にこの証明書を更新します。Device Manager を使用して証明書を生成する場合は、5 年間有効です。証明書の有効期間を確認するには、[オブジェクト（Objects）] > [証明書（Certificates）] を選択し、リスト内で証明書を見つけて [アクション（Actions）] 列の [情報（information）] アイコン（View or info icon button.）をクリックします。情報ダイアログ ボックスに、有効期間およびその他の特性が表示されます。このページから代替証明書をアップロードすることもできます。

  • 既知キーの証明書：既知のキーによる復号のルールの場合、宛先サーバの現在の証明書とキーがアップロードされていることを確認する必要があります。サポートされるサーバで証明書およびキーが変更されるたびに、新しい証明書およびキーを（内部証明書として）アップロードし、新しい証明書を使用するように SSL 復号設定を更新する必要があります。

ステップ 9

外部サーバで不足している信頼できる CA 証明書をアップロードします。

システムには、サード パーティによって発行された、広範な信頼できる CA ルート証明書および信頼できる CA 中間証明書が含まれています。これらは、再署名の復号ルールについて 脅威に対する防御 と宛先サーバーの間で接続をネゴシエートするときに必要です。

信頼できるルート CA の信頼チェーン内にあるすべての証明書を、信頼できる CA 証明書のリストにアップロードしますが、これにはルート CA 証明書およびすべての中間 CA 証明書が含まれます。これを行わないと、中間 CA から発行された信頼できる証明書の検出が困難になります。[オブジェクト（Objects）] > [証明書（Certificates）] ページで証明書をアップロードします。「信頼できる CA 証明書のアップロード」を参照してください。

SSL 復号ポリシーの設定

URL フィルタリング、侵入、マルウェア コントロール、および詳細なパケット検査を必要とするその他のサービスを適用できるように、SSL 復号ポリシーを使用して暗号化されたトラフィックをプレーン テキスト トラフィックにできます。ポリシーがトラフィックが許可する場合、そのトラフィックはデバイスから出る前に再暗号化されます。

SSL 復号ポリシーは、暗号化されたトラフィックにのみ適用されます。暗号化されていない接続は SSL 復号ルールに対して評価されません。


（注）  

VPN トンネルは SSL 復号ポリシーが評価される前に復号されるので、トンネル自体にはポリシーは適用されません。ただし、トンネル内で暗号化された接続は SSL 復号ポリシーによる評価の対象となります。

以下の手順で、SSL 復号ポリシーを設定する方法を説明します。SSL 復号を作成および管理するエンドツーエンド プロセスの説明については、SSL 復号ポリシーの実装および管理方法を参照してください。

始める前に

SSL 復号ルール テーブルには、2 つのセクションが含まれています。

  • [アイデンティティポリシーアクティブ認証ルール（Identity Policy Active Authentication Rules）]：アイデンティティ ポリシーを有効にしてアクティブ認証を使用するルールを作成すると、システムがこれらのポリシーの動作に必要な SSL 復号ルールを自動的に作成します。これらのルールは、常に自分で作成した SSL 復号ルールの前に評価されます。アイデンティティ ポリシーに変更することによって、間接的にのみこれらのルール変更できます。

  • [SSL ネイティブ ルール（SSL Native Rules）]：これらはあなたが構成したルールです。このセクションにのみルールを追加できます。

手順

ステップ 1

[ポリシー（Policies）] > [SSL 復号（SSL Decryption）] の順に選択します。

ポリシーをまだ有効化していない場合は、[SSL復号の有効化（Enable SSL Decryption）] をクリックし、「SSL 復号ポリシーの有効化」の説明に従ってポリシーを設定します。

ステップ 2

ポリシーのデフォルト アクションを設定します。

最も安全な選択肢は、[復号しない（Do Not Decrypt）] です。詳細については、SSL 復号のデフォルト アクションの設定を参照してください。

ステップ 3

SSL 復号ポリシーを管理します。

SSL 復号を設定した後、このページにすべてのルールが順番に一覧表示されます。上から下に向かってルールがトラフィックと照合され、最初に適合したルールによって、適用されるアクションが決定されます。このページで次の操作を実行できます。

  • ポリシーを無効にするには、[SSL 復号ポリシー（SSL Decryption Policy）] トグルをクリックします。[SSL複合を有効化（Enable SSL Decryption）] をクリックすると再度有効にできます。

  • ポリシーで使用する証明書のリストを含むポリシー設定を編集するには、[SSL復号設定（SSL Decryption Settings）] ボタン（歯車/設定] をクリックします。）をクリックします。SSL 復号設定の指定を参照してください。また、クライアントに配布できるように、再署名の復号ルールで使用する証明書をダウンロードできます。次の項を参照してください。

  • ルールを設定するには、次の手順を実行します。

    • 新しいルールを作成するには、[+] ボタンをクリックします。SSL 復号ルールの設定を参照してください。

    • 既存のルールを編集する場合は、（[操作（Actions）] 列の）対象のルールの編集アイコン（edit icon）をクリックします。また、テーブル内の特定のルール プロパティをクリックして、そのプロパティを選択的に編集することもできます。

    • 不要になったルールを削除する場合は、（[操作（Actions）] 列の）対象のルールの削除アイコン（delete icon）をクリックします。

  • ルールを移動するには、編集して [順序（Order）] ドロップダウン リストから新しい場所を選択します。

  • URL カテゴリの削除または変更などが原因で特定のルールに問題が発生した場合、これらのルールのみを表示するには、検索ボックスの横にある [See Problem Rules] リンクをクリックしてテーブルをフィルタ処理します。これらのルールを編集および修正（または削除）して、必要とするサービスが提供されるようにします。

SSL 復号ポリシーの有効化

SSL 復号ルールを設定する前に、ポリシーを有効にして、いくつかの基本的な設定を構成する必要があります。以下の手順で、ポリシーを直接有効にする方法を説明します。アイデンティティ ポリシーを有効にするときにこのポリシーを有効にすることもできます。アイデンティティ ポリシーでは、SSL 復号ポリシーを有効にする必要があります。

始める前に

SSL 復号ポリシーを持たないリリースからアップグレードし、アクティブな認証ルールを使用してアイデンティティ ポリシーを設定した場合、SSL 復号ポリシーはすでに有効になっています。必ず使用する再署名の復号証明書を選択し、必要に応じて事前定義されたルールを有効にします。

手順

ステップ 1

[ポリシー（Policies）] > [SSL 復号（SSL Decryption）] の順に選択します。

ステップ 2

[SSL復号の有効化（Enable SSL Decryption）] をクリックしてポリシー設定を構成します。

  • このポリシーを初めて有効にする場合は、[SSL復号設定（SSL Decryption Configuration）] ダイアログ ボックスが開きます。次の手順に進みます。

  • 以前にこのポリシーを設定した後で無効にした場合は、前の設定とルールを使用してポリシーが再度有効になります。[SSL復号設定（SSL Decryption Settings）] ボタン（歯車/設定] をクリックします。）をクリックし、既知のキーと復号の再署名の証明書の設定で説明されているように設定できます。

ステップ 3

[再署名証明書の復号（Decrypt Re-Sign Certificate）] で、再署名証明書での復号を実装するルールに使用するために内部 CA 証明書を選択します。

事前定義済みの NGFW-Default-InternalCA 証明書か、作成またはアップロードしたものを使用できます。証明書がまだ存在しない場合は、[内部CAを作成（Create Internal CA）] をクリックして作成します。

クライアントのブラウザに証明書をまだインストールしていない場合は、ダウンロード ボタン（Download button.）をクリックしてコピーを入手します。証明書をインストールする方法については、各ブラウザのマニュアルを参照してください。再署名の復号ルールの CA 証明書のダウンロードも参照してください。

ステップ 4

（オプション）。[信頼できるCA証明書（Trusted CA Certificates）] の下にある [+] をクリックし、ポリシーで信頼する証明書または証明書グループを選択します。

デフォルトグループの Cisco-Trusted-Authorities には、システム定義の信頼できる CA 証明書がすべて含まれています。追加の証明書をアップロードした場合は、ここでそれらを追加するか、それらを独自のグループに収集して、ここでグループを選択できます。Cisco-Trusted-Authorities グループを置き換えるか、単に独自のグループを追加できます。ユーザは、証明書の署名機関がこのリストに含まれていないサイトの証明書を受け入れるように求められます。証明書が信頼されていないという理由だけで、サイトへのアクセスがブロックされることはありません。

リストを空のままにするか、空の証明書グループのみを選択すると、SSL 復号ポリシーはすべての証明書を信頼します。

ステップ 5

初期 SSL 復号ルールを選択します。

システムには以下の事前定義ルールが含まれており、役立つ場合があります。

  • [Sensitive_Data]：このルールでは、金融サービスまたは健康と医療の URL カテゴリ（銀行、医療機関、ヘルスケア サービスなど）内の Web サイトに一致するトラフィックは復号しません。このルールを実装するには、URL ライセンスを有効にする必要があります。

ステップ 6

[有効化（Enable）]をクリックします。

SSL 復号のデフォルト アクションの設定

暗号化された接続が特定の SSL 復号ルールに一致しない場合、SSL 復号ポリシーのデフォルト アクションに基づいて処理されます。

手順

ステップ 1

[ポリシー（Policies）] > [SSL 復号（SSL Decryption）] の順に選択します。

ステップ 2

[デフォルトアクション（Default Action）] フィールドの任意の場所をクリックします。

ステップ 3

一致するトラフィックに適用するアクションを選択します。

  • [復号しない（Do Not Decrypt）]：暗号化された接続を許可します。次にアクセス制御ポリシーは、暗号化された接続を評価し、アクセス制御ルールに基づいてドロップまたは許可します。

  • [ブロック（Block）]：接続をすぐに切断します。接続はアクセス制御ポリシーに渡されません。

ステップ 4

（オプション）デフォルト アクションのロギングを設定します。

デフォルト アクションに一致するトラフィックのロギングをダッシュボードのデータまたはイベント ビューアに記載されるようにするには、トラフィックのロギングを有効にする必要があります。次のオプションから選択します。

  • [接続終了時（At End of Connection）]：接続の終了時にイベントを生成します。

    • [接続イベントの送信先（Send Connection Events To）]：外部の syslog サーバにイベントのコピーを送信するには、syslog サーバを定義するサーバ オブジェクトを選択します。必要なオブジェクトが存在しない場合は、[新しい Syslog サーバの作成（Create New Syslog Server）] をクリックして作成します（syslog サーバへのロギングを無効化するには、サーバのリストから [任意（Any）] を選択します）。

      デバイスのイベント ストレージは限られているため、外部の syslog サーバにイベントを送信することにより、長期間ストレージが利用できるようになり、イベントの分析を向上できます。

  • [ロギングなし（No Logging）]：イベントを生成しません。

ステップ 5

[保存（Save）] をクリックします。

SSL 復号ルールの設定

SSL 復号ルールを使用して、暗号化された接続を処理する方法を決定します。SSL 復号ポリシーに設定されたルールは、上から下への順に評価されます。トラフィックに適用されるルールは、すべてのトラフィック基準が一致した最初のルールです。

[SSLネイティブルール（SSL Native Rules）] セクションでのみルールを作成し、編集できます。


（注）  

SSL 復号ポリシーが接続を評価する前に、VPN 接続（サイト間とリモート アクセスの両方）のトラフィックが復号されます。したがって、SSL 復号ルールが VPN 接続に適用されることはなく、これらのルールを作成するときに VPN 接続を考慮する必要はありません。ただし、VPN トンネル内で暗号化された接続を使用する場合は評価されます。たとえば、RA VPNトンネル自体は(すでに復号されているので)評価されなくても、RA VPN接続経由の内部サーバへのHTTPS接続は、SSL復号ルールによって評価されます。

始める前に

既知キーの復号ルールを作成する場合は、宛先サーバのための証明書とキーを（内部証明書として）アップロードし、証明書を使用するために SSL 復号ポリシーの設定も編集します。既知キー ルールは通常、ルールの宛先ネットワークの条件で宛先サーバを指定します。詳細については、既知のキーと復号の再署名の証明書の設定を参照してください。

手順

ステップ 1

[ポリシー（Policies）] > [SSL復号（SSL Decryption）] の順に選択します。

（アクティブ認証アイデンティティ ルール用に自動的に生成されたもの以外に）任意の SSL 復号ルールを構成していない場合、[事前定義済みルールを追加（Add Pre-Defined Rules）] をクリックして、事前定義済みのルールを追加できます。ルールを選択するように要求されます。

ステップ 2

次のいずれかを実行します。

  • 新しいルールを作成する場合は、[+] ボタンをクリックします。
  • 既存のルールを編集する場合は、対象のルールの編集アイコン（edit icon）をクリックします。

不要になったルールを削除する場合は、対象のルールの削除アイコン（delete icon）をクリックします。

ステップ 3

[順序（Order）] で、ルールの番号付きリストのどこにルールを挿入するかを選択します。

[SSLネイティブルール（SSL Native Rules）] セクションにのみルールを挿入できます。アイデンティティ ポリシーアクティブ認証ルールはアイデンティティ ポリシーから自動的に生成され、読み取り専用です。

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

デフォルトでは、ルールはリストの最後に追加されます。ルールの配置を後で変更する場合は、このオプションを編集して配置を変更します。

ステップ 4

[タイトル（Title）] にルールの名前を入力します。

この名前にスペースを含めることはできません。英数字と特殊文字 + . _ - を使用できます

ステップ 5

一致するトラフィックに適用するアクションを選択します。

各オプションの詳細については、次を参照してください。

ステップ 6

以下のタブの任意の組み合わせを使用して、トラフィック一致基準を定義します。

  • [送信元/送信先（Source/Destination）]：トラフィックが通過するセキュリティ ゾーン（インターフェイス）、IP アドレスまたは IP アドレスの国/大陸（地理的ロケーション）、トラフィックで使用されている TCP ポート。デフォルトでは、すべてのゾーン、アドレス、地理的ロケーション、TCP ポートが対象になります。SSL 復号ルールの送信元/送信先基準を参照してください。
  • [アプリケーション（Application）]：アプリケーション、またはタイプ、カテゴリ、タグ、リスク、ビジネスとの関連性ごとにアプリケーションを定義するフィルタ。デフォルトは任意の暗号化されたアプリケーションです。SSL 復号ルールのアプリケーション基準を参照してください。
  • [URL]：Web 要求の URL カテゴリ。デフォルトでは URL カテゴリおよびレピュテーションはマッチングの目的では考慮されません。「SSL 復号ルールの URL 基準」を参照してください。
  • [ユーザ（Users）]：アイデンティティ ソース、ユーザまたはユーザ グループ。アイデンティティ ポリシーにより、ユーザおよびグループ情報をトラフィックの照合に使用できるかどうかを判断します。この基準を使用するには、アイデンティティ ポリシーを設定する必要があります。SSL 復号ルールのユーザ基準を参照してください。
  • [拡張（Advanced）]：SSL/TLS バージョンや証明書のステータスなどの接続に使用する証明書に由来する特性。SSL 復号ルールの詳細条件を参照してください。

条件を変更するには、条件内の [+] ボタンをクリックし、希望するオブジェクトまたは要素を選択し、 ポップアップ ダイアログボックスの [OK] をクリックします。基準にオブジェクトが必要で、そのオブジェクトが存在しない場合、[新規オブジェクトの作成（Create New Object）] をクリックします。オブジェクトまたは要素をポリシーから削除するには、そのオブジェクトまたは要素の [x] をクリックします。

条件を SSL 復号ルールに追加する際は、以下のヒントを参考にしてください。

  • 1 つのルールにつき複数の条件を設定できます。ルールがトラフィックに適用されるには、トラフィックがそのルールのすべての条件に一致する必要があります。たとえば、URL カテゴリに基づいて復号するために単一のルールを使用できます。

  • ルールの条件ごとに、最大 50 の条件を追加できます。トラフィックが、基準のいずれかと一致する場合、トラフィックはその条件を満たすことになります。たとえば、単一のルールを使用して、最大 50 のアプリケーションまたはアプリケーション フィルタのアプリケーション制御を適用できます。したがって、単一の条件では項目間に OR 関係がありますが、条件タイプ間（たとえば、送信元/宛先とアプリケーション間）には AND 関係があります。

  • URL カテゴリのマッチングには、URL フィルタリング機能のライセンスが必要です。

ステップ 7

（オプション）ルールのロギングを設定します。

ルールと一致するトラフィックをダッシュボード データまたはイベント ビューアに含めるには、ロギングを有効にする必要があります。次のオプションから選択します。

  • [接続終了時（At End of Connection）]：接続の終了時にイベントを生成します。

    • [接続イベントの送信先（Send Connection Events To）]：外部の syslog サーバにイベントのコピーを送信するには、syslog サーバを定義するサーバ オブジェクトを選択します。必要なオブジェクトが存在しない場合は、[新しい Syslog サーバの作成（Create New Syslog Server）] をクリックして作成します（syslog サーバへのロギングを無効化するには、サーバのリストから [任意（Any）] を選択します）。

      デバイスのイベント ストレージは限られているため、外部の syslog サーバにイベントを送信することにより、長期間ストレージが利用できるようになり、イベントの分析を向上できます。

  • [ロギングなし（No Logging）]：イベントを生成しません。

ステップ 8

[OK] をクリックします。

SSL 復号ルールの送信元/送信先基準

SSL 復号ルールの [送信元/送信先（Source/Destination）] 基準で、トラフィックが通過するセキュリティ ゾーン（インターフェイス）、IP アドレスまたは IP アドレスの国/大陸（地理的ロケーション）、トラフィックで使用されている TCP ポートを定義します。デフォルトでは、すべてのゾーン、アドレス、地理的ロケーション、TCP ポートが対象になります。TCP は、SSL 復号ルールに一致する唯一のプロトコルです。

条件を変更するには、該当する条件の [+] ボタンをクリックして目的のオブジェクトまたは要素を選択し、[OK] をクリックします。基準にオブジェクトが必要で、そのオブジェクトが存在しない場合、[新規オブジェクトの作成（Create New Object）] をクリックします。オブジェクトまたは要素をポリシーから削除するには、そのオブジェクトまたは要素の [x] をクリックします。

ルールに一致する送信元と送信先を識別するのに、次の基準を使用できます。

送信元ゾーン、送信先ゾーン

トラフィックが経由するインターフェイスを定義するセキュリティ ゾーン オブジェクト。どのインターフェイスのトラフィックでも適用するものとして、いずれか、または両方の基準を定義することも、両方とも未定義にすることもできます。

  • ゾーン内のインターフェイスからデバイスを発信するトラフィックと一致させるには、そのゾーンを [送信先ゾーン（Destination Zones）] に追加します。

  • ゾーン内のインターフェイスからデバイスに着信するトラフィックと一致させるには、そのゾーンを [送信元ゾーン（Source Zones）] に追加します。

  • 送信元ゾーンと送信先ゾーンの条件を両方ともルールに追加した場合、指定した送信元ゾーンのいずれかから発信されて、指定した送信先ゾーンのいずれかを経由するトラフィックが一致することになります。

トラフィックがデバイスに出入りする場所に基づいてルールを適用する必要がある場合は、この基準を使用します。たとえば、外部ホストから内部ホストへのすべてのトラフィックが復号されたことを確認したい場合、[送信元ゾーン（Source Zones）] で外部ゾーンを選択し、[送信先ゾーン（Destination Zones）] で内部ゾーンを選択します。

送信元ネットワーク、宛先ネットワーク

ネットワーク アドレスまたはトラフィックの場所を定義するネットワーク オブジェクトまたは地理的位置です。

  • IP アドレスまたは地理的位置からのトラフィックを一致させるには、[送信元ネットワーク（Source Networks）] を設定します。

  • IP アドレスまたは地理的位置へのトラフィックを一致させるには、[送信先ネットワーク（Destination Networks）] を設定します。

  • 送信元と送信先ネットワークの両方の条件をルールに追加すると、一致するトラフィックは指定した IP アドレスのいずれかから送信され、送信先 IP アドレスのいずれかを通って出力されなければなりません。

この条件を追加するには、次のタブから選択します。

  • [ネットワーク（Network）]：制御するトラフィックの送信元または宛先 IP アドレスを定義するネットワーク オブジェクトまたはグループを選択します。


    （注）  

    既知キーの復号ルールの場合、証明書とアップロードしたキーを使用する送信先サーバの IP アドレスを持つオブジェクトを選択します。

  • [地理位置情報（Geolocation）]：位置情報機能を選択して、その送信元または宛先の国や大陸に基づいてトラフィックを制御できます。大陸を選択すると、その大陸内のすべての国が選択されます。地理的位置を直接ルールで選択するほかに、作成した位置情報オブジェクトを選択して場所を定義することもできます。地理的位置を使用すると、特定の国で使用されているすべての潜在的な IP アドレスを知る必要なく、その国へのアクセスを簡単に制限できます。

送信元ポート、宛先ポート/プロトコル

トラフィックで使用されるプロトコルを定義するポート オブジェクト。SSL 復号ルールに対してのみ TCP プロトコルとポートを指定できます。

  • TCP ポートからのトラフィックを一致させるには、[送信元ポート（Source Ports）] を設定します。

  • TCP ポートへのトラフィックを一致させるには、[送信先ポート/プロトコル（Destination Ports/Protocols）] を設定します。

  • 特定の TCP ポートから特定の TCP ポートへ発信されるトラフィックを一致させるには、両方のポートを設定します。たとえば、TCP/80 ポートから TCP/8080 ポートへのトラフィックをターゲットにすることができます。

SSL 復号ルールのアプリケーション基準

SSL 復号ルールのアプリケーション基準では、IP 接続で使用されるアプリケーション、あるいは、タイプ、カテゴリ、タグ、リスク、またはビジネスとの関連性によってアプリケーションを定義するフィルタ処理が定義されます。デフォルトは、SSL プロトコル タグを持つアプリケーションです。暗号化されていないアプリケーションは SSL 復号ルールと一致できません。

ルールで個別のアプリケーションを指定できますが、アプリケーション フィルタを使用すれば、ポリシーの作成と管理が簡単になります。たとえば、リスクが高くビジネス関連性が低いすべてのアプリケーションを復号またはブロックする SSL 復号ルールを作成できます。ユーザがこのようなアプリケーションのいずれかを使用しようとすると、セッションが復号またはブロックされます。

さらに、シスコはシステムおよび脆弱性データベース（VDB）の更新を通して、頻繁にアプリケーション検出機能の更新や追加を行います。これにより、リスクの高いアプリケーションのルールが新しいアプリケーションに自動的に適用される可能性があり、手動でルールを更新する必要がなくなります。

アプリケーションとフィルタをルールで直接指定することも、これらの特性を定義するアプリケーション フィルタ オブジェクトを作成することもできます。複雑なルールを作成する場合は、オブジェクトを使用すると、システム制限内（基準ごとに 50 項目）に収めることが簡単になります。

アプリケーションとフィルタのリストを変更するには、条件内にある [+] ボタンをクリックし、個別のタブにリストされている必要なアプリケーションまたはアプリケーション フィルタ オブジェクトを選択して、ポップアップ ダイアログボックスの [OK] をクリックします。いずれかのタブで [高度なフィルタ（Advanced Filter）] をクリックすると、フィルタ基準の選択、または特定のアプリケーションの検索ができます。アプリケーション、フィルタ、またはオブジェクトの [x] をクリックすると、ポリシーから削除されます。[フィルタとして保存（Save As Filter）] リンクをクリックすると、組み合わせ条件が、新規のアプリケーション フィルタ オブジェクトとして保存されます。

アプリケーション基準と、高度なフィルタを設定してアプリケーションを選択する方法の詳細については、アプリケーション フィルタ オブジェクトの設定を参照してください。

SSL 復号ルールでアプリケーション基準を使用する場合は、次のヒントを考慮してください。

  • システムは、StartTLS を使用して暗号化できる、暗号化されていないアプリケーションを識別できます。これには、SMTPS、POPS、FTPS、TelnetS、および IMAPS などのアプリケーションが含まれます。また、TLS ClientHello メッセージのサーバ ネーム インジケーション、またはサーバ証明書のサブジェクト識別名の値に基づいて特定の暗号化アプリケーションを特定できます。

  • システムは、サーバ証明書の交換後にのみアプリケーションを識別できます。SSL ハンドシェイク中に交換されたトラフィックがアプリケーション基準を含む SSL ルールの他のすべての条件と一致するが識別が完了していない場合、SSL ポリシーはパケットの通過を許可します。この動作により、ハンドシェイクを完了させてアプリケーションを識別できるようにすることができます。システムが識別を完了すると、システムはアプリケーション基準と一致する残りのセッション トラフィックに対して SSL ルール アクションを適用します。

  • 選択したアプリケーションが VDB の更新によって削除された場合は、アプリケーション名の後に「（廃止）」が表示されます。これらのアプリケーションはフィルタから削除する必要があります。削除しないと、それ以降の展開やシステム ソフトウェアのアップグレードがブロックされます。

SSL 復号ルールの URL 基準

SSL 復号ルールの URL の基準は、Web 要求の URL が属するカテゴリを定義します。また、復号、ブロック、または復号せずに許可するサイトの相対的なレピュテーションも指定できます。デフォルトは、URL カテゴリに基づき接続と一致しません。

たとえば、すべての暗号化されたギャンブルサイトをブロックしたり、信頼できないソーシャル ネットワーキング サイトを復号したりできます。該当するカテゴリとレピュテーションの URL をユーザが参照しようとすると、セッションがブロックされるか、または復号されます。URL カテゴリの照合の詳細については、カテゴリ別とレピュテーション別の URL のフィルタリングを参照してください。

[カテゴリ（Categories）] タブ

[+] をクリックし、必要なカテゴリを選択し、[OK] をクリックします。ポリシーからカテゴリやオブジェクトを削除するには、該当する [x] をクリックします。

デフォルトでは、レピューテションに関係なく、選択した各カテゴリのすべての URL にルールが適用されます。レピュテーションに基づいてルールを制限するには、各カテゴリの下矢印をクリックして、[任意（Any）] チェックボックスを選択解除し、[レピュテーション（Reputation）] スライダを使用してレピュテーション レベルを選択します。レピュテーション スライダの左側に復号なしで許可されるサイトが示され、右側に復号またはブロックされるサイトが示されます。レピュテーションの使用方法はルール アクションによって異なります。

  • ルールで接続が復号またはブロックされる場合は、レピュテーション レベルを選択すると、そのレベルよりもシビラティ（重大度）が高いすべてのレピュテーションも選択されます。たとえば、問題のあるサイト（レベル 2）を復号またはブロックするルールを設定する場合、信頼できない（レベル 1）のサイトも自動的に復号またはブロックされます。

  • ルールで復号なし（復号しない）で接続が許可される場合は、レピュテーション レベルを選択すると、そのレベルよりもシビラティ（重大度）が低いすべてのレピュテーションも選択されます。たとえば、[好ましいサイト（Favorable sites）]（レベル 4）を復号しないルールを設定した場合、[信頼できる（Trusted）]（レベル 5）サイトも自動的に復号されません。

レピュテーションが不明な URL をレピュテーション一致に含めるには、[レピュテーションが不明なサイトを含める（Include Sites with Unknown Reputation）] オプションを選択します。通常、新しいサイトは評価されていません。また、その他の理由でサイトのレピュテーションが不明である（または判断できない）場合もあります。

URLのカテゴリを確認します。

特定の URL のカテゴリとレピュテーションを確認できます。[確認するURL]ボックスにURLを入力し、[移動]をクリックします。結果を表示するには、外部の Web サイトに移動します。分類に同意しない場合は、[URLカテゴリの異議を送信する]リンクをクリックしてお知らせください。

SSL 復号ルールのユーザ基準

SSL 復号ルールのユーザ基準は、IP 接続のユーザまたはユーザ グループを定義します。ルールにユーザまたはユーザ グループの基準を含めるように、アイデンティティ ポリシーと関連ディレクトリ サーバを設定する必要があります。

アイデンティティ ポリシーは、特定の接続のためにユーザ アイデンティティを収集するかどうかを決定します。アイデンティティが確立されると、ホストの IP アドレスが識別されたユーザに関連付けられます。したがって、送信元 IP アドレスがユーザにマッピングされているトラフィックは、そのユーザから発信されたものとみなされます。IP パケット自体にはユーザ アイデンティティ情報が含まれていないため、この IP アドレスからユーザへのマッピングが最良の推測となります。

1 つのルールに最大 50 のユーザまたはグループを追加できるので、個々のユーザを選択するよりも、グループを選択する方が妥当です。たとえば、外部ネットワークからエンジニアリンググループへのトラフィックを復号するルールを作成し、そのグループからの発信トラフィックを復号しない別のルールを作成できます。すると、新しいエンジニアにこのルールを適用するには、エンジニアをディレクトリ サーバの Engineering グループに追加するだけですみます。

そのソース内のすべてのユーザに適用するアイデンティティ ソースを選択することもできます。したがって、複数のActive Directoryドメインをサポートしている場合は、ドメインに基づいて差分復号を提供できます。

ユーザ リストを変更するには、条件の中にある [+] ボタンをクリックし、次のいずれかの方法でユーザまたはユーザ グループを選択します。ポリシーからユーザまたはグループを削除するには、該当する [x] をクリックします。

  • [アイデンティティソース（Identity Sources）]：AD レルムやローカル ユーザ データベースなど、選択したソースから取得したすべてのユーザにルールを適用するアイデンティティ ソースを選択します。必要なレルムがまだ存在していない場合は、[新しいアイデンティティレルムの作成（Create New Identity Realm）] をクリックします。

  • [グループ（Groups）]：目的のユーザ グループを選択します。グループを選択できるのは、ディレクトリ サーバでグループを設定している場合だけです。グループを選択すると、そのグループのすべてのメンバー（サブグループを含む）にそのルールが適用されます。サブグループを別の方法で処理する場合は、サブグループ用の個別のアクセス ルールを作成し、それをアクセス コントロール ポリシー内で親グループのルールの上に配置する必要があります。

  • [ユーザ]: 個々のユーザを選択します。ユーザ名には、Realm\usernameなどのアイデンティティソースのプレフィックスが付きます。

    Special-Identities-Realmの下にはいくつかの組み込みユーザがあります。

    • [認証失敗（Failed Authentication）]：ユーザが認証を求められ、有効なユーザ名/パスワードを入力できずに最大試行回数に達しました。認証の失敗により、ユーザがネットワークにアクセスできなくなることはありませんが、このようなユーザに対してネットワーク アクセスを制限するアクセス ルールを作成できます。

    • [ゲスト（Guest）]：ゲスト ユーザは [認証失敗（Failed Authentication）] ユーザと似ていますが、アイデンティティ ルールでこのようなユーザがゲストと呼ばれるように設定されている点で異なります。ゲスト ユーザが認証を求められましたが、認証できずに最大試行回数に達しました。

    • [認証不要（No Authentication Required）]：ユーザの接続が、認証不要と指定されているアイデンティティ ルールに一致したため、ユーザは認証を求められませんでした。

    • [不明（Unknown）]：IP アドレスのユーザ マッピングがないため、認証失敗の記録がありません。通常、これは、HTTP トラフィックがそのアドレスからまだ見られてないことを意味します。

SSL 復号ルールの詳細条件

詳細のトラフィックの一致条件は、接続に使用する証明書に由来する特徴に関連します。次のオプションのいずれかまたはすべてを設定できます。

証明書のプロパティ

トラフィックは、選択したプロパティのいずれかに一致する場合、ルールの証明書プロパティのオプションに一致します。次の項目を設定できます。

証明書のステータス

証明書が [有効（Valid）] か [無効（Invalid）] か。証明書のステータスを気にしない場合は、[任意（Any）]（デフォルト）を選択します。

証明書は、次の条件のすべてが満たされている場合に有効とみなされ、それ以外の場合は無効とみなされます。

  • ポリシーが証明書を発行した CA を信用できる。

  • 証明書の署名を証明書の内容に対して正しく検証できる。

  • 発行元の CA 証明書が信用できる CA 証明書のポリシーのリストに格納されている。

  • ポリシーの信用できる CA すべてで証明書が失効していない。

  • 現在の日付が証明書の [有効期間の開始（Valid From）] と [有効期間の終了（Valid To）] の期間内にある。

自己署名

サーバ証明書に同じサブジェクトおよび発行元識別名が含まれているかどうか。次のいずれかを選択します。

  • 自己署名（Self-Signing）：サーバ証明書は自己署名されています。

  • CA 署名（CA-Signing）：サーバ証明書は認証局によって署名されています。 つまり、発行元とサブジェクトは同じではありません。

  • 任意（Any）：証明書が自己署名されているかどうかを一致条件として考慮しません。

サポートされるバージョン

一致する SSL/TLS バージョン。ルールは、選択したいずれかのバージョンを使用するトラフィックにのみ適用されます。デフォルトは全バージョンです。SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3 から選択してください。

たとえば、TLSv1.2/3 の接続のみを許可する場合は、それよりも低いバージョンにブロックルールを作成できます。

TLS 1.3 接続に一致させるには Snort 3 を使用している必要があります。

記載されていない SSL v2.0 などのバージョンを使用するトラフィックは、SSL 復号ポリシーのデフォルトのアクションによって処理されます。

SSL 復号設定の指定

トラフィックを復号するルールがある場合は、証明書設定を指定する必要があります。設定を変更して、暗号化されたトラフィックに復号を適用する方法を変更することもできます。以降のトピックでは、オプションについて説明します。

既知のキーと復号の再署名の証明書の設定

再署名によってまたは既知のキーを使用して復号を実装する場合は、SSL 復号ルールが使用できる証明書を特定する必要があります。すべての証明書が有効で、期限が切れていないことを確認します。

特に既知のキーの復号の場合は、復号する接続の各宛先サーバの現在の証明書とキーがシステムにあることを確認する必要があります。既知キーの復号ルールでは、復号の宛先サーバからの実際の証明書とキーを使用します。したがって、常に脅威に対する防御 デバイスに最新の証明書とキーがあることを確認する必要があります。そうでない場合復号は失敗します。

既知のキー ルールで宛先サーバの証明書またはキーを変更するたびに新しい内部証明書とキーをアップロードします。それらを内部証明書（内部 CA 証明書ではありません）としてアップロードします。次の手順の間に証明書をアップロードするか、[オブジェクト（Objects）] > [証明書（Certificates）] ページに進み、そこにアップロードします。

手順

ステップ 1

[ポリシー（Policies）] > [SSL復号（SSL Decryption）] の順に選択します。

ステップ 2

[SSL復号設定（SSL Decryption Settings）] ボタン（歯車/設定] をクリックします。）をクリックします。

必要に応じて、[基本（Basic）] タブを選択します。

ステップ 3

[再署名証明書の復号（Decrypt Re-Sign Certificate）] で、再署名証明書での復号を実装するルールに使用するために内部 CA 証明書を選択します。

事前定義済みの NGFW-Default-InternalCA 証明書か、作成またはアップロードしたものを使用できます。証明書がまだ存在しない場合は、[内部CAを作成（Create Internal CA）] をクリックして作成します。

クライアントのブラウザに証明書をまだインストールしていない場合は、ダウンロード ボタン（Download button.）をクリックしてコピーを入手します。証明書をインストールする方法については、各ブラウザのマニュアルを参照してください。再署名の復号ルールの CA 証明書のダウンロードも参照してください。

ステップ 4

既知のキーを使用して復号するルールごとに、宛先サーバの内部証明書とキーをアップロードします。

  1. [既知キー証明書の復号（Decrypt Known-Key Certificates）] で [+] をクリックします。

  2. 内部 ID の証明書を選択するか、[新しい内部証明書の作成（Create New Internal Certificate）] をクリックし、ここでそれをアップロードします。

  3. [OK] をクリックします。

ステップ 5

（オプション）。[信頼できるCA証明書（Trusted CA Certificates）] の下にある [+] をクリックし、ポリシーで信頼する証明書または証明書グループを選択します。

デフォルトグループの Cisco-Trusted-Authorities には、システム定義の信頼できる CA 証明書がすべて含まれています。この設定の変更が必要になる可能性のある主なケースは次のとおりです。

  • デフォルトグループにない信頼できる CA 証明書を使用する場合。作成後、SSL 復号ポリシー設定でデフォルトグループと新しいグループの両方を選択します。これは、追加の信頼できる CA 証明書をアップロード済みの場合に実行できます。

  • デフォルトグループにあるものよりも限定された信頼できる CA 証明書のリストを使用する場合。作成後、信頼できる証明書の完全なリスト（差分だけでなく）を持つグループを作成し、SSL 復号ポリシー設定で唯一のグループとして選択します。

ユーザは、証明書の署名機関がこのリストに含まれていないサイトの証明書を受け入れるように求められます。証明書が信頼されていないという理由だけで、サイトへのアクセスがブロックされることはありません。

リストを空のままにするか、空の証明書グループのみを選択すると、SSL 復号ポリシーはすべての証明書を信頼します。

ステップ 6

[保存（Save）] をクリックします。

高度なトラフィックおよび復号できないトラフィックの設定の指定

デフォルトの動作を使用しない場合は、高度な復号の設定と復号できないトラフィックの設定を指定できます。

手順

ステップ 1

[ポリシー（Policies）] > [SSL復号（SSL Decryption）] の順に選択します。

ステップ 2

[SSL復号設定（SSL Decryption Settings）] ボタン（歯車/設定] をクリックします。）をクリックします。

ステップ 3

[詳細（Advanced）] タブで、TLS 1.3 復号を有効にするかどうかを選択します。

TLS 1.3 復号を有効にする場合は、TLS 1.3 に適用する必要がある各ルールの [詳細（Advanced）] タブでも [TLS 1.3] オプションを選択する必要があります。TLS 1.3 を復号するには、Snort 3 を実行している必要があります。

ステップ 4

[復号化不可のアクション（Undecryptable Actions）] タブで、復号を実装するルールに一致するものの復号できない接続をシステムが処理する方法を変更します。

デフォルトでは、これらの接続にはデフォルトアクションと同じアクションが適用されます。例外は復号エラーの発生であり、それについてはブロックするかリセットによりブロックすることのみを選択できます。

これらのカテゴリの説明については、復号できないトラフィックの処理を参照してください。

ステップ 5

[OK] をクリックします。

再署名の復号ルールの CA 証明書のダウンロード

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

以下のいくつかの方法で、ユーザに必要な証明書を提供できます。

ルート証明書を受け入れるようにユーザに通知する

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


（注）  

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

クライアントデバイスにルート証明書を追加する

ネットワーク上のすべてのクライアントデバイスに、信頼できるルート認証局としてルート証明書を追加できます。そうすれば、クライアント アプリケーションは自動的にルート証明書を持つトランザクションを受け入れるようになります。

証明書を電子メールで送信するか、共有サイトに置くことで、ユーザが証明書を入手できるようにします。または、会社のワークステーション イメージに証明書を組み込み、アプリケーションの更新機能を使用して、ユーザに証明書を自動的に配布することもできます。

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

手順

ステップ 1

Device Manager から証明書をダウンロードします。

  1. [ポリシー（Policies）] > [SSL復号（SSL Decryption）] の順に選択します。

  2. [SSL復号設定（SSL Decryption Settings）] ボタン（歯車/設定] をクリックします。）をクリックします。

  3. [Download] ボタン（Download button.）をクリックします。

  4. ダウンロード場所を選択して、必要に応じてファイル名を変更し（拡張子はそのまま）、[保存（Save）] をクリックします。

    これで、[SSL 復号設定（SSL Decryption Settings）] ダイアログ ボックスからキャンセルできます。

ステップ 2

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

プロセスは、オペレーティング システムとブラウザの種類によって異なります。たとえば、Windows 上で実行されている Internet Explorer および Chrome の場合は次のプロセスを使用できます。（Firefox の場合は、[ツール（Tools）] > [オプション（Options）] > [詳細（Advanced）] ページでインストールします。）

  1. [スタート（Start）] メニューから、[コントロールパネル（Control Panel）] > [インターネットオプション（Internet Options）] を選択します。

  2. [Content] タブを選択します。

  3. [証明書（Certificates）] ボタンをクリックして、[証明書（Certificates）] ダイアログ ボックスを開きます。

  4. [信頼されたルート証明機関（Trusted Root Certification Authorities）] タブを選択します。

  5. [Import（インポート）] をクリックし、ウィザードに従ってダウンロードされたファイル（<uuid>_internalCA.crt）を見つけて選択し、信頼できるルート認証局のストアに追加します。

  6. [Finish] をクリックします。

    メッセージは、インポートが成功したことを示しているはずです。ユーザがよく知られたサード パーティの認証局から証明書を取得するのではなく自己署名証明書を生成した場合は、途中で Windows が証明書を検証できなかったことを警告するダイアログ ボックスが表示される場合があります。

    [証明書（Certificates）] ダイアログ ボックスと [インターネット オプション（Internet Options）] ダイアログ ボックスを閉じることができます。

例：ネットワークからの古い SSL/TLS バージョンのブロック

一部の組織では、政府の規制または会社のポリシーにより、古いバージョンのSSLまたはTLSの使用を禁止する必要があります。SSL復号ポリシーを使用して、禁止するSSL/TLSバージョンを使用するトラフィックをブロックできます。禁止されたトラフィックをすぐに捕捉できるようにするには、このルールをSSL復号ポリシーの先頭に配置することを検討してください。

次の例では、すべてのSSL 3.0およびTLS 1.0接続をブロックします。

始める前に

この手順では、SSL 復号ポリシーがすでに有効になっていると仮定します（SSL 復号ポリシーの有効化 を参照）。

手順

ステップ 1

[ポリシー（Policies）] > [SSL復号（SSL Decryption）] の順に選択します。

ステップ 2

[+] ボタンをクリックして、新しいルールを作成します。

ステップ 3

[順序（Order）] で、[1] を選択してルールをポリシーの先頭に配置するか、またはネットワークに最も適した数を選択します。

デフォルトでは、ルールはポリシーの最後に追加されます。

ステップ 4

[タイトル（Title）] に、ルールの名前（たとえば、Block_SSL3.0_and_TLS1.0）を入力します。

ステップ 5

[アクション（Action）] で、[ブロック（Block）] を選択します。これにより、ルールに一致するすべてのトラフィックが即座にドロップされます。

ステップ 6

[送信元/宛先（Source/Destination）]、[アプリケーション（Applications）]、[URL（URLs）]、[ユーザ（Users）] の各タブについては、すべてのオプションをデフォルト値のままにします。

ステップ 7

[詳細（Advanced）] タブをクリックし、[サポートされているバージョン（Supported Versions）] の下の [SSL 3.0] と [TLS 1.0] を選択したままにします。ただし、[TLS 1.1]、[TLS 1.2]、および [TLS 1.3] はオフにします。

ステップ 8

（任意）ブロックされた接続をダッシュボードやイベントに反映させるには、[ロギング（Logging）] タブをクリックし、[接続終了（At End of Connection）] を選択します。外部syslogサーバを使用している場合は、それを選択することもできます。

ステップ 9

[OK]をクリックします。

これでポリシーを展開できます。展開すると、システムを通過するSSL 3.0またはTLS 1.0接続はドロップされます。

（注）  

 

SSL 2.0 接続は、ポリシーのデフォルトアクションによって処理されます。これらもドロップされるようにするには、デフォルトアクションを [ブロック（Block）] に変更します。

次のタスク

このルールを実装する場合、次の推奨事項があります。

  • どのタイプの復号ルールでも、すべてのSSL/TLSオプションが選択されている[詳細設定]タブはデフォルト設定のままにします。すべてのバージョンに適用することで、ハンドシェイクプロセスが簡素化されます。ただし、最初のブロックルールでは、SSL 3.0 および TLS 1.0 接続が引き続き妨げられます。

  • 通常は、ポリシーのデフォルトアクションとして [復号しない（Do Not Decrypt）] を使用することをお勧めします。しかし、SSL 2.0 接続は常にデフォルトアクションによって処理されるため、代わりに [ブロック（Block）] を使用することもできます。ただし、すべての復号可能なトラフィックのデフォルト アクションとして [復号しない（Do Not Decrypt）] を適用する場合は、ポリシーの最後に [復号しない（Do Not Decrypt）] ルールを作成し、トラフィック一致基準のすべてのデフォルト値を受け入れます。このルールならば、テーブル内の以前のルールに一致しない、すべてのサポート対象の TLS 接続に一致し、それらの TLS バージョンにおけるデフォルトとして機能します。

SSL 復号のモニタリングおよびトラブルシューティング

ここでは、SSL 復号ポリシーのモニタおよびトラブルシューティング方法について説明します。

SSL 復号のモニタリング

ダッシュボードに復号についての情報を表示でき、ログ収集を有効化したルール（またはデフォルトのアクション）に一致するトラフィックのイベントを表示できます。

SSL 復号のダッシュボード

全体的な復号の統計情報を評価するには、[モニタリング（Monitoring）] > [SSL復号（SSL Decryption）] ダッシュボードを表示します。ダッシュボードには次の情報が表示されます。

  • 暗号化されたトラフィックとプレーン テキスト トラフィックの割合。

  • SSL ルールに従って、暗号化されたトラフィックがどの程度復号されたか。

イベン

ダッシュボードに加えて、イベント ビューア（[モニタリング（Monitoring）] > [イベント（Events）]）には、暗号化されたトラフィックの SSL 情報が含まれています。イベントの評価についていくつかのヒントを次に示します。

  • 一致するトラフィックをブロックする SSL ルール（またはデフォルトのアクション）と一致したためにドロップされた接続の場合、[アクション（Action）] は「ブロック」で、[理由（Reason）] は「SSL ブロック」を示す必要があります。

  • [実際のSSLアクション（SSL Actual Action）] フィールドは、システムが接続に適用した実際のアクションを示します。これは、一致するルールに定義されたアクションを示す [予期されたSSLアクション（SSL Expected Action）] とは異なります。たとえば、接続が復号を適用するルールと一致しても、いくつかの理由で復号できないことがあります。

復号再署名がブラウザに関して動作する（ただしアプリケーションに関しては機能しない）Web サイトの処理（SSL または認証局ピンニング）

スマートフォンおよびその他のデバイス用の一部のアプリケーションでは「SSL（または認証局）ピンニング」と呼ばれる手法が使用されます。SSL ピンニング手法では、元のサーバ証明書のハッシュがアプリケーション自体の内部に埋め込まれます。その結果、アプリケーションが 脅威に対する防御 デバイスから再署名された証明書を受け取ると、ハッシュ検証に失敗し、接続が中断されます。

Web サイトのアプリケーションを使用してそのサイトに接続することができないにもかかわらず、Web ブラウザを使用する場合は、接続に失敗したアプリケーションを使用したデバイス上のブラウザでも接続できるというのが主な症状です。たとえば、Facebook の iOS または Android アプリケーションを使用すると接続に失敗しますが、Safari または Chrome で https://www.facebook.com を指定すると接続に成功します。

SSL ピンニングは特に中間者攻撃を回避するために使用されるため、回避策はありません。次のいずれかの選択肢を使用する必要があります。

  • アプリケーションのユーザをサポートします。この場合は、サイトへのトラフィックを復号できません。[SSL復号（SSL Decryption）] ルールの [アプリケーション（Application）] タブで、サイトのアプリケーションの [復号しない（Do Not Decrypt）] ルールを作成し、そのルールが、接続に適用される [再署名の復号（Decrypt Re-sign）] ルールの前に適用されることを確認します。

  • ユーザにブラウザだけを使用させます。サイトへのトラフィックを復号する必要がある場合は、ネットワーク経由で接続するときにサイトのアプリケーションを使用できないためにブラウザだけを使用する必要があることをユーザに通知する必要があります。

詳細の表示

サイトがブラウザでは機能するのに同じデバイス上のアプリケーションでは機能しない場合は、ほぼ確実に SSL ピンニングによるものと考えられます。ただし、詳しく調べる必要がある場合は、ブラウザのテストに加えて、接続イベントを使用して SSL ピンニングを識別できます。

アプリケーションは、次の 2 つの方法でハッシュ検証の失敗に対処する場合があります。

  • グループ 1 のアプリケーション（Facebook など）は、サーバから SH、CERT、SHD メッセージを受け取るとすぐに SSL ALERT メッセージを送信します。アラートは、通常、SSL ピンニングを示す「Unknown CA (48)」アラートです。アラート メッセージの後に TCP リセットが送信されます。イベントの詳細情報で次のような症状が見られます。

    • SSL フロー フラグには ALERT_SEEN が含まれます。

    • SSL フロー フラグには APP_DATA_C2S または APP_DATA_S2C は含まれません。

    • SSL フロー メッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE です。

  • グループ 2 のアプリケーション（Dropbox など）はアラートを送信しません。代わりに、ハンドシェイクが完了するまで待ってから TCP リセットを送信します。イベントで次のような症状が見られます。

    • SSL フロー フラグには ALERT_SEEN、APP_DATA_C2S、または APP_DATA_S2C は含まれません。

    • SSL フロー メッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE、CLIENT_KEY_EXCHANGE、CLIENT_CHANGE_CIPHER_SPEC、CLIENT_FINISHED、SERVER_CHANGE_CIPHER_SPEC、SERVER_FINISHED です。