Azure Private LinkとNSGの相性とは？トラフィック制御のポイントを初心者向けに解説

Azure NSGとPrivate Linkの相性｜トラフィック制御を正しく設定するポイント

先生と生徒の会話形式で理解しよう

生徒

「Azure Private Link（アジュールプライベートリンク）を使って、社内システムからデータベースに安全に接続したいんです。でも、NSG（ネットワークセキュリティグループ）の設定が難しくて困っています。」

先生

「それは素晴らしい取り組みですね。Private Linkを使えば、インターネットを経由せずにプライベートなネットワーク内で通信が完結します。ただし、NSGとの組み合わせには少しコツが必要なんですよ。」

生徒

「相性があるってことですか？どこの通信を許可すれば正しく動くのか、具体的に教えてほしいです！」

先生

「もちろんです。初心者の方でも迷わないように、通信の流れや設定のポイントを整理して解説していきましょう！」

1. Azure Private LinkとNSGの基本概念

Azure Private Link（アジュールプライベートリンク）とは、Azure上のサービス（SQL DatabaseやStorage Accountなど）に、自分たちの仮想ネットワーク（VNet）内のプライベートIPアドレスを使ってアクセスできるようにする仕組みです。これにより、データがインターネットに露出するリスクを劇的に減らすことができます。

一方で、NSG（ネットワークセキュリティグループ）は、仮想ネットワーク内の通信を制御する「ファイアウォール」のような役割を果たします。特定のIPアドレスやポート番号からの通信を「許可」したり「拒否」したりするルールを設定します。この二つを組み合わせる際、どこで通信がブロックされるのかを正しく理解することが、トラブルシューティングの第一歩となります。

2. プライベートエンドポイントとトラフィックの流れ

Private Linkを利用する際は、仮想ネットワーク内に「プライベートエンドポイント」という特殊なネットワークインターフェイス（NIC）が作成されます。このエンドポイントには、仮想ネットワーク内のプライベートIPアドレスが割り当てられます。

通常の通信であれば、仮想マシンからこのプライベートIPアドレスに対してパケットを送信します。このとき、通信経路には二つのチェックポイントが存在します。一つ目は「送信元（仮想マシンなど）」のサブネットに適用されたNSG、二つ目は「宛先（プライベートエンドポイント）」のサブネットに適用されたNSGです。以前のAzureの仕様では、プライベートエンドポイントに対するNSGの制御には制限がありましたが、現在は設定によって柔軟に制御が可能になっています。

ネットワーク構成をイメージするために、簡単な構成例を考えてみましょう。例えば、WEBサーバーがDBサーバーに接続するようなケースです。ここで、接続を確認するためのテスト用スクリプトの例を見てみましょう。


using System;
using System.Net.NetworkInformation;

