注意点
2021/10/6時点の情報です
はじめに
Purviewのネットワークアクセス制御を理解するためにいろいろ動かした備忘録です。
参考
https://docs.microsoft.com/en-us/azure/purview/catalog-private-link-faqs
https://docs.microsoft.com/en-us/azure/purview/catalog-private-link
結論
いくつかのパターンで、それぞれの動作を確認したところ、以下の整理となった。
- ファイアウォールによる、パブリックネットワークアクセス拒否→インジェストプライベートエンドポイントが必要となる。
- 参考のリンクでは、パブリックネットワークアクセス許可の動作がいまいちわかりにくかったがはっきりした。マネージドストレージとEvent Hubsが閉域化するとは書いてあるが、Accountにもきっちりアクセスできなくなる。
- 注意しないといけないのは、パブリックネットワークアクセス許可をオフにして、アカウントとポータルのエンドポイントは構成して、インジェストエンドポイントを構成しない状態。これはスキャンができず、カタログ自体にはアクセスできる謎サービスとなる（手動でカタログ情報作れるかはためしていない
- ポータル、アカウントのPrivate Endpointは同じDNSゾーンを使うので、名前解決の方式にもよるが、基本的にセットでデプロイする（SynapseのようにWebエンドポイントは設置しない、という方式はとらない
- バランスがよさそうなのは、パブリックネットワークアクセス許可して、インジェストエンドポイントも利用する。
- →SHIRからはインジェストエンドポイントが利用されるため、スキャン情報はproxyの例外としてインジェストエンドポイントを指定すればインターネット越しとならないが、Azure IRは併用可能
- ただし、インターネット越しにPurviewのカタログなどが見えるようになるため、これを気にする場合には不適。Azure IRが使えなくなることによるスケーラビリティの欠如とバランスをとる必要がある。
- →SHIRからはインジェストエンドポイントが利用されるため、スキャン情報はproxyの例外としてインジェストエンドポイントを指定すればインターネット越しとならないが、Azure IRは併用可能
- 試して気づいたが、SHIRを利用＝パブリックネットワークアクセス許可をオフにすると、MSIによるデータソーススキャンができない（AKVでサービスプリンシパルなど情報を入れないといけない）ため、キー管理が必要となる
結果詳細
- シナリオ 1 - ご利用の Azure Purview に接続して、プライベートかつ安全にデータ ソースをスキャンする
- account、portalのプライベートエンドポイントを設置
- シナリオ 2 - ご利用の Purview アカウントにプライベートかつ安全に接続する
- account、portal、ingestのプライベートエンドポイントを設置
これらに対して、パブリックネットワークアクセス許可を組み合わせて検証した。
なお、スキャン対象にはファイアウォールをかけておらず、Azure IRが成功したらSHIRは試していない（ハイフンの結果）。
シナリオ 1 ＋パブリック許可
設定
| パブリックネットワークアクセス許可 | accountのプライベートエンドポイント | portalのプライベートエンドポイント | インジェストプライベートエンドポイント |
|---|---|---|---|
| 〇 | 〇 | 〇 | × |
結果
| ユースケース | アクセス元条件 | 結果 |
|---|---|---|
| Studio利用 | Vnet外 | OK |
| Studio利用 | Vnet内 | OK |
| スキャン（パブリックリソース） | Azure IR | OK |
| スキャン（パブリックリソース） | SHIR | - |
シナリオ 1 ＋パブリック不許可
設定
| パブリックネットワークアクセス許可 | accountのプライベートエンドポイント | portalのプライベートエンドポイント | インジェストプライベートエンドポイント |
|---|---|---|---|
| × | 〇 | 〇 | × |
結果
| ユースケース | アクセス元条件 | 結果 |
|---|---|---|
| Studio利用 | Vnet外 | NG |
| Studio利用 | Vnet内 | OK |
| スキャン（パブリックリソース） | Azure IR | NG |
| スキャン（パブリックリソース） | SHIR | NG |
シナリオ 2 ＋パブリック許可
設定
| パブリックネットワークアクセス許可 | accountのプライベートエンドポイント | portalのプライベートエンドポイント | インジェストプライベートエンドポイント |
|---|---|---|---|
| 〇 | 〇 | 〇 | 〇 |
結果
| ユースケース | アクセス元条件 | 結果 |
|---|---|---|
| Studio利用 | Vnet外 | OK |
| Studio利用 | Vnet内 | OK |
| スキャン（パブリックリソース） | Azure IR | OK |
| スキャン（パブリックリソース） | SHIR | - |
シナリオ 2 ＋パブリック不許可
設定
| パブリックネットワークアクセス許可 | accountのプライベートエンドポイント | portalのプライベートエンドポイント | インジェストプライベートエンドポイント |
|---|---|---|---|
| × | 〇 | 〇 | 〇 |
結果
| ユースケース | アクセス元条件 | 結果 |
|---|---|---|
| Studio利用 | Vnet外 | NG |
| Studio利用 | Vnet内 | OK |
| スキャン（パブリックリソース） | Azure IR | NG |
| スキャン（パブリックリソース） | SHIR | OK |
おまけ
synapseのようにwebプライベートエンドポイントは不要なのかと思ったが、DNSZoneが同一であるため、accout側のプライベートエンドポイントを作成したら同じoneで解決が必要なPortalにもプライベートエンドポイントが必要だった
設定
| パブリックネットワークアクセス許可 | accountのプライベートエンドポイント | portalのプライベートエンドポイント | インジェストプライベートエンドポイント |
|---|---|---|---|
| 〇 | 〇 | × | × |
結果
| ユースケース | アクセス元条件 | 結果 |
|---|---|---|
| Studio利用 | Vnet外 | OK |
| Studio利用 | Vnet内（DNSゾーンとリンク） | NG |
| スキャン（パブリックリソース） | Azure IR | - |
| スキャン（パブリックリソース） | SHIR | - |