はじめに
この章では、本書の目的と読者、学ぶべきポイントをわかりやすく説明します。
目的
FortiGateのSSLインスペクションは、暗号化された通信（例えば銀行サイトやウェブメール）を一時的に復号して安全性を確認する機能です。本書は、実務で必要な基礎知識と運用上の注意点を丁寧に伝えます。専門用語は最小限にして、具体例を交えて説明します。
対象読者
- ネットワーク管理者やセキュリティ担当者
- FortiGateを導入検討中の方
- SSLインスペクションの基礎を短時間で把握したい方
本書で学べること
- インスペクションの基本概念と目的
- deep-inspectionとcertificate-inspectionの違い（後章で詳述）
- FortiGateでの基本設定ポイントと運用時の注意点
次章からは、まずSSLインスペクションの全体像を平易に解説します。
SSLインスペクションの概要
概要
FortiGateのSSLインスペクションは、クライアント（例：社員のPC）とサーバ（例：Webサイト）の間に入り、暗号化された通信を一時的に復号して検査する仕組みです。復号後にウイルス検査やアクセス制御を行い、再び暗号化して送信します。
仕組み（簡単な流れ）
- クライアント→FortiGate：クライアントはサーバへ接続要求を出します。
- FortiGate→サーバ：FortiGateがサーバと別の暗号化セッションを張ります。
- 検査：FortiGateが中間で復号し、ポリシーやアンチウイルスで検査します。
- クライアントへ再暗号化：検査後、FortiGateが検査用の証明書で再暗号化してクライアントに渡します。
主な利点
- HTTPS内部のマルウェアや不正通信を検出できます。
- Webフィルタやアプリ制御を暗号化通信内にも適用できます。
注意点
- プライバシー：通信内容を復号するため、個人情報や機密データの扱いに注意が必要です。ポリシーで検査対象を限定する設計が重要です。
- 証明書管理：FortiGateが生成する中間証明書をクライアント側で信頼させる必要があります。銀行サイトなど証明書ピンニングのあるサービスは接続できない場合があります。
- 性能：復号・検査処理で機器に負荷がかかります。帯域やCPUの余裕を確認してください。
展開パターンの例
- 透過モード：ネットワークのゲートウェイとして自然に動作します。設定が少なく導入が簡単です。
- プロキシ（明示）モード：クライアント設定でプロキシを指定します。詳細な制御やログ収集がしやすいです。
deep-inspection と certificate-inspection
概要
deep-inspectionは通信を一度復号して中身を詳しく検査し、問題がなければ再暗号化して転送する方式です。検査精度が高く、通信内のファイルや投稿内容まで確認できます。一方、certificate-inspectionはサーバ証明書やSNI（接続先の名前）を確認して簡易なチェックやフィルタを行います。復号しないため負荷が小さく、速い処理が可能です。
deep-inspectionの仕組みと特徴
機器が自ら中間者として動き、サーバ側とクライアント側の両方と暗号化された通信を作ります。結果としてURLや本文、アップロードファイルなどを細かく検査できます。高度なマルウェア検出や機密データ漏えい対策に向きます。ただし、CPUやメモリの負荷が高くなり、証明書ピンニングを使うアプリは正常に動かない場合があります。プライバシー配慮や法的確認も必要です。
certificate-inspectionの仕組みと特徴
サーバ証明書の発行元や有効期限、SNI情報から接続先を判断します。復号を行わないため処理は軽く、HTTPS通信の大まかな分類やURLベースのフィルタに適します。通信内部の詳細は見えないため、本文や添付ファイルの検査はできません。軽い負荷で広範囲を守りたい場合に有効です。
使い分けの目安
・高い検査精度や機密情報保護が必要ならdeep-inspectionを選びます。例：社内の機密文書や銀行取引の監視。
・速度や互換性、運用コストを重視するならcertificate-inspectionを選びます。例：一般的なWebフィルタや帯域管理。
選択時はセキュリティ要件とユーザー体験のバランスを考えてください。
モードの違いまとめ
簡単な結論
deep-inspectionは通信を復号して中身まで詳しく検査します。セキュリティは高く脅威検出力に優れますが、クライアント側に証明書の配布や信頼設定が必要になります。certificate-inspectionは復号しない簡易チェックで、証明書情報や接続先名（SNI）などを確認します。中身は見ないため、クライアント証明書の配布は不要なことが多いです。
仕組みの違い
- deep-inspection：TLSを復号してHTTPや通信ペイロードまで検査します。マルウェアや不正なスクリプトも検知できます。
- certificate-inspection：ハンドシェイクでやりとりされる証明書やSNI、ポート情報を基に判断します。暗号化後の中身は見ません。
運用面の差
- 準備：deepでは内部CAを配布したり端末にルートを入れる必要があります。certificateではその手間がほぼ不要です。
- パフォーマンス：deepは復号・再暗号化でCPU負荷が高くなります。certificateは軽い負荷です。
- ユーザー体験：deepで証明書エラーやピンニングの問題が起きる場合があります。certificateは干渉が少ないです。
選び方の目安（具体例）
- 重要な社内環境でマルウェア対策を重視する場合：deep-inspectionを検討します。端末管理が可能で、証明書配布に支障がないことが前提です。
- 公衆Wi‑Fiやゲストネットワークで利用者の端末をいじれない場合：certificate-inspectionが現実的です。検出力は限定されますが導入が簡単です。
以上をもとに、セキュリティ要件と運用コストを天秤にかけて選ぶとよいです。
FortiGateでの基本設定ポイント
プロファイルの作成とポリシー適用
GUIで「Security Profiles → SSL/SSH Inspection」を開き、既存のdeep-inspectionやcertificate-inspectionプロファイルを複製して編集します。名前をわかりやすく付け（例: SSL-Deep-Office）、該当ポリシーに割り当てて通信を検査します。プロファイルでは検査対象（HTTP/HTTPSなど）と検査レベルを設定します。
FortiGate CA証明書の配布
deep-inspectionを使う場合、FortiGateが発行するCA証明書をクライアントの「信頼されたルート」にインポートします。配布方法は環境に合わせて選びます。例えば、Windows環境はGPO、モバイル端末はMDM、小規模は手動配布が現実的です。配布後はブラウザで証明書警告が出ないことを確認します。
除外と例外サイトの設定
金融機関や証明書ピン留めのあるサービスなど、SSL中間解読が許容されないサイトを除外リストに登録します。URLやIP、SNIで除外する運用が一般的です。通信異常が出た場合はまず除外設定を疑ってください。
ログ・監視とパフォーマンス管理
SSL復号は負荷が高くなります。CPUやSSLセッション数、ログ量を監視し、必要ならオフロードや検査対象の絞り込みを行います。ログはTLSバージョンやサーバ証明書情報をチェックするのに役立ちます。
テスト運用と運用ルール
いきなり全社展開せず、先にパイロットグループで動作確認を行います。証明書の有効期限管理、配布手順、トラブル発生時の除外フローを文書化してください。バックアップと設定のエクスポートも忘れず行います。
設計・運用時の注意点
除外ポリシーの方針
機微情報を扱うサイト（銀行、医療、行政など）はdeep-inspectionの対象外にする運用を推奨します。具体的にはSNIやホスト名、IPレンジで除外リストを作成します。例：SNIにbank.exampleやhealth.exampleを含むトラフィックは検査を行わない、といった設定です。利用者のプライバシーと法令遵守を優先します。
FortiOSのバージョン差と対応確認
FortiOSのバージョンでTLS1.3やHTTP/3/QUICの検査可否や制限が異なります。導入前に現在のバージョンでプロキシモードが利用可能か、TLS1.3の0-RTTや暗号スイートの制約を確認してください。OSアップデートを行う際は、検査ポリシーの見直しを同時に計画します。互換性の問題で通信が切断される場合があります。
性能とログ管理
deep-inspectionはCPUとメモリを多く消費します。検査対象を絞り、重要なログ項目のみ収集することで負荷を抑えます。ログは定期的に確認し、異常なSSLエラーや検査失敗を早期に検出してください。
ユーザー影響とサポート体制
証明書警告やアプリケーションの接続失敗が発生することがあります。ユーザーへ事前に周知し、問い合わせフローを用意します。証明書ピンニングや古いクライアントは動作しない場合があるため、影響端末のリストアップと代替手段を準備します。
テストと変更管理
本番投入前に段階的にテスト環境で検証します。代表的なサービスを対象に接続確認とログ確認を行い、問題があれば除外リストやポリシーを調整します。変更はドキュメント化し、ロールバック手順を明確にしてください。
セキュリティとコンプライアンス
除外を増やし過ぎるとセキュリティが低下します。リスク評価を定期的に行い、法的要件や社内規定と照らしてポリシーを更新してください。事故発生時の対応手順と監査ログの保全を必須とします。
