ネットワークセキュリティはワークロードセキュリティではありません

侵害、ハッキング、ハイジャック、データ損失、流出はすべて、ほとんどのクラウドアーキテクチャに存在する問題であり、 その理由は非常に単純です。アプリケーション開発、ワークロードオペレーティングシステム、ネットワークプロトコル、および全体的なプロセス管理に関する複雑さはすべて、機能性と回復力というさまざまな優先順位を念頭に置いて設計されました。これらのタスクはすべて機能する必要があり、アーキテクチャ全体の要素の障害に耐える必要がありますが、これらの要素 のセキュリティ保護は 一般的に後回しにされてきました。

ネットワークはアーキテクチャ全体の重要なインフラストラクチャであるため、そこにセキュリティおよびマイクロセグメンテーションソリューションを適用することは理にかなっているように思われます。

アプリケーションの開発方法、さまざまなOSの構築方法、展開方法、これらすべてがどのように仮想化、抽象化、管理されるかに関係なく、これらの要素のほとんどは相互に通信する必要があります。ネットワークがない場合、各アプリケーションは孤島です。また、今日のほとんどのアプリケーションは、プライベート ネットワークまたはインターネットを介して、リモート クライアントがアクセスできるように設計されています。これはあらゆる種類のクラウドアーキテクチャで必要であり、クラウドネイティブアーキテクチャは、そのアーキテクチャを介して通信するためのネットワークがすでに存在しなければ機能しません。したがって、 クラウドアーキテクチャ全体の最も重要な要素は、実際にはネットワーク自体であると主張できます。

クラウドアーキテクチャにおけるネットワークインフラストラクチャの重要な性質により、すべてのアーキテクチャのネットワーク層のみに固有の課題と優先順位があります。ネットワークには、ネットワークに依存するワークロードやアプリケーションにまったく関係のない懸念があります。これらのネットワーク上の懸念の例としては、次のようなものがあります。

• 信頼性(ネットワークが機能する必要がある)
• 回復性 (1 つ以上のネットワーク デバイスの障害がシステム全体の障害を引き起こさないようにする)
• トラフィックエンジニアリングとサービス品質(IPネットワークは設計上「コネクションレス」ですが、さまざまな種類のトラフィックを設計して優先順位を付ける方法が必要です)
• スケーリング (ネットワークはリソースの上限に達することなく進化できる必要があります)

アプリケーションとワークロードは、ネットワークを使用するためにこれらの詳細を認識する必要はありません。

では、これはネットワークのセキュリティとワークロードのセキュリティ保護にとって何を意味するのでしょうか?特に、 ネットワークセキュリティ とネットワークベースのソリューション、およびワークロードセキュリティとマイクロセグメンテーションなどのソリューションとの対比について、明確な考慮事項を検討します。

ネットワークセキュリティの簡単な歴史

セキュリティは常にほとんどのクラウドアーキテクチャの後発であるため、セキュリティと ネットワークセグメンテーション は従来、ネットワーク層で実装されてきました。ネットワークはアーキテクチャ全体の重要なインフラストラクチャであるため、そこにセキュリティおよびマイクロセグメンテーションソリューションを適用することは理にかなっているように思われます。

時計を数十年前にさかのぼると、IP ネットワークのセキュリティはもともと、ルータとスイッチのアクセス コントロール リスト(「ACL」)の形式をとっていました。ネットワーク デバイスは通常、パケットごとにトラフィックを処理するため、パケットがルーターまたはスイッチに到着すると、これらの ACL がチェックされ、パケットの転送を許可するかブロックするかが決定されます。

このアプローチは、元々同じ基本的なアプローチを使用していた専用ネットワークデバイス(ファイアウォール)にアウトソーシングされました。すべての IP パケットのヘッダーには、パケットのデータ ペイロードに存在するデータの種類を示す TCP または UDP 番号に加えて、送信元と宛先を示す情報が含まれているため、ファイアウォールはこの情報を使用して、独自のアクセス制御リストに基づいて転送の決定を行います。ネットワークがパケットを処理するため、ネットワークにセキュリティとマイクロセグメンテーションも処理させることは理にかなっています。

ただし、パケットベースのファイアウォールをだますのは一般に簡単です。IP パケット内のアドレスと TCP/UDP ポート番号を「スプーフィング」することはそれほど難しくなく、その結果、データ ペイロードに含まれるものを簡単にマスクできるパケットになります。そのため、セッションベースのファイアウォールは、特定のフロー内のすべてのパケットを一意のセッションにマッピングし、そのセッションが関連付けられていると「考える」アプリケーションに基づいてそのセッションの動作を監視することに重点を置くように進化しました。これらのファイアウォールは、各パケットを完全に可視化することはできませんでしたが、それらのパケットとセッションの動作をアプリケーションのベースライン動作と比較し、異常を探します。

