HTTP/2.0 時代の SSL トラフィックの可視性と制御
F5 の「SSL Everywhere」アーキテクチャは、すべての F5 BIG-IP 導入に含まれるカスタム作成された SSL/TLS スタックを中心に構築されています。 これにより、F5 は HTTP/2.0 時代の SSL/TLS トラフィックを可視化し、制御できるようになります。
SSL/TLS トラフィックの可視性と制御がなぜそれほど重要なのか? わずか 10 年前、SSL は、セキュリティを重視する Web サイトやサービスのログイン ページ用に、金融機関や公共機関などの特定の組織に限定されていました。 現在、これはほとんどの Web ベースのサービスに拡張されており、急速に通信の事実上のプロトコルになりつつあります。 ガートナーの業界調査によると、2015 年末までに世界のインターネット トラフィックの 50% 以上が暗号化される予定です。
TLS は現在、ネットワーク サーバー上で通信セキュリティを提供するため、企業の IT ネットワークへのアプローチにパラダイム シフトをもたらします。 送信されるデータの暗号化には対称暗号化が使用されるため、クライアントとサーバー間の接続はプライベートです。
HTTP/2.0 での SSL/TLS トラフィックの可視性と制御
暗号化されたトラフィックの使用が増えるにつれて、ファイアウォール、侵入防止システム、侵入検知システムに依存する従来のアプローチは時代遅れになりました。これらのデバイスは、通過するデータ ストリームを認識できず、不意を突かれることになるからです。
この問題の解決策は、初期の SSL 復号化をセキュリティ境界で実行することです。 しかし、セキュリティ境界で機能する業界内で利用可能なソリューションのほとんどは、「SSL 復号化」という特定の目的のために設計または開発されていません。 暗号を解読する能力を持っている人もいるかもしれませんが、適切に解読することはできません。 多くの企業では、SSL 復号化を有効にするとパフォーマンスが大幅に低下する現象も発生しています。 これにより、SSL トラフィックの最適化された処理を組み込んだ境界を「どのように」設計すべきかを探求する探求が始まりました。 当然のことながら、レイヤー 7 セキュリティ デバイスの有効性を最大限に高めるには、SSL 復号化をセキュリティ境界の近くで実行する必要があります。 受信 SSL が復号化されると、結果のリクエストを分析、変更、および制御できるようになります。
SSL暗号
サイバー犯罪者は、セキュリティデバイスがセキュリティの抜け穴であることを知りながら、SSL を使用してセキュリティデバイスを回避して攻撃することがよくあります。 SSL トラフィック内に隠されたマルウェアも、セキュリティ プラットフォームを簡単に回避する可能性があります。 ガートナー社はまた、2017 年までに企業のネットワークに対する攻撃の 50% 以上が SSL を使用してセキュリティを回避するようになると予測しています。
Heartbleed、BEAST、POODLE などの攻撃を引き起こす、より脆弱な暗号スイートが発見されたため、セキュリティ管理者が脆弱性を修正できる時間は限られています。 数百または数千の SSL フロント サーバーを管理する必要がある場合、悪意のあるソースからの攻撃に対して脆弱なまま、修正に数週間かかります。
どのトラフィックを復号化するかを知ることが問題になります。 企業が外部のユーザーにコンテンツを提供する場合、デバイスを使用してサーバーから SSL トラフィックをオフロードし、トラフィック フローに保護を挿入する必要があります。 これにより SSL が破壊されますが、賢明な方法で破壊されます。銀行セッションの暗号化は不要ですが、Facebook セッションの暗号化は必要です。 セキュリティには、トラフィックがどこに向かっているかを理解し、それを復号化するか、そのままにしておくかを決定するインテリジェンスが必要です。
SSL は技術的にはユーザーがポイントツーポイントでセキュリティを実現できるようにサポートしますが、必ずしもトラフィック全体を保護できるわけではありません。 SSL 証明書を偽造せずに、暗号化されたトラフィックにマルウェアを隠すことで SSL を傍受される可能性があります。 したがって、IT 部門の主な焦点は、詐欺をリアルタイムで検査し、すぐに軽減することです。
F5 の完全なプロキシ アーキテクチャにより、内部通信と外部通信の両方に分離された接続を実装しながら、変換と復号化をシームレスに実行できます。 SSL セッションを終了する機能により、IT 部門は外部のトラフィックに暗号化を使用し、必要に応じて古い HTTP を利用することも容易になります。 すべての接続が可能になり、IT 部門は HTTP/2.0 の利点を享受するために Web アプリケーション インフラストラクチャ全体を破壊して置き換える必要がなくなります。
TLS構成を管理しながらパフォーマンスを維持する
1024 ビットから 2048 ビットへのより強力なキー長の採用により、計算要件は以前の 4 倍から 8 倍に指数関数的に増加しました。 これにより、同様のトラフィック サイズを処理する必要がある既存のインフラストラクチャのパフォーマンスが低下します。 専用のハードウェアとハードウェア アクセラレータを組み合わせることで、サーバー ファーム全体の CPU リソースをアップグレードする必要性が軽減されます。
PCI DSS 3.1 では、2016 年 6 月 30 日までに SSL と TLS 1.0 の使用を中止し、より新しい TLS 実装を採用することが企業に義務付けられているため、企業はすべてのデバイスに SSL 集中管理ポイントを設け、環境全体で問題を数分以内に修正できるようにする必要があります。
ドキュメント参照: