KNOWLEDGE - COLUMN ナレッジ - コラム

Azure NSPで一元管理!通信リスクをゼロに

2025-11-20

セキュリティ

ネットワークセキュリティ境界

関連するソリューション

セキュリティサービス

セキュリティ製品

サイバー・セキュリティ・ソリューション部
テクニカルスペシャリスト
ボル カーステン顔写真

PaaSは便利ですが、要件によってはPaaSを利用できない場合もあります。通信の制御が難しかったり、ロギングや監査機能が不足していることが理由として挙げられます。特にPaaS間の通信は注意が必要です。PaaSを気軽に利用する方も多いと思いますが、特に現代ではセキュリティがますます重要になっています。設定ミスや不注意によるデータ流出の可能性があるため、今後はこれを考慮していきましょう。
 
次に、どのようにこれを実現するかという質問が出てくるかと思います。Azureクラウドでは、これを実施するための新しい機能が登場しましたので紹介します。その機能は「Network Security Perimeters(ネットワーク セキュリティ境界)」です。まず強調しておきたいのは、これは主にAzureクラウド上のPaaSを制御するための機能で、他のPaaSを制御できません。しかし、AzureのPaaSは通信を制御することが可能です。詳細は後ほど説明します。
 
参考URL:ネットワークセキュリティ境界とは何ですか?

ネットワークセキュリティ境界

ネットワーク セキュリティ境界のユースケースとは

ネットワークセキュリティ境界のユースケースについてですが、仮想ネットワーク内のリソース、例えば仮想マシンやコンテナなどの通信を制御するために多くの選択肢があります。ネットワークセキュリティグループやアプリケーション セキュリティ グループなどがあり、さらに細かく制御したい場合は、Azure Firewallを導入することも可能です。これらを利用して各リソースの受信および送信を制限することで、データ流出のリスクを抑えることができます。
 
いくつかのPaaSではプライベート エンドポイントという機能もあります。プライベート エンドポイントを使用することで、特定のPaaSのために仮想ネットワーク内にネットワークインターフェースが作成され、安全にインターネットを通さずにアクセスできます。また、プライベートエンドポイントが設定された後、そのPaaSのインターネットエンドポイントを無効化することも可能です。無効化することでインターネットからのアクセスを完全に防ぐことができます。ただし、プライベートエンドポイントへの通信はフローログや通信ログに出ませんので、注意が必要です※2
 
例えば、仮想ネットワークの仮想マシンからプライベートエンドポイントへの通信は確認できますが、プライベートエンドポイントへの受信はログに出ません。オンプレミス環境からExpressRouteやVPN経由でプライベートエンドポイントと通信する際も、Azure側のフローログや通信ログでは確認できません。
 
参考URL:
プライベート エンドポイントとは
※2プライベート エンドポイント トラフィック
 
プライベートエンドポイントがないPaaSについてはどうすればよいでしょう。また、ユースケースによっては必要ない場合もあります。例えば、PaaSのみが存在する場合です。そのため、PaaS同士の間の通信を制御したいと考えています。これまで、特に送信に関しては細かく制御することが難しかったです。
 
PaaSによっては、ファイアウォールのような機能が付いており、受信はある程度制御が可能です。例えば、特定のIPレンジからのみ許可することや、サービスエンドポイントやプライベートエンドポイントに絞ることができます。しかし、PaaSによって受信制御機能が異なるため、制御が不十分な場合もあります。Azure Monitorはその一例です。
 
一方、送信に関しては、ほとんどのPaaSで制御機能がありません。そのため、PaaSからのデータ流出を防ぐことが難しくなります。PaaSからインターネットへの送信や、PaaS間の通信も同様です。PaaS間の通信では、リソースプロバイダーからの通信を許可することはできますが、特定のリソースに絞ることはできませんでした。例えば、ストレージアカウントからの受信を許可できる場合がありますが、細かい制御ができず、すべてのストレージアカウントからの通信を許可してしまうことになります。

ネットワークセキュリティ境界

信頼されたAzureサービスからの通信を許可する選択肢もありますが、これによりすべてのAzure PaaSを許可することになり、細かい制御ができません。
 
参考URL:信頼された Azure サービス
 
繰り返しになりますが、これにはいくつかの問題があります。PaaSごとに設定が必要で、受信および送信の制御機能が不十分です。PaaS間の通信制御機能も不十分で、PaaSによって制御機能が異なり、一貫性がありません。そのため、あるPaaSへのアクセスを監査する際には複雑になります。統一された監査方法がないため、何が何にアクセスしようとしているかの可視化が難しいです。

ネットワーク セキュリティ境界とは

やっと本題に入ります!これらの問題を解決するために、ネットワークセキュリティ境界の機能が役立ちます。まず、新しいリソースとして「ネットワークセキュリティ境界」を作成する必要があります。作成後、特定のPaaSをこのネットワークセキュリティ境界と紐づけることが可能です。ネットワークセキュリティ境界を箱のようなものと考えてください。その箱に複数のPaaSを詰めることができます。
 
例えば、リソースA、リソースB、リソースCを同じネットワークセキュリティ境界と紐づけると、その箱の中に入っているリソース同士で通信が可能になります。これにより、PaaS間の通信制御が簡単になります。PaaSがどのPaaSと通信して良いかという問題も解決されます。
 
この仕組みにより、データの流出を防ぐことができます。例えば、特定のストレージアカウント(PaaS)への通信を許可し、他のストレージアカウントへの通信を拒否することができます。それだけでなく、ネットワーク セキュリティ境界内のリソースに対して、受信・送信を制御することが可能です。リソースごとに異なるルールを設定することもできます。便利ですね!
 
リソースごとに受信ルールと送信ルールを設定でき、一貫した方法で設定が可能になりました。ネットワーク セキュリティ境界にはログ機能もあり、監査の面でも、受信や送信の許可・拒否を確認しやすくなりました。
 
ただし、一つ強調すべき点があります。ネットワークセキュリティ境界内のリソースには、マネージドIDを紐づける必要があります。これは、リソースをネットワークセキュリティ境界に追加すると、その情報がマネージドIDに付与されるためです。同じネットワークセキュリティ境界にあるリソースと通信する際に、マネージドIDを確認し合い、同じであれば通信が許可されます。したがって、リソースをネットワークセキュリティ境界に追加する際は、そのリソースのマネージドIDを有効化する必要があります。ちなみに、マネージドIDなしのリソースを追加しようとすると、Azureポータル上に注意が表示されます。

ネットワークセキュリティ境界


マネージドIDについてですが、2つの種類があります。システム割り当てとユーザー割り当てです。どちらも利用可能です。マネージドIDを有効化することを忘れないでください。有効化しないと、他のネットワークセキュリティ境界内のリソースとの通信ができなくなります。
 
参考URL:マネージド ID の種類
 
ネットワークセキュリティ境界を作成する際、以下の項目を設定する必要があります。まず、「サブスクリプション」や「リソースグループ」を選択します。次に、名前を作成し、リージョンを選択します。最後に、プロファイル名を作成する必要があります。このプロファイルに対して受信・送信ルールを設定できます。ここで設定するプロファイル名はデフォルトプロファイルとなりますが、ネットワークセキュリティ境界を作成した後、追加のプロファイルを作成することも可能です。

リソース

サブスクリプション
既存サブスクリプションを選択
リソースグループ
既存リソースグループを選択
名前
任意
リージョン
既存リージョンを選択
プロファイル名
任意

ネットワークセキュリティ境界を作成する際、プロファイルが必須であることを覚えておいてください。また、最小権限の概念を忘れないでください。プロファイルのルールを設定する際は、できる限り最小限の権限と通信に絞ったほうが良いです。ネットワークセキュリティ境界内のリソースが互いに通信する必要があるからといって、そのネットワークセキュリティ境界の外のすべてのリソースが通信する必要があるわけではありません。同様に、ネットワークセキュリティ境界内のリソースが外部のリソースと通信する必要があるわけでもありません。
 
