[連載]ゼロトラストのネットワークの大黒柱。SSE/SASEをVPN置き換えで終わらせない[第3回]

恐縮です。**

ゼロトラストの話で、デバイスの次に一気に目立つのがここです。
SSE/SASE。
言葉としても強い。絵も描きやすい。変化も見せやすい。
だから、かなり多くの現場で「次はSASEだ」となります。

でも、ここは熱が入りやすい分だけ、かなり危ないです。
なぜか。
SASEを入れても、アクセス制御が変わらないまま終わる会社が本当に多いからです。
出口が変わる。VPNが少し減る。トラフィックの見え方は変わる。
でも、誰が・どの端末で・どこへ・どの条件で行けるかは、あまり変わっていない。
これでは、見た目は派手でも中身は薄い。
ここが一番つらいです。

前回はこちら。

まず、SSEとSASEの違いを

ここは冒頭で一度切っておいた方が、かなり読みやすいです。
現場ではこの二つがかなり混ざります。
でも、役割は同じではありません。

SSEは、セキュリティ側の束です。
ZTNA、SWG、CASBのように、ユーザーのアクセスやSaaS利用、Web利用をどう制御するかに寄っています。
つまり、アクセス制御の本体はこちらです。

SASEは、そのSSEにネットワーク側の要素を足した考え方です。
拠点接続やWANの見直しまで含めて、ネットワークとセキュリティをまとめて再設計する。
こちらは、アクセス制御だけでなく、経路そのものまで含めて見る整理です。

雑に言うなら、
ユーザーアクセスの制御を中心に見るならSSE。
拠点・回線・経路まで含めて見るならSASE。
です。

だから実務では、リモートアクセス、SaaS利用、社内アプリ到達制御の話をしているのに、言葉だけSASEになっていることがかなり多いです。
これは珍しくありません。

この先の本文では、アクセス制御の話を中心にするので、SSE/SASEと併記しつつ書きます。
ただし、主役はあくまで「どう到達させるか」を設計する部分です。ここはかなり大事です。

だから先に言い切ります。
SSE/SASEは、ネットワーク機器の置き換えではありません。
アクセス経路を、ゼロトラスト前提で引き直す話です。
ここを外すと、かなりの確率で例外だらけになります。

ゼロトラストのネットワークの柱で本当にやりたいのは、
誰が。
どの端末で。
どの経路から。
何に対して。
どの条件なら到達してよいのか。
これを、場所やVPN接続の有無ではなく、アイデンティティと端末状態を前提に制御することです。

つまり、ネットワークの柱は「つながるか・つながらないか」を雑に決める柱ではありません。
到達の仕方を細かく設計し直す柱です。
ここまで来ると、SASEの見え方がかなり変わってきます。

参考URL

SASEは魔法でもないし、手品でもない

ここはかなり重要です。
SASEという言葉が出ると、つい「これを入れればゼロトラストが進む」と見えやすい。
でも、実際はそんなに簡単ではありません。

SASEの中には、ZTNA、SWG、CASB、FWaaSのような要素が入っています。
つまり、インターネット向けの出口制御もあるし、SaaS利用の可視化もあるし、社内アプリへの到達制御もある。
かなり広い。
だからこそ便利です。

でも、広いということは、入れただけで全部よくなるわけではない、ということでもあります。
アイデンティティが弱ければ、誰に許可しているのかが雑になる。
端末状態が弱ければ、危ない端末もそのまま通してしまう。
アプリ棚卸しが甘ければ、何をZTNAへ移すべきか決まらない。
ポリシー設計が甘ければ、結局は「広く許可、困ったら例外」で崩れます。

ここが本質です。
SASEは強い。かなり強い。
でも、前提が弱いまま入れると、強い箱を入れただけで終わります。
だから、SASEは魔法ではありません。
前の柱が整っているほど効くし、整っていないほど荒れる。
ここを先に理解しておいた方が、かなり事故が減ります。

参考URL

ネットワークの柱で本当に変えるべきもの

ネットワークの柱で変えるべきなのは、回線や機器の見た目ではありません。
アクセスの考え方そのものです。

昔の発想では、社内ネットワークに入ったら広く行ける。
VPNにつながったら中に入れる。
拠点からなら信頼する。
この考え方がかなり強かった。

でも、いまはもう厳しいです。
ユーザーは社外から入る。
SaaSはインターネット上にある。
社内アプリもクラウドに寄る。
委託先も入る。
端末の状態もバラつく。
この状態で「中だから信用」はかなり危ない。

だから、変えるべきはここです。
ネットワークに入れるかどうかではなく、
必要なリソースに、必要な条件でだけ到達させる。
ここに発想を切り替える。

