FortiGate VPN MFA：ローカルトークン、RADIUS、SAMLのどれを選ぶか

FortiGate VPN MFAの設計は、まず「第二要素を誰が検証するのか」という一つの問いから始まります。ゲートウェイ自身がローカルトークンやメールで送るコードで検証する場合もあれば、RADIUSバックエンドが強制してチャレンジを返す場合、SAMLのIDプロバイダーがブラウザ内で手続き全体を担う場合もあります。どれを選ぶかでログインの流れ、失敗の兆候、復旧手順が変わり、コマンドブロックを流用すると、もっともらしく見えて誰も認証できない設定が出来上がります。本記事は仕組みを扱い、各設計がログイン時に実際に何をしているのか、どこで破綻するのかを説明します。

ログイン手続きが要素の所有者を決める

最初の二つの設計では、FortiGateが信頼する側になります。資格情報を集め、第二要素が必要かどうかを判断し、ローカルまたはチャレンジを促して検証します。三つ目の設計では、ゲートウェイは検証者ではなく中継者になり、クライアントをIDプロバイダーへリダイレクトし、アサーションを受け取り、表明されたIDをユーザーとグループに対応付けます。RADIUSの設計では両者の中間に位置し、ポリシーを持つバックエンドとの要求と応答のやり取りを駆動します。

この違いが、集められる証拠を決めます。ゲートウェイが検証する場合、そのデバッグ出力が何が起きたかを教えてくれます。IDプロバイダーが検証する場合、ゲートウェイはアサーションが届いたことしか分からず、「MFAが実際に要求されたか」の答えはプロバイダーのログにあり、ファイアウォールのログにはありません。誤ったログを読むことは、設計どおりに動いている展開を誤診する最も一般的な原因です。サービス自体も手続きを制限します：FortiOS 7.6.3はSSL VPNトンネルモードを廃止し、IPsecを採用しますが、Webモードは対応モデルでAgentless VPNとして継続するため、あるサービスで証明された手続きが別のサービスでもそのまま使えるわけではありません。

ローカル検証：トークンとメールコード

FortiGateが管理する要素はユーザーオブジェクトに紐づきます。FortiTokenや文書化されたトークン連携には、登録、対応する検証手続き、該当する場合のライセンス、交換手順が必要です。メールで送るコードには、動作するSMTP経路と、トンネルができる前にユーザーが到達できるメールボックスが必要であり、これは暗号技術とは無関係で、誰かがログインできるかどうかに深く関係する依存関係です。

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

メール配信は認証の可用性の一部であり、VPN経由でしか到達できないメールボックスは、誰にとっても自力で解けないループを作ります。配信遅延、コードの有効期間、リモート認証のタイムアウトは三つの別々の制約です。一つを引き上げても到達不能なメールボックスは直らず、ループを試したことのない設計は休暇明けの最初のパスワードリセットでそれを発見します。

保証要件もここに属するため、製品選定の前に確認してください。NIST SP 800-63Bはメールを帯域外認証として受け入れがたいものとしているため、準拠をうたう展開はどれほど便利でもメールコードを第二要素に使えません。機器に機能があることは、その機能が所定の標準を満たすという表明ではありません。

RADIUS：ゲートウェイが問い、バックエンドが決める

RADIUSでは、FortiGateは資格情報を要素ポリシーを持つバックエンドへ送ります。やり取りは単純な許可か拒否か、あるいはクライアントが答えるべきチャレンジを含むことがあり、その場合、VPNサービスとクライアントの両方がそのチャレンジの形に対応している必要があります。プッシュ承認を強制するバックエンドと、パスワードに六桁のコードを付けることしか知らないクライアントは、途中で出会いません。

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

トンネルを責める前に、バックエンドを単独でテストしてください。authserverのテストが成功してVPNログインが失敗するなら、違いは資格情報ではなくチャレンジの扱いにあり、ゲートウェイの認証デーモンのデバッグにそれが現れます：

diagnose debug application fnbamd -1
diagnose debug enable

SAML：ブラウザがゲートウェイを離れる

SAMLの設計では、クライアントはIDプロバイダーへリダイレクトされてそこで認証し、アサーションを持って戻り、ゲートウェイはそれを信頼関係とグループ対応付けに対して検証します。ゲートウェイはパスワードも第二要素も見ないため、これはセキュリティ上の改善であると同時に運用上の複雑さでもあり、失敗はファイアウォールが検査できないブラウザセッションの中で起きるのです。

アサーションを受け入れることは、プロバイダーがそのサインインにMFAを要求した証拠になりません。一部のアプリケーションにだけMFAを適用するプロバイダーのポリシーでは、要求したとおりのログインが得られても、前提とした保証は得られません。この特定のアプリケーションについてプロバイダーのポリシーを確認し、どちらかで名前を変更した後もグループクレームのFortiGateグループへの対応付けが一致しているか確認してください。

クライアントの対応はここで最も重要になります。VPNクライアントの中にはブラウザへの引き渡しをネイティブに扱うものもあれば、システムブラウザを開くものもあり、ヘッドレスやコマンドラインのクライアントはフローを完了できないことがあります。プロファイルを公開する前に、ユーザーが実際に使うクライアントと、実際に使うプラットフォームでテストしてください。

復旧も仕組みの一部です

上のどの設計にも、到達不能なメールボックス、紛失したトークン、チャレンジを拒否するバックエンド、ロックされたIDプロバイダーのアカウントという、一度に一人のユーザーで失敗しうる依存関係があります。誰がアクセスを復旧できるのか、どの対応手順で、申請者のどのような確認をもって行うのかを今決めてください。VPN経路から切り離して保持する緊急用のローカル管理者アカウントは一つの統制です、説明のないパスワードだけの迂回は、発見を待つインシデントです。

次に、展開前に三つのログイン（通常のログイン、拒否されたか期限切れの要素、承認された紛失認証器の復旧）をテストします。それぞれがどのログに現れるかを記録してください。その記録が「MFAは有効です」を、他の誰かが運用できる設計に変えます。