WEBVTT

00:00:00.000 --> 00:00:07.640
マイクロソフト365、コパイロット、AI、Azure、そして未来の働き方を形作る人々が集う10日間、準備はいいですか?

00:00:07.800 --> 00:00:12.260
今年の1月、M365コンがさらにパワーアップして帰ってきます。

00:00:12.500 --> 00:00:18.360
世界中のMVPや業界エキスパートによるライブセッション、実演でも実践的な知識を体験しましょう。

00:00:18.580 --> 00:00:21.920
ありきたりなスライドや、終わりのない専門用語の羅列はありません。

00:00:22.080 --> 00:00:29.200
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に取り組みます。

00:00:29.200 --> 00:00:35.120
ITプロフェッショナル、開発者、ビジネスリーダーなど、それぞれの役割に合わせたセッションをご用意しています。

00:00:35.300 --> 00:00:40.440
10日間にわたり、様々な技術を学び、世界中のコミュニティとつながることができます。

00:00:40.660 --> 00:00:44.680
ライブ視聴で得た実践的な洞察を、ぜひ組織に持ち帰ってください。

00:00:45.060 --> 00:00:51.140
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付を開始しました。

00:00:51.380 --> 00:00:55.960
m365コン.NETにアクセスして、今すぐ座席を確保しましょう。

00:00:55.960 --> 00:00:59.840
繰り返しになりますが、m365コン.NETです。

00:01:00.000 --> 00:01:04.960
m365コン.NETから参加して、1月のライブでお会いしましょう。

00:01:05.160 --> 00:01:09.040
M365FMのマイクロソフトナレッジナゲットへようこそ。

00:01:09.160 --> 00:01:10.500
ホストのミルコピロッチです。

00:01:10.660 --> 00:01:14.400
今日のトピックは、誰もが一度は耳にしたことがあるものの、明確に説明できる人が少ないものです。

00:01:14.540 --> 00:01:16.160
Azureプライベートリンクについてです。

00:01:16.340 --> 00:01:21.840
ストレージアカウントやSQLデータベースの設定時に見かけるオプションですが、実際には何をするものなのか、本当に必要なのでしょうか。

00:01:21.840 --> 00:01:23.720
多くの人が誤解している点があります。

00:01:23.940 --> 00:01:29.720
Azure内で実行されているサービスは自動的にプライベートであり、デフォルトでインターネットから遮断されていると思い込んでいることです。

00:01:29.900 --> 00:01:32.400
それは間違いであり、全くの事実ではありません。

00:01:32.560 --> 00:01:38.440
ほとんどのAzureパースサービス、ストレージSQL、キーハウルトなどは、最初からパブリックエンドポイントを備えています。

00:01:38.620 --> 00:01:43.460
つまり、正しいURLと資格情報さえあれば、インターネット上の誰でもアクセスできるということです。

00:01:43.460 --> 00:01:50.380
このエピソードの終わりには、プライベートリンクの正体、その存在理由、そしてトラフィックをパブリックインターネットから守る仕組みが理解できるはずです。

00:01:50.520 --> 00:01:52.580
分かりやすい例え話で詳しく解説します。

00:01:52.780 --> 00:01:57.960
マーケティング的な誇張や専門用語は抜きにして、従来の手法であるパブリックエンドポイントがどこにでも存在していた状況を説明します。

00:01:58.140 --> 00:01:59.780
まずは問題点から始めましょう。

00:01:59.980 --> 00:02:04.600
プライベートリンクが登場する前は、全てのAzureパースサービスにデフォルトでパブリックエンドポイントが付与されていました。

00:02:04.600 --> 00:02:10.180
ストレージアカウントを作成すると、Azureはミストラギアカウント、ブロブ、コア、Windows.netのようなURLを発行します。

00:02:10.360 --> 00:02:12.600
そのURLはパブリックIPアドレスに解決されます。

00:02:12.760 --> 00:02:15.580
インターネットに接続できる人なら誰でも、そこへ接続を試みることができてしまいます。

00:02:15.740 --> 00:02:19.000
さて、自身のAzure仮想ネットワーク内で仮想マシンを動かしていると想像してください。

00:02:19.180 --> 00:02:21.880
その仮想マシンが、ブロブストレージからファイルを読み取る必要があるとします。

00:02:22.040 --> 00:02:24.080
トラフィックはAzure内部に留まると思いますよね。

00:02:24.080 --> 00:02:26.200
どちらのリソースも同じクラウド内にあるのですから。

00:02:34.600 --> 00:02:39.140
これは、オフィスビルの一室にいて、同じ建物内にある備品室へ物を取りに行くようなものです。

00:02:39.300 --> 00:02:44.000
しかし、廊下を歩いていく代わりに、一度外に出て、建物の周りを一周し、別のドアから入り直さなければならないのです。

00:02:44.120 --> 00:02:46.460
これでは意味がありませんが、まさにそれが起こっていたことなのです。

00:02:46.620 --> 00:02:47.920
これは深刻な問題です。

00:02:48.100 --> 00:02:53.000
両方のリソースがマイクロソフトのデータセンター内にあるにも関わらず、データはパブリックインターネットを経由して移動しています。

00:02:53.080 --> 00:02:56.700
通信は暗号化されていますが、それでも開かれたインターネットにさらされています。

00:02:56.920 --> 00:03:00.020
それは、あなたが制御できないルーターやスイッチを通過しているのです。

00:03:00.180 --> 00:03:03.760
もし誰かがその通信を防止できれば、あなたが送っている内容を見られてしまう可能性があります。

00:03:03.960 --> 00:03:05.340
ここにはよくある誤解があります。

00:03:05.580 --> 00:03:08.680
多くの人が、自分のサブスクリプション内にあるのだから、プライベートだと考えています。

00:03:08.880 --> 00:03:10.020
仕組みはそうではありません。

00:03:10.220 --> 00:03:13.260
サブスクリプションは課金と管理の境界であり、ネットワークの境界ではないのです。

00:03:13.260 --> 00:03:16.500
デフォルトでは、Azureサービスはインターネットから到達可能な状態にあります。

00:03:16.740 --> 00:03:21.540
それらを守っているのは、認証と認可のレイヤー、キー、パスワード、ファイアウォールルールだけです。

00:03:21.720 --> 00:03:23.740
しかし、ネットワーク経路そのものはパブリックなのです。

00:03:23.860 --> 00:03:26.580
そこで、マイクロソフトはこれを見て、もっと良い方法があるはずだと考えました。

00:03:26.740 --> 00:03:28.040
そして彼らはそれを作り上げました。

00:03:28.240 --> 00:03:29.480
それがプライベートリンクです。

00:03:29.660 --> 00:03:32.880
その解決策が、ネットワークインターフェースカードとしてのプライベートエンドポイントです。

00:03:32.880 --> 00:03:37.600
プライベートリンクは全体的なサービスですが、理解すべき中心はプライベートエンドポイントです。

00:03:37.600 --> 00:03:44.220
これは、仮想ネットワーク内に存在し、パースサービスに接続する仮想ネットワークインターフェースカード、NIC、です。

00:03:44.460 --> 00:03:45.420
仕組みはこうです。

00:03:45.620 --> 00:03:48.480
ストレージアカウント用にプライベートエンドポイントを作成すると、

00:03:48.740 --> 00:03:53.380
Azureは仮想ネットワーク内にサブネットのプライベートIPを持つ仮想NICを構築します。

00:03:53.500 --> 00:03:58.020
そのNICは、バックエンドのプライベートリンクを通じてストレージアカウントに接続されます。

00:03:58.180 --> 00:04:02.020
そのため、VMの視点からは、ストレージアカウントが他のリソースと同じように、

00:04:02.020 --> 00:04:05.520
プライベートIPを持って自身のネットワーク内に存在しているように見えます。

00:04:05.680 --> 00:04:10.280
VMがストレージアカウントへ通信を送る際、その通信はNICのプライベートIPに到達し、

00:04:10.540 --> 00:04:13.840
パブリックインターネットではなく、マイクロソフトのバックボーンネットワークを経由します。

00:04:14.000 --> 00:04:16.600
Azureの内部インフラストラクチャから外に出ることはありません。

00:04:16.760 --> 00:04:19.260
オフィスビルの安全な廊下のようなものだと考えてください。

00:04:19.460 --> 00:04:23.460
外に出て建物の周りを歩く代わりに、ただ廊下を歩いて備品室に入るだけです。

00:04:23.600 --> 00:04:25.760
直通接続であり、遠回りは不要です。

00:04:25.900 --> 00:04:28.360
さて、ここで多くの人が見落としがちな微妙な点があります。

00:04:28.540 --> 00:04:32.240
プライベートエンドポイントを有効にしても、パブリックエンドポイントは自動的に無効になりません。

00:04:32.420 --> 00:04:34.220
両者は同時に存在することができます。

00:04:34.400 --> 00:04:37.220
プライベートエンドポイントを作成してもパブリック設定を変更しなければ、

00:04:37.500 --> 00:04:39.640
ストレージアカウントはインターネットからアクセス可能なままです。

00:04:39.760 --> 00:04:42.980
完全に遮断するには、パブリックネットワークアクセスを明示的に無効にする必要があります。

