🙌

[Az-700学習メモ] Azure サービスへのプライベート アクセスの設計と実装

2023/01/14に公開約2,600字

学習資材

https://learn.microsoft.com/ja-jp/training/modules/design-implement-private-access-to-azure-services/

サービスエンドポイント

  • インターネットに出ないだけで、パブリックIPを利用する。
    漠然と記憶はしていたが、パブリックIPを利用したアクセスになることに注意。ただし、インターネット経由ではなく、Azureバックボーン経由になるのが、通常のアクセスとは異なる点である。
    経路としてのパブリックアクセスはOFFになるが、口としてのパブリックIPは残る感じになる。

  • 特定のAzure サービスへのアクセスに絞ることができない。
    プライベートリンクとは異なり、上記が制約として出てくるだろう。例えば、Storage Accoutのサービスエンドポイントが存在したとする。任意のストレージアカウントにアクセスが可能になるため、例えば自作したリソースに対してもアクセス可能になる。情報漏洩のリスクは存在する。

そのため、基本的にはプライベートエンドポイントの利用が推奨されている。

注意
Azure プラットフォームでホストされるサービスに対して、セキュリティで保護されたプライベートなアクセスを行うには、Azure Private Link の使用をお勧めします。

プライベートリンクサービス

自社所有のサービスと、顧客所有のサービスとをプライベートで通信するためのサービスだが、前提条件として何がクリアになっていれば利用できるのだろうか?
(同じサブスクリプション?リージョンは別でも大丈夫?)

プライベートエンドポイントとDNSの関係性

  • オンプレからプライベートDNSゾーンにアクセスするとき
    Azure が提供するDNSサーバにアクセスして名前解決を行うにはAzure内部からの通信のみしか受けていない。そのため、オンプレから名前解決を行うためには、Vnet内にDNSフォワーダ(VM)を作成し、オンプレ → DNSフォワーダ → Azure提供DNSサーバという経路でアクセスするしかない。以下は概要図

  • 168.63.129.16とは

DNS サーバーを明示的に指定していない環境における、既定の DNS リゾルバー

なるほどてっきり、DNSゾーンのことだと思っていたが、Azure既定のDNSリゾルバ**的な立ち位置になるのだろう。
https://jpaztech1.z11.web.core.windows.net/IPアドレス168.63.129.16について.html

パブリックDNSとプライベートDNSとDNSリゾルバーの関係

プライベートDNSゾーン:Azure Vnet内からの名前解決で使われる。
パブリックDNSゾーン:インタネート経由で名前解決で使われる。例えば、ドメインを公開してホストしておくことで、WEBサーバの名前解決などで用いられる。
DNSリゾルバー:DNSサーバへ問合せを行ってくれるソフトウェアのこと。

そう、DNSゾーンはあくまで、自身の担当分のレコードを保持しているだけで、積極的に情報をくれるわけではないのだ。そのため、リゾルバーのような主体的に問い合わせを行ってくれる存在が必要になる。

Vnet統合について

主に、AppService・Functions・Logic Appsにてサポートされる。Vnet統合を行うには、専用のサブネットが必要になる。

  • 調べる前のイメージ:対象リソースをVnetに存在するものと扱い、Vnet内の他リソースとのプライベートな送受信ができるもの。

  • 調べた後のイメージ:厳密には対象リソースから送信方向の通信を、仮想ネットワーク内にルーティングさせる機能である。これによって、本来インターネットに公開されていないVnet内のリソースにアクセスさせることができる。エンドポイント経由でしかアクセスできないリソース(DBとか)が存在する場合は利用されるだろう。
    参考:
    https://learn.microsoft.com/ja-jp/azure/virtual-network/vnet-integration-for-azure-services
    https://ascii.jp/elem/000/004/059/4059866/

  • リージョンVnet統合とゲートウェイが必要なVnet統合
    Vnet統合にも2種類の方式が存在する。両者の違いとしては、リージョンVnet統合はVnet統合元のサービス(AppServiceとか)とVnetが同一リージョンに存在するときに使われる。専用のサブネットは必要になる。
    ゲートウェイが必要なVnet統合は、リージョンが異なるときに利用する。専用のサブネットは不要の一方で、Vnet側に仮想ネットワークゲートウェイが必要になる点が注意。(仮想ネットワークゲートウェイには専用のサブネットが必要にはなる)

参考
https://cloudsteady.jp/post/47596/
https://cloudsteady.jp/post/43767/

  • Vnet統合時の通信制御について
    NSGやルートテーブルを使った制御が可能。ただし、送信の規則だけになる。受信の制御は各サービスの持つアクセス制御で実装する必要がある。
    AppServiceの場合は、WEBSITE_VNET_ROUTE_ALLを『1』に設定する必要があるらしい。
    DNSプライベートゾーン利用の場合は、上記に加えてWEBSITE_DNS_SERVERに『168.63.129.16』を設定する必要がある。この辺は、実際に使う時に追々確認するとしよう。

Discussion

ログインするとコメントできます