リモートアクセスに関して、アンケートへのご協力をよろしくお願いします。
【免責事項】
本記事は、登壇者の発表内容や発言は個人の見解であり、所属組織を代表するものではありません。
紹介する設定や技術は「学びの共有」を目的としています。本番環境へ適用する際は、各組織の環境に合わせて各自で検証し、ご自身の責任でご判断ください。設定変更等によって生じたトラブルについて、コミュニティおよび登壇者は責任を負えませんので、あらかじめご了承ください。
また、この内容は2026.4.10時点の内容でして、情報は常に変化するので、メーカーさん等の正式情報を確認ください。
- 1.概要
- 2.脆弱性と攻撃の被害
- 3.代替え案(対処策)
- 4.設定に関して
- 5.IPsecは果たして安全か
- 6.メーカー対応
- 7. リモートアクセスのロードマップとゼロトラスト(ZTNA)機能
- 8.UTMのセキュリティ設定
- 9.WEST-SECイベントに関して
1.概要
(1)概要
・FortiOS 7.6.3 以降、SSL-VPNトンネルモードが廃止され、リモート接続をするには、IPsec VPNを使う必要がある。
・これまでは、設定画面はあったが、FortiOS 7.6.3 からはGUI/CLIからSSL-VPNトンネルモードの設定自体が消失
(2)廃止の背景
・IPsecがOSのカーネルレベルで処理される標準化されたプロトコルであるのに対し、SSL-VPNは多くの場合、Webアプリケーションとして実装される。これにより、メモリ管理や入力検証におけるバグが致命的な脆弱性につながりやすい構造的欠陥を抱えていた。
・近年のセキュリティインシデントにおいて、FortiGateのSSL-VPN機能(sslvpnd)は、ランサムウェアグループや国家支援型攻撃者(APT)の主要な標的となってきた。特に、認証する前(=認証せずに)に悪用可能なリモートコード実行(RCE)ができる脆弱性が発生し、その攻撃の被害が多発していることがある(詳細はこのあと)
・脆弱性の頻発でパッチ適用が負担に ※2025.10.24の記事
https://xtech.nikkei.com/atcl/nxt/column/18/03373/101600001/
(3)詳細
・当初、FortiOS 7.4系列において、メモリ容量が2GB以下のエントリーモデル(FortiGate-40F, 60F等)を対象にSSL-VPN機能の削除が開始された 。しかし、FortiOS 7.6.3のリリースに伴い、この制限はすべてのFortiGateモデルに拡大された 。
・具体的には以下の変更が適用される
❶SSL-VPNトンネルモードの完全削除
GUI(管理画面)およびCLI(コマンドライン)の両方から設定項目が排除される。
❷設定の継承不可
既存のファームウェアから7.6.3へアップグレードした際、既存のSSL-VPN設定は削除され、移行されない 。また、 SSL-VPN利用ユーザはFortiOS 7.6系へのアップグレード前にSSL-VPNからIPSec VPNへの移行を完了する必要がある 。
❸Webモードの名称変更と縮小
従来の「SSL-VPN Webモード」は「Agentless VPN」へと名称変更される。総メモリ容量が2GB以下のモデル(40F/60F等)ではメモリ枯渇を防ぐために本機能が使用不可となった。また、それ以外のモデルでも、利用できなかったり、Agentless VPN機能はサポート対象外とされている場合もある。
| ■参考:エントリーモデル(2GBメモリ)での廃止が先行した理由 sslvpndプロセスが大量のメモリを消費し、システム全体の安定性を脅かす可能性があるため |
・SSL-VPN(Virtual Private Network)を利用できるバージョン7.4などの技術サポートの終了(EoES:End of Engineering Support)は、2027年5月11日(2026.4月に1年延長が発表) ※2026.04.07の記事
https://xtech.nikkei.com/atcl/nxt/column/18/00001/11649/
2.脆弱性と攻撃の被害
(1)UTMやFWでの脆弱性が頻発
FortiGate社に限らず、代表的な会社のUTMやFW、VPN装置にて、脆弱性の存在が確認されています。
(出典:令和6年9月 警察庁サイバー警察局 https://www.npa.go.jp/publications/statistics/cybersecurity/data/R6kami/R06_kami_cyber_jousei.pdf)

【参考記事】
・Fortinet 製 FortiOS の脆弱性対策について(CVE-2024-55591)
https://www.ipa.go.jp/security/security-alert/2024/alert20250115.html
・「Cisco ASA」狙うゼロデイ攻撃、5月に複数政府機関で確認
https://www.security-next.com/174973
・Ivanti製VPN製品の脆弱性、国内組織もゼロデイ攻撃の標的に ※Ivanti Connect Secureは、旧Pulse Connect Secure
https://www.security-next.com/152609
・Check Point機器のVPN機能に脆弱性、攻撃から判明 - アップデートを
https://www.security-next.com/157686
・Palo Alto Networks 製 PAN-OS の脆弱性対策について(CVE-2024-3400)
https://www.ipa.go.jp/security/security-alert/2024/alert20240415.html
(2)発表された脆弱性
SSL-VPNのデーモン部分に致命的バッファオーバーフロー(CVE-2024-21762)や認証バイパス脆弱性(CVE-2023-27997)などが立て続けに発見され、いずれもパッチ適用前の環境で攻撃に使われている
(3)ランサムウェア攻撃の感染ルート
| ア 感染経路 ランサムウェアの感染経路について質問したところ、115件の有効な回答があり、このうち、VPN機器からの侵入が73件で63%、リモートデスクトップからの侵入が21件で18%を占め、テレワーク等に利用される機器等のぜい弱性や強度の弱い認証情報等を利用して侵入したと考えられるものが約82%と大半を占めた。 ![]() (出典:令和6年3月14日 警察庁 https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf |
(4)ニュースや報道発表
・2025年4月には米CISAも Fortinet のSSL-VPN脆弱性事例に言及し、修正パッチ適用までSSL-VPN機能を無効化するよう勧告した
・フランスCERT-FR も同様に被害を報告しており、グローバルに強い注意喚起がなされている
https://thehackernews.com/2025/04/fortinet-warns-attackers-retain.html#:~:text=The%20U,said%20it%27s%20aware%20of%20compromises
(5)攻撃を受けるとどうなるか
近年のSSL-VPNの脆弱性(CVE-2023-27997やCVE-2024-21762など)は、「認証前」の「リモートコード実行(RCE)」と呼ばれるものです。
これは単にVPNの認証をすり抜けるだけでなく、FortiGateのOS(FortiOS)上で、攻撃者が用意した不正なプログラム(コード)を直接実行できることを意味します。root権限の取得も可能です。
3.代替え案(対処策)
3.1 ワークアラウンド
少なくとも、FortiOSを最新化した上での暫定対処です。
・VPN利用の廃止(保守作業は現地のみにする)
・利用時のみ稼働させる。(同時に、IPアドレスを確認し、そのIPアドレスからのみ接続許可をする)
・ログおよび監視の強化をし、何か不審な動作があればすぐに停止する状況で運用する。
・送信元IPアドレス制限(Geo-IP機能を利用)。少なくとも、海外からの利用がないのであれば、海外通信は全てブロックでいいだろう。ただし、踏み台経由で通信されたら意味がないので、効果は限定的。
3.2 対処策
・全体像
| 項目 | (1)従来のSSL-VPN | (2)IPsec VPN | (3)ZTNA | (4)FortiSASE (SIA) |
|---|---|---|---|---|
| 通信プロトコル | TCP | UDP ESP |
TCP | UDP / ESP (優先) TCP (代替) |
| ポート番号 | 443 | 500, 4500 (※ESPはポート番号無) |
443 | 500, 4500 443 (※IPsec通信不可時のフォールバック用) |
・UDP500と4500の補足
| ポート番号 | 用途 |
|---|---|
| UDP 500 | ・鍵交換のIKE(Internet Key Exchange)の初期通信で利用 |
| UDP 4500 | ・NAT-T環境でのIKE通信の継続(注1) ・ESPパケットのUDPカプセル化(注2) |
注1:鍵交換の継続: 経路上にNATが存在することが判明すると、IKEの通信自体もUDP 500からUDP 4500に切り替わります。
注2:ESPのカプセル化: 実際の暗号化通信(ESPパケット)をUDP 4500でカプセル化して送受信。
4.設定に関して
4.1 状態確認と無効化
(1)バージョンの確認
・ダッシュボード > ステータス >システム情報 からバージョンの確認

(2)SSL-VPN機能の無効化
・設定方法として、SSL-VPNをOFFにすれば、無効化できる

(3)SSL-VPN設定の削除
機能の無効化だけでも攻撃されることはないが、不要な設定であるため、削除しておく
a)ファイアウォールポリシーの削除
b)SSL-VPN設定の削除
c)SSL-VPNユーザの削除
d) SSL-VPNユーザグループの削除
e)スタティックルート ※SSL-VPNのIPプール宛て(ssl.root)の静的ルーティングを書いていた場合
f)SSL-VPNポータル設定: ※ポータル自体の削除。
など
(4)設定画面の変化
❶旧画面 v7.2.10の場合

❷7.6.3 以降の設定できない画面

4.2 IPsecへの移行
(1)概要
ローカルネットワークでのテストだが、設定手順は基本的に同じ。

(2)必要なソフトウェア
・FortiClient(無料版・有償版)
※ 無料版は、ライセンス費用ゼロで利用可能だが、Fortinetの公式テクニカルサポートの対象外であり、有償版(FortiClient EMSライセンス)を利用することが推奨。
※IPsecの脆弱性が出た場合、無料版でもソフトウェアのバージョンアップ自体は提供される(と思われます)。
※OS標準のVPNクライアントを利用すれば、ソフトウェアのインストールすら不要です。ただし、OS標準クライアントは、あくまで「トンネルを繋ぐだけ」の機能しか持ち合わせておらず、FortiClientを使うのが推奨です。
(3)認証設計
IPsecの認証は、フェーズに分けて考える
❶トンネルの認証(機器同士の接続)
| 認証方法 | 内容 | 推奨度 |
|---|---|---|
| PSK(事前共有鍵) | 事前に共有した強固な文字列(たとえば、20文字以上のランダム英数字) | 運用が楽。実際には多くの企業ではPSKを使っていると想定される |
| 証明書(デバイス証明書) | PC側にクライアント証明書、FortiGate側にサーバー証明書を入れ、ルート証明書で相互認証 | セキュリティは強固だが、運用が大変 |
❷ユーザ認証
・従来のIKEv1では「XAuth」と呼ばれる仕組みでユーザ名とパスワードの認証を実施していましたが、よりセキュアなIKEv2ではXAuthが利用できません。そのため、IKEv2の標準規格である「EAP(拡張認証プロトコル)」を用いて、個人ごとの認証を実施します。
・社内のActive Directory(AD)やRADIUSサーバーと連携して既存のアカウントを流用するか、利用者数が少ない環境であれば、FortiGate本体のローカルデータベースでユーザ管理(アカウント作成)を行います。
❸MFA(多要素認証):【絶対必須(MUST)】
FortiGateで設定できる認証方法
| 項番 | 方式 | 推奨度 | 備考 |
|---|---|---|---|
| 1 | スマホアプリ(FortiToken Mobile | 〇 | セキュリティレベルが高いが、中間者攻撃の可能性もゼロではなく、完璧ではない ※ Microsoft Authenticator 等も使えるが、メーカのFortiTokenを使うのがお勧め |
| 2 | メールによるOTP | △ | FortiGate標準機能で無料実装可能。ただし、攻撃によってはメールの盗聴、メールアカウントの乗っ取りなどにより、OTPの情報も盗まれる可能性あり(※NISTのガイドライン等では低評価) |
| 3 | SMS認証 | △ | SMS送信用の外部ゲートウェイ契約(従量課金)が必要であり、現実的ではなさそう。 |
| 4 | クライアント証明書によるユーザ認証 | (実施できるのであれば)◎ | 証明書配布・失効管理など運用負荷が非常に高く、費用対効果が悪い。 |
※SSL-VPNで証明書認証やワンタイムパスワード(MFA)を利用する場合、FortiGateの時刻が正確である必要があります。システム > 設定 からNTPが正しく同期されているか確認する。
❹送信元IPアドレス制限
・ 実施できる環境(接続元のIPが固定されている保守業者や特定拠点など)であれば、絶対に実施すべきです。
・認証が始まる前の段階で不正なパケットを破棄するため、セキュリティ対策として 非常に強固
・設定場所は、 通常の「ファイアウォールポリシー(IPv4ポリシー)ではなく、「ローカルインポリシー(Local-In Policy)」で行う。→設定方法は後述
4.3 設定手順(FortiGate側)
・ForiOSの7.6系と7.4系で手順が結構違う。今回は、7.4系と7.6系の両方の画面が混在しているが、手順書ではなく、骨子を説明したものと理解していただきたい。
(1)ネットワーク構成図

(2)設定パラメータ
・ VPN接続設定情報一覧
| 項目 | 内容 |
|---|---|
| WAN側インターフェース | wan1(IP: 203.0.113.254) |
| LAN側インターフェース | lan(IP: 192.168.1.254/24) |
| VPNクライアント用IPアドレスプール | 192.168.20.64 ~ 192.168.20.127 |
| 事前共有鍵(PSK) | fortinet |
| 許可ユーザーグループ | IPsec-VPN_Users ※事前にユーザー・グループ作成が必要 |
・インターフェース設定

(3)ポリシー
・通常のFWポリシー
| 項番 | 役割 | 送信元アドレス | 宛先アドレス | サービス | セキュリティプロファイル | NAT | アクション |
|---|---|---|---|---|---|---|---|
| 1 | LAN ⇔ インターネット | 192.168.1.0/24 | ANY | ALL | AV, IPS, SSL-inspection等 | Enable | 〇 許可 |
| 2 | VPN ⇔ 内部ネットワーク | 192.168.20.64/26 | 192.168.1.10 | HTTPS | AV, IPS, SSL-inspection等 | Disable | 〇 許可 |
| 3 | VPN ⇔ インターネット | 192.168.20.64/26 | ANY (all) | HTTP、HTTPS、DNS | 必要に応じて設定 | Enable | 〇 許可 |
| 4 | 上記以外すべて拒否 | ANY | ANY | ANY | - | - | ✕ 拒否 |
・ローカルインポリシー
| 項番 | 役割 | 送信元インターフェース | 送信元アドレス | 宛先インターフェース | 宛先アドレス | サービス | セキュリティプロファイル | NAT | アクション |
|---|---|---|---|---|---|---|---|---|---|
| 1 | IPsec VPN確立用通信 | port1(WAN) | 許可するIP | port1(WAN) | 203.0.113.254 | UDP 500/4500, ESP | - | - | 〇 許可 |
| 2 | すべて拒否 | port1(WAN) | ANY | port1(WAN) | ANY | ANY | - | - | × 拒否 |
(4)7.4系の手順
a)VPN>IPsecウィザードから設定していく ※IPアドレス等が上記で書いたものと違うのはお許しください。
b)ポリシーアンドルーティング

| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| IPv4スプリットトンネリングを有効化 | OFF | 端末からのインターネット直接通信を禁止し、全通信をFortiGate(社内)経由に強制する設定。マルウェア感染時の踏み台化やセキュリティポリシー迂回を防ぐため、OFFが原則。 |
| エンドポイント登録を許可 | OFF | 旧バージョン向けのレガシー機能(現在は非推奨・廃止)。現行環境では使用しないため、無効のままで問題なし。 |
c)クライアントオプション

| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| パスワード保存 | ON(※MFA導入が前提) | MFA(多要素認証)環境であれば、パスワード保存によって利便性を高めてもセキュリティを担保できる |
| オートコネクト | OFF | PC起動時やネットワーク接続時に意図せずVPN接続を開始しないように |
| 常にアップ(Keep Alive) | OFF | 通信がない状態でもトンネルを維持し続ける設定。セキュリティの観点でOFFが原則 |
d)VPNトンネルの編集
・IKEのバージョンは、バージョン2を使う

・フェーズ1プロポーザル ※画面が正しくなくてごめんなさい

| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| 暗号化と認証アルゴリズム | AES256/SHA256 および AES128/SHA256 のみ有効(SHA1は削除) | 強固な暗号方式のみを使用する。SHA1を含む2つの設定は「×」で削除 |
| Diffie-Hellman(DH)グループ | 20(または21)にチェック | DHグループ20/21は最新世代の強力な暗号方式。それ以外のチェックは外す |
・フェーズ2プロポーザル
先と同様

(5)7.6系の設定
a)左メニューの [VPN] > [VPNウィザード] をクリック
b)「トンネル名」に任意の名前を入力(例:IPsec-VPN)

c)VPNトンネルの設定
| 項目 | 内容 |
|---|---|
| VPNクライアントの種類 | FortiClient(盾のアイコン)を選択 |
| 認証方式 | 事前共有鍵 を選択 |
| 事前共有鍵 | fortinet を入力 |
| ユーザー認証方法 | 作成済みユーザーグループ(例:IPsec-VPN_Users)を選択 |
※その他の、IKEバージョン、NATトラバーサルなどはデフォルトのまま

d)リモートエンドポイントの設定(IPプールの割り当て)
VPN接続してきた端末に対して、社内から割り当てるIPアドレスの範囲を指定
| 項目 | 内容 | 備考 |
|---|---|---|
| 接続されたエンドポイントに割り当てるアドレス | 192.168.20.64 - 192.168.20.127 | |
| 接続されたエンドポイントのサブネット | 255.255.255.255 | 他の端末と通信させないため32ビット |

| 設定項目 | 推奨設定 | 理由 |
|---|---|---|
| セキュリティポスチャゲートウェイのマッチング | オン(※) | 端末が自社のセキュリティ基準(OSやアンチウイルス等)を満たしているか確認するため。 |
| EMS SN検証 | オン(※) | 偽の管理サーバーへの接続(中間者攻撃)を防ぐため。 |
| パスワードの保存 | オフ | PC紛失・盗難時に、第三者による社内ネットワークへの不正アクセスを防ぐため。 |
| 自動接続 | オフ | 意図しない接続を防ぎ、必要な時だけ手動で接続させて安全性を高めるため。 |
| 常に稼働している(キープアライブ) | オフ | 無通信のセッションを自動切断し、乗っ取りリスクを減らすため。 |
※上記2つは、社内で「FortiClient EMS(エンドポイント管理サーバー)」を導入・運用している場合のみ有効です。
e)ローカルFortiGateの設定(ルーティングとポリシー)
VPNの入り口となるインターフェースと、アクセスを許可する社内ネットワークを指定
| 項目 | 内容 |
|---|---|
| トンネルにバインドする着信インターフェース | wan1(インターネット側)を選択 |
| ローカルインターフェース | lan(社内ネットワーク側)を選択 |
| ローカルアドレス | lan(192.168.1.0/24 のネットワークオブジェクト)を選択 |
f)設定のレビューと適用
ウィザードによって自動生成される設定(アドレスグループ、インターフェース、ファイアウォールポリシー等)のリストが確認できます。
「トンネルが正常に設定されました」と表示されれば完了です。
g)設定の確認
左メニューの [VPN] > [VPNトンネル] をクリックします。
リストに作成した IPsec-VPN が表示され、インターフェースバインディングが wan1 になっていることを確認します。
(※誰も接続していない初期状態では、ステータスは「非アクティブ(赤色ダウン)」となります)