最小権限の概念に従って、各リソースにできる限り絞りましょう。同じネットワークセキュリティ境界内にリソースA、リソースB、リソースCがあるとします。例えば、リソースAとリソースBの通信要件が異なる場合、各リソースのために専用のプロファイルを作成しましょう。また、残念ながら現在、プロファイルはネットワークセキュリティ境界の子リソースです。したがって、多くのネットワークセキュリティ境界がある場合は、各ネットワークセキュリティ境界のためにプロファイルおよびルールを定義する必要があります。異なるネットワークセキュリティ境界に存在するプロファイルは、他のネットワークセキュリティ境界で使用することはできません。

現在サポートされているリソース

デフォルトプロファイルを作成した後、リソースを追加することが可能です。ネットワークセキュリティ境界にリソースを追加する形となります。現在サポートされているリソースは以下の通りです。

リソース名
サブリソース名
可用性
Azure Monitor
Log Analytics ワークスペース、アプリケーションインサイト、アラート、通知サービス
一般公開
Azure AI Search

一般提供
Cosmos DB

パブリック プレビュー
Event Hubs

一般提供
Key Vault(キーボールト)

一般提供
SQL DB

パブリック プレビュー
Storage

一般提供
Azure OpenAI サービス

パブリック プレビュー

参考URL:オンボード済みのプライベート リンク リソース
 
ネットワークセキュリティ境界機能は比較的新しいため、サポートされているリソースは今後増えていくでしょう。ネットワークセキュリティ境界を作成する段階でリソースを追加することも、作成後に追記することも可能です。ただし、ここで注意が必要なポイントがあります。特定のPaaSは、一つのネットワークセキュリティ境界にのみ追加可能です。一度ネットワークセキュリティ境界と紐づけると、他のネットワークセキュリティ境界に紐づけることはできません。言い換えると、同じ特定のPaaSリソースは複数のネットワークセキュリティ境界に同時に共存することが不可能です。

例:ネットワークセキュリティ境界

次に、受信・送信のルールを設定することができます。ルールの名前を設定することが可能で、受信ルールの場合は、接続元として「ソースIP」および「サブスクリプション」の2つの選択肢があります。現在、接続元として他のネットワークセキュリティ境界を設定することはできません。また、他のサブスクリプションからの通信を許可する場合は、そのサブスクリプションの各サービスでマネージドIDを有効化する必要があります。これは、ネットワークセキュリティ境界がマネージドIDの情報を確認するためです。情報を確認し、マネージドIDが許可されているサブスクリプションに所属している場合、ネットワークセキュリティ境界はその通信を許可します。許可されていないサブスクリプションに所属している場合は、通信を拒否します。
 
送信ルールに関しては、FQDNの許可のみが可能です。IPに基づいて通信を許可・拒否することはできません。FQDNを指定することで、PaaSがどこと通信してよいかを制御できます。受信および送信の制御は基本的にこれに基づきます。
 
参考URL:サポートされているアクセス規則の種類

作成済ネットワークセキュリティ境界の設定

一旦、新しいネットワークセキュリティ境界の作成を取りやめましょう。そして、既存のネットワークセキュリティ境界の設定を確認しましょう。以下の2つの設定を確認することができます。

プロファイル
関連付けられているリソース

ここから新しいプロファイルを追加でき、先ほど説明した通り、特定のリソースの追加や受信・送信ルールを定義できます。
 
リソースの関連付けを確認すると、すでにネットワークセキュリティ境界に追加済みのリソースが以下のように確認できます。あるリソースがどのプロファイルに所属しているかも確認できます。