00:04:43.180 --> 00:04:45.860
多くの人は、プライベートエンドポイントを作成するだけで十分だと考えています。

00:04:46.020 --> 00:04:46.780
そうではありません。

00:04:46.780 --> 00:04:49.580
Azureに対して、プライベートアクセスのみを許可するよう指示する必要があります。

00:04:49.720 --> 00:04:51.640
ついでに、もう一つの誤解も解いておきましょう。

00:04:51.780 --> 00:04:54.380
プライベートリンクはVPNやExpressRouteとは異なります。

00:04:54.560 --> 00:04:57.800
これらは異なる問題を解決するものであり、比較については後ほど説明します。

00:04:57.960 --> 00:05:00.700
今のところは、プライベートリンクとはネットワーク全体を接続するのではなく、

00:05:01.020 --> 00:05:03.060
特定のサービスにアクセスするためのものだと理解しておいてください。

00:05:03.200 --> 00:05:04.820
さて、プライベートエンドポイントを作成し、

00:05:05.020 --> 00:05:07.580
VMからプライベートIP経由でストレージアカウントに到達できるようになりました。

00:05:07.720 --> 00:05:10.480
しかし、VMは実際にどのようにしてそのストレージアカウントを見つけるのでしょうか?

00:05:10.560 --> 00:05:13.100
以前は、パブリックURLを解決してパブリックIPを取得していました。

00:05:13.280 --> 00:05:14.660
現在はプライベートIPが必要です。

00:05:14.800 --> 00:05:16.080
それはどのように機能するのでしょうか?

00:05:16.180 --> 00:05:17.640
そこで登場するのがDNSです。

00:05:17.800 --> 00:05:19.200
次にそれを見ていきましょう。

00:05:19.400 --> 00:05:22.040
DNSこそが、すべてを機能させる秘密のソースです。

00:05:22.040 --> 00:05:23.680
プライベートエンドポイントが作成され、

00:05:23.880 --> 00:05:26.560
VMはプライベートIP経由でストレージアカウントに到達できます。

00:05:26.740 --> 00:05:29.760
しかし重要な点は、VMはそのIPを知らないということです。

00:05:29.880 --> 00:05:33.520
VMが知っているのは、例えば、ミストラギアカウントのようなストレージアカウントのURLだけです。

00:05:33.660 --> 00:05:35.360
ブログ、コア、Windows.netです。

00:05:35.540 --> 00:05:36.980
それが接続に使用する名前です。

00:05:37.120 --> 00:05:39.820
では、どのようにしてパブリックIPではなくプライベートIPを見つけるのでしょうか?

00:05:39.900 --> 00:05:41.960
ここでDNSが重要な役割を果たします。

00:05:41.960 --> 00:05:43.640
プライベートエンドポイントを作成し、

00:05:43.920 --> 00:05:46.580
推奨されるプライベートDNSゾーンとの統合を選択すると、

00:05:46.860 --> 00:05:48.400
Azureが自動的にゾーンを作成します。

00:05:48.560 --> 00:05:51.820
ブログストレージアカウントの場合、そのゾーンはプライバテリンクと呼ばれます。

00:05:52.000 --> 00:05:54.020
ブログ、コア、Windows.netです。

00:05:59.760 --> 00:06:00.500
巧妙な部分です。

00:06:00.660 --> 00:06:02.540
元のパブリックURLは解決されますが、

00:06:02.820 --> 00:06:07.060
直接パブリックIPを返す代わりに、プライベートゾーンを指すCNAMEレコードを返します。

00:06:07.240 --> 00:06:09.040
解決の連鎖は以下のようになります。

00:06:09.220 --> 00:06:11.380
VMがストレージアカウントのURLを要求すると、

00:06:11.500 --> 00:06:14.640
DNSはミストラギアカウントを指すCNAMEを返します。

00:06:14.760 --> 00:06:18.700
これは仮想ネットワークにリンクされたプライベートDNSゾーン内に存在するプライバテリンク、

00:06:19.180 --> 00:06:21.040
ブログ、コア、Windows.netです。

00:06:21.200 --> 00:06:23.260
DNSはそれをプライベートIPに解決し、

00:06:23.520 --> 00:06:25.420
VMはそのプライベートIPに接続するため、

00:06:25.700 --> 00:06:27.500
トラフィックは公衆インターネットに一切触れません。

00:06:27.660 --> 00:06:29.680
オフィスビルの受付を想像してみてください。

00:06:29.940 --> 00:06:31.840
誰かが入ってきて備品室の場所を聞いたとき、

00:06:32.160 --> 00:06:33.960
受付係はその人を外に出したりしません。

