ネットワークセキュリティはワークロードセキュリティではない

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

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

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

どのクラウドアーキテクチャでもネットワークインフラストラクチャは重要な性質を持っているため、すべてのアーキテクチャのネットワーク層にのみ特有の課題と優先事項があります。ネットワークには、ネットワークに依存するワークロードやアプリケーションにはまったく依存しない懸念事項があります。このようなネットワーク問題の例としては、次のようなものがあります。

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

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

では、これはネットワークの保護とワークロードの保護にとってどのような意味があるのでしょうか。ここでは明確な検討事項があります。具体的には両者の対比です。 ネットワークセキュリティ ネットワークベースのソリューション、ワークロードセキュリティ、マイクロセグメンテーションなどのソリューションもあります。

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

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

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

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

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

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

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

ファイアウォールが転送できるパケットと転送できないパケットを決定するのと並行して、ルーターとスイッチには独自のセキュリティ上の懸念があります。それは、ネットワークプロトコルが最初に設計されたとき、セキュリティは主要な関心事ではなかったという同じ基本的な問題によるものです。

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

念のために言っておきますが、これらはあらゆるクラウドアーキテクチャのネットワーク層に存在するセキュリティ課題のほんの一例にすぎません。

• トラフィックエンジニアリング
• サービス拒否 (DoS)
• ARP スプーフィング
• BGP 認証
• トラフィックリダイレクト
• マン・イン・ザ・ミドル攻撃
• 偽ルート伝搬
• ファーストホップルーターハイジャック
• セッションクッキーハイジャック

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

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

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

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

多くの場合、ワークロードはレイヤー3の境界を越えて、またはクラウド間でライブマイグレーションされます。ワークロードは、これらの移行を強制するために何らかの方法でこれらの移行を追跡するネットワークレイヤーツールに依存するべきではありません。 ワークロードセキュリティ とマイクロセグメンテーション。アプリケーションはワークロード間の依存関係に依存しており、これらの依存関係はネットワークレイヤーのツールでは見えないことが多いため、ネットワークがアプリケーションの依存関係全体を可視化できないという理由で、アプリケーションに関する境界線を定義する制限があってはなりません。

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

また、ワークロードとアプリケーションのセキュリティ要件に対するソリューションとして、ファイアウォール (ハードウェアまたはハイパーバイザー内の仮想インスタンス) を提案することもあり、次世代ファイアウォールはネットワークトラフィックをレイヤ7で完全に可視化できると主張しています。ただし、どのファイアウォールもパケットが到達して初めて役に立ちます。ファイアウォールには、送信元のアプリケーションやワークロードの動作に影響を与えることはできず、パケットがファイアウォールのポートに到着するのを待つだけです。 ファイアウォールはネットワークセキュリティを強化します そして、トラフィックが移動中であるときのマイクロセグメンテーション（南北交通）。ソースである東西トラフィックでは、アプリケーションやワークロードのセキュリティは適用されません。どちらのソリューションも真価を発揮するために必要です。 ゼロトラスト アーキテクチャは実現される予定だが、アーキテクチャの一方の層では、もう一方の層に完全なセキュリティとマイクロセグメンテーションを提供することはできない。

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

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

つまり、ワークロードのセキュリティおよびマイクロセグメンテーションソリューションを設計する場合、それらのソリューションをワークロードに導入する必要があるということです。ネットワークツールには、ワークロードやアプリケーションの問題とは異なる優先順位があります。ネットワーク・ファブリック全体に出入りする南北方向のトラフィックを強制することに重点を置いたネットワーク・セキュリティ・ツールは常に存在します。これらのネットワーク・ツールはネットワーク・デバイスに導入される予定です。ワークロードセキュリティはワークロード自体に導入する必要があり、ワークロード間およびアプリケーション間の東西トラフィックの強制に重点が置かれます。

アーキテクチャ全体の各レイヤーを独自のレイヤー固有の優先順位に集中させることで、どちらのレイヤーも他のレイヤーに依存せず、どちらのレイヤーも他のレイヤーの動作やスケーリングに制限を課すことはありません。その結果、ゼロトラストアーキテクチャが完全に実現しました。

多くのクラウドネイティブアーキテクチャは、セキュリティのベストプラクティスに従い、ワークロード自体にワークロードセキュリティソリューションを導入します。しかし、古い習慣はなかなか消え去り、多くの場合、既存の IT 環境をデータセンターからデータセンタに移行すると消滅します。 クラウドサービス、ネットワークソリューションを使用してワークロードのセキュリティを強化しようとする従来のアプローチも移行され、その結果、ワークロードとアプリケーションの間の東西のセキュリティ要件に気づかないことが多いネットワーク層が生まれます。その結果、ゼロトラストは実現しません。

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

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

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

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