暗号化された脅威からの防御

EU一般データ保護規則（GDPR）、Googleの検索結果ランキングの優先順位、HTTP（クリアテキスト）サイトに対するブラウザの警告、安価な証明書や無料の証明書（Let’s Encrypt）の入手が容易になったことなど、採用が進んだ背景にはいくつもの要因があり、これらは一部の例にすぎません。この進化によりWebトラフィックのセキュリティは向上していますが、これには暗号化されたトラフィックに潜むマルウェアの危険性と、ワークロード需要の増大という代償が伴います。そのため、組織は、強固なセキュリティとプライバシーを確保しつつ、インフラストラクチャのスピードと可用性を高めるソリューションを実装する必要があります。

見えないものを守ることはできない

トラフィックの暗号化は、データの閲覧や改ざん攻撃を行う可能性がある中間者攻撃を防ぐのに最適ですが、暗号化により、検査または分析用のデバイスやサービスがトラフィックを認識できなくなる可能性があります。トラフィックの暗号化および復号化では多くの計算能力が消費されるため、侵入検知/防止システム（IDS/IPS）、マルウェア サンドボックス、次世代ファイアウォール（NGFW）など多くのセキュリティ検査ソリューションでは、まったく復号化が行われないか、またはパフォーマンスが大幅に低下し処理が追い付かず、暗号化されたトラフィックをそのまま通過させてしまいます。アプリケーションに入ってくるトラフィックでも、インターネットに出ていく内部トラフィックでも、すべてのインフラストラクチャへの投資がその潜在能力を十分に発揮するには、それらの可視性を確保する必要があります。

アウトバウンドSSL/TLS検査における課題

マルウェアが危険であることは誰もが知っていますが、他のユーザーやデバイスへのマルウェアの伝播やデータの流出を特定して阻止するには通常、多層的な防御が使用されます。マルウェアは、悪意のあるWebサイトやフィッシング メールなど、さまざまなソースから取り込まれる可能性があるため、出口ネットワーク トラフィックを検査し、マルウェアが指揮統制サーバーを呼び出すことができないことと、管理環境に機密データが放置されていないことを確認する必要があります。現在は、ほぼすべての攻撃者が暗号化されたチャネルを使用してマルウェアのアウトバウンド通信を隠蔽しているため、これは課題となっています。

インバウンドSSL/TLS検査における課題

また、インバウンド トラフィックの検査の難しさもあります。F5 Labsの『2018年版アプリケーション プロテクション レポート』によると、アプリやWebサイトの多くは組織のビジネスにとって不可欠なものであり、Webアプリの34%がミッション クリティカルであると報告されています。また、アプリケーションが不可欠なものである場合、悪意のあるトラフィックを排除するWebアプリケーション ファイアウォール（WAF）やIDS/IPSなどのセキュリティ ソリューションを使用することになるでしょう。セキュリティ検査デバイスに加えて、アナリティクス エンジンやカスタマ エクスペリエンス ソリューションを使用してアプリケーション トラフィックを実行する必要があるかもしれません。これらのソリューションはすべて独自の価値を提供しますが、大規模な復号化はおそらくその中には含まれていないでしょう。

SSL/TLSの可視性のメリット

最近のF5 Labsの調査によると、マルウェアの68%が、マルウェアの識別と無効化を目的としたセキュリティ デバイスから自身の経路を隠すために暗号化を使用していることが明らかになりました。この数字は今後も増加していくと考えられます。多層防御戦略を導入する際、多くの管理者は、マルウェアから防御するために複数のセキュリティ ソリューションを1つのシリアル チェーンに展開しています。これは驚くほど非効率的であり、また、1つのセキュリティ検査ソリューションに過剰の負荷がかかることで悪意のあるトラフィックが通過してしまう可能性も残されます。可視性とセキュリティは必要ですが、パフォーマンスを損なうことはできません。

暗号化されたマルウェアを無効化