00:06:34.120 --> 00:06:36.280
建物内の正しい廊下を教えてくれるのです。

00:06:36.440 --> 00:06:38.700
プライベートDNSゾーンは建物から外に出ることなく、

00:06:39.000 --> 00:06:41.200
トラフィックを適切な場所へ誘導する受付係のようなものです。

00:06:41.340 --> 00:06:43.980
この仕組みがどう働くかは、VMがどこにあるかによって決まります。

00:06:43.980 --> 00:06:46.380
プライベートエンドポイントと同じ仮想ネットワーク内にある場合、

00:06:46.600 --> 00:06:49.500
プライベートDNSゾーンがリンクされるため、解決は自動的に行われます。

00:06:49.620 --> 00:06:51.140
ピアリングされたネットワークにある場合は、

00:06:51.380 --> 00:06:53.200
そのネットワークにもゾーンをリンクする必要があります。

00:06:53.420 --> 00:06:56.980
VPNやエクスプレスルートを介したオンプレミスのマシンの場合は少し手間がかかります。

00:06:57.180 --> 00:06:58.780
通常はDNSフォワーダーを設定するか、

00:06:59.000 --> 00:07:00.580
Azure DNS Private Resolverを使用して、

00:07:00.780 --> 00:07:02.500
クエリが確実にプライベートゾーンに到達するようにします。

00:07:02.660 --> 00:07:04.700
しかし、Azure内部のほとんどのシナリオでは、

00:07:04.920 --> 00:07:06.500
基本部分は自動的に処理されます。

00:07:06.500 --> 00:07:08.860
大規模な環境ではDNSは複雑になりがちですが、

00:07:09.080 --> 00:07:12.760
標準的なケース、つまりプライベートエンドポイントと同じ仮想ネットワークにあるVMであれば、

00:07:13.020 --> 00:07:14.340
Azureが自動的に処理してくれます。

00:07:14.520 --> 00:07:16.020
何も触る必要はありません。

00:07:16.220 --> 00:07:18.220
実際の例で、その動作を見てみましょう。

00:07:18.440 --> 00:07:19.820
実世界でのオークスルーです。

00:07:19.980 --> 00:07:21.680
Azure Storageでのプライベートリンク。

00:07:21.860 --> 00:07:23.160
具体的に見ていきましょう。

00:07:23.340 --> 00:07:26.340
Azure仮想ネットワーク内で仮想マシンが実行されているとします。

00:07:26.560 --> 00:07:29.980
そのVMは、Azure Blob Storageアカウントからファイルを取得する必要があります。

00:07:30.200 --> 00:07:31.320
よくある構成です。

00:07:31.480 --> 00:07:33.120
ユーザーのアップロードを保存するアプリや、

00:07:33.400 --> 00:07:35.540
コンテナーから読み取るデータ処理ジョブなどが考えられます。

00:07:35.680 --> 00:07:37.900
プライベートリンクがない場合、どうなるでしょうか。

00:07:38.020 --> 00:07:40.380
VMがストレージアカウントのパブリックURLを検索し、

00:07:40.600 --> 00:07:41.920
パブリックIPアドレスを取得します。

00:07:42.080 --> 00:07:44.980
トラフィックは仮想ネットワークから出てパブリックインターネットを経由し、

00:07:45.260 --> 00:07:47.520
再びAzureに戻ってストレージアカウントに到達します。

00:07:47.700 --> 00:07:49.200
この往復は不要なものです。

00:07:49.380 --> 00:07:50.960
どちらのリソースもAzure内にありますが、

00:07:51.220 --> 00:07:53.740
データはいずれにせよパブリックインターネットを経由する回り道をします。

00:07:53.920 --> 00:07:55.080
プライベートリンクを使用すると、

00:07:55.280 --> 00:07:58.260
ストレージアカウントのブロブサブリソースに対してプライベートエンドポイントをデプロイします。

00:07:58.420 --> 00:08:00.680
これがブロブデータを扱う具体的な部分です。

00:08:00.680 --> 00:08:04.220
Azureは仮想ネットワーク内にプライベートIPを持つ仮想NICを作成し、

00:08:04.480 --> 00:08:06.020
プライベートDNSゾーンを設定します。

00:08:06.180 --> 00:08:09.220
すると、先ほど説明したDNS解決の連鎖が始まります。

00:08:09.400 --> 00:08:10.700
今度はVMが同じURL、

00:08:10.880 --> 00:08:13.800
mistragiaccount.blog.coa.windows.netを解決すると、

00:08:13.800 --> 00:08:15.880
パブリックIPではなくプライベートIPが返されます。

00:08:16.000 --> 00:08:18.500
トラフィックはVMからプライベートエンドポイントへ、