class ConnectivityCheck
{
    static void Main()
    {
        // プライベートエンドポイントのIPアドレスを指定
        string targetIp = "10.0.0.5"; 
        Ping pingSender = new Ping();
        
        try
        {
            PingReply reply = pingSender.Send(targetIp);
            if (reply.Status == IPStatus.Success)
            {
                Console.WriteLine("プライベートエンドポイントへの接続に成功しました！");
            }
            else
            {
                Console.WriteLine("接続に失敗しました。NSGの設定を確認してください。");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("エラーが発生しました: " + ex.Message);
        }
    }
}


プライベートエンドポイントへの接続に成功しました！

3. ネットワークセキュリティグループ（NSG）の設定ルール

NSGを設定する際、最も重要なのは「受信セキュリティ規則」と「送信セキュリティ規則」の区別です。Private Linkを経由する通信において、接続元の仮想マシンから見れば「送信（アウトバウンド）」の規則が適用され、プライベートエンドポイント側から見れば「受信（インバウンド）」の規則が適用されます。

初心者がよく陥る罠は、宛先となるプライベートエンドポイントのIPアドレスに対してポートを開放し忘れることです。例えば、Azure SQL Databaseに接続する場合、デフォルトではポート番号1433を使用します。このポート番号に対する通信をNSGで許可していないと、どれだけPrivate Linkの設定が正しくても通信は遮断されてしまいます。

ここで、設定状況を管理するためのリスト形式のデータをイメージしてみましょう。どのサブネットにどのルールを適用するかを整理することが大切です。


RuleName    | Priority | Port | Direction | Action
------------+----------+------+-----------+--------
AllowSQL    | 100      | 1433 | Outbound  | Allow
AllowHTTPS  | 110      | 443  | Outbound  | Allow
DenyAll     | 65000    | Any  | Outbound  | Deny

上記のような設定を管理する場合の、設定変更用SQLイメージ（内部管理用）は以下のようになります。


INSERT INTO NetworkRules (RuleName, Priority, Port, Direction, Action)
VALUES ('AllowSQL', 100, 1433, 'Outbound', 'Allow');

SELECT * FROM NetworkRules WHERE Direction = 'Outbound';


RuleName | Priority | Port | Direction | Action
---------+----------+------+-----------+-------
AllowSQL | 100      | 1433 | Outbound  | Allow

4. プライベートエンドポイントにおけるNSGサポートの有効化

実は、プライベートエンドポイントが存在するサブネットに対してNSGを正しく機能させるには、「プライベートエンドポイントのネットワークポリシー」という設定を有効にする必要があります。これが無効になっていると、そのサブネットにNSGを割り当てていても、プライベートエンドポイント宛ての通信がNSGのルールを無視して通過してしまう（あるいは予期せずブロックされる）ことがあります。

AzureポータルやCLI（コマンドラインインターフェイス）から、この「ネットワークポリシー」の設定を確認・変更することができます。特にセキュリティ要件が厳しいシステムでは、この設定を有効にして、プライベートエンドポイントへのアクセスを厳密に制御することが推奨されます。

CLIを使って設定を確認する際のコマンド例は以下の通りです。


az network vnet subnet update \
  --name MySubnet \
  --resource-group MyResourceGroup \
  --vnet-name MyVnet \
  --disable-private-endpoint-network-policies false
{
  "name": "MySubnet",
  "privateEndpointNetworkPolicies": "Enabled",
  "provisioningState": "Succeeded"
}

5. 送信元サブネットでの制御ポイント

通信を開始する側、つまり「送信元」の仮想マシンなどが所属するサブネットでのNSG設定についても詳しく見ていきましょう。ここでは、サービスへのアクセスを制限するために、宛先IPアドレス（プライベートエンドポイントのIP）に対して特定のポートのみを許可する設定を行います。

ここで注意したいのは、Azureサービスのバックエンド側での変更です。Private Linkを使っている場合、サービス側のIPアドレスは固定されますが、まれに構成変更などで新しいエンドポイントを追加することがあります。運用の手間を減らすためには、IPアドレスを直接指定するだけでなく、ASG（アプリケーションセキュリティグループ）を活用して、論理的なグループに対してルールを適用するのも賢い方法です。

プログラムから特定のポートが開いているかを確認する、簡易的なポートチェッカーの例を作成してみました。


using System;
using System.Net.Sockets;

class PortChecker
{
    static void Main()
    {
        string host = "10.0.0.5";
        int port = 1433; // SQL Serverのデフォルトポート

        using (TcpClient client = new TcpClient())
        {
            try
            {
                // 3秒のタイムアウトを設定して接続試行
                var result = client.BeginConnect(host, port, null, null);
                bool success = result.AsyncWaitHandle.WaitOne(TimeSpan.FromSeconds(3));

                if (success && client.Connected)
                {
                    Console.WriteLine($"{port}番ポートへの通信は許可されています。");
                }
                else
                {
                    Console.WriteLine($"{port}番ポートが閉じているか、NSGで遮断されています。");
                }
            }
            catch (Exception)
            {
                Console.WriteLine("接続中にエラーが発生しました。");
            }
        }
    }
}


1433番ポートへの通信は許可されています。

6. 宛先サブネットでの制御ポイント

プライベートエンドポイントが配置されている「宛先」のサブネットにおけるNSG設定です。ここでは、どの送信元からのアクセスを許可するかを定義します。例えば、「WEBサーバー用サブネットからのアクセスのみを許可し、それ以外の管理用サブネットからのアクセスは拒否する」といった、最小権限の原則に基づいた設定が可能です。

ここで混乱しやすいのが、プライベートエンドポイント自体の挙動です。プライベートエンドポイントは、受信したトラフィックをバックエンドのAzureサービス（Paas：サービスとしてのプラットフォーム）へ転送します。そのため、NSGのルールでは「受信」方向の制御をメインに行うことになります。宛先IPにはプライベートエンドポイントのIPアドレスを、宛先ポートには対象サービスのリスニングポートを指定します。

データベース接続ユーザーの管理テーブルなどを例に、アクセス許可リストをイメージしてみましょう。


UserID | AccessFrom     | TargetService | Permission
-------+----------------+---------------+------------
101    | 192.168.1.10   | SQL_DB        | Allow
102    | 192.168.1.20   | SQL_DB        | Allow
103    | 172.16.0.5     | Storage       | Deny
104    | 10.0.0.50      | AppService    | Allow

このデータを更新するSQLの例です。


UPDATE AccessControl 
SET Permission = 'Allow' 
WHERE UserID = 103;

SELECT * FROM AccessControl;


UserID | AccessFrom     | TargetService | Permission
-------+----------------+---------------+------------
101    | 192.168.1.10   | SQL_DB        | Allow
102    | 192.168.1.20   | SQL_DB        | Allow
103    | 172.16.0.5     | Storage       | Allow
104    | 10.0.0.50      | AppService    | Allow

7. トラブルシューティングのコツ

もし通信がうまくいかない場合は、どこでパケットが止まっているかを特定する必要があります。Azureには「ネットワークウォッチャー（Network Watcher）」という非常に便利なツールがあります。その中の「IPフローの検証」機能を使うと、指定した送信元と宛先の間で、どのNSGルールが通信を許可または拒否しているかを即座に判定してくれます。

また、NSGの診断ログを有効にすることで、実際に拒否されたパケットの履歴を確認することも可能です。ログを確認する際は、タイムスタンプ、送信元IP、宛先IP、ポート番号、そして「Action（AllowかDenyか）」を重点的にチェックしましょう。初心者のうちは、優先度の高いルールが先に適用されてしまい、意図したルールまで到達していないというミスが多く見られます。優先度の数字が小さいほど先に評価されるという原則を忘れないようにしましょう。

8. セキュリティを高めるためのベストプラクティス

Private LinkとNSGを併用する最大の目的は、セキュリティの強化です。単に「繋がれば良い」という考えではなく、必要最小限の通信だけを許可する「ホワイトリスト方式」で運用することが推奨されます。具体的には、タグ（サービス分類）を活用したり、特定のIPアドレス範囲だけに絞り込むことで、万が一仮想マシンが乗っ取られた際の被害を最小限に抑えることができます。

さらに、Azure Firewall（アジュールファイアウォール）を組み合わせることで、より高度なトラフィック分析やフィルタリングを行うことも可能です。小規模なシステムであればNSGだけでも十分ですが、大規模なエンタープライズ環境では、複数のセキュリティ層を重ねる「多層防御」の考え方が不可欠です。Private Linkは、その多層防御における非常に強力な武器の一つとなります。

最後に、接続情報を管理する簡単なC#クラスの例を見て、全体のイメージを固めましょう。


public class AzureConnectionInfo
{
    public string ServiceName { get; set; }
    public string PrivateIp { get; set; }
    public int Port { get; set; }

