編集

次の方法で共有


ネットワーク レベルのセグメント化を使用してワークロードをセキュリティで保護および管理する

Azure Firewall
Azure Monitor
Azure SQL データベース
Azure Virtual Network

セグメント化は、Microsoft Azure で利用可能なツールを使用して、ネットワーク フットプリントを取得し、ソフトウェア定義境界を作成するモデルです。 その後、これらの境界とのトラフィックを管理するルールを設定し、ネットワークのさまざまな部分に異なるセキュリティ体制を適用できるようにします。 異なるアプリケーション (または特定のアプリケーションの一部) をこれらの境界に配置するときに、これらのセグメント化されたエンティティ間の通信を管理できます。 アプリケーション スタックの一部が侵害された場合に、このセキュリティ違反の影響をより適切に抑えられ、ネットワークの残りの部分を通じて横方向に拡散されることを防げるようになります。 この能力は、組織に世界クラスのセキュリティの考え方をもたらすことを目的とする、Microsoft によって公開されたゼロ トラスト モデルに関連付けられている重要な原則です

セグメント化のパターン

Azure で操作する場合、保護に役立つ幅広いさまざまなセグメント化オプションを利用できます。

リソース フローチャート

  1. サブスクリプション: サブスクリプションは高レベルのコンストラクトであり、プラットフォームを利用するエンティティ間の分離が提供されます。 これは、社内の大規模な組織間の境界を分割することを目的としています。 異なるサブスクリプション内のリソース間の通信は、明示的にプロビジョニングする必要があります。

  2. Microsoft Azure Virtual Network: 仮想ネットワークは、プライベート アドレス空間内のサブスクリプション内に作成されます。 このネットワークは、既定で 2 つの仮想ネットワーク間でトラフィックが許可されないため、リソースのネットワーク レベルの封じ込めを実現できます。 サブスクリプションと同様に、仮想ネットワーク間の通信は明示的にプロビジョニングする必要があります。

  3. ネットワーク セキュリティ グループ (NSG): NSG は、レイヤー 4 ファイアウォールとして仮想ネットワーク内のリソース間のトラフィックを制御するためのアクセス制御メカニズムです。 NSG では、インターネットや他の仮想ネットワークなどの外部ネットワークを使用したトラフィックも制御されます。 NSG では、サブネット、VM のグループ、さらに単一の仮想マシンに対して境界を作成することにより、セグメント化戦略を細かいレベルにすることができます。

  4. Azure Virtual Network Manager (AVNM): Azure Virtual Network Manager (AVNM) は、中央の IT 管理チームが大規模なサブスクリプション間で仮想ネットワークをグローバルに管理できるようにするネットワーク管理サービスです。 AVNM を使用すると、複数の仮想ネットワークをグループ化し、定義済みのセキュリティ管理規則を適用できます。これは、選択した仮想ネットワークに一度に適用する必要があります。 NSG と同様に、AVNM を介して作成されたセキュリティ管理規則もレイヤー 4 ファイアウォールとして機能しますが、セキュリティ管理規則は NSG よりも先に評価されます。

  5. アプリケーション セキュリティ グループ (ASG):ASG では、NSG に似た制御メカニズムが提供されますが、アプリケーション コンテキストで参照されます。 ASG を使用すると、アプリケーション タグの下に VM のセットをグループ化できます。 基になる各 VM に適用されるトラフィック ルールを定義できます。

  6. Azure Firewall: Azure Firewall は、サービスとしてのクラウド ネイティブ ステートフル ファイアウォールです。 このファイアウォールは、クラウド リソース、インターネット、オンプレミス間を流れるトラフィックをフィルター処理するために、仮想ネットワークまたは Azure Virtual WAN ハブ デプロイにデプロイできます。 ルールまたはポリシーを (Azure Firewall または Azure Firewall Manager を使用して) 作成し、レイヤー 3 からレイヤー 7 の制御を使用してトラフィックを許可するか拒否するかを指定します。 また、Azure Firewall とサード パーティの両方を使用して、インターネットに送信されるトラフィックをフィルター処理することもできます。 高度なフィルター処理とユーザー保護のために、一部またはすべてのトラフィックをサード パーティのセキュリティ プロバイダー経由で送信します。

