100%

ゼロトラストの導入から、こう困った!私はこう解決したという事例としてZTNAにおけるZscalerの適用事例をお伝え致します!

序章

ゼロトラストという言葉が世の中に出てからしばらく経ち、いろいろな企業が従来の境界型セキュリティモデルからゼロトラストモデルへの転換をし始めたと思います。

ゼロトラストとは

ゼロトラストの考え方とは、そもそも「どんなものであるか」から語りたいと思います。ゼロトラストの英語を日本語に直して、そのままの意味となりますが、「何も信頼しない」という概念となります。従来は境界の中にいれば安全という、守るべきものは境界の中に閉じ込めておき、守るべきものは境界の中からアクセスする、脅威は全部境界の外にあるという考え方が主流でした。つまり、内は安全だが、外は危険という考え方であり、内と外のネットワークの境界線上にセキュリティ対策を施し、守ることで、中は信頼するという考え方となります。ただ時代は移り変わっていくもので、近年では、コロナウイルス感染拡大のために、テレワークが主流になり、それに伴い、内部からの情報漏洩が多発し、加えて、クラウドサービスの利用拡大に伴うセキュリティリスクの増加が世の中の対策のトレンドとして風潮され、今までの境界防御だけでは如何ともし難い状況が生まれ始めました。内は安全という概念が壊れ始めた中で、主流として取り込まれた概念が、ゼロトラストとなります。つまり、ネットワークの内部と外部を区別することなく、守るべきものにアクセスするものは全て信用せずに検証することで、脅威を防ぐ考え方となります。

ゼロトラストの重要な要素

ゼロトラストという概念が分かったとしても、今までの主流の考え方を根本的にひっくり返す必要があるため、導入に舵をきった企業は大変な思いをしたかと思います。何も信用しないためにはどうしたらよいかという中で、認証認可の考え方があります。つまり、「誰が」、「どのデバイスで」、「どのデータに」、「どのようにアクセスする」かの認証・認可を常にする必要があります。これを一から構築するのは非常に体力がいる話であり、各種コンポーネントに対してソリューションを導入し、それをカスタマイズすることでそれを実装していくことが主流な動きになると思います。今回の記事では必要なコンポーネントの一つであるZTNAについて紹介したいと思います。

ZTNAとは

ZTNAとは、ゼロトラストネットワークアクセスの意味となり、利用者の情報や端末の状態を検査し、状態に応じてクラウドサービスやオンプレミスの業務システムへのアクセスを制御する仕組みとなります。検査する内容は多岐にわたり、例えば「自社の端末か」「エージェントが端末に入っているか」「セキュリティ更新プログラムを適用しているか」「安全な場所から接続しているか」等を総合的に判断して、信頼できるかどうかを確認します。上記の検査で得た利用者や端末の状態と、事前に設定したセキュリティポリシーを照合し、アクセスする対象をその都度決めること等を実現するといった、まさにゼロトラストの主要な要素を担当しております。

ZTNAとしてZscalerを選んだ理由

ZTNAとして、私はZscaler(ゼットスケーラー)の導入をしました。なぜZscalerを選んだかというと、一つ目としてクラウド型の製品である点です。まず基盤を大きく変更することから、PoC(Proof of  Concept)をしてから導入が必須であると思います。オンプレ型の製品の場合は、まず購入から入るかと思いますが、Zscaler はクラウド型の製品であるため、契約から導入までに時間がかからず、数日以内に導入を完了しました。すぐに利用可能で、もし検討した内容と違うということでしたら、すぐに返却できるというものが必要であったため、クラウド型は必須でした。二つ目として、サービスのラインナップの多さです。Zscalerの主な機能としては、Zscaler Internet Access(ZIA:クラウドProxyのような機能)とZscaler Private Access(ZPA:VPNの代わりとして有効活用できるような機能)が有名ですが、その他、Zscaler Digital Experience(ZDX:監視と可視化する機能)やZscaler Cloud Platform(ZCP:CSPMのような機能)等、かゆいところにも手が届く機能が具備されておりました。三つ目は導入企業数です。私も今回の選定までにどんな企業が導入しているかというのを営業担当にもいろいろ聞きましたが、やはり大手のほとんどがZscalerを導入しているという実績があります。例えば、紹介ページにも記載がありますが、NTTデータ、ソフトバンクといった通信企業やNECといった老舗メーカなどの本当に日本を代表する企業が利用しているため、安心感が醸成され、最終的に、製品選定として、Zscalerの利用が満場一致となりました。

導入時に悩んだこと

満場一致で選定されたZscalerですが、導入時に一番悩んだことは、ブラウザ分離です。ITリテラシーが非常に低い環境にいるため、標的型メールなどでURLのクリックや添付のクリックは日常茶飯事で、C&C(コマンドアンドコントロール)対策として、ブラウザ分離が必須要件としてありました。最初はエンドポイントセキュリティでの対策として、EDR(Endpoint Detection and Response)にて挙動確認等からブラウザ分離を行わなくてもリスクとして許容可能ではないかということで進めておりましたが、標的型メール訓練を先んじてやった際の開封率の高さから(驚きの10%!)、許容はできないという結論となり、急遽既存の環境と同等のブラウザ分離は残すことが必要となりました。そこで出てきた解は、クラウドブラウザアイソレーション(CBI:クラウドブラウザ分離)となります。Zscaler側で分離されたブラウザを用意しており、ZscalerがWebページに接続し、分離されたブラウザにロードし、我々ユーザ側にはHTMLでストリーミングされる仕組みを用いることで、所謂ブラウザ分離を実現し、ブラウザベースでの攻撃などを阻止する仕組みを導入出来ました。ただここで大きな問題として、CBI経由でのIP固定が出来なかったことです。IPアドレス固定でアクセスが必要なサイトが複数個あり、Zscalerの所持しているIPアドレス帯を登録することも検討しましたが、さすがグローバル展開している企業ということから、ものすごい数のIPアドレスを保持しており、Zscalerが提供するIPレンジを丸ごと許可するように登録するのは無理があるなという整理となってしまいました。

解決方法はZPA側にあった

当該悩みに関して、ベストソリューションとして、最初に検討したのは、IP固定が必要な通信は限定されることから、Zscalerをバイパスして接続することでした。ただ、その接続先が未来永続的に安心であるとは言えず、例えばそのサイトが廃止され、マルウェアが仕込まれたサイトになった場合(非常に低い確率ですが。)は直接アクセスになることからC&Cのセッションが張られてしまうといったことに繋がるため、NGという結論となりました。その後もZscaler側と協議を重ね対応した方法は、ZPAのコンポーネントであるConnecterを利用する方法となります。IP固定が必要なサイトをZscaler側に登録をしておいて、当該IPアドレスに通信が発生した場合に、Zscaler側でConnecterにトラフィックを自動的にリダイレクトさせ、Connecter経由でインターネットへ出ていく方法です。これをやることで、長い闘いに終止符を打つことが出来ました。

最後に

今回は、私が体験したゼロトラスト導入の一部を紹介しました。実際に導入する上で、今後も様々な導入障壁があるかと思います。ただ、こういった障壁一個一個に解決策は存在するため、是非とも共有をいただければ、パイオニアの功績はきっとIT業界を更に進めていくことになると思います。

以上