ログイン検査が2つでも二要素ではない：VPNとRADIUS

VPNゲートウェイに二つ目の認証バックエンドを追加すると、二要素目を追加したように感じます。しかし通常は二つ目の検査が増えるだけで、これは別の失敗モードを持つ別の対象です。両方が成功する必要があるのか、それぞれが何を証明するのか、片方が利用できないときに何が起きるのかは、三つの別個の決定です。これを誤ると、デモでは厳しく、障害時には弱いゲートウェイになります。

二つ目のバックエンドが実際に証明するもの

ローカルアカウントの検索は、名前がデータベースに存在し、パスワードがそれに一致したことを証明します。RADIUS交換は、RADIUSサーバーが 受け取った属性に対してAccess-Acceptを返したことを証明します。どちらの記述も要素の種類には触れていません、なぜなら どちらも知識を検証するからです。そしてNISTのデジタルアイデンティティガイドは、異なる要素の種類とその認証器を数えており、サーバーやプロンプトではありません。

両方のシステムが関与する正当な設計もあります。中央サービスが本人を認証し、ゲートウェイがそのアカウントにこのトンネルの権利があるかを独立に確認します。これは認証に並ぶ認可であり、これを二要素と呼ぶと、ポリシー検査と所持の証明を混同します。

RADIUSは、プッシュ承認やハードウェアトークンなど、一つを検証するものの前段に置かれると、本当の二要素目を運べます。封筒は利用者がどの認証器を示したかを教えないため、ゲートウェイのラベルではなくバックエンドのポリシーを読んでください。

AND、OR、フォールバックは別の製品です

実装を比較する前に、要件における両方の意味を決めてください。ANDポリシーは指定されたすべての検査の通過を要求し、ORポリシーはいずれか成功したものを受け入れ、フォールバックは宣言された障害条件でのみ二つ目を試します。この三つは障害時に逆の振る舞いをし、通常レビューが意図したのはそのうち一つだけです。

構成画面にバックエンドの項目を二つ追加しても、製品がどのポリシーを実装しているかは分かりません。プラグインを順に連結し最初の拒否で止まるゲートウェイもあり、それはすべてのプラグインが必須のときだけANDです。ローカルアカウントを上書きとして扱うものもあり、それは中央の障害を迂回に変えます。信頼できる答えは、導入するビルドに対して実行する、経路ごとの文書化された否定テストです。

フォールバックが最も疑わしいのは、何かが壊れたときにも動き続けるために存在するからです。RADIUSに到達できないたびにローカルパスワードを受け入れるフォールバックは、中央のポリシーを二つ目の弱い扉に変えてしまっています。

OpenVPNの二重検査は具体的な事例です

コミュニティ版OpenVPN 2.6は、両方が有効なとき、クライアント証明書と設定されたauth-user-pass-verifyスクリプトの両方を要求します。これは証明書検証と資格情報スクリプトの間の文書化されたANDであり、本当に二つの検査です。それは依然として自動的に二種類の要素ではありません、スクリプトがパスワードだけを検証するかもしれないからです。

この組み合わせは関連付けの問いも残します。証明書は通常デバイスを識別し、資格情報は人を識別しますが、既定のフローでは両方が同じ主体を指すことを要求しません。どの組を許可するかを決め、その対応表を検証スクリプト内か後続の認可ステップで強制してください。

証明書のみのモードは一つの検査で、PINで保護されているかどうか分からない鍵に支えられています。PINは、その鍵なしでは使えない場合に限り、同じ資格情報を知識と所持に変えます。鍵をディスク上で暗号化せずに置くと、二つ目の部分はファイル権限に縮みます。

アプライアンスベンダーは独自の配管を作り、多くの場合ウェブコンソールの背後にPAMモジュールやRADIUSプラグインを置きます。コミュニティの振る舞いは二重検査がどう見えるかの参考であり、アプライアンスがそれらをどう組み合わせるかの説明ではありません。

自分のゲートウェイで組み合わせを確認する

コンソールの要約を信じる前に構成を読んでください。ポリシーを決める行は、証明書モード、資格情報スクリプト、プラグインの順序です。

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grepは証明書が必要かどうかと、その後にどのスクリプトが走るかを示し、順序は名前が示す以上に重要です。証明書のダンプはゲートウェイが見る識別情報を与え、関連付け表に必要なCNとシリアル番号を含みます。RADIUSのテストは否定ケースで、誤ったパスワードはAccess-Rejectを、正しいものはAccess-Acceptを生む必要があります。拒否された資格情報がそれでもセッションを生むなら、スクリプトは認証経路にまったく載っていません。

次にラボのインスタンスで、必須のバックエンドを止めて有効な資格情報で接続し、障害ケースを実行します。期待される結果は拒否であり、それ以外は誰も文書化していないフォールバックポリシーです。

要件を否定ケースとして書く

使える要件は、証明、それを提示できるアカウント、検証者が欠けたときの結果を名指しします。デバイスの識別情報と人の識別情報の間で許される対応も述べます。これは発注書の製品名より正確で、テストできます。

受け入れには、不適格なローカルアカウント、欠けた必須の証明、無効な二要素目、到達できない必須バックエンドという四つの拒否を含めるべきです。各拒否には他のものと区別するログ行が必要で、そうでなければ次のインシデントは推測から始まります。ゲートウェイ、RADIUSサーバー、ディレクトリは互いに責任を押し付けるので、どのコンポーネントが各決定をしたかを記録してください。

プラグインやファームウェアを変更したら、四つの拒否を再実行してください。安価であり、それらが守るポリシーは攻撃者が最初に調べる部分です。