    public void DisplayConfig()
    {
        Console.WriteLine($"サービス名: {ServiceName}");
        Console.WriteLine($"接続先IP: {PrivateIp}");
        Console.WriteLine($"使用ポート: {Port}");
        Console.WriteLine("この情報を元にNSGの受信・送信規則を設定してください。");
    }
}

class Program
{
    static void Main()
    {
        var config = new AzureConnectionInfo 
        { 
            ServiceName = "Azure SQL Database", 
            PrivateIp = "10.0.0.15", 
            Port = 1433 
        };
        config.DisplayConfig();
    }
}


サービス名: Azure SQL Database
接続先IP: 10.0.0.15
使用ポート: 1433
この情報を元にNSGの受信・送信規則を設定してください。

まとめ

Azure Private Link（アジュールプライベートリンク）とNSG（ネットワークセキュリティグループ）を組み合わせて活用することは、現代のクラウドセキュリティにおいて非常に重要なテーマです。Private Linkは、本来インターネット経由でアクセスするAzureのPaaSサービスを、自分たちの仮想ネットワーク（VNet）内のプライベートな存在として扱うための画期的な技術です。しかし、ただ導入するだけでは不十分であり、NSGという「門番」を正しく配置して初めて、鉄壁の守りを築くことができます。

通信制御の核心を振り返る

この記事を通じて学んだ通り、Private Linkの通信制御には「送信元」と「宛先」の両面での設定が欠かせません。送信元の仮想マシン側では、どのアドレスのどのポートに対して通信を許可するかを明確に定義し、不要なアウトバウンド通信を遮断することで、マルウェアなどによる情報の外部流出を防ぐことができます。一方、プライベートエンドポイントが設置された宛先サブネット側では、特定の正当なアクセス元からのインバウンド通信のみを受け入れるようにルールを厳格化します。この「入り口」と「出口」の両方でチェックを行う二重の防御姿勢こそが、セキュアなインフラ構築の基本となります。

設定の落とし穴とネットワークポリシー

特に初心者が迷いやすいポイントとして、プライベートエンドポイントにおける「ネットワークポリシーの有効化」がありました。以前の仕様ではNSGがプライベートエンドポイントに対して無視されることもありましたが、現在では設定変更により、プライベートエンドポイントに対しても詳細なフィルタリングを適用できるようになっています。これにより、マイクロセグメンテーション（ネットワークを細かく切り分けて制御する手法）が容易になり、より高度なセキュリティ設計が可能となっています。

また、運用面ではAzure Network Watcher（ネットワークウォッチャー）などのツールを駆使し、パケットがどこで止まっているかを可視化する習慣をつけることが大切です。クラウドの世界では、物理的な配線が見えない分、論理的な設定の整合性がすべてを左右します。優先順位（Priority）の設計ミス一つで通信が途絶えることもあるため、常にルールの一覧性を保ち、ドキュメント化しておくことが推奨されます。

実務で役立つ確認用SQLとC#クラスの再整理

最後に、実務でNSGのルール変更履歴や接続先リストをデータベースで管理することを想定した、より実戦的なデータ構造とプログラムの例を見てみましょう。このようにデータを構造化して捉えることで、複雑なネットワーク設定も頭の中で整理しやすくなります。


id | service_type  | private_ip | port | security_zone | last_audit_date
---+---------------+------------+------+---------------+-----------------
1  | SQL_Database  | 10.0.1.10  | 1433 | Database_Zone | 2026-03-25
2  | Blob_Storage  | 10.0.1.20  | 443  | Storage_Zone  | 2026-03-26
3  | Key_Vault     | 10.0.2.5   | 443  | Security_Zone | 2026-03-30
4  | App_Service   | 10.0.5.15  | 443  | Frontend_Zone | 2026-03-31
5  | Redis_Cache   | 10.0.1.50  | 6379 | Database_Zone | 2026-03-28

特定のゾーンに属するエンドポイントの情報を抽出するSQLの例です。


SELECT service_type, private_ip, port
FROM EndpointInventory
WHERE security_zone = 'Database_Zone'
ORDER BY id ASC;


service_type | private_ip | port
-------------+------------+-----
SQL_Database | 10.0.1.10  | 1433
Redis_Cache  | 10.0.1.50  | 6379

次に、これらの接続情報を管理するための拡張されたC#クラスの例を紹介します。


using System;
using System.Collections.Generic;

public class NetworkSecurityAudit
{
    public string RuleName { get; set; }
    public string Description { get; set; }
    public bool IsEncrypted { get; set; }