ZTNAはこの考え方と相性がいいです。
「社内に広く入れる」ではなく、「このアプリにだけ行ける」に寄せやすいからです。
SWGは、Webアクセスを見て止める。
CASBは、SaaS上の利用実態やデータの動きを見て制御する。
つまり全部、到達の質を変えるための部品です。

ここを一つにまとめて、アクセス経路を再設計する。
これがSSE/SASEの面白さです。
そして、ここをVPN置き換えだけで終わらせると、一番もったいないです。

参考URL

ZTNA、SWG、CASBをどう分けて見るか

ここも混ざりやすいです。
全部SASEの中で語られるので、現場ではすぐ一塊になります。
でも、役割はかなり違います。

ZTNAは、到達先を絞る部品です。
ユーザーにネットワーク全体を見せるのではなく、このアプリ、このポート、この接続だけを許可する。
広く中に入れる発想を壊す役目です。

SWGは、Webへの出口を整える部品です。
危ないサイト、怪しい通信、業務に不要なアクセス、マルウェア配布先などを見て止める。
いわば、Web利用をゼロトラスト前提で見直すための出口側です。

CASBは、SaaS利用を整える部品です。
どのSaaSを誰が使っているか。
承認済みか。
危ない共有がないか。
機密データがどこへ流れているか。
ここを可視化し、制御につなげる。

この3つを雑にまとめると、
ZTNAは到達先を絞る。
SWGはWebへの出口を絞る。
CASBはSaaS利用を絞る。
です。

ここを分けて考えると、SASE導入の順番もかなり見えやすくなります。
VPN置き換えが急務ならZTNAから入る。
Web利用の整理が先ならSWGが効く。
SaaS乱立とデータ持ち出しが痛いならCASBの価値が大きい。
つまり、SASEは一つの箱ではなく、何を先に締めるかの選択肢の集合でもあります。

参考URL

https://www.zscaler.com/products/zero-trust-network-access-ztna

https://www.netskope.com/products/cloud-access-security-broker

https://www.paloaltonetworks.com/sase/prisma-access

現場で最低限そろえたいもの

SASE編で最初に揃えたいのは、派手なPoCではありません。
まず土台です。
ここを飛ばすと、かなり高い確率であとで崩れます。

一つ目は、アクセス先の棚卸しです。
何にアクセスしているのか。
SaaSか、Webか、社内アプリか、オンプレか、クラウドか。
これが分からないままSASEを入れると、どこをZTNAへ寄せるのか、どこをSWGで見るのか、どこをCASBで見るのかが決まりません。
最初の地図がないまま機器だけ先に入る形になります。
これは危ないです。

二つ目は、VPN例外の洗い出しです。
SASE導入でだいたい苦しむのは標準ユーザーではありません。
古い業務システム、固定IP前提、業者接続、運用端末、管理者作業、ファイル共有、特殊プロトコル。
つまり例外側です。
ここが見えていないと、切り替えは必ず止まります。

三つ目は、IdPと端末状態の連携です。
誰か分からない。
端末が管理下か分からない。
認証強度が分からない。
これでは、SASE側で細かいポリシーを書いても、結局ざっくり許可しかできません。
ネットワークの柱は、前の柱にかなり依存します。
ここは本当に大きいです。

四つ目は、ポリシーを小さく始めることです。
最初から全アプリ、全拠点、全ユーザーを一気に切り替える。
これは理想に見えますが、現場ではかなり危ない。
まずは対象を切る。重要度を切る。影響範囲を切る。小さく通して、詰まる場所を見つけて、そこから広げる。
この順番の方が、かなり回ります。

五つ目は、ログを見る責任の置き場です。
SASEはログが増えます。
Web、SaaS、私設アプリ、遮断、許可、失敗、例外。
ここを誰が見るのかが曖昧だと、結局は「入れたけど、使い切れない」になります。
ログは増えたが、判断に変わらない。これはかなりもったいないです。

[画像④：ネットワークの柱で最低限そろえたいもの]
※ 図の要素：左から右へ、アクセス先の棚卸し → VPN例外の洗い出し → IdPと端末状態の連携 → ポリシーを小さく開始 → ログを見る責任の置き場 の流れ
※ キャプション案：最初から全部つなぐより、まずはこの5点を先に固める

代表的な製品はこの3つから見れば外しにくい

SSE/SASEで代表例を3つ挙げるなら、まずは
Zscaler
Netskope
Prisma Access
でよいと思います。

ここでも言いたいのは、どれが絶対に一番かではありません。
現場で比較対象に上がりやすく、考え方の違いを見やすい3つ、という意味です。

