Share via

セキュリティ管理規則を使用した Azure Virtual Network Manager での仮想ネットワークへの適用

  • [アーティクル]

この記事では、ネットワーク セキュリティ グループなどのツールに対してセキュリティ ポリシーを柔軟かつスケーラブルに適用するセキュリティ管理規則について説明します。 まず、仮想ネットワークの適用のさまざまなモデルについて説明します。 次に、セキュリティ管理規則を使用してセキュリティを適用するための一般的な手順について説明します。

重要

Azure Virtual Network Manager は、ハブ アンド スポーク接続構成と、セキュリティ管理規則を使用したセキュリティ構成に対して一般提供されています。 メッシュ接続の構成は、パブリック プレビューのままです。

このプレビュー バージョンはサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

仮想ネットワークの適用

ネットワーク セキュリティ グループ (NSG) だけでは、複数のアプリケーション、チーム、さらには組織全体にわたって広範囲の仮想ネットワークに適用することが難しい場合があります。 多くの場合、組織全体への一元化された適用の試みと、きめ細かく柔軟な制御をチームにまかせるこという作業のバランスを取る必要があります。

セキュリティ管理規則は、これらの各モデルの長所を統合し、同時にそれぞれの短所を減らすことで、適用と柔軟性の間のこの変動を完全に排除することを目的とします。 中央のガバナンス チームは、セキュリティ管理規則を通じてガード レールを確立しますが、個々のチームが NSG 規則を通じて必要に応じて柔軟にピンポイントでセキュリティを適用する余地を残しています。 セキュリティ管理規則は、NSG ルールをオーバーライドするためのものではありません。 それよりも、NSG ルールと連携して、組織全体に適用と柔軟性を提供します。

適用モデル

セキュリティ管理規則を使用しないセキュリティ管理のいくつかの一般的なモデルとその長所と短所を見てみましょう。

モデル 1: 中央のガバナンス チームによる NSG の管理

このモデルでは、組織内の中央ガバナンス チームによってすべての NSG が管理されます。

長所 デメリット
中央のガバナンス チームが、重要なセキュリティ規則を適用できます。 管理者が各 NSG を管理する必要があり、NSG の数が増えて負荷が増加するため、運用のオーバーヘッドが大きくなります。

モデル 2 - 個々のチームによる NSG の管理

このモデルでは、一元化されたガバナンス チームなしで、組織内の個々のチームによってそれぞれの NSG が管理されます。

長所 デメリット
個々のチームは、サービス要件に基づいてセキュリティ規則を柔軟に調整できます。 中央ガバナンス チームが、リスクのあるポートのブロックなど、重要なセキュリティ規則を適用できません。

また、個々のチームが NSG を誤って構成したり、NSG のアタッチを忘れたりして、脆弱性の露出を招く可能性もあります。

モデル 3 - NSG は Azure Policy を通じて作成され、個々のチームによって管理されます。

このモデルでは、個々のチームが引き続き NSG を管理します。 違いは、NSG が標準ルールを設定するために Azure Policy を使用して作成される点です。 これらのルールを変更すると、監査通知がトリガーされます。

長所 デメリット
個々のチームは、セキュリティ規則を柔軟に調整することができます。

中央のガバナンス チームは、標準のセキュリティ規則を作成し、規則が変更された場合は通知を受け取ることができます。		 チームの NSG 所有者は引き続き規則を変更できるため、中央のガバナンス チームは依然として標準のセキュリティ規則を適用できません。

また、通知のために管理が困難になることもあります。

セキュリティ管理規則によるネットワーク トラフィックの適用と例外

これまでに説明した概念をシナリオ例に適用してみましょう。 会社のネットワーク管理者は、会社全体の受信 SSH トラフィックをブロックするセキュリティ規則を適用したいと考えています。 この種類のセキュリティ規則の適用は、セキュリティ管理者ルールがないと困難でした。 管理者がすべての NSG を管理する場合、管理オーバーヘッドが高くなり、管理者は NSG ルールを変更する製品チームのニーズに迅速に対応できません。 一方、製品チームがセキュリティ管理規則なしで独自の NSG を管理する場合、管理者は重要なセキュリティ規則を適用できず、潜在的なセキュリティ リスクが未解決のままになります。 セキュリティ管理規則と NSG の両方を使用すると、このジレンマを解決できます。

この場合、管理者はセキュリティ管理規則を作成し、社内のすべての仮想ネッ トワークの受信 SSH トラフィックをブロックできます。 また、管理者は、例外が必要な特定の仮想ネットワークに対して受信 SSH トラフィックを許可するセキュリティ管理規則を作成することもできます。 セキュリティ管理規則は会社全体に適用され、管理者は特定の仮想ネットワークに対して引き続き例外を許可できます。 これは、それぞれの規則の優先度の使用を通じて行われます。

図は、管理者が次の目標を達成する方法を示しています。

  • 組織全体にセキュリティ管理規則を適用します。
  • アプリケーション チームが SSH トラフィックを処理するための例外を許可します。

ネットワーク セキュリティ グループを使用したセキュリティ管理規則の適用の図。

手順 1: ネットワーク マネージャー インスタンスを作成する

会社の管理者は、このネットワーク マネージャー インスタンスのスコープとして会社のルート管理グループを持つネットワーク マネージャーを作成できます。

手順 2: 仮想ネットワークのネットワーク グループを作成する

管理者は、組織内のすべての仮想ネットワークで構成される "すべてのネットワーク グループ" と、例外を必要とするアプリケーションの仮想ネットワークで構成されるアプリ ネットワーク グループという 2 つのネットワーク グループを作成します。 上の図のすべてのネットワーク グループは VNet 1 から VNet 5 で構成され、アプリ ネットワーク グループには VNet 4 と VNet 5 があります。 ユーザーは、動的メンバーシップを使用して両方のネットワーク グループを簡単に定義できます。

手順 3: セキュリティ管理構成を作成する

この手順では、次のセキュリティ管理構成で 2 つのセキュリティ管理規則を定義します。

  • 優先度が 100 未満のすべてのネットワーク グループの受信 SSH トラフィックをブロックするセキュリティ管理規則。
  • 優先度が 10 より高いアプリ ネットワーク グループの受信 SSH トラフィックを許可するセキュリティ管理規則。

手順 4: セキュリティ管理構成をデプロイする

セキュリティ管理構成のデプロイ後、社内のすべての仮想ネットワークには、セキュリティ管理規則によって適用される受信 SSH トラフィックの拒否規則が適用されます。 拒否ルールを変更できるのは個々のチームでなく、定義されている会社の管理者だけです。 アプリ仮想ネットワークには、受信 SSH トラフィックの許可規則と受信 SSH トラフィックの拒否規則 (すべてのネットワーク グループ規則から継承) の両方が含まれます。 アプリ ネットワーク グループの受信 SSH トラフィックの許可規則の優先順位が小さい場合、その規則が最初に評価されます。 受信 SSH トラフィックがアプリ VNet に送信されると、より優先度の高いセキュリティ管理規則によってトラフィックが許可されます。 アプリ仮想ネットワークのサブネットに NSG があると仮定すると、この受信 SSH トラフィックは、アプリケーション チームによって設定された NSG に基づいて次に評価されます。 ここで説明するセキュリティ管理者ルールの手法を使用すると、会社の管理者は会社のポリシーを効果的に適用し、組織全体にわたって NSG と連携する柔軟なセキュリティ ガード レールを作成できます。

次のステップ