ネットワークの観点から Azure でワークロードを整理する場合の、一般的なパターンを次に示します。 これらの各パターンでは、さまざまな種類の分離と接続が提供されます。 組織に最適なモデルについては、組織のニーズに基づいて決定する必要があります。 これらの各モデルで、Azure ネットワーク サービスを使用してセグメント化を行う方法について説明します。

また、組織に適した設計は、ここに一覧表示されているもの以外である可能性もあります。 また、その結果が予想されるのは、すべてのユーザーに合う 1 つのサイズがないためです。 最終的には、これらのパターン全体の原則を使用して、組織に最適なものを作成することが期待されます。 Azure プラットフォームは、必要な柔軟性とツールを提供します。

パターン 1: 単一の仮想ネットワーク

このパターンでは、ワークロードのすべてのコンポーネントまたは、場合によっては、IT フットプリント全体が単一仮想ネットワーク内に配置されます。 仮想ネットワークは複数のリージョンにまたがることはできないため、単一のリージョンでのみ操作する場合、このパターンである可能性があります。

この仮想ネットワーク内のセグメントの作成に使用する可能性が最も高いエンティティは、NSG または ASG です。 どちらを選ぶかは、ネットワーク サブネットまたはアプリケーション グループのどちらとしてセグメントを参照するかによって異なります。 次の図は、そのようなセグメント化された仮想ネットワークの外観例です。

単一の仮想ネットワークを示す図。

この設定では、データベース ワークロードを配置した Subnet1 と、Web ワークロードを配置した Subnet2 があります。 Subnet1 が Subnet2 とのみ通信できることと、Subnet2 がインターネットと通信できることを示す NSG を配置することができます。 また、多くのワークロードが存在する場合は、この概念をさらに取り入れることができます。 たとえば、あるワークロードが別のワークロードのバックエンドと通信することを許可しないサブネットを構築します。

ここでは NSG を使用してサブネット トラフィックを管理する方法を説明しましたが、Azure Marketplace または Azure Firewall のネットワーク仮想化アプライアンスを使用して、このセグメント化を適用することもできます。

パターン 2: 複数の仮想ネットワーク間でピアリングを使用

このパターンは、前のパターンを拡張したもので、潜在的なピアリング接続を持つ複数の仮想ネットワークがあります。 アプリケーションを個別の仮想ネットワークにグループ化する場合や、複数の Azure リージョンに存在させる必要がある場合は、このパターンを選ぶことができます。 仮想ネットワークは、相互に通信するためには仮想ネットワークを別のネットワークに明示的にピアリングする必要があるため、仮想ネットワークを介して組み込みのセグメント化が行えます。 (仮想ネットワーク ピアリングの接続は推移的ではないことに注意してください)。パターン 1 と同様の方法で仮想ネットワーク内をさらにセグメント化するには、仮想ネットワークで NSG/ASG を使用します。

複数仮想ネットワークのパターンを示す図。

パターン 3: ハブ アンド スポーク モデルの複数の仮想ネットワーク

このパターンは、より高度な仮想ネットワーク組織であり、特定のリージョンの仮想ネットワークを、そのリージョン内の他のすべての仮想ネットワーク用のハブとして選択します。 ハブ仮想ネットワークとそのスポーク仮想ネットワークの間の接続は、Azure 仮想ネットワーク ピアリングを使用して実現されます。 すべてのトラフィックはハブ仮想ネットワークを通過し、異なるリージョンにある他のハブへのゲートウェイとして機能することができます。 ハブでセキュリティ体制を設定して、仮想ネットワーク間のトラフィックをスケーラブルな方法でセグメント化し、管理できるようにします。 このパターンの利点の 1 つは、 ネットワーク トポロジが増えるにつれ、セキュリティ体制のオーバーヘッドが増大することはないことです (新しいリージョンに展開する場合を除く)。 また、このトポロジ パターンは Azure Virtual WAN に置き換えられる場合があります。これにより、ユーザーはハブ仮想ネットワークを管理サービスとして管理できます。 Azure Virtual WAN 導入の利点について詳しくは、ハブ アンド スポークの Virtual WAN アーキテクチャに関する記事を参照してください。

