クラウド内の仮想マシンを保護するための 4 つのステップ

セキュリティは人間にとっての問題ですが、サイバーセキュリティはリスクの複雑な要因と、障害が発生した場合に発生する可能性のある深刻な悪影響のために、より深刻な問題です。

仮想ネットワーク セキュリティは、従来のホスティングおよびアプリケーション セキュリティから生じる問題とネットワーク セキュリティの懸念が組み合わされ、さらに仮想リソースとサービスの課題が加わるため、さらに深刻な問題となります。クラウド仮想ネットワークの問題がようやく認識され始めたばかりであり、これらの問題を解決するにはまだ長い道のりがあることは間違いありません。

セキュリティは常に漸進的な問題として捉えるべきです。現在の状況と、これまで経験、許容、解決されてきた状況との違いは何でしょうか?ネットワーク内のクラウド仮想セキュリティの場合、最大の違いは仮想からリソースへのマッピング、つまり管理対象コンポーネントを接続するために必要なフレームワークです。つまり、クラウド コンピューティングの仮想サービスのセキュリティ問題は、ホストされたソフトウェア機能を保護するために設計されたセキュリティ ツールが、物理デバイスを保護するために設計されたセキュリティ ツールと異なるために発生します。

[[261691]]

管理対象要素を分離して保護する

クラウド内の仮想マシンを保護するための最初のステップは、新しくホストされる要素を分離することです。たとえば、エッジ デバイスでホストされている 3 つの機能が、サービス データ プラットフォームの一部として、ネットワーク ユーザーに表示されるアドレスとして、または非表示のプライベート サブネットの一部としてクラウドに展開できるとします。ビジネスがクラウドに展開されている場合、あらゆる機能が攻撃される可能性があり、ホスティングおよび管理プロセスも可視化され、脆弱になる可能性があります。企業がホストと機能の接続をプライベート サブネットワーク内で分離すると、外部からのアクセスから保護されません。

今日のコンテナ ホスティングでは、データ センターでもクラウドでも、アプリケーション コンポーネントはプライベート サブネット内に展開されます。したがって、ユーザーがアクセスする必要がある API を表すアドレスのみが表示されます。同じ原則を仮想関数に適用する必要があります。ユーザーが実際に接続するインターフェースを公開し、残りを保護されたアドレスで隠します。

すべてのコンポーネントがテストされ、監査されていることを確認する

クラウド仮想セキュリティの 2 番目のステップは、展開を許可する前に、仮想機能のセキュリティ コンプライアンスを認定することです。仮想ネットワークでは外部からの攻撃は現実的なリスクですが、内部からの攻撃は大惨事となります。バックドアの脆弱性を防ぐ機能がサービスに導入されると、その機能はサービス インフラストラクチャの一部となり、他のインフラストラクチャ要素への攻撃ベクトルが公開される可能性が高くなります。

強力なライフサイクル管理を遵守して、コンポーネントが同じサービス インスタンス内の他のコンポーネントにのみアクセスできるようにし、新しいソフトウェア ホスト機能にマルウェアが侵入するリスクを軽減することが重要です。バックドア攻撃はサービス自体を危険にさらす可能性がありますが、マルウェアが他のサービスや顧客に拡散する可能性は低いでしょう。

ただし、このアプローチでは、オペレーターの安全性テストの負担が軽減されるわけではありません。管理対象のすべての機能については、オペレーターが監査および検証できる強力なライフサイクル管理コンプライアンス プロセスを遵守することが重要です。ホスティング機能を提供する会社が新しいコードを適切にテストすれば、偶発的な脆弱性や意図的に導入されたバックドアの脆弱性が含まれる可能性は低くなります。

ネットワークを保護するための個別の管理API

3 番目のステップは、インフラストラクチャ管理をビジネス プロセスおよびサービスから分離することです。管理 API は、機能、機能性、およびサービスの動作を制御するように設計されているため、常に大きなリスクを伴います。このようなすべての API を保護することは重要ですが、サービス ユーザーがアクセスすべきではないインフラストラクチャ要素を監視する API を保護することは非常に重要です。

クラウド内の仮想マシンのセキュリティを確保するための最も重要な領域は、ETSI ネットワーク機能仮想化 (NFV) 業界仕様グループによって義務付けられた仮想ネットワーク機能マネージャー (VNFM) アーキテクチャの仮想機能固有の部分です。このコードは、ネットワーク機能仮想化 (NFV) のプロバイダーによって提供され、インフラストラクチャ要素やオーケストレーション ツールまたはデプロイメント ツールを表す API へのアクセスが必要になる場合があります。これらの要素により、インフラストラクチャ管理 API へのゲートウェイが開かれ、仮想クラウド サービスで使用される機能のセキュリティと安定性に影響を及ぼす可能性があります。

VNFM を保護するということは、NFV プロバイダーに、インフラストラクチャまたはデプロイメント/管理 API への VNFM 接続を管理するためのアーキテクチャをレビューおよびセキュリティ強化のために利用できるように要求することを意味します。他の NFV またはサービスに関連付けられたサービス ユーザー、NFV、または VNFM がインフラストラクチャ管理 API にアクセスできないようにすることが重要です。

アクセス権限を制限することで、企業はセキュリティリスクを制限できます。さらに、オペレーターは、あらゆるソースからのインフラストラクチャ管理およびオーケストレーション API へのアクセスのログ記録を要求し、管理アクセスの漏洩を防ぐために、あらゆるアクセスまたは変更を確認する必要があります。

接続を安全かつ分離したままにする

クラウド仮想ネットワーク セキュリティの 4 番目で最後のポイントは、仮想ネットワーク接続がテナント間またはサービス間で交差しないようにすることです。仮想ネットワークは、再デプロイまたはスケーリングされた機能に対して柔軟な接続を作成するための優れた方法ですが、仮想ネットワークを変更するたびに、2 つの異なるサービス、テナント、または機能/機能のデプロイ間に意図しない接続が作成されるリスクがあります。これにより、データ プラットフォームの漏洩、実際のユーザー ネットワーク間の接続、および管理または制御の漏洩が発生し、あるユーザーが他のユーザーのサービスに影響を与える可能性があります。

仮想接続を管理するためのプラクティスとポリシーにより、このようなエラーのリスクを軽減できますが、完全に回避することは非常に困難です。これは、仮想ネットワーク接続機能と実際のネットワーク接続ユーザーの間に間接的な関係があるためです。考えられる解決策の 1 つは、ネットワーク スキャナーまたはインベントリ ツールを使用して仮想ネットワーク上のデバイスと仮想アプライアンスを検索し、その結果を予想されるサービス トポロジと比較することです。これは、仮想ネットワークに変更を加える最後の手順として実行できます。

クラウド仮想ネットワークはネットワークにクラウド コンピューティングをもたらしますが、サーバー、ホスティング、仮想ネットワークのセキュリティの問題ももたらします。企業がデバイスのみでネットワークを構築していた時代のツールや手法を使用し、これらのリスクは従来の方法で対処できると考えている人は、すぐに厳しい現実に直面することになります。