h) VPNトンネルの詳細設定と暗号化アルゴリズムの確認
・ウィザードで自動生成されたIPsecトンネルのパラメーターを確認・調整します。
・[VPN] > [VPNトンネル] を開き、作成したトンネル(例:IPsec-VPN)を選択して [編集] をクリックします。
・設定を確認します。


・暗号化・認証アルゴリズム: 「フェーズ1の提案」「フェーズ2セレクター(高度)」を展開すると、ウィザードによって推奨される強固な暗号化(AES128/AES256など)と認証(SHA256など)、Diffie-Hellmanグループ(21など)になっていることを確認。
※この点は、クライアントソフトのバージョンによってはGCMが未対応だったりもするので、クライアントソフト側と設定を合わせる。


i)ファイアウォールポリシーのチューニング(アクセス制限)
セキュリティを高めるため、「必要なサーバーへ、必要な通信のみ」に制限します。

j)VPN経由でのインターネットアクセス許可
VPN接続中のPCが、自宅の回線から直接インターネットに出るのではなく、会社のFortiGate(wan1)を経由してインターネットにアクセスする運用とする場合の、インターネットへ抜けさせるための新規ポリシーの設定。※IPS等のセキュリティ設定は、必要に応じて実施。

(6)ローカルインポリシーによるVPN接続元の制限(セキュリティ強化)
特定のアクセス元(例:PCの固定IP 203.0.113.33/32)のみを許可し、それ以外をすべて拒否する設定を行います。
a)初期状態では設定メニューが表示されていないため、 [システム] > [表示機能設定] を開き、「その他の機能」列にある [Local Inポリシー] のスイッチをオン(緑色)

b) [ポリシー&オブジェクト] > [ローカルインポリシー] を開く
c)画面上部の [新規作成] をクリックし、以下の通り設定。

d)それ以外のすべての通信を拒否するルールの作成
上記で許可したIPアドレス以外からの通信をすべて遮断するための「暗黙の拒否」ルールを作成します。
e)ファイアウォールポリシーは上から順番に評価されます。設定完了後、「カスタム」セクション内に作成した2つのルールが以下の順番に並んでいることを確認。

4.4 FortiClient側の設定
a)FortiClientを起動し、「新規VPN接続」の設定画面(または既存設定の編集画面)を開きます。
b)画面上部のタブで「IPsec VPN」が選択されていることを確認し、以下を入力。

| 項目 | 設定 | 備考 |
|---|---|---|
| フェイルオーバーSSL VPN | なし | IPsec VPNが何らかの理由で繋がらない場合、自動的にSSL-VPNでの接続に切り替え(フェイルオーバー)する機能 |
| Single Sign On Settings | チェックを外す(デフォルト) | SAMLを利用したモダンなシングルサインオン(SSO)認証を行うための専用設定で、使わない機能は無効にする |
c)詳細設定 > VPN設定
「+詳細設定」をクリックしてメニューを展開し、「VPN設定」の項目を以下のように指定します。以下、バージョンによって設定項目が若干異なる。


| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| IKE(バージョン) | バージョン2 | IKEの最新バージョンを使用することで、セキュリティ・安定性ともに向上するため。 |
| モード(メイン / アグレッシブ) | 設定不要(IKEv2選択時は項目非表示) | メインモード/アグレッシブモードは旧IKEv1用の設定。IKEv2では不要のため考慮しなくてよい。 |
| Address Assignment(アドレス割り当て) | モードコンフィグ | FortiGate側からVPNクライアントへ社内用IPアドレスやDNS情報を自動配布するために必要。 |
| Encapslation | Auto(UDP fallback TCP) | 基本は高速なUDP通信(Port 500/4500)を使用し、UDPが遮断されている場合は、自動的にTCP(Port 443)で接続 |
d)詳細設定 > フェーズ1

| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| IKEプロポーザル | 上段・下段ともに AES256/SHA256(または AES128/SHA256) | FortiGate側の設定と一致させるため。強固な暗号方式を使用すること。 |
| DHグループ | 20 と 21 を複数チェック | FortiGate側の設定と合わせるため。強力な暗号グループを使用する。 |
| DPD(デッドピア検出) | チェックを入れる(推奨) | 通信断を迅速に検知し、セッション残りを防ぎスムーズな再接続を可能にするため。 |
| NATトラバーサル | チェックを入れる(必須) | 自宅ルーターやテザリングなどNAT環境からVPN接続するための必須機能。無効にすると出先から接続できなくなる可能性が高い。 |
| ローカルLANの有効化 | チェックを外す(推奨) | 自宅LANと社内LANを同時接続するスプリットトンネル状態となり、感染端末を踏み台にされるリスクがあるためOFFが原則。 |
e)詳細設定 > フェーズ2

| 項目 | 推奨値 | 理由・解説 |
|---|---|---|
| IKEプロポーザル(暗号方式 / 認証) | AES256 / SHA256(または AES128 / SHA256) | FortiGate側のフェーズ2設定と一致させるため。強固な暗号方式を使用する |
| リプレイ検出を有効にする | ON(チェックを入れる) | 過去の暗号化パケットを再送信する「リプレイ攻撃」を防ぐための必須機能。デフォルトでON |
| Perfect Forward Secrecy(PFS)を有効にする | ON(チェックを入れる) | セッション鍵の安全性を高める現代VPNでは必須のセキュリティ設定 |
| DHグループ | 20 を選択(1つのみ) | PFSを有効にすると選択可能。強力な暗号グループである20を選択する |
| 鍵の有効期間 | 43200秒(12時間)のまま | デフォルト値で問題なし。セキュリティと再接続頻度のバランスが取れている |
f)接続の確認
・設定が保存されると、接続画面に戻ります。
・VPN名称のプルダウンから作成した IPsec-VPN を選択。
・パスワード欄に、設定したユーザ(ipsec-vpn_user)のパスワードを入力して、「接続」ボタンをクリック
・正常にトンネルが確立される(メーターや接続時間が表示される)ことを確認

4.3 移行ウィザードの活用
・FortiGateがFortiOS 7.6にアップグレード済みであれば、「SSL VPN to IPsec VPN Migration」という移行ウィザード(GUI)が使えます(ただし、バージョン/機種依存)。
・SSL-VPN用に作っていた「どのユーザーグループに、社内のどのサーバーへのアクセスを許可するか」という複雑なポリシー群や、IPアドレスプールの設定を、そっくりそのままIPsec用に自動生成・複製してくれます。
・ただし、ウィザードが生成する暗号化設定(フェーズ1/フェーズ2のプロポーザル)を、あとからGUIまたはCLIで確認し、不要な弱い暗号化方式のチェックを外すなどの調整が必要です。
4.4 TCPの443番を使った通信
※IPsec over TCPはEMS版FortiClientで正式サポートされており、無償版では基本的に使えません
(1)ESPやUDPによる接続制限
IPsecは基本的にはESPというプロトコルを使います。しかし、ESPというプロトコルは多くのファイアウォールで拒否されているため、NAT Traversalを活用してUDPを使って通信をします。
よって、先の4.2の手順で実施した場合の利用プロトコルとポートは以下です。
| NAT-Tの設定 | ① 認証・鍵交換(IKE) | ② 暗号化データ(ESP) | 必要なFWの許可設定(WAN側) |
|---|---|---|---|
| OFF(拠点間VPN等) | UDP 500 | IPプロトコル 50 | UDP 500 および IPプロトコル 50 |
| ON(推奨)(リモートワーク) | UDP 500 → 4500 通信経路にNAT(自宅ルーターなど)がいることを検知した瞬間にUDP 4500番へ変更 |
UDP 4500 | UDP 500 および UDP 4500 |
(2)課題と解決策
・IPsecに移行すると、上記のように標準はUDP 500/4500番を使います。すると、このポートがFWでブロックされているネットワークから接続する人もいるのです。
・「SSL-VPNの時は出張先のホテルから繋がったのに、IPsecに変えたら弾かれて繋がらなくなった」という声があるかもしれません。
・そこで、「IPsec over TCP 443」です。この設定を入れておけば、IPsecのセキュリティを保ったまま、SSL-VPNと同じでどこからでも繋がる利便性(TCP 443)』を再現できます。
・FortiClient 7.0以降でIPsec/TCPに対応しており、特に7.4以上の最新版使用が推奨
・それほど実績が多いわけではありません。
・IPsec over TCPはEMS版FortiClientで正式サポートされており、EMSライセンスが事実上必須となります。つまり、無償版(VPN-only版)では基本的に使えません。※無償版と有償版は、ダウンロードして使用するインストールファイル自体が別物です。

