Azure PaaSサービスを安全に使いたいと考えた時、Private Endpointを検討するのはよくあると思います。ただ、Private Endpointは存在していると時間単位で課金されていったり、開発のアジリティに影響が出るため、テスト用やシンプルなファイル共有にはハードルが少し高い場合があります。よって、PaaSを普通にPaaSとして使う(自分でも何を言っているのか、、、)需要ももちろんあります。その際の最小限の穴あけについて挙動の確認をしました。
前提条件として、PaaSにアクセスするVMのSubnetにはデフォルトルートを仮想アプライアンスに向けるような設定がされているとします。
穴あけ
L3/L4レベルでの穴あけが必要です。
NSG
- NSGはデフォルトでは送信規則が実質なにも設定されていない
- 自由に外部アクセスさせたくない環境には送信規則でInternet拒否のルールが必要
- PaaSを利用する場合には、Internet拒否ルールより上位のルールとして、サービスタグで許可ルールを追加する
- 検証環境のイメージはコチラ
- ※後の検証を分かり易くするためInternet拒否のルールは一旦無し
ルーティング
前提条件で示した通り、想定環境はデフォルトルートが仮想アプライアンスやオンプレを向いているとします。NSGの送信ルールで穴あけをしたところで、トラフィックがそうしたアプライアンスを経由することとなるため、そこで許可されていなければPaaSに到達できません。
また、PaaSへの接続許可については、アプライアンス上でのルールの管理が煩雑になります(PaaSのIPが可変であるため)。そこでAzure環境としてはUDRを利用します。
UDR
- UDRはサービスタグも指定可能
- NSGで許可した宛先のPaaSに対してネクストホップをInternetで指定することで、バックボーン経由での通信とする
- 検証環境では、デフォルトルートはネクストホップなし、とすることで疎通確認を簡素化した
- PaaSへのアクセスがUDRに則っていなければトラフィックがドロップされる
- デフォルトルートはロンゲストマッチに従い必ず最後に評価されます
疎通確認
- デフォルトルートのネクストホップをなしに設定するとその影響下のVMに対してRDPができない(レスポンスがドロップされる)ため、手間ではあるが踏み台用VMを用意。Bastionでもよかった。
- 接続先のPaaSとしてストレージアカウントを作成し、Azure Filesに適当にファイルを置いておく
- 踏み台VMからテスト用VMにRDP接続し、テスト用VM上にてAzure Filesをマウントする
- ファイルを置いたり消したりしながらきちんと動くことを確認
- また、Azure Files以外のパブリックIPに対してブラウザ等からアクセスを試み、到達できないことを確認
Service Endpoint
- ちなみにサービスエンドポイント(PaaS上でのサブネット許可ルール)を利用する場合は、PaaSへのルートテーブルが対象のSubnetに対して自動で追加されるため、UDRの許可が不要だったりします。
- 試しに、今回作成したルートテーブルでStorege.EastAsiaのルートを削除し、ストレージアカウント側からサービスエンドポイントを追加します。
- この状態で、Azure Filesへのアクセス確認を行うと問題なく動くことが確認できます。
おわり
- PaaSをPaaSとして使うって、変な表現だ
GitHubで編集を提案
Discussion