• 脆弱性管理
• 多要素認証の導入と接続元IPアドレスの制限
• 管理用画面への外部からのアクセス制限

　SSL VPNの脆弱性管理については、定期メンテナンスを前提とした運用から一歩進める必要がある。近年は、脆弱性の公開から悪用までの時間が短縮している。脆弱性の深刻度や悪用状況を踏まえ、緊急性が高い場合には次回のメンテナンスを待たずにパッチを適用するなど、「深刻度を考慮しながら迅速に対処する必要があります」と今井氏は強調する。

　これらの対策は、主に既知の脆弱性への対処を前提としたものだ。公表前の脆弱性であるゼロデイ脆弱性を突いた攻撃は、防ぎ切れない可能性がある。仮に攻撃者がSSL VPNに侵入した場合でも、被害を最小化できる対策を併せて検討すべきだ。具体的には以下の対策が考えられる。

• アクセス権限最小化の原則に基づいた制御
• 接続してくるデバイスのチェック（会社貸与デバイスかどうか、セキュリティ対策ソフトが稼働しているかなど）
• ログの集約・監視

　特に、認証後に社内ネットワークへ広くアクセスを許可する設定は避ける必要がある。侵害が拡大しやすくなるだけではなく、影響範囲の特定や調査も困難になるからだ。

　SSL VPNを単に運用し、バージョンアップをしているだけでは、セキュリティレベルは「100点満点中、20点程度」であり、MFAを導入して「ようやく50点」だと今井氏は語る。SSL VPNを安全に運用するには、侵入されることを前提にした対策も含めて、適切な対策が欠かせない。

より安全な環境へ移行する3つの選択肢

　必要な対策を講じたとしても、SSL VPNの脆弱性の悪用そのものを完全に防ぐことは難しく、実害に至る可能性をゼロにすることはできない。設定ミスのリスクも踏まえると「侵入を100％防ぐことは難しいのが現状です」と今井氏は語る。

　これらの対策を継続的に実施するには、相応の運用負荷が伴う。人員が限られる中堅・中小企業では、ITやセキュリティに精通した人材を常時確保できるとは限らず、必要な対策を維持し続けること自体が容易ではない。

　「対策を講じてもなおリスクが残ること」と「運用負荷の高さ」という2つの課題を背景に、SSL VPNからの脱却と、新たなアーキテクチャの検討が進みつつある。今井氏によると、移行先としての主な選択肢は3つある。

　1つ目はIPsec VPNだ。SSL VPNの脆弱性が狙われやすい背景には、インターネットに公開されたアクセスの入り口であることに加え、SSL／TLS関連のライブラリなど、依存するコンポーネントの脆弱性の影響を受けやすいという要因がある。そのため「IPsec VPNに切り替えることで、対処すべき脆弱性の数は減る可能性があります」と今井氏は説明する。

　IPsec VPNにも課題はある。トンネルの設定やルーティングの設計など、ネットワーク構成を明示的に設計する必要があることから、SSL VPNと比べて導入や運用のハードルが高くなりやすい。脆弱性管理やMFAを含むID管理などの対策は、引き続き必要だ。IPsec VPNへの切り替えは一定のリスク低減にはつながるものの、抜本的な解決策とは言い切れない。

　認証後に社内ネットワークに広くアクセスできてしまうという問題は、IPsec VPNに切り替えても解消されない。これは「VPNという仕組みそのものに起因する制約です」と今井氏は語る。

　2つ目の「ZTNA」（Zero Trust Network Access）は、ゼロトラストセキュリティの考え方に基づいた、VPNに代わる新たなリモートアクセスの仕組みだ。VPNのようにネットワーク単位で接続を許可するのではなく、ユーザーやデバイスの状態に応じて、アプリケーション単位でアクセスを制御する点に特徴がある。「状態が変わることを前提に、一度ではなく継続的にチェックしながらアクセスを許可することで、リスクを削減します」と今井氏は説明する。

　ZTNAは例えば、デバイスで動作しているはずのEPPやEDRが無効化されるなど、状態に変化があればアクセスを停止するといった制御を可能にする。認証後に社内ネットワークへ広くアクセスを許可するのではなく、ユーザーや利用目的ごとにアクセス範囲を限定することで、仮にアカウントが侵害されても影響範囲を局所化できる。結果として、被害の封じ込めや調査の効率化にもつながる。