    public void PrintAuditReport()
    {
        string status = IsEncrypted ? "暗号化済み" : "非暗号化（警告）";
        Console.WriteLine($"[監査レポート] ルール名: {RuleName}");
        Console.WriteLine($"説明: {Description}");
        Console.WriteLine($"通信状態: {status}");
        Console.WriteLine("--------------------------------------------------");
    }
}

class Program
{
    static void Main()
    {
        var auditLogs = new List<NetworkSecurityAudit>
        {
            new NetworkSecurityAudit { RuleName = "Allow-SQL-Private", Description = "社内システムからDBへの専用線接続", IsEncrypted = true },
            new NetworkSecurityAudit { RuleName = "Deny-Public-Access", Description = "外部インターネットからの全遮断設定", IsEncrypted = true }
        };

        Console.WriteLine("Azure Private Link 運用状況確認プログラムを開始します...");
        foreach (var log in auditLogs)
        {
            log.PrintAuditReport();
        }
    }
}


Azure Private Link 運用状況確認プログラムを開始します...
[監査レポート] ルール名: Allow-SQL-Private
説明: 社内システムからDBへの専用線接続
通信状態: 暗号化済み
--------------------------------------------------
[監査レポート] ルール名: Deny-Public-Access
説明: 外部インターネットからの全遮断設定
通信状態: 暗号化済み
--------------------------------------------------

Private LinkとNSGの適切な設定は、一度覚えてしまえば他のAzureサービスにも応用が効く強力なスキルです。最初は複雑に感じるかもしれませんが、「どのIPがどこへ、どのポートで話しかけるか」という基本に立ち返れば、必ず正解に辿り着けます。この記事が、皆さんの安全なAzure環境構築の一助となれば幸いです。

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！Private LinkとNSGをバラバラに考えていたのが、繋がらない原因だったんですね。特に宛先サブネット側でのインバウンド許可が必要だという点が、目から鱗でした。」

先生

「その通りです。プライベートエンドポイントはVNet内の『仮想的なNIC（ネットワークカード）』として振る舞うので、そこに届くパケットをNSGで通してあげる必要があるんです。理解が深まりましたね。」

生徒

「はい。あと、ネットワークポリシーを有効にしないとNSGが効かない場合があるという話も衝撃でした。Azureポータルでしっかり設定を確認してみます。もし設定を間違えても、ネットワークウォッチャーがあるから安心ですね。」

先生

「素晴らしい意気込みです！トラブルシューティングツールを使いこなせれば、エンジニアとして一人前ですよ。セキュリティグループの優先順位を整理する時は、さっきのSQLの例のようにリスト化して考えるとミスが減りますよ。」

生徒

「分かりました。まずは開発環境で1433ポートの疎通確認プログラムを動かして、NSGのルールを変えながら挙動を試してみようと思います。実際に動かしてみるのが一番の近道ですね！」

先生