モチベ
- Azure PaaSサービスと接続するための穴あけって基本アウトバウンドでしか許可したことないな～と思いつつ、ただ実際受信トラフィック発生することもあるよな～どう考えればいいんだろうと思っていた
前提
- NSGもAzure Firewallもステートフルなファイアーウォールであり、行きの通信許可に対して戻りの通信の許可ルールは自動で追加される
受信・送信どちらで開けるべきか
- 結局のところは下記のDocsに記載がある
- サービスタグについて確認するときに何度も訪れるページ
次の表は、各サービス タグがこのようなリージョン スコープをサポートしているかどうかを示し、各タグで示されている方向は推奨事項です。 たとえば、AzureCloud タグを使用して受信トラフィックを許可することができます。
(方向についても記載あったんだ、、、という感じ)
※一部抜粋
| タグ | 受信または送信で使用できるか |
|---|---|
| AzureCloud | 両方 |
| AzureBackup | 送信 |
| AzureMonitor | 送信 |
| AzureSentinel | 受信 |
-
なので、基本はこの表に載っている方向に従って設定すればOK（大体の場合は送信方向の許可で済む）
- つまり、VMやクライアント側からPaaSへの通信を開始するパターンが殆ど
-
ただこの表には罠があって、送信/受信の片側しか記載がなくてもNSG上は逆側も設定できてしまう
-
実際にNSGでAzureBackupの受信ルールを設定できた
- この場合、AzureBackupの受信ルールだけでAzureBackupが機能するかはCustomer Riskの問題で、利用前に要検証
- ただ、サービスタグによってはエラーで設定できないものもあるらしい(真偽不明)
-
また、引用部分にもあるが、設定できるからといって不用意に特定サービスタグのインバウンド許可ルールを作成しないほうが良いのは明白
おわり
- ちなみに、Azure Firewallのネットワーク規則においてもサービスタグを利用することができるがTarget側でしか利用できない
- このことからも、Azure PaaSの利用には基本送信側でのルールを作っておけばよさそう
- Azure FirewallではSourceにサービスタグが使えないので、IPで設定する必要が出てくる
- その場合は、PaaSのIPアドレスが変更される可能性があるため(Maxで1週間ごと),それを検知する仕組みが必要になってくる
GitHubで編集を提案
Discussion