Zscalerは、Zero Trust Exchangeの考え方で、インターネットアクセスとアプリ到達制御をまとめて見やすいです。
SASEを「アクセス経路の再設計」として捉えるとき、かなり比較しやすい代表例です。

Netskopeは、SaaS利用やデータの見え方を含めて考えたいときに比較しやすいです。
CASBやデータ保護を含めた見方を強く持ちたい組織では、かなり候補に上がりやすいです。

Prisma Accessは、既存のネットワーク・セキュリティ運用とつなげて見たいときに比較しやすいです。
Palo Alto系の運用資産や設計思想を持っている組織では、かなり自然な比較対象になります。

大事なのは、きれいな画面や機能一覧ではありません。
自社の例外接続、既存VPN、SaaS利用、認証基盤、端末状態と本当につながるか。
ここで見ると、製品の見え方はかなり変わります。

参考URL
https://www.zscaler.com/products/sase
https://www.netskope.com/platform/sse
https://www.paloaltonetworks.com/sase/prisma-access

現場でよくある失敗は、だいたい同じ

一番多いのは、VPN置き換えで終わることです。
これは本当によくあります。
経路は変わった。出口もクラウド化した。拠点構成も少しきれいになった。
でも、アクセスの考え方は前と同じ。
広く許可して、困ったら例外。
これでは、ゼロトラストとしてはかなり弱いです。

次に多いのが、最初から全部つなごうとして止まることです。
全ユーザー、全アプリ、全拠点、全例外を一気に扱う。
これはかなりの確率で止まります。
原因は単純です。
現実が複雑すぎるからです。
だから、小さく切る。
ここはかなり大事です。

さらに多いのが、IdPと端末条件が弱いままポリシーだけ細かいことです。
見た目は立派です。
でも、誰か分からない、端末状態も弱い、リスク判定も薄い。
この状態では、細かいルールほど空振りします。
結果として、例外が増える。
ここはかなり苦しいです。

もう一つは、ログが増えただけで終わることです。
SASEは可視化に強いです。
でも、可視化は見て終わりでは意味がない。
誰が見て、何を異常とし、どこまでを止めるのか。
そこまで決めないと、ログは宝の山ではなく、ただの倉庫になります。

最後に、例外が永続化することです。
最初は暫定のはずだった固定IP許可。
まだ残っているVPN直通。
古い認証方式。
管理者だけ別経路。
これが積み上がると、SASEを入れても裏口だらけになります。
例外はゼロにできなくてもいい。
でも、見えない例外と見直されない例外はかなり危ないです。
はっきり言います。例外は例外で永続的なものであってはいけない。

この柱が整うと、次のワークロードの柱が回り始める

ネットワークの柱が整うと、次はワークロードの柱がかなり現実的になります。
ここから先は、人のアクセスだけでなく、アプリやクラウドの実行環境そのものをどう守るか、という話へ進んでいきます。

なぜか。
ネットワークの柱が弱いと、そもそも到達制御が粗い。
誰がどこへ来ているのかも曖昧。
この状態では、ワークロード側で細かい保護をしても、入り口が広すぎて苦しくなります。

逆に、SSE/SASEやZTNAでアクセス経路が整理されると、
どのアプリに誰が来るのか。
どの条件なら到達するのか。
どこが公開面なのか。
ここがかなり見えやすくなります。

つまり、ネットワークの柱は単なる接続の話ではありません。
次のワークロード保護の前提を整える話でもあります。
ここが見えると、SASEを先にやる意味もかなり腹落ちしやすくなります。

まとめ

SSE/SASEは、ネットワーク機器の置き換えではありません。
アクセス経路を、ゼロトラスト前提で引き直す話です。
ここを外すと、見た目は変わっても中身が変わらない。
これはかなり起きやすいです。

ZTNAは到達先を絞る。
SWGはWeb出口を絞る。
CASBはSaaS利用を絞る。
この役割の違いを押さえながら、IdP、端末状態、例外管理、ログ運用をつないでいく。
すると、ネットワークの柱はかなり強くなります。

最初に全部完璧である必要はありません。
でも、棚卸し、例外整理、ポリシーの小さな開始、ログを見る責任、このあたりを曖昧にしたまま進めると、だいたいあとで詰まります。
ここはかなりの確率で詰まります。
だから先に手を打つ。これが大事です。

SASEは派手です。
でも、本当に効くのは派手さではありません。
到達の仕方を細かく変えられるかどうか。
ここです。

そして、この柱が整うと、次のワークロードの柱がやっと現実になります。
ネットワークの柱は、やはりかなり大きい。
そう思います。

恐縮でした。

次回はこちら