前へ 1 2 次へ

第17回 “あのセキュリティ事故”はどうやったら防げた？ 検証委員会

フォーティネットの「ユニバーサルZTNA」が実現する、スムーズで無駄のないZTNAへの移行

“脱VPN”方針の大手エネルギー企業、だがZTNA移行の成功パターンが分からず…　どうすればよい？

文●大塚昭彦／TECH.ASCII.jp

提供: フォーティネット

  • この記事をはてなブックマークに追加
  • 本文印刷

VPNと大きく異なるZTNAの“仕組み”、それがもたらすメリット

　ZTNA（ゼロトラストネットワークアクセス）の基本的な説明については、以前の記事でまとめたのでご参照いただきたい。今回の記事では、ZTNAが実現する“新たな仕組み”がVPNとどう違うのかにフォーカスして説明したい。

■本連載の記事より：ZTNA（ゼロトラストネットワークアクセス）とは
　「わずか3日」で狙われたVPNの脆弱性！ 対策が後手に回り500GBの情報漏洩… どうやったら防げた？

　従来のVPNは「ネットワーク単位」でアクセスを制限する（許可／拒否する）ものだったが、ZTNAは「アプリケーション単位」のアクセス制限を行う。そのため、アプリケーションがクラウドにあってもオンプレミスにあっても、ZTNAの適用は可能だ。

　さらにZTNAでは、どこからの／どんなユーザーの／どんなデバイスのアクセスでも、一律に“信頼できないもの”として取り扱う。この原則に基づいて、ユーザーIDだけではない「より厳密な認証」を実施するとともに、一度認証したあともリスクの高い行動をしていないかなど「継続的な検証」を行う。さらには、ユーザー一人ひとりのロール（所属部署や役職など）に応じて「必要最小限のアクセス権限しか与えない」仕組みをとる。

　こうした仕組みがあるため、VPNでは防げなかった「盗み出したユーザーIDを悪用する攻撃（なりすまし）」「感染デバイスを踏み台とした攻撃」「ネットワーク侵入後の横展開攻撃（ラテラルムーブメント）」などが実行できなくなる。ZTNAは、攻撃者にとって“やっかいなセキュリティ環境”を実現するのだ。

ZTNAでは、アプリケーションアクセスに対してより厳密で継続的な検証を行い、さらに最小限のアクセス権限だけを与える

従来のリモートアクセスVPN（左）と、ZTNA（右）の違い

ZTNA移行を確実に進めるための「成功パターン」は？

　もっとも、従来のVPNの仕組みとまったく異なるため、「既存のVPNを一気にZTNAへ置き換える」というプランは現実的ではない。移行がうまく進まなければ、業務遂行に大きな影響を与えてしまう場合もある。そのため、今回のストーリーのように「どこから、どうやって？」と悩む企業も多いだろう。

　VPNからZTNAへの移行は段階的に、アプリケーションごとに適用していく必要がある。以下では、ZTNA移行を成功させるための、基本的な手順や考え方をまとめる。

　まずは、リモートアクセスが必要な業務アプリケーションの「棚卸し」を行う。IT／セキュリティ部門がすべて把握できているとは限らないので、各業務部門にアンケートを依頼したり、VPNやファイアウォールの通信ログを参照したりする。

　アプリをリストアップしたら、それぞれ以下の情報をまとめる。これらは、個々のアプリケーションをどういう方法でZTNA化するのか、容易にZTNA移行できるかどうか、どの順番に移行を行うかを検討するために必要な情報だ。

■ZTNA移行に向けたアプリの棚卸しで確認すべき項目
　・アプリの種別：SaaS、IaaS、オンプレミスなど
　・通信プロトコル：HTTP/HTTPS（Web）、RDP、SMBなど
　・認証方式：SSO、MFA（多要素認証）、ローカルID、端末証明書など
　・ユーザー：社員、委託先、取引先、海外拠点など
　・データ機密度：個人情報、営業情報、公開情報など

　続いて、棚卸しの結果に基づき、各アプリの移行対応を決める。具体的には「すぐにZTNAへ移行する」「移行に問題がないか検証する」「当面はVPN利用を継続する」の3つに分類すればよい。

　大まかに言えば、SaaSやWebアプリ（HTTP/HTTPS）はすぐに移行しやすく、Webプロトコル以外のファイルサーバーや自社開発アプリなどは要検証、レガシーなアプリは当面VPNで継続、といった判断になるだろう。

　対応の優先順位付けでは、技術的な移行の容易さだけでなく、セキュリティリスクの高さや、インシデント発生時の影響の大きさなども考えて判断すべきである。たとえば、機密度の高いデータを扱うシステムは優先的に移行を進める、といった具合だ。