4.5 セキュリティを高める設定
既に述べた内容と重複しますが、改めて整理します。
(1)認証強化
・Client-to-SiteでIPsec-VPNを利用する場合はMFA(メール、証明書、FortiTokenなど)を必ず利用する。※ただし、二要素認証は、脆弱性を突かれたら意味がない。
(2)送信元IPアドレス制限
・Local-In Policyによる送信元IPアドレス制限を行う。送信元IPアドレスを偽装してIKEのネゴシエーションはできないので、非常に強固な防御策
・Local-In Policyは、デフォルトではFortiGateのGUI画面に表示されません。もし設定内容をGUI上でも確認できるようにしたい場合は、CLIで以下のコマンドを入れると、GUIの「ポリシー&オブジェクト」メニュー内に「ローカルインポリシー」が表示されるようになります。
config system settings
set gui-local-in-policy enable
end
||
❶通信相手がわかっている場合
・通信相手のIPアドレスが固定IPアドレスであり、わかっている。または、接続の都度、通信相手のIPアドレスを確認する。
【設定概要】
・許可する「特定のIPアドレス」のオブジェクトを作成する。GUIでも設定可能
>||
config firewall address
edit "Allowed_IPsec_Source"
set type ipmask
set subnet 203.0.113.50 255.255.255.255 # ←許可したい特定のIPアドレス
next
end・2. Local-In Policyを設定する(IKEへの着信制限)
config firewall local-in-policy
edit 1
set intf "wan1" # ←インターネット側の公開インターフェース
set srcaddr "Allowed_IPsec_Source" # ←先ほど作った特定IPのオブジェクト
set dstaddr "all"
set service "IKE" # 重要:UDP 500 / 4500 を含む標準オブジェクト
set action accept
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "all"
set dstaddr "all"
set service "ALL" # ALLにしないとうまくいかない可能性あり
set action deny
set schedule "always"
next
end
❷GeoIPにより日本国内のみを許可する
※ただし、踏み台経由で通信されたら意味がないので、効果は限定的。
【設定概要】
・GeoIPオブジェクトの作成: 日本国内(または業務を行う特定の国)のみを含むアドレスオブジェクトを作成します。
config firewall address
edit "Japan"
set type geography
set country "JP"
next
end・Local-Inポリシーの適用: GeoIPオブジェクトからの IKE (UDP 500/4500) を許可し、それ以外は拒否。
config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "Japan" <-- 許可する国またはIPリスト
set dstaddr "all"
set service "IKE" <-- UDP 500, 4500を含むサービス
set action accept
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "all"
set dstaddr "all"
set service "IKE"
set action deny <-- それ以外はプロセスに到達させずに破棄
set schedule "always"
next
endこの設定により、攻撃対象領域を地理的に限定し、海外からの無差別な脆弱性スキャンを無効化できます 。
(3)IKEおよび暗号化設定の最適化
IPsecの設定自体も、現代の基準に合わせて強化する。
| 設定項目 | 内容 | |
|---|---|---|
| IKEv1の無効化 | IKEv1(特にAggressive Mode)は、事前共有鍵(PSK)のハッシュを盗聴されやすく、辞書攻撃に脆弱です。必ず IKEv2 のみを使用 | |
| 強力な暗号化スイートの強制 | DES, 3DES, SHA1, MD5などのレガシーアルゴリズムは排除し、AES-256-GCM および SHA-256 以上を使用 | |
| PFS (Perfect Forward Secrecy) の有効化 | Diffie-Hellmanグループ(DH Group)は19,20,21(ECC)を使用し、万が一鍵が漏洩しても過去の通信が解読されないようにする |
【参考】DH(Diffie-Hellman)グループ
| DHグループ | 方式 | セキュリティ強度 | 現在の評価と実務での扱い |
|---|---|---|---|
| 2, 5 | MODP | 弱い(解読可能) | 完全非推奨。脆弱性が確認されています |
| 14 | MODP(2048-bit) | 最低限 | 旧世代の標準(互換性用)。古い端末を接続させるために残されることが多いですが、新規構築では推奨されません |
| 19 | ECC(256-bit) | 高い | 現代の標準(推奨)。非常に高速で安全。一般的な企業VPNのベストプラクティスです |
| 20 | ECC(384-bit) | 非常に高い | 高セキュリティ(強く推奨)。米国政府のセキュリティ基準(NSA Suite B)にも準拠するレベル。今回設定された大正解のグループです |
| 21 | ECC(521-bit) | 最強(過剰) | オーバースペック。強度は最強ですが、計算処理が重くなり、接続時の遅延やスループット低下を招くため、通常は選びません |
4.6 ZTNAやFortiSASE
詳細は後述
5.IPsecは果たして安全か
5.1 そもそも、なぜIPsecなら安全なのか
❶プロトコルおよび処理レイヤーの違い
IPsec(Internet Protocol Security)は、OSI参照モデルのネットワーク層(レイヤー3)とIKE(UDP500および4500)で動作し、SSL-VPNはアプリケーション層(レイヤー7)で動作します。これは、ファイアウォール上で「Webブラウザ向けのアプリケーション」を動かしているのと同じ状態です。セキュリティ機能を提供するはずのファイアウォールが、最も複雑で攻撃を受けやすいアプリケーション層の処理を引き受けてしまっています。
❷「Webサーバーとして振る舞う」という構造的弱点
・SSL-VPNの場合
Webサーバー(SSL-VPN)は、ログイン画面を表示するために、送られてきたHTTPリクエストの中身(URL、Cookie、User-Agentなどの文字列情報)をすべて読み込み、その意味を解析(パース)しなければなりません。文字列を解釈しようとしてメモリ領域があふれ(バッファオーバーフロー)、その拍子に紛れ込ませた不正コードが実行されてしまいます。これが「認証前」に起きてしまうのが致命的です。
・IPsecの場合
IPsecは「鍵」が合わないパケット、規定のサイズや構造と異なるパケットは、中身を解釈することなく即座に破棄(ドロップ)します。複雑な文字列解析を行わないため、付け入る隙が極めて少ないのです。
参考 NSAとCISAによる発表
■IPsecの推奨
「NSAおよびCISAは、VPN向けの標準化されたセキュリティ要件に対して検証済みの標準化されたインターネット鍵交換/インターネットプロトコルセキュリティ(IKE/IPsec)VPNを推奨します。」
NSA and CISA recommend standardized Internet Key Exchange/Internet Protocol Security (IKE/IPsec) VPNs that have been validated against standardized security requirements for VPNs.
■SSL/TLS VPNを非推奨
「非標準のVPNソリューション(Secure Sockets Layer/Transport Layer Security(SSL/TLS)VPNと呼ばれる製品群を含む)の選択は避けてください。
これらの製品には、TLS経由でトラフィックをトンネリングするためのカスタムかつ非標準の機能が含まれています。カスタムまたは非標準の機能を使用すると、製品で使用されるTLSパラメータが安全であっても、追加のリスクに晒されることになります。」
Avoid selecting non-standard VPN solutions, including a class of products referred to as Secure Sockets Layer/Transport Layer Security (SSL/TLS) VPNs. These products include custom, non-standard features to tunnel traffic via TLS. Using custom or non-standard features creates additional risk exposure, even when the TLS parameters used by the products are secure.
出典:NSA(米国家安全保障局)とCISA(米サイバーセキュリティ・社会基盤安全保障庁))による発表(2021年9月28日付)
https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/csi_selecting-hardening-remote-access-vpns-20210928.pdf
5.2 SSL-VPNの脆弱性の脅威
過去5年間、Fortinet製品に対する攻撃の大部分はSSL-VPN機能を標的としてきました。特筆すべきは、それらの多くが「認証不要(Pre-authentication)」で「リモートコード実行(RCE)」が可能であったという事実です。これは、攻撃者がIDやパスワードを持たずとも、外部からパケットを送信するだけでファイアウォールの制御権(root権限)を奪取できることを意味します。
■代表的な致命的脆弱性 ・CVE-2022-42475 (CVSS 9.8 - Critical) sslvpndにおけるヒープベースのバッファオーバーフロー脆弱性です。特細工されたHTTPリクエストを処理する際のメモリ管理不備を悪用し、認証なしで任意のコード実行が可能でした。この脆弱性は「ゼロデイ」として実際に悪用されました 。 ・CVE-2023-27997 (CVSS 9.8 - Critical) 通称「XORtigate」と呼ばれるこの脆弱性も、SSL-VPNのWebポータル処理におけるヒープオーバーフローでした。MFA(多要素認証)が有効であっても、MFAの処理が行われる「前」にメモリ破壊が発生するため、防御不可能でした。この脆弱性は、ランサムウェアグループによる初期侵入経路として広く悪用されました 。 ・CVE-2018-13379 (CVSS 9.8 - Critical) パストラバーサル(ディレクトリトラバーサル)の脆弱性であり、認証なしでシステムファイル(sslvpn_websessionなど)を読み取ることが可能でした。これにより、ログイン中のユーザーの平文パスワードが流出する事態となりました 。
5.3 FortiGateにおけるこれまでのIPsecの脆弱性
一方、IPsec VPN(iked)に関連する脆弱性は、その性質と影響度がSSL-VPNとは大きく異なります。IPsecなら絶対に安全とは言えませんが、攻撃の難易度と前提条件がより厳しい傾向にあります。
■IPsec関連の主な脆弱性 ・CVE-2024-46669 (CVSS 3.5 - Low/Medium) IKEサービスにおける整数オーバーフローの脆弱性です。これによりikedプロセスがクラッシュし、DoS(サービス拒否)状態になる可能性があります。しかし、この脆弱性を悪用するには認証済みの攻撃者である必要があります。つまり、攻撃者はすでにVPNの認証情報を盗み出しているか、内部犯である必要があり、外部からの無差別攻撃には利用できません 。 ・CVE-2023-46715 (CVSS 4.7 - Medium) IPsec VPNにおけるオリジン検証エラーです。認証済みのユーザーが、他のユーザーのIPアドレスになりすましてパケットを送信できる可能性があります。これも認証済みユーザーに限定された攻撃であり、システム全体の掌握(RCE)には直結しません 。 ・CVE-2025-58413 (CVSS 7.5 - High) 比較的最近報告されたスタックベースのバッファオーバーフロー脆弱性であり、認証なしでRCEが可能となるリスクがあります。これはIPsecの実装においてもメモリ破壊系の脆弱性が起こり得ることを示していますが、SSL-VPNの頻発する脆弱性と比較すればレアケースであり、また攻撃にはバイナリパケットの精巧な操作が必要となるため、HTTPリクエストを悪用するものより技術的ハードルが高いとされます 。
・以下は、Fortinet社のPSIRTのサイト。脆弱性情報が確認できる。
https://www.fortiguard.com/psirt
【IPsecで検索】
CriticalとHighを探すと2件しかない。そのうち、画面の下側のはFGFMの内容なので、実際にはHighの1件しかない。また、そのHigh内容も、DDoSの影響などであり、今回のSSL-VPNの任意のコードが実行できるものはない。

【sslvpnで検索】
CriticalとHighを探すと11件。その中で、Criticalが4件で、先に述べた重大な脆弱性のCVE-2023-27997などもある。

| 比較項目 | SSL-VPN | IPsec |
|---|---|---|
| 悪用条件 | 認証不要で攻撃できた例が多数有り | IKEフェーズ1で厳密なパラメータ交換を行うので、事前共有鍵などがないと攻撃はほぼ不可能 |
| 攻撃手法 | HTTPリクエストの操作 | IKEパケットの操作 |
| 影響度 | 完全なシステム掌握 SSL-VPNの侵害は即座に組織全体の脅威となる |
サービス停止 (DoS) やなりすまし |
| 補足 | HTTP/HTTPSプロトコルを使用する、これはテキストベースであり、攻撃者はWebブラウザやBurp Suite、curlなどの一般的なツールを使って簡単に異常なデータを送り込むことができ、Fuzzing(検査ツールによる総当たり攻撃)も容易 | IKEはUDP上のバイナリプロトコルであり、パケット構造や状態遷移が厳格。攻撃するのは非常に困難 |
■注意点
ただし、Cisco ASAシリーズのソフトウェアにおけるVPN接続の「IKEv1」「同v2」処理に存在する脆弱性があったので、IPsecは脆弱性を突かれることが無いとは言えない。
https://www.security-next.com/066862
5.4 IPsecで代用できるのか
| Q.ホテルなどのWifiではIPsecが使えないのではなかったか |
従来のIPsec、TCPではなくESPをを使用するため、接続できないことがよくありました。
そこで、そこで、NAT TraversalおよびUDP Encapsulation of IPsec Packets(UDP4500)を使い、ESPではなくUDPにして通過できるようにしました。
ですが、少し前から、 多くのホテルや公衆Wi-Fiのゲストネットワークでは、Firewallが導入され、Web閲覧(TCP 80/443)以外の通信を遮断する設定が増えています。そこで、FortiOSとFortiClientに実装されている「IPsec over TCP」機能です。 FortiOS 7.0以降およびFortiClient 7.0以降では、IKEv2パケットおよびESPペイロードをTCPヘッダーで包み込み、ポート443(または任意のTCPポート)で通信させる機能が実装されています。
5.5 IPsecにすれば安全というものではない【重要】
SSL-VPNからIPsecへの移行は、深刻な脆弱性リスクを低減し、アタックサーフェス(攻撃対象領域)を縮小するための非常に有効な手段です。
しかし、「IPsecにすれば絶対に安全」というわけではありません。トータルセキュリティと継続的運用が重要です。
❶プロトコルへの過信は禁物
・IPsecの基盤技術そのものは堅牢ですが、すでに述べた通り、IPsecの鍵交換プロトコルでも深刻な脆弱性が報告された事例があります。
❷リスクを低減する仕組みの実装
・IPsecへ移行したからといってパッチ適用を怠ってよいわけではありません。利用するVPN機器やクライアントソフトウェアの定期的なファームウェア更新が不可欠です。
・また、強固なMFA、最小権限アクセスの適用、IPアドレス制限なども重要です。
❸構築前後のセキュリティテストと継続的なモニタリング
・必要に応じて専門家によるペネトレーションテスト(侵入テスト)を実施し、安全性を実証してから本番運用を開始することが強く推奨されます。
・稼働後も、不正なログイン試行や異常な通信パターンがないか、日々のログ監視(モニタリング)を行う「運用」がセキュリティの要となります。
❹根本的なリスク低減
もし、リモートアクセスをせずとも、保守は現地で実施するなどの運用変更が可能であれば、そもそもリモートアクセスを無くすことが最も安全です。
6.メーカー対応
6.1 いつまでの対応すべきかについて
(1)ソフトウェアのライフサイクル
| フェーズ | 名称 | 意味 | 内容 | 期間の目安 |
|---|---|---|---|---|
| 1 | GA (General Availability) | 一般利用可能 | リリース開始。フルサポート状態 | 約36ヶ月(3年) |
| ↓ | ||||
| 2 | EOES(End of Engineering Support) | エンジニアリングサポート(開発修正)の終了 | 新機能や通常のバグ修正が終了。脆弱性パッチのみ提供される | さらに約18ヶ月(1.5年) |
| ↓ | ||||
| 3 | EOS(End of Support) | 全サポートの完全終了(EOL) | 使用停止推奨 | ― |
(2)EOESとEOSの主な違い
| 項目 | EOES (End of Engineering Support) エンジニアリングサポート終了 |
EOS (End of Support) サポート終了 |
|---|---|---|
| 主な意味 | 開発部門による開発・修正が終了する。 ただし、致命的な問題のみ例外対応される。 |
メーカーからの全ての支援が停止する。 使用し続けることは極めて危険。 |
| バグ修正 | △ 致命的な不具合・重大な脆弱性のみ修正 | × 一切修正されない |
| シグネチャ更新 (AV/IPS等) |
○ 継続して提供される | × 配信停止 |
| 技術問合せ | ○ 可能(ただし調査は既知事例ベース) | × 受付不可 |
| 目安時期 | ソフトウェア(OS)のリリースから約36ヶ月後 | ハードウェアの販売終了から5年後 ソフトウェアのリリースから約54ヶ月後 |
一言で言うと
・EOES:新機能や通常のバグ修正は止まるが、セキュリティパッチ(重大なもの)は出るため、移行準備期間として使える。
・EOS:セキュリティパッチもシグネチャも完全に止まるため、この日までに更改必須。
6.2 OSの強制アップデート
(1)概要
・FortiOS 7.4.8 および 7.6.4 より、特定の条件下にある機器のOSを「最新のパッチバージョン」へ強制的に自動アップグレードする機能が追加されました。
・発動条件:
以下のいずれかに該当した場合に強制実行されます。
| ・機器のサポート契約が無効(ライセンスが失効)になった場合 ・OSが End of Engineering Support(EOES)を迎えた場合 |
・アップグレードの範囲(仕様):
現在のマイナーバージョン内での「最新パッチバージョン」へのアップデートのみが行われます(例:7.4.8 → 最新の 7.4.x)。
※勝手に 7.4.x から 7.6.x や 7.8.x などの別のマイナー・メジャーバージョンへと飛躍してアップグレードされることはありません。
(2) 目的と背景
| Q.目的は?なぜこんなことをするの? |
→EOESの状態は変わらないが、そのバージョンにおける既知の脆弱性は塞がれた状態になります。
・アップデートは「完全ランダム」ではなく、機器で指定した開始~終了時間の枠内で、アクセス集中を防ぐために分散(ランダム)実行される。
(3)ケーススタディ
✅ ケース1:EOSEOES(サポート終了)を迎えた場合
2026/5/11にEOESを迎える → 機器が定期通信で判定し、数日以内(5/14頃など)に最新パッチ(例: 7.4.9)へ強制アップグレードされます。
✅ ケース2:ライセンス(サポート契約)が切れた場合
2026/2/10にライセンス切れ → 2/13頃に7.4.9へ強制Update

※重要なポイント:「7.4.3 → 7.4.9」 という動きになり、「7.6.x」のような別系統へ勝手に飛躍しません。(アップデートの範囲は3桁目のみ)
(4)実行スケジュールの調整と状態確認
強制アップグレードが走る場合でも、業務影響を抑えるために実行される曜日や時間帯をあらかじめ指定しておくことが可能です。
■ ①自動アップデートの事前設定(スケジュールルールの作成)
アップグレードが実行される際の基本ルールを設定します。
※CLIの「config system fortiguard」階層で設定します。
config system fortiguard
# 自動アップグレード機能の有効化
set auto-firmware-upgrade enable
# 実行する曜日(例: 日曜日)
set auto-firmware-upgrade-day sunday
# 実行開始・終了時間(例: 深夜2時~5時)
set auto-firmware-upgrade-start-hour 2
set auto-firmware-upgrade-end-hour 5
# リリース後の遅延日数(例: 3日待つ)
# ※何も設定していない時はデフォルトの「3日後の午前2時-4時内」で更新されます。
set auto-firmware-upgrade-delay 3
end※注意:仕様上、「曜日(day)」と「遅延日数(delay)」は両立しません。遅延日数(delay)を設定した場合、その日数が経過したタイミングが優先され、曜日設定は上書き(無視)されます。
■ ②強制アップグレード対象の確認
現在の機器が強制アップグレードの対象になっているかは、以下のコマンドで確認できます。
※設定モード(config)を抜け、一番上の階層で実行します。
diagnose debug application forticldd
※結果の「Auto image upgrade」項目に「(Forced)」と記載があると強制アップグレードの対象です。
(5)強制アップグレードの停止・延期について
Q. CLIから「set auto-firmware-upgrade disable」を設定すれば、強制アップグレードを止められますか?
A. 止められません。(設定自体は入りますが、システムに無視されます)
通常の自動アップデートであればこのコマンドで無効化できますが、サポート切れやEOESに伴う「強制アップグレード条件」に合致してしまった場合、この disable 設定はオーバーライド(無視)され、強制的にアップデートがスケジュールされます。
■ 唯一の延期方法(ディレイコマンド)
検証が終わっていない等、どうしても強制アップグレードを避けたい(延期したい)場合は、以下のコマンドを利用します。
execute auto-upgrade delay-installation
- 効果:強制アップグレードのスケジュールが組まれた状態でも、インストールを「7日間固定」で延期することができます。
- 注意:アップグレードが実際に実行される前であれば何度でも実行可能ですが、恒久的に止めるコマンドは存在しないため、継続して延期したい場合は定期的に(7日ごとに)実行し続ける必要があります。
(6)システム管理者の対応
簡単に言うと、「EOESを迎える前に、計画的なアップグレード(移行)の実施」をする必要があるということです。なぜなら、今回の変更により、意図しないタイミング(デフォルトでは条件合致から3日後の深夜帯など)で機器の再起動が発生し、業務影響が出るリスクがあるからです。
7. リモートアクセスのロードマップとゼロトラスト(ZTNA)機能
7.1 概要
(1)リモートアクセスの将来的なステップ
❶VPNの強化
脆弱性の多いSSL-VPNなどを廃止し、よりセキュアなIPsec-VPNに移行
❷ZTNAへの移行
クラウドを使わず、また、オンプレのFortiGateを使ったまま、アクセス制御だけを強化。
ネットワーク単位のVPNから、FortiClient EMS等を使ったアプリ単位のZTNAへ切り替え
❸SASEへの移行
クラウドのFortiSASEに移行

(2)Fortinet ZTNAとFortiSASE
違いを表にします。
| 比較ポイント | Fortinet ZTNA(オンプレミス型) | FortiSASE(クラウド型) |
|---|---|---|
| 一言でいうと | VPNを置き換えるアクセス制御機能 | リモートワーク用の総合セキュリティ拠点 |
| セキュリティの場所 | 自社のFortiGate | Fortinetのクラウド上 |
| 守る対象の通信 | 主に「社内システム」へのアクセス | 「インターネット」「SaaS」「社内」すべて |
| 含まれる機能 | アプリ単位のアクセス制御、端末ポスチャチェック | ZTNA機能、Webフィルタ、CASB、クラウドFW、DLPなど |
| 導入のハードル | 既存のFortiGate+EMSがあればすぐ始められる | 新規でクラウドサービスの契約・設計が必要 |
7.2 ZTNA
(1)ZTNAアーキテクチャの構成要素
Universal ZTNAは以下の3つのコンポーネントが連携して動作する。
❶FortiGate
・従来のファイアウォール機能に加え、「アクセスプロキシ(Access Proxy)」として動作する。外部からの接続要求を受け取り、認証とポスチャ(健全性)チェックを行った上で、内部のアプリケーションサーバーへ代理接続する。ユーザー端末と内部サーバーが直接IP通信することはない 。
・追加ライセンス不要(機器標準機能)
❷FortiClient EMS
・ エンドポイントの管理サーバー。クラウド版(FortiClient Cloud)またはオンプレミス版
・各端末からテレメトリ情報(OSバージョン、パッチ適用状況、AV稼働状況など)を収集し、それに基づいてZero Trust Tag(例:Corporate_PC, High_Risk, Patched)を動的に割り当てる。このタグ情報はリアルタイムでFortiGateに同期される 。
❸FortiClient
・有償版クライアントソフトで、「FortiClient EMS」のサブスクリプションライセンス(利用する端末数に応じた課金)が必要にです。
・エンドポイント上で動作し、EMSへ情報を送信するとともに、ユーザーがアプリケーションへアクセスする際に、デバイス証明書を提示して相互TLS(mTLS)認証を行う 。
(2)FortiClient EMSの3つの重要機能
ZTNAを実現する上で、EMSが重要な役割を担います。
| 機能 | 内容 |
|---|---|
| 端末の状態監視(ポスチャーチェック) | 各PCのFortiClientからテレメトリ情報を収集し常に状態を把握する |
| ZTNAタグの付与とFortiGateへの共有 | 収集した情報をもとに端末へZTNAタグ(ラベル)を付与しFortiGateへ連携する |
| ポリシー(設定)の一括配布 | EMSの管理画面からセキュリティ設定やルールを端末へ一括配布する |
(3)IPアドレスベースからタグベース(ZTNA型)による制御
❶従来型VPN:IPプール方式
a)認証: ユーザーがVPNにログインする。
b)IP付与: 所属グループ(例:営業部)に応じて、ファイアウォールがIPプール(例:10.0.1.x)からIPアドレスを払い出す。
c)FWポリシー: ファイアウォールにはIPアドレスベースでルールを書く。
| ▼ この方式の限界(弱点) ・IPアドレス=安全性ではない: 10.0.1.xというIPアドレスをもらえれば、そのPCがウイルスまみれでも通信できてしまう ・管理が限界: 部署や役職が増えるたびに細かいIPプールを作り、複雑なルーティングとFWポリシーを管理しなければならず、運用が破綻しがち |
❷ZTNA:タグ+ID方式
実際のFortiGateの設定画面(ZTNAルール)では、送信元IPの代わりに「ユーザー情報」と「ZTNAタグ」を直接指定して制御します。
a)ID認証: SAML(Entra IDなど)でユーザを認証
b)状態確認: EMSから送られてきたタグ情報を確認
c)ZTNAポリシー: FortiGateには「送信元IP」を書く欄すらなく、ユーザIDとタグによるルールを書く
(4)ZTNAタグの実態
・ZTNAタグは、VLANなどのようにフレームに付与されるものではありません
・ZTNAの通信において、デバイス証明書によってタグが識別されます。このデバイス証明書は、TLSプロトコルにおける「クライアント証明書(Client Certificate)」と全く同じ位置づけです。
・ブラウザには「セッションCookie」が付与される。そして、以降のHTTPリクエストは、TLSのセッション管理に加えて、このCookieによってユーザを識します。
(5)ZTNAの動作フロー
a)ユーザーが https://crm.company.com にアクセス。
b)DNSはFortiGateのWAN IP(VIP)を返す。
c)FortiClientがFortiGateに対してTLS接続を開始し、デバイス証明書を提示。
d)FortiGateは証明書の正当性と、EMSから同期されたZTNAタグを確認(例:タグがCompliantであるか)。
e)ポリシーに合致すれば、FortiGateが内部サーバーへ接続を中継する。
※マイクロセグメンテーション: ユーザーには内部ネットワークのIPアドレスが付与されないため、VPNのようにネットワークスキャンを行ったり、許可されていないサーバーへ横展開(ラテラルムーブメント)したりすることが物理的に不可能となる 。
(3)技術構成詳細:ZTNAの実装
ZTNAの実装には、EMSとFortiGateの連携(Fabric Connector)が必須となる。
❶ステップ1:EMSでのタグ定義
EMS管理画面にて、「Zero Trust Tagging Rules」を作成する。
ルール例:「Windows Defenderが有効」かつ「ドメイン参加済み」の場合 → タグ Low_Risk を付与。
❷ステップ2:FortiGateでのプロキシ設定
CLIを用いたアクセスプロキシの設定例:
・ファブリックコネクタの設定(EMS連携)
config system csf
set status enable
set group-name "SecurityFabric"
end
config endpoint-control fctems
edit "EMS_Server"
set server "192.168.10.10" # EMSのIP
set https-port 443
set certificate "Fortinet_Factory"
next
end・ZTNAサーバー(VIP)の設定
config firewall access-proxy
edit "Web_App_Proxy"
set vip "Public_VIP_Object"
set client-cert enable # デバイス証明書の要求
config api-gateway
edit 1
set url-map "/crm"
set service https
config realservers
edit 1
set ip 10.0.1.50
set port 443
next
end
next
end
next
end❸ZTNAルールの設定(ポリシー)
Bash
config firewall proxy-policy
edit 1
set name "Allow_CRM_Access"
set proxy access-proxy
set access-proxy "Web_App_Proxy"
set srcintf "wan1"
set srcaddr "all"
set dstaddr "all"
set ztna-ems-tag "Low_Risk" # EMSタグによる制御
set action accept
set schedule "always"
next
endこの設定により、「Low_Risk」タグを持つ端末のみがCRMへのアクセスを許可される。もし端末がウイルスに感染し、EMSがタグを外せば、即座にアクセスは遮断される 。
7.3 FortiSASE
(1)3つの機能
| 項目 | 意味 | 対象 | Zscalerでの対応 |
|---|---|---|---|
| SPA (Secure Private Access) | 社内へのアクセス | 社内のファイルサーバー、業務システム、イントラネットなど。 | ZPA (Zscaler Private Access) |
| SIA (Secure Internet Access) | Webへのアクセス | 一般的なWebサイトの閲覧など。(資料上部の青い矢印) | ZIA (Zscaler Internet Access) |
| SSA (Secure SaaS Access) | クラウドサービスへのアクセス | Microsoft 365、Box、SalesforceなどのSaaS。(資料左側の水色の矢印。CASBなどの機能で制御) | ZIA (Zscaler Internet Access) + CASB機能 |
(2)FortiSASEに必要なもの
社内サーバー(プライベートアプリ)にアクセスするため必要なのは以下の3つです。
| 項目 | 役割 | 補足 |
|---|---|---|
| FortiSASE クラウド (PoP) | 通信のハブとなるFortinetのクラウド基盤 | FortiSASEのライセンスは、ユーザー単位の年間サブスクリプションです。 規模にもよりますが、年間1ユーザで2万とか、それくらいが軸かと |
| FortiClient | ユーザー端末からFortiSASEへトンネル接続するソフトウェア | |
| FortiGate | ZscalerのApp Connectorの代替となる役割 |