リソース名
リソースの種類
アクセスモード プロファイル
アクセスログ
有効なパブリックネットワークアクセス
状態
リソースA
ストレージアカウント
Enforced(強制モード) defaultProfile アクセスログを表示
●Secured By Perimeter
●Succeeded
リソースB
ストレージアカウント Transition(移行モード (以前の学習モード)
defaultProfile
アクセスログを表示
▲Enabled ●Succeeded
リソースC
Log Analytics ワークスペース
Enforced
defaultProfile
アクセスログを表示
▲Disabled
●Succeeded
リソースD
Key Vault
Enforced
defaultProfile
アクセスログを表示
▲Enabled
●Succeeded

また、マネージドIDに問題がある場合は、「有効なパブリックネットワークアクセス」の列で確認できます。▲が表示されている場合、マネージドIDに問題があります。「アクセスモード」の列もご存知かと思いますが、デフォルトのアクセスモードはTransition(移行モード、以前の学習モード)となります。必要に応じて手動でEnforced(強制モード)に切り替えることが可能です。
 
移行モードの挙動は、まずリソースに対して設定されているルールを確認します。しかし、一致するルールがない場合は、通信を許可すべきかどうかをリソース自体のファイアウォール設定で確認します。最初は移行モードのままで良いでしょう。設定することで、あるリソースから別のリソースへの通信フローを確認できます。例えば、受信ルールの追加を忘れてしまい、本来その通信が拒否されるはずですが、リソース自体のファイアウォール設定で許可するルールがある場合、その通信を許可します。

ログの設定

また、移行モードが稼働中に最も重要なことはログの確認です。どのリソースがどのリソースを使用しているのかを確認します。ログはAzureの「診断ログ」で確認可能です。ログは通常通り、ストレージアカウントやEvent Hubs、Log Analyticsワークスペースなどに送信可能です。診断ログは必ず設定するようにしてください。
 
ログで確認できるのは、ネットワークセキュリティ境界によるパブリックインバウンド受信・送信の許可および拒否です。また、同じネットワークセキュリティ境界内での許可も確認できます。さらに、PaaS自体のファイアウォールによるパブリックインバウンド受信・送信の許可および拒否も確認できます。他にもルールがありますので、詳細なルールは以下のURLで確認できます。
 
参考URL:アクセス ログのカテゴリ
 
例えば、ログをLog Analyticsワークスペースに送信しているとします。そうすると、Log Analyticsワークスペース内に「NSPAccessLogs」というテーブルが作成されます。クエリを実行することで、以下のデータを確認できます。


説明
timeGenerated
イベント集計の開始を示す時間
オペレーションネーム(OperatingName)
最上位レベルの PaaS 操作名を示します。
操作バージョン(OperationVersion)
操作に関連付けられている API バージョン
カテゴリ(Category)
NSP アクセス ログ カテゴリ
場所(Region)
NSP のリージョンを示します。
結果の説明(ResultDescription)
操作の結果に関する追加の説明 (使用可能な場合)
プロファイル(Profile)
リソースに関連付けられている NSP プロファイルの名前
ServiceResourceId
NSP アクセス ログを出力する PaaS リソースのリソース ID
MatchedRule
一致したアクセス規則名を含む JSON プロパティ バッグ。 NSP アクセス 規則名またはリソース ルール名 (リソース ID ではない) のいずれかを指定できます。
ソースIPアドレス(SourceIpAddress)
受信接続を行う送信元の IP アドレス (使用可能な場合)
SourcePort 受信接続のポート番号 (使用可能な場合)
SourceProtocol
{AppProtocol}:{TransportProtocol} 形式の受信接続に使用されるアプリケーション層プロトコルとトランスポート層プロトコル。 例: "HTTPS:TCP"。 使用可能な場合は指定する必要があります。
SourcePerimeterGuids
ソース リソースの境界 GUID の一覧。 これは、境界 GUID に基づいて許可されている場合にのみ指定する必要があります。
SourceAppId Azure Active Directory のソースのアプリ ID を表す一意の GUID
ResultDirection Inbound' または 'Outbound' の評価結果の方向
ResultAction 評価の結果が 'Approved' か 'Denied' かを示します。
ルールタイプ(RuleType)
ルールが定義されている場所 (NSP または PaaS リソース) を示します。
交通タイプ(TrafficType)
トラフィックが 'プライベート'、'パブリック'、'Intra'、'クロス' の境界であるかどうかを示します。

参考URL:nspaccesslogsの列
 
診断ログを有効化すれば、移行モードでも強制モードでもログを取得できます。このログは監査のために利用可能です。また、ネットワークセキュリティ境界内のリソースのログを収集したい場合、収集先のLog Analyticsワークスペースを同じネットワークセキュリティ境界に追加することが必要です。これは、リソースがLog Analyticsワークスペースにデータを送信するためです。
 
リソース自体のファイアウォール設定で通信を許可するルールがある場合、その通信は許可されます。

移行モードから強制モードへの切り替えの流れ

診断ログを有効化すると、先ほど共有した表の通り、「NSPAccessLogs」テーブルを利用して、ネットワークセキュリティ境界のログを確認できます。通信が許可されたのか拒否されたのか、その通信に関連するプロファイルなどを確認できます。ネットワークセキュリティ境界のルールによって許可・拒否されたのか、PaaS自体のファイアウォールによって許可・拒否されたのかも確認できます。
 
通信を確認し、ルールに問題がなければ、移行モードから強制モードに切り替えることが可能です。強制モードに切り替えると、PaaS自体のファイアウォールで許可された通信でも、そのルールは無視されます。ネットワークセキュリティ境界のルールのみが適用されるため、ルールに問題がないか、まず移行モードで確認することが非常に重要です。
 
まず移行モードで動作させ、自分の環境で機能するために何のアクセスが必要とされるか確認しましょう。誰も本番のアプリを壊したくはありません。100%問題ないと確認できたら、強制モードに切り替えることを検討します。
 
なお、ある仮想ネットワークでサービスエンドポイントを利用してリソースと通信している場合、強制モードに切り替えるとサービスエンドポイントは使用できなくなります。プライベートエンドポイントに切り替える必要があります。既にプライベートエンドポイントを使用している場合は、そのまま使用可能です。プライベートエンドポイントは受信ルールに追加する必要はありません。

ネットワークセキュリティ境界

パブリック ネットワーク アクセスの制御

もう一つの新しい機能が現在デプロイされています。リソースごとに設定できるかは異なりますが、PaaSによっては受信を許可するか、インターネットからの受信を許可するかを設定できます。その設定に「境界で保護」という機能が追加されている可能性があります。例えば、ストレージアカウントのネットワーク設定を確認してみましょう。
 
[セキュリティとネットワーク] で [ネットワーク] を選択し、パブリックネットワークアクセスのところで [管理] を選択します。通常の「有効」および「無効」に加えて、「境界で保護」も追加されています。ストレージアカウントがまだネットワークセキュリティ境界と紐づいていない状態でもこのオプションを選択できます。選択すると、すべての受信・送信が拒否され、プライベートエンドポイントに対する通信のみが許可されます。「無効」の選択肢よりもさらにセキュアな選択肢となります。「無効」は受信の通信のみを拒否します。
 
参考URL:既定のパブリック ネットワーク アクセス規則を設定する
 
したがって、最初に「境界で保護」を選択して有効化してから、ネットワークセキュリティ境界に紐づければ、そのネットワークセキュリティ境界のルールが適用され、同じネットワークセキュリティ境界内に存在するリソースと通信することができます。これは最小権限を与える方法の一つです。
 
また、自動化のためにAzure Policyを利用することが可能です。あるリソースが作成された際に、そのリソースのネットワーク設定を自動的に「境界で保護」に設定することができます。さらに、デフォルトのネットワークセキュリティ境界に紐づけることも可能です。別のタイミングでそのデフォルトのネットワークセキュリティ境界から外し、異なるネットワークセキュリティ境界に移行することもできます。このような運用も可能です。

最後に

ネットワークセキュリティ境界についての説明は以上です。比較的シンプルなものですが、冒頭で述べた一貫性のないPaaSのネットワーク制御問題を解決できます。PaaSリソースの受信・送信ルールは統一された方法で設定できるようになり、データの流出を防ぐために役立ちます。最小権限とアクセスを与えることができ、豊富なログもあるため、監査もより簡単に行えるようになりました。
 
ぜひネットワークセキュリティ境界を試してみてください。また、AzureのPaaSだけでなく、他に使用しているPaaSが安全に使われているかどうかも考えてみてください。他のPaaSでも似たような機能があるかもしれません。


当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。

メルマガ登録ボタン

ボル カーステン

サイバー・セキュリティ・ソリューション部 テクニカルスペシャリスト

この執筆者の記事一覧

関連するソリューション

セキュリティサービス

セキュリティ製品

関連するナレッジ・コラム

もし1億円を運ぶなら?そこから学ぶ5つの脅威モデリング

バックアップ、”ちゃんと”取れていますか?

パスキーは万能か?~証券詐欺から考える個人認証の現実