00:08:18.820 --> 00:08:22.240
そしてマイクロソフトのバックボーンを経由してストレージアカウントへ流れます。

00:08:22.440 --> 00:08:24.520
Azureの内部ネットワークから出ることはありません。

00:08:24.520 --> 00:08:26.020
ここが重要なポイントです。

00:08:26.160 --> 00:08:27.820
アプリケーションは変更する必要がありません。

00:08:28.000 --> 00:08:30.480
接続文字列の修正も構成ファイルの更新も不要です。

00:08:30.660 --> 00:08:31.880
URLはそのままです。

00:08:32.060 --> 00:08:34.780
変わるのは、そのURLがどのように解決されるかという点だけです。

00:08:34.920 --> 00:08:38.280
アプリの観点からは、依然として同じストレージアカウントに接続していますが、

00:08:38.540 --> 00:08:40.440
裏側ではトラフィックの経路が全く異なっています。

00:08:40.660 --> 00:08:44.080
さらに徹底したい場合はパブリックエンドポイントを完全に無効にすることも可能です。

00:08:44.240 --> 00:08:47.520
つまり、ストレージアカウントにはプライベートエンドポイント経由でしかアクセスできなくなります。

00:08:47.680 --> 00:08:49.280
インターネットへの露出はゼロになります。

00:08:49.360 --> 00:08:51.540
外部から接続を試みることさえ誰にもできません。

00:08:51.680 --> 00:08:53.220
もう一つ注目すべき点があります。

00:08:53.400 --> 00:08:55.420
ストレージアカウントには複数のサブソースがあります。

00:08:55.640 --> 00:08:57.940
ブロブが一つですが、ファイル、テーブル、クエウェもあります。

00:08:58.200 --> 00:09:00.160
それぞれに独自のプライベートエンドポイントを設定できます。

00:09:00.360 --> 00:09:03.180
ブロブトラフィック用に一つ、ファイルトラフィック用に別のエンドポイントを用意できます。

00:09:03.380 --> 00:09:06.340
あるいは、ニーズに応じて全てを網羅する単一のエンドポイントを使用することも可能です。

00:09:06.500 --> 00:09:09.460
さて、他のAzure接続オプションと何が違うのか疑問に思うかもしれません。

00:09:09.640 --> 00:09:11.860
VPN、ExpressRoot、サービスエンドポイントです。

00:09:11.860 --> 00:09:13.400
どれも似たような響きに聞こえます。

00:09:13.580 --> 00:09:14.560
整理してみましょう。

00:09:14.720 --> 00:09:17.940
プライベートリンク対VPN対ExpressRoot対サービスエンドポイント。

00:09:18.100 --> 00:09:21.980
では、プライベートリンクはVPN、ExpressRoot、サービスエンドポイントと比べてどうでしょうか。

00:09:22.080 --> 00:09:25.240
どれも同じことをしているように聞こえますが、実際には異なる問題を解決しています。

00:09:25.400 --> 00:09:27.360
多くの場合、これらを組み合わせて使用します。

00:09:27.560 --> 00:09:29.060
まずはVPNから始めましょう。

00:09:29.240 --> 00:09:33.040
仮想プライベートネットワークは、パブリックインターネット経由でオンプレミスネットワークとAzureを接続します。

00:09:33.340 --> 00:09:36.080
これは、拠点とAzureの間に暗号化されたトンネルを作成します。

00:09:36.200 --> 00:09:39.840
トラフィックは確かに暗号化されますが、パブリックインターネット上を移動することに変わりはありません。

00:09:39.980 --> 00:09:42.640
トンネルは安全ですが、それが通る道はパブリックなものです。

00:09:42.780 --> 00:09:45.840
プライベートリンクはVPNを置き換えるものではなく、併用するものです。

00:09:45.980 --> 00:09:51.560
VPNでオフィスとAzureを接続し、その接続からプライベートリンクを使用してストレージアカウントにプライベートにアクセスする場合があります。

00:09:51.760 --> 00:09:53.280
ExpressRootは異なります。

00:09:53.500 --> 00:09:56.600
データセンターからAzureへの専用プライベート回線を提供します。

00:09:56.780 --> 00:09:58.920
トラフィックはパブリックインターネットに一切触れません。

00:09:59.080 --> 00:10:01.940
マイクロソフトのネットワークに直結する独自の専用道路を持つようなものです。

00:10:02.080 --> 00:10:03.540
しかし、ここが注意点です。

00:10:03.540 --> 00:10:06.800
ExpressRoot単体では、PaaSサービスへのプライベートアクセスは提供されません。

00:10:06.940 --> 00:10:10.660
ネットワークをAzureに接続しますが、ストレージアカウントには依然としてパブリックエンドポイントが存在します。

