二要素認証を備えた仮想 VPN ゲートウェイの受け入れ検証

ベンダーはこのアプライアンスを仮想で二要素対応だと説明しますが、どちらの言葉も購入を決める問いに答えていません。どのハイパーバイザーイメージが対象か、どのクライアントが登録できるか、第二要素が実際に何を証明するのか、ID プロバイダが落ちたら何が起きるのかは、まだ開いたままです。それらを受け入れ段階に変えてリハーサルで実行すれば、判断はデータシートの説得力に依存しなくなります。下のシートはその証跡のための構造であり、製品の順位付けではありません。

サプライヤがこの配備について確認すべきこと

配備を一枚にまとめることから始めます。ハイパーバイザーかクラウド、ゲストのアーキテクチャ、対応イメージ、アプライアンスが期待するインターフェースです。利用者を加え、その OS、端末が管理されているか、登録とサインインがどう動くべきかを書きます。次にプライベートアクセスです。アプリケーションとプレフィックス、DNS の構成、戻り経路、そして公衆インターネットへの出口が提案に含まれるかどうかです。

運用も同じ一枚に入ります。筐体を誰が保守するか、更新はどこから来るか、ログはどこへ行くか、設定はどう守られるか、そして事業が実際に合意した復旧目標は何かです。ソフトウェアが仮想マシンで動くことではなく、まさにその組み合わせを確認するようサプライヤに求めます。ID プロバイダやライセンスサービスといった外部依存は見える形で残します。同梱されるかどうかに関わらず配備の一部だからです。依存が名指しされていない配備シートは、たいてい未知の依存を抱えた配備シートです。

第二要素が本当に第二要素であることを証明する

認証器と検証フローを名指しし、各手順がどの身元を確立するかを述べます。パスワードを二回続けて尋ねるのは第二要素ではなく、パスワードとワンタイムコードの組み合わせは、サービスに結び付いた暗号学的認証器とは別の主張です。箱のラベルではなく、買うフローを書きます。

フィッシング耐性は別の性質であり、NIST の認証器ガイダンス もそう扱っています。利用者がだまされて中継しうるコードは、多要素認証を満たしながらその追加条件には失敗します。必要ならその性質を明示的に求めます。次に、利用者が実際に使うクライアントの種類で実演を要求し、登録、拒否または期限切れのチャレンジ、認証器を失った後の復旧、他の利用者が接続したままの一人の失効を網羅します。ゲートウェイの身元検証も範囲に残します。どのゲートウェイでも信じるクライアントは、問題を解いたのではなく移しただけだからです。

何かを壊す前に合格条件を書く

下の表は、サプライヤとの接触に耐えるシートの部分です。各行が保証ではなく証跡を求めるからです。リハーサルの前に合格条件を埋め、証跡のない行は失敗した行として扱います。五つの段階がゲートウェイの務めを覆います。

登録が最初に来るのは、その後のすべてがそれに依存するからです。登録できない端末は試験できません。サインインは登録とは別の段階で、拒否は多くのシートが忘れる段階です。全員を通すゲートウェイは、誰かを拒否することを示していないからです。失効と復元は運用リスクの大半を抱え、どちらも複製の上で安く練習できます。

本番のゲートウェイではなく複製で練習する

妨害を伴う段階は、サポートされた配備手順に従って基盤の複製で実行し、証跡はそれぞれ日付と設定バージョンとともに保管します。再起動の行はコンソールからの再起動では答えにならず、復元の行は設定のエクスポートでは答えになりません。どの状態がひとりでに戻り、何が再接続を要するかを記します。その差こそ運用チームが受け継ぐものだからです。リハーサルは、障害を説明せずに復元を計時できる唯一の機会でもあります。

各テストの時点で ID プロバイダの状態を記録します。健全なプロバイダに対して試した障害の行は、シートの主張の反対を証明するからです。同じリハーサルの二人のレビュー担当は別のものを見つけ、二番目はたいていダッシュボードの画面写真が証跡の行を見つけます。その証跡は該当する行に添えたままにし、プロジェクト名のフォルダには置きません。

チームが動かす作業負荷を測る

通常の一週間に近い負荷を決め、配備する場所で測ります。同時実行数、トラフィックの混合、そしてチームが実際に持つ保守時間帯です。宣伝されたスループットの数字は実験室の条件を述べるもので、利用者のことを何も語りません。復元は計画ではなく復旧目標に対して測ります。

すべての段階に証跡があり、すべての証跡に日付があればシートは完成です。誰かが保守し、各行に証跡のあるアプライアンスは、チェック済みの箱の最も長いリストとは別の買い物です。