はじめに
Microsoft Purview アカウントを閉域でアクセスするよう以下のような構成を行っている場合に、 Purview ポータル(クラシック・新しいポータル両方)でデータカタログにアクセスできない問題が発生したので、解決方法を共有します。
Microsoft Purview アカウント
- ファイアウォールの設定でパブリックのアクセスを無効にしている
- Account もしくは Platform Private Endpoint を作成して、仮想ネットワーク内から Purview アカウントにアクセスできるよう設定している
- 【クラシックポータルを使っている方】
- 名前解決: nslookup [purview_account].purview.azure.com で正しい プライベート IP が表示される
- Test-NetConnection [purview_account].purview.azure.com -Port 443 -InformationLevel Detailed が Success で応答する
- 【新しいポータルを使っている方】
- nslookup [tenantId]-api.purview-service.microsoft.com で正しい プライベート IP が表示される
- Test-NetConnection [tenantId]-api.purview-service.microsoft.com -Port 443 -InformationLevel Detailed が Success で応答する
- REST API は通常通りリクエストが処理される
その他
- Private Endpoint が配置されている仮想ネットワーク上に作成した Azure VM から Purview にアクセスする
- DNS については Azure 提供の DNS を使用している
事象
Azure VM 等で閉域内からデータカタログにアクセスするとこのようにエラーの通知が発生します。
ホーム画面以外のページに遷移すると、下図のようなエラーでデータカタログにアクセスできません。
新しいポータルからアクセスしようとしても同様で、こちらはネットワークエラーと出ていました。
それぞれ Test-NetConnection を実行してみると、問題なく通信ができていることが確認できています。
クラシックポータル
新しいポータル
解決方法
結論としてはブラウザの Local Network Access (LNA) 設定が原因でした。
永続的な対処と一時的な対処で2通りの方法があるのでそれぞれ紹介します。
１. Portal Private Endpoint を作成する(こちらの方がおすすめ)
クラシックポータル、新ポータル関わらず Portal Private Endpoint を作成してPurviewポータルごと閉域でアクセスするように設定すれば解決します。
複数の Purview アカウントが同一テナント内で運用されている場合は、他の Purview アカウント運用に影響が無いか確認してから作成しましょう。
エンタープライズバージョンにアップグレードしている(新しい Purview を使っている)場合は、Portal Private Endpoint を作成すると新ポータルからデータガバナンスソリューションに対してパブリックアクセスができなくなります。
ただし、秘密度ラベル等の M365 系ソリューションは問題なくパブリックアクセスできますので大丈夫です。
２. ブラウザの設定を変更する
ブラウザの LNA 設定を無効にすることで、一時的に対応することが可能です。
使用しているブラウザに合わせて、下記をURLバーに入力して設定画面に遷移してください。
edge://flags/#local-network-access-check
chrome://flags#local-network-access-check
遷移したら Local Network Access Checks という項目が一番上に出てくるので、値を"Disabled"に切り替えてください。(切り替えるとブラウザが再起動します)
LNA 機能自体はブラウザのセキュリティ対策機能の一つなので、この手法で永続的に対処することはあまりおすすめできません。
補足
類似事象として、 Key Vault や Storage でも LNA 設定が原因の問題がありますが、こちらと異なり Purview では LNA 設定を有効にしても事象が解決しません。
どうしてこんな事象が発生するの？
新旧の Purview ポータルからデータカタログにアクセスすると、LNA 機能によってバックエンドAPI(catalog.prod.ext.web.purview.azure.com)へのリクエストがブロックされてしまいエラーが発生するようです。
開発者ツールで通信を覗いてみると、それぞれディレクトリ違いで同じエンドポイント宛に送っているリクエストなのにリクエストが正常に返答されているものとされていないものがあることが分かると思います。(それぞれページのオリジンが違うため成否が分かれている)
コンソールタブを開くと、こんな感じで CROS ポリシーに引っ掛かっているエラー表示が大量に見えると思います。
バックエンドAPIのエンドポイントに対する閉域アクセスは Portal Private Endpoint でカバーされているため、新ポータルでも Portal Private Endpoint を作成することで事象が解消されるという理屈です。
まとめ
今後のアップデートにより解消されるかもしれないですが、新ポータルの場合は Portal Private Endpoint も一緒に作ってしまうのが一番分かりやすそうです。
MS の QA にもこの事象と解決方法が回答されていましたが、このページだけだと問題の根本までは解説されていなかったので、 Portal Private Endpoint を作るだけで解決できる理屈も含めてまとめてみました。