その後、いわゆる「次世代」ファイアウォールが登場し、パケットに含まれるもの、パケットが関連付けられているアプリケーション、関連付けられているユーザー、およびセキュリティ侵害を示すその他の詳細を識別するために、はるかに多くのインテリジェンスを適用しました。ただし、これらの詳細はすべて、送信元または宛先のワークロード自体ではなく、ネットワーク内でインラインで発生します。ファイアウォールは、ワークロードやアプリケーションを監視し、選択したトラフィックをファイアウォールに誘導する中央ツールと何らかの方法で通信しない限り、これらのパケットを送受信しているワークロードで何が起こっているのかわかりません。しかし、これは導入が複雑になる可能性があるため、ファイアウォールは多くの場合、ネットワーク内に座ってパケットの到着を待っています。

ネットワークセキュリティはワークロードセキュリティとは異なります

ファイアウォールが転送できるパケットと転送できないパケットを決定するのと並行して、ルーターとスイッチには独自のセキュリティ上の懸念があり、これは同じ基本的な問題の結果です。

BGP や OSPF などのパケットの転送に使用される TCP/IP および動的ルーティング プロトコルは、アプリケーションやワークロードと同じ基本的な目標である機能性と回復性に基づいて設計されました。ネットワークが始まった当初は、セキュリティは優先事項ではありませんでした。セキュリティとマイクロセグメンテーションは、ネットワーク進化の後期段階で優先事項となり、ネットワークに特有のセキュリティ上の懸念に対処するためにネットワークセキュリティソリューションが使用されてきました。セキュリティは、ワークロードやアプリケーションだけの問題ではありません。ネットワークには、ワークロードやアプリケーションが可視化できないセキュリティ上の懸念があります。

これらは、クラウドアーキテクチャのネットワーク層に存在するセキュリティ上の課題のほんの一例にすぎません。

• トラフィックエンジニアリング
• サービス拒否(DoS)
• ARPスプーフィング
• BGP認証
• トラフィックのリダイレクト
• 中間者攻撃
• 偽のルート伝播
• ファーストホップ ルーター ハイジャック
• セッション Cookie ハイジャック

この短いリストの項目はすべて、ワークロードやアプリケーションではなく、ネットワークに固有のセキュリティ上の懸念事項です。たとえば、トラフィック エンジニアリングの課題は、MPLS などのテクノロジーやラベル配布プロトコルの信頼性によって解決されます。サービス拒否は重大な問題であり、多くの場合、ISP ルーティング ピアと交換される BGP コミュニティの使用によって対処されます。ARP スプーフィングは、ルーターがレイヤー 3 アドレスとレイヤー 2 アドレス間のマッピングを変更し、トラフィックの宛先がハイジャックされる問題です。BGP認証では、インターネットを介したルーティングの問題を回避するために、BGPピア間で交換される情報を暗号化するためにRPKIなどが必要です。などなど。ネットワーキングには、クラウドアーキテクチャのネットワーク層に固有のセキュリティ問題に対処するための独自の専門用語があります。

これらの例は、ネットワークアーキテクチャの主なセキュリティ上の懸念事項のほんの一部であり、ワークロードやアプリケーションアーキテクチャではありません。アプリケーション開発チームとシステムチームは、通常、これらのネットワークセキュリティ上の懸念を可視化する必要はないため、可視化できません。ワークロードのOSがiptablesを使用してパケットを送受信する場合、BGPがネットワーク内のどこかのISP間で何らかの形でハイジャックされているかどうかを知る必要はありません。ワークロードとアプリケーションは、ネットワークセキュリティではなく、ワークロードとアプリケーションのセキュリティに関係しています。

ネットワークセキュリティソリューションはワークロードセキュリティソリューションではありません

つまり、 ネットワークのセキュリティの課題に対処するために設計されたツールは、通常、ワークロードやアプリケーションのセキュリティやマイクロセグメンテーションの課題に対処するための適切なツールではないということです。ワークロードのセキュリティは、多くの場合、規模に制限されない必要があり、複数のクラウドに何千ものワークロードをデプロイすることは、それらのワークロードにアプリケーションレベルのセキュリティを提供するために、1つのネットワーク層ツールに依存するべきではありません。

ワークロードはレイヤー 3 の境界を越えて、またはクラウド間でライブ移行されることが多く、 ワークロードのセキュリティ とマイクロセグメンテーションを強制するために、ワークロードはこれらの移行を何らかの形で追跡するネットワーク層ツールに依存しるべきではありません。アプリケーションはワークロード間の依存関係に依存しており、これらの依存関係はネットワーク層ツールには見えないことが多いため、アプリケーションの完全な依存関係に対するネットワークの可視性の欠如によって、アプリケーションの周囲のリングフェンスの定義に制限されるべきではありません。

一部のネットワーキングベンダーは、ワークロードとアプリケーションのセキュリティ、およびマイクロセグメンテーションの要件に対するソリューションとしてSDNソリューションを提案します。しかし、これらのツールはネットワークまたはハイパーバイザー層に存在し、これらのツールは、自動化、仮想化、ネットワーク分析、ネットワークオーバーレイとトンネリング、動的ルーティングプロトコル間の認証など、これらの層の優先順位に対処するように設計されています。SDNツールは、ワークロードやアプリケーションにセキュリティとマイクロセグメンテーションを大規模に提供するようには設計されていませんでした。

