この記事では、ネットワーク セキュリティ グループなどのツールに対してセキュリティ ポリシーを柔軟かつスケーラブルに適用するセキュリティ管理規則について説明します。 まず、仮想ネットワークの適用のさまざまなモデルについて説明します。 次に、セキュリティ管理規則を使用してセキュリティを適用するための一般的な手順について説明します。
仮想ネットワークの適用
ネットワーク セキュリティ グループ (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トラフィックを許可するセキュリティ管理者ルールです。
10は100より小さいため、 アプリネットワークグループの 許可ルールは、組織内のすべての仮想ネットワークに適用される拒否ルールの前に評価されます。
手順 4: セキュリティ管理構成をデプロイする
セキュリティ管理者の設定を展開した後、社内のすべての仮想ネットワークにはセキュリティ管理者ルールによって強制される受信SSHトラフィック拒否ルールが適用されます。 個々のチームが拒否規則を変更することはできません。 定義できるのは会社の管理者だけです。 アプリの仮想ネットワークには、入荷SSHトラフィックを許可するルールと、すべてのネットワークグループルールから継承した受信SSHトラフィック拒否ルールの両方があります。 Appネットワークグループの「Allow inbound SSH Traffic」ルールは優先度10なので、まず評価されます。 着信SSHトラフィックが アプリの 仮想ネットワークに到達した場合、優先度10のルールでそのトラフィックが許可されます。 Appの仮想ネットワークのサブネットにNSGが存在すると仮定すると、この入荷SSHトラフィックは次にアプリケーションチームが設定したNSGに基づいて評価されます。 ここで説明するセキュリティ管理者ルールの手法を使用すると、会社の管理者は会社のポリシーを効果的に適用し、組織全体にわたって NSG と連携する柔軟なセキュリティ ガード レールを作成できます。
次のステップ
セキュリティ管理規則を使用して危険度の高いポートをブロックする方法について説明します
Azure Virtual Network Manager の FAQ を参照してください。