トラフィックを復号化して検査デバイスに送信するSSL/TLSソリューションは、マルウェアの影響を軽減するための最初のステップとしては有効です。しかし、特定のトラフィックが特定の検査デバイスを通過する必要がない場合、不必要なレイテンシが発生する可能性があります。たとえば、ユーザーのアウトバウンド トラフィックが既知の優良サイト（またはIPアドレス）に向かっていて、データ損失防止（DLP）ソリューションで機密性の高いトラフィックが検出されなかった場合でも、そのトラフィックはNGFWやIDSを通過する必要があるでしょうか？おそらく、リスク許容度に応じてトラフィックの経路をカスタマイズする機能を持つことが重要になるでしょう。

完全前方秘匿性と暗号の俊敏性

TLSプロトコルには、完全前方秘匿性（PFS）保護と呼ばれるパッシブ監視手段があり、暗号化された接続の両側の鍵確立プロトコルにそのためのやり取りが追加されます。PFSは、ユーザーが開始するセッションごとに一意のセッション鍵を生成することで、攻撃者が単一の鍵を簡単に復元して以前に記録された何百万もの対話を解読できないようにします。

PFSが事実上の標準になると、特にこれはTLS 1.3で唯一許可されている方法であるため、インバウンド トラフィックについてパッシブ検査ソリューションの計画を立てる必要があります。これまでは、RSA鍵を使用して、これらのいずれかのソリューションと鍵を共有していましたが、セッションごとに固有の鍵を生成するPFSでは、これは不可能です。F5® SSL Orchestrator®は、クリアテキスト トラフィックを復号化して検査ソリューションに転送するか、RSAでTLS 1.2を使用して復号化して再暗号化することができます。2番目の方法では、復号化の負荷が検査デバイスに戻されますが、ソリューションをトラフィックに合わせる必要はないので、レイテンシは増加せず、データ センター内に転送中のクリアテキスト データが存在することもありません。

PFSの実装時に必須となる楕円曲線暗号の脆弱性はまだ見つかっていませんが、誰もがご存じのように、今安全なものが永遠に安全であるわけではありません。セキュリティ研究やハッキング ツールは、コンピューティング能力と同様に進歩し続けており、それは必然的に脆弱性の発見につながります。すべての復号化と暗号化を一元管理することで、古い暗号が非推奨になったら暗号を簡単に変更できます。

SSL/TLSの可視性は十分ではなく、オーケストレーションを介した制御が鍵

アプリケーションに入ってくるパケットやネットワークから出ていくパケットの内部を可視化できることは、大きな一歩ですが、それは最初の一歩にすぎません。セキュリティ スタック全体で復号化/暗号化を管理するために、手動のデイジーチェーンや設定に頼るのは面倒であり、特定の方法を強制するポリシーには常に例外が伴うことはご存じのとおりです。SSL Orchestratorは大規模な可視性をもたらしますが、実際に他社製品と一線を画す理由はオーケストレーションにあります。

オーケストレーションは、リスクと動的ネットワークの状況に基づいて、ポリシーベースのトラフィック ステアリングをサービス チェーンに提供します。SSL/TLSとHTTPの両方のフルプロキシであるSSL Orchestratorは、インテリジェントな決定を行ってインバウンドおよびアウトバウンド トラフィックをセキュリティ スタック内のサービス チェーンに誘導することができます。また、トラフィックのほとんどはHTTPSですが、SSL Orchestratorでは、FTP、IMAP、POP3、ICAP内のSTARTTLSなど、他のトラフィック タイプを使用して、復号化と再暗号化をインテリジェントに管理できます。これらすべてが可能な製品は他にありません。これが、他のSSL/TLSソリューションがアプリやネットワークを包括的に保護できない理由です。

F5のセキュリティ専門家にご相談ください

セキュリティに関するご質問や問題、他にも何かご相談がありましたら、お気軽にお問い合わせください。
ご連絡をお待ちしております。