FortiGate リモートアクセスの 2 要素認証と ZTNA｜FortiToken 設定

はじめに

リモートアクセスは、社外から社内資源へ接続する経路であり、インターネットに公開されるぶん、攻撃者にとって主要な標的になります。パスワードのみの認証では、漏えいや総当たりによる不正接続のリスクが残るため、2 要素認証や、ネットワーク全体ではなくアプリケーション単位でアクセスを絞る仕組みが重要になります。

加えて、FortiGate のリモートアクセスは近年大きく構成が変わりました。SSL VPN トンネルモードが廃止され、現行では IPsec VPN・Agentless VPN・ZTNA を用途に応じて使い分ける形になっています。本記事では、この前提のうえで、リモートアクセスの 2 要素認証と ZTNA の要点をまとめます。設定全体の優先度は『FortiGate ハードニングの優先度と確認手順』で扱っています。

リモートアクセスの堅牢化は、現行の接続方式を把握したうえで、利用者の認証を 2 要素に強化し、必要に応じて ZTNA でアクセス範囲をアプリケーション単位に絞る、という流れで整理できます。以降では現状と選択肢から順に扱います。

リモートアクセスの現状と選択肢

リモートアクセスの設計を考える前に、現行で利用できる方式と、その背景となった変更を押さえます。

SSL VPN トンネルモードの廃止と IPsec VPN への移行

FortiOS 7.6.3 以降、SSL VPN トンネルモードは IPsec VPN に置き換えられ、GUI・CLI から利用できなくなりました。旧バージョンの設定はアップグレードで引き継がれないため、7.6.3 へアップグレードする前に、IPsec VPN への移行を済ませておく必要があります。 アップグレードの進め方は関連記事『FortiGate アップグレードパスの確認手順』を参照してください。置き換え後の IPsec VPN は、従来の IPsec が遮断される環境に配慮して、TCP ポート 443 を使う構成も選べます。

参考: Fortinet「SSL VPN tunnel mode replaced with IPsec VPN」
“the SSL VPN tunnel mode feature is replaced with IPsec VPN”
（SSL VPN トンネルモード機能は IPsec VPN に置き換えられた）
https://docs.fortinet.com/document/fortigate/7.6.3/fortios-release-notes/173430/ssl-vpn-tunnel-mode-no-longer-supported

あわせて、SSL VPN の Web モードは「Agentless VPN」へ改称され、RAM が 2GB 以下の機種（40F・60F・61F は 7.6.0、50G は 7.6.1）では利用できなくなりました。該当機種では、リモートアクセスの方式を IPsec VPN や ZTNA へ見直す必要があります。

現行の選択肢

現行のリモートアクセスは、用途に応じて次の方式から選びます。

 IPsec ダイヤルアップ VPN: 利用者の端末にトンネルを張り、社内ネットワークへ接続するフルトンネル型。広い到達性が必要な用途に向きます。

 Agentless VPN（旧 SSL VPN Web モード）: ブラウザー経由で社内の Web アプリケーションへリバースプロキシ接続する方式。クライアントのトンネルは張りません。

 ZTNA: アプリケーション単位でアクセスを許可し、端末の姿勢を確認する方式。ネットワーク全体への到達性は与えません。

2 要素認証の重要性

リモートアクセスのゲートウェイは公開されるため、認証情報の漏えいや総当たりの標的になります。過去には 2 要素認証のバイパスにつながる脆弱性（CVE-2020-12812 など）も公表されており、適切な 2 要素認証の構成と、脆弱性への速やかなパッチ適用の両方が重要です。脆弱性情報の確認は関連記事『FortiGate PSIRT の確認手順』で扱っています。次のセクションから、リモートアクセス利用者への 2 要素認証の適用を扱います。

リモートアクセス VPN の 2 要素認証

IPsec ダイヤルアップ VPN や Agentless VPN の利用者に対して、パスワードに加えて FortiToken による所有要素を組み合わせると、認証情報が漏えいした場合の不正接続を抑止できます。FortiToken にはハードウェアトークンとモバイルトークン（FortiToken Mobile）があり、ワンタイムパスワードのほか、スマートフォンへのプッシュ通知による承認も利用できます。

ローカルユーザーへの割り当ては、管理者の場合と同様に two-factor で行います。

config user local
    edit "vpn_user01"
        set type password
        set passwd <password>
        set two-factor fortitoken
        set fortitoken <token-serial>
        set email-to user@example.com
    next
end

割り当てたユーザーを、VPN で参照するユーザーグループに含めることで、接続時に 2 要素認証が要求されます。利用者数が多い環境では、FortiAuthenticator や RADIUS を介した集中管理や、SAML による外部 IdP との連携（シングルサインオン）も選択肢になります。

設定の前提として、トークンは時刻ベースのワンタイムパスワードを使うため、NTP による時刻同期を整えておきます（時刻同期は関連記事『FortiGate 暗号化と物理アクセスの堅牢化』を参照）なお、管理者アカウントの 2 要素認証は関連記事『FortiGate 管理者アカウントと認証設定の手順』で扱っています。

確認: show user local | grep -e two-factor -e fortitoken

参照: FortiToken の割り当てと VPN 利用者認証は FortiOS Administration Guide を確認しています。
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/14906/administrator-account-options

ZTNA によるアプリケーション単位のアクセス制御

ZTNA（Zero Trust Network Access）は、利用者にネットワーク全体への到達性を与えるのではなく、アプリケーション単位でアクセスを許可する仕組みです。端末の識別・認証に加え、端末のセキュリティ状態（姿勢）を確認したうえでアクセスを判断します。VPN のように「社内ネットワークに入れる」のではなく、「許可されたアプリケーションにだけ届く」点が特徴です。

仕組みの中心になるのが、アクセスプロキシとセキュリティ姿勢タグです。

 アクセスプロキシ: FortiGate が HTTP・TCP の通信を HTTPS 接続で中継するリバースプロキシです。IPsec や SSL VPN のトンネルを張らずに、保護対象サーバーへアクセスできます。HTTPS アクセスプロキシのほか、内部でのみ名前解決できる宛先向けの TCP フォワーディングがあります。

 セキュリティ姿勢タグ（旧 ZTNA タグ）: FortiClient EMS のタグ付けルールから生成され、FortiGate に同期されます。たとえば、特定のマルウェアファイルを検知した端末にタグを付け、そのタグを持つ端末のアクセスを拒否する、といった姿勢に基づく制御ができます。

参考: Fortinet「ZTNA access proxy」
“FortiGate access proxy can proxy HTTP and TCP traffic over secure HTTPS connections”
（FortiGate のアクセスプロキシは HTTP・TCP 通信を安全な HTTPS 接続で中継できる）
https://docs.fortinet.com/document/fortigate/7.0.0/ztna-architecture/19197/ztna-access-proxy

構成の流れは、FortiClient EMS をファブリックコネクタとして接続し、姿勢タグを同期したうえで、アクセスプロキシの宛先（ZTNA サーバー）を定義し、ポリシーで許可するタグを指定する、という順序になります。ポリシーでは ztna-ems-tag で許可する姿勢タグを指定します。

加えて、FortiClient や端末証明書を必要とせず、ブラウザーから認証してアクセスする ZTNA Web ポータルも用意されています。利用者側の導入の負担を抑えたい場合の選択肢になります。なお、これらのプロキシ系機能は、RAM が 2GB 以下の機種では利用できません。特権アクセスの管理を強化する用途では、FortiPAM と組み合わせる構成もあります。

ZTNA の通信は、GUI の「ログとレポート」の ZTNA トラフィックで確認できます。アクセスの可否を記録・監査する観点は、関連記事『FortiGate ログ管理とフォレンジックの手順』とあわせて整理できます。ZTNA の具体的な構築手順は範囲が広いため、本記事では要点に留めています。

VPN と ZTNA の使い分け

リモートアクセスの方式は、どれか 1 つに統一するというより、用途に応じて使い分ける、あるいは組み合わせる前提で考えると整理しやすくなります。

フルトンネル型の IPsec VPN は、利用者の端末を社内ネットワークに接続し、複数のサーバーや、Web 以外のプロトコルを含む広い到達性が必要な用途に向きます。一方で、利用者にネットワークレベルの到達性を与えるため、端末が侵害された場合の影響範囲は広くなります。

ZTNA は、アプリケーション単位でアクセスを許可し、端末の姿勢を確認するため、到達範囲を絞れる点が強みです。ただし、フルトンネルのような広い到達性は前提としていないため、ネットワーク全体への接続が必要な用途には、そのままでは置き換わりません。

このため、実務では次のような使い分け・組み合わせが現実的です。

• 広いネットワーク到達性が必要な用途: IPsec VPN（必要に応じて TCP 443 を使用）
• 特定の Web アプリケーション・サーバーへのアクセス: ZTNA（アクセスプロキシ・姿勢タグ）
• 端末導入の負担を抑えたいブラウザーアクセス: ZTNA Web ポータルや Agentless VPN

いずれの方式でも、公開されるゲートウェイは攻撃対象になり得ます。接続元の制限・2 要素認証・脆弱性への速やかなパッチ適用を組み合わせ、単一の対策に依存しない多層の構成にすることをおすすめします。 ZTNA は到達範囲を絞ることで、端末が侵害された場合の横移動のリスクを下げる方向に働きます。

まとめ

FortiGate のリモートアクセスは、SSL VPN トンネルモードの廃止を経て、IPsec VPN・Agentless VPN・ZTNA を用途に応じて使い分ける構成へ移行しました。リモートアクセスの堅牢化は、利用者の認証を 2 要素に強化し、必要に応じて ZTNA でアクセス範囲をアプリケーション単位に絞り、公開ゲートウェイを多層で守る、という流れで整理できます。

• SSL VPN トンネル廃止後は IPsec VPN・Agentless VPN・ZTNA を使い分け
• リモートアクセス利用者への FortiToken による 2 要素認証
• プッシュ通知や SAML・RADIUS 連携による認証の選択肢
• ZTNA のアクセスプロキシによるアプリ単位のアクセス制御
• セキュリティ姿勢タグによる端末状態に基づく可否判断
• フルトンネル VPN とアプリ単位の ZTNA の使い分けと併用
• 接続元制限・2FA・パッチ適用を組み合わせた多層構成

以上、最後までお読みいただきありがとうございました。