　また、全社ではなく一部部門だけで利用されているアプリは検証や移行が進めやすいので、こうしたアプリから対応を始めて徐々に移行規模を拡大していく、という方法をとることもできる。

フォーティネットのZTNAはあらゆる場所／ユーザー／アプリに適用できる

　フォーティネットでは、あらゆる場所からの／あらゆるユーザーによる／あらゆるアプリケーションへのアクセスに適用できる「FortinetユニバーサルZTNAソリューション」を提供している。その構成や特徴、メリットを簡単にご紹介しよう。

「FortinetユニバーサルZTNAソリューション」の基本構成

　同ソリューションの基本的な構成要素は、ユーザー側のエンドポイントを監視する「FortiClient EMS/Agent」、アプリの前段でアクセスを制御するプロキシ「ZTNA Application Gateway」、そしてサードパーティの認証基盤である。

　FortiClient EMS（Endpoint Management Server）は、エンドポイントのFortiClient Agentと連携するエンドポイント管理サーバーだ。このサーバーで、たとえばデバイスの同一性、アクセス元の場所、OSのバージョン、深刻度の高い脆弱性の有無、セキュリティ機能の有効化状況といった、アクセス制御に必要なエンドポイントの詳細情報を収集し、アクセストラフィックにタグ付け（ZTNAタグ）ができる。

FortiClient EMSは、エンドポイントの詳細なセキュリティ状況（ポスチャ）を調べ、そのアクセスにタグ付けを行う

　一方、ZTNA Application Gatewayは、アプリに対するすべてのアクセストラフィックを仲介し、EMSが付けたZTNAタグとポリシーを照合してアクセス制御を行う。また、通過を許可したトラフィックに対しても、継続的なセキュリティ検査を行って攻撃をブロックする。

　ZTNA Application Gatewayの機能は、FortiSASEやFortiGateに内蔵されている。そのため、クラウド上のアプリでもオンプレミスのアプリでも、アクセストラフィックの制御が可能だ。また、HTTP/HTTPSのリバースプロキシ機能と、TCPプロトコルのフォワードプロキシ機能を備えているため、SaaSやWebアプリだけでなく、リモートデスクトップ（RDP）やファイルサーバー（SMB）などの非Webアプリにも適用できる。

FortiGate上のプロキシポリシーの設定画面。FortiClientによるZTNAタグを参照して、アプリへのアクセスを制御する

　こうした構成により、アクセス元が社内でもリモートでも、同一のポリシーに基づいてZTNAが適用できる。また、FortiClient Agentがインストールされていないエンドポイント（社外委託先や取引先、従業員の私物BYODデバイス）からのアクセスも、ユーザー認証に基づいて許可できる（ただし「セキュリティリスクが高いアクセス」となるため、一定のアクセス制限を適用すべきである）。

VPNからZTNAの移行期間もカバー、スムーズで無駄のない移行に

　FortinetユニバーサルZTNAの特徴は、まず「統合されたプラットフォーム」で提供されることだ。ZTNAの適用対象がSaaSでもオンプレミスアプリでも、またアクセス元が社内でもリモートでも、単一の管理画面とポリシーで制御できる。

　さらに「VPNからZTNAへの移行段階を包括的にカバーできる」点もメリットだ。FortiOSやFortiClient Agentは、IPsec-VPNにもZTNAにも対応できる機能を備えているので、移行期間中も複数のセキュリティ製品を導入、並行運用する必要がなく、よりスムーズな移行が可能となる。

　なお、FortiClientを利用すれば、IPsec-VPNであってもクライアントのセキュリティ状態（前述のZTNAタグ）を確認して、リスクの高いクライアントの接続を拒否することができる。つまり、VPN利用を続けるセキュリティリスクを軽減させることができるのだ。この点も、VPNからZTNAへの移行期間にはメリットとなるだろう。

■後日談：

　V社では、段階的なZTNA移行を、FortinetのユニバーサルZTNAソリューションを利用して進める方針を固めた。全体では1年半から2年ほどかかる見通しだが、まずはZTNAが適用しやすいSaaSと、攻撃を受けた際の業務影響が大きいアプリから順に着手していく。

　実は、V社にはすでに、ファイアウォールやVPNゲートウェイとしてFortiGateが導入されていた。これをそのまま、ZTNAへの移行中はIPsec-VPNゲートウェイとして、また移行後もZTNA Application Gatewayとして活用する。これにより追加コストを抑え、管理作業もシンプルに済ませる狙いである。慎重かつ確実に移行を進めることで、業務への影響も最小限で済みそうだ。

■関連サイト

前へ 1 2 次へ
Fortinet トップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります