MFA サービス停止：VPN 接続の可否を事前に決めておく

VPN への接続が止まり、アラートは第二要素のサービスに到達できないと告げています。誰かがまだ接続できるかどうかは、障害の発生前に答えておくべきポリシーの問いであり、発生中に決めることではありません。検証サービスが利用できないことは、要素が通過した証拠ではなく、拒否された認証要求は到達不能と同じ出来事ではありません。以下の手順書は、この区別を検証可能な文書化されたルールに変えます。

手順 1：三つの結果を別々に名付ける

三つの状態を書き出し、それらを一つにまとめることを拒否してください。一次認証の失敗、第二要素の要求が拒否またはタイムアウトした状態、MFA サービスがまったく応答しなかった状態で、それぞれ担当者もログ行も正しい対応も異なります。汎用的なタイムアウトのメッセージが一つあると、どれに当たるのかが隠れ、その曖昧さが障害を議論に変えます。必要になる前に、手順書で状態に名前を付けておきましょう。

拒否は、検証サービスが応答して「いいえ」と答えたという意味で、可用性の問題ではなくポリシーの結果です。期限切れの試行は、要求が存在したのに誰も時間内に完了しなかったという意味です。到達不能なサービスは、問いにまったく答えが返らなかったという意味です。三つ目のだけが障害です。

手順 2：プロキシが実際に使う失敗時の動作を読む

サービスに接続できないときの動作を決める設定を見つけ、テンプレートではなく実行中の構成から読み取ってください。Duo の RADIUS プロキシでは、文書化された failmode の値は safe と secure で、safe は一次認証が成功したときだけ試行を許可し、secure はその条件で試行を拒否します。

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

safe という名前は可用性の選択を表すもので、受け入れたすべてのセッションに新しい第二要素があったという保証ではありません。設定が行う取引がまさにそれなので、この一文はリスク台帳に載せるべきです。値を別の事業者、別の統合、別のプロキシ方式に一般化せず、その製品自身の相当する設定についてはその製品の文書を読んでください。この理解なしにベンダーの例からコピーした構成は、次の障害を待つ驚きです。

どの方式が有効かを誰も言えないなら止めてください。手順書の残りはその答えに依存します。

手順 3：再試行をフローに合わせる

ゲートウェイのタイムアウトと再試行の動作を、それが動かしている認証フローに合わせてください。調整されていない再試行は複数のプロンプトを生み、試行の対応付けを混乱させ、ログがどの結果がどのログインのものか言えなくなります。非常に長いタイムアウトは可用性の設計ではなく、同じ答えをより長く待つことです。

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

プロキシ自身の要求タイムアウトは別の限界で、発行されて完了しない認証要求は拒否され、その拒否は戻ることのできる障害ではありません。拒否、未完了の要求、到達不能なサービスを、判断表への三つの異なる入力として扱ってください。そして、どの状態が受け入れ、どの状態が保留し、どの状態が人間にエスカレーションするのかを表で明示してください。

二つのコンポーネントがどちらも再試行するなら、まず再試行の所有権を直してください。重複したプロンプトは所有者が二つある症状で、遅いサービスの症状ではありません。

手順 4：緊急アクセスは別に統治する

緊急アクセスが必要なら、独自の範囲、身元、権限、監査証跡を与えてください。全ユーザーに対して MFA を静かに無効化することは緊急時の手順ではなく、インシデントを伴う恒久的な弱体化です。セキュリティの責任者が、受け入れルール、可視性、エスカレーション経路を事前に承認します。

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

本番以外の環境で、一次認証の失敗、意図的な拒否、要求の期限切れ、サービスの利用不能というマトリクス全体を試験してください。それぞれについて、受け入れの結果と記録された理由を残します。設定された動作を知るために本番障害を起こさず、緊急経路をそのために書かれたインシデントの最中に初めて試さないでください。一度も実行されていない復旧手順は文書であり、統制ではありません。

三つの状態に名前が付き、失敗時の動作が実行中のシステムから読み取られ、再試行の所有者が一つに定まり、緊急アクセスに独自の承認と見直しがあって初めて、手順書は終わります。予測可能な適用と既知の復旧経路こそ、文書化する価値のある成果です。