(2)社内のサーバに接続する際の通信経路
リモート端末から社内サーバーまでの通信経路は、ハブ&スポーク型のネットワーク通信になります。
a)リモート端末 (PC) からインターネット を経由して最寄りの FortiSASE PoP(クラウド) に接続。※443ではなくIPsec
b)FortiSASEから、本社のFortiGate(ハブ) へルーティング ※通信はIPsecトンネルの中を通る
c)本社のFortiGateから、社内サーバー または 支店のFortiGate(スポーク) へ通信が届く。
※FortiSASEはADVPN(Auto Discovery VPN)をサポートするため、有効にした場合は本社HUBを経由せずにPOPから支店のFortigateへの直接通信が可能。(スポークtoスポーク)
(3)Zscalerとの違い
| 比較項目 | Zscaler (ZPA) | FortiSASE (SPA) |
|---|---|---|
| アーキテクチャ | アプリケーション・アクセス(特定アプリのみ通信を中継) | ネットワーク・アクセス(クラウド型拠点間VPN) |
| 社内に置く機器 | App Connector (VM等のソフトウェア)軽量な仮想マシンなど。 | FortiGate (FW/VPNゲートウェイ)物理アプライアンスまたは仮想FW。 |
| 通信の方向 | 社内からクラウドへの片方向(アウトバウンドTLSトンネルのみ) | 双方向 (IPsecトンネル)標準的なルータ間VPN通信。 |
| 社内側のポート公開 | 不要(インターネットからの着信を全遮断可能) | 必要(IPsecを張るためのグローバルIPやポート待受が原則必要) |
| メリット | 社内ネットワークを完全に隠蔽できる。インフラ依存が少ない。 | 既存のFortiGate等のインフラやネットワーク設計(ルーティング等)をそのまま活かせる。 |
【参考】FortiSASEの構成

【参考】Zaclaerの構成

8.UTMのセキュリティ設定
8.1 概要
・最近、ランサムウエアの被害が増えていますが、内部のラテラルムーブメントであったり、C&Cサーバへの通信防御のために、FortiGateの設定を見直すことは非常に有効です。
・たとえば、潜入に成功したマルウェアは、攻撃者の指令を行うC&C(Command & Control)サーバと通信を行います。そこで、内から外への通信の強化(FW、IPS、URLフィルタ、アプリケーションコントロールなど)、ログの設定とアラートをしっかりするだけでも、効果(防げる、または気づける)があります。
・攻撃を気づければ、被害を最小限にするためのアクションを実施できます。
※今回、設定は厳しめになっているので、運用をしながらチューニングも必要かと思います。

8.2 ファイアウォール(FW)ポリシー
(1)概要
・多くの企業では、社内からインターネットへ向かう「Outbound(中から外)」のポリシーが、非常に雑になっている場合があります
・たとえば、FWの更改をするときに、お客様とポリシーを見直すのですが、何千行ものポリシーがあったりします。
「これ、残しますか?」
と聞くと、
「わからないから残しましょう」
と言われることがよくあります。それは危険です。
そこがセキュリティホールになったりします。
・また、サーバからインターネットの通信ですが、送信元IPアドレスだけを制限し、あて先はANYにする場合があります。これだと、サーバが乗っ取られると、C&Cサーバに自由に通信できてしまいます。仮にWindowsのUpdateだけしかインターネットに接続する必要が無いのであれば、そこに限定します。
(2)実際の設定
・送信元、あて先IPを、ANYではなく、IPアドレスおよびポートで細かく設定します。必要最小限にします。
・仮にWindowsのUpdateだけしかインターネットに接続する必要が無いのであれば、ファイアウォールポリシーにて、ISDBを使ってMicrosoft-Windows.Update や Microsoft-Web などを許可、または、FQDN(ワイルドカードドメイン)で、「*.update.microsoft.com」を指定します。
・Geo-IPによる通信制御: 業務で通信する必然性のない国や地域への通信(インバウンド・アウトバウンド共に)をオブジェクト化し、FWポリシーの最上位でブロックします。
(参考)[ポリシー&オブジェクト] > [アドレス] から新規オブジェクトを作成、タイプを「ジオグラフィ」に設定して、日本を選択

8.3 IPS(侵入防御システム)
・内部からから外へのポリシーに対してもIPSを有効にする
・Critical/Highシグネチャは、検知(Monitor)でなく、「Block」が望ましいであろう。
・シグネチャとしては、high_securityにすると、CriticalからMediumまでの広範囲な脆弱性をブロックします。ただ、正常な通信を止めてしまうリスクもあるため、実務ではテスト導入(モニタリング)を経てから適用することが推奨されます。

| オプション項目 | 現在の状態 | 推奨設定 | 機能概要 |
|---|---|---|---|
| 悪意のあるURLをブロック | OFF (無効) | ON (有効) | FortiGuardのデータベースに基づき、既知の悪意あるURL(マルウェア配布サイトなど)への通信をIPSエンジンレベルでブロックする。 |
| ボットネットサイトへの発信接続をスキャン | 無効 | ブロック | 社内ネットワークから、外部の既知のボットネットC&C(コマンド&コントロール)サーバに向けた通信を監視・制御する。 |
・こちらも、ファイアウォールポリシーにて、IPSを [オン] に。
8.4 Webフィルタ(URLフィルタリング)
・デフォルトのプロファイルで有効になっていると思うが、以下などの「Malicious Websites(悪意のあるWebサイト)」「Phishing(フィッシング)」「Spam URLs」のカテゴリをブロックする

・セキュリティリスクのカテゴリの説明は、以下
| カテゴリ名 | 内容 |
|---|---|
| 悪意のあるWebサイト | ウイルス(マルウェア)を配布しているサイトや、アクセスしただけでPCを感染させる攻撃プログラムが仕込まれている明確に危険なサイトをブロック |
| フィッシング | 銀行やSNSなどを装った偽サイトをブロック |
| スパムURL | 迷惑メールに記載されたリンク先のURLをブロック |
| ダイナミックDNS | 攻撃者がC&Cサーバー(指令サーバー)や踏み台として悪用しやすい、IPアドレスが頻繁に変わるドメインをカテゴリごと制限 |
| 新たに観察されたドメイン | 世界で初めて通信が観測されたばかりの未知のドメインをブロック |
| 新たに登録されたドメイン | 取得された直後のドメインをブロック(※短期間で使い捨てられるフィッシング用やスパム用のサイトへのアクセスを防ぐ) |
・こちらも、ファイアウォールポリシーにて、Webフィルタを [オン] に。
8.5 アプリケーションコントロール
デフォルトの通りであるが、Proxy(フリーProxyやTorなど)とP2Pをブロックする。


| オプション項目 | 現在の状態 | 推奨設定 | 機能概要 |
|---|---|---|---|
| デフォルト以外のポートで検知されたアプリケーションをブロック | OFF | ON | 標準とは異なる不審なポートを使用するアプリケーションの通信を強制的にブロック |
| DNSトラフィックの許可とログ | ON | ON | DNS(名前解決)の通信を自動的に許可し、そのアクセスログを取得 |
| HTTPベースアプリケーションの差し替えメッセージ | ON | ON | Webアプリがブロックされた際、ユーザーのブラウザに「会社ポリシーによりブロックされました」という警告画面を表示 ユーザーが「ネットワークエラー」と勘違いすることによる、ヘルプデスクへの不要な問い合わせを防ぐため。 |
・こちらも、ファイアウォールポリシーにて、アプリケーションコントロールを [オン] に。
8.6 SSLインスペクション
(1)Deep Inspection
Deep Inspection(フルSSLインスペクション)を有効にすることで、FWがクライアントとWebサーバの間に入り、通信を一度復号します。これにより、暗号化された通信内に潜むマルウェア、不正なスクリプト、機密情報の持ち出しをIPSやアンチウイルス機能で確実に検知・ブロックできる。
| UTMのセキュリティ機能 | Certificate Inspection(宛先・証明書のみ確認) | Deep Inspection(通信の完全復号) | Deep Inspectionが必要な理由・備考 |
|---|---|---|---|
| アンチウイルス (AV) / サンドボックス | ❌ 検査不可 | ⭕ 検査可能 | 暗号化された通信内でダウンロードされる「ファイル本体」をスキャンするには、中身を開く(復号する)ことが必須です。 |
| IPS (侵入防御) | ❌ 検査不可 | ⭕ 検査可能 | 通信データ(ペイロード)内に潜む脆弱性攻撃のエクスプロイトコードや、C&Cサーバとの不正なコマンド通信を検知するには復号が必須です。 |
| DLP (情報漏洩防止) | ❌ 検査不可 | ⭕ 検査可能 | 通信内の文字列(マイナンバー、クレジットカード番号、社外秘キーワードなど)や、持ち出されるファイルの中身を確認するには復号が必須です。 |
| ファイルフィルタ | ❌ 検査不可 | ⭕ 検査可能 | HTTPS経由でアップロード・ダウンロードされるファイルの拡張子(.exeなど)や種類を正確に識別しブロックするには復号が必須です。 |
| Webフィルタ | △(FQDNレベルは 判定可能) | ⭕ 判定可能 | example.com などのドメイン(ホスト名)までは、暗号化される前の「SNI(Server Name Indication)」情報を見ることで判定・ブロックが可能で、URLレベルは無理 |
| アプリケーションコントロール | △(一部可能) | ⭕ 詳細制御可能 | アプリケーションの「大まかな識別」は通信先のSNIや振る舞いで可能ですが、「Slackへのログインは許可するが、ファイルのアップロードは禁止する」のような細かいアクション制御には復号が必須です。 |
・こちらも、ファイアウォールポリシーにて、SSLインスペクションを [オン] に。
(2)除外設定(Exempt)
・すべての通信を復号すると、プライバシーの問題や技術的な不具合が生じるため、適切な「除外(Exempt)」設定が不可欠です。
・たとえば、オンラインバンキング(金融機関)や、個人の医療情報、クレジットカード情報などの通信
8.7 DNSフィルタ
社内のPCが危険なサーバーと通信しようとした際、DNS(名前解決)の段階で強制的にストップをかけ、安全な警告画面(ブロックポータル)へ誘導する設定を行います。
【設定】
・「ボットネットC&Cのリクエストをブロックポータルにリダイレクト」 を[オン] に
・「FortiGuardカテゴリベースのフィルタ」 が [オン] になっていることを確認する。
・カテゴリ一覧の 「セキュリティ・リスク」 グループを展開し、「悪意のあるWebサイト」 や 「ダイナミックDNS」 のアクションが [ブロックポータルにリダイレクト] に設定されていることを確認する。(※もし許可やモニタになっていれば、右クリック等で変更します)

・プロファイルを保存後、[ポリシー&オブジェクト] > [ファイアウォールポリシー] にて、該当のポリシーを編集、「セキュリティプロファイル」欄の [DNSフィルタ] を [オン] にして適用する。
8.8 ログおよびアラート設定と監視
・FWやIPS等で、拒否された通信のログを監視することで、内部で既にマルウェアが活動を開始し、外部へ接続しようとしている兆候を早期に発見できます。
・また、インターネットへ抜ける許可ポリシーのログ設定は、セキュリティイベントだけでなく、可能であれば すべてのセッションを取得します。後から判明した悪意のあるIPアドレスへの通信を追跡できます。ただし、「すべてのセッション」をログに記録すると、ログのデータ量が爆発的に増えます。そのため、FortiAnalyzer等へのログ転送が必須になるでしょう。

・Automation機能によるリアルタイムアラート設定をすることで、不正な通信に管理者が早期に気づくことが大事です。
・日常業務と並行して監視をするのは、特に夜間は限界があるので、SOCサービスを利用することが望まれます。
9.WEST-SECイベントに関して
9.1 イベント概要
Connpassの募集ページはこちら
| 項目 | 内容 |
|---|---|
| 日時 | 2026年4月14日(火) 19:00 - 21:00 |
| 会場 | オンライン |
| タイトル | FortiGateにおけるSSL-VPN機能の廃止について |
| 概要および目的 | FortiGateにおけるSSL-VPN機能の廃止に関する概要と、それに伴う対応方法(IPsec VPNへの移行や設定の無効化手順など)についての解説・学習 |
9.2 申し込み者および参加者
❶申込者 551名

❷参加者 385名

※途中で抜けて再度入った人の重複があると思います。
9.3 事前アンケート結果
■Q1. ご自身の立場について

■Q2. 貴社(またはご担当組織)における、リモートアクセスの利用範囲を教えてください。
■Q3.現在利用しているリモートアクセスの仕組みを教えてください。(複数選択可)

■Q5.リモートアクセス環境のセキュリティ対策として、現在実施しているものを教えてください。(複数選択可)
■Q6.リモートアクセスの運用・管理に関して、現在抱えている悩みや課題はありますか?
| カテゴリ | 件数 | 主な内容 |
|---|---|---|
| 脆弱性対応・パッチ適用の負荷 | 8 | パッチ適用タイミングの制約(夜間・休日)、停止できない環境、頻繁な更新、ゼロデイ攻撃への懸念 |
| FortiGate SSL-VPN廃止・IPsec移行の課題 | 5 | IPsec移行後の接続不安定、デバッグ困難、認証方式の代替対応 |
| 全般的なセキュリティ・脆弱性への不安 | 5 | VPNの脆弱性、接続後の同一セグメント問題、漠然とした不安 |
| ZTNA/SASE・ゼロトラスト化への関心と懸念 | 4 | ゼロトラスト化の推進意欲、SASE依存による可用性・障害リスク |
| 監視・運用・トラブル対応のノウハウ | 4 | 監視ポイントや調査手法の不明確さ、自宅回線トラブルの切り分け |
| コストに関する悩み | 3 | 投資判断の難しさ、SaaSの値上げ懸念、コスト負担 |
| 外部業者・アカウント管理 | 2 | 保守ベンダーや協力会社のアカウント管理の不備 |
| その他、特になしなど | 6 | 特になし、設定・構築の難易度、ソリューションの選定など |
■Q7. 今回のイベントで知りたいこと、聞きたいことがあれば教えてください。
| カテゴリ | 件数 | 主な内容 |
|---|---|---|
| IPsecへの移行実務・設定・安全性 | 7 | 構築・移行時の注意点(ハマりポイント)、IPsecの安全性・優位性の根拠、SAML連携時のタイムアウトなどのトラブル対応 |
| 代替手段・今後の技術動向・他社動向 | 6 | SASE以外の代替策、他社製品の対応状況、VPN/IPsecの中長期的な存続やサポート見通し |
| ZTNA / SASEへの移行と市場感度 | 5 | ZTNA/SASEの移行手順や安全性、他社の導入状況、小規模・個人環境での適用可否 |
| セキュリティ全般・脆弱性への対策 | 4 | 脆弱性が狙われる原因、パッチ未適用の理由、その対策、生成AI普及による影響 |
| SSL-VPN廃止の背景・サポート期間 | 3 | 廃止に至った背景、猶予期間延長の理由、特別サポートの実態 |
| 運用改善・全体像の把握 | 2 | 事象の全体像の理解、運用の簡素化・効率化の方法 |
| 特になし | 1 | 質問事項なし |
9.4 事後アンケート結果
■Q1.今回の勉強会の満足度を教えてください
| 評価 | 件数 | 割合 |
|---|---|---|
| 1 | 0 | 0% |
| 2 | 0 | 0% |
| 3 | 3 | 5.8% |
| 4 | 19 | 36.5% |
| 5 | 30 | 57.7% |
| 合計 | 52 | 100% |
平均:4.52点 / 5点満点
■Q2.今回の勉強会の理解度を教えてください
| 評価 | 件数 | 割合 |
|---|---|---|
| 1 | 0 | 0% |
| 2 | 0 | 0% |
| 3 | 12 | 23.1% |
| 4 | 20 | 38.5% |
| 5 | 20 | 38.5% |
| 合計 | 52 | 100% |
平均:4.15点 / 5点満点
■Q1とQ2の理由を教えてください。
| カテゴリ | 件数 | 主な内容 |
|---|---|---|
| 実機デモ・資料・解説への高評価 | 8 | GUIを用いた設定デモや、簡潔で分かりやすい資料・解説への高評価 |
| 技術的な理解の向上 | 6 | SSL-VPN廃止の背景、IPsec移行のポイント、通信やセキュリティの仕組み理解の深化 |
| 新たな知見(ZTNA/SASE・周辺製品)の獲得 | 3 | ZTNAやFortiSASEへの移行の必要性、EMSやPAMなど周辺製品の学び |
| 情報量の多さと復習への意欲 | 3 | 内容の高度さ・情報量の多さから、資料での復習や社内展開への意欲 |
| その他(確認・称賛など) | 2 | 事前調査の答え合わせや、ポジティブな感想 |
■Q3.感想やご意見などがあればお願いします。
| カテゴリ | 件数 | 主な内容 |
|---|---|---|
| 運営への感謝とイベントの高評価 | 9 | コンテンツへの感謝や「最高」「楽しかった」などの賛辞、タイミングが合致したことへの評価 |
| 実務に直結する技術的な学び・気づき | 5 | 自動アップデート制御、SSL-VPNとIPsec併用の気づき、汎用知識の獲得、事前調査の答え合わせ |
| 特定の技術に対する関心・今後の要望 | 3 | SASE構成の深掘り、PAMへの関心、脱VPNへの意欲、アーカイブ配信の要望 |
| 資料や最新情報の提供に対する評価 | 3 | 分かりやすい資料への評価、メーカー担当者による最新情報提供への満足 |
たくさんの人にご参加いただき、誠にありがとうございました。