　3つ目の「SASE」（Secure Access Service Edge）および「SSE」（Security Service Edge）は、アクセス制御やフィルタリング、マルウェア検知、そして前述のZTNAなどのセキュリティ機能を提供するクラウドサービス群だ。ネットワークとセキュリティを一体的に提供するSASEに対して、SSEはその中でもセキュリティ機能に特化している。

　SASE／SSEでは、ベンダーが展開するPoP（Point of Presence：接続拠点）にユーザーの通信を集約し、一元的に制御する。こうした構成は「Microsoft 365」「Salesforce」をはじめとする複数のクラウドサービスを利用する企業や、テレワーク前提の企業に適していると今井氏は説明する。

　クラウドサービスであるSASE／SSEでは、パッチ適用をはじめとするメンテナンス作業はベンダーが担う。ライセンスコストは増加する可能性があるものの、従来のWebプロキシなど個別に導入してきたセキュリティ製品を集約・置換することで、結果として運用負荷やコストの削減につながる可能性がある。

ZTNAやSASE／SSEの導入・検討時に留意すべきポイント

　SSL VPNの有力な移行先になり得るZTNAやSASE／SSEについては、さまざまなベンダーが製品を提供している。選定に当たっては「機能やコストはもちろん、既存システムとの親和性を重視すべきです」と今井氏は述べる。

　Microsoft 365や「Microsoft Azure」「Microsoft Entra ID」といったMicrosoft製品を中心に活用している企業であれば、同社のZTNAサービスである「Microsoft Entra Private Access」が導入しやすく、有力な選択肢となる。一方で特定のセキュリティベンダー製品に詳しい担当者が社内にいる場合は、そのベンダーのZTNA製品やSASE／SSEサービスであれば導入や運用のイメージを持ちやすく、検討のきっかけにしやすい。

　各分野で広く使われている製品を組み合わせる「ベスト・オブ・ブリード」というアプローチもある。ただし導入後の運用を考えると、人的リソースに限りのある中堅・中小企業にとっては、ある程度ベンダーを絞り込むことは検討の価値がある。「異なるベンダー製品の管理画面をそれぞれ開くよりも、1つの管理画面で設定や現状把握を済ませられる方が、運用負荷を軽減できます」と今井氏は語る。

　ZTNAやSASE／SSEでは、SSL VPNに比べてアクセス制御をより細かく設計する必要がある。具体的には「誰が何を利用してよいのか」「どこまでアクセスを許可するのか」といった要件を明確にして、ポリシーとして定義することになる。その前提として、制御対象となるIDやアプリケーションの棚卸しと可視化は欠かせない。これらの作業には一定の時間と負荷が掛かるため、余裕を持った計画策定と設計期間の確保が重要になる。

　見落とされがちなのがデバイス管理だ。資産管理が不十分なデバイスが存在したり、OSが混在していたりする企業は珍しくない。業務委託先からのアクセスが盲点となり、どのようなデバイスが接続しているのかを把握できていないこともある。「SSL VPNからの移行を機に、デバイスについてもしっかり把握することが大切です」と今井氏は指摘する。

　SSL VPNの見直しについて、今井氏は「ゼロトラストセキュリティの考え方を取り入れながら、次のステージに進む好機だと捉えるべきです」と指摘する。単なる移行にとどまらず、よりセキュアなアクセス方式を採用することで、業務の生産性向上につなげることが重要になる。

　ゼロトラストセキュリティは分かりにくい考え方だと捉えられがちだが、本質はシンプルだ。

　例えば最近のオフィスでは、ビルの入り口で一度チェックすれば、どこにでも入れるといった運用は採用されていない。入室できる場所をセキュリティカードなどで制限し、行動も把握できるようにしていることが一般的だ。

　システムの世界でも同様に、IDとパスワードによる認証だけに依存するのではなく、その後のアクセス範囲を適切に制御し、追跡できる状態にすることが求められる。こうした考え方が、ゼロトラストセキュリティの基本となる。