SSL ソリューションを導入する際の重要な考慮事項
人間は社会的な動物なので、秘密を守るのに苦労します。 私たちは情報の共有を通じて生き残り、繁栄します。 しかし、一部の情報は秘密にしておく必要があり、そのため、スパルタ軍がギリシャとの戦争中に軍事情報を保護するために転置暗号を使用して以来、暗号化は何らかの形で存在してきました。
しかし、個人データを秘密に保つ科学はかつては政府の諜報機関の管轄だったが、インターネットの普及によりプライバシーはすべての人にとっての関心事となった。 データ侵害が相次いでいる中、個人データや企業データをオンラインでどのように保護するかという問題は、世界中の企業にとって最重要課題となっています。
わずか 10 年前、大規模金融機関と政府機関が、歴史的には Secure Sockets Layer (SSL) として知られ、現在は Transport Layer Security (TLS) と呼ばれる暗号化プロトコルを採用している主な組織でした。 今日、SSL はどこにでもあります。 アナリストは、暗号化されたトラフィックが、2015年のわずか29％から2016年には北米のオンライントラフィック全体の64％近くにまで増加すると予測している。1 組織は、電子メールやソーシャル メディアからストリーミング ビデオまで、あらゆるトラフィックの大部分を暗号化しようと躍起になっています。 この進化により、Web トラフィックのセキュリティは強化されますが、代償も伴います。 SSL トラフィックの増加により、強力なセキュリティによって要求されるワークロードの増加にネットワーク インフラストラクチャが対応できるようにする効率的な SSL ソリューションを実装するという負担が組織にかかっています。
組織は SSL が提供するセキュリティ レベルに魅力を感じますが、どこでも常時使用できるセキュリティ プロトコルとして SSL を導入するには課題があります。 同時に、攻撃者が暗号化されたトラフィックを見ることができないセキュリティ デバイスからマルウェアを隠す方法として SSL を使用し始めたため、SSL は脆弱性のベクトルになりました。 分散型サービス拒否 (DDoS) 攻撃は、SSL サーバー トラフィックのホスティングに関連する比較的大きな計算コストを利用するため、特に厄介です。 さらに、Heartbleed インシデントなどの実装の問題により、セキュリティ侵害が発生する可能性があります。
SSL を適切に導入することは、熟練した管理者にとっても困難です。 ただし、サイト全体で SSL を展開する際の最新のオプションと傾向を把握することで、事後対応型の戦術ではなく事前対応型の戦略を選択し、変化に先んじることが可能になります。
SSL の主な目的は、applications間で転送されるデータを保護することです。 SSL によって保護されると、Web ブラウザなどのクライアントとサーバー間の通信はプライベートになり、両者の ID を認証できます。 しかし、注目を集めた米国の調査で判明したように、秘密鍵で暗号化されたすべてのトラフィックは、将来的に解読される可能性があります。 国家安全保障局（NSA）のエドワード・スノーデンからの漏洩。 すべての Web 通信を保護するだけでは十分ではありません。
SSL には、Perfect Forward Secrecy (PFS) 保護と呼ばれる受動的な監視対策があり、SSL 接続の両側間のキー確立プロトコルに追加の交換を追加します。 PFS は、ユーザーが開始するセッションごとに一意のセッション キーを生成することで、攻撃者が 1 つのキーを復元して以前に記録された何百万もの会話を解読できないことを保証します。
PFS を導入するのは一見簡単そうに見えます。application配信コントローラ (ADC) などの SSL 終端デバイス内で PFS を有効にするだけです。 ただし、侵入検知システム(IPS) や侵入検知システム (IDS) などのパッシブ セキュリティ デバイスを使用している組織では、多くの場合、これらのデバイスを永続的な秘密キーで構成する必要があるため、問題が発生します。PFS では、永続的な秘密キーは使用されません。 したがって、組織は IPS/IDS をオフにするか、PFS をオフにするかの選択に直面します。 どちらを選択しても、全体的なセキュリティ体制が損なわれます。
別の方法があります。 すべての SSL トラフィックを Webapplicationファイアウォールや ADC などのリバース プロキシにオフロードすることで、IDS/IPS が本来の目的を果たすことができるようにします。リバース プロキシは暗号を処理してから、復号化されたトラフィックを IDS/IPS に渡して検査とサニタイズを行います。
できること: データの整合性を保護するために PFS を有効にします。 さらに、SSL トラフィックをオフロードし、ネットワーク セキュリティ デバイスの動作を最適化するために、リバース プロキシを導入することを検討してください。
HTTP Strict Transport Security (HSTS) を有効にすることは、applicationsのセキュリティ体制を改善するための最も簡単で強力な方法の 1 つです。 HSTS は、HTTPS トラフィックにヘッダーを挿入することで、Cookie ハイジャック、中間者攻撃、ダウングレード攻撃などのいくつかの一般的な攻撃ベクトルに対する保護レイヤーを提供します。 現在、すべての主要ブラウザは HSTS をサポートしており、HSTS を使用するとすべてのトラフィックが暗号化された状態を保つことができます。
できること: サブドメインに対して HSTS を有効にして、すべてのドメインのすべてのページに HSTS ヘッダーがあることを確認します。 これらのサブドメインが SSL の使用をサポートできることを確認してください。 SSL ソリューションによって、システム全体の HSTS パラメータをすばやく簡単に構成できることを再確認してください。 HSTS ヘッダーの有効期間が 6 か月以上であることを確認します。
applicationsを管理し、そのセキュリティを確保するには、トラフィックの可視性、または Webapplicationファイアウォール (WAF)、IPS/IDS、次世代ファイアウォール (NGFW) などのセキュリティ デバイスにその可視性を提供して、既知の脅威をスクリーニングする機能が必要です。 ただし、定義上、SSL は通信されるデータをセキュリティ ソリューションからさえも隠しますが、悪意のあるトラフィックを効果的に明らかにしながらセキュリティを維持するアプローチがいくつかあります。
SSL トラフィックの暗号化と復号化には追加の計算能力が消費されます。 SSL の普及に伴い、ネットワークとユーザー エクスペリエンスは遅延やパフォーマンスの低下の影響を受ける可能性があります。 さらに、計算負荷の高いプロトコルの中には、現在使用されている一部のセキュリティ デバイスではサポートされていないものもあります。 ADC は、TCP、HTTP、SSL の完全なプロキシとして機能することで計算負荷を軽減します。つまり、ADC はクライアント (ブラウザ) への 1 つの接続と、サーバーへの別の接続を作成します。 SSL プロキシの変換特性により、サイトはapplicationサーバーの機能から切り離された SSL 機能を提供できます。
できること: 拡張可能なソリューションを展開します。 SSL 終了作業を ADC にオフロードすると、パフォーマンス、キー保護、可視性を損なうことなく、一貫した SSL ポリシーを簡単に適用できます。 これにより、バックエンドのトランスポート オプションに関係なく、ADC が Web サーバーへのインターフェイスを ADC がサポートする任意のプロトコルに変換できるようになり、柔軟性が向上します。 これにより、バックエンドのビジネスクリティカルなレガシーデバイスとapplicationsは、堅牢な公開セキュリティ体制を維持しながら、変更なしで引き続き動作できるようになります。
さらに、中央制御ポイントを持つことで、新たな脆弱性から保護するためのサイトの更新プロセスが効率化されます。 最後に、ハイブリッド アーキテクチャでは、インフラストラクチャに対する計算負荷を軽減し、仮想展開を最大限に活用するために、SSL 処理を仮想マシン (VM) からハードウェア デバイスにオフロードできるソリューションを探します。
セキュリティアナリストは、2017 年までに、新しいマルウェアの 100% が、それを識別して無効化するように設計されたセキュリティ デバイスから痕跡を隠すために SSL を使用するようになると予測しています。 企業は、スピアフィッシングやマルウェア活動などの高度な持続的脅威 (APT) を軽減するために、送信 Web トラフィックを監視してサニタイズする必要があります。
管理者がこれらの脅威を検出できるように支援するために、新しいセキュリティ デバイスが絶えず開発されています。 多くの管理者は、多層防御戦略と呼ばれるものを実装し、セキュリティ デバイスをチェーン状に展開して、相互にサポートできるようにしています。 ただし、SSL 操作はこれらのデバイスの効率、セキュリティ、パフォーマンスを妨げます。 これらの新しいテクノロジーの多くは、暗号化されたトラフィックを認識できないか、暗号化されたトラフィックを検査するタスクを実行すると大幅なパフォーマンスの低下が発生します。 たとえば、次世代ファイアウォールでは、SSL を有効にするとパフォーマンスが最大 80% 低下する可能性があります。 マルウェアやスピアフィッシングの作成者はこれを認識しており、マルウェアと外部との間のすべての通信を暗号化する動きを急速に進めています。
できること: これらの暗号化された脅威に対抗する 1 つの方法は、可視性チェーンの両側に ADC を配置する SSL エアギャップ ソリューションを導入することです。 ユーザーに最も近い ADC は送信トラフィックを復号化し、復号化された通信をセキュリティ デバイス経由で送信します。 コンテンツを表示できるようになったこれらのデバイスは、ポリシーと制御を適用し、マルウェアを検出して無力化します。 チェーンのもう一方の端では、別の ADC がデータセンターから出るトラフィックを再暗号化します。 このソリューションを導入すると、セキュリティ デバイスを適切な状態に保つ柔軟性が得られ、デバイスが本来の目的どおりに機能することが保証されます。
もう一つ注意点: FireEye や Cisco Sourcefire などの可視性スキャナーを使用して、ゼロデイ攻撃やその他の悪意のある攻撃からネットワークを保護する場合は、SSL ソリューションがこれらのセキュリティ製品と緊密に連携して効率を最大化するようにしてください。
SSL の導入の複雑さと、多くのネットワーク デバイスが暗号化されたトラフィックを可視化する難しさにより、SSL は DDoS 攻撃の格好の標的になっています。これは攻撃者も十分に理解している事実です。 正当な SSL トラフィックの全体的な量が急増するにつれて、セキュリティ デバイスが悪意のある DDoS トラフィックを識別することがますます困難になります。
できること: 疑わしい DDoS トラフィックを効率的に識別し、Web サイトの可用性への影響を防ぐことができる包括的な SSL ソリューションを使用して、SSL 再ネゴシエーション攻撃や SSL フラッドなどの DDoS 攻撃を軽減します。 SSL ベースの DDoS 攻撃の影響を軽減するのに役立つクラウドベースの DDoS サービスの調査を検討してください。
では、SSL セキュリティ体制が適切かどうかをどのように確認すればよいのでしょうか? Qualys SSL Labs は、攻撃を受ける前にサイトの証明書と構成をテストできる貴重なツールを提供します。 また、ブラウザの SSL 実装を評価し、急速に進化する SSL の課題に対して他のサイトや競合他社がどのように対処しているかを確認することもできます。
1990 年代に SSL プロトコルが導入されて以来、鍵交換の主な選択肢として RSA 暗号システムが使用されてきました。 時間が経つにつれて、ブルートフォース攻撃がより実行可能になるにつれて、RSA キーの長さを長くする必要がありました。 現在、RSA キーは非常に大きいため、キー交換は非常に計算集約的な操作になります。
厳格なプライバシー管理を維持しながら計算負荷を軽減するために、新しい暗号化プロトコルが普及しつつあります。 たとえば、楕円曲線暗号 (ECC) は、以前のアルゴリズムと同じレベルのセキュリティを提供しながら、必要な処理が少なくなるため、モバイル デバイスのバッテリー寿命にもはるかに優しいということになります。 これらの暗号化オプションは有望ですが、組織は当然ながら、これらの新しいプロトコルを提供するために何百ものサーバーを再構成する必要があることを懸念しています。
できること: 時間の経過とともにアルゴリズムを切り替える必要があることは珍しくないので、SSL ソリューションに暗号の俊敏性、つまり、同じ Webapplication内であっても、ECC、RSA2048、DSA などの複数の暗号化プロトコルを同時に提供できる SSL デバイスの能力があることを確認してください。 さらに、暗号の多様性が増すにつれて、SSL ソリューションが最新の暗号サポートを維持していることの実績を示すことが不可欠になります。
SSL キーは組織にとって最も貴重な資産の 1 つです。 秘密 SSL キーを入手した攻撃者は、ターゲットのapplicationsを偽装し、究極のフィッシング ポータルを作成する可能性があります。 ただし、これらの非常に重要なキーを保護する方法はいくつかあります。
ハードウェア セキュリティ モジュール (HSM) は、暗号化キーを保護および管理するための厳格な FIPS 140-2 暗号化設計ガイドラインに準拠した、独立したソフトウェアおよびハードウェア セキュリティ デバイスです。 キーは HSM から転送されることがないため、Heartbleed バグのような SSL の脆弱性を心配する必要はありません。
できること: SSL キーを保護する最も安全な方法は、HSM を使用することです。 一部の ADC に含まれているような内部 HSM を購入するなど、いくつかの可能性があります。 一部の組織では、HSM デバイスを集中キー ストアとして使用してキー管理を統合しています (たとえば、データ センターごとに 1 ペア)。 これらのネットワーク HSM は、キーの復号化を必要とするサービスが内部ネットワーク経由でアクセスできるため、多くの SSL 終端ポイントで同じネットワーク HSM を使用できます。 注意点が1つあります: SSL ソリューションがネットワーク HSM にシームレスに接続できることを確認してください。
組織は、SSL キーのセキュリティを確保するために、エンタープライズ キーおよび証明書管理 (EKCM) のベスト プラクティスを実装します。 パスフレーズをネットワーク ファイル システムに暗号化された形式で保存できる、ハードウェアで保護された暗号化キー ストレージ システムの使用を検討してください。
効果的な EKCM ベスト プラクティスの基礎は、すべてのエンタープライズ証明書、その場所、およびそれらを管理する担当者の包括的なインベントリを作成することです。 SSL 対応の各 Web サイトには独自の証明書があり、各証明書には有効期限があります。 特定の週に、1 つ以上の証明書の有効期限が切れる場合があり、その場合、関連する Web サイトまたはapplicationが利用できなくなります。 これらすべての証明書を管理するのは大変な作業ですが、重要なサイトの高可用性を確保するには不可欠です。 さらに、SSL 証明書は、キーの長さ (2048 ビット以上)、デジタル署名 (SHA2 以上)、および内部 PKI 内またはパブリック ルート CA によって生成されていない不正な証明書についても監査する必要があります。 最後に、PCI DSS に準拠するには、文書化された証明書とキー管理プロセスが必要です。
できること: 中規模から大規模の組織の管理者の多くは、組織が多くの場所にキーと証明書を保有しているため、外部の証明書管理システムを好みます。 特に、次の 2 つの外部ソリューションで多くの人が成功を収めています。 Venafi と Symantec。 どのようなソリューションを選択する場合でも、管理を自動化し、運用負荷を軽減するためのオープン API が備わっていることが重要です。
コンプライアンスは、多くの場合、SSL 導入の原動力となります。 PCI DSS 仕様に準拠するapplicationsは、PCI 3.0 への準拠を維持するために、今後 2 年間で SSLv3 と TLSv1 の使用を中止する必要があります。 新しい PCI DSS 展開では、SSL 3.0 と TLS 1.0 がすでに無効になっている必要があります。
できること: まず、ネットワーク ファイアウォールが ICSA Labs 認定されていることを確認します。 さらに、SSL 変換サービスでは、個々のサーバーにポリシーを適用する必要なく、インターネット向けの SSL ポリシーへの準拠を維持する機能が提供されます。 SSL ソリューションが今後の TLS 1.3 に対応していることを確認します。 さらに、個々のapplicationごとにコンプライアンスを解決しようとするのではなく、ADC にオフロードされたネットワーク サービスを通じてコンプライアンスを一元化することで、実際の運用効率を向上させることができます。
好むと好まざるとにかかわらず、オンラインの世界は危険な場所であり、企業の機密情報を攻撃者から保護することは、あらゆる規模の企業にとって最優先事項となっています。 プライバシー侵害がますます一般的になるにつれ、多くの組織はオンライン データの整合性を保護する方法として SSL に注目しています。 ただし、包括的な SSL 戦略の実装には、可視性、パフォーマンス、規模に関する独自の課題が伴います。
適切な計画と導入により、強力な SSL 戦略により侵害のリスクが軽減されます。 戦略が定まると、サイトは将来のセキュリティ、拡張性、信頼性を考慮して位置付けられ、本当に重要なこと、つまりビジネスの前進に重点が置かれるようになります。
F5とつながる