00:10:10.800 --> 00:10:14.940
ExpressRootとプライベートリンクを組み合わせることで、それらのサービスへの真のプライベートアクセスが可能になります。

00:10:15.140 --> 00:10:17.040
サービスエンドポイントは古い技術です。

00:10:17.200 --> 00:10:21.660
これにより、仮想ネットワークからのトラフィックのみが到達できるようにAzureサービスへのアクセスを制限できます。

00:10:21.880 --> 00:10:24.700
しかし、サービスには依然としてパブリックエンドポイントが存在します。

00:10:24.880 --> 00:10:28.400
このVNETからのトラフィックのみ許可する、というファイアウォールルールを追加しているにすぎません。

00:10:28.580 --> 00:10:30.920
エンドポイント自体は依然としてインターネットにさらされています。

00:10:31.100 --> 00:10:32.620
プライベートリンクの型が安全です。

00:10:32.760 --> 00:10:35.660
なぜならエンドポイントは真にVNET内部にあり、プライベートIPを持つからです。

00:10:35.660 --> 00:10:37.500
攻撃対象となるパブリックエンドポイントはありません。

00:10:37.620 --> 00:10:39.180
分かりやすい考え方をお教えしましょう。

00:10:39.340 --> 00:10:41.500
VPNはパブリックな道路を通る安全なトンネルです。

00:10:41.640 --> 00:10:43.940
ExpressRootはAzureに直結する専用道路です。

00:10:51.660 --> 00:10:52.720
これを使うべきでしょうか?

00:10:52.840 --> 00:10:53.640
場合によります。

00:10:53.820 --> 00:10:57.580
OfficeをAzureに接続するには、VPNまたはExpressRootという選択肢があります。

00:10:57.780 --> 00:11:01.060
PaaSサービスにプライベートにアクセスする場合、プライベートリンクがゴールドスタンダードです。

00:11:01.240 --> 00:11:03.820
さらに強力なセキュリティが必要な場合は、これらを組み合わせましょう。

00:11:03.880 --> 00:11:08.540
ExpressRootでトラフィックをAzureにプライベートに引き込み、そこからプライベートリンクで各サービスにプライベートにアクセスします。

00:11:08.680 --> 00:11:11.340
しかし、プライベートリンクはマイクロソフトのサービス専用ではありません。

00:11:11.520 --> 00:11:13.200
独自のアプリケーションでも利用可能です。

00:11:13.360 --> 00:11:16.240
プライベートリンクサービスを使えば、独自のプライベートエンドポイントをホストできます。

00:11:16.440 --> 00:11:18.320
ここで、多くの人が見落としていることがあります。

00:11:18.520 --> 00:11:21.300
プライベートリンクは、Azureサービスを利用するためだけのものというわけではありません。

00:11:21.300 --> 00:11:23.920
自社のアプリケーションを世界に公開するためにも使えるのです。

00:11:24.060 --> 00:11:26.520
それこそが、まさにプライベートリンクサービスが構築された理由です。

00:11:26.660 --> 00:11:28.420
SaaSプロバイダーであると仮定してみましょう。

00:11:28.420 --> 00:11:32.960
スタンダードロードバランサーの背後にある仮想マシンでアプリケーションを動かし、顧客がそこにアクセスするとします。

00:11:33.180 --> 00:11:38.580
従来の方法では、すべてをインターネットに公開するか、自社と顧客のネットワーク間にVPNを設定するかの二択でした。

00:11:38.760 --> 00:11:40.400
どちらにも大きな欠点があります。

00:11:40.640 --> 00:11:44.840
公開すればセキュリティリスクが高まり、VPNは管理や保守が複雑になります。

00:11:45.040 --> 00:11:47.520
プライベートリンクサービスがその問題を解決します。

00:11:47.520 --> 00:11:53.180
サービスを作成してスタンダードロードバランサーに接続すれば、顧客は自身の仮想ネットワーク内にプライベートエンドポイントを作成できるようになります。

00:11:53.360 --> 00:11:55.900
そのエンドポイントが、あなたのサービスに直接接続するのです。

00:11:56.020 --> 00:11:58.880
ピアリングもVPNも不要でパブリックへの露出は一切ありません。

00:11:59.040 --> 00:12:03.580
トラフィックは顧客のプライベートエンドポイントからマイクロソフトのバックボーンを通って、直接あなたのサービスへと送られます。

00:12:03.740 --> 00:12:05.220
インターネットには一切触れません。

00:12:05.220 --> 00:12:11.260
サービスには、マイアップ、GUID、リージョン、Azure、プライバテリンクサービスのような、グローバルで1位のエイリアスが割り当てられます。