ハブ アンド スポーク モデルを示す図。

推奨される Azure クラウド ネイティブ セグメント化の制御は、Azure Firewall です。 Azure Firewall は、Microsoft Azure Virtual Network とサブスクリプションの両方で機能し、レイヤー 3 からレイヤー 7 の制御を使用してトラフィック フローを管理できます。 通信ルールがどのように示されるかを定義し (たとえば、仮想ネットワーク X は仮想ネットワーク Y と通信できないが、仮想ネットワーク Z とは通信できる。*.github.com へのアクセスを除く仮想ネットワーク X のインターネットはない、など)、一貫して適用することができます。 Azure Firewall Manager を使うと、複数の Azure Firewall 間でポリシーを一元管理し、DevOps チームがローカル ポリシーをさらにカスタマイズできるようにすることが可能です。 また、マネージド ハブ ネットワークとして Azure Virtual WAN を選択した場合、Azure Firewall Manager を使用することもできます。

次の表は、パターンのトポロジの比較を示しています。

パターン 1 パターン 2 パターン 3
接続とルーティング: 各セグメントの相互通信方法 システム ルーティングでは、任意のサブネット内の任意のワークロードへの既定の接続が提供されます パターン 1 と同じ スポーク仮想ネットワーク間の既定の接続はありません。 接続を有効にするには、ハブ仮想ネットワークで Azure Firewall などのレイヤー 4 ルーターが必要です。
ネットワーク レベルのトラフィックのフィルター処理 トラフィックは既定で許可されます。 NSG や ASG をこのパターンのフィルター処理に使用することができます。 パターン 1 と同じ 既定では、スポーク仮想ネットワーク間のトラフィックは拒否されます。 Azure Firewall 構成では、windowsupdate.com などの選択したトラフィックを有効にできます。
一元化されたログ記録 仮想ネットワークの NSG および ASG ログ すべての仮想ネットワークにわたる NSG および ASG ログを集計します ハブを介して送信されるすべての承認および拒否されたトラフィックを、Azure Firewall が Azure Monitor にログ記録します。
意図せず開かれたパブリック エンドポイント DevOps で誤って、正しくない NSG や ASG ルールを使用してパブリック エンドポイントが開かれる場合があります。 パターン 1 と同じ スポーク仮想ネットワークで誤ってパブリック エンドポイントを開いた場合、アクセスは有効にされません。 戻りパケットはステートフル ファイアウォール (非対称ルーティング) を介して破棄されます。
アプリケーション レベルの保護 NSG や ASG では、ネットワーク レイヤーのサポートのみが提供されます。 パターン 1 と同じ Azure Firewall では、送信トラフィックと仮想ネットワーク間での HTTP/S および MSSQL の FQDN フィルター処理がサポートされます。

パターン 4: 複数のネットワーク セグメントにまたがる複数の仮想ネットワーク

このパターンでは、同じく複数のサブスクリプションにまたがる複数の仮想ネットワークを、一元的に管理および保護する方法について説明します。 AVNM で作成したセキュリティ管理規則では、仮想ネットワークが相互に接続されていても、異なるサブスクリプションに属していても、一貫した方法でベースライン セキュリティ規則を適用できます。 たとえば、SSH ポート 22、RDP ポート 3389 など、インターネットからの危険度の高いポートを無効にして、組織内のすべての仮想ネットワークでセキュリティ侵害からソリューションを保護します。 セキュリティ管理規則とそのしくみについて詳しくは、Azure Virtual Network Manager のセキュリティ管理規則に関するページをご覧ください。

Azure Virtual Network Manager を示す図。

AVNM は、最小限のネットワーク ルールで組織のネットワーク全体を保護する優れたソリューションですが、AVNM に加えて、NSG や ASG を使用して各仮想ネットワークに詳細なネットワーク ルールを適用する必要があります。 このプロセスは、セキュリティ要件に基づいてシステムによって異なる場合があります。

次のステップ

コンポーネント テクノロジの詳細については、次を参照してください。

次の関連するアーキテクチャを確認してください。