また、次世代ファイアウォールはネットワークトラフィックに対するレイヤー7の完全な可視性を提供すると主張して、ワークロードとアプリケーションのセキュリティ要件に対するソリューションとして、ハードウェアまたはハイパーバイザー内の仮想化インスタンスのいずれかのファイアウォールを提案する可能性もあります。ただし、ファイアウォールはパケットが到達した場合にのみ役立ちます。ファイアウォールには、ソースでアプリケーションやワークロードの動作に影響を与える機能はなく、パケットがファイアウォールのポートに到着するのを待つだけです。ファイアウォールは、トラフィックが転送中(南北トラフィック)の際に、ネットワークセキュリティとマイクロセグメンテーションを強制します。アプリケーションやワークロードのセキュリティをソース (East-West トラフィック) で適用しません。どちらのソリューションも真の ゼロトラスト アーキテクチャを実現するために必要ですが、アーキテクチャの一方の層が他方の層に完全なセキュリティとマイクロセグメンテーションを提供することはできません。

ネットワークチームは、ワークロードやアプリケーションのセキュリティを任されるべきではありません

ネットワークチームは、ワークロードやアプリケーションタスクとは異なるネットワークタスクに重点を置きます。これらのタスクには、レイヤー 2 およびレイヤー 3 の変換と転送メカニズム、BGP や OSPF などのルーティング プロトコルと相互のピアリング方法、独自の認証メカニズムなど、これらのチームに関連する用語が含まれます。スパニングツリーやECMPなどのレイヤ2ネットワークの問題に対するソリューションにも、独自のセキュリティ優先順位があります。ハイパーバイザーに導入されたSDNや仮想化ネットワークアプライアンスなどのネットワークツールは、ネットワークの優先順位に固有の問題に焦点を当てています。これらのソリューションはどれも、ワークロード自体のセキュリティリスクを優先事項にしません。

これが意味するのは、ワークロード用のセキュリティおよびマイクロセグメンテーションソリューションを設計する際には、それらのソリューションをワークロードにデプロイする必要があるということです。ネットワークツールには、ワークロードやアプリケーションの懸念事項とは異なる優先順位があります。ネットワーク セキュリティ ツールは常に存在し、ネットワーク ファブリック全体に出入りする南北トラフィックの強制に重点を置いています。これらのネットワークツールは、ネットワークデバイスに展開されます。ワークロード セキュリティはワークロード自体にデプロイする必要があり、ワークロード間およびアプリケーション間で East-West トラフィックを適用することに重点を置きます。

アーキテクチャ全体の各レイヤーを、それぞれのレイヤーに固有の優先順位に焦点を合わせておくことで、それぞれが他方に不可知論的であり、どちらのレイヤーも他方の運用方法やスケーリング方法に制限を課すことがなくなります。その結果、ゼロトラストアーキテクチャが完全に実現されました。

多くのクラウドネイティブアーキテクチャはセキュリティのベストプラクティスに従っており、ワークロード自体にワークロードセキュリティソリューションをデプロイします。しかし、古い習慣はなかなか消えず、既存のIT環境がデータセンターから クラウドサービスに移行されるとき、多くの場合、ネットワークソリューションを使用してワークロードセキュリティを適用しようとする従来のアプローチも移行され、その結果、ワークロードとアプリケーション間の東西のセキュリティ要件を無視することが多いネットワークレイヤーになります。その結果、ゼロトラストではありません。

これが、イルミオが全体的なセキュリティアーキテクチャに適合する場所です。ネットワークセグメンテーションに対する従来のアプローチとは異なり、Illumioを使用すると、セキュリティとマイクロセグメンテーションを、保護およびセグメント化しようとしているエンティティ、つまりワークロード自体に直接適用できます。そうすることで、ワークロードとアプリケーションのセキュリティとマイクロセグメンテーションを、これらがネットワーク上のどこにあるかに依存することなく拡張および進化させることができます。これにより、ワークロードはオンプレミスのデータセンターやクラウドプロバイダーのどこにでも常駐または移行できます。

マルチクラウドアーキテクチャは、基盤となるすべてのネットワークトポロジーにわたって到達可能な1つの広範なネットワークファブリックを作成します。セキュリティとマイクロセグメンテーションは同じガイドラインに従い、同じネットワークファブリック全体で一貫性のあるスケーラブルなソリューションをエンドツーエンドで提供する必要があります。ゼロトラストとは、セキュリティの信頼境界が保護する必要があるすべてのワークロードとアプリケーションにプッシュされることを意味し、クラウドアーキテクチャの異なるレイヤーでこの目標を有効にしようとしても、その目標を制限すべきではありません。

これらのトピックの詳細と、イルミオがワークロードとアプリケーションのセキュリティをどのように解決するかについては、以下をご覧ください。

• セグメンテーションの進化に関するこの簡単な概要ビデオをご覧ください
• このオンデマンドウェビナーをご覧ください: ネットワークからセキュリティを解放する:セグメンテーションをシンプルに