00:12:11.380 --> 00:12:15.900
顧客はそのエイリアスを使って接続しますが、誰がそれを見ることができるかはあなたが完全に制御できます。

00:12:16.100 --> 00:12:21.900
RBACロールや特定のサブスクリプションで可視性を制限することも、エイリアスを持つ誰でも接続リクエストができるようにすることも可能です。

00:12:22.060 --> 00:12:26.460
接続リクエストはすべて手動で承認する必要があるため、誰が接続しているのかを常に正確に把握できます。

00:12:26.660 --> 00:12:29.060
SaaSプロバイダーにとってこれは大きな変革です。

00:12:29.200 --> 00:12:33.940
ファイアウォールルールの開放や複雑なVPN設定の管理に代わり、顧客にエイリアスを渡すだけになります。

00:12:34.120 --> 00:12:37.460
顧客がプライベートエンドポイントを作成し、あなたがそれを承認すれば完了です。

00:12:37.600 --> 00:12:38.320
これだけです。

00:12:38.460 --> 00:12:40.000
ただし、一つ制限があります。

00:12:40.200 --> 00:12:43.280
プライベートリンクサービスはスタンダードロードバランサーでのみ機能し、ベーシックでは利用できません。

00:12:43.420 --> 00:12:46.240
まだベーシックロードバランサーをお使いの場合は、まずアップグレードが必要です。

00:12:46.400 --> 00:12:49.780
それは、得られるセキュリティとシンプルさを考えれば小さな代償と言えるでしょう。

00:12:49.960 --> 00:12:54.140
さて、ここまでのセキュリティは素晴らしいものですが、コンプライアンス要件や予算面ではどう影響するのでしょうか。

00:12:54.240 --> 00:12:56.860
セキュリティ、コンプライアンス、そしてコストの検討事項です。

00:12:57.000 --> 00:13:00.740
プライベートリンクがコンプライアンス要件や予算にどのような意味を持つのか、詳しく見ていきましょう。

00:13:00.920 --> 00:13:02.500
まずはセキュリティの観点からです。

00:13:02.500 --> 00:13:06.260
プライベートリンクは、パブリックエンドポイントを排除することで攻撃対象領域を削減します。

00:13:06.420 --> 00:13:07.800
これが最大のメリットです。

00:13:07.940 --> 00:13:14.120
インターネット上のどこからでもアクセスできるストレージアカウントやSQLデータベースの代わりに、仮想ネットワーク内からのトラフィックにのみ応答するリソースを利用できます。

00:13:14.340 --> 00:13:17.080
スキャンされるパブリックIPや、探索されるオープンポートはありません。

00:13:17.240 --> 00:13:19.220
攻撃対象領域が劇的に縮小します。

00:13:19.400 --> 00:13:22.640
あまり注目されていませんが、もう一つの利点としてデータ漏洩防止が挙げられます。

00:13:22.740 --> 00:13:25.480
各プライベートエンドポイントは特定のインスタンスにのみ紐付きます。

00:13:25.680 --> 00:13:29.680
サービス全体やサブスクリプション内のすべてのストレージアカウントではなく、その一つだけが対象です。

00:13:29.860 --> 00:13:35.520
そのため、万が一仮想ネットワーク内のワークロードが侵害されても、そのプライベートエンドポイントを使って他のストレージアカウントに到達することはできません。

00:13:35.660 --> 00:13:38.140
許可したその一つのリソースにのみアクセスが制限されるからです。

00:13:38.280 --> 00:13:40.740
セキュリティチームにとってこの封じ込めは非常に重要です。

00:13:40.740 --> 00:13:43.700
コンプライアンスの観点でも、プライベートリンクは多くの要件を満たします。

00:13:43.700 --> 00:13:49.300
HIPAA、GDPR、PCIなどの規制では、機密データが公衆ネットワークを経由しないことが求められることがよくあります。

00:13:49.480 --> 00:13:51.980
プライベートリンクを使えば、それを明確に証明できます。

00:13:52.180 --> 00:13:56.740
トラフィックはマイクロソフトのバックボーン内に留まるため、関差ログを提示して、これが証明ですということができます。

00:13:56.920 --> 00:13:59.820
規制の厳しい業界にとっては、それだけでも投資する価値があります。

00:14:00.060 --> 00:14:01.760
さて、コストについて話をしましょう。

00:14:01.940 --> 00:14:03.340
驚かれる方が多い部分です。

00:14:03.480 --> 00:14:05.060
プライベートリンクは無料ではありません。

00:14:05.060 --> 00:14:09.820
プライベートエンドポイントごとに時間単位の料金がかかり、さらに経由するトラフィックに応じたデータ処理費用も発生します。

00:14:09.960 --> 00:14:14.780
利用状況によっては、ファイアウォールルールを備えたパブリックエンドポイントを使う場合に比べて2から3倍高くなることもあります。

00:14:14.960 --> 00:14:17.520
エンドポイントの数が多いと、すぐに金額が積み上がります。

00:14:17.700 --> 00:14:19.480
では、正直な見解をお伝えします。

00:14:19.640 --> 00:14:21.920
プライベートリンクが常に正しい選択とは限りません。

00:14:21.920 --> 00:14:27.820
機密データのない開発環境やテスト環境であれば、適切なファイアウォールルールを設定したパブリックエンドポイントで十分でしょう。

00:14:28.000 --> 00:14:32.420
インターネットからアクセスされる公開ウェブサイトをホストしている場合、プライベートリンクは役に立ちません。

00:14:32.600 --> 00:14:37.620
しかし、金融、医療、政府といった規制の厳しい業界の本番ワークロードでは、プライベートリンクが必須となることが多いのです。

00:14:37.760 --> 00:14:39.900
それは安全にビジネスを行うためのコストといえます。

00:14:40.100 --> 00:14:42.680
導入の前に、いくつか注意しておくべき落とし穴があります。

00:14:42.900 --> 00:14:45.960
導入時の落とし穴について、初心者が陥りがちな点です。

00:14:46.100 --> 00:14:47.860
無駄な苦労をしないようにアドバイスさせてください。

00:14:48.040 --> 00:14:50.940
初めてプライベートリンクを設定する際によくある間違いをいくつか紹介します。

00:14:51.120 --> 00:14:54.880
まず第一に、プライベートエンドポイントを作成した後は、パブリックエンドポイントを無効にする必要があります。

00:14:55.040 --> 00:14:56.440
これが最大の落とし穴です。

00:14:56.620 --> 00:15:00.160
多くの人がプライベートエンドポイントを作れば十分だと考えますが、そうではありません。

00:15:00.160 --> 00:15:04.440
パブリックエンドポイントはデフォルトで有効なままなので、トラフィックがインターネットを経由し続ける可能性があります。

00:15:04.600 --> 00:15:08.260
ネットワーク設定を開きパブリックネットワークアクセスを明示的にオフにする必要があります。

00:15:08.460 --> 00:15:11.340
この手順を飛ばすと、実際には何も保護できていないことになります。

00:15:11.540 --> 00:15:15.320
次に、オンプレミスのクライアント向けのDNS解決には追加の設定が必要です。

00:15:15.500 --> 00:15:21.460
VPNやエクスプレスルート経由で接続している社内マシンでは、プライベートエンドポイントのIPを自動的に解決できません。

00:15:21.460 --> 00:15:26.840
プライベートDNSゾーンはAzure仮想ネットワークにリンクされており、オンプレミスのDNSサーバーにはリンクされていないためです。

00:15:26.980 --> 00:15:32.220
DNSフォワーダーを設定するか、Azure Deans Private Resolverを使用して、クエリがプライベートゾーンに到達するようにする必要があります。

00:15:32.400 --> 00:15:36.020
多くの方がこれを見落とし、オンプレミスのアプリがなぜ接続できないのか不思議に思います。

00:15:36.200 --> 00:15:39.600
また、プライベートエンドポイントはリージョンをまたいで自動的に機能するわけではありません。

00:15:39.760 --> 00:15:45.140
仮想ネットワークが西ヨーロッパにあり、米国東部のストレージアカウント用にプライベートエンドポイントを作成しても機能しません。

00:15:45.140 --> 00:15:48.500
プライベートエンドポイントは、仮想ネットワークと同じリージョンにある必要があります。

00:15:48.660 --> 00:15:52.640
パースサービスは別のリージョンにあっても構いませんが、エンドポイント自体はVNETのリージョンと一致させる必要があります。

00:15:52.820 --> 00:15:54.440
計画を立てる際は注意してください。

00:15:54.640 --> 00:15:55.480
もう一つあります。

00:15:55.720 --> 00:15:58.860
ネットワークセキュリティグループはプライベートエンドポイントのNICに影響します。

00:15:59.020 --> 00:16:01.780
プライベートエンドポイントは、サブネット内に仮想NICを作成します。

00:16:01.960 --> 00:16:05.840
そのNICは、同じサブネット内の他のリソースと同様に、同じNSGルールの影響を受けます。

00:16:05.940 --> 00:16:08.960
NICサブネットへのトラフィックをブロックすると、エンドポイントは機能しなくなります。

00:16:08.960 --> 00:16:10.980
NSGルールで許可されていることを確認してください。