更新日：2026.9.6
| このページの内容 |
シナリオ2の概要
 |
今回からシナリオ2 ZTNA方式のリモートアクセスです。 前回のシナリオ1では、上の図のようにPC1からSecure Accessに対してVPN（TLS）を張った。また、AWSのFortiVMからはSecure Accessに対してIPsecトンネルを張った。そして赤矢印のように、PC1からAWS内のAD1に対してPingやRDP接続を行った。 |
 |
うん、めちゃ大変だった。 |
|
そうだね。シナリオ2では下図のように、AWS内にRC（Resource Connector）を建てる。そしてPC1がAD1に通信する際に、前回のようにVPNを経由してPC1がAD1に直接アクセスするのではなく、RC1が赤矢印のように代行してAD1へ通信するようにします。 |
|
ん？代行して通信？ってことはRC1はプロキシサーバのような役割ってこと？ |
|
そうだね。ただちょっと違う点がある。 プロキシサーバの場合はPCがプロキシサーバへ向かって 送信元IP：PC 送信元IP：PC ここはまた後ほど詳しく書きます。 |
|
む、難しいな。でもプロキシサーバと同様、RC1が代行通信した結果を、PC1は受け取るということだよね？ |
|
そうだね。なので、RC1がAD1に対してRDP接続をしたら、PC1上にそのRDP接続している画面が表示される。 |
|
ほう・・・。なんかすごいことをやっている気はするけど、これ、わざわざやる必要あるのかな？VPNaaSで既にPC1からAD1には通信できているんだから必要なくない？ |
|
既にVPNaaSがある場合だったら、必要か必要でないかで言えば必要ない。 |
|
ん？あ、じゃあVPNaaSを導入せずに、こちらのRC1で代行通信させる方式だけを使うという選択肢もあるわけか。 |
|
そうだね。このRCに代行通信させる方式をCiscoはZTA（Zero Trust Access）と呼んでいる。けれどSASEというかNW業界ではこの通信方式のことをZTNA（Zero Trust Network Access）と一般的に呼んでいるかな。 |
|
Ciscoはすぐにちょっと独自な呼び方をしたがりますよね？ |
|
そうだね・・・。 |
|
それにしても、ZTNAってよく聞くワードだと思っていたけど、このことだったのか。 で、じゃあZTNA方式とVPNaaS方式、どっちがいいんですか？ |
VPNaaS vs ZTNA
|
VPNaaSとZTNAのどっちがいいとか悪いとかはないけど、私の個人的な評価は下の表の通りかな。 |
| VPNaaS方式 | ZTNA方式 | |
| 既存VPNから移行のしやすさ | ◎ | × |
| 「リモートアクセス端末 ← 社内NW」方向の通信 | ○ | × |
| セキュリティ | ○ | ◎ |
| 利便性 | ○ | ◎ |
|
なるほど、どちらも強みがあるわけか。 |
|
そうだね。順に見ていくと。 1点目の既存VPNから移行のしやすさは圧倒的にVPNaaS方式が有利だ。VPNaaS方式は間にSASE（クラウド）が仲介するだけで従来のVPNとほぼ変わらないので、既存のVPNで適用している通信制御ルールをそのまま設定可能なケースが多いからだ。 |
|
ZTNA方式はそうではないってこと？ |
|
そうだね。今後、実際の設定画面を見ていくけど、通信先のアプリケーションをそれぞれ設定する必要があったりして、かなり手数がかかる。それにZTNA方式の場合はサーバに到着するパケットの送信元IPが常にRCのIPになる。サーバによってはそれを受け付けないこともあってZTNA方式にできないこともある。 |
|
なるほど・・・。 |
|
続いて2点目の「リモートアクセス端末 ← 社内NW」方向の通信。 これ、ZTNA方式はできないんだ。 例えばVPNaaS方式の場合であれば下図の赤矢印のとおり、AD1（172.17.1.90）からPC1（10.34.0.11）へ通信することも、許可ポリシーさえ設定すれば可能だ。 |
|
ところがZTNA方式の場合、赤矢印の通信の送信元IPはRC1（172.17.1.80）なので、AD1はPC1のIPなんか知らない。なのでAD1は、RC1から来た通信に対して返答することはできるけど、AD1から自主的にPC1に対して通信することはできないんだ。 |
|
なるほど。そしたら「PC1 ← AD1」のように、「リモートアクセス端末 ← 社内のサーバ」という通信が必要な場合はVPNaaSが必要ってことですね！ |
|
そうだね。 |
|
けど実際、サーバからスタートする通信ってよくあるんですか？ 「クライアント → サーバ」方向の通信は一般的だと思うけど、 「クライアント ← サーバ」方向の通信ってほとんどないと思うけど。 |
|
そうだね。今はもうほとんどない。実際、企業によってはサーバ発通信が全くなくてZTNA方式だけを導入するケースもあると思う。 けどセキュリティ関連ソフトとかは今でも設定次第ではサーバ発通信が発生するし、2000年代とかのレガシー系と呼ばれるような古いシステムも、サーバ発通信があるケースが多いんだ。特に製造業とかだとレガシー系を未だに使っているケースが多い印象があるよ。なのでZTNAとVPNaaSを併用で導入するケースが多いかな。私がここ2～3社くらいに提案していたのも併用案だった。 |
|
なるほど・・・。 |
|
続いて3点目のセキュリティ。これはZTNA方式のほうが上だと思う。 |
|
えーと、VPNaaS方式は○。ZTNA方式は◎という評価ですね。ということはVPNaaS方式も十分よいけど、ZNTA方式は更によいということですね。 |
|
そうだね。ZTNA方式のほうが上の理由は、通信の都度、送信元のPCがチェックされるから。これがいわゆる ゼロトラスト＝何も信用しない。なので毎回チェックする。 の根幹とも言える部分だ。 |
|
毎回チェックって、何をチェックするの？ |
|
送信元のPCのOSのバージョンだったり、ウイルス対策ソフトが正常に稼働しているかだったりとかだね。 |
|
そんなの毎回チェックする必要ある？1日1回確認すれば十分では？ |
|
ああ、私もそう思う。毎回チェックするのがそんなに大きなメリットだとは思えない。 それによくパンフレットとかだと VPN方式だと一度認証したらその後はたくさんの宛先に通信し放題。 とかアピールされているけど、別にVPN方式でも宛先を細かく制限すれば実現できるのになって思うよ。どうもどのメーカーも、ZTNA方式を必要以上によいものだとアピールしすぎだと個人的には思っているよ。 |
|
なるほど。じゃあ先生はZTNA方式には後ろ向きなのかな？ |
|
いや、ここまで言っておいてなんだけど、そんなことないです。すいません。むしろZTNA推奨派です・・・。 |
|
なんだ。ここまで悪く言っておいて。なんでなんですか？ |
|
それは4つ目の利便性。 実は私の職場も何年か前にVPN方式からZTNA方式に切替わったんだけど、めちゃめちゃラクになったと感じたよ。リモートワークでPCを起動すると、VPNの場合はVPNを張る動作が発生していたけど、ZTNAはそれがなくなったからね。ZTNAについてはこのあと詳しく取り上げるけど、ZTNAはVPNのように「とにかくまず張る必要があるもの」ではないから。 |
|
へえ。けどVPNも自動接続機能があれば手動で張らなくてよいので、ZTNAと変わらないのでは？ |
|
それはそうなんだけど、VPNの場合は接続完了を確認したり、時々接続が切れてしまったり、 VPNが問題なく接続されているか？ を気にする機会がどうしても多少なり発生していた。けれどZTNA方式にしたら、これを気にする必要が一切なくなった。これが思った以上にストレスがなくなってラクだったんだよね。なのであくまで個人的にだけど、ZTNA方式のみの導入、おすすめです。 |
|
なるほど。 |
|
それでは次回からは具体的な設定を見ていきます。今回も読んでくれてありがとうございました。 |