はじめに
前回は、BUFFALO法人向けAPの Link Integrity を使って、SingleID連携SSID と緊急用SSID を切り替える構成を検証しました。
ただ、その構成がすべてのお客様に必要とは限りません。求める可用性は、業務内容やネットワークの使い方によって変わります。
そこで今回は、SingleID連携Wi‑Fiの可用性を3つのフェーズに分けて考えます。
- まずは SingleID 側の可用性を前提に運用する
- 必要に応じて AP 側の設定を見直し、再認証の発生を抑える
- さらに必要な場合だけ Link Integrity による自動切替を使う
まず前提にしたいこと
今回の話は、「SingleID が不安だから追加対策を入れる」という話ではありません。
前提は次の2つです。
- SingleID 側では、サービス可用性を高める
- お客様環境側では、必要に応じて接続継続策を追加する
この2つは役割が違います。まずは SingleID 側で担う可用性があり、そのうえでお客様環境側にどこまで追加対策が必要かを考えます。
フェーズ1：まずは SingleID の可用性を前提に運用する
最初のフェーズは、SingleID が提供する可用性を前提に、WPA2/WPA3-Enterprise 認証をそのまま運用する という考え方です。
SingleID のクラウドRADIUSは AWS 上で稼働し、物理的に分離された複数のアベイラビリティゾーンに配置されています。また、ロードバランサーは使わず、プライマリRADIUSとセカンダリRADIUSを個別に用意し、障害時には RADIUSクライアントであるAPの設定 によりセカンダリRADIUSへ自動的に認証先を切り替える構成です。加えて、24時間365日の常時監視と、障害検知時のサーバープロセス自動復旧も前提になっています。
また、障害時に影響を受けるのは主に 新規の認証要求 です。RADIUS は常時通信を行うわけではないため、接続済みユーザーが即時に切断されるわけではなく、新規接続や再認証のタイミングが論点になります。
このフェーズだけでも、共有パスワード運用に比べれば前進です。個人ごとに証明書で認証できるため、利用者単位・端末単位で管理できます。
そのため、すべてのお客様に最初から追加対策が必要なわけではありません。まずは SingleID を前提に安全な認証へ移行し、その上で必要なら補強する、という順番で十分なケースは多くあります。
このフェーズが向いているのは、たとえば次のようなケースです。
- まずは共有パスワード運用をやめたい
- 認証強化の優先度が高い
- 障害時の自動切替までは求めていない
フェーズ2：再認証の発生を抑える
次のフェーズは、AP側やクライアントデバイス側の設定を使って、再認証が起きる頻度を下げる という考え方です。
ここで見るのは次の2点です。
- 認証キャッシュ（Auth Cache）
- 再認証間隔（Re-Auth Interval）
直近の認証成功情報を保持する設定を有効にしておけば、一時的にサーバーと通信できなくても、キャッシュ情報を使って再接続を許可できます。また、再認証間隔を長めに設定しておけば、障害発生中に再認証が集中しにくくなります。
第1回の検証中のディスカッションを踏まえると、BUFFALO法人向けAPでまず見直したいのは セッションタイムアウト です。1時間程度を一つの目安に、再認証が起きる間隔を短くしすぎないように設定すると、障害発生中の再認証集中を抑えやすくなります。
さらに、複数AP環境でローミングが発生する場合 は、PMKキャッシュも有効です。BUFFALO法人向けAPでは、セッションタイムアウトとPMKキャッシュの時間は同じです。PMKキャッシュを有効にしておけば、障害発生中のローミングでも再認証を起こしにくくできます。
つまりフェーズ2の中心は、まず セッションタイムアウトを見直して再認証の発生を抑えること です。そのうえで、複数AP環境なら PMKキャッシュも追加します。
多くのお客様では、このフェーズまでで十分だと思います。SingleID 側の可用性対策に加えて、再認証の起き方を調整しておけば、かなりのケースをカバーできます。
このフェーズが向いているのは、たとえば次のようなケースです。
- 障害発生中の再認証頻度が気になる
- セッションタイムアウトを見直したい
- 複数AP環境でローミングも発生する
- 自動フェイルオーバーまでは必要ない
フェーズ3：必要な場合だけ Link Integrity による自動切替を使う
最後のフェーズが、Link Integrity を使って緊急用SSIDへの自動切替まで行う という考え方です。
これは、普段は SingleID連携SSID を使い、SingleID のクラウドRADIUSに到達できなくなった時だけ、緊急用の PSK用SSID へ切り替える構成です。第1回で直接検証したのは、デフォルトゲートウェイ監視による切替動作でした。ここでは、その結果を踏まえて実運用での位置づけを考えます。
このフェーズは、緊急時の接続継続を最優先したい場合の追加策 です。通常時は無効、緊急時のみ有効という運用になります。一部APでは自動検知・切替も可能です。
ただし注意点もあります。PSK運用では個人を特定できません。さらに、パスワード漏洩リスクがあるため、緊急利用後はSSIDパスワード変更が必要です。
このため、フェーズ3は標準構成ではなく、販売店やSIerが持っておくオプション として考えるのが自然です。
また、Link Integrity は短くしすぎないことも重要です。簡単に切り替わりすぎると、PSKが近道になってしまいます。切替は、本当に必要な時だけ起きるように設計します。
Link Integrity による自動切替は、たとえば次のようなケースで検討しやすくなります。
- 社内LAN接続の継続が重要
- インターネット断そのものより、社内リソース利用継続を重視したい
- BUFFALO の NAS など、社内LAN上のリソースを使い続けたい
- 障害時の考え方まで含めて提案したい
逆に言えば、「クラウドRADIUSを使う以上、必ず Link Integrity が必要」という話ではありません。
ベストプラクティスとしてどう伝えるか
販売店やSIerが持っておきたい選択肢は、次の3つです。
- SingleID の可用性を前提に、そのまま運用する
- セッションタイムアウトを調整し、必要に応じて PMKキャッシュも使いながら再認証の発生を抑える
- 必要な場合だけ Link Integrity による自動切替を追加する
この順番なら、お客様にも説明しやすくなります。最初からすべてを入れるのではなく、
- どこまで可用性を望んでいるか
- どこまで自動化が必要か
- 社内LAN継続の重要度はどれくらいか
を見ながら、必要なところまで選んでもらう形です。
まとめ
SingleID連携Wi‑Fiの可用性は、単に「自動フェイルオーバーを入れるかどうか」で決まる話ではありません。
考え方としては、
- フェーズ1：SingleID の可用性を前提に運用する
- フェーズ2：セッションタイムアウトを調整し、必要に応じてPMKキャッシュも使いながら再認証の発生を抑える
- フェーズ3：必要な場合だけ Link Integrity による自動切替を使う
という順番です。
多くのお客様では、フェーズ1とフェーズ2までで十分だと思います。フェーズ3は、その先で必要なお客様にだけ提案するオプションです。
認証のセキュリティを強化しつつ、どこまで可用性も求めるのか。その線引きをお客様ごとに決められることが、SingleID と BUFFALO法人向けAPを組み合